Datový sklad, lakehouse, nebo data mesh?

Datový sklad, data lake, lakehouse, data mesh — každý rok přibývá termín, který podle konferenčních slajdů „nahrazuje všechno předchozí”. Ve skutečnosti jsou to čtyři různé odpovědi na dvě otázky: kde mají data žít a kdo za ně odpovídá. Každá vznikla pro jiný typ firmy — a nejlíp se to vysvětluje na firmách, které na nich skutečně jedou. Projdeme je jednu po druhé, vždy stejně: co to je, v čem je to silné, kdo to používá a pro koho dává smysl. A na konci řekneme jasný závěr — ne jen „záleží”.

Datový sklad: jedna databáze, jedna pravda

Co to je. Strukturovaná data ze všech systémů se pravidelně stahují do jedné relační databáze, kde se čistí, propojují a modelují pro reporting. Všechno je v tabulkách, na všechno se ptáte přes SQL, každá metrika má jednu definici.

Silné stránky. Konzistence a jednoduchost provozu. Slabina: relační databáze má výkonnostní strop — a nestrukturovaná data (obrázky, logy, texty) do ní nepatří.

Kdo na něm jede. Banky a retail na něm stojí od devadesátých let — je to nejprověřenější vzor v oboru. A v menším měřítku je to dnes standard pro střední firmy: typický český e-shop se Shoptetem, Pohodou a třemi reklamními účty má gigabajty strukturovaných dat, o která se stará jeden člověk. Přesně pro tenhle profil stavíme sklady na PostgreSQL.

Pro koho. Firmy se strukturovanými daty z běžných systémů, které chtějí řídit byznys podle čísel — bez datového týmu.

Data lake: levné jezero surových dat

Co to je. Surová data — soubory, logy, exporty — se ukládají do levného objektového úložiště přesně tak, jak přišla. Struktura se řeší až při čtení.

Silné stránky. Cena a kapacita: uložíte cokoli a kolik chcete. Slabina je zrcadlová: jezero samo o sobě nedává odpovědi, jen skladuje. Bez disciplíny se změní v „data swamp” — bažinu souborů, ve kterých se po roce nikdo nevyzná.

Kdo na něm jede. Vzor vznikl v éře Hadoopu u internetových gigantů, kteří potřebovali ukládat petabajty logů dřív, než věděli, k čemu je použijí. Dnes se čisté jezero samostatně vidí zřídka — přežívá jako vstupní a archivní vrstva větších architektur.

Pro koho. Jako samostatná architektura téměř pro nikoho; jako levný archiv surových dat pod skladem nebo lakehousem — běžná praxe.

Lakehouse: sklad postavený na jezeře

Co to je. Na první pohled protimluv: sklad postavený na jezeře. Data leží v levném objektovém úložišti jako soubory — jenže soubory samy o sobě neumějí to, co databáze. Když do nich zapisují dvě úlohy najednou, vznikne poškozený dataset; když potřebujete opravit jeden řádek, přepisujete celé soubory; a nikdo vám nezaručí, že v nich za půl roku bude stejná struktura. Přesně tohle řeší transakční vrstva — Delta Lake nebo Apache Iceberg. Nad soubory vede záznam změn, a tím jim dodá chování databázových tabulek: transakce, vynucené schéma, běžné UPDATE — a návrat k libovolné historické verzi dat, takzvaný „time travel”. SQL dotaz pak nevidí hromadu souborů, ale obyčejnou tabulku.

Druhá polovina principu: úložiště je oddělené od výpočtů. Data leží jednou a levně, výpočetní výkon si připojujete podle potřeby — ráno reporting, přes den analýzy, v noci trénink ML modelu, všechno nad toutéž jedinou kopií dat. Uvnitř se data typicky vedou medailonovými vrstvami; ostatně právě z lakehouse světa ten termín pochází.

Silné stránky. Škáluje na objemy, které relační databázi položí, a BI s ML běží nad jedněmi daty. Slabina: cloudové účtování podle spotřeby umí překvapit a platforma si žádá inženýry.

Kdo na něm jede — a proč ho miluje fintech. Coinbase skóruje transakce proti podvodům v reálném čase: ML modely počítají stovky příznaků a rozhodují v desítkách milisekund — nad stejnou platformou, nad kterou běží běžný reporting. Digitální banka Nubank na jedné lakehouse platformě obsluhuje tisíce interních uživatelů dat. Fintech je pro lakehouse ideální kombinace požadavků: obrovský tok transakcí, ML v reálném čase a regulatorika, která vyžaduje nezměnitelnou, auditovatelnou historii — tři věci, které jinde musíte skládat ze tří systémů, tady dostanete v jedné.

Pro koho. Firmy, kterým objem nebo povaha dat přerostly relační databázi, a ty, co vedle reportingu potřebují ML. U nás je to varianta Pro na Azure Databricks — vzor vrstev zůstává stejný jako u skladu, mění se platforma pod ním.

Data mesh: organizace, ne technologie

Co to je. Jediná ze čtveřice, která není o technologii, ale o lidech. Data mesh stojí na čtyřech principech. Za prvé: data vlastní domény, ne centrální tým — o datech zásilek rozhoduje logistika, o datech kampaní marketing, protože jim rozumějí nejlíp. Za druhé: data jsou produkt — doména je nepouští dál jako náhodný export, ale jako udržovanou věc s dokumentací, garantovanou kvalitou a jasným vlastníkem; ostatní týmy je konzumují jako interní službu, bez fronty na centrální tým. Za třetí: společná samoobslužná platforma, aby si každá doména nestavěla vlastní infrastrukturu. A za čtvrté: federativní pravidla — bezpečnost, formáty a standardy platí pro všechny, ale vymáhá je platforma automaticky, ne úřad s razítkem.

Technologie pod tím může být sklad i lakehouse — mesh neříká, v čem data jsou, ale kdo za ně odpovídá.

Silné stránky. Řeší úzké hrdlo, které nastane, když jeden centrální tým obsluhuje desítky týmů. Slabina: vyžaduje, aby každá doména měla lidi schopné za data odpovídat — a to je drahé.

Kdo na něm jede — a proč je to Uber. Uber spravuje přes exabajt dat a jeho datovou platformu používá víc než deset tisíc interních uživatelů. Žádný centrální tým na světě takový provoz neobslouží — proto Uber popsal ve svém inženýrském blogu vlastní vrstvu DataMesh: domény vlastní své datové produkty, platforma jim dává společnou infrastrukturu a pravidla. Podobnou cestou prošlo Zalando: centrální data lake se stal úzkým hrdlem bez jasného vlastnictví, tak odpovědnost rozdělili mezi domény. V obou případech si všimněte pořadí: nejdřív bolest z měřítka, pak mesh. Ne naopak.

Pro koho. Organizace se stovkami lidí pracujících s daty a mnoha doménami. V malé firmě je mesh antipattern: rozdělí odpovědnost, kterou v pohodě nese jeden člověk, mezi pět lidí, kteří na ni nemají čas.

Srovnání v jedné tabulce

Architektura	Kdo na ní jede	Typický stack	Pro koho
Datový sklad	banky, retail, střední firmy a e-shopy	PostgreSQL + ELT + BI	strukturovaná data, řízení podle čísel, malý tým
Data lake	vstupní/archivní vrstva větších platforem	objektové úložiště	archiv surových dat, ne samostatné řešení
Lakehouse	Coinbase, Nubank — fintech a ML provozy	Databricks, Delta/Iceberg	velké objemy, ML + reporting nad jedněmi daty
Data mesh	Uber, Zalando	organizační model nad skladem či lakehousem	stovky datových lidí, mnoho domén

Klíčový závěr: většina firem skončí u principů lakehouse

Teď ta jasná odpověď. Když se podíváte, kam se obor posouvá, směr je jednoznačný: k principům lakehouse. Dat přibývá každé firmě, ML a AI přestávají být výsadou korporací a nikdo nechce provozovat dvě oddělené platformy — jednu pro reporting, druhou pro datovou vědu. Vrstvená cesta dat od surových záznamů k metrikám, transformace nad jedním úložištěm, reporting i ML nad těmi samými daty — tohle je dnes výchozí vzor, ne exotika. Proto na něm jede fintech a proto ho velcí hráči přestali zpochybňovat.

Podstatný je ale dovětek, který na konferencích zazní málokdy: většina firem potřebuje lakehouse principy, ne lakehouse platformu. Pro e-shop s gigabajty strukturovaných dat je plný Databricks zbytečný luxus — stejné principy (medailonové vrstvy, ELT, jeden zdroj pravdy pro všechny reporty) dostanete na PostgreSQL za zlomek nákladů. A v tom je celá pointa: když architekturu postavíte správně od začátku, růst znamená výměnu platformy pod ní, ne přestavbu. Sklad na PostgreSQL s vrstvami je zmenšený lakehouse; až data přerostou databázi, přenese se stejný vzor na Databricks — přesně takhle je postavená i cesta mezi naší variantou Growth a Pro. Špatná zpráva pro milovníky revolucí, dobrá pro rozpočty: správná volba dnes není „která architektura”, ale „jak velká implementace téže architektury”.

A proč jsme zastánci právě tohohle přístupu my? Protože stavíme obě měřítka — sklady na PostgreSQL pro e-shopy i lakehouse na Databricks pro firmy s velkými objemy — a vrstvená architektura je jediná věc, kterou jsme u žádného z nich nelitovali. Každé číslo v reportu se dá dohledat zpět ke zdroji, dnešní reporting a zítřejší ML stojí nad jedněmi daty, technologie pod tím jsou otevřené a data patří klientovi. A hlavně: viděli jsme dost firem, které po dvou letech bouraly špatně založený reporting a stavěly znovu. Tohle přesvědčení nemáme z konferencí — máme ho z projektů, které přežily růst svých majitelů.

Data mesh do tohohle obrázku nevstupuje jako konkurent — je to organizační nadstavba pro chvíli, kdy máte datových týmů tolik, že si šlapou na paty. A čisté jezero zůstává tím, čím je: levným vstupním patrem pod tím vším.

Jak se rozhodnout

Celé rozhodnutí se dá shrnout do tří otázek.

1. Jaká data máte? Pokud jde o strukturované tabulky z běžných systémů — e-shop, účetnictví, reklama — stačí datový sklad. Lakehouse začne dávat smysl ve chvíli, kdy k nim přibudou velké toky událostí, soubory nebo nestrukturovaný obsah.

2. Kdo se o data bude starat? Sklad na PostgreSQL uřídí jeden člověk vedle své běžné práce. Lakehouse předpokládá datový tým s inženýry. A data mesh dává smysl teprve tehdy, když datových týmů máte tolik, že si šlapou na paty.

3. K čemu data chcete? Pro reporting a řízení firmy podle čísel stačí sklad. Jakmile k tomu přibude strojové učení nad velkými objemy, míříte k lakehouse.

A jedna kontrolní otázka na závěr: řešíte bolest technickou, nebo organizační? Výkon a objemy vyřeší platforma. Vlastnictví dat a úzká hrdla mezi týmy vyřeší jen organizace — žádný nákup technologie to za vás neudělá. Záměna těchhle dvou bolestí je nejdražší omyl z celého seznamu.

Coinbase, Uber i český e-shop nakonec dělají totéž: stejné principy, jiná velikost implementace — podle vlastního měřítka a vlastní bolesti, ne podle konferenčních slajdů. Jak vypadá stavba, když vám vyjde sklad, popisujeme krok za krokem — a kolik co stojí, říkáme předem.

---

Nevíte, do které řádky patříte? Ozvěte se — projdeme vaše systémy a objemy a řekneme vám to na rovinu, i kdyby odpověď byla „zatím vám stačí Excel”.