Propojení s datovými sklady a Business Intelligence

Při nasazení datové virtualizace do ekosystému Business Intelligence musíme brát v potaz, zda jej nasazujeme do již existujícího prostředí, či jej nasazujeme do zcela nového prostředí.

V případě nasazení do již existujícího prostředí je potřeba zanalyzovat, co vše v prostředí již funguje. Často se setkáme s tím, že už se uživateli aktivně používají nástroje Business Intelligence, datová uložiště jsou již designovaná a zaimplementovaná, ETL skripty jsou vytvořena a aktivně běží a dodávají data, standardy v datovém skladu jsou nadefinované a dodržované, nebo existují reporty, které spolehlivě dodávají konkrétním uživatelům požadované informace. Do takového prostředí je vhodné datovou virtualizaci implementovat následovně: (3)

• Nainstalovat server datové virtualizace a do ní importovat zdrojové tabulky a v ní nedefinovat obaly a virtuální pohledy pro relevantní tabulky. Reporty zůstávají nezměněny a přistupují stále k datovým uložištím napřímo

• Po jednom se datoví uživatelé přesměrovávají k přístupům do datových uložišť pomocí datové virtualizace. Virtuální pohledy jsou vytvořeny se stejnou strukturou a se stejným obsahem, jako jsou jejich zdroje. Díky tomu se uživatelům nemění dotazy na uložiště, která zůstávají stejná, pouze se dotazují do serveru datové virtualizace, a ne napřímo do zdrojů

• Pro některé datové uživatele se mapování virtuálních pohledů v tomhle kroku změní, protože by se měla již pozměnit transformační logika (obsažena v ETL skriptech doplňujících data do zdrojových tabulek) a musí být otestována, aby byla garantována podobnost 1:1 i v novém virtuálním pohledu

• V dalším kroku je potřeba se soustředit na zjednodušení architektury vymazáním duplikátních hodnot z datových uložišť. Pokud se do zdrojových tabulek již nepřistupuje, protože se dotazy uživatelů přesměrovali na jiné tabulky (v jiných uložištích), tak se stávají nadbytečnými a mohou být smazány. Spolu s nimi mohou být smazány i ETL skripty, které do nich nahrávali data. Pokud se odstranilo dostatek nadbytečných tabulek, může se pozornost přesunout na celé uložiště a její odstavení.

Reportů se ale stále změny nedotýkají, jelikož by stále měly ukazovat stejné údaje a jediný potenciální rozdíl by mohl být v rychlosti načítání reportu, což poté záleží na používané databázi a hardware-u.

41

• Tento krok se zase věnuje normalizaci struktury virtuálních pohledů, jelikož je stále máme identicky strukturované ke zdrojovým tabulkám. Virtuální pohledy mohou stále mít podobnou strukturu, ale pokud se v nich udělá jakákoliv změna, musí se podobně reagovat i s reporty, které z virtuálních pohledů získávají data.

• Spustit caching pro virtuální pohledy, které výkonnostně selhávají, a je nezbytné výkonnost zlepšit.

Výhodou této strategie je, že se jedná o vcelku jednolitou migraci. Existující uživatelé nepoznají, že se v datových uložištích staly jakékoliv změny a architektura je díky datové virtualizace mnohem agilnější, jelikož se změny implementují rychleji. (3)

Je tedy vhodné se v takovém prostředí zamyslet, zda datová virtualizace opravdu způsobí revoluci a změní celý fungující systém. S největší pravděpodobností totiž nezmění. Může ovšem tady mít přidanou hodnotu, bude se tedy spíše jednat o evoluci. (3)

U vývoje nového Business Intelligence systému ovšem implementace datové virtualizace bude odlišná od předchozích kroků. V tomhle případě budeme postupovat následovně: (3)

• Musí se vyvinout systém s minimálním počtem datových uložišť, preferované jsou datové stage a datové sklady. Pomocí ETL/ELT a replikací pak ukládat data do daných uložišť. Poté je potřeba se rozhodnout jak velké množství čištění dat a datové integrace chceme provádět. V případě čištění dat bychom je měli provádět již při ukládání do datových uložišť, protože je to vhodnější místo pro čištění než přímo při mapování virtuálních pohledů, které by mohlo být komplexnější a více náročné na zatížení CPU.

Chceme zkrátka čistit data co nejdále od reportů (ideálně již v produkčních systémech) a pokud možno mít v datovém skladu data již očištěná, transformovaná a virtuálních pohledů zakomponována pravidla, která se musejí dodržovat. Pro vývoj a zakomponování filtrů existují dva důležité existují dva důležité důvody – zvýšení kvality dat a v případě implementace filtrů v první vrstvě virtuálních pohledů (při mapování) uvidí uživatelé vždy vyčištěná a ověřená data, i v případě přístupu do nejnižší úrovně virtuálních pohledů, a také kvůli konzistenci reportingu pro všechny nástroje a všechny její uživatele. Struktury těchto pohledů by měli být stejné jako jejich zdrojové tabulky, na které jsou napojené.

• Vytvoření druhé vrstvy virtuálních pohledů, kde každý pohled reprezentuje určitý byznys objekt nebo součást byznys objektu (např. zákazníci, produkty nebo faktury).

To znamená, že se spojují různé pohledy na sebe a vytvářejí jeden větší virtuální pohled.

Pokud jsou byznysové objekty částmi jiných byznys objektů, můžeme se dostat do zahnízděných pohledů, je v tom případě potřeba definovat byznys objekty co nejvíc srozumitelně.

• Vývoj třetí vrstvy virtuálních pohledů s cílem splnit konkrétní požadavky datových uživatelů nebo jejich skupin. To se může týkat potřeby konkrétní struktury pohledů, protože se jejich nástroje mohou připojit pouze na danou strukturu. Nebo i potřeby

42

pracovat pouze s aktuálními daty, a ne s historickými, což může vést k dalším filtracím dat. Tím pádem se v této vrstvé vytváří již jakási forma virtuálního datového tržiště.

• V dalším kroku by se měli již vyvinout reporty z nejvyšší vrstvy virtuálních pohledů. Je možné, že se v tomto kroku budou dělat určité změny ve virtuálních pohledech, jelikož se při vývoji reportů přijde na nové znalosti a potřeby, které se budou muset zakomponovat i do vrstvy datové virtualizace.

• Je možné, že bude potřeba zapojit do hry také caching pro některé z virtuálních pohledů. Ať už z důvodu nízké výkonnosti dotazů, vysokého zatížení produkčních systémů nebo potřeby uživatelů vidět konzistentní data v určitém časovém období.

Obrázek 9 Propojenost datové virtualizace s datovými sklady (zdroj: (3))

Existují dva důležité body, proč řešení pomocí datové virtualizace přímo nenahrazuje datové sklady – datové sklady umožňují historizaci dat a jsou rychlejší. To jsou fakta, která se nedají vyvrátit žádnou současnou a nejspíše ani budoucí platformou datové virtualizace. Organizace by ovšem neměli vyhledávat řešení datové virtualizace a vytvoření logických datových skladů jenom proto, aby nahradily svá současná řešení s klasickými datovými sklady, ale i pro vzájemnou součinnost těchto dvou typů technologií. (3)

Datové sklady mohou být zdrojem pro datovou virtualizaci, ale i naopak datová virtualizace může dodávat data do datových skladů. Především ve formě pomoci s datovými transformacemi z jiných zdrojů, kdy datová virtualizace může např. přeměnit nestrukturovaná data do strukturované podoby, což může poté datový sklad využít. (3)

Datové virtualizaci je časově náročná především kvůli dodatečné práci s různými strukturami dat, které musí shromažďovat a zpracovat, na rozdíl od datových skladů. Datové sklady samy o sobě jsou designované pro příjem a analýzu vysokého objemu data, trvá jim ovšem delší dobu implementace nového datového zdroje. Datová virtualizace jí v tomhle může pomoci kvůli její

43

schopnosti integrovat do sebe heterogenní datové zdroje rychleji, a v případě potřeby může nabrat i data z datového skladu a zkontrolovat, zda data z datového skladu spojena s daty z dalších datových zdrojů jsou směrodatná a smysluplná, čímž také může datová virtualizace poskytnout dočasné řešení pro práci s daty, dokud se datové zdroje neimplementují do datového skladu. (3)