Když vidím dataset poprvé| Mňamka #174

V nedávné době mne Eva Hankusová poprosila, zda bych nenapsal Bizztro Mňamku s názvem “Když vidím dataset poprvé”. Řekl jsem jí, že za čas, co pracuji v Bizztreat, jsem už pár datasetů poprvé viděl a určitě se rád podělím o mé zkušenosti, které s každým datasetem bobtnají jak gumový medvídek ve vodě.

Use Case

Dataset jako takový se dá zkoumat z různých perspektiv a lze si položit mnoho otázek, které se datasetu týkají:

• K čemu má dataset sloužit? 
• Jaké informace přináší koncovému uživateli? 
• Odkud pochází?
• Jaké je jeho postavení v logickém datovém modelu (LDM)?
• Jaká je jeho datová kvalita?
• Atd.

Co všechny tyto otázky spojuje a možná i předchází je to, že vždy je dobré vědět, co vlastně jdu s daným datasetem dělat, jak má vypadat výsledek a především, co výsledek přinese koncovému uživateli. Na tyto otázky odpovídá use case (případ užití, UC). 

“Obchodní případ užití popisuje posloupnost akcí prováděných v podnikání, která přináší výsledek v podobě pozorovatelné hodnoty pro individuální účastníky podnikání.” (2001, Rational Software Corporation)

Jinými slovy, analytik musí pochopit proces, jehož je daný dataset součástí. Jeho kroky, vstupy, výstupy, cíl a taktéž roli samotného datasetu v daném business procesu.

Bez odpovědi na zmiňované otázky nebo pochybnosti ohledně přidané hodnoty daného UC se většinou vyplatí se raději danému UC vůbec nevěnovat, dále ho diskutovat a nebo zadání zadavateli rozmluvit.

Taktéž lze diskutovat o pracnosti získání či vytvoření finálního (konzumovatelného) datasetu a především to, zda se vynaložené úsilí poté vrátí na přidané hodnotě.

Extrakce

Ok, tak teda víme, proč je dataset důležitý a jakou hraje roli v daném UC. Taktéž známe význam a přidanou hodnotu UC pro zákazníka a tak chápeme celý koncept toho, co děláme a vlastně máme i velký elán do práce, jelikož víme, že na konci celého procesu vznikne něco, co zákazníkovi opravdu pomůže a bude mít přidanou hodnotu.

Co teda dál?

Je potřeba dataset získat a mít ho v prostředí, kde jej budeme schopni pohodlně a naplno analyzovat. 

Já osobně volím pro rychlé explorativní analýzy nejraději SQL databázové systémy (DBS) či datové sklady (DWH) jako například Google BigQuery, MS Azure SQL, Redshift či Snowflake - což jsou DBS/DWH, které v Bizztreat nejčastěji využíváme a tudíž tyto DBS/DWH znám a mám toto prostředí přístupné v rámci projektu, na kterém zrovna analýzu provádím. Data dostáváme do těchto DBS/DWH pomocí specializovaných komponent, tzv. extraktorů, o kterých vám povyprávím třeba někdy příště (už v této fázi extrakce, lze data různě osekávat (např. brát jen inkrementální přírůstky), měnit (např. transponovat) apod.). 

Co je však důležité říci je, že není nikde psáno, že byste dataset nemohli zkoumat třeba v Tableau, Power BI či v Pythonu. Vše se odvíjí od schopností, dovedností, okolností (např. mám k dispozici DBS/DWH) každého z nás a taktéž od toho, co vám prostě nejvíce vyhovuje. Jediné, co bych nedoporučoval u větších datasetů (milion a více řádků, záleží i na počtu sloupců), jsou tabulkové editory (Excel, Google Sheets, …). Vše se zde totiž odvíjí od výkonnosti vašeho stroje (Excel) a ani online tabulkové editory vás svojí rychlostí při např. filtrování velkých datasetů nenadchnou.

Důvěřuj, ale prověřuj

Předpokládejme, že dataset máme v DBS/DWH či na lokálním PC/Mac. Často se stává, že dostaneme dataset/data, o kterých datový vlastník či business owner tvrdí, že s nimi nebude problém postavit ten či onen dashboard. Data tam, dle jejich slov,  zkrátka jsou a to i ve skvělé kondici. Jak se říká - “Důvěřuj, ale prověřuj.” A tak je třeba i tyto tvrzení řádně proklepnout.

Každý datový analytik má nějaké best practices, jak porozumět datasetu. Já osobně se nejprve snažím daný dataset pochopit z hlediska toho, co obsahuje, tj. jaké informace data v něm obsažená přinášejí. Tj. nejprve zjistit, čemu se daný dataset věnuje. To by mělo být zjištěno při probírání daného UC s business ownerem, který vám řekne, zda byste se měli zaobírat datasetem zachycující např. vydané faktury či přijaté objednávky. Zpravidla nepracujete jen s jedním datasetem ale množinou datasetů, které mezi sebou mají i nějaké vazby (relace).

Pokud tedy již víme, že nás zajímá dataset XY a měl by obsahovat data týkající se daného UC, tak započneme datovou analýzu.

Celistvá data a porozumění atributům

První věcí, kterou v rámci datové analýzy dělám, je to, že se podívám, zda dataset opravdu něco obsahuje. Ano i to se stalo, že například po extrakci dat byl dataset prázdný a neobsahoval žádné záznamy. Častěji se stává, že dataset neobsahuje atributy, které jsou rozhodující pro daný UC. Proto je nutné znát celý dataset jako své vlastní boty a přesně vědět, jaký atribut (v tabulce si představte jako sloupec) co znamená. Pokud některé důležité atributy chybí, tak se doptávám datového vlastníka, kde je mám získat. Zároveň se dívám, zda například ve sloupci cena, který by měl obsahovat numerické hodnoty, není text. 

Důležité je taktéž v této explorativní fázi, kdy poznávám dataset, vědět, zda chci využít dataset celý nebo pro účely UC bude stačit třeba jen zlomek datasetu. Nemusím se pak zabývat pochopením a poznáním významu všech atributů daného datasetu, ale jen těch vybraných, které jsou pro mne důležité. Tento přístup osobně moc nevyznávám, jelikož ze zkušenosti vím, že je nejlepší mít dataset celý a až v dalších fázích zpracování dat poté vytvářet struktury, které obsahují jen vybrané atributy, které jsou pro daný UC důležité. Proč? Protože třeba za měsíc, za půl roku či za rok přijde business owner s požadavkem, že chce ten či onen atribut přidat do výsledného dashboardu a pro mne je to poté jen minoritní úprava.

Je toho moc? Dovolte, abychom vám pomohli. 

Další věcí, kterou je dle mého názoru třeba zkontrolovat, je, že při extrakci nedošlo k změně či poškození dat. Jsou data opravdu všechna? Jsou např. číselné hodnoty v atributech stejné jako v systému odkud data pocházejí? K tomu slouží kontrolní výpočty, kdy si např. zkontroluji, že suma všech zakázek za poslední měsíc sedí se sumou v systému, apod.

Datové typy

Datové typy atributů jsou dalším velkým tématem. Je zřejmé, že například zmiňovaný atribut cena by měl mít nastavený číselný datový typ (např. NUMERIC, DECIMAL, FLOAT, …), popis položky faktury by měl být textového datového typu (např. STRING, VARCHAR) a datum vydání faktury by měl mít datový typ DATE či TIMESTAMP, podle toho zda máme informaci jen o datumu nebo i o datumu a čase.

Na tyto a další datové typy DWH Google BigQuery se můžete podívat zde. Všechny ostatní DWH/DBS mají taktéž ve svých dokumentacích uvedené datové typy, které podporují, jak je nazývají, jaké mají vlastnosti a především jak lze jednotlivé datové typy přetypovat, tj. změnit jejich datový typ na jiný, vámi požadovaný.  

Věděli jste, že například v Redshiftu je maximální možná velikost záznamu v jedné buňce pro datový typ VARCHAR 0.065MB a pro Snowflake je to 16MB. Celkem rozdíl, že?

Cíl je tedy jasný. Určit (a později ve fázi čištění dat nastavit) pro všechny atributy jejich správné datové typy. 

Taktéž je dobré se zabývat četností chybějících hodnot u atributů, které víte, že budou pro váš UC klíčové. Například si představte, že chcete sledovat celkovou pořizovací cenu všech prodaných výrobků vaší společnosti v čase. Jak bude vypovídající výsledek, pokud u poloviny všech součástek nebude uveden nákupní cena?

PK, FK a Datový model

Další důležitou součástí analýzy, když vidím dataset poprvé, je odpovědět si na otázku, jak je vlastně zasazen do výsledného datového modelu. 

Má validní primární klíč (Primary Key, PK)? Obsahuje nějaké cizí klíče (Foreign Key, FK)? Jaké entity se k těmto klíčům vážou? Jsem shopen dataset propojit s tou či onou entitou, která už je třeba součástí modelu?

Ano, téměř každý student informatiky ví, že záznam v DBS by měl mít svůj unikátní identifikátor tzv. primární klíč. Často tomu tak nebývá, datasety je vůbec nemají nebo naopak nejsou unikátní (vyskytuje se v datasetu více záznamů se stejným PK). 

V takovém případě je potřeba unikátnost zařídit například jen jednoduchou grupací řádků (někdy to může být složitější a je nutné nastavit pravidla pro výběr správného záznamu, pokud se hodnoty jednotlivých atributů se stejným PK liší).

Pro datasety které PK nemají je dobré takový PK vytvořit. Složený PK je PK složený z atributů daného datasetu tak, že je vždy unikátní. Lze ho taktéž zahashovat a vytvořit tak ID, které nebude vypadat jako dlouhý textový řetězec složený z hodnot atributů daného datasetu (Hash Funkce v BigQuery).

Následně je dobré se zaměřit na referenční integritu. Cizí klíč (tj. použití primárního klíče - atributu nebo skupiny atributů jednoznačné identifikujících jednotlivé řádky relační tabulky - pro zachycení vazby mezi daty) nemůže nabývat jiných hodnot než těch, které jsou obsaženy ve sloupcích - atributech tvořících primární klíč.

Jinými slovy, zda hodnoty primárního klíče odpovídají hodnotám v cizím klíči relační tabulky, která se může do dané relační tabulky s primárním klíčem odkazovat a naopak. 

Některé vizualizační platformy vám tyto nedostatky v referenční integritě odpustí, ale například GoodData vám při sestavování LDM může váš datový model naprosto zamítnout a vy se tak budete vracet zpět na uplný začátek. 

Pokud mám více datasetů po kupě a znám vazby mezi nimi, tak tyto vazby otestuji (pomocí SQL dotazů), abych si byl jist, že můj zkoumaný dataset zapadá do již známého logického datového modelu.

Co dál? 

Doufám, že jste alespoň rámcově poznali, jak jeden z mnoha datových detektivů analyzuje dataset, když ho vidí poprvé. 

Mám na vás možná jen kontrolní otázku a to proč tuto analýzu teda vlastně děláme? 

Dobře, nebudu vás napínat a odpovím. Dle mého názoru je to přesně proto, že víme jaké jsou v datasetu nedostatky, na co si dát pozor, zda vůbec bude použitelný pro daný UC, kolik času nám zabere jeho čištění, zakomponování do celého řešení, atd. 

Ale o tom vám mohu něco povyprávět zase příště. 

Mějte se hezky!

Zapomněl jsem na něco? Chcete se na něco zeptat? Napište mi. Rád to s vámi proberu.

Patrik

Nestačilo? Dole je toho pro vás víc!