Ovaj članak je prijevod mog članka o mediju - , koji se pokazao prilično popularnim, vjerojatno zbog svoje jednostavnosti. Stoga sam odlučio to napisati na ruskom i dodati malo kako bi običnoj osobi koja nije stručnjak za podatke bilo jasno što je skladište podataka (DW), a što jezero podataka (Data Lake) i kako se slagati se zajedno.
Zašto sam htio pisati o jezeru podataka? Radim s podacima i analitikom više od 10 godina, a sada definitivno radim s velikim podacima u Amazon Alexa AI u Cambridgeu, koji je u Bostonu, iako živim u Victoriji na otoku Vancouver i često posjećujem Boston, Seattle , i U Vancouveru, a ponekad čak iu Moskvi, govorim na konferencijama. I ja pišem s vremena na vrijeme, ali pišem uglavnom na engleskom, a već sam pisao , također imam potrebu podijeliti analitičke trendove iz Sjeverne Amerike i ponekad pišem .
Oduvijek sam radio sa skladištima podataka, a od 2015. počeo sam blisko surađivati s Amazon Web Services, te općenito prešao na analitiku u oblaku (AWS, Azure, GCP). Promatram evoluciju analitičkih rješenja od 2007. i čak sam radio za prodavača skladišta podataka Teradata i implementirao ga u Sberbanku, a tada se pojavio Big Data s Hadoopom. Svi su počeli govoriti da je era skladišta prošla i da je sada sve na Hadoopu, a onda su opet počeli pričati o Data Lakeu, da je sada definitivno došao kraj skladišta podataka. Ali na sreću (možda nesreću za neke koji su zaradili mnogo novca postavljajući Hadoop), skladište podataka nije nestalo.
U ovom članku ćemo pogledati što je podatkovno jezero. Ovaj je članak namijenjen ljudima koji imaju malo ili nimalo iskustva sa skladištima podataka.
Na slici je Bledsko jezero, ovo mi je jedno od najdražih jezera, iako sam tamo bio samo jednom, zapamtio sam ga za cijeli život. Ali mi ćemo govoriti o drugoj vrsti jezera - jezeru podataka. Možda su mnogi od vas već više puta čuli za ovaj pojam, ali još jedna definicija nikome neće škoditi.
Prije svega, ovdje su najpopularnije definicije podatkovnog jezera:
"pohrana datoteka svih vrsta neobrađenih podataka koja je dostupna za analizu bilo kome u organizaciji" - Martin Fowler.
“Ako mislite da je data mart boca vode - pročišćena, zapakirana i pakirana za praktičnu konzumaciju, onda je podatkovno jezero ogroman rezervoar vode u njenom prirodnom obliku. Korisnici, mogu skupljati vodu za sebe, roniti duboko, istraživati” - James Dixon.
Sada sa sigurnošću znamo da se podatkovno jezero odnosi na analitiku, omogućuje nam pohranjivanje velikih količina podataka u izvornom obliku i imamo potreban i praktičan pristup podacima.
Često volim pojednostaviti stvari, ako mogu objasniti složeni pojam jednostavnim riječima, onda sam razumijem kako funkcionira i za što je potreban. Jednog dana sam čačkao po fotogaleriji iPhonea i sinulo mi je, ovo je pravo jezero podataka, čak sam napravio slajd za konferencije:
Sve je vrlo jednostavno. Fotografiramo telefonom, fotografija se sprema na telefon i može se spremiti u iCloud (cloud file storage). Telefon također prikuplja metapodatke o fotografiji: što je prikazano, geo tag, vrijeme. Kao rezultat toga, možemo koristiti korisničko sučelje iPhonea da pronađemo svoju fotografiju, a čak vidimo i indikatore, na primjer, kada tražim fotografije s riječju vatra, pronađem 3 fotografije sa slikom vatre. Za mene je ovo kao alat za poslovnu inteligenciju koji radi vrlo brzo i jasno.
I naravno, ne smijemo zaboraviti na sigurnost (autorizaciju i autentifikaciju), inače naši podaci lako mogu završiti u javnoj domeni. Puno je vijesti o velikim korporacijama i startupima čiji su podaci postali javno dostupni zbog nemara programera i nepoštivanja jednostavnih pravila.
Čak i tako jednostavna slika pomaže nam zamisliti što je podatkovno jezero, njegove razlike u odnosu na tradicionalno skladište podataka i njegove glavne elemente:
- Učitavanje podataka (Ingestion) ključna je komponenta podatkovnog jezera. Podaci mogu ući u skladište podataka na dva načina - batch (učitavanje u intervalima) i streaming (protok podataka).
- Pohrana datoteka (Storage) glavna je komponenta podatkovnog jezera. Trebali smo da pohrana bude lako skalabilna, iznimno pouzdana i jeftina. Na primjer, u AWS-u to je S3.
- Katalog i Pretraživanje (Katalog i pretraživanje) - kako bismo izbjegli Data Swamp (to je kada sve podatke bacimo na jednu hrpu i onda je nemoguće raditi s njima), moramo napraviti sloj metapodataka za klasifikaciju podataka tako da korisnici mogu lako pronaći podatke koji su im potrebni za analizu. Osim toga, možete koristiti dodatna rješenja za pretraživanje kao što je ElasticSearch. Pretraživanje pomaže korisniku da pronađe tražene podatke putem korisničkog sučelja.
- Obrada (Proces) - ovaj korak je odgovoran za obradu i transformaciju podataka. Možemo transformirati podatke, promijeniti njihovu strukturu, očistiti ih i još mnogo toga.
- sigurnosti (Sigurnost) - Važno je posvetiti vrijeme sigurnosnom dizajnu rješenja. Na primjer, šifriranje podataka tijekom pohrane, obrade i učitavanja. Važno je koristiti metode provjere autentičnosti i autorizacije. Konačno, potreban je alat za reviziju.
S praktičnog gledišta, podatkovno jezero možemo okarakterizirati pomoću tri atributa:
- Sakupite i pohranite bilo što — podatkovno jezero sadrži sve podatke, i neobrađene podatke za bilo koje vremensko razdoblje i obrađene/očišćene podatke.
- Duboko skeniranje — podatkovno jezero omogućuje korisnicima istraživanje i analizu podataka.
- Fleksibilan pristup — Podatkovno jezero pruža fleksibilan pristup različitim podacima i različitim scenarijima.
Sada možemo govoriti o razlici između skladišta podataka i podatkovnog jezera. Obično ljudi pitaju:
- Što je sa skladištem podataka?
- Zamjenjujemo li skladište podataka podatkovnim jezerom ili ga proširujemo?
- Je li još uvijek moguće bez podatkovnog jezera?
Ukratko, nema jasnog odgovora. Sve ovisi o konkretnoj situaciji, vještinama tima i budžetu. Na primjer, migracija skladišta podataka s Oraclea na AWS i stvaranje podatkovnog jezera od strane Amazonove podružnice - Woot - .
S druge strane, dobavljač Snowflake kaže da više ne morate razmišljati o podatkovnom jezeru, budući da njihova podatkovna platforma (do 2020. bila je to skladište podataka) omogućuje kombiniranje i podatkovnog jezera i podatkovnog skladišta. Nisam puno radio sa Snowflakeom, a to je uistinu jedinstven proizvod koji to može. Cijena izdanja je druga stvar.
Zaključno, moje osobno mišljenje je da nam i dalje treba skladište podataka kao glavni izvor podataka za naše izvješćivanje, a sve što nam ne štima spremamo u podatkovno jezero. Cjelokupna uloga analitike je osigurati jednostavan pristup tvrtki za donošenje odluka. Što god rekli, poslovni korisnici učinkovitije rade sa skladištem podataka nego s jezerom podataka, na primjer u Amazonu - postoji Redshift (analitičko skladište podataka) i postoji Redshift Spectrum/Athena (SQL sučelje za podatkovno jezero u S3 temeljeno na Košnica/Presto). Isto vrijedi i za druga moderna skladišta analitičkih podataka.
Pogledajmo tipičnu arhitekturu skladišta podataka:
Ovo je klasično rješenje. Imamo izvorne sustave, koristeći ETL/ELT kopiramo podatke u analitičko skladište podataka i povezujemo ga s Business Intelligence rješenjem (moj favorit je Tableau, a što je s vama?).
Ovo rješenje ima sljedeće nedostatke:
- ETL/ELT operacije zahtijevaju vrijeme i resurse.
- Memorija za pohranjivanje podataka u skladište analitičkih podataka u pravilu nije jeftina (npr. Redshift, BigQuery, Teradata), jer trebamo kupiti cijeli klaster.
- Poslovni korisnici imaju pristup očišćenim i često agregiranim podacima, a nemaju pristup neobrađenim podacima.
Naravno, sve ovisi o vašem slučaju. Ako nemate problema sa svojim skladištem podataka, onda vam podatkovno jezero uopće ne treba. Ali kada se pojave problemi s nedostatkom prostora, snage ili cijena igra ključnu ulogu, tada možete razmotriti opciju podatkovnog jezera. Zbog toga je podatkovno jezero vrlo popularno. Evo primjera arhitekture podatkovnog jezera:
Koristeći pristup podatkovnom jezeru, učitavamo neobrađene podatke u naše podatkovno jezero (batch ili streaming), a zatim obrađujemo podatke prema potrebi. Podatkovno jezero omogućuje poslovnim korisnicima stvaranje vlastitih transformacija podataka (ETL/ELT) ili analizu podataka u rješenjima poslovne inteligencije (ako je potreban upravljački program dostupan).
Cilj svakog analitičkog rješenja je služiti poslovnim korisnicima. Stoga uvijek moramo raditi prema zahtjevima poslovanja. (U Amazonu ovo je jedno od načela - rad unatrag).
Radeći sa skladištem podataka i jezerom podataka, možemo usporediti oba rješenja:
Glavni zaključak koji se može izvući jest da se skladište podataka ne natječe s podatkovnim jezerom, već ga nadopunjuje. Ali na vama je da odlučite što je ispravno za vaš slučaj. Uvijek je zanimljivo isprobati sami i izvući prave zaključke.
Također bih vam želio ispričati jedan od slučajeva kada sam počeo koristiti data lake pristup. Sve je prilično trivijalno, pokušao sam koristiti ELT alat (imali smo Matillion ETL) i Amazon Redshift, moje rješenje je radilo, ali nije odgovaralo zahtjevima.
Trebao sam uzeti web zapisnike, transformirati ih i agregirati kako bih pružio podatke za 2 slučaja:
- Marketinški tim želio je analizirati aktivnost bota za SEO
- IT je želio pogledati metriku izvedbe web stranice
Vrlo jednostavni, vrlo jednostavni dnevnici. Evo primjera:
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" "-" "-"Jedna datoteka težila je 1-4 megabajta.
Ali postojala je jedna poteškoća. Imali smo 7 domena po cijelom svijetu, au jednom danu kreirano je 7000 tisuća datoteka. Ovo nije puno veći volumen, samo 50 gigabajta. Ali veličina našeg Redshift klastera također je bila mala (4 čvora). Učitavanje jedne datoteke na tradicionalan način trajalo je otprilike minutu. Odnosno, problem nije riješen direktno. I to je bio slučaj kada sam odlučio upotrijebiti pristup podatkovnog jezera. Rješenje je izgledalo otprilike ovako:
Vrlo je jednostavno (želim napomenuti da je prednost rada u oblaku jednostavnost). Koristio sam:
- AWS Elastic Map Reduce (Hadoop) za snagu računala
- AWS S3 kao pohrana datoteka s mogućnošću šifriranja podataka i ograničavanja pristupa
- Spark kao InMemory računalna snaga i PySpark za logiku i transformaciju podataka
- Parket kao rezultat Spark
- AWS Glue Crawler kao sakupljač metapodataka o novim podacima i particijama
- Redshift Spectrum kao SQL sučelje za jezero podataka za postojeće Redshift korisnike
Najmanji EMR+Spark klaster obradio je cijeli hrp datoteka u 30 minuta. Postoje i drugi slučajevi za AWS, posebno mnogi povezani s Alexom, gdje postoji mnogo podataka.
Nedavno sam saznao da je jedan od nedostataka podatkovnog jezera GDPR. Problem je kada klijent traži brisanje, a podaci su u jednoj od datoteka, ne možemo koristiti Data Manipulation Language i operaciju DELETE kao u bazi podataka.
Nadam se da je ovaj članak razjasnio razliku između skladišta podataka i podatkovnog jezera. Ako ste zainteresirani, mogu prevesti više svojih članaka ili članaka stručnjaka koje čitam. I također reći o rješenjima s kojima radim i njihovoj arhitekturi.
Izvor: www.habr.com