Artikulu hau bitartekoari buruzko nire artikuluaren itzulpena da - , nahiko ezaguna izan zen, ziurrenik bere sinpletasunagatik. Hori dela eta, errusieraz idaztea erabaki nuen eta pixka bat gehitzea datu-espezialista ez den pertsona arrunt bati datu-biltegi bat (DW) zer den eta zer den datu-laku bat (Data Lake) eta nolakoa den argi uzteko. elkarrekin elkartu.
Zergatik idatzi nahi nuen data lakeari buruz? 10 urte baino gehiago daramatzat datuekin eta analitikekin lan egiten, eta orain, zalantzarik gabe, datu handiekin lan egiten ari naiz Cambridgeko Amazon Alexa AI-n, hau da, Bostonen, nahiz eta Vancouver uhartean Victorian bizi naizen eta sarritan Bostongo, Seattle-n bisitatu. , eta Vancouver-en, eta batzuetan Moskun ere, hitzaldietan hitz egiten dut. Noizean behin ere idazten dut, baina ingelesez idazten dut batez ere, eta dagoeneko idatzi dut , Ipar Amerikako analitika joerak partekatzeko beharra ere badut, eta batzuetan idazten dut .
Datu biltegiekin lan egin izan dut beti, eta 2015az geroztik Amazon Web Servicesekin lankidetza estuan hasi nintzen, eta, oro har, hodeiko analitiketara pasatu nintzen (AWS, Azure, GCP). 2007az geroztik analitika-soluzioen bilakaera ikusi dut eta Teradata datu biltegiko saltzailearentzat ere lan egin nuen eta Sberbanken inplementatu nuen, eta orduan agertu zen Big Data Hadoop-ekin. Denak esaten hasi ziren biltegiratze aroa pasatu zela eta orain dena Hadoop-en zegoela, eta gero Data Lake-ri buruz hitz egiten hasi ziren, berriro, orain datu biltegiaren amaiera behin betiko iritsi zela. Baina zorionez (agian zoritxarrez Hadoop konfiguratzeko diru asko irabazi zuten batzuentzat), datu biltegia ez zen desagertu.
Artikulu honetan datu-laku bat zer den aztertuko dugu. Artikulu hau datu biltegiekin esperientzia gutxi edo batere ez duten pertsonei zuzenduta dago.
Irudian Bled aintzira da, hau da nire lakurik gogokoenetariko bat, behin bakarrik egon nintzen arren, bizitza osorako gogoratu nintzen. Baina beste laku mota bati buruz hitz egingo dugu: datu-laku bat. Beharbada, zuetako askok behin baino gehiagotan entzun duzue jada termino honi buruz, baina definizio batek gehiago ez dio inori kalterik egingo.
Lehenik eta behin, hona hemen Data Lake baten definizio ezagunenak:
"Erakundeko edonork aztertzeko erabilgarri dagoen datu gordina mota guztietako biltegiratze fitxategia" - Martin Fowler.
"Data mart bat ur botila bat dela uste baduzu, araztua, ontziratua eta kontsumitzeko ontziratua, orduan datu-lakua ur biltegi erraldoia da bere forma naturalean. Erabiltzaileok, ura bil dezaket niretzat, sakon murgildu, arakatu" - James Dixon.
Orain ziur dakigu datu-laku bat analitikari buruzkoa dela, datu kopuru handiak bere jatorrizko forman gordetzeko aukera ematen digu eta datuetarako sarbide beharrezkoa eta erosoa dugu.
Askotan gauzak sinplifikatzea gustatzen zait, termino konplexu bat hitz sinplez azaltzeko gai bada, orduan neuk ulertzen dut nola funtzionatzen duen eta zertarako behar den. Egun batean, iPhoneko argazki galerian bueltaka nengoen, eta konturatu nintzen, hau benetako data lake bat da, hitzaldietarako diapositiba bat ere egin nuen:
Dena oso sinplea da. Telefonoan argazki bat ateratzen dugu, argazkia telefonoan gordetzen da eta iCloud-en gorde daiteke (hodeiko fitxategien biltegiratzea). Telefonoak argazki metadatuak ere biltzen ditu: zer erakusten den, geo-etiketa, ordua. Ondorioz, iPhonearen interfaze atsegina erabil dezakegu gure argazkia aurkitzeko eta adierazleak ere ikusten ditugu, adibidez, su hitzarekin argazkiak bilatzen ditudanean, suaren irudia duten 3 argazki aurkitzen ditut. Niretzat, hau oso azkar eta zehaztasunez funtzionatzen duen Business Intelligence tresna bat bezalakoa da.
Eta, jakina, ez dugu ahaztu behar segurtasunaz (baimena eta autentifikazioa), bestela gure datuak erraz hel daitezke domeinu publikoan. Garatzaileen arduragabekeriagatik eta arau sinpleak ez betetzeagatik, datu asko publikoki eskuragarri dauden korporazio eta startup handiei buruzko albiste asko daude.
Irudi sinple batek ere datu-laku bat zer den, datu-biltegi tradizional batekin dituen desberdintasunak eta bere elementu nagusiak irudikatzen laguntzen digu:
- Datuak kargatzen (Irenstea) datu-lakuaren funtsezko osagaia da. Datuak bi modutara sar daitezke datu biltegian: batch (tarteka kargatzea) eta streaming (datuen fluxua).
- Fitxategiak biltegiratzea (Biltegiratzea) Data Lake-ren osagai nagusia da. Biltegiratzea erraz eskalagarria, oso fidagarria eta kostu baxua izatea behar genuen. Adibidez, AWS-n S3 da.
- Katalogoa eta Bilaketa (Katalogoa eta Bilaketa) - Datuen zingira saihesteko (hau da datu guztiak pila batean botatzen ditugunean, eta orduan ezinezkoa da horrekin lan egitea), metadatu geruza bat sortu behar dugu datuak sailkatzeko. erabiltzaileek erraz aurki ditzaten datuak aztertzeko behar dituztenak. Gainera, bilaketa-soluzio osagarriak erabil ditzakezu, hala nola ElasticSearch. Bilaketak erabiltzaileari beharrezko datuak aurkitzen laguntzen dio interfaze atsegin baten bidez.
- Prozesatzeko (Prozesua) - urrats hau datuak prozesatzeaz eta eraldatzeaz arduratzen da. Datuak eraldatu, egitura alda ditzakegu, garbitu eta askoz gehiago.
- ΠΠ΅Π·ΠΎΠΏΠ°ΡΠ½ΠΎΡΡΡ (Segurtasuna) - Garrantzitsua da irtenbidearen segurtasun diseinuan denbora ematea. Esaterako, datuen enkriptatzea biltegiratzean, prozesatzen eta kargatzean. Garrantzitsua da autentifikazio- eta baimen-metodoak erabiltzea. Azkenik, auditoretza tresna bat behar da.
Ikuspuntu praktikotik, datu-laku bat hiru atributuren arabera ezaugarritu dezakegu:
- Bildu eta gorde edozer gauza β Data Lake-k datu guztiak ditu, bai edozein denbora-tarterako prozesatu gabeko datu gordinak bai prozesatutako/garbitutako datuak.
- Eskaneatu sakona β data lake batek erabiltzaileei datuak arakatu eta aztertzeko aukera ematen die.
- Sarbide malgua β Data Lake-ak datu eta eszenatoki ezberdinetarako sarbide malgua eskaintzen du.
Orain datu biltegi baten eta data lake baten arteko ezberdintasunaz hitz egin dezakegu. Normalean jendeak galdetzen du:
- Zer gertatzen da datu biltegiarekin?
- Datu biltegia datu-laku batekin ordezkatzen ari gara ala zabaltzen ari gara?
- Oraindik posible al da data lakerik gabe egitea?
Laburbilduz, ez dago erantzun argirik. Egoera zehatzaren, taldearen gaitasunen eta aurrekontuaren araberakoa da dena. Adibidez, datu biltegi bat Oraclera AWSra migratzea eta Amazon filial batek datu-laku bat sortzea - ββWoot - .
Bestalde, Snowflake saltzaileak dio jada ez duzula datu-laku batean pentsatu behar, haien datu-plataformak (2020ra arte datu biltegi bat zen) datu-laku bat eta datu-biltegi bat konbinatzeko aukera ematen baitu. Ez dut asko lan egin Snowflake-rekin, eta benetan hori egin dezakeen produktu paregabea da. Gaiaren prezioa beste kontu bat da.
Amaitzeko, nire iritzi pertsonala da oraindik datu-biltegi bat behar dugula gure txostenak egiteko datu-iturri nagusi gisa, eta kabitzen ez dena datu-laku batean gordetzen dugula. Analitikaren eginkizun osoa enpresei erabakiak hartzeko sarbide erraza eskaintzea da. Zer esanik ez, negozio-erabiltzaileek datu-biltegi batekin datu-laku batekin baino eraginkorrago lan egiten dute, adibidez Amazonen - Redshift dago (datu-biltegi analitikoa) eta Redshift Spectrum/Athena (SQL interfazea S3-n oinarritutako datu-laku baterako). Hive/Presto). Gauza bera gertatzen da beste datu analitikoen biltegi modernoekin.
Ikus dezagun datu biltegiaren arkitektura tipiko bat:
Hau irtenbide klasikoa da. Iturburu-sistemak ditugu, ETL/ELT erabiliz datuak datu analitikoen biltegi batean kopiatzen ditugu eta Business Intelligence soluzio batera konektatzen ditugu (nire gogokoena Tableau da, eta zurea?).
Irtenbide honek desabantaila hauek ditu:
- ETL/ELT operazioek denbora eta baliabideak behar dituzte.
- Oro har, datu analitikoen biltegi batean datuak gordetzeko memoria ez da merkea (adibidez, Redshift, BigQuery, Teradata), cluster oso bat erosi behar baitugu.
- Enpresen erabiltzaileek garbitutako eta askotan agregatutako datuetarako sarbidea dute eta ez dute datu gordinak eskuratzeko.
Noski, dena zure kasuaren araberakoa da. Datu-biltegiarekin arazorik ez baduzu, ez duzu datu-lakurik behar. Baina espazio, potentzia edo prezio faltarekin arazoak sortzen direnean funtsezko papera betetzen dutenean, datu-laku baten aukera kontuan hartu dezakezu. Horregatik oso ezaguna da data lakea. Hona hemen datu-lakuaren arkitektura baten adibide bat:
Datu-lakuaren ikuspegia erabiliz, datu gordinak gure datu-lakuan kargatzen ditugu (batch edo streaming), ondoren datuak behar bezala prozesatzen ditugu. Datu-lakuak negozio-erabiltzaileei beren datu-eraldaketak (ETL/ELT) sortzeko edo Business Intelligence soluzioetan datuak aztertzeko aukera ematen die (beharrezko kontrolatzailea eskuragarri badago).
Edozein analisi-soluzioren helburua negozio-erabiltzaileei zerbitzatzea da. Horregatik, beti egin behar dugu lan negozioaren eskakizunen arabera. (Amazonen hau printzipioetako bat da: atzerantz lan egitea).
Datu biltegiarekin eta datu-laku batekin lan eginez, bi irtenbideak aldera ditzakegu:
Atera daitekeen ondorio nagusia da data warehouse ez dela data lakearekin lehiatzen, hura osatzen baizik. Baina zure esku dago zure kasurako zer den erabakitzea. Beti da interesgarria zuk zeuk probatzea eta ondorio egokiak ateratzea.
Data lake ikuspegia erabiltzen hasi nintzeneko kasuetako bat ere kontatu nahiko nuke. Dena nahiko hutsala da, ELT tresna bat erabiltzen saiatu nintzen (Matilion ETL genuen) eta Amazon Redshift, nire irtenbideak funtzionatu zuen, baina ez zituen baldintzak betetzen.
Web erregistroak hartu, eraldatu eta batu behar nituen 2 kasuetarako datuak emateko:
- Marketing taldeak SEOrako bot jarduera aztertu nahi zuen
- IT webgunearen errendimenduaren neurketak aztertu nahi zituen
Erregistro oso sinpleak, oso sinpleak. Hona hemen adibide bat:
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" "-" "-"Fitxategi batek 1-4 megabyte pisatzen zuen.
Baina bazegoen zailtasun bat. Mundu osoan 7 domeinu genituen, eta 7000 mila fitxategi sortu ziren egun batean. Hau ez da bolumen askoz gehiago, 50 gigabyte baino ez. Baina gure Redshift klusterraren tamaina ere txikia zen (4 nodo). Fitxategi bat modu tradizionalean kargatzeak minutu bat inguru behar izan zuen. Hau da, arazoa ez zen aurrez aurre konpondu. Eta hori gertatu zen data lake ikuspegia erabiltzea erabaki nuenean. Irtenbideak honelako itxura zuen:
Nahiko sinplea da (kontuan izan nahi dut hodeian lan egitearen abantaila sinpletasuna dela). Nik erabili nuen:
- AWS Elastic Map Reduce (Hadoop) Konputazio Potentziarako
- AWS S3 fitxategien biltegiratze gisa, datuak enkriptatzeko eta sarbidea mugatzeko gaitasunarekin
- Spark InMemory informatika ahalmen gisa eta PySpark logika eta datuen eraldaketarako
- Spark-en ondorioz parketea
- AWS Glue Crawler datu eta partizio berriei buruzko metadatu-biltzaile gisa
- Redshift Spectrum lehendik dauden Redshift erabiltzaileentzako datu-lakurako SQL interfaze gisa
EMR+Spark kluster txikienak fitxategi pila osoa prozesatu zuen 30 minututan. Badaude beste kasu batzuk AWSrentzat, batez ere Alexa-rekin lotutako asko, non datu asko dauden.
Duela gutxi jakin nuen datu-laku baten desabantaila bat GDPR dela. Arazoa da bezeroak ezabatzeko eskatzen duenean eta datuak fitxategietako batean daudenean, ezin ditugu Datu Manipulazio Lengoaia eta DELETE eragiketa erabili datu-base batean bezala.
Artikulu honek datu biltegi baten eta data lake baten arteko aldea argitu izana espero dut. Interesatzen bazaizu, nire artikulu edo irakurtzen ditudan profesionalen artikulu gehiago itzul ditzaket. Eta lan egiten ditudan irtenbideak eta haien arkitektura ere kontatu.
Iturria: www.habr.com