ETL s 50+ zdroji: jak zautomatizovat schema drift a quality gates

„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 tvé 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: Source team přidá sloupec, ty o tom nevíš

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. Tvůj ETL SELECT * najednou vrací o sloupec víc, schema drift breaks 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 (stored as 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: Data quality gates před loadem

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: Observability přes 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 network hiccup 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íš, kde skončil, pokračuj. Rychlé, ale musíš 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-runneš, už loaded řádky se overwritnou identicky (no-op), nové přibudou. Deterministický, bezpečný.

Problém 5: Contract testing s source teams

Nejlepší case: source team předem řekne „mění se schema, upravte ETL“. Střední case: zjistíš to z schema validátoru. Nejhorší case: zjistíš to 3 dny po change z quality gate alertu.

Contract testing formalizuje expectations:

• Mezi source team a DWH týmem je YAML file s expected schema + invariants (na constraint úrovni, ne jen types)
• Source team CI běží tento contract test proti testing environment 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 3rd-party sources (external APIs, CSV feeds). Tam zůstává schema validator + quality gates. Ale pro interní source systémy je contract testing game-changer.

Magistra implementation

Po 6 měsících provozu:

• 52 source systems, 140+ ETL pipelines
• 18 schema drift alertů za 6 měsíců — 15 neblokujících, 3 vyžadovaly úpravu ETL
• Quality gate fails ~2× týdně — většinou transient issues (source system migrace)
• Mean time to detection pro data corruption: < 2 hodiny (proti ~3 dny předtím)
• Contract testing s 4 interními source teams (remaining 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 tvá 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 end result

Plus contract testing s interními source teams, pokud je to politicky možné. Tohle celé není luxury — pro 50+ source systems je to minimum.