Å is raksts ir tulkojums manam rakstam par mediju - , kas izrÄdÄ«jÄs diezgan populÄrs, iespÄjams, vienkÄrŔības dÄļ. TÄpÄc nolÄmu uzrakstÄ«t krieviski un nedaudz papildinÄt, lai parastam cilvÄkam, kurÅ” nav datu speciÄlists, bÅ«tu skaidrs, kas ir datu noliktava (DW) un kas ir datu ezers (Datu ezers), un kÄ viÅi to dara. sanÄk kopÄ.
KÄpÄc es gribÄju rakstÄ«t par datu ezeru? Es strÄdÄju ar datiem un analÄ«zi vairÄk nekÄ 10 gadus, un tagad es noteikti strÄdÄju ar lielajiem datiem Amazon Alexa AI KembridžÄ, kas atrodas BostonÄ, lai gan es dzÄ«voju ViktorijÄ VankÅ«veras salÄ un bieži apmeklÄju Bostonu, Sietlu. , un VankÅ«verÄ un dažreiz pat MaskavÄ es uzstÄjos konferencÄs. Es arÄ« rakstu ik pa laikam, bet rakstu galvenokÄrt angliski, un esmu jau rakstÄ«jis , man arÄ« ir jÄdalÄs ar analÄ«tikas tendencÄm no Ziemeļamerikas, un es dažreiz rakstu .
Es vienmÄr esmu strÄdÄjis ar datu noliktavÄm, un kopÅ” 2015. gada sÄku cieÅ”i sadarboties ar Amazon Web Services un parasti pÄrgÄju uz mÄkoÅa analÄ«zi (AWS, Azure, GCP). Esmu novÄrojis analÄ«tikas risinÄjumu attÄ«stÄ«bu kopÅ” 2007. gada un pat strÄdÄjis datu noliktavas pÄrdevÄjÄ Teradata un ieviesis to Sberbank, un tieÅ”i tad parÄdÄ«jÄs Big Data ar Hadoop. Visi sÄka runÄt, ka krÄtuves laikmets ir pagÄjis un tagad viss ir Hadoop, un tad viÅi atkal sÄka runÄt par Data Lake, ka tagad noteikti ir pienÄcis datu noliktavas beigas. Bet par laimi (varbÅ«t diemžÄl dažiem, kuri nopelnÄ«ja daudz naudas, izveidojot Hadoop), datu noliktava nepazuda.
Å ajÄ rakstÄ mÄs apskatÄ«sim, kas ir datu ezers. Å is raksts ir paredzÄts cilvÄkiem, kuriem ir maz vai nav nekÄdas pieredzes ar datu noliktavÄm.
BildÄ ir Bledas ezers, Å”is ir viens no maniem mīļÄkajiem ezeriem, lai gan biju tur tikai vienu reizi, atcerÄjos visu mūžu. Bet mÄs runÄsim par cita veida ezeru - datu ezeru. VarbÅ«t daudzi no jums jau ir dzirdÄjuÅ”i par Å”o terminu vairÄk nekÄ vienu reizi, taÄu vÄl viena definÄ«cija nevienam nekaitÄs.
PirmkÄrt, Å”eit ir vispopulÄrÄkÄs datu ezera definÄ«cijas:
"Visu veidu neapstrÄdÄtu datu failu krÄtuve, kas ir pieejama analÄ«zei ikvienam organizÄcijÄ" - Martin Fowler.
āJa jÅ«s domÄjat, ka datu centrs ir Å«dens pudele - attÄ«rÄ«ta, iepakots un iepakots Ärtam patÄriÅam, tad datu ezers ir milzÄ«gs Å«dens rezervuÄrs tÄ dabiskajÄ formÄ. LietotÄji, es varu savÄkt Å«deni sev, nirt dziļumÄ, izpÄtÄ«t.ā - Džeimss Diksons.
Tagad mÄs noteikti zinÄm, ka datu ezers ir saistÄ«ts ar analÄ«zi, tas ļauj mums uzglabÄt lielu datu apjomu sÄkotnÄjÄ formÄ un mums ir nepiecieÅ”amÄ un Ärta piekļuve datiem.
Man bieži patÄ«k lietas vienkÄrÅ”ot, ja es varu izskaidrot sarežģītu terminu vienkÄrÅ”iem vÄrdiem, tad es pats saprotu, kÄ tas darbojas un kam tas ir vajadzÄ«gs. KÄdu dienu pabiju pa iPhone fotogaleriju, un man uznÄca, ka Å”is ir Ä«sts datu ezers, es pat uztaisÄ«ju slaidu konferencÄm:
Viss ir ļoti vienkÄrÅ”i. FotografÄjam telefonÄ, fotogrÄfija tiek saglabÄta telefonÄ un var tikt saglabÄta iCloud (mÄkoÅa failu krÄtuvÄ). TÄlrunis apkopo arÄ« fotoattÄlu metadatus: parÄdÄ«to, Ä£eogrÄfisko atzÄ«mi, laiku. RezultÄtÄ mÄs varam izmantot iPhone lietotÄjam draudzÄ«go interfeisu, lai atrastu savu fotoattÄlu un mÄs pat redzam indikatorus, piemÄram, kad es meklÄju fotogrÄfijas ar vÄrdu uguns, es atrodu 3 fotoattÄlus ar ugunsgrÄka attÄlu. Man tas ir gluži kÄ biznesa informÄcijas rÄ«ks, kas darbojas ļoti Ätri un skaidri.
Un, protams, mÄs nedrÄ«kstam aizmirst par droŔību (autorizÄciju un autentifikÄciju), pretÄjÄ gadÄ«jumÄ mÅ«su dati var viegli nonÄkt publiskajÄ domÄnÄ. Ir daudz ziÅu par lielÄm korporÄcijÄm un jaunuzÅÄmumiem, kuru dati kļuva publiski pieejami izstrÄdÄtÄju nolaidÄ«bas un vienkÄrÅ”u noteikumu neievÄroÅ”anas dÄļ.
Pat Å”Äds vienkÄrÅ”s attÄls palÄ«dz mums iedomÄties, kas ir datu ezers, tÄ atŔķirÄ«bas no tradicionÄlÄs datu noliktavas un tÄ galvenie elementi:
- Notiek datu ielÄde (NorÄ«Å”ana) ir galvenÄ datu ezera sastÄvdaļa. Datus var ievadÄ«t datu noliktavÄ divos veidos ā pakeÅ”u (ielÄdÄjot ar intervÄliem) un straumÄÅ”anas (datu plÅ«sma).
- Failu glabÄÅ”ana (Storage) ir datu ezera galvenÄ sastÄvdaļa. Mums vajadzÄja, lai krÄtuve bÅ«tu viegli mÄrogojama, ÄrkÄrtÄ«gi uzticama un zemas izmaksas. PiemÄram, AWS tas ir S3.
- Katalogs un meklÄÅ”ana (Katalogs un MeklÄÅ”ana) - lai mÄs izvairÄ«tos no datu purva (tas ir tad, kad mÄs izmetam visus datus vienÄ kaudzÄ, un tad ar tiem nav iespÄjams strÄdÄt), mums ir jÄizveido metadatu slÄnis, lai klasificÄtu datus lai lietotÄji varÄtu viegli atrast analÄ«zei nepiecieÅ”amos datus. TurklÄt varat izmantot papildu meklÄÅ”anas risinÄjumus, piemÄram, ElasticSearch. MeklÄÅ”ana palÄ«dz lietotÄjam atrast nepiecieÅ”amos datus, izmantojot lietotÄjam draudzÄ«gu saskarni.
- PÄrstrÄdes (Process) - Å”is solis ir atbildÄ«gs par datu apstrÄdi un pÄrveidoÅ”anu. MÄs varam pÄrveidot datus, mainÄ«t to struktÅ«ru, notÄ«rÄ«t tos un daudz ko citu.
- DroŔība (DroŔība) ā ir svarÄ«gi veltÄ«t laiku risinÄjuma droŔības dizainam. PiemÄram, datu Å”ifrÄÅ”ana uzglabÄÅ”anas, apstrÄdes un ielÄdes laikÄ. Ir svarÄ«gi izmantot autentifikÄcijas un autorizÄcijas metodes. Visbeidzot, ir nepiecieÅ”ams revÄ«zijas rÄ«ks.
No praktiskÄ viedokļa datu ezeru varam raksturot ar trim atribÅ«tiem:
- SavÄc un uzglabÄ jebko ā datu ezers satur visus datus, gan neapstrÄdÄtos neapstrÄdÄtos datus par jebkuru laika periodu, gan apstrÄdÄtos/notÄ«rÄ«tos datus.
- DziÄ¼Ä skenÄÅ”ana ā datu ezers ļauj lietotÄjiem izpÄtÄ«t un analizÄt datus.
- ElastÄ«ga piekļuve ā Datu ezers nodroÅ”ina elastÄ«gu piekļuvi dažÄdiem datiem un dažÄdiem scenÄrijiem.
Tagad mÄs varam runÄt par atŔķirÄ«bu starp datu noliktavu un datu ezeru. Parasti cilvÄki jautÄ:
- KÄ ar datu noliktavu?
- Vai mÄs aizstÄjam datu noliktavu ar datu ezeru vai paplaÅ”inÄm to?
- Vai joprojÄm var iztikt bez datu ezera?
ÄŖsÄk sakot, skaidras atbildes nav. Viss atkarÄ«gs no konkrÄtÄs situÄcijas, komandas prasmÄm un budžeta. PiemÄram, datu noliktavas migrÄÅ”ana uz Oracle uz AWS un Amazon meitasuzÅÄmuma Woot izveidotÄ datu ezera izveide. .
No otras puses, pÄrdevÄjs Snowflake saka, ka jums vairs nav jÄdomÄ par datu ezeru, jo viÅu datu platforma (lÄ«dz 2020. gadam tÄ bija datu noliktava) ļauj apvienot gan datu ezeru, gan datu noliktavu. Es neesmu daudz strÄdÄjis ar Snowflake, un tas patieÅ”Äm ir unikÄls produkts, kas to spÄj. Emisijas cena ir cits jautÄjums.
Visbeidzot, mans personÄ«gais viedoklis ir tÄds, ka mums joprojÄm ir nepiecieÅ”ama datu noliktava kÄ galvenais datu avots mÅ«su pÄrskatu veidoÅ”anai, un visu, kas neatbilst, mÄs glabÄjam datu ezerÄ. Visa analÄ«tikas loma ir nodroÅ”inÄt uzÅÄmumiem vieglu piekļuvi lÄmumu pieÅemÅ”anai. Lai ko teiktu, biznesa lietotÄji ar datu noliktavu strÄdÄ efektÄ«vÄk nekÄ ar datu ezeru, piemÄram, Amazon - ir Redshift (analÄ«tiskÄ datu noliktava) un Redshift Spectrum/Athena (SQL saskarne datu ezeram S3, pamatojoties uz Hive/Presto). Tas pats attiecas uz citÄm mÅ«sdienu analÄ«tisko datu noliktavÄm.
Apskatīsim tipisku datu noliktavas arhitektūru:
Tas ir klasisks risinÄjums. Mums ir avota sistÄmas, izmantojot ETL/ELT, mÄs kopÄjam datus analÄ«tisko datu noliktavÄ un savienojam ar Business Intelligence risinÄjumu (mans mīļÄkais ir Tableau, kÄ ar jums?).
Å im risinÄjumam ir Å”Ädi trÅ«kumi:
- ETL/ELT operÄcijÄm nepiecieÅ”ams laiks un resursi.
- Parasti atmiÅa datu glabÄÅ”anai analÄ«tiskajÄ datu noliktavÄ nav lÄta (piemÄram, Redshift, BigQuery, Teradata), jo mums ir jÄiegÄdÄjas viss klasteris.
- Biznesa lietotÄjiem ir piekļuve iztÄ«rÄ«tiem un bieži vien apkopotiem datiem, un viÅiem nav piekļuves neapstrÄdÄtiem datiem.
Protams, tas viss ir atkarÄ«gs no jÅ«su gadÄ«juma. Ja jums nav problÄmu ar jÅ«su datu noliktavu, tad jums vispÄr nav nepiecieÅ”ams datu ezers. Bet, ja rodas problÄmas ar vietas trÅ«kumu, jaudu vai cenu spÄlÄ galveno lomu, varat apsvÄrt datu ezera iespÄju. TÄpÄc datu ezers ir ļoti populÄrs. Å eit ir datu ezera arhitektÅ«ras piemÄrs:
Izmantojot datu ezera pieeju, mÄs ielÄdÄjam neapstrÄdÄtus datus savÄ datu ezerÄ (paketÄ vai straumÄjot), pÄc tam apstrÄdÄjam datus pÄc vajadzÄ«bas. Datu ezers ļauj biznesa lietotÄjiem izveidot savas datu transformÄcijas (ETL/ELT) vai analizÄt datus Business Intelligence risinÄjumos (ja ir pieejams nepiecieÅ”amais draiveris).
Jebkura analÄ«tikas risinÄjuma mÄrÄ·is ir apkalpot biznesa lietotÄjus. TÄpÄc mums vienmÄr jÄstrÄdÄ atbilstoÅ”i biznesa prasÄ«bÄm. (AmazonÄ tas ir viens no principiem - darbs atpakaļ).
StrÄdÄjot gan ar datu noliktavu, gan datu ezeru, varam salÄ«dzinÄt abus risinÄjumus:
Galvenais secinÄjums, ko var izdarÄ«t, ir tÄds, ka datu noliktava nekonkurÄ ar datu ezeru, bet gan papildina to. Bet tas ir jÅ«su ziÅÄ, lai izlemtu, kas ir piemÄrots jÅ«su gadÄ«jumam. VienmÄr ir interesanti paÅ”iem to izmÄÄ£inÄt un izdarÄ«t pareizos secinÄjumus.
VÄlos pastÄstÄ«t arÄ« vienu no gadÄ«jumiem, kad sÄku lietot datu ezera pieeju. Viss ir diezgan triviÄls, mÄÄ£inÄju izmantot ELT rÄ«ku (mums bija Matillion ETL) un Amazon Redshift, mans risinÄjums strÄdÄja, bet neatbilst prasÄ«bÄm.
Man vajadzÄja Åemt tÄ«mekļa žurnÄlus, pÄrveidot tos un apkopot, lai sniegtu datus par diviem gadÄ«jumiem:
- MÄrketinga komanda vÄlÄjÄs analizÄt robotu darbÄ«bu SEO
- IT vÄlÄjÄs apskatÄ«t vietnes veiktspÄjas rÄdÄ«tÄjus
Ä»oti vienkÄrÅ”i, ļoti vienkÄrÅ”i baļķi. Å eit ir piemÄrs:
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" "-" "-"Viens fails svÄra 1-4 megabaitus.
Bet bija viena grÅ«tÄ«ba. Mums bija 7 domÄni visÄ pasaulÄ, un vienÄ dienÄ tika izveidoti 7000 tÅ«kstoÅ”i failu. Tas nav daudz lielÄks apjoms, tikai 50 gigabaiti. Bet arÄ« mÅ«su Redshift klastera izmÄrs bija mazs (4 mezgli). Viena faila ielÄde tradicionÄlÄ veidÄ aizÅÄma apmÄram minÅ«ti. Tas nozÄ«mÄ, ka problÄma netika atrisinÄta. Un tas bija gadÄ«jumÄ, kad es nolÄmu izmantot datu ezera pieeju. RisinÄjums izskatÄ«jÄs apmÄram Å”Ädi:
Tas ir pavisam vienkÄrÅ”i (gribu atzÄ«mÄt, ka mÄkonÄ« strÄdÄÅ”anas priekÅ”rocÄ«ba ir vienkÄrŔība). ES izmantoju:
- AWS elastÄ«gÄ kartes samazinÄÅ”ana (Hadoop) skaitļoÅ”anas jaudai
- AWS S3 kÄ failu krÄtuve ar iespÄju Å”ifrÄt datus un ierobežot piekļuvi
- Spark kÄ InMemory skaitļoÅ”anas jauda un PySpark loÄ£ikai un datu pÄrveidoÅ”anai
- Parkets Spark rezultÄtÄ
- AWS Glue Crawler kÄ metadatu savÄcÄjs par jauniem datiem un nodalÄ«jumiem
- Redshift Spectrum kÄ SQL interfeiss datu ezeram esoÅ”ajiem Redshift lietotÄjiem
MazÄkais EMR+Spark klasteris apstrÄdÄja visu failu kaudzi 30 minÅ«Å”u laikÄ. Ir arÄ« citi AWS gadÄ«jumi, Ä«paÅ”i daudzi, kas saistÄ«ti ar Alexa, kur ir daudz datu.
Nesen es uzzinÄju, ka viens no datu ezera trÅ«kumiem ir GDPR. ProblÄma ir tad, kad klients lÅ«dz to dzÄst un dati atrodas kÄdÄ no failiem, mÄs nevaram izmantot datu manipulÄcijas valodu un DELETE darbÄ«bu kÄ datu bÄzÄ.
Es ceru, ka Å”is raksts ir izskaidrojis atŔķirÄ«bu starp datu noliktavu un datu ezeru. Ja interesÄ, varu iztulkot vÄl savus vai lasÄ«tos profesionÄļu rakstus. Un arÄ« pastÄstÄ«t par risinÄjumiem, ar kuriem strÄdÄju, un to arhitektÅ«ru.
Avots: www.habr.com