Tento článek je překladem mého článku na médiu - , který se ukázal být docela populární, pravděpodobně pro svou jednoduchost. Proto jsem se rozhodl to napsat v ruštině a trochu přidat, aby bylo běžnému člověku, který není datovým specialistou, jasné, co je datový sklad (DW) a co je datové jezero (Data Lake) a jak vycházet spolu.
Proč jsem chtěl psát o datovém jezeře? S daty a analytikou pracuji více než 10 let a nyní rozhodně pracuji s velkými daty v Amazon Alexa AI v Cambridge, což je v Bostonu, ačkoli žiji ve Victorii na ostrově Vancouver a často navštěvuji Boston, Seattle , a Ve Vancouveru a někdy i v Moskvě mluvím na konferencích. Čas od času také píšu, ale píšu hlavně anglicky a už jsem psal Také mám potřebu sdílet analytické trendy ze Severní Ameriky a občas píšu .
Vždy jsem pracoval s datovými sklady a od roku 2015 jsem začal úzce spolupracovat s Amazon Web Services a obecně jsem přešel na cloudovou analytiku (AWS, Azure, GCP). Pozoroval jsem vývoj analytických řešení od roku 2007 a dokonce jsem pracoval pro dodavatele datového skladu Teradata a implementoval jsem ho ve Sberbank, což je doba, kdy se objevila Big Data s Hadoopem. Všichni začali říkat, že éra úložiště pominula a teď všichni používají Hadoop, a pak se zase začalo mluvit o Data Lake, že teď definitivně nastal konec datového skladu. Datový sklad ale naštěstí (možná bohužel pro některé, kteří na zřízení Hadoopu vydělali hodně peněz) nezmizel.
V tomto článku se podíváme na to, co je to datové jezero. Tento článek je určen lidem, kteří mají s datovými sklady malé nebo žádné zkušenosti.
Na obrázku je jezero Bled, to je jedno z mých nejoblíbenějších jezer, i když jsem tam byl jen jednou, pamatoval jsem si to do konce života. Budeme se ale bavit o jiném typu jezera – datovém jezeře. Možná mnozí z vás již o tomto pojmu nejednou slyšeli, ale ještě jedna definice nikomu neuškodí.
Za prvé, zde jsou nejoblíbenější definice Data Lake:
„souborové úložiště všech typů nezpracovaných dat, které je k dispozici pro analýzu komukoli v organizaci“ – Martin Fowler.
„Pokud si myslíte, že datový obchod je láhev vody – vyčištěná, zabalená a zabalená pro pohodlnou spotřebu, pak je datové jezero obrovskou zásobárnou vody ve své přirozené podobě. Uživatelé, mohu sbírat vodu pro sebe, potápět se hluboko, prozkoumávat“ - James Dixon.
Nyní s jistotou víme, že datové jezero je o analytice, umožňuje nám ukládat velké množství dat v původní podobě a máme k nim potřebný a pohodlný přístup.
Často rád věci zjednodušuji, pokud dokážu složitý pojem vysvětlit jednoduchými slovy, pak sám pochopím, jak to funguje a k čemu je to potřeba. Jednoho dne jsem šmátral ve fotogalerii iPhonu a došlo mi, tohle je skutečné datové jezero, dokonce jsem udělal snímek pro konference:
Vše je velmi jednoduché. Fotíme telefonem, fotka se uloží do telefonu a lze ji uložit na iCloud (cloudové úložiště souborů). Telefon také shromažďuje metadata fotografií: to, co je zobrazeno, zeměpisné označení, čas. Díky tomu můžeme k vyhledání naší fotografie použít uživatelsky přívětivé rozhraní iPhonu a dokonce vidíme indikátory, například když hledám fotografie se slovem oheň, najdu 3 fotografie s obrázkem ohně. Pro mě je to jako nástroj Business Intelligence, který funguje velmi rychle a jasně.
A samozřejmě nesmíme zapomenout na bezpečnost (autorizaci a autentizaci), jinak mohou naše data snadno skončit ve veřejné doméně. Je spousta novinek o velkých korporacích a startupech, jejichž data se díky nedbalosti vývojářů a nedodržování jednoduchých pravidel stala veřejně dostupná.
I takový jednoduchý obrázek nám pomůže představit si, co je to datové jezero, jeho rozdíly od tradičního datového skladu a jeho hlavní prvky:
- Načítání dat (Ingestion) je klíčovou součástí datového jezera. Data mohou vstupovat do datového skladu dvěma způsoby – dávkovým (načítání v intervalech) a streamováním (datový tok).
- Ukládání souborů (Úložiště) je hlavní součástí Data Lake. Potřebovali jsme, aby bylo úložiště snadno škálovatelné, extrémně spolehlivé a levné. Například v AWS je to S3.
- Katalog a vyhledávání (Katalog a vyhledávání) - abychom se vyhnuli Data Swamp (to je, když všechna data vysypeme na jednu hromádku a pak se s nimi nedá pracovat), musíme vytvořit metadatovou vrstvu pro klasifikaci dat aby uživatelé mohli snadno najít data, která potřebují pro analýzu. Kromě toho můžete použít další vyhledávací řešení, jako je ElasticSearch. Vyhledávání pomáhá uživateli najít požadovaná data prostřednictvím uživatelsky přívětivého rozhraní.
- Zpracování (Proces) - tento krok je zodpovědný za zpracování a transformaci dat. Můžeme transformovat data, měnit jejich strukturu, čistit je a mnoho dalšího.
- zabezpečení (Zabezpečení) – Je důležité věnovat čas návrhu zabezpečení řešení. Například šifrování dat během ukládání, zpracování a načítání. Je důležité používat metody ověřování a autorizace. Nakonec je zapotřebí nástroj pro audit.
Z praktického hlediska můžeme datové jezero charakterizovat třemi atributy:
- Sbírejte a ukládejte cokoli — datové jezero obsahuje všechna data, jak surová nezpracovaná data za jakékoli časové období, tak zpracovaná/vyčištěná data.
- Hluboké skenování — datové jezero umožňuje uživatelům zkoumat a analyzovat data.
- Flexibilní přístup — Datové jezero poskytuje flexibilní přístup k různým datům a různým scénářům.
Nyní můžeme mluvit o rozdílu mezi datovým skladem a datovým jezerem. Obvykle se lidé ptají:
- A co datový sklad?
- Nahrazujeme datový sklad datovým jezerem nebo jej rozšiřujeme?
- Dá se to ještě obejít bez datového jezera?
Zkrátka jednoznačná odpověď neexistuje. Vše záleží na konkrétní situaci, schopnostech týmu a rozpočtu. Například migrace datového skladu do Oracle na AWS a vytvoření datového jezera dceřinou společností Amazonu – Woot – .
Na druhou stranu, prodejce Snowflake říká, že už nemusíte přemýšlet o datovém jezeře, protože jejich datová platforma (do roku 2020 to byl datový sklad) umožňuje kombinovat jak datové jezero, tak datový sklad. Se Snowflake jsem moc nepracoval a je to opravdu unikátní produkt, který tohle umí. Cena emise je jiná věc.
Na závěr můj osobní názor je, že stále potřebujeme datový sklad jako hlavní zdroj dat pro naše reportingy a cokoli se nevejde, uložíme do datového jezera. Úkolem analytiky je poskytnout firmám snadný přístup k rozhodování. Ať už se dá říct cokoli, firemní uživatelé pracují s datovým skladem efektivněji než s datovým jezerem, například v Amazonu – existuje Redshift (analytický datový sklad) a Redshift Spectrum/Athena (rozhraní SQL pro datové jezero v S3 založené na Úl/Presto). Totéž platí pro další moderní analytické datové sklady.
Podívejme se na typickou architekturu datového skladu:
Jedná se o klasické řešení. Máme zdrojové systémy, pomocí ETL/ELT kopírujeme data do analytického datového skladu a propojujeme je s řešením Business Intelligence (mým oblíbeným je Tableau, a co vy?).
Toto řešení má následující nevýhody:
- Operace ETL/ELT vyžadují čas a zdroje.
- Paměť pro ukládání dat v analytickém datovém skladu zpravidla není levná (například Redshift, BigQuery, Teradata), protože musíme koupit celý cluster.
- Firemní uživatelé mají přístup k vyčištěným a často agregovaným datům a nemají přístup k nezpracovaným datům.
Vše samozřejmě záleží na vašem případu. Pokud nemáte problémy s datovým skladem, pak datové jezero vůbec nepotřebujete. Když ale nastanou problémy s nedostatkem místa, energie nebo cena hraje klíčovou roli, pak můžete zvážit možnost datového jezera. To je důvod, proč je datové jezero velmi oblíbené. Zde je příklad architektury datového jezera:
Pomocí přístupu data lake načítáme nezpracovaná data do našeho datového jezera (dávka nebo streamování), poté data zpracováváme podle potřeby. Datové jezero umožňuje podnikovým uživatelům vytvářet vlastní transformace dat (ETL/ELT) nebo analyzovat data v řešeních Business Intelligence (pokud je k dispozici potřebný ovladač).
Cílem každého analytického řešení je sloužit podnikovým uživatelům. Proto musíme vždy pracovat podle obchodních požadavků. (U Amazonu je to jeden z principů – pracovat pozpátku).
Při práci s datovým skladem a datovým jezerem můžeme obě řešení porovnat:
Hlavním závěrem, který lze vyvodit, je, že datový sklad datovému jezeru nekonkuruje, ale spíše jej doplňuje. Ale je na vás, abyste se rozhodli, co je pro váš případ správné. Vždy je zajímavé si to sami vyzkoušet a vyvodit správné závěry.
Rád bych vám také řekl jeden z případů, kdy jsem začal používat přístup data lake. Vše je celkem triviální, zkusil jsem použít nástroj ELT (měli jsme Matillion ETL) a Amazon Redshift, moje řešení fungovalo, ale nevyhovovalo požadavkům.
Potřeboval jsem vzít webové protokoly, transformovat je a agregovat, abych poskytl data pro 2 případy:
- Marketingový tým chtěl analyzovat aktivitu botů pro SEO
- IT se chtělo podívat na metriky výkonu webu
Velmi jednoduché, velmi jednoduché protokoly. Zde je příklad:
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" "-" "-"Jeden soubor vážil 1-4 megabajty.
Ale byla tu jedna potíž. Měli jsme 7 domén po celém světě a za jeden den bylo vytvořeno 7000 50 tisíc souborů. To není o moc větší objem, jen 4 gigabajtů. Ale velikost našeho clusteru Redshift byla také malá (XNUMX uzly). Načtení jednoho souboru tradičním způsobem trvalo asi minutu. To znamená, že problém nebyl vyřešen čelně. A to byl případ, kdy jsem se rozhodl použít přístup datového jezera. Řešení vypadalo asi takto:
Je to celkem jednoduché (chci poznamenat, že výhodou práce v cloudu je jednoduchost). Použil jsem:
- AWS Elastic Map Reduce (Hadoop) pro výpočetní výkon
- AWS S3 jako úložiště souborů s možností šifrování dat a omezení přístupu
- Spark jako výpočetní výkon InMemory a PySpark pro logiku a transformaci dat
- Parkety jako výsledek Spark
- AWS Glue Crawler jako sběratel metadat o nových datech a oddílech
- Redshift Spectrum jako SQL rozhraní k datovému jezeru pro stávající uživatele Redshift
Nejmenší cluster EMR+Spark zpracoval celý zásobník souborů za 30 minut. Existují další případy pro AWS, zejména mnoho souvisejících s Alexou, kde je mnoho dat.
Nedávno jsem se dozvěděl, že jednou z nevýhod datového jezera je GDPR. Problém je, když klient požádá o smazání a data jsou v jednom ze souborů, nemůžeme použít Data Manipulation Language a operaci DELETE jako v databázi.
Doufám, že tento článek objasnil rozdíl mezi datovým skladem a datovým jezerem. V případě zájmu mohu přeložit více mých článků nebo článků profesionálů, které jsem přečetl. A také vyprávět o řešeních, se kterými pracuji, a jejich architektuře.
Zdroj: www.habr.com