„Máme 50 zdrojových systémů.“ Když tohle slyším na kickoff, vím, že největší pain point nebudou transformace. Bude to schema drift — zdrojové systémy se mění bez varování a vaše ETL pipelines padají v 3 ráno, když se někdo v SAPu ráno rozhodl přidat sloupec.
Pro Magistru (50+ zdrojů: lékárny, e-shop, HR systém, DNS servery, externí CSV feeds, SOAP APIs…) jsme museli tohle vyřešit pipeline-first. Tady je, co funguje.
Problém 1: Tým zdrojového systému přidá sloupec, vy o tom nevíte
Lékárenský systém v 200 pobočkách přidá sloupec `loyalty_tier` na customer tabulku. Source team to neřekne DWH týmu — proč by měl, jejich systém funguje. Váš ETL SELECT * najednou vrací o sloupec víc, schema drift rozbije cokoli downstream.
Řešení: explicit schema declaration v ETL kódu, ne SELECT *:
-- Zdroj: pharmacies_customer SELECT customer_id, -- INT NOT NULL full_name, -- VARCHAR(200) email, -- VARCHAR(200) NULL registered_at -- TIMESTAMP FROM pharmacies_customer WHERE updated_at > :last_load_time
Když source přidá `loyalty_tier`, náš SELECT ho neberu, ale pipeline funguje. Source team má 30 dní na to oznámit změnu. Jinak nové pole zmeškáme, ne ale celý load.
Schema validator běží nad source systémem 1× denně. Porovnává aktuální schema s očekávaným (uloženým jako YAML v repository). Diff = alert. „V pharmacies_customer je nový sloupec loyalty_tier. Mám ho přidat do DWH nebo ignorovat?“ Lidská volba, ne automatická.
Problém 2: Kontroly kvality dat před nahráním
Nová verze e-shop exportu obsahuje 30 % řádků s prázdným `customer_email`. V předchozích exports to bylo 2 %. Něco se děje na source straně. Loadnout to bez kontroly = znečištění DWH.
Quality gates na každém zdroji:
- Row count: je aktuální load v rozumném rozsahu proti poslednímu měsíci? (±30 %)
- Null rate per critical column: customer_id nesmí mít > 0 %, email < 5 %
- Referential integrity: všechny order.customer_id musí existovat v customer tabulce
- Business invariants: součet pricing sloupců = total, data consistency mezi tabulkami
Gate fail = load se zastaví, alert jde lidem, do DWH nic nezmění. Předchází to tomu, aby CFO se díval na dashboard a viděl 30 % zákazníků bez e-mailu, protože se rozbilo na source straně a my jsme to ochotně přenesli.
Problém 3: Monitoring napříč celou pipeline
Data projdou 5 vrstev: source pull → staging → raw → enriched → presentation. Když se v presentation objeví divná čísla, kde je problém?
Metric per stage:
- Rows in, rows out, rows rejected (quality gate)
- Stage duration (p50, p99)
- Error count, error types
- Data freshness (latest timestamp v každé tabulce)
Všechno do centrálního observability (v Magistra používáme Application Insights + custom dashboards v Power BI — ano, monitoring data platformy jede v ní samé).
Problém 4: Idempotentní re-runy
Tu noc ETL pipeline padne uprostřed, protože výpadek sítě na source DB. Co teď? Dva extrémy:
- Restart from scratch — mažeme target data a load znovu. Pro velké tabulky (miliony řádků) hodiny práce.
- Resume from checkpoint — pokud víte, kde skončil, pokračujte. Rychlé, ale musíte zaručit idempotenci.
Řešení: upsert s deterministic keys. Každý ETL write je MERGE INTO target USING source ON target.key = source.key WHEN MATCHED UPDATE... WHEN NOT MATCHED INSERT.... Když pipeline re-runnete, už loaded řádky se overwritnou identicky (no-op), nové přibudou. Deterministický, bezpečný.
Problém 5: Testy kontraktů s týmy zdrojových systémů
Nejlepší scénář: source team předem řekne „mění se schema, upravte ETL“. Střední scénář: zjistíte to z schema validátoru. Nejhorší scénář: zjistíte to 3 dny po změně z quality gate alertu.
Contract testing formalizuje očekávání:
- Mezi source team a DWH týmem je YAML soubor s očekávaným schématem a invarianty (na úrovni constraintů, ne jen typů)
- Source team CI běží tento contract test proti testovacímu prostředí před deployem — pokud by změna breakla DWH contract, deploy se blokuje
- Lepší než SNS alert: source team vidí v jejich CI, že by downstream rozbil, a mluví s DWH týmem před, ne po
Tohle nefunguje u zdrojů třetích stran (externí API, CSV feedy). Tam zůstává schema validator + quality gates. Ale pro interní source systémy je contract testing zlomový bod.
Magistra v praxi
Po 6 měsících provozu:
- 52 source systémů, 140+ ETL pipelines
- 18 schema drift alertů za 6 měsíců — 15 neblokujících, 3 vyžadovaly úpravu ETL
- Quality gate selhání ~2× týdně — většinou přechodné problémy (source system migrace)
- Mean time to detection pro data corruption: < 2 hodiny (proti ~3 dny předtím)
- Contract testing se 4 interními source týmy (zbývajících 8 je legacy, postupně migrujeme)
Co si z toho vzít
ETL s mnoha zdroji není o tom umět dělat transformace. Je o tom vědět, kdy je něco rozbité. Bez toho vaše DWH pomalu naakumuluje bad data a jednoho dne CFO zjistí, že čísla jsou špatná po 3 měsíce. Oprava zpětně = horor.
Tří pilíře:
- Explicit schema v ETL kódu, ne SELECT *
- Quality gates na vstupu každého zdroje
- Observability z každé stage, ne jen konečný výsledek
Plus contract testing s interními source teams, pokud je to politicky možné. Tohle celé není luxus — pro 50+ source systémů je to minimum.