Už dlho som chcel napísať tento článok, ale v kútiku duše som dúfal, že Microsoft nezanevrie na technológiu OLAP kociek. S vydaním SQL Servera 2017 sa ale už definitívne potvrdzuje dlhodobý trend, že OLAP je výbehová technológia, o ktorú nemá záujem už ani jej výrobca, a nahradzuje ju buď Tabularom, alebo R Serverom. V tomto článku si povieme, prečo je OLAP v dnešnej dobe zlá voľba, a prečo by ste ho už nemali používať na nové projekty.

OLAP kocky vznikli pôvodne v polovici 90-tych rokov, v dobe, keď Windows 95 bol pokročilý operačný systém, počítače sa začínali vo veľkom ešte len objavovať v domácnostiach, a mali malú pamať aj rýchlosť. Vtedajšie databázy však už vtedy nestíhali spracovávať analytiku nad všetkými dátami, a preto prišiel OLAP, ktorý sľuboval predpočítané agregované dáta. Jeho prvú komerčnú implementáciu kúpil Microsoft od istej izraelskej firmy aj s jeho tvorcom, premenoval ju na Analysis Services, a pridal ju do SQL Servera. Potiaľto naše okienko do histórie.

Prišlo však 21. storočie, a s ním exponenciálna explózia v množstve dát, ktoré treba zanalyzovať. Zo začiatku to nebol problém, ale akonáhle objemy dát začali rásť do desiatok TB a viac, tak sa začali prejavovať architekturálne problémy OLAP kociek, ktoré si popíšeme nižšie. To by ani tak nebol problém, keby Microsoft na to reagoval a prispôsoboval OLAP tak, aby tento nápor zvládol. Lenže posledné väčšie zmeny uviedol Microsoft s verziou SQL Servera 2005, čiže pred 12 rokmi (!). Odvtedy vyšlo 6 verzií SQL Servera, a len v 2 z nich boli novinky – bohužiaľ len kozmetické. Nepomohol tomu ani fakt, že pôvodný tvorca OLAPu odišiel v roku 2009 do Bing Maps, lebo ho to už nezaujímalo… A ak dnes chcete použiť OLAP pre naozaj veľké dáta, tak si už dopredu môžete byť istí, že projekt zlyhá. Na internete síce nájdete články od samozvaných expertov, ktorí tvrdia, že keď sú dáta predpočítané, tak žiadna iná technológia (napr. Tabular) nemôže byť rýchlejšia – no z toho zjavne vyplýva, že nikdy nepracovali s terabajtami dát. Tu sú dôvody, prečo.

OLAP nepredpočítava všetko, niekedy dokonca nič

OLAP štandardne predpočítava dáta iba na najnižšej úrovni agregácie. A aj to len pre agregačné funkcie Sum, Count, Min a Max. Pri ostatných predpočítava len pár agregátov, alebo vôbec nič. A na vyšších úrovniach mu musíte povedať, ktorú konkrétnu kombináciu má predpočítať. Čo je fajn, ak máte 10-20 atribútov v celej kocke, čo sa takmer nikdy nestáva. V bežnej veľkej kocke totiž máte stovky až tisícky atribútov, a pokryť všetky kombinácie týmto spôsobom je jednoducho nemožné. V Tabulare si môžete vytvoriť agregácie podľa seba.

Nepoužiteľný Distinct Count

A teraz perlička – pre Distinct Count sa nepredpočítava absolútne nič! Namiesto toho sa funkcia vždy počíta z detailných riadkov, a aj to dosť neefektívne. Funkcia, ktorá je úplne bežne použitá v biznis analýze, je v OLAPe pri veľkých dátach úplne nepoužiteľná. A ak máte terabajty dát, tak užívateľom proste nevysvetlíte, že pri každom rozkliku v kontingenčke musia čakať niekoľko minút na výsledok. OLAP sa totiž zavádza kvôli tomu, aby reakcie na užívateľské požiadavky boli okamžité. Sú tam síce drobné možnosti optimalizácie, ktoré to niekoľkonásobne zrýchlia, ale zrýchlenie rozkliku z 10 na 2 minúty je stále zlé, akokoľvek dobre to vyzerá – OLAP sa zavádza preto, aby to trvalo sekundy.

Zastaralá architektúra pre nasadzovanie zmien

Ďalším zabijakom riešenia je to, že aj pri relatívne bežných operáciách musíte preprocesovať (dať znova prepočítať) celú kocku, a ak máte šťastie a používate zdieľané dimenzie, tak všetky kocky. Čo pri desiatkach TB dát znamená, že užívatelia neuvidia aktuálne dáta niekoľko dní. Potrebujete pridať nový atribút? Prepočítajte kocku. Potrebujete nebodaj novú dimenziu? Prepočítajte kocku. Chcete zmeniť zoradenie prvkov v atribútoch na iné? Prepočítajte kocku. Pri tomto prístupe je jasné, prečo Yahoo prešlo pri 100 TB OLAP kocke z Analysis Services ku konkurenčným Microstrategy.

Minimálne možnosti optimalizácie výkonu a optimizér z praveku

Keď už aj rozbeháte nejak OLAP, tak po čase ho bude potrebné optimalizovať. A pri terabajtoch dát hneď od začiatku. Niektoré z agregátov však OLAP kocka nepredpočíta, aj keď jej to zadáte – napr. Distinct Count vôbec, First-/LastChild čiastočne, a pri parent-child hierarchiách sa musíte uspokojiť s tým, že agregáty existujú len na najnižšej a najvyššej úrovni hierarchií, bez možnosti kontroly. Toto všetko sa obchádza predagregovaním dát v databázach, ale tu mi potom uniká zmysel, prečo sa vlastne nasadzuje OLAP. A ďalšia perlička – keď aj OLAP vie vypočítať agregáty na vyšších úrovniach pre tých pár funkcií, ktoré pozná, tak mu nesmiete dať vypočítať stovky agregácií (v dobrej viere, že pokryjete toho čím najviac) – optimizér OLAPu proste z toho celého úplne zblbne, a v niektorých prípadoch spadne výkon dotazov na úroveň kalkulačky. Toto sľubovali vylepšiť v SQL Serveri 2016, ale nakoniec sa po tom zľahla zem. A opäť, počet zmien v OLAPe v SQL Serveri 2017 je magická nula.

Neschopnosť spracovať veľké dáta a detaily súčasne

Toto je úplný paradox, ktorý by ste vôbec nečakali od OLAP kociek. Ak ich totiž potrebujete použiť na veľké dáta, a zároveň mať možnosť rozkliknúť sa na úplný detail, tak veľmi rýchlo narazíte na dlhodobý limit atribútov v OLAP kockách – cca. 2 miliardy unikátnych hodnôt na 1 atribút. Čo znamená, že keď spravíte faktovú dimenziu s viac ako cca. 2 miliardami riadkov, ktoré obsahujú aj ID riadku (ktoré musíte mať v kocke kvôli rozkliku na detail), tak Vám to jednoducho spadne na chybe pri spracovaní dát. Je síce zopár možností, ako to obísť, ale len za cenu drastického zníženia výkonu kocky. A to už môžete radšej smerovať analytiku a reporting priamo na dátové sklady s predpočítanými agregátmi.

Nemožnosť naplno využiť všetky pokročilé vlastnosti

Pri veľkých dátach je väčšina pokročilých vlastností OLAP kociek nepoužiteľná buď kvôli technologickým obmedzeniam (keď zapnete toto, nemôže byť zapnuté tamto), alebo kvôli výkonu. Ako príklad uvediem writeback, parent-child hierarchie, referencované dimenzie a M:N vzťahy. Takže takmer všetka pokročilá funkcionalita, ktorou sa OLAP líši od Tabularu, aj tak nie je použiteľná buď vo vzájomnej kombinácii alebo pri veľkých dátach.

Jediným pozitívom na OLAPe je jazyk MDX, ale ten plnohodnotne funguje aj v Tabulare. Takže pre väčšinu ľudí nebude stáť komplikované riešenie OLAPu za patálie spojené s jeho vývojom a údržbou. Na dnešnú dobu je to ako stará socialistická Škodovka – aj ňou sa síce odveziete, ale radšej si kúpte novú. Na dnešnú dobu je prispôsobená lepšie.

A kam smeruje vývoj v blízkej budúcnosti?

Podľa rôznych indícií to vyzerá tak, že OLAP bude nahradený Tabularom. Čiže serverovou verziou PowerPivotu. Dokonca v oficiálnych odporúčaniach sa už uvádza, že na nové projekty sa má používať Tabular. V marketingových materiáloch síce ešte stále nájdete odkazy na multidimenzionálne Analysis Services a rôzne hybridné nasadenia OLAPu a Tabularu, ale vo väčšine prípadov je to už len utópia a maskovanie nevyhnutného.

Tu sú dôvody, prečo používať Tabular namiesto OLAPu (niektoré oficiálne, niektoré neoficiálne, niektoré z osobných skúseností):

1. Tabular je aktívne vyvíjaný a rozširovaný od roku 2010 (s výnimkou temného obdobia MS BI v rokoch 2014-2015),
2. Tabular je optimalizovaný pre Distinct Count, a na plnej čiare výkonovo poráža OLAP,
3. Tabular plne podporuje DAX aj MDX (dokonca MDX neoficiálne aj pre tvorbu merítok/measures),
4. Nasadenie nových zmien v „dimenziách“ nevyžaduje takmer nikdy reprocessing modelu – väčšinou iba dotknutej tabuľky alebo zopár tabuliek,
5. Máte plnú kontrolu nad optimalizáciou výkonu, najmä vďaka vypočítaným tabuľkám,
6. Tabular má rýchlejšie odozvy, a efektívnejšie pracuje s viacerými procesormi aj pamäťou (aj keď jej spotrebuje viac),
7. Vývoj riešenia je typicky 10-20x rýchlejší v porovnaní s OLAPom,
8. Čo v Tabulare chýba, to sa dá ľahko dorobiť jednoduchým workaroundom,
9. Na Tabular sa dá natívne pripájať z ľubovoľného Excelu, aj pomocou pôvodného OLAP konektoru zo všetkých väčších reportovacích nástrojov, pretože navonok sa SSAS Tabular správa ako OLAP kocka, a používa rovnaký protokol/ovládač ako OLAP kocky,
10. Tabular funguje aj v cloude ako Azure Analysis Services,
11. Tabular je predvolený spôsob inštalácie Analysis Services od verzie 2017,
12. Tabular sa vie pripojiť natívne k oveľa väčšiemu množstvu dátových zdrojov ako OLAP, najmä od verzie 2017,
13. Tabular 2017 vie dáta nielen počítať, ale aj transformovať, spájať, rozdeľovať a ľubovoľne ohýbať vďaka zabudovanému Power Query a jazyku M.

A čo sa týka objemu dát, ktoré to vie zvládnuť? Microsoft okrem oficiálnych obmedzení neuvádza, koľko dát tam dostanete. Napríklad ja som na Slovensku pracoval najviac s 200 GB modelom v pamäti (čo odpovedalo niečo vyše 1 TB dát v dátovom sklade), a po krátkej optimalizácii to výkonnostne porážalo OLAP na plnej čiare. Niektoré z pokročilých vzorcov bolo síce treba prepísať na iný spôsob výpočtu, ale za a) nebolo to ťažké a za b) nevyhnete sa tomu tak či tak pri žiadnej technológii. Výsledné riešenie však bolo rýchle, stabilné, dalo sa ľahko rozširovať, a spĺňalo to všetky požiadavky klienta aj jeho užívateľov. Takže, z môjho pohľadu už nie je dôvod používať OLAP, ak máte k dispozícii aj Tabular. Jedine, že by ste chceli zažiť masochizmus spomínaný vyššie na vlastnej koži 🙂

Aktualizácia 12.9.2018: Microsoft dnes pridal do Tabularu podporu agregácií. Tým de facto pochoval OLAP. Preto ho už naozaj nepoužívajte na nové projekty – vedia veľmi dobre, prečo vám to odporúčali.

Michal Chmelár

Autor, tréner a expert na PowerPivot, Power BI a jazyk DAX. Založil som tento web, aby som pomohol dostať PowerPivot a Power BI do širšieho povedomia, a aby som ľuďom ukázal, že aj komplexné analytické problémy idú riešiť jednoducho. Po nociach vzývam Majstra Yodu a tajne plánujem ovládnutie vesmíru.