Naozaj potrebujete celú históriu dát?

Pri svojich konzultáciách sa veľakrát stretávam s rovnakým problémom – klient sa pokúsi naliať do PowerPivotu, Power BI či SSAS Tabularu komplet všetky dáta, ktoré nájde vo firme a ešte k tomu aj v šuflíku u suseda, a potom sa diví, prečo to zrazu ide tak pomaly. Keď mám optimalizovať takýto dátový model, tak moja prvá otázka smeruje hneď na princíp redukcienaozaj potrebujete celú históriu dát ? A aj keď je zvyčajná odpoveď „samozrejme že áno“, tak sa aj napriek tomu pokúsim o redukciu. V tomto článku rozvediem bližšie, z akého dôvodu.

Keď firma zvyčajne nájde zázračný nástroj, ktorý vie zanalyzovať kopu dát, tak niekto vo firme dostane zrazu nápad, že keď to ide, tak vyskúšame do toho hodiť ďalšie dáta. A potom ďalšie a ďalšie. Až nakoniec to skončí v situácií, že každé šuchnutie papiera musí byť zaznamenané v tomto systéme, a, samozrejme, všetky štatistiky nad tým musia okamžite fungovať. A ideálne nad všetkými dátami pozbieranými za posledných 25 rokov zo všetkých možných archívov.

Keď aj takúto obludu optimalizujem, a ide dostatočne rýchlo, tak sa celý cyklus opakuje – vždy sa nájdu ďalšie a ďalšie dáta, ktoré „nevyhnutne musia byť“ v dátovom modeli, a časom celý výkon tohto riešenia spadne na rovnakú, alebo ešte horšiu úroveň. A môžete mať hocijakú zázračnú technológiu a nadupaný hardvér, a pri vyskúšaní 20. riešenia sa stále budete diviť, prečo sa hľadanie svätého grálu stále nedarí nájsť. Problém pritom nie je v technológii, ani v ľuďoch. Problém je v tom, že sa do dátového modelu tlačia dáta, ktoré si nikto nikdy nepozrie. Jednoducho len preto, lebo šéf XY ich tam chce mať.

Praktický príklad – povedzme, že máte v dátovom modeli dáta za posledných 5 rokov. Napríklad všetky objednávky, plus nejaké číselníky k tomu. Keď takéto dáta spočítate v grafe na úrovni rokov, tak to pravdepodobne bude zaujímavá informácia pre manažment, ako sa firme darilo za tieto roky. Možno budú pre nich zaujímavé aj údaje na úrovni štvrťrokov či mesiacov. Ale ak budú chcieť ísť ešte nižšie, tak s obrovskou pravdepodobnosťou to budú chcieť iba pre posledný rok, maximálne dva. Pretože takmer naisto pre nich nebude mať zmysel analyzovať predaje za 5. februára pred 4 rokmi. A keby aj – viete si predstaviť jediný praktický (!) príklad, kedy to naozaj budú potrebovať? A najmä, že to budú potrebovať robiť každý boží deň počas niekoľkých nasledujúcich rokov? Či že ich bude zaujímať detail objednávky šróbu od Jožka Mrkvičku z 12.3.2012? Sami viete, že určite nie. Pre detailnú analýzu na úrovni záznamov je potrebné len krátke obdobie z posledného roka, a pre všetko staršie postačujú aj zosumarizované dáta, napr. na úrovni týždňov alebo mesiacov – a čím ďalej do minulosti, tým na vyššej a vyššej úrovni. A po rozumnej diskusii so svojimi nadriadenými väčšinou aj oni sami uznajú, že mať detaily z pred 20 rokov má úplne nulovú cenu, a že históriu potrebujú vidieť viac-menej len pre orientáciu. A že určite nepotrebujú celú históriu dát.

Takáto situácia Vám následne výrazne uľahčí celé riešenie – budete potrebovať menej pamäte, menej miesta na diskoch, menej procesorového výkonu, a možno aj lacnejšie licencie. A celé riešenie bude fungovať oveľa rýchlejšie, a z pohľadu užívateľov zvládne oveľa viac dát. Pretože ak dokážete napr. v PowerPivote optimalizovať dátový model tak, že historické dáta budú zosumarizované na vyššej úrovni, tak následne viete spraviť také merítka, ktoré budú inteligentne vyberať dáta z agregovaných aj neagregovaných častí, a kombinovať ich do navonok rovnakého výsledku. A budú to robiť 20x rýchlejšie, ako keby ste mali v PowerPivote projekt celej jadrovej elektrárne. A okrem toho Vám to vyrobí menej práce a starostí do budúcnosti, pretože menšie riešenie je zvyčajne menej prácnejšie aj oveľa menej problematickejšie. A nad tým sa už oplatí zamyslieť, vytrpieť si niekoľko kôl mítingov, a dospieť k dohode, ktorá všetkým stranám značne zjednoduší život. Pretože v žiadnom riešení určite nutne nepotrebujete mať detailné dáta 20 rokov dozadu. Ani komplet celú históriu dát. A to ani v jadrovej elektrárni.