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).