Principy datových skladů

Proč datový sklad a jaké problémy řeší

Datový sklad (Data Warehouse, DWH) je integrované, předmětově orientované, časově proměnlivé a nezměnitelné úložiště, které konsoliduje data z heterogenních zdrojů a zpřístupňuje je pro rozhodování. Oproti provozním systémům (OLTP) klade důraz na analytické dotazy, historizaci, konzistenci definic metrik a rychlou dostupnost informací. Tvorba DWH vyžaduje disciplínu v datovém modelování, integraci, řízení kvality a governance, jinak hrozí „spreadsheet chaos“, lokální pravdy a drahé point-to-point datové toky.

Architektonické přístupy: Inmon, Kimball, Data Vault a Lakehouse

• Inmon (Corporate Information Factory): enterprise 3NF integrační vrstva (EDW) → datamarty. Silná integrita, komplexnější model.
• Kimball (Dimenzionální model): byznysově orientované fact/dimension schéma, bus matrix, konformní dimenze; rychlý time-to-value.
• Data Vault 2.0: Hubs–Links–Satellites, auditovatelnost, flexibilní historizace, odolnost vůči změnám zdrojů; nad tím dimenzionální prezentace.
• Lakehouse: jednotné úložiště pro „raw/curated/serving“ vrstvy na souborových formátech (Parquet/ORC) s transakčním logem; kombinuje data lake a DWH vlastnosti.

Referenční vrstvení: od zdroje k reportu

• Staging (Raw): přebírá data as-is, ukládá landing snímky, change data capture (CDC), minimalizuje transformace.
• Integration/Core: očištěná, sjednocená data, historizace, podnikové entity; Data Vault / 3NF / dimenzionální „core“.
• Semantic/Serving: datamarty ve star nebo snowflake schématu, agregace, pohledy pro BI a samoobsluhu.

Dimenzionální modelování: bus matrix, grain a konformní dimenze

• Bus matrix: mapa byznys procesů (fakta) × sdílené dimenze; řídí konzistenci napříč doménami.
• Grain (zrna fact tabulek): nejnižší úroveň detailu (např. položka dokladu vs. denní agregát); volba ovlivňuje objem a dotazy.
• Konformní dimenze: sdílené dimenze (Zákazník, Produkt, Čas) s jednotnými klíči a atributy pro srovnatelnost metrik.
• Typy faktů: aditivní (prodej), semi-aditivní (stav zásob), neaditivní (poměry); fakt tabulky transakční, snapshot, akumulující.

Historie a změny: Slowly Changing Dimensions (SCD)

• SCD0: beze změny (přepis).
• SCD1: přepis hodnot (bez historie).
• SCD2: plná historie (datum valid-from/valid-to, příznak aktuálnosti).
• SCD3/4/6: alternativy (omezená historie ve sloupcích, historická tabulka, kombinace 1+2).

Identifikace záznamů: natural vs. surrogate keys

Pro dimenze používejte surrogate keys (číselné identifikátory) pro stabilitu odkazů a efektivní joiny. Natural keys (ze zdrojů) ukládejte pro business key a deduplikaci. U SCD2 má každá verze stejný business key, ale jiný surrogate key.

ETL vs. ELT a datové toky

• ETL: transformace před nahráním (typické pro klasické DWH nástroje).
• ELT: nahrát do výkonné platformy (cloud DWH/lakehouse) a transformovat SQL/enginem; lepší škálování, push-down optimalizace.
• CDC: log-based (binlog/redo), timestamp, diff snímky; důležité pro near-real-time aktualizace.
• Batch vs. stream: dávky pro plánované zpracování; stream (event-driven) pro nízkou latenci a up-to-date metriky.

Datová kvalita: pravidla, profilace a monitorování

• Pravidla DQ: úplnost, platnost, unikátnost, konzistence, včasnost; thresholdy a SLI/SLO pro kvalitu.
• Profilace: statistiky distribučních tvarů, kardinality, anomálií; baseline pro detekci odchylek.
• Validace v pipeline: unit/integration testy SQL, kontrakty schémat (např. schema registry u streamu).

Metadata, katalog a data lineage

• Technická a byznysová metadata: definice metrik, slovník pojmů, původ dat (lineage), vlastnictví (data ownership).
• Data Catalog: vyhledávání datasetů, klasifikace citlivosti, hodnocení kvality, recenze uživatelů.
• Lineage: sledování transformací od zdroje po report pro audit, dopadové analýzy a řešení incidentů.

Bezpečnost, přístup a ochrana soukromí

• IAM: RBAC/ABAC, princip nejmenších oprávnění, row/column-level zabezpečení, data masking.
• Šifrování: v klidu a přenosu, customer-managed keys; auditní logy přístupů.
• Soukromí: minimalizace dat, pseudonymizace/anonymizace, retenční politiky, soulad s regulacemi (např. GDPR).

Výkon a fyzická vrstva: sloupcové formáty, particionace, cache

• Formáty: sloupcové uložení (Parquet/ORC) a komprese pro skeny a agregace; pro DWH enginy nativní sloupcové segmenty.
• Particionace a clustering: podle data, entity, oblasti; data skipping, z-ordering, sort keys.
• Materializace: materializované pohledy, agregace po čase, roll-up tabulky, result cache pro opakované dotazy.
• Konkurence a kvóty: warehouse pooly, workload management, query governor.

Semantická vrstva a samoobslužná analytika

• Semantic layer: jednotné definice metrik (např. MRR, ARPU), dimenzí a výpočtů pro celý BI ekosystém.
• Data marts: doménové kostry (sales, finance, marketing) optimalizované pro reporty a ad-hoc analýzy.
• OLAP: „thin models“ na sloupcových enginech vs. předpočítané kostky; volba dle latence a variability dotazů.

Orchestrace, plánování a DevOps pro DWH

• Orchestrace: DAG nástroje (závislosti, retries, SLA), event-driven spouštění.
• Versioning a IaC: SQL/transformace ve gitu, infrastructure-as-code, migrační skripty schémat.
• CI/CD: testy transformací, data diffs, izolovaná prostředí (dev/test/prod), blue-green publikace pohledů.
• Observabilita: metriky pipeline (průtok, latence), data freshness, data downtime, alerting.

FinOps: řízení nákladů a efektivity

• Tagování a chargeback: náklady podle domén/týmů, rozpočty, showback.
• Optimalizace dotazů: limitování skenů, pruning partií, recyklace výsledků, result-set cache.
• Životní cyklus dat: TTL, archivace do levnější vrstvy, cold/warm/hot strategie.

Kritické principy návrhu (shrnutí)

1. Začněte byznys doménou: definujte metriky, zdrojové systémy, bus matrix a konformní dimenze.
2. Zvolte model jádra: dimenzionální, Data Vault nebo hybrid; dokumentujte grain a SCD strategii.
3. Řiďte kvalitu: pravidla DQ, monitorování, automatické testy v pipeline.
4. Udržujte lineage a katalog: vyhledatelnost, audit, dopadové analýzy.
5. Měřte a optimalizujte: p95/p99 latence dotazů, náklady na sken/uživatele, freshness dat.

Typické anti-patterny a jak se jim vyhnout

• ETL „na míru“ pro každý report: vede k duplicitám a nekonzistenci; standardizujte vrstvu core a sdílené dimenze.
• Bez SCD politiky: míchání aktuálních a historických hodnot; vždy definujte, co je „stav k datu“.
• „Schema-on-read“ bez governance: různé definice metrik; zaveďte semantickou vrstvu a datový slovník.
• Příliš brzká agregace: ztráta detailu a nemožnost re-analýzy; agregujte až v serving vrstvě.
• Neregulované náklady: neomezené skeny; nastavte kvóty, warehouses a pravidla pro účty.

Kontrolní seznam před go-live

• Definované POV (purpose of value), metriky a jejich vzorce; schválené vlastníky dat.
• Implementovaná SCD, DQ pravidla, alerty a lineage.
• Testy výkonu a nákladové limity; nastavené SLA/SLO pro freshness a dostupnost.
• Bezpečnost: RBAC, maskování, šifrování, audit, retenční policy.
• Orchestrace: DAG závislosti, retries, backfill, postupy obnovy (DR).

Závěr: datový sklad jako produkt

Úspěšný datový sklad není jednorázový projekt, ale produkt s jasnou hodnotou, vlastníky, roadmapou a měřením přínosů. Kombinace robustní integrační vrstvy, srozumitelné semantiky, řízené kvality a škálovatelné fyzické platformy poskytuje podniku jediný důvěryhodný zdroj pravdy a zkracuje cestu od dat k rozhodnutí.