Kas me vajame andmejärve? Kuidas andmesalvestusega edasi minna?

See artikkel on minu medium'i artikli tõlge — Andmejärvega tutvumise juhend, mis osutus üsna populaarseks, tõenäoliselt oma lihtsuse tõttu. Seetõttu otsustasin selle kirjutada eesti keeles ja veidi täiendada, et tavaline inimene, kes ei ole andmetöötluse spetsialist, mõistaks, mis on andmehoidla (DW) ja mis on andmejärv (Data Lake), ning kuidas need koos eksisteerivad.

Miks ma tahtsin andmejärve kohta kirjutada? Olen töötanud andmete ja analüütikaga üle 10 aasta ning praegu töötan kindlasti suurte andmete kallal Amazon Alexa AI-s Cambridge'is, mis asub Bostoni lähedal, kuigi elan ise Vancouveri saarel Victorias ja käin sageli nii Bostonis, Seattle'is kui ka Vancouveris, ning mõnikord isegi Moskvas konverentsidel esinemas. Samuti kirjutan aeg-ajalt, kuid peamiselt inglise keeles, ja olen juba kirjutanud mitmeid raamatuid, mul on samuti soov jagada Põhja-Ameerika analüütika trende ning kirjutan mõnikord Telegramis.

Olen alati töötanud andmehoidlate kallal ja alates 2015. aastast olen intensiivselt töötanud Amazon Web Servicesiga, üldiselt olen üle läinud pilveanalüütikale (AWS, Azure, GCP). Olen jälginud analüütikalahenduste evolutsiooni alates 2007. aastast ning olen isegi töötanud andmehoidla tootemüügis Teradata, rakendades seda Sberbankis, just siis ilmuski Big Data koos Hadoopiga. Kõik hakkasid rääkima, et andmehoidlate ajastu on möödas ja nüüd on kõik Hadoopis, ning hiljem hakati rääkima Data Lake'ist, jälle väideti, et nüüd on andmehoidla tõeliselt lõppenud. Kuid õnneks (võib-olla mõne jaoks ka kahjuks, kes teenis palju raha Hadoopi seadistamise eest) pole andmehoidlad kadunud.

Selles artiklis vaatleme, mis on andmejärv. Artikkel on mõeldud inimestele, kellel on andmehoidlate osas vähe või üldse mitte kogemusi.

Pildil on Bledi järv, see on üks mu lemmikjärvi, kuigi olen seal käinud vaid korra, kuid mäletan seda kogu elu. Kuid me räägime teisest järve tüübist — andmejärvest. Võib-olla olete paljusid neist juba korduvalt kuulnud, kuid veel üks määratlus ei tee kellelegi halba.

Esiteks on siin kõige populaarsemad määratlused Andmejärve kohta:

«failihoidla kõikidest tüüpidest tooredate andmete, mis on kergesti analüüsitavad organisatsioonis kellegi poolt» — Martin Fowler.

«Kui te arvate, et andmevaade on veepudel — puhastatud, pakendatud ja mugavaks tarbimiseks valmis, siis andmejärv on tohutu reservuaar veega selle looduslikus vormis. Kasutajad saavad endale vett võtta, sügavale sukelduda ja uurida» — James Dickson.

Nüüd teame kindlasti, et andmejärv on seotud analüütikaga, see võimaldab meil salvestada suuri andmemahtusid nende algses vormis ja meil on vajalik ja mugav juurdepääs andmetele.

Mulle meeldib sageli asju lihtsaks teha, kui ma saan keerulise termini lihtsate sõnadega selgitada, siis olen ma endale selgeks teinud, kuidas see töötab ja miks see vajalik on. Üks kord, kui ma kaevusin iPhone'i fotogaleriisse, tuli mulle mõte, et see on tõeline andmejärv, isegi tegin slaidi konverentside jaoks:

Kõik on väga lihtne. Teeme telefoniga foto, foto salvestatakse telefoni ja võib olla salvestatud ka iCloudi (pilvesalvestusteenus). Samuti kogub telefon foto metandmeid: mis on pildil, geotag, aeg. Tulemuseks on see, et saame kasutada mugavat iPhone'i liidest, et leida oma foto ja näeme isegi statistikat, näiteks kui ma otsin fotosid sõnaga tuli (fire), siis leian 3 fotot lõkketule pildist. Minu jaoks on see justkui Business Intelligence tööriist, mis töötab väga kiiresti ja täpselt.

Ja muidugi ei tohi me unustada turvalisust (autentimine ja autoriseerimine), vastasel juhul võivad meie andmed kergesti avalikuks saada. On palju uudiseid suurettevõtetest ja idufirmadest, kelle andmed on ametlikult avalikuks saanud arendajate hooletuse ja lihtsate reeglite eiramise tõttu.

Isegi selline lihtne pilt aitab meil mõista, mis on andmejärv, selle erinevused traditsioonilisest andmehoidlast ja selle põhielemendid:

1. Andmete laadimine (Ingestion) — andmejärve peamine komponent. Andmed võivad jõuda andmehoidlasse kahel viisil — batch (vahetustega laadimine) ja streaming (andmevoog).
2. Failide salvestus (Storage) — andmejärve peamine komponent. Me vajame, et hoidlal oleks lihtne skaleeritavus, erakordselt usaldusväärsus ja madal hind. Näiteks AWS-is on see S3.
3. Kataloog ja Otsing (Kataloog ja Otsing) — et vältida Meediate Pange (see on siis, kui me viskame kõik andmed ühte kuhja ja hiljem on nendega võimatu töötada), peame looma metaandmete kihi andmete klassifitseerimiseks, et kasutajad saaksid kergesti leida neid andmeid, mida nad vajavad analüüsimiseks. Täiendavalt võime kasutada lisalahendusi otsimiseks, näiteks ElasticSearch. Otsing aitab kasutajal otsida vajalikke andmeid mugavate liideste kaudu.
4. Töötlemine (Protsess) — see samm vastutab andmete töötlemise ja transformatsiooni eest. Me saame andmeid transformeerida, nende struktuure muuta, puhastada ja palju muud.
5. Turvalisus (Turvalisus) — on oluline kulutada aega lahenduse turvalisuse kujundamisele. Näiteks andmete krüptimine nende säilitamise, töötlemise ja laadimise ajal. On oluline kasutada autentimise ja autoriseerimise meetodeid. Kokkuvõtteks on vajalik audititööriist.

Praktilisest vaatenurgast võime iseloomustada andmejärve kolme atribuudiga:

1. Koguge ja hoidke kõike — andmejärv sisaldab kõiki andmeid, nii tooreid töötlemata andmeid mis tahes ajavahemiku jooksul kui ka töödeldud/puhastatud andmeid.
2. Sügav analüüs — andmejärv võimaldab kasutajatel andmeid uurida ja analüüsida.
3. Paindlik ligipääs — andmejärv tagab paindliku ligipääsu erinevatele andmetele ja erinevatele stsenaariumidele.

Nüüd saame rääkida andmehoidla ja andmejärve erinevustest. Inimesed küsivad sageli:

• Aga kuidas on andmehoidla olukord?
• Kas me asendame andmehoidla andmejärvega või laiendame seda?
• Kas on võimalik siiski ilma andmejärve hakkama saada?

Lühidalt, selget vastust ei ole. Kõik sõltub konkreetsest olukorrast, meeskonna oskustest ja eelarvest. Näiteks andmehoidla migreerimine Oracle'ist AWS-sse ja andmejärve loomine Amazon'i tütarettevõtte Woot kaudu — Meie andmejärve lugu: Kuidas Woot.com ehitas serverivaba andmejärve AWS-is.

Teiselt poolt, Snowflake väidab, et teie ei pea enam andmejärve pärast muretsema, kuna nende andmeplatvorm (kuni 2020, kui see oli andmehoidla) võimaldab teil liita nii andmejärve kui ka andmehoidla. Olen Snowflake'iga natuke töötanud ja see on tõeliselt ainulaadne toode, mis suudab seda teha. Hinna küsimus on juba teine teema.

Kokkuvõttes on minu isiklik arvamus, et meil on endiselt vaja andmehoidlat kui meie aruandluse peamist andmeallikat ning kõik, mis sinna ei mahu, salvestame andmejärve. Analüütika roll on pakkuda ettevõttele mugavat juurdepääsu otsuste tegemiseks. Ükskõik kuidas võtta, töötavad äri kasutajad andmehoidlaga tõhusamalt kui andmejärvega; näiteks Amazonis on olemas Redshift (analüütiline andmehoidla) ja Redshift Spectrum/Athena (SQL liides andmejärvele S3-s, mis põhineb Hive/Presto). Sama kehtib ka teiste kaasaegsete analüütiliste andmehoidlate kohta.

Vaadakem tüüpilist andmehoidla arhitektuuri:

See on klassikaline lahendus. Meil on allikate süsteemid, mille abil ETL/ELT kaudu kopeerime andmed analüütilisse andmehoidlasse ja ühendame need Business Intelligence lahendusega (minu lemmik on Tableau, aga mis on teie?).

Sellisel lahendusel on järgmised puudused:

• ETL/ELT operatsioonid nõuavad aega ja ressursse.
• Reeglina ei ole andmete salvestamine analüütilises andmehoidlas odav (näiteks Redshift, BigQuery, Teradata), kuna peame ostma terve klastrite komplekti.
• Ärikasutajatel on juurdepääs puhastatud ja sageli aggregeeritud andmetele ning neil ei ole võimalust saada tooreid andmeid.

Muidugi sõltub kõik teie juhtumist. Kui teie andmehoidlas ei ole probleeme, siis ei ole teil andmejärve üldse vaja. Kuid kui tekivad probleemid koha, võimekuse või hinna eest, siis on mõttekas kaaluda andmejärve varianti. Sellepärast on andmejärv väga populaarne. Siin on näide andmejärve arhitektuurist:

Andmejärve lähenemisviisi kasutades laadime toored andmed meie andmejärve (batch või streaming) ja seejärel töötleme andmeid vastavalt vajadusele. Andmejärv võimaldab äri kasutajatel luua oma andmete transformatsioone (ETL/ELT) või analüüsida andmeid Business Intelligence lahendustes (kui on vajalik draiver).

Iga analüütilise lahenduse eesmärk on teenida äri kasutajaid. Seetõttu peame alati töötama äri nõudmistest lähtudes. (Amazonis on see üks põhimõtteid — töötama tagurpidi).

Töötades nii andmehoidla kui andmejärvega, saame võrrelda mõlemat lahendust:

Peamine järeldus, mille võib teha, on see, et andmesalvestus ei konkureeri andmejärvega, vaid täiendab seda. Kuid teil on õigus otsustada, mis sobib teie juhtumiga. Alati on huvitav ise proovida ja õiged järeldused teha.

Tahan rääkida ka ühest juhtumist, kui hakkasin kasutama andmejärve lähenemist. Kõik oli üsna banaalne, proovisin kasutada ELT tööriista (meil oli Matillion ETL) ja Amazon Redshift, minu lahendus toimis, kuid ei vastanud nõuetele.

Mul oli vaja võtta veebilogid, neid transformeerida ja agregeerida, et esitada andmed kahe juhtumi jaoks:

1. Turundusmeeskond soovis analüüsida botide tegevust SEO jaoks
2. IT soovis vaadata veebisaitide töö statistikat

Väga lihtsad, väga lihtsad logid. Siin on näide:

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

Ühe faili suurus oli 1-4 megabaiti.

Kuid oli üks raskus. Meil oli 7 domeeni üle kogu maailma, ja ühe päeva jooksul loodi 7000 faili. See pole väga suur kogus, kokku 50 gigabaiti. Kuid meie Redshifti klaster oli ka väike (4 sõlme). Traditsiooniliste meetoditega ühe faili laadimine võttis umbes minuti. See tähendab, et probleem ei lahendatud otse. See oli see juhtum, kui otsustasin kasutada andmejärve lähenemist. Lahendus nägi välja umbes nii:

See on piisavalt lihtne (tahan tähele panna, et pilveteenustes töötamise eelis on lihtsus). Kasutasin:

• AWS Elastic Map Reduce (Hadoop) kui arvutusvõimsust
• AWS S3 kui failihoidla, millel on andmete krüpteerimise ja juurdepääsu piiramise võimalused
• Spark kui InMemory arvutusvõimsus ja PySpark andmete loogika ja transformatsiooni jaoks
• Parquet kui Spark'i töö tulemus
• AWS Glue Crawler kui uute andmete ja partiide metaandmete kogum
• Redshift Spectrum kui SQL liides andmejärvele olemasolevatele Redshift kasutajatele

Kõige väiksem EMR+Spark klaster töötles kogu failipaki 30 minutiga. On ka teisi juhtumeid AWS jaoks, eriti palju, mis on seotud Alexaga, kus andmeid on väga palju.

Hiljuti sain teada ühe andmejärve puuduse — see on GDPR. Probleem on selles, et kui klient palub andmeid kustutada ja need on ühes faili, siis ei saa me kasutada Andmete Manipuleerimise Keelt ning DELETE käsku nagu andmebaasis.

Loodan, et artikkel selgitas andmehoidla ja andmejärve vahelisi erinevusi. Kui see oli huvitav, siis võin tõlkida veel oma artikleid või professionaalide artikleid, keda loen. Samuti võin rääkida lahendustest, millega töötan, ja nende arhitektuurist.

Allikas: habr.com