Text vyšel ve zkrácené podobě v čísle 9/2016 časopisu IT Systems
Co mají všichni uživatelé datových skladů a BI řešení společné? Shodují se na tom, že nízká kvalita dat je neobyčejně frustrující a drahá. Stejně tak panuje většinová shoda na tom, že řízení datové kvality je pro datové sklady druhá nejdůležitější kompetence, hned po řízení metadat. Méně jednotný názor je na to, co to vlastně datová kvalita je, a co musí splňovat BI řešení, abychom se sledováním a zlepšováním datové kvality mohli zabývat.
Často používaná definice říká, že data jsou kvalitní, pokud uživatelé mají data kompletní, srozumitelná, konzistentní, relevantní a včas. Ještě jednodušeji řečeno, data jsou kvalitní, pokud splňují požadavky uživatelů na jejich použití. Nízká kvalita dat v datovém skladu totiž podkopává důvěru v reportovaná čísla a vede ke vzniku „shadow BI“, kdy si uživatelé vytvářejí kontrolní reporty. Náklady na reporting a čas přístupu k informacím se tak, oproti očekávání, zavedením datového skladu výrazně nezlepší.
V prostředí datového skladu se ale vyskytují dvě velké skupiny uživatelů, které mají různé zájmy. Vlastníci datového skladu jsou ochotni považovat data za kvalitní, pokud nenaruší zpracování v datovém skladu od vstupu dat až po výpočty cílových data martů a reportů. Na druhé straně stojí byznys uživatelé, které zajímá hlavně to, že výsledky jsou důvěryhodné a včas. Popřípadě ještě chtějí vědět, na základě jakých dat byla spočtena reportovaná čísla, zda při zpracování došlo k nějakým chybám, jak byly opraveny a zda měly nějaký dopad na výsledek.
Z mnoha pohledů je první skupina ve velké výhodě. Zná technologie, rozumí řešení datového skladu a implementuje změny. Příkladem řešení preferující požadavky této skupiny je například metodika Data Vault. Tato metodika rezignuje na rozlišování kvalitních a nekvalitních dat z pohledu byznys požadavků. Soustředí se na schopnost dlouhodobého ukládání informací pocházejících z různých zdrojů v různé struktuře, na přesnou identifikaci zdroje jednotlivých dat a na konzistenci jejich propojení. Mechanickým použitím této metody vznikají řešení, ve kterém koncoví uživatelé dostávají data s mnoha duplicitami a nekonzistencemi, a je pouze na nich, jak s takovýmito daty naloží. Pro reálnou použitelnost je nutné implementovat uživateli účelové data marty a řešení problémů datové kvality je tak přeneseno tam i se všemi výhodami (přístup k minimálně modifikovaným datům) a nevýhodami (duplikace pravidel čištění). Síla byznys uživatelů spočívá v tom, že mohou definovat a vyžadovat byznys pravidla, které data musí datový sklad splňovat, a zejména v tom, že ve většině případů řešení financují.
Je důležité uvědomit si, že datové nekonzistence či nekvality budou v primárních systémech existovat vždy, a to i přes co nejdůkladnější validační pravidla při pořizování dat. Jednoduše proto, že jsou mnohá data zadávána lidmi nebo chyby vznikají chybným zpracováním v primárních systémech. Stejně tak se budou existovat nekonzistence mezi systémy.
Ještě důležitější je uvědomit si, že ne každá nekonzistence či nekvalita je pro uživatele dat důležitá a její oprava či náprava ekonomická je ekonomicky výhodná.
Seznam nejčastějších vad v datové kvalitě, stejně tak jako seznam strategií, jak jim předcházet, je neobyčejně dlouhý. Zastavme se alespoň u několika z nich.
Na to, jak se chovat k null hodnotě v datovém skladu a které sloupce (mimo klíčů) by měly umožňovat zápis null hodnot, je mnoho názorů. Jedni tvrdí, že null hodnoty by se v datovém skladu neměly vyskytovat vůbec a při přejímání dat z primárních systémů by se měly nahrazovat speciální hodnotou. Zastánci tohoto přístupu prosazují minimum nullable sloupců v modelu. Tento postoj odůvodňují tím, že se snadno odhalí chyby v transformacích. Slabá stránka tohoto přístupu je definice speciálních hodnot. Pro krátké řetězce se hledá nevýznamová hodnota těžko a pro číselné hodnoty se ve většině databázových serverů žádná taková speciální hodnota nedá definovat vůbec. Opačný přístup předpokládá použití pouze nullable sloupců v modelu a všechny testy vyplnění hodnot přenechává na validacích datové kvality během zpracování. Tento přístup má samozřejmě dopad na náročnost zpracování a není schopen odhalit null hodnoty vzniklé chybnými transformacemi.
Je zarážející, že v druhé dekádě dvacátého prvního století se stále musíme zabývat kódováním českých znaků. Dědictví nabodeníček Jana Husa, invence bratrů Kamenických, štědrosti Microsoftu generujícího kódové stránky skoro stejně často jako verze operačních systémů vede k tomu, že i po nechtěném zásahu do konfigurace nebo upgrade nějaké komponenty začne dostávat datový sklad místo textů rozsypaný čaj. Protože pro datové sklady je kritická velikost ukládaných dat, tak ani přechod na kódování UTF8 není spásným řešením.
Duplicitní záznamy vznikají na dvou místech. Primární systémy mohou dodávat stejná data opakovaně nebo mohou duplicity vznikat chybami v transformacích, většinou definicí nedostatečných kritérii při spojování tabulek. Duplicity jsou poměrně snadno odhalitelné. Složitější je její náprava zejména v případě chybných transformací.
Počítat s tím, že vstupní data mohou být někdy nedostupná, se zdá samozřejmé. Přitom v mnoha případech transformace počítají vždy s kompletní sadou vstupních dat. Výsledkem toho přístupu je buďto nemožnost dokončení denního zpracování nebo porušení řad hodnot a stavů v historii. Přitom řešení může být poměrně jednoduché. Stačí striktně rozdělit vstupní data na transakční a stavová. Pro transakční data zajistit, aby se zpracovala, až budou dodána, ale se správným datem. Pro stavová data se vždy použít poslední dostupný obraz. Tato strategie, že denní zpracování datového skladu neohrozí neplánovaný výpadek některého zdrojového systému s minimálním dopadem na kvalitu dat.
Častým problémem při rozvoji datového skladu je nutnost zvětšování textových polí. Ať už to je způsobeno změnou stávajících systémů nebo napojením nových datových zdrojů. Z pohledu datové kvality je nutné zajistit, aby nedošlo k nechtěnému zkrácení nových hodnot. Jedna z možných strategií, jak předcházet těmto chybám v datové kvalitě, je používat pro všechny řetězce zbytečně velké sloupce a ověření délky a textových patternů přenechat na validaci datové kvality během zpracování. Musíme si ale dát pozor, protože některé datové servery toto řešení zvětšuje velikost skutečně uložených dat a snižuje výkon.
Mezi další zdroje vad v datové kvalitě patří nekonzistentní použití speciálních znaků, sémantická nekonzistence mezi jednotlivými zdroji, nezanalyzované transformace při přípravě vstupů pro datový sklad, změna struktury dat v primárních systémech a zejména změna sémantiky používání současných struktur, nezdokumentované rozdíly oproti přijatým standardům a politikám, manuální zásahy do dat nebo do kódu transformací a obecně špatně nastavené procesy vlastnictví dat a data managementu v organizaci.
Připravit datový sklad pro řízení datové kvality znamená připravit se na nepředvídané. Řešení musí být podobné jako systémy pro krizové řízení v případě přírodních katastrof. Musí být jednoduché a rychlé, aby fungovalo v krizových situacích. Musí být použitelné jak při záplavách, tak při požárech ze sucha a dokonce i při zemětřesení, i když všichni tvrdí, že zemětřesení nastat nemůže. Řešení musí zahrnovat technické prostředky i procesy. Postupy musí být dobře popsány a všichni zainteresovaní musí znát svoje povinnosti. A také všechny činnosti se musí pravidelně trénovat.
Základní strategie, jak s vadami bojovat je jejich odhalování a testování datové kvality na všech úrovních datového skladu během každého zpracování. Na obrázku jsou uvedena místa testování a doporučené typy testů.
Co to znamená z pohledu datového skladu? Řešení datové kvality musí být zohledněno v návrhu datového modelu, při analýze a vývoji transformací i při procesech provozování datového skladu.
Procesy
Procesy spojené s řízením datové kvality a opravou chyb jsou kapitolou samy o sobě. Asi nikdo už dnes nepochybuje o tom, že každá nalezená chyba v datové kvalitě musí být zaznamenána, že o tom, jak bude opravena, musí rozhodnout byznys vlastník dat, nikoliv nějaký technik, a že musí být zaznamenáno kdy, co a jak bylo opraveno. Ještě krásnější je, když u každé chyby jsme schopni alespoň přibližně odhadnout její finanční dopad.
Co je ale platné, že datový sklad odhalí nekonzistence v datech, když si jich nikdo nevšimne. Extrémním příkladem byla situace, kdy analytik více méně náhodou zjistil, že už dva měsíce je jeden produkt přenášený do datového skladu označován jako nevalidní z důvodů hodnot jeho parametrů v primárních datech. Tedy všechny transakce spojené s tímto systémem se nezpracovávají. A jednoduchá oprava nebyla jednoduše možná, protože by to změnilo výsledky, které již byly reportovány.
Častěji je nastaven proces, kdy se chybná data opravují v primárních systémech, a do datového skladu se dostanou při příštím zpracování. Toto je preferovaný přístup, protože zvyšuje datovou kvalitu nejen v datovém skladu, ale napříč firmou (systémy jsou integrovány a chyba, resp. oprava se šíří). S tímto procesem bývají všichni spokojeni až do okamžiku, kdy primární systém ohlásí, že data prostě změnit nemůže, protože to prostě nejde.
Při návrhu řešení je nutné počítat s opravami jako standardní součástí zpracování. Použití opravných položek a opakované zpracování opravených dat z chybových tabulek je jedním z možných přístupů. Začít řešit proces opravy dat ve dvě ráno v den měsíční uzávěrky není příjemná situace pro žádného ze zúčastněných.
Transformace
Transformační procedury, ať již jsou realizovány jakkoliv, mění data v datovém skladu, a proto většina vad v datové kvalitě je spojena právě s nimi. Přístup k jejich návrhu a vývoji je proto zásadní. Transformace můžeme rozdělit do tří skupin. Transformace realizující byznys pravidla a datové integrace. Tyto transformace jsou zpravidla navrhovány analytiky a vytvářeny ručně. Z pohledu datové kvality je kritická dostatečně rozsáhlá kontextová, strukturální a sémantická analýza vstupních dat a také adekvátní profiling vstupních dat. To je jediný způsob, jak předcházet vzájemné nekonzistenci, výskytu duplicit nebo ztrátě dat způsobené chybami v definici transformačních pravidel.
Druhým typem transformací jsou technologické transformace. Mezi ně patří load dat z primárních systémů, staging, historizace nebo archivace. Tyto procedury mohou být kompletně generovány na základě datového modelu a vzorů připravených architekty. Vynechání lidských zásahů do kódu významně snižuje počet chyb a tím i možnost vzniku chyb v datech. Ostatně jakýkoliv ručně vytvářený kód nebo dokonce data jsou velikým rizikem z pohledu datové kvality a nejčastější příčinou chyb. Jako bonus získáváme snížení nákladů na vývoj a údržbu takových transformací.
Třetím typem transformací jsou procesy validace datové kvality. Doporučovaným patternem je rozdělení každé logické transformace na byznys transformaci, následné ověření datové kvality získaných dat a jejich výsledné zpracování – nejčastěji historizace. Aby tento pattern mohl efektivně fungovat, je nutné, aby validační pravidla byla definována metadaty a relativně snadno měnitelná bez nutnosti zásahu do kódu řešení. V takovém případě je možné při nalezení chyby definovat nové pravidlo, které identifikuje vadná data při dalších zpracování. Zároveň je možné měnit místo, kde validace vadná data identifikují. Obecně platí, že čím blíže zdrojovým datům je chyba identifikovaná, tím menší dopad má na výsledné zpracování. Metadaty řízené validace navíc umožňují operativně řídit rozsah prováděných validací a tím výpočetní nároky zpracování.
Model
Dobrý datový model je vždy kompromisem vycházejícím z existujících dostupných logických datových modelů pro jednotlivé vertikály, modely primárních aplikací a požadavky na srozumitelnost modelu. Obecné logické modely se vyznačují velikou komplexitou, prostě proto, protože jsou obecné. Na druhé straně je v nich koncentrovaná nenahraditelná zkušenost z desítek existujících řešení. Slepá aplikace těchto modelů vede ke zbytečně složitým transformacím, které jsou náchylné produkovat chyby nejen v datové kvalitě. Na druhé straně často většina dat pochází z jednoho nebo dvou primárních systémů a uživatelé by nejraději chtěli zachovat jejich datový model i v datovém skladu, protože ho znají a rozumějí mu. Přílišné lpění na modelu dat z jednoho primárního systému ale vede k problémům při integracích a k následným nekonzistencím.
Pro udržení datové kvality je nutné mít velmi přesný popis sémantiky modelu, všech jeho tabulek a sloupců. Nestačí pouze existence popisu, stejně nutné je dosáhnout jednotného chápání modelu mezi všemi uživateli. Právě rozdílné názory na význam jednotlivých entit jsou častým důvodem nekonzistencí a chyb v transformačních pravidlech.
Z pohledu datové kvality je velmi důležité, aby technické aspekty datového modelu, které podporují řízení a ověřování datové kvality byly jednotně řešeny v celém modelu. Zpravidla se jedná o sloupce označující chybové nebo nevalidní řádky, „error tabulky“ – tabulky obsahující řádky, které neprošly testy datové kvality, auditní sloupce se záznamy o původu dat a identifikací procesů, které řádky do datového skladu přidaly nebo je měnily. Sem patří jednoznačně definované způsoby použité historizace, jednotná pravidla pro práci s null hodnotami, s velikostí použitých datových typů a pravidla pro práci s umělými klíči.
Jediný způsob je zvládnout komplexitu problematiky návrhu datového modelu je zapojení datového architekta s dostatečnou zkušeností už v počátečních etapách přípravy řešení. Musí být schopen rozhodnout o vhodnosti použitých patternů, strategií a procesů z pohledu velikosti datového skladu, účelům řešení a vyspělosti zákazníka. Musí být schopen ohodnotit dopad všech rozhodnutí jak v době vývoje, tak v době provozování a rozvoje řešení. Zároveň musí být schopen dohodnout se na výsledném řešení s budoucími byznys uživateli. Na něm leží největší váha při dohledu nad výsledky práce jednotlivých analytiků a musí průběžně revidovat všechny změny datového modelu.
RNDr. Ondřej Zýka
Autor pracuje v Profinitu jako Senior data consultant. Má dvacetiletou zkušenost s datově intenzivními projekty jako je budování datových skladů a speciálních operativních datastorů, datové migrace, projekty řízení datové kvality a řízení metadat. V současnosti také vyučuje na ČVUT FIT a UAI Jihočeské univerzity.