Architektura datových skladů a Data Lakehouse: konvergence analytických světů

Abstrakt: Svět datové analytiky byl po desetiletí rozdělen na dva nesmiřitelné tábory: strukturované, vysoce kvalitní, ale drahé a rigidní datové sklady a flexibilní, levná, ale chaotická datová jezera. Článek analyzuje historický vývoj těchto architektur, jejich limity a představuje koncept Data Lakehouse, který kombinuje to nejlepší z obou světů. Text rozebírá technologické inovace, které Lakehouse umožnily — především otevřené tabulkové formáty Delta Lake, Apache Iceberg a Apache Hudi, které přinášejí transakční integritu (ACID) a podporu SQL nad levným objektovým úložištěm. Věnuje se rovněž architektonickému vzoru Medallion (Bronze, Silver, Gold) a důsledkům pro správu dat a jejich demokratizaci v podnicích.

---

1. Úvod: příběh dvou architektur

Abychom pochopili současnou změnu, musíme se podívat do historie.

1.1 Éra datových skladů (1980 — 2010)

Enterprise Data Warehouse vznikl z potřeby sjednotit data z různých operačních systémů (ERP, CRM, billing) pro účely reportingu.

• Charakteristika: relační databáze, silné schéma definované při zápisu, SQL, vysoká kvalita dat.
• Technologie: Teradata, Oracle Exadata, později cloudové Snowflake či Google BigQuery.
• Problém: drahé na škálování. Neumějí efektivně pracovat s nestrukturovanými daty (video, text, logy). Změna schématu trvá měsíce.

1.2 Éra datových jezer (2010 — současnost)

S nástupem Big Data a Hadoopu vznikla potřeba ukládat obrovské objemy dat levně.

• Charakteristika: ukládání souborů „tak jak jsou" (schéma se vyhodnocuje až při čtení), podpora všech typů dat, levný hardware nebo cloudové úložiště typu S3.
• Technologie: HDFS, AWS S3, Azure Data Lake Storage.
• Problém: mnoho jezer se zvrhlo v takzvané datové bažiny. Data byla nekonzistentní, chyběly transakce (selhal-li zápis v polovině, soubor byl poškozen), chyběla možnost řízeně mazat data (problém s GDPR) a výkon pro BI dotazy byl tragický.

1.3 Důsledek: dvojí architektura

Většina firem skončila s hybridním modelem. Data se nasypala do jezera (pro datové vědce a strojové učení), pak se složitě transformovala a nahrála do skladu (pro BI analytiky a management). Nevýhody jsou zřejmé: duplikace dat (úložiště se platí dvakrát), nekonzistence (reporty v BI nesedí s modely v ML) a složitá údržba transformačních pipeline.

---

2. Data Lakehouse: sjednocení paradigmat

Koncept Data Lakehouse, popularizovaný společností Databricks, slibuje sjednocení obou světů. Lakehouse je architektura pro správu dat, která implementuje funkce typické pro datové sklady — ACID transakce, verzování, indexování — přímo nad levným úložištěm typu data lake.

2.1 Klíčové vlastnosti

1. Transakční podpora. Mnoho datových pipeline čte a zapisuje data současně. Lakehouse garantuje atomicitu (zapíše se vše, nebo nic) a izolaci.
2. Vynucování a evoluce schématu. Lakehouse odmítne zapsat data, která neodpovídají schématu, ale zároveň umožňuje schéma řízeně měnit.
3. Oddělení výpočtu a úložiště. Data leží levně na S3 nebo ADLS. Výpočetní kapacita (Spark clustery, SQL warehousy) se spouští, jen když je potřeba, a škáluje se nezávisle.
4. Otevřenost. Data jsou uložena v otevřených formátech (Parquet, Avro, ORC). Nejsou uzamčena v proprietárním formátu jednoho dodavatele. K datům přistupuje Spark, Python, SQL, Presto, Trino i Power BI.
5. Podpora pro BI i strojové učení. Nad stejnými daty běží SQL dotazy pro dashboardy i Python skripty pro trénování modelů.

---

3. Technologické základy: otevřené tabulkové formáty

To, co dělá Lakehouse možným, je vrstva metadat nad surovými soubory. Tři hlavní technologie soupeří o dominanci.

3.1 Delta Lake (Databricks, Linux Foundation)

Pravděpodobně nejrozšířenější formát. Ukládá data v Parquet souborech a vede k nim transakční log (_delta_log), což je série JSON souborů popisujících, které Parquet soubory jsou platné pro danou verzi tabulky. Mezi klíčové funkce patří Time Travel (možnost dotázat se na stav dat k minulému úterý), Z-Ordering (optimalizace fyzického uložení pro rychlé vyhledávání) a MERGE (SQL příkaz pro update a insert).

3.2 Apache Iceberg (Netflix, Apache Software Foundation)

Původně vyvinut v Netflixu pro obrovské tabulky o velikosti petabajtů. Vyniká podporou změn schématu — přejmenování sloupce je jen změna v metadatech a nepřepisují se data. Nabízí skryté partitioning, kdy uživatel nemusí vědět, jak je tabulka fyzicky rozdělena. Silně ho podporují Snowflake, AWS i Cloudera.

3.3 Apache Hudi (Uber, Apache Software Foundation)

Zaměřen na streamování a časté aktualizace záznamů (upserty). Ideální pro scénáře, kde se data mění velmi rychle, například data o jízdách v aplikaci Uber.

---

4. Medallion Architecture

Jak organizovat data uvnitř Lakehouse? Standardem se stala medailová architektura, která definuje tři vrstvy kvality dat.

4.1 Bronzová vrstva — surová data

Surová data přesně tak, jak přišla ze zdroje (Kafka, IoT, API, dump databáze). Slouží jako historický záznam a umožňuje přepočítání v případě chyby v logice. Strukturou jsou často jen JSONy nebo CSV, vrstva je pouze pro připojování dalších záznamů a nemá validaci schématu.

4.2 Stříbrná vrstva — pročištěná data

Vyčištěná, deduplikovaná a otypovaná data. Transformace zahrnují odstranění prázdných hodnot, parsování JSONů do sloupců, sjednocení formátů data a join referenčních dat (například nahrazení identifikátoru zákazníka jeho jménem). Slouží datovým vědcům a pokročilým analytikům jako důvěryhodný, ale stále granulární zdroj.

4.3 Zlatá vrstva — připravená pro byznys

Vysoce agregovaná data připravená pro konkrétní byznysové účely. Často modelovaná jako hvězdicové schéma s tabulkami faktů a dimenzí. Je to zdroj pro reporting (Power BI, Tableau) a manažerské dashboardy s rychlou odezvou.

---

5. Výhody a byznys hodnota

Přechod na Lakehouse není jen technologické cvičení, má přímý dopad na byznys.

1. Snížení celkových nákladů. Eliminace drahých licencí za tradiční datové sklady pro ukládání historických dat. Ukládání na S3 stojí jednotky centů za gigabajt.
2. Práce v reálném čase. Díky streamovacím schopnostem Sparku mohou data protékat z bronzové do zlaté vrstvy v řádu sekund. Management vidí prodeje teď, ne včera.
3. Správa dat a GDPR. Díky podpoře DELETE a UPDATE v Delta Lake i Icebergu lze snadno vymazat data zákazníka, takzvané právo být zapomenut. V čistém datovém jezeře nad HDFS to bylo extrémně obtížné, musel se přepsat celý soubor.
4. Demokratizace dat. Data nejsou zamčená v silech. Analytik se SQL i datový vědec s Pythonem přistupují ke stejné tabulce. Odpadá hádka, čí čísla jsou správná.

---

6. Výzvy a budoucnost

Lakehouse není bez problémů. Správa tisíců malých souborů (známý problém small files) vyžaduje pravidelnou údržbu pomocí příkazů VACUUM a OPTIMIZE. Pro extrémně rychlé dotazy s latencí pod sekundu nad menšími datovými sadami zůstává specializovaná databáze (ClickHouse, Druid) rychlejší.

Budoucnost směřuje k bezserverovým variantám Lakehouse, kde uživatel neřeší clustery a jen píše SQL, a k integraci s generativní AI, kdy se velký jazykový model dotazuje dat v Lakehouse přirozeným jazykem.

---

7. Závěr

Data Lakehouse představuje konvergenci dvou světů, která byla nevyhnutelná. Pro moderní firmu, která chce být řízená daty a zároveň využívat AI, je to v současnosti nejracionálnější architektonická volba. Umožňuje začít v malém a škálovat až do petabajtů, aniž by bylo nutné měnit platformu.

---

Reference a doporučená literatura

• Armbrust, M., et al. (2021): Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. CIDR.
• Inmon, W. H. (2005): Building the Data Warehouse.
• Kimball, R., & Ross, M. (2013): The Data Warehouse Toolkit.
• Databricks: The Data Lakehouse Platform.
• Zaharia, M., et al. (2016): Apache Spark: A Unified Engine for Big Data Processing.
• Apache Iceberg Documentation.
• Delta Lake Documentation.