Datový sklad & Lakehouse

Proč centralizovat data do warehouse/lakehouse¶

Typický podnik má data roztroušená v desítkách systémů — ERP, CRM, e-shop, HR systém, Excel soubory, Google Sheets, API třetích stran. Každý systém má vlastní formát, vlastní definice, vlastní historii. Výsledek:

• Management nedostane odpověď na jednoduchou otázku — „Jaký byl revenue tento měsíc?” vyžaduje 3 dny práce analytika
• Čísla se neshodují — obchod reportuje jinak než finance, nikdo neví co je pravda
• Historická data chybí — zdrojové systémy mažou nebo přepisují, žádný audit trail
• AI/ML nemá data — modely potřebují konsolidovaná, čistá data na jednom místě

Warehouse vs. Lakehouse vs. Lake¶

Data Warehouse (Snowflake, BigQuery, Redshift)¶

Pro koho: Firmy se strukturovanými daty, primární potřeba je BI a reporting.

• Schéma definované předem (schema-on-write)
• Optimalizováno pro SQL dotazy a agregace
• ACID transakce, time travel, zero-copy cloning
• Managed service — žádná infrastruktura k údržbě
• Nejvyšší výkon pro analytické dotazy

Data Lakehouse (Databricks, Delta Lake, Apache Iceberg)¶

Pro koho: Firmy s mixem strukturovaných a nestrukturovaných dat, ML/AI workloads.

• Otevřené formáty (Delta, Iceberg, Hudi) — žádný vendor lock-in
• Schema-on-read i schema-on-write
• Unified processing — SQL, Python, Spark, ML v jednom prostředí
• Cost-effective storage (object storage = S3/ADLS)
• ACID transakce nad data lake díky Delta/Iceberg

Data Lake (S3/ADLS raw)¶

Pro koho: Landing zone pro raw data, archivace, specifické ML pipeline.

• Nejlevnější storage
• Žádná struktura — dump anything
• Bez Delta/Iceberg = žádné ACID, žádný time travel
• Typicky Bronze vrstva v Medallion architektuře

Jak vybíráme technologii¶

Neprodáváme jednu technologii. Volíme na základě vašich požadavků:

Snowflake volíme, když: primární use case je BI/reporting, tým zná SQL, potřebujete multi-cloud, data sharing mezi organizacemi, separace compute a storage je klíčová.

Databricks volíme, když: potřebujete ML/AI workloads vedle analytics, máte velké objemy nestrukturovaných dat, tým zná Python/Spark, chcete open-source formáty (Delta Lake).

BigQuery volíme, když: jste na Google Cloud, chcete serverless (žádný cluster management), pay-per-query model dává smysl pro vaše query patterny, potřebujete GIS/ML integraci.

PostgreSQL + dbt volíme, když: objem dat < 100 GB, rozpočet je omezený, tým zná PostgreSQL, nepotřebujete škálovat compute nezávisle na storage.

Implementační přístup¶

1. Discovery a data modeling (2-3 týdny)¶

• Inventarizace zdrojů a datových entit
• Dimensional modeling (Kimball) nebo Data Vault 2.0
• Source of truth definice pro klíčové entity
• Naming conventions, data types, standardy

2. Infrastruktura a ingestion (2-3 týdny)¶

• Provisioning warehouse/lakehouse (IaC — Terraform)
• Ingestion pipeline pro klíčové zdroje
• Bronze layer — raw data, immutable, partitioned
• Monitoring a alerting od prvního dne

3. Transformace a business layer (3-4 týdny)¶

• dbt project setup s CI/CD
• Silver layer — cleaning, validation, conforming
• Gold layer — business-ready views, KPI, metriky
• Semantic layer pro konzistentní definice

4. Optimalizace a hardening (ongoing)¶

• Query performance tuning (clustering, materialized views)
• Cost optimalizace (warehouse sizing, auto-suspend, resource monitors)
• Partitioning a pruning strategie
• Backup, DR, retention policies

Cost optimalizace¶

Cloudový warehouse bez governance rychle generuje nečekané náklady. Implementujeme:

• Resource monitors — automatické zastavení při dosažení budget limitu
• Auto-suspend/resume — warehouse neběží, když ho nikdo nepoužívá
• Query profiling — identifikace drahých dotazů, optimalizace
• Storage tiering — hot/warm/cold data na různých úrovních storage
• Reservation vs. on-demand — pro předvídatelné workloads reserved capacity ušetří 30-60%

Souvisí s