Ĉi tiu artikolo estas traduko de mia artikolo pri mediumo - , kiu montriĝis sufiĉe populara, verŝajne pro sia simpleco. Tial mi decidis skribi ĝin en la rusa kaj aldoni iomete por klarigi al ordinara homo, kiu ne estas datuma specialisto, kio estas datuma stokejo (DW), kaj kio estas datuma lago (Data Lago), kaj kiel ili interkonsenti.
Kial mi volis skribi pri la datumlago? Mi laboras kun datumoj kaj analizoj dum pli ol 10 jaroj, kaj nun mi certe laboras kun grandaj datumoj ĉe Amazon Alexa AI en Kembriĝo, kiu estas en Bostono, kvankam mi loĝas en Viktorio sur Vankuvera Insulo kaj ofte vizitas Bostonon, Seatlon. , kaj En Vankuvero, kaj foje eĉ en Moskvo, mi parolas en konferencoj. Mi ankaŭ skribas de tempo al tempo, sed mi skribas ĉefe en la angla, kaj mi jam skribis , Mi ankaŭ bezonas dividi analizajn tendencojn el Nordameriko, kaj mi foje skribas .
Mi ĉiam laboris kun datumstokejoj, kaj ekde 2015 mi komencis labori proksime kun Amazon Web Services, kaj ĝenerale ŝanĝis al nuba analizo (AWS, Azure, GCP). Mi observis la evoluon de analizaj solvoj ekde 2007 kaj eĉ laboris por la datumvendisto Teradata kaj efektivigis ĝin ĉe Sberbank, kaj tiam aperis Big Data kun Hadoop. Ĉiuj komencis diri, ke la epoko de stokado pasis kaj nun ĉio estis sur Hadoop, kaj tiam ili komencis paroli pri Data Lake, denove, ke nun la fino de la datumstokejo definitive venis. Sed feliĉe (eble bedaŭrinde por iuj, kiuj gajnis multe da mono instalante Hadoop), la datumstokejo ne foriris.
En ĉi tiu artikolo ni rigardos kio estas datuma lago. Ĉi tiu artikolo estas destinita al homoj, kiuj havas malmulte aŭ neniun sperton kun datumstokejoj.
En la bildo estas la lago Bled, ĉi tiu estas unu el miaj plej ŝatataj lagoj, kvankam mi estis tie nur unufoje, mi rememoris ĝin dum mia tuta vivo. Sed ni parolos pri alia speco de lago - datuma lago. Eble multaj el vi jam aŭdis pri ĉi tiu termino pli ol unu fojon, sed unu plia difino damaĝos neniun.
Antaŭ ĉio, jen la plej popularaj difinoj de Datuma Lago:
"dosier-stokado de ĉiuj specoj de krudaj datumoj disponeblaj por analizo de iu ajn en la organizo" - Martin Fowler.
"Se vi pensas, ke datuma vendejo estas botelo da akvo - purigita, pakita kaj pakita por oportuna konsumo, tiam datuma lago estas grandega akvorezervujo en sia natura formo. Uzantoj, mi povas kolekti akvon por mi, plonĝi profunde, esplori" - James Dixon.
Nun ni scias certe, ke datuma lago temas pri analizo, ĝi permesas al ni stoki grandajn kvantojn da datumoj en sia originala formo kaj ni havas la necesan kaj oportunan aliron al la datumoj.
Mi ofte ŝatas simpligi aferojn, se mi povas klarigi kompleksan terminon per simplaj vortoj, tiam mi mem komprenas kiel ĝi funkcias kaj por kio ĝi necesas. Iun tagon, mi ĉirkaŭpaŝis en la iPhone-fotogalerio, kaj ekkomprenis min, ĉi tio estas vera datuma lago, mi eĉ faris lumbildon por konferencoj:
Ĉio estas tre simpla. Ni prenas foton per la telefono, la foto estas konservita sur la telefono kaj povas esti konservita al iCloud (nuba dosierstokado). La telefono ankaŭ kolektas foto-metadatumojn: kio estas montrita, geo-etikedo, tempo. Kiel rezulto, ni povas uzi la uzant-amika interfaco de la iPhone por trovi nian foton kaj ni eĉ vidas indikilojn, ekzemple, kiam mi serĉas fotojn kun la vorto fajro, mi trovas 3 fotojn kun bildo de fajro. Por mi, ĉi tio estas nur kiel Komerca Inteligenta ilo, kiu funkcias tre rapide kaj klare.
Kaj kompreneble, ni ne devas forgesi pri sekureco (rajtigo kaj aŭtentikigo), alie niaj datumoj povas facile finiĝi en la publika havaĵo. Estas multaj novaĵoj pri grandaj korporacioj kaj noventreprenoj, kies datumoj fariĝis publike haveblaj pro la neglektemo de programistoj kaj malsukceso sekvi simplajn regulojn.
Eĉ tia simpla bildo helpas nin imagi kio estas datumlago, ĝiaj diferencoj de tradicia datumstokejo kaj ĝiaj ĉefaj elementoj:
- Ŝarĝante Datumojn (Ingesto) estas ŝlosila komponento de la datenlago. Datumoj povas eniri la datumstokejon en du manieroj - batch (ŝarĝado je intervaloj) kaj streaming (datumfluo).
- Dosiera stokado (Stokado) estas la ĉefkomponento de la Datuma Lago. Ni bezonis, ke la stokado estu facile skalebla, ekstreme fidinda kaj malmultekosta. Ekzemple, en AWS ĝi estas S3.
- Katalogo kaj Serĉo (Katalogo kaj Serĉo) - por ke ni evitu la Datuman Marĉon (ĉi tio estas kiam ni forĵetas ĉiujn datumojn en unu amaso, kaj tiam estas neeble labori kun ĝi), ni devas krei metadatuman tavolon por klasifiki la datumojn. tiel ke uzantoj povas facile trovi la datumojn, kiujn ili bezonas por analizo. Aldone, vi povas uzi pliajn serĉsolvojn kiel ElasticSearch. Serĉo helpas la uzanton trovi la postulatajn datumojn per uzant-amika interfaco.
- Procezo (Procezo) - ĉi tiu paŝo respondecas pri prilaborado kaj transformado de datumoj. Ni povas transformi datumojn, ŝanĝi ĝian strukturon, purigi ĝin kaj multe pli.
- Sekureco (Sekureco) - Gravas pasigi tempon pri la sekureca dezajno de la solvo. Ekzemple, datuma ĉifrado dum stokado, prilaborado kaj ŝarĝo. Gravas uzi aŭtentigajn kaj rajtigajn metodojn. Fine necesas revizia ilo.
De praktika vidpunkto, ni povas karakterizi datuman lagon per tri atributoj:
- Kolektu kaj stoku ion ajn — la datuma lago enhavas ĉiujn datumojn, ambaŭ krudajn neprilaboritajn datumojn por ajna tempodaŭro kaj prilaboritajn/purigitajn datumojn.
- Profunda Skanado — datuma lago permesas al uzantoj esplori kaj analizi datumojn.
- Fleksebla aliro — La datuma lago disponigas flekseblan aliron por malsamaj datumoj kaj malsamaj scenaroj.
Nun ni povas paroli pri la diferenco inter datuma stokejo kaj datuma lago. Kutime homoj demandas:
- Kio pri la datumstokejo?
- Ĉu ni anstataŭigas la datumstokejon per datuma lago aŭ ĉu ni vastigas ĝin?
- Ĉu ankoraŭ eblas malhavi datuman lagon?
Mallonge, ne estas klara respondo. Ĉio dependas de la specifa situacio, la kapabloj de la teamo kaj la buĝeto. Ekzemple, migri datumstokejon al Oracle al AWS kaj krei datuman lagon de Amazon-filio - Woot - .
Aliflanke, vendisto Snowflake diras, ke vi ne plu bezonas pensi pri datumlago, ĉar ilia datumplatformo (ĝis 2020 ĝi estis datumstokejo) permesas vin kombini ambaŭ datumlagon kaj datumstokejon. Mi ne multe laboris kun Snowflake, kaj ĝi estas vere unika produkto kiu povas fari tion. La prezo de la afero estas alia afero.
Konklude, mia persona opinio estas, ke ni ankoraŭ bezonas datuman stokejon kiel la ĉefa fonto de datumoj por nia raportado, kaj kio ajn ne taŭgas, ni konservas en datuma lago. La tuta rolo de analizo estas provizi facilan aliron por komerco por fari decidojn. Kion ajn oni povas diri, komercaj uzantoj laboras pli efike kun datuma stokejo ol datumlago, ekzemple en Amazon - estas Redshift (analitika datumstokejo) kaj estas Redshift Spectrum/Athena (SQL-interfaco por datumlago en S3 bazita sur Hive/Presto). La sama validas por aliaj modernaj analizaj datumstokejoj.
Ni rigardu tipan arkitekturon de datum-magazeno:
Ĉi tio estas klasika solvo. Ni havas fontsistemojn, uzante ETL/ELT ni kopias datumojn en analizan datumstokejon kaj ligas ĝin al Business Intelligence-solvo (mia plej ŝatata estas Tableau, kio pri via?).
Ĉi tiu solvo havas la jenajn malavantaĝojn:
- ETL/ELT-operacioj postulas tempon kaj rimedojn.
- Kiel regulo, memoro por stoki datumojn en analiza datuma stokejo ne estas malmultekosta (ekzemple Redshift, BigQuery, Teradata), ĉar ni devas aĉeti tutan areton.
- Komercaj uzantoj havas aliron al purigitaj kaj ofte kunigitaj datumoj kaj ne havas aliron al krudaj datumoj.
Kompreneble, ĉio dependas de via kazo. Se vi ne havas problemojn kun via datumstokejo, tiam vi tute ne bezonas datuman lagon. Sed kiam problemoj aperas kun manko de spaco, potenco aŭ prezo ludas ŝlosilan rolon, tiam vi povas konsideri la opcion de datuma lago. Tial la datuma lago estas tre populara. Jen ekzemplo de arkitekturo de datuma lago:
Uzante la aliron de datuma lago, ni ŝarĝas krudajn datumojn en nian datuman lagon (loko aŭ streaming), tiam ni prilaboras la datumojn laŭbezone. La datumlago permesas al komercaj uzantoj krei siajn proprajn datumtransformojn (ETL/ELT) aŭ analizi datumojn en Business Intelligence-solvoj (se la necesa ŝoforo disponeblas).
La celo de iu ajn analiza solvo estas servi komercajn uzantojn. Tial ni devas ĉiam labori laŭ komercaj postuloj. (Ĉe Amazon tio estas unu el la principoj - labori malantaŭen).
Laborante kun kaj datuma stokejo kaj datuma lago, ni povas kompari ambaŭ solvojn:
La ĉefa konkludo, kiun oni povas tiri, estas, ke la datumstokejo ne konkuras kun la datumlago, sed prefere kompletigas ĝin. Sed dependas de vi decidi, kio taŭgas por via kazo. Ĉiam estas interese provi ĝin mem kaj tiri la ĝustajn konkludojn.
Mi ankaŭ ŝatus diri al vi unu el la kazoj, kiam mi komencis uzi la datuman lagan aliron. Ĉio estas sufiĉe bagatela, mi provis uzi ELT-ilon (ni havis Matillion ETL) kaj Amazon Redshift, mia solvo funkciis, sed ne kongruis kun la postuloj.
Mi devis preni interretajn protokolojn, transformi ilin kaj kunigi ilin por provizi datumojn por 2 kazoj:
- La merkata teamo volis analizi bot-agadon por SEO
- IT volis rigardi retejajn rendimentajn metrikojn
Tre simplaj, tre simplaj protokoloj. Jen ekzemplo:
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" "-" "-"Unu dosiero pezis 1-4 megabajtojn.
Sed estis unu malfacilaĵo. Ni havis 7 domajnojn tra la mondo, kaj 7000 50 mil dosieroj estis kreitaj en unu tago. Ĉi tio ne estas multe pli da volumo, nur 4 gigabajtoj. Sed la grandeco de nia Redshift-areto ankaŭ estis malgranda (XNUMX nodoj). Ŝargado de unu dosiero laŭ la tradicia maniero daŭris proksimume minuton. Tio estas, la problemo ne estis solvita fronte. Kaj ĉi tio estis la kazo kiam mi decidis uzi la datuman lagan aliron. La solvo aspektis kiel ĉi tio:
Ĝi estas sufiĉe simpla (mi volas rimarki, ke la avantaĝo labori en la nubo estas simpleco). Mi uzis:
- AWS Elastic Map Reduce (Hadoop) por Komputila Potenco
- AWS S3 kiel dosierstokado kun la kapablo ĉifri datumojn kaj limigi aliron
- Spark kiel InMemory komputika potenco kaj PySpark por logiko kaj datuma transformo
- Parquet kiel rezulto de Spark
- AWS Glue Crawler kiel metadatumo-kolektanto pri novaj datumoj kaj sekcioj
- Redshift Spectrum kiel SQL-interfaco al la datenlago por ekzistantaj Redshift-uzantoj
La plej malgranda EMR+Spark-areo prilaboris la tutan stakon da dosieroj en 30 minutoj. Estas aliaj kazoj por AWS, precipe multaj rilataj al Alexa, kie estas multaj datumoj.
Ĵus mi eksciis, ke unu el la malavantaĝoj de datuma lago estas GDPR. La problemo estas kiam la kliento petas forigi ĝin kaj la datumoj estas en unu el la dosieroj, ni ne povas uzi Data Manipulation Language kaj DELETE operacio kiel en datumbazo.
Mi esperas, ke ĉi tiu artikolo klarigis la diferencon inter datuma stokejo kaj datuma lago. Se vi interesiĝis, mi povas traduki pli da miaj artikoloj aŭ artikoloj de profesiuloj, kiujn mi legas. Kaj ankaŭ rakontu pri la solvoj kun kiuj mi laboras kaj ilia arkitekturo.
fonto: www.habr.com