Ta članek je prevod mojega članka o mediju - , ki se je izkazalo za precej priljubljeno, verjetno zaradi svoje preprostosti. Zato sem se odločil, da ga napišem v ruščini in malo dodam, da bo navadnemu človeku, ki ni strokovnjak za podatke, jasno, kaj je podatkovno skladišče (DW) in kaj je podatkovno jezero (Data Lake) ter kako razumeti se skupaj.
Zakaj sem želel pisati o podatkovnem jezeru? S podatki in analitiko delam že več kot 10 let, zdaj pa zagotovo delam z velikimi podatki pri Amazon Alexa AI v Cambridgeu, ki je v Bostonu, čeprav živim v Viktoriji na otoku Vancouver in pogosto obiščem Boston, Seattle , in V Vancouvru in včasih celo v Moskvi govorim na konferencah. Občasno tudi pišem, vendar pišem predvsem v angleščini in sem že pisal , prav tako moram deliti analitične trende iz Severne Amerike in včasih pišem .
Vedno sem delal s podatkovnimi skladišči, od leta 2015 pa sem začel tesno sodelovati z Amazon Web Services in na splošno prešel na analitiko v oblaku (AWS, Azure, GCP). Razvoj analitičnih rešitev opazujem od leta 2007 in celo delam za ponudnika podatkovnih skladišč Teradata ter jih implementiram pri Sberbank in takrat se je pojavil Big Data s Hadoopom. Vsi so začeli govoriti, da je doba shranjevanja minila in je zdaj vse na Hadoopu, potem pa so spet začeli govoriti o Data Lakeu, da je zdaj zagotovo prišel konec podatkovnega skladišča. A na srečo (morda na žalost nekaterih, ki so z nastavitvijo Hadoopa zaslužili veliko denarja) podatkovno skladišče ni izginilo.
V tem članku si bomo ogledali, kaj je podatkovno jezero. Ta članek je namenjen ljudem, ki imajo malo ali nič izkušenj s podatkovnimi skladišči.
Na sliki je Blejsko jezero, to je eno mojih najljubših jezer, čeprav sem bil tam samo enkrat, sem si ga zapomnil za vse življenje. Vendar bomo govorili o drugi vrsti jezera - o podatkovnem jezeru. Morda ste mnogi že večkrat slišali za ta izraz, vendar še ena definicija nikomur ne bo škodila.
Najprej so tukaj najbolj priljubljene definicije podatkovnega jezera:
»shramba datotek vseh vrst neobdelanih podatkov, ki je na voljo za analizo vsem v organizaciji« - Martin Fowler.
»Če mislite, da je podatkovni trg steklenica vode – prečiščena, pakirana in pakirana za udobno uživanje, potem je podatkovno jezero ogromen rezervoar vode v njeni naravni obliki. Uporabniki, lahko zbiram vodo zase, se potapljam globoko, raziskujem« - James Dixon.
Zdaj zagotovo vemo, da je podatkovno jezero namenjeno analitiki, omogoča nam shranjevanje velikih količin podatkov v izvirni obliki in imamo potreben in priročen dostop do podatkov.
Pogosto rad poenostavim stvari, če lahko kompleksen pojem razložim s preprostimi besedami, potem sam razumem, kako deluje in za kaj je potreben. Nekega dne sem brskal po fotogaleriji iPhona in se mi je posvetilo, to je pravo podatkovno jezero, naredil sem celo diapozitiv za konference:
Vse je zelo preprosto. Fotografiramo na telefon, fotografija se shrani na telefon in jo lahko shranimo v iCloud (shramba datotek v oblaku). Telefon zbira tudi metapodatke o fotografijah: kaj je prikazano, geooznaka, čas. Posledično lahko uporabimo uporabniku prijazen vmesnik iPhona, da poiščemo svojo fotografijo in vidimo celo indikatorje, na primer, ko iščem fotografije z besedo ogenj, najdem 3 fotografije s podobo ognja. Zame je to kot orodje poslovne inteligence, ki deluje zelo hitro in natančno.
In seveda ne smemo pozabiti na varnost (avtorizacija in avtentikacija), sicer lahko naši podatki zlahka končajo v javni domeni. Veliko je novic o velikih korporacijah in startupih, katerih podatki so postali javno dostopni zaradi malomarnosti razvijalcev in neupoštevanja preprostih pravil.
Že tako preprosta slika nam pomaga predstavljati, kaj je podatkovno jezero, njegove razlike od tradicionalnega podatkovnega skladišča in njegove glavne elemente:
- Nalaganje podatkov (Zaužitje) je ključna komponenta podatkovnega jezera. Podatki lahko v podatkovno skladišče vstopajo na dva načina – paketno (nalaganje v intervalih) in pretočno (pretok podatkov).
- Shranjevanje datotek (Storage) je glavna komponenta podatkovnega jezera. Potrebovali smo, da je shramba enostavno razširljiva, izjemno zanesljiva in poceni. Na primer, v AWS je S3.
- Katalog in iskanje (Katalog in iskanje) - da se izognemo Data Swampu (to je, ko vse podatke odložimo na en kup in je potem z njimi nemogoče delati), moramo ustvariti metapodatkovno plast za razvrščanje podatkov. tako da uporabniki zlahka najdejo podatke, ki jih potrebujejo za analizo. Poleg tega lahko uporabite dodatne iskalne rešitve, kot je ElasticSearch. Iskanje uporabniku pomaga najti zahtevane podatke preko uporabniku prijaznega vmesnika.
- Predelava (Proces) - ta korak je odgovoren za obdelavo in preoblikovanje podatkov. Podatke lahko transformiramo, spremenimo njihovo strukturo, jih očistimo in še veliko več.
- varnost (Varnost) - Pomembno je posvetiti čas varnostni zasnovi rešitve. Na primer šifriranje podatkov med shranjevanjem, obdelavo in nalaganjem. Pomembno je, da uporabite metode avtentikacije in avtorizacije. Končno je potrebno revizijsko orodje.
S praktičnega vidika lahko podatkovno jezero označimo s tremi atributi:
- Zberite in shranite karkoli — podatkovno jezero vsebuje vse podatke, tako surove neobdelane podatke za poljubno časovno obdobje kot obdelane/očiščene podatke.
- Globoko skeniranje — podatkovno jezero uporabnikom omogoča raziskovanje in analizo podatkov.
- Prilagodljiv dostop — Podatkovno jezero omogoča prilagodljiv dostop do različnih podatkov in različnih scenarijev.
Zdaj lahko govorimo o razliki med podatkovnim skladiščem in podatkovnim jezerom. Ponavadi ljudje vprašajo:
- Kaj pa podatkovno skladišče?
- Ali podatkovno skladišče nadomeščamo s podatkovnim jezerom ali ga širimo?
- Ali je še mogoče brez podatkovnega jezera?
Skratka, ni jasnega odgovora. Vse je odvisno od specifične situacije, sposobnosti ekipe in proračuna. Na primer, selitev podatkovnega skladišča iz Oracle v AWS in ustvarjanje podatkovnega jezera s strani hčerinske družbe Amazon - Woot - .
Po drugi strani pa prodajalec Snowflake pravi, da o podatkovnem jezeru ni več treba razmišljati, saj njihova podatkovna platforma (do leta 2020 je bila to podatkovno skladišče) omogoča združevanje podatkovnega jezera in podatkovnega skladišča. Nisem veliko delal s Snowflake in to je resnično edinstven izdelek, ki zmore to. Druga stvar je cena izdaje.
Na koncu naj povem, da moje osebno mnenje je, da še vedno potrebujemo podatkovno skladišče kot glavni vir podatkov za naše poročanje, vse, kar ne ustreza, pa shranimo v podatkovno jezero. Celotna vloga analitike je omogočiti podjetjem enostaven dostop za sprejemanje odločitev. Karkoli že lahko rečemo, poslovni uporabniki učinkoviteje delajo s podatkovnim skladiščem kot podatkovnim jezerom, na primer v Amazonu - obstaja Redshift (skladišče analitičnih podatkov) in Redshift Spectrum/Athena (SQL vmesnik za podatkovno jezero v S3, ki temelji na Panj/Presto). Enako velja za druga sodobna analitična podatkovna skladišča.
Oglejmo si tipično arhitekturo podatkovnega skladišča:
To je klasična rešitev. Imamo izvorne sisteme, z uporabo ETL/ELT kopiramo podatke v skladišče analitičnih podatkov in jih povežemo z rešitvijo Business Intelligence (moj najljubši je Tableau, kaj pa vaš?).
Ta rešitev ima naslednje pomanjkljivosti:
- Operacije ETL/ELT zahtevajo čas in sredstva.
- Pomnilnik za shranjevanje podatkov v skladišču analitičnih podatkov praviloma ni poceni (na primer Redshift, BigQuery, Teradata), saj moramo kupiti cel grozd.
- Poslovni uporabniki imajo dostop do očiščenih in pogosto združenih podatkov in nimajo dostopa do neobdelanih podatkov.
Seveda je vse odvisno od vašega primera. Če nimate težav s svojim podatkovnim skladiščem, potem podatkovnega jezera sploh ne potrebujete. Ko pa se pojavijo težave s pomanjkanjem prostora, močjo ali igra ključno vlogo cena, potem lahko razmislite o možnosti podatkovnega jezera. Zato je podatkovno jezero zelo priljubljeno. Tukaj je primer arhitekture podatkovnega jezera:
S pristopom podatkovnega jezera naložimo neobdelane podatke v naše podatkovno jezero (paketno ali pretočno), nato pa jih po potrebi obdelamo. Podatkovno jezero omogoča poslovnim uporabnikom ustvarjanje lastnih transformacij podatkov (ETL/ELT) ali analizo podatkov v rešitvah poslovne inteligence (če je na voljo potreben gonilnik).
Cilj vsake analitične rešitve je služiti poslovnim uporabnikom. Zato moramo vedno delati v skladu s poslovnimi zahtevami. (Pri Amazonu je to eno od načel - delo za nazaj).
Če delamo s podatkovnim skladiščem in podatkovnim jezerom, lahko primerjamo obe rešitvi:
Glavna ugotovitev, ki jo lahko potegnemo, je, da podatkovno skladišče ne konkurira podatkovnemu jezeru, temveč ga dopolnjuje. Na vas pa je, da se odločite, kaj je prav za vaš primer. Vedno je zanimivo poskusiti sami in narediti prave zaključke.
Rad bi vam povedal tudi enega izmed primerov, ko sem začel uporabljati pristop podatkovnega jezera. Vse je precej trivialno, poskusil sem uporabiti orodje ELT (imeli smo Matillion ETL) in Amazon Redshift, moja rešitev je delovala, vendar ni ustrezala zahtevam.
Moral sem vzeti spletne dnevnike, jih preoblikovati in združiti, da bi zagotovil podatke za 2 primera:
- Tržna ekipa je želela analizirati dejavnost botov za SEO
- IT je želel preučiti meritve uspešnosti spletnega mesta
Zelo preprosti, zelo preprosti dnevniki. Tukaj je primer:
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" "-" "-"Ena datoteka je tehtala 1-4 megabajte.
Vendar je bila ena težava. Imeli smo 7 domen po vsem svetu in v enem dnevu je bilo ustvarjenih 7000 tisoč datotek. To ni veliko večja prostornina, le 50 gigabajtov. Vendar je bila tudi velikost naše gruče Redshift majhna (4 vozlišča). Nalaganje ene datoteke na tradicionalen način je trajalo približno minuto. To pomeni, da problem ni bil neposredno rešen. In tako je bilo, ko sem se odločil uporabiti pristop podatkovnega jezera. Rešitev je izgledala nekako takole:
Je precej preprosto (želim opozoriti, da je prednost dela v oblaku preprostost). Uporabil sem:
- AWS Elastic Map Reduce (Hadoop) za računalniško moč
- AWS S3 kot shramba datotek z možnostjo šifriranja podatkov in omejitve dostopa
- Spark kot računalniška moč InMemory in PySpark za logiko in transformacijo podatkov
- Parket kot rezultat Spark
- AWS Glue Crawler kot zbiralec metapodatkov o novih podatkih in particijah
- Redshift Spectrum kot vmesnik SQL do podatkovnega jezera za obstoječe uporabnike Redshift
Najmanjša gruča EMR+Spark je obdelala celoten sveženj datotek v 30 minutah. Obstajajo tudi drugi primeri za AWS, zlasti veliko povezanih z Alexa, kjer je veliko podatkov.
Pred kratkim sem izvedel, da je ena od pomanjkljivosti podatkovnega jezera GDPR. Težava je v tem, da ko odjemalec zahteva izbris in so podatki v eni od datotek, ne moremo uporabiti jezika za manipulacijo podatkov in operacije DELETE kot v bazi podatkov.
Upam, da je ta članek pojasnil razliko med podatkovnim skladiščem in podatkovnim jezerom. Če vas zanima, lahko prevedem več svojih člankov ali člankov strokovnjakov, ki jih berem. Povedati tudi o rešitvah, s katerimi delam, in njihovi arhitekturi.
Vir: www.habr.com