Jedním z mých nedávných projektů bylo vybudování nového reportingu pro jednoho Telco operátora v UK v Londýně. Jde o poměrně dynamickou firmu a tento projekt byl po všech stránkách poměrně hodně zajímavý. Nejzajímavější ovšem byl cíl – vybodování datového skladu a reportingu nad ním v poměrně velmi krátké době.
A jak zajistit úspěch takového projektu v oblasti Buisness Intelligence? Dle mého názoru je jedním z důležitějších aspektů dodat výsledky co nejdříve. A to nejen například první prototyp nebo PoC, ale pokud možno i hlavní výstup projektu. Protože právě dodávka a předání alespoň nějaké části vytvoří možnost zkonzultovat se zákazníkem a získat jeho zpětnou vazbu a vytvořit si představu o dalším pokračování. V případě potřeby pak přibrzdit a vydat se jiným směrem. Touto předávkou části myslím použitelnou část výstupu pro finálního uživatele. Pokud bude předána například jen analýza ve Wordu, tak věřte, že to moc užitku nepřinese.
Korporace a velké projekty
Z předchozích zkušeností, kdy jsem pracoval v bankách na velkých projektech týkajících se dodávky části nebo celého datového skladu, byl velký problém v tom, že po poměrně velkou dobu (fáze analýzy) zákazník vůbec netuší na čem děláte a jestli jste pochopili, co vlastně potřebuje. Ve chvíli, kdy pak máte tuto analýzu hotovou, a doufáte, že víte co budete dělat, předáte tuto analýzu zákazníkovi.
Obvykle jde o desítky stránek ve Wordu a sem tam nějaký excel a diagramy. A chcete to odsouhlasit zákazníkem – s termínem “včera”. Zákazníkovi se to ale nechce číst, ani kontrolovat. Jednak proto, že mu to nemusí nic říct, ale také proto, že to zabere dost času vše projít a zkontrolovat. Chápu zde postavení dodavatele, který chce vidět podpis a tím mít krytá záda a jasně ohraničený další postup a odfajkovanou velkou část práce, ale už zde vznikají vzájemná nepochopení a budoucí průtahy. A pak… pak následuje několik měsíců vývoje… až je vše hotovo! Tedy alespoň dodavatel v to doufá a zákazník se na to těší. (Pokud do té doby nenašel cesty jak své původní potřeby vyřešit jinak, protože dnes už může mít potřeby jiné.) A nastává tedy fáze testování…
Waterfall a jak to dělat jinak
Jak jste již asi pochopili, nejsem moc zastánce waterfall přístupu v oblasti Business Intelligence. A tento nedávný projekt pro jednu Telco firmu v Londýně mě přesvědčil, že agilní a rychlý vývoj nese své ovoce. Hlavním principem, který se na svých projektech snažím dodržovat je – ukázat jeden až dva reporty klientovi, na které se bude moci podívat a vyzkoušet si, zda se mu líbí. Vzít alespoň malou část jeho reálných dat, v rychlosti je intuitivně upravit do použitelné podoby a nachystat jeden/dva reporty pro klienta, upravit je do funkční podoby – a ty mu dát. Dát, ne jen ukázat v powerpoint prezentaci.
Je dost pravděpodobné, že většinu této práce hned poté zahodíte, a začnete tyto transformace a reporty budovat “doopravdy”, ale to, že si klient může na toto první demo sáhnout, přinese klid na obě strany. Některá z pozitiv tohoto přístupu jsou:
- Klient ve vás získá důvěru v to, že jeho data umíte zpracovat.
- Může si vyzkoušet, zda mu dané řešení vyhovuje, nebo vlastně potřebuje něco úplně jiného.
- Už při takto krátké cestě můžete trochu odhadnout, jaké problémy vás při transformacích čekají – kvalita dat se projeví velmi záhy.
- Uvidíte, jak moc se o to klient zajímá. Jestli si s tím bude alespoň trochu hrát nebo ne.
- Pochopíte k čemu ty data jsou a co z toho klient potřebuje získat
- V podstatě už můžete začít testovat. (A to před ukončením vývoje!, ať žije paralelismus.)
Krátký cyklus
Zásadním faktorem v následující práci je stále udržovat krátký cyklus zapojování klienta a předávání části výstupů. Prostě udržet s klientem stále kontakt a jakmile máte něco hotového šup s tím za ním.
Problémy
Velkým problémem a brzdou mohou být zpoždění na straně klienta – čekání na data, čekání na nastavení databáze, čekání na rozhodnutí o tom, jestli jít do cloudu nebo ne a následně čekání na založení virtual machine jejich administrátorem. Většina těchto problémů se dá celkem efektivně řešit simulací na vaší straně. Nemáte data – nasimulujte si je pokud máte alespoň strukturu. Nemáte hotové prostředí – nasimulujte si jej u sebe, nebo ve vašem cloudu. (Jen zde dejte pozor na data klienta – nedávejte je kam nepatří 😉 Se simulovanými nebo anonymizovanými daty by neměl být problém. I když dnes s connectivitou většinou není problém, tak téměř vždy se snažím si prostředí s databázemi a nainstalovanými programy simulovat přímo na svém počítači – vývoj je pak přeci jen rychlejší. Jen se v těchto simulacích neutopte a hlavně – čím jednodušeji, tím lépe.
Rychlost
Asi nejzásadnějším bodem pro rychlost bylo, že jsme se snažili udělat naprostou většinu transformací parametricky. Což znamená, že místo jednoho scriptu/workflow/modulu pro každou ETL transformaci, resp. přečtení a nahrání tabulky do Data Martu jich máte ve výsledku třeba jen 5 dohromady. Ano, stojí to často námahu vymyslet pravidla, a parametry jak se transformace má změnit pro ten a ten typ vstupu, ale v našem případě to dopadlo tak, že na vstupu jsme měli jen 3 rozdílné typy vstupů – a všechny 3 se dali parametrizovat jedinou tabulkou. Vstupů nakonec bylo asi kolem 30. V podstatě se řídím jedním zásadním pravidlem – jakmile se chystáte něco zkopírovat, 3x si rozmyslete, zda z toho raději neudělat funkci a parametrizovat danou funkcionalitu. Ale zároveň nevymýšlejte příliš složité funkce – někdy je to právě v tom najít dobrý kompromis, v tom jak složitě udělat případnou rozhodovací logiku nebo přidat další informace/parametry ke vstupu.
Nezávislost nápočtu
Další věcí, která souvisela s parametrizací nápočtu bylo zásadní omezení závislostí jednotlivých kroků na sobě. Jestli jste někdo někdy viděl mapu závislostí v nějakém větším datovém skladu, tak mi asi dáte za pravdu, že nebývá úplně přehledná. Zde jsme se snažili většinu těchto závislostí výpočtů úplně eliminovat. V podstatě se logicky nejsložitější operace dějí až v reportech. Jediná závislost kroků na sobě je čistě logická. A stejně jsme v ní udělali chybu!! – o tom ale více níže.
1) stažení souborů
2) předpřipravení všech vstupů do použitelnějšího formátu (v podstatě zapsání do stage)
3) historizace profilové dimenze
4) nápočet faktů
5) publikace výstupů
Snažte se řídit instinktem – co pro co potřebujete.
Široké tabulku
Všechny výstupní tabulky jsme se z počátku snažili tvořit co nejširší – rozhodně do nich dát všechny údaje z dimenzí a nesnažit se o žádné snowflake schámata. Dramaticky to ovlivní rychlost reportingu nad tím (opět – nepřežeňte to, nebo ho to zabije). V dnešní době, kdy storage je téměř to nejlevnější, tak nevím proč na něm šetřit. Nápočet je sice o něco delší, ale selecty z toho mnohonásobně rychlejší. A o jednoduchosti selectu se asi rozepisovat nemusím.
Přepočítatelnost
Dříve jsem se setkal s tím, že přepočítat historii datového skladu je absolutně nemožné. Nikdy se mi to nelíbilo. Vždyť přece, když chcete spočítat nějaký konkrétní den, tak stačí pro něj mít vstupy. Toto ale velmi zásadně narušuje historizace – a především její velmi obyklá forma SCD (Wikipedia – Slowly Changing Dimension) (a nejčastějí Type 2). Číst z ní by ještě nějak šlo, ale vytváření/měnění v ní historie je tedy oříšek. V našem projektu jsme se ji právě pro to snažili eliminovat. Plus jsme se snažili transformace napsat parametricky (viz. výše), aby byly schopné zpracovat jakýkoliv den. Toto nám umožnilo kdykoliv zpracovat jakoukoliv oblast dat, kterou jsme zrovna potřebovali. Časem se toto stalo obrovsky využívané – až jsme tyto nápočty rovnou doplnili o funkcionalitu kontroly a smazání předchozí historie. Navíc to také umožnilo velmi rychlé opravy dat – a to se také stávalo poměrně často, že “něco opravovali” na zdrojovém systémů.
Spolu s touto přepočítatelností, jsme také vedli logy o tom kdy a co se zrovna napočítalo a kolik řádků se zapsalo. (o logování a monitoringu ale jidny)
Poučení do příště
Ne vše se ale povedlo hned ze začátku. Například tím, že jsme se snažili mít co nejdříve alespoň nějaký výstup, tak se stávalo, že jsme museli často sahat do samotné logiky tvoření těchto dat, a následně i do výstupních formátů. Snažte se, aby i když vše tvoříte v rychlosti a často i počítáte s tím, že to jednou budete předělávat, abyste to tvořili přehledně a alespoň komentovali vaše hacky a workaroundy.
Dalším bodem byla historizace – přeci jen jsme si neodpustili a jednu tabulku historizovali pomocí SCD Type 2 – přišlo nám to u profilů úplně normální. Musím ale zpětně říci, že bych to tak příště neudělal a použil všude snapshoty. Nechci říci, že je to všelék, ale pro alespoň tento projekt by se to hodilo.
Závěr
Na závěr bych chtěl dát asi základní poučku – hlavně jednoduše!
0 Comments