Doteď jsme databázi brali jako místo, které obsluhuje aplikaci — rychlé malé dotazy „dej mi uživatele 5", „ulož objednávku". Ale data se taky potřebují analyzovat: kolik jsme prodali za měsíc, jak se chovají uživatelé, podklady pro reporty a ML. To je úplně jiná práce a dělá se jinými nástroji. Tahle kapitola vysvětlí ten rozdíl a základ datového světa kolem backendu.
Pár pojmů na úvod
- OLTP (Online Transaction Processing) = databáze obsluhující aplikaci (rychlé malé operace).
- OLAP (Online Analytical Processing) = zpracování pro analýzu (velké agregující dotazy).
- Data warehouse = úložiště optimalizované na analýzu velkého množství dat.
- ETL / ELT = přesun dat z různých zdrojů (provozní DB, logy, cizí systémy) do warehouse. ETL = Extract → Transform → Load; ELT prohodí pořadí (nahraj syrově, transformuj až ve warehouse).
- Batch vs stream = zpracování po dávkách vs průběžně, jak data přitékají.
OLTP vs OLAP — dva úplně různé úkoly
Tohle rozlišení je základ. Stejná data, ale dvě naprosto odlišné práce:
| OLTP (obsluha aplikace) | OLAP (analýza) | |
|---|---|---|
| Typický dotaz | „dej mi objednávku #42" | „kolik jsme prodali po měsících za 3 roky" |
| Velikost dotazů | Hodně malých | Málo, ale obří (přes miliony řádků) |
| Operace | Čtení i zápis | Skoro jen čtení, agregace |
| Optimalizace | Rychlá odezva | Velký průchod dat |
| Příklady | Postgres, MySQL | BigQuery, Snowflake, ClickHouse |
⚠️ Nepouštěj těžké analytické dotazy na svoji provozní (OLTP) databázi! Jeden report přes miliony řádků dokáže databázi zahltit tak, že začne brzdit celá aplikace. Analytika patří jinam — do warehouse.
Proč jsou OLAP nástroje na agregace tak rychlé? Sloupcové uložení (columnar). Běžná OLTP databáze
ukládá data po řádcích (celý záznam pohromadě — ideální, když potřebuješ celý řádek). OLAP nástroje
(BigQuery, Snowflake, ClickHouse) ukládají data po sloupcích. Když počítáš „průměr ceny přes
miliardu objednávek", přečteš jen sloupec cena a nic dalšího — místo abys tahal celé řádky. To je
hlavní důvod, proč zvládají agregace, na kterých by se řádkově uložená databáze zadusila.
Data warehouse a jak se tam data dostanou (ETL)
Data warehouse je samostatné úložiště navržené přesně na analytiku — zvládne obří agregace nad spoustou dat, ale není stavěné na obsluhu appky. Data se do něj kopírují z provozních databází (a dalších zdrojů) procesem ETL:
- Extract — vytáhni data ze zdrojů.
- Transform — pročisti a převeď do tvaru vhodného na analýzu.
- Load — nahraj do warehouse.
(Někdy se pořadí prohodí na ELT — nahraje se syrově a transformuje až ve warehouse.) Tím se oddělí provoz od analytiky: appka jede na svém OLTP a reporty se počítají vedle, aniž by si navzájem překážely.
Jak se data reálně tahají: ne plným kopírováním pokaždé (drahé), ale inkrementálně — jen to, co přibylo/změnilo se. Často přes CDC (Change Data Capture) ze změnového logu databáze, takže neotravuješ produkci dotazy. A protože job poběží i víckrát (selhání, backfill historie), musí být idempotentní (dvojí běh nezdvojí data).
Senior bere data jako produkt: hlídá data quality (kontroly schématu, čerstvosti, počtů řádků, anomálií — ať se tichá chyba pozná) a lineage (odkud číslo v reportu pochází a co se přepočítá při změně). Reportům se totiž věří a rozhoduje se podle nich.
Batch vs stream processing
Dva způsoby, jak data zpracovávat:
- Batch (dávkově) — sesbíráš velkou hromadu dat a zpracuješ ji najednou, periodicky (např. každou noc přepočítáš denní statistiky). Jednoduché, efektivní, ale výsledek je se zpožděním.
- Stream (proudově) — zpracováváš události průběžně, jak přitékají (živé počítadlo, detekce podvodu v reálném čase). Aktuální, ale složitější. Staví na frontách a Kafce.
Pravidlo: když stačí „do druhého dne", dělej batch (levnější a jednodušší). Stream nasaď, jen když opravdu potřebuješ výsledek hned.
Failure modes — jak to v praxi praská
- Analytika na provozní databázi → jeden report položí celou aplikaci.
- Žádné oddělení OLTP/OLAP → škálování se rve mezi appkou a reporty.
- Stream tam, kde stačil batch → zbytečná složitost a náklady.
- ETL bez hlídání → tichá chyba v transformaci → špatná čísla v reportech, kterým se pak věří.
🛠️ Cvičení
- OLTP, nebo OLAP? Zařaď dotazy: „přihlas uživatele", „spočítej průměrnou útratu na zákazníka za rok", „ulož objednávku", „top 10 produktů za kvartál". Kam který patří a proč.
- Proč ne na provozní DB. Vysvětli na příkladu, co se stane, když pustíš roční agregaci přes miliony řádků přímo na produkční Postgres.
- Navrhni tok dat. Nakresli, jak se data z appky dostanou do reportů (OLTP → ETL → warehouse → dashboard).
- Batch, nebo stream? Rozhodni a zdůvodni: noční přehled tržeb, detekce podvodné platby, měsíční faktury, živý počet diváků streamu.
- ETL chyba. Vymysli, jak by tichá chyba v kroku „transform" mohla vést ke špatným číslům, a jak bys to odhalil.
Náčrt řešení — rozbal, až si cvičení zkusíš sám
- OLTP, nebo OLAP — pointa: „přihlas uživatele" a „ulož objednávku" jsou malé rychlé operace obsluhující appku (OLTP); „průměrná útrata za rok" a „top 10 za kvartál" jsou obří agregace (OLAP). Pozor: rozhoduje, jestli jde o malou operaci nad appkou, nebo agregaci přes spoustu řádků — to určí i nástroj (Postgres vs warehouse).
- Proč ne na provozní DB — pointa: roční agregace přes miliony řádků udělá velký průchod dat a zahltí OLTP databázi tak, že začne brzdit celá aplikace. Pozor: report tím připraví reálné uživatele o výkon, proto analytika patří do warehouse, ne na produkční Postgres.
- Navrhni tok dat — pointa: data jdou z OLTP databáze přes ETL (extract → transform → load) do warehouse a odtud do reportů/dashboardů; tím se oddělí provoz od analytiky. Pozor: tahej inkrementálně (často přes CDC), ne plným kopírováním, a job měj idempotentní (dvojí běh nezdvojí data).
- Batch, nebo stream — pointa: noční přehled tržeb a měsíční faktury stačí dávkově (batch), detekce podvodné platby a živý počet diváků potřebuje výsledek hned (stream). Pozor: stream je dražší a složitější, ber ho jen když „do druhého dne" nestačí.
- ETL chyba — pointa: tichá chyba v „transform" (špatný výpočet, vypadlé řádky) vyrobí věrohodně vypadající, ale špatná čísla, kterým se v reportech věří. Pozor: odhalíš to jen monitoringem a kontrolami data quality (počty řádků, schéma, čerstvost, anomálie) — sama o sobě se neprozradí.
🧠 Otázky & odpovědi
Jaký je rozdíl mezi OLTP a OLAP?
OLTP je databáze obsluhující aplikaci — hodně malých rychlých operací (čtení i zápis), např. „dej mi objednávku #42". OLAP je zpracování pro analýzu — málo, ale obřích agregujících dotazů přes miliony řádků, např. „kolik jsme prodali po měsících za 3 roky". Jsou to dva různé úkoly, optimalizované opačně, a dělají se jinými nástroji (Postgres vs BigQuery/Snowflake/ClickHouse).
Proč nepouštět analytické dotazy na provozní databázi?
Protože těžký analytický dotaz přes miliony řádků dokáže provozní (OLTP) databázi zahltit natolik, že začne brzdit celá aplikace — report tím připraví reálné uživatele o výkon. Analytika patří jinam, do data warehouse, kam se data zkopírují, takže provoz a reporty si navzájem nepřekážejí.
Co je ETL a k čemu data warehouse?
Data warehouse je úložiště optimalizované na analytiku (obří agregace), ne na obsluhu appky. Data se do něj kopírují z provozních databází a dalších zdrojů procesem ETL: Extract (vytáhni), Transform (pročisti a převeď do vhodného tvaru), Load (nahraj). Tím se oddělí provoz od analytiky — appka jede na svém OLTP a reporty se počítají vedle.
Kdy zvolit batch a kdy stream processing?
Batch (dávkově, periodicky) zvol, když stačí výsledek se zpožděním — třeba noční přepočet denních statistik. Je jednodušší a levnější. Stream (průběžně, jak data přitékají) zvol, jen když opravdu potřebuješ výsledek hned — živé počítadlo, detekce podvodu v reálném čase. Stream je aktuálnější, ale složitější a dražší, tak ho neber, když batch stačí.
Proč je nebezpečná tichá chyba v ETL?
Protože reportům a dashboardům se věří a rozhodují se podle nich. Když se v kroku „transform" něco potichu pokazí (špatně se spočítá, vypadnou řádky), čísla vypadají věrohodně, ale jsou špatná — a nikdo to nepozná, dokud se podle nich neudělá špatné rozhodnutí. Proto se i datové pipeline musí monitorovat a ověřovat (kontroly počtů, testy).