See artikkel on minu artikli tõlge meediumil - , mis osutus üsna populaarseks ilmselt oma lihtsuse tõttu. Seetõttu otsustasin kirjutada selle vene keeles ja lisada veidi, et tavainimesele, kes pole andmespetsialist, oleks selge, mis on andmeladu (DW) ja mis on andmejärv (Data Lake) ja kuidas nad seda teevad. koos läbi saama.
Miks ma tahtsin andmejärvest kirjutada? Olen töötanud andmete ja analüütikaga üle 10 aasta ning nüüd töötan kindlasti suurandmetega Amazon Alexa AI-s Cambridge'is, mis asub Bostonis, kuigi elan Victoria osariigis Vancouveri saarel ja külastan sageli Bostonit, Seattle'i. , ja Vancouveris ja mõnikord isegi Moskvas räägin ma konverentsidel. Aeg-ajalt kirjutan ka, aga kirjutan peamiselt inglise keeles ja olen juba kirjutanud , Mul on ka vajadus jagada Põhja-Ameerika analüütikatrende ja mõnikord kirjutan sisse .
Olen alati töötanud andmeladudega ja alates 2015. aastast hakkasin tegema tihedat koostööd Amazon Web Servicesiga ning üldiselt läksin üle pilvanalüütikale (AWS, Azure, GCP). Olen jälginud analüüsilahenduste arengut alates 2007. aastast ja töötanud isegi andmelao müüja Teradata heaks ja juurutanud selle Sberbankis ning just siis ilmusid Big Data koos Hadoopiga. Kõik hakkasid rääkima, et salvestamise ajastu on möödas ja nüüd on kõik Hadoopi peal, ja siis hakati uuesti Data Lake'ist rääkima, et nüüd on andmelao lõpp kindlasti käes. Kuid õnneks (võib-olla kahjuks mõne jaoks, kes Hadoopi seadistamisega palju raha teenis), ei kadunud andmeladu kuhugi.
Selles artiklis vaatleme, mis on andmejärv. See artikkel on mõeldud inimestele, kellel on andmeladudega vähe või üldse mitte kogemusi.
Pildil on Bledi järv, see on üks mu lemmikjärvi, kuigi olin seal vaid korra, jäi see eluks ajaks meelde. Kuid me räägime teist tüüpi järvedest - andmejärvest. Võib-olla on paljud teist sellest terminist juba mitu korda kuulnud, kuid veel üks määratlus ei kahjusta kedagi.
Esiteks on siin andmejärve kõige populaarsemad määratlused:
"igat tüüpi töötlemata andmete failimälu, mis on analüüsimiseks saadaval kõigile organisatsioonis osalejatele" - Martin Fowler.
“Kui arvate, et andmemart on veepudel – puhastatud, pakendatud ja mugavaks tarbimiseks pakendatud, siis andmejärv on tohutu veehoidla oma loomulikul kujul. Kasutajad, ma saan endale vett koguda, sügavuti sukelduda, uurida. ”- James Dixon.
Nüüd teame kindlalt, et andmejärv on seotud analüütikaga, see võimaldab salvestada suuri andmeid algsel kujul ning meil on andmetele vajalik ja mugav ligipääs.
Mulle meeldib sageli asju lihtsustada, kui suudan lihtsate sõnadega seletada keerulist terminit, siis saan ise aru, kuidas see toimib ja milleks seda vaja on. Ühel päeval tuhnisin iPhone'i pildigaleriis ja mulle jõudis kohale, et see on tõeline andmejärv, tegin isegi konverentside jaoks slaidi:
Kõik on väga lihtne. Teeme telefoniga foto, foto salvestatakse telefoni ja seda saab salvestada iCloudi (pilvefailide salvestusruum). Telefon kogub ka fotode metaandmeid: mida näidatakse, geosilti, kellaaega. Tänu sellele saame oma foto leidmiseks kasutada iPhone'i kasutajasõbralikku liidest ja näeme isegi indikaatoreid, näiteks kui otsin fotosid sõnaga tuli, leian 3 fotot tulekahju kujutisega. Minu jaoks on see just nagu Business Intelligence tööriist, mis töötab väga kiiresti ja selgelt.
Ja loomulikult ei tohi me unustada turvalisust (autoriseerimine ja autentimine), vastasel juhul võivad meie andmed kergesti avalikku omandisse sattuda. Palju on uudiseid suurkorporatsioonide ja idufirmade kohta, mille andmed said avalikult kättesaadavaks arendajate hooletuse ja lihtsate reeglite eiramise tõttu.
Isegi nii lihtne pilt aitab meil ette kujutada, mis on andmejärv, selle erinevusi traditsioonilisest andmelaost ja selle põhielementidest:
- Andmete laadimine (Neelamine) on andmejärve põhikomponent. Andmeid saab andmelattu sisestada kahel viisil – partii (intervallide tagant laadimine) ja voogedastus (andmevoog).
- Failide salvestamine (Salvestus) on Data Lake'i põhikomponent. Meil oli vaja, et salvestusruum oleks kergesti skaleeritav, äärmiselt töökindel ja odav. Näiteks AWS-is on see S3.
- Kataloog ja otsing (Kataloog ja otsing) - selleks, et saaksime vältida andmelohu (see on siis, kui me paneme kõik andmed ühte hunnikusse ja siis pole nendega võimalik töötada), peame andmete klassifitseerimiseks looma metaandmekihi et kasutajad leiaksid analüüsiks vajalikud andmed hõlpsalt üles. Lisaks saate kasutada täiendavaid otsingulahendusi, nagu ElasticSearch. Otsing aitab kasutajal kasutajasõbraliku liidese kaudu vajalikke andmeid leida.
- Töötlemine (Protsess) - see samm vastutab andmete töötlemise ja teisendamise eest. Saame andmeid teisendada, nende struktuuri muuta, puhastada ja palju muud.
- turvalisus (Turvalisus) – Oluline on kulutada aega lahenduse turbekujundusele. Näiteks andmete krüpteerimine salvestamise, töötlemise ja laadimise ajal. Oluline on kasutada autentimis- ja autoriseerimismeetodeid. Lõpuks on vaja auditeerimisvahendit.
Praktilisest vaatenurgast saame andmejärve iseloomustada kolme atribuudiga:
- Koguge ja hoidke kõike — andmejärv sisaldab kõiki andmeid, nii töötlemata töötlemata andmeid mis tahes ajavahemiku kohta kui ka töödeldud/puhastatud andmeid.
- Sügav skaneerimine — andmejärv võimaldab kasutajatel andmeid uurida ja analüüsida.
- Paindlik juurdepääs — Andmejärv pakub paindlikku juurdepääsu erinevatele andmetele ja erinevatele stsenaariumidele.
Nüüd saame rääkida andmelao ja andmejärve erinevusest. Tavaliselt küsivad inimesed:
- Aga andmehoidla?
- Kas asendame andmelao andmejärvega või laiendame seda?
- Kas ilma andmejärveta saab ikka hakkama?
Ühesõnaga, selget vastust pole. Kõik oleneb konkreetsest olukorrast, meeskonna oskustest ja eelarvest. Näiteks andmelao migreerimine Oracle'i AWS-i ja andmejärve loomine Amazoni tütarettevõtte Wooti poolt. .
Teisest küljest ütleb müüja Snowflake, et enam ei pea andmejärvele mõtlema, kuna nende andmeplatvorm (kuni 2020. aastani oli see andmeladu) võimaldab kombineerida nii andmejärve kui ka andmeladu. Ma ei ole Snowflake'iga palju töötanud ja see on tõeliselt ainulaadne toode, mis suudab seda teha. Emissiooni hind on teine teema.
Kokkuvõtteks võib öelda, et minu isiklik arvamus on, et meil on aruandluse peamiseks andmeallikaks siiski vaja andmeladu ja kõik, mis ei sobi, salvestame andmejärve. Analüütika kogu roll on pakkuda ettevõtetele lihtsat juurdepääsu otsuste tegemiseks. Mida iganes võib öelda, ärikasutajad töötavad andmelaoga tõhusamalt kui andmejärvega, näiteks Amazonis – seal on Redshift (analüütiline andmeladu) ja Redshift Spectrum/Athena (SQL liides S3 andmejärve jaoks, mis põhineb Taru/Presto). Sama kehtib ka teiste kaasaegsete analüütiliste andmeladude kohta.
Vaatame tüüpilist andmelao arhitektuuri:
See on klassikaline lahendus. Meil on lähtesüsteemid, ETL/ELT abil kopeerime andmed analüütilisse andmelattu ja ühendame need Business Intelligence’i lahendusega (minu lemmik on Tableau, aga sinu oma?).
Sellel lahendusel on järgmised puudused:
- ETL/ELT toimingud nõuavad aega ja ressursse.
- Reeglina pole analüütilises andmelaos andmete salvestamiseks mõeldud mälu odav (näiteks Redshift, BigQuery, Teradata), kuna peame ostma terve klastri.
- Ärikasutajatel on juurdepääs puhastatud ja sageli koondatud andmetele ning neil puudub juurdepääs algandmetele.
Muidugi oleneb kõik teie juhtumist. Kui sul pole andmelaoga probleeme, siis pole andmejärve üldse vaja. Kui aga tekib probleeme ruumipuudusega, võimsusega või võtmerolli mängib hind, võite kaaluda andmejärve võimalust. Seetõttu on andmejärv väga populaarne. Siin on näide andmejärve arhitektuurist:
Andmejärve lähenemisviisi kasutades laadime algandmed oma andmejärve (partii või voogedastus), seejärel töötleme andmeid vastavalt vajadusele. Andmejärv võimaldab ärikasutajatel luua oma andmete teisendusi (ETL/ELT) või analüüsida andmeid Business Intelligence'i lahendustes (kui vajalik draiver on olemas).
Iga analüütikalahenduse eesmärk on teenindada ärikasutajaid. Seetõttu peame alati töötama vastavalt ärinõuetele. (Amazonis on see üks põhimõtetest – tagurpidi töötamine).
Töötades nii andmelao kui ka andmejärvega, saame võrrelda mõlemat lahendust:
Peamine järeldus, mille võib teha, on see, et andmeladu ei konkureeri andmejärvega, vaid pigem täiendab seda. Kuid teie otsustate, mis teie juhtumi jaoks sobib. Alati on huvitav seda ise proovida ja õigeid järeldusi teha.
Räägin teile ka ühest juhtumist, mil ma andmejärve lähenemist kasutama hakkasin. Kõik on üsna triviaalne, proovisin kasutada ELT tööriista (meil oli Matillion ETL) ja Amazon Redshiftit, minu lahendus töötas, aga ei vastanud nõuetele.
Mul oli vaja võtta veebilogid, need teisendada ja koondada, et saada andmeid kahel juhul:
- Turundusmeeskond soovis analüüsida robotite tegevust SEO jaoks
- IT soovis vaadata veebisaidi toimivusmõõdikuid
Väga lihtsad, väga lihtsad palgid. 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" "-" "-"Üks fail kaalus 1-4 megabaiti.
Kuid oli üks raskus. Meil oli 7 domeeni üle maailma ja ühe päevaga loodi 7000 tuhat faili. See pole palju suurem maht, vaid 50 gigabaiti. Kuid ka meie punanihke klastri suurus oli väike (4 sõlme). Ühe faili laadimine traditsioonilisel viisil võttis aega umbes minuti. See tähendab, et probleem ei lahenenud otsekohe. Ja see juhtus siis, kui otsustasin kasutada andmejärve meetodit. Lahendus nägi välja umbes selline:
See on üsna lihtne (tahan märkida, et pilves töötamise eeliseks on lihtsus). Ma kasutasin:
- AWS-i elastne kaardi vähendamine (Hadoop) arvutusvõimsuse jaoks
- AWS S3 failide salvestusruumina, mis võimaldab andmeid krüptida ja piirata juurdepääsu
- Spark kui InMemory arvutusvõimsus ja PySpark loogika ja andmete teisendamiseks
- Parkett Sparki tulemusena
- AWS Glue Crawler uute andmete ja partitsioonide metaandmete kogujana
- Redshift Spectrum SQL-i liidesena andmejärvele olemasolevatele Redshifti kasutajatele
Väikseim EMR+Sparki klaster töötles kogu failide virna 30 minutiga. AWS-i puhul on ka teisi juhtumeid, eriti palju Alexaga seotud juhtumeid, kus on palju andmeid.
Just hiljuti sain teada, et andmejärve üks puudusi on GDPR. Probleem on selles, et kui klient palub need kustutada ja andmed on ühes failis, siis me ei saa kasutada andmemanipulatsiooni keelt ja DELETE operatsiooni nagu andmebaasis.
Loodan, et see artikkel selgitas andmelao ja andmejärve erinevust. Kui olete huvitatud, võin tõlkida rohkem oma artikleid või professionaalide artikleid, mida lugesin. Ja räägin ka lahendustest, millega töötan, ja nende arhitektuurist.
Allikas: www.habr.com