Datová kvalita & Governance

Proč je datová kvalita kritická¶

Dashboard, kterému nikdo nevěří, je dražší než žádný dashboard. Lidé ho ignorují a rozhodují se podle intuice — nebo si dělají vlastní Excel. Viděli jsme to desítkykrát:

• Revenue se liší o 5% mezi finančním a obchodním reportem
• Duplicitní zákazníci — jeden zákazník ve 3 systémech pod 3 různými ID
• Chybějící data — 15% objednávek nemá vyplněnou kategorii, segmentace je nepoužitelná
• Zastaralá data — pipeline spadla před týdnem, nikdo si nevšiml

Data quality není nice-to-have. Je to prerequisite pro jakoukoliv datovou iniciativu — BI, analytics, AI/ML.

Data Quality Framework¶

6 dimenzí kvality¶

Pro každý dataset měříme a hlídáme:

1. Completeness — Jaký podíl hodnot chybí? Threshold per sloupec (např. email: max 2% null)
2. Consistency — Shodují se data mezi zdroji? Zákazník v CRM = zákazník v ERP?
3. Accuracy — Jsou hodnoty správné? PSČ existuje? Datum je v minulosti, ne v roce 2087?
4. Timeliness — Jak čerstvá jsou data? SLA: objednávky do 5 minut, finanční data do 1 hodiny
5. Uniqueness — Existují duplicity? Detekce fuzzy duplicit (Novák Jan vs. Jan Novák)
6. Validity — Odpovídají hodnoty definovanému formátu a rozsahu? Email má @, věk je 0-150

Automatizované quality checks¶

Quality checks běží automaticky jako součást každé pipeline:

• dbt tests: Schema validace (unique, not_null, accepted_values, relationships)
• Great Expectations: Komplexní datové testy s human-readable dokumentací
• Custom validators: Business-specific pravidla (suma objednávky > 0, datum dodání > datum objednávky)
• Anomaly detection: Statistické anomálie v objemu, distribuci, trendech

Když quality check selže: - Pipeline se zastaví (raději žádná data než špatná data) - Alert do Slacku/Teams s detailem problému - Failed records jdou do karantény pro review - Quality incident se zaloguje s root cause a resolution

Quality dashboard¶

Centrální přehled kvality všech datasetů: - Quality score per dataset (agregace 6 dimenzí) - Trend v čase — kvalita se zlepšuje nebo zhoršuje? - Top issues — které problémy mají největší dopad? - SLA compliance — kolik datasetů splňuje definované SLA?

Data Governance¶

Ownership model¶

Každý dataset má definovaného: - Data Owner — business zodpovědnost (kdo definuje, co data znamenají) - Data Steward — operativní zodpovědnost (kdo řeší quality issues) - Technical Owner — technická zodpovědnost (kdo spravuje pipeline)

Data Contracts¶

Formální dohoda mezi producentem a konzumentem:

contract:
  name: orders-v2
  owner: team-ecommerce
  schema:
    - name: order_id
      type: string
      constraints: [not_null, unique]
    - name: total_amount
      type: decimal(10,2)
      constraints: [not_null, positive]
  quality:
    completeness: ">99%"
    freshness: "<5 minutes"
  sla:
    availability: "99.9%"
    support: "business-hours"

Breaking change = nová verze contractu + notification všem konzumentům + migration period.

Data Lineage¶

Automaticky trackujeme cestu dat od zdroje po konzumenta:

• Odkud data přišla — zdrojový systém, tabulka, API endpoint
• Jak se transformovala — které pipeline, jaké transformace, jaké filtry
• Kam putuje — které dashboardy, modely, reporty data konzumují
• Impact analysis — změna ve zdroji → které downstream systémy jsou ovlivněny?

Nástroje: dbt lineage, DataHub, Apache Atlas, OpenLineage.

Datový katalog¶

Centrální místo pro discovery a dokumentaci dat:

• Search & discovery — analytik hledá „monthly revenue” → najde definici, vlastníka, quality score
• Business glossary — jednotné definice business termínů
• Data dictionary — technický popis tabulek a sloupců
• Usage analytics — které datasety se používají, které ne
• Collaboration — komentáře, otázky, rating

GDPR a compliance¶

Personal Data Management¶

• PII detection: Automatická klasifikace sloupců obsahujících osobní údaje
• Data masking: Pseudonymizace PII v development a testing prostředích
• Encryption: At-rest a in-transit šifrování pro citlivá data
• Access control: RBAC — přístup k PII pouze pro autorizované role

Right to be Forgotten¶

Automatizovaný pipeline pro mazání osobních údajů: 1. Request přijde přes API/formulář 2. Identifikace všech výskytů osoby napříč platformou (lineage) 3. Anonymizace/smazání ve všech systémech 4. Audit log jako důkaz compliance 5. Konfirmace žadateli

Retention Policies¶

• Automatické mazání/archivace dat po uplynutí retention period
• Per-dataset konfigurace (finanční data: 10 let, logy: 90 dní, marketingová data: 2 roky)
• Audit trail retention operací

Implementační postup¶

1. Assessment (1-2 týdny): Audit současného stavu — kde jsou největší quality problémy? Existuje governance? Kdo vlastní data?
2. Framework setup (2-3 týdny): Quality checks, monitoring, alerting. Ownership model. Prvních 5-10 datasetů pod governance.
3. Katalog a lineage (2-4 týdny): Nasazení datového katalogu, automatický lineage, dokumentace klíčových datasetů.
4. Škálování (ongoing): Postupné rozšíření na všechny datasety. Školení data stewardů. Continuous improvement.

Souvisí s