Proč potřebujeme plán kvality dat
Plán kvality dat je řídicí dokument, který stanovuje vlastnictví dat, přesnou definici metrik kvality a systematiku validací v datovém pipeline. Jeho cílem je zajistit, aby data byla spolehlivá, auditovatelná a použitelná pro analytiku, reporting, AI/ML a provozní procesy. Dokument tvoří základ pro datovou správu (data governance), kontrakty mezi producenty a spotřebiteli dat i pro SLA/SLO metriky, podle kterých se řídí provoz.
Rozsah a principy plánu
- Rozsah: zdrojové systémy, integrační vrstvy (ETL/ELT), datová skladiště/datová jezera, sémantická vrstva, reporty a API.
- Principy: „quality by design“, automatizace, měřitelnost, transparentnost, minimalismus v metrikách (méně, ale důležité), „shift-left“ validace při vstupu.
- Řízení rizika: soustředění na kritické datové domény (finance, zákazníci, soulad s regulací).
Model vlastnictví: role a odpovědnosti
Jasné vlastnictví eliminuje „bezprizorná data“ a urychluje řešení incidentů. Doporučený model:
- Data Owner (Biznis vlastník): schvaluje definice, prahové hodnoty a akceptační kritéria; rozhoduje o výjimkách.
- Data Steward: kurátor kvality; spravuje katalog, glosář a metriky; koordinuje nápravy.
- Data Custodian (IT/Platforma): zajišťuje infrastrukturu, automatizované testy a monitoring.
- Data Producer: tým zdrojové aplikace; garantuje kvalitu na vstupu a dodržování datových kontraktů.
- Data Consumer: BI/AI/provoz; hlásí odchylky, participuje na UAT a definici byznys pravidel.
RACI matice pro kvalitu dat
| Aktivita | Owner | Steward | Custodian | Producer | Consumer |
|---|---|---|---|---|---|
| Definice metrik | A | R | C | C | I |
| Nastavení validací | C | R | A | R | I |
| Monitoring a alerty | I | R | A | C | I |
| Incident management | A | R | R | C | C |
| Schvalování výjimek | A | R | C | C | I |
Glosář a datové kontrakty
Bez jednotného jazyka není stabilní kvalita. Plán vyžaduje:
- Byznys glosář: definice entit (zákazník, objednávka), agregací (výnos), periodicity a časové platnosti.
- Datové kontrakty: schémata, typy, povinná pole, kardinality, SLA na latenci a aktualizaci, pravidla verzování (schema evolution).
Taxonomie metrik kvality
- Přesnost (Accuracy): míra souladu s realitou nebo referenčním zdrojem.
- Úplnost (Completeness): podíl vyplněných povinných polí a záznamů.
- Jedinečnost (Uniqueness): absence duplicitních entit a klíčů.
- Platnost (Validity): soulad s doménami hodnot, regexy, typy, referenčními tabulkami.
- Konzistence (Consistency): soulad napříč systémy/vrstvami (např. sumy v DWH vs. ERP).
- Včasnost (Timeliness): zpoždění vůči dohodnuté latenci (SLA/SLO).
- Integrita (Integrity): referenční a transakční integrita (FK, bilance, rovnice).
- Traceability: sledovatelnost původu (lineage), auditní stopa transformací.
Šablona definice metrik (příklad)
| Název metriky | Definice | Vzorec | Zdroje | Prahy (Warn/Error) | Periodicita | Vlastník |
|---|---|---|---|---|---|---|
| Úplnost e-mailu zákazníka | Podíl řádků s ne-NULL a neprázdným e-mailem | (počet_validních / počet_všech) × 100 % | CRM.customers.email | 95 % / 90 % | denně | Data Steward – Doména Zákazník |
| Platnost formátu e-mailu | Shoda s regex vzorem RFC-like | počet_regex_ok / počet_všech | CRM.customers.email | 98 % / 95 % | denně | Data Steward – Doména Zákazník |
| Jedinečnost zákaznického ID | Podíl unikátních customer_id | count_distinct(customer_id) / count(*) | CRM.customers.customer_id | 100 % / 99,9 % | nepřetržitě | Owner – Komerční provoz |
Validace: typy testů a kde je spouštět
- Schémové testy: typy, povinnost polí, délky, enumy, primární klíče.
- Referenční testy: cizí klíče, mapování na referenční tabulky (země, měny).
- Byznys pravidla: doménové logiky (např. datum faktury ≤ datum dodání), rovnice, bilance.
- Distribuční/anomální testy: odchylky v histogramu, průměr/medián/σ, sezónnost.
- Lineage konzistence: kontrola zachování počtů a sum po transformacích (source→staging→DWH→mart).
- Contract testy na API/eventy: validace payloadů, verzí a zpětné kompatibility.
Životní cyklus datových validací
- Návrh: identifikace kritických polí a rizik; návrh pravidel a prahů.
- Implementace: infra testy v pipeline (ETL/ELT), build-time testy (CI), runtime monitoring.
- Kalibrace prahů: A/B porovnání, analýza historických rozdělení, sezónní výjimky.
- Provoz: alerty, dashboardy, incidenty, ticketing, nápravná opatření (CAPA).
- Revize: kvartální přehodnocení relevance pravidel a metrik.
Architektura monitorování kvality
- Observabilita dat: metriky objemu, čerstvosti, schémových změn, výpadků.
- Alerting: multiúrovňový (INFO/WARN/ERROR), on-call rotace, tichý režim pro plánované výpadky.
- Dashboardy: domény × metriky × SLA/SLO; drill-down na tabulky/sloupce.
- Audit trail: logy validací, verzování pravidel, podpisy release-ů, důkaz kontroly.
SLA, SLO a akceptační kritéria
- SLA (Service Level Agreement): závazná dostupnost a latence (např. „denní reporty do 08:00 s 99,5 % dostupností“).
- SLO (Service Level Objective): interní cíle kvality (např. „≥ 97 % úplnost klíčových polí“).
- Akceptační kritéria: explicitní prahy, nad kterými je dataset nasaditelný do produkce nebo report publikovatelný.
Řízení incidentů kvality dat
| Úroveň | Popis | Příklady | Reakce | MTTA/MTTR cíl |
|---|---|---|---|---|
| P1 – Kritický | Dopad na finanční/legální výstupy | Chybné výnosy v uzávěrce | Incident war-room, rollback, blokace publikace | 15 min / 4 h |
| P2 – Vysoký | Dopad na klíčové KPI | Nekonzistentní prodeje v DWH vs. ERP | Hotfix, korektivní skripty | 1 h / 1 den |
| P3 – Střední | Lokální anomálie | Chybějící hodnoty v menší subdoméně | Backlog, plán nápravy | 4 h / 3 dny |
| P4 – Nízký | Kozmetické problémy | Neaktuální štítky | Regulérní release | 1 den / 2 týdny |
Lineage, katalogizace a dohledatelnost
- Datový lineage: vizualizace toků od zdrojů po KPI; identifikace bodů selhání.
- Datový katalog: popisy tabulek/sloupců, vlastníci, citlivost, kvalitativní skóre.
- Provenience: audit transformací, verzování dbt/SQL modelů, mapování závislostí.
Master data a referenční data
Kvalita master a referenčních dat je násobitelem kvality napříč doménami. Plán obsahuje:
- Politiky zlatého záznamu (golden record): deduplikace, párování, převaha zdrojů.
- Správa kódovníků: schvalování změn, verzování a distribuce do systémů.
- Kontroly integrity: FK na kódovníky, časová platnost (SCD), mapování na externí standardy.
Integrace kvality do SDLC a CI/CD
- Shift-left testy: spouštění validací při každém buildu; blokace release při porušení kontraktu.
- Testy na úrovni modelu: schéma, jedinečnost, not-null, reference, vlastní byznys pravidla.
- Testovací data: syntetické sety s hraničními případy, ochrana soukromí (maskování).
- Canary a rollback: postupné nasazení transformací s porovnáním metrik před/po.
Výjimky, tolerance a sezónnost
Některé odchylky jsou očekávané (sezónní špičky, legislativní změny). Plán určuje:
- Mechanismus výjimek: časově omezené, schválené ownerem, s kompenzačním opatřením.
- Dynamické prahy: percentilové prahy podle historie; guardrails pro extrémy.
- Kontextualizace alertů: spojování více signálů (objem + úplnost + včasnost).
Měření přínosu a KPI kvality
- DQI (Data Quality Index): agregované skóre napříč metrikami s vahami podle rizika.
- MTTA/MTTR: rychlost reakce a nápravy incidentů kvality.
- Defect Leakage: procento chyb proniknutých do produkčních reportů.
- Business Impact: počet odvrácených chyb s finančním dopadem, snížení manuálních zásahů.
Standardní dokumentace a artefakty
- Rejstřík metrik kvality (tabulka s definicemi, prahy, vlastníky, periodicita).
- Mapa lineage a závislostí (vizuál + export do JSON/CSV pro audit).
- Katalog dat se schématy, citlivostí a přístupy.
- Runbook incidentů (playbook pro P1–P4, kontakty, eskalace, komunikační šablony).
- Šablony datových kontraktů (API/event/Batch) včetně verzování.
Příklad validačního plánu pro dataset „Sales Orders”
| Pravidlo | Typ | Popis | Prahy | Frekvence | Akce při porušení |
|---|---|---|---|---|---|
| order_id je unikátní | Schéma/PK | Žádné duplikáty klíče | 100 % / 100 % | při každém loadu | blok pipeline, ticket P1 |
| customer_id existuje v Customers | FK integrita | Platné vztahy objednávka→zákazník | 99,99 % / 99,9 % | denně | karanténa záznamů, P2 |
| sum(order_amount) = sum(line_items.amount) | Byznys rovnost | Kontrola bilance hlavička/řádky | 100 % / 99,95 % | denně | alarm, manuální reconcile, P2 |
| Včasnost dat D-1 do 06:00 | Timeliness | Dataset publikován v SLA | 99,5 % / 99 % | denně | alert on-call, P2 |
Ochrana údajů a kvalita
- Maskování a pseudonymizace: testovací a analytická prostředí s minimem PII.
- Validace citlivosti: kontrola úniků PII do neaut
