Andmejuhtide teekond gigabaitidest petabaitideni
Allikas: Äri-IT Kevad 2025
Autor: Dmitri Oništšik, andmearhitekt
Kuidas lahendada aruandlusplatvormi skaleerimise probleeme, kui ettevõtte kasv ületab tehnoloogilised võimed?
Kujutagem ette olukorda: teie ettevõte kasvab kiiresti – kui varem lugesite tellimusi tuhandetes, siis nüüd sadades tuhandetes. Ettevõtte aruandlusplatvorm on surve all ning teie ülesanne on see probleem lahendada. Ei tundu esmapilgul eriti keeruline, eks? Tuleb lihtsalt skaleerida, lisada süsteemi rohkem võimsust ja ressursse ning probleem kaob. Kuid lahendus ei pruugi olla nii lihtne.
Uuringud on näidanud, et meeskonna suuruse kahekordistamine ei too peaaegu kunagi kaasa samaväärset tootlikkuse kasvu. Sageli võib juhtuda hoopis vastupidi – jõudlus langeb märgatavalt. Kas see kehtib ka andmeplatvormide kohta?
Kasvava andmemahu proovikivid
2000. aastate alguses hakkasid mõned Silicon Valley ettevõtted (nt Yahoo, Amazon, Google ja Facebook), kes kogusid ja töötlesid enneolematul hulgal andmeid, kogema mitmesuguseid andmetöötluse ja -halduse probleeme. Tööriistad ja tehnoloogiad, mida tol ajal kasutati, ei suutnud enam pidevalt kasvavat andmemahtu hallata. Andmete hulk aina kasvas tänu interneti ja sotsiaalvõrgustike levikule. Mida rohkem inimesi oli ühendatud ülemaailmse veebiga, seda rohkem sisu nad iga minutiga lõid.
Viimase kümnendi jooksul on mobiilseadmed ja asjade internet andmete hulka veelgi suurendanud. Keskmiselt kasvab andmete maht igal aastal üle 20% võrreldes eelnevate perioodidega. Mahu kasv mitte ainult ei võimenda varasemaid probleeme, vaid toob kaasa ka täiesti uusi väljakutseid, mida oli varem raske ette näha.
Andmete omadused
Suured andmed (big data) oli tuntud kontseptsioon ka enne 2000. aastaid, kuid see ei olnud veel mure, mis oleks tollal puudutanud igat ettevõtet. Tänapäeval võivad peaaegu kõik ettevõtted oma elutsükli mis tahes etapis kokku puutuda suurte andmete probleemiga. Kolm V-d – maht (volume), kiirus (velocity) ja mitmekesisus (variety) – on suurandmete määravad omadused. Maht viitab andmete kogusele, kiirus andmetöötluse kiirusele ja mitmekesisus andmetüüpide hulgale. Kuigi olulised on kõik kolm, keskendume selles artiklis eeskätt mahule, kuna see nõuab tööriistade ja protsesside kohandamist.
Enamik andmetega seotud probleeme tuleneb kahest tegurist: tehnoloogilised piirangud ja vajalike andmehaldusprotsesside puudumine. Kui maht kasvab, võite avastada, et praegused tööriistad ja arhitektuurid enam ei tööta – need pole loodud horisontaalseks skaleerimiseks. Kujutage ette, et teil on üks andmebaasiserver, mis on nüüd 100% ulatuses kasutusel, kuid mis ei suuda sellest hoolimata uut aruannet õigel ajal esitada. Olete selle probleemiga varemgi kokku puutunud ning tellite serverile rohkem mälu. See aitab, aga ainult mõneks ajaks. Seda nimetatakse vertikaalseks skaleerimiseks – lisate süsteemi üha rohkem ressursse, suurendate salvestusruumi ning tellite kiirema kõvaketta, uue protsessori jne. Lõpuks tuleb piir ikkagi ette – te ei saa lõputult lisada aina võimsamaid komponente.
Andmete skaleerimine
Lahendus on panna mitu odavamat arvutit koos tööle ja jaotada töö nende vahel ära. Teoreetiliselt saate selliseid arvuteid lisada lõputult ning olete võimeline töötlema ja salvestama mis tahes vajalikku andmemahtu. Seda nimetatakse horisontaalseks skaleerimiseks. Kaasaegsed andmeplatvormid ongi ehitatud tavaliselt sellise skaleeritavuse põhimõtteid järgides:
- arvutus- ja salvestusressursside eraldamine – saate suurendada salvestusmahtu ilma, et peaksite suurendama arvutusvõimsust, ja vastupidi;
- paralleelne andmetöötlus – töö jaotamine tükkideks ja iga osa töötlemiseks oma arvutusmootori kasutamine;
- järkjärgulised laadimised – ETL-protsessi käivitamisel töödeldakse teabest ainult uut osa, mitte iga kord kogu infot uuesti (oli üsna levinud tehnika varasemates andmeplatvormides).
Andmete juhina peate teadma, et erinevat tüüpi skaleerimine nõuab erinevat arhitektuuri, infrastruktuuri, võrgutopoloogiat ning oskusi ja teadmisi. Ühelt tüübilt teisele üleminek on omaette väljakutse. Ärge pidage seda „lihtsaks uuenduseks“, see on täiesti uus mõtteviis, mille taga on uued põhimõtted, tööriistad ja tehnoloogiad. Orkestreerimine muutub olulisemaks kui kunagi varem. Jälgitavus läheb keerukamaks ja seda tuleb hoolikalt planeerida. Kui teie eelarve pole piiramatu, hoidke algusest peale oma kuludel silm teravalt peal. Ärge usaldage ainult kalkulaatoreid ja müüjate lubadusi – see on alati kallim, kui plaanisite, lihtsalt süsteemi keerukuse tõttu. Algajana on teil peaaegu nullprotsendiline võimalus arvestada kõigi kuludega. Näiteks ei pruugi te alguses arvestada võrguinfrastruktuuri kulusid, sest varem oli teil vaid üks masin tarkvarapõhise tulemüüriga. Kui teie süsteemis on kümneid komponente, mis suhtlevad turvaliselt omavahel ja väljaspool platvormi piire, muutuvad võrgukulud teie arvetel garanteeritult nähtavaks.
Andmehalduse ja protsesside muutumine kasvu tingimustes
Mis puudutab teist tegurit – protsesse –, siis miks need muutuvad? Kui andmete maht kasvab, kasvab sageli ka töödeldavate andmete mitmekesisus: uus personalisüsteem vajab ühendamist, GPS-sensorid saadavad potentsiaalselt huvitavaid andmeid, mida peab töötlema jne. Alguses oli teie platvormil paartosinat tabelit ja teie kaks andmeanalüütikut tundsid neid läbi ja kõiki. Nüüd on tabeleid sadu ja keegi ei mõista enam kõiki andmeid täielikult. Nii juhtub, kui ettevõttel puudub andmehaldus (data governance).
On aeg hakata pöörama tähelepanu metaandmete haldamisele, looma organisatsioonis andmekultuuri, selgitama osakondade juhtidele, miks see on oluline ja vajalik, miks nad peavad panustama ja ressursse investeerima ning millised võivad olla tagajärjed, kui nad seda ei tee. Organisatsiooni sees on oluline tabada hetk, mil on vaja igapäevasesse töösse tuua rohkem formaalsust ja struktuuri.
Te ei saa endale lubada, et mitutosinat andmeanalüütikut-inseneri omavad teie platvormil ühesuguseid administraatoriõigusi. Te ei saa toetuda ühele kõike teadvale inimesele – süsteem muutub liiga suureks ja keerukaks, et üks tähtliige suudaks seda hallata ja hooldada. Teie meeskond peab tegema koostööd, jagama teadmisi ja vastutust, mõistma oma piire. On aeg luua juurdepääsuhalduse kontseptsioon, eraldada ülesanded, määratleda vajalikud protsessid ning investeerida plaanidesse, mis puudutavad katastroofidest taastumist ja äritegevuse järjepidevust. Ärge oodake, et teie meeskond skaleerub ilma teie juhendamise ja pingutuseta – seda lihtsalt ei juhtu. Väikesed vead ja pisemad puudused võivad eskaleeruda ning tekitada teie ettevõttele olulisi äritegevuse ja mainekujunduse kahjusid.
Teemad, millest eespool juttu oli, on väga mitmetahulised ja keerukad ning mis veelgi olulisem – väga organisatsioonispetsiifilised. Me kõik oleme oma andmekirjaoskuse teekonnal erinevates punktides, mistõttu on raske anda universaalseid nõuandeid, mis sobiksid kõigile ja kõikjal. Loodame, et selle artikliga kaetud põhitõed panevad teid mõtlema, mida saaksite oma olukorra, olemasolevate ressursside ja organisatsiooni jaoks teha. Kas teil on juba midagi arutuse all? Milleks te valmistuma hakkate ja millal? Pidage meeles, et parim aeg midagi alustada oli eile ja teine parim aeg selleks on täna.