Čtvrtý díl: Oracle x Microsoft – kdo nabízí lepší BI?

Čtvrtý díl: Oracle x Microsoft – kdo nabízí lepší BI?

Má tahle otázka vůbec smysl? Každý z těchto nástrojů má svoje výhody i nevýhody, ale především každý je vhodný pro něco jiného.

Power BI je flexibilní, rychle se vyvíjející nástroj, s jehož pomocí si postavíte skvělou datově-analytickou samoobsluhu.

Oracle Analytics Server (jinak OAS, dříve Oracle BI) je zralý, sofistikovaný a flexibilní nástroj pro tvorbu podnikových BI řešení. Obsahuje celou řadu samostatných modulů a podporuje (mimo jiné) i podobné pracovní scénáře jako Power BI (dále PBI). Jedním z nich je například i zmiňovaná BI samoobsluha, která je v posledních letech oblíbeným marketingovým trhákem na poli BI obecně.

Přesto, že naším úkolem v rámci projektu migrace Dr.Max není hodnotit kdo/co je lepší ale migrovat, nevyhnuli jsme se bouřlivým diskusím a porovnávání jednotlivých funkcionalit obou nástrojů. Je mezi nimi totiž několik klíčových rozdílů, které zásadně ovlivňují složitost migračního projektu.

Oracle Analytics Server

OAS je historicky postavený na architektuře Oracle BI serveru, který je odpovědný za

  1. Správu sémantického modelu, který má 3 základní vrstvy:
    • Fyzickou pro mapování databáze, kde jsou uložená data.
    • Logickou pro
      • modelování a tvorbu vazeb mezi jednotlivými entitami modelu
      • podporu business logiky (např. výpočet různých metrik, tvorba hierarchií pro podporu agregací)
    • Prezentační pro uspořádání a prezentaci model způsobem srozumitelným koncovým uživatelům
  2. Transformaci BI dotazů do dialektu databáze, ve které jsou uložená data, přičemž
    • Snahou BI serveru je maximálně delegovat výkonovou zátěž na databázi (ideálně samozřejmě na Oracle RDBMS).
    • Výsledný SQL dotaz je sestaven na základě sofistikovaného parametrizovatelného generátoru.
  3. Kešování a další zpracování dat získaných z databáze a jejich doručení konzumentům.

Microsoft Power BI

PBI je nástroj pro rychlou analýzu dat a reporting postavený na principu samoobsluhy. Vzhledem k tomu, že výchozí stav je OAS a cílový PBI, nabízí se  logicky popis formou co všechno PBI oproti OAS umí, neumí a co není.

Na rozdíl od OAS – což je samostatný produkt – je PBI součástí ekosystému, který v prostředí Azure víceméně zajišťuje podobnou funkcionalitu jako OAS. Klíčové je slovo „víceméně“ – platí to totiž pouze na úrovni top-level architektury, kde se dají najít paralely mezi jednotlivými komponentami. Pod kapotou to potom vypadá samozřejmě jinak.

Samotný PBI obsahuje „pouze“:

  1. Správu sémantického modelu, který na rozdíl od OAS neumožňuje model vrstvit (tj. modelovat business logiku a samostatně udržovat prezentační model pro tvůrce reportů).
  2. Vizualizaci/prezentaci dat získaných z modelu.


OAS a PBI se liší hlavně ve způsobu zpracování dat. PBI navíc postrádá prezentační model

Největší rozdíl je přístup k získávání / zpracování dat. OAS se historicky snaží delegovat co největší zátěž na databázi (ideálně samozřejmě také z dílny Oracle), kdežto Microsoft inzeruje jako hlavní zpracování dat v PBI na základě tzv. Tabular Modelu v paměti pomocí Vertipaq Engine.

Můžeme samozřejmě vést dlouhou a (ne)plodnou diskusi na téma

  • je výhodnější použít pro rychlé analytické dotazy sloupcový/in-memory engine přímo v databázi

nebo

  • je lepší využít BI engine jako je VertiPaq a zpřístupnit rychlou analytiku i pro data získaná z databází které takovým enginem nedisponují?

Kromě toho rychle zjistíme, že in-memory scénář typu VertiPaq naráží

  • buď na problémy s velkými objemy dat, které musí analytické dotazy zpracovat
  • nebo na nemalé náklady na podporu velkých in-memory datasetů.

Pro náš projekt ovšem platí, že

  1. Cílová platforma je daná a tudíž …
  2. … Jedná se o zásadní změnu paradigma zpracování dat, který se nutně promítá do toho, jak postavit rozsáhlý BI model (který bude třeba v rámci migrace postavit v novém prostředí).

Takže jak na to? Všechno zahodit a znova? Vybrat si to nejlepší, zbytek zahodit a znova? Nebo se pokusit migrovat staré řešení do nového prostředí, zprovoznit ho a potom postupně upravovat?

Každá z uvedených variant má svoje výhody, ale i nevýhody. S ohledem na zadání projektu, zdroje a čas, který máme k dispozici, může být špatná volba smrtící.

No a jak je naším zvykem, na problémy související s volbou správného přístupu a důvody které k tomu vedly si probereme příště