Chcete být Data-driven?

Tak buďte Data-informed & Data-inspired

qlik sense

Business Intelligence a datová virtualizace

Co to vlastně datová virtualizace je a jaké jsou její výhody a nevýhody?

Tento článek jsme rozdělili do dvou částí. První částí je manažerské shrnutí, kde se dozvíte, co to vlastně datová virtualizace je a jaké jsou její výhody nevýhody, aniž bychom vás zasypávali technickými pojmy. Pokud jste ale technický typ, doporučujeme manažerské shrnutí přeskočit a začít číst rovnou detailnější technické vysvětlení podstaty datové virtualizace.

Manažerské shrnutí

Základem Byznys Inteligence jsou kvalitní data. Firmy do reportingu a analýzy dat investují spousty prostředků, aby mohly lépe optimalizovat firemní procesy, hledat nové příležitosti, minimalizovat rizika a obecně zvyšovat výkonnost. Kdo má v konkurenčním boji rychleji důležité informace, může i rychleji reagovat a získat konkurenční výhodu.

Postupem času se vyvinula řada variant Business Intelligence přístupů a architektur, které mají za cíl stejnou věc: dodat cílovému uživateli spolehlivé informace. Nejčastější je architektura postavená kolem datového skladu. Firemní data jsou na pravidelné, většinou denní, bázi importována do relační databáze (datového skladu), ze kterého se pak generují reporty a provádějí analýzy. Tato architektura, jako každá jiná, má své výhody a nevýhody. Jako výhody je možné uvést konsolidovaná očištěná data z různých systémů v jednom uživatelsky přívětivém modelu, historizaci nebo zabezpečení dat.

Nevýhodou datových skladů je ale často časová a finanční náročnost rozšiřování o nová data a obecně implementace jakýchkoliv změn. Z obchodního hlediska potřebuje firma velmi rychle reagovat. Změní se situace na trhu, je potřeba se jí přizpůsobit nebo využít náhlou novou příležitost. „Data driven“ firma bude pro kvalifikované rozhodnutí chtít využít maximum informací. Přidání nové oblasti dat do datového skladu je ale většinou otázkou týdnů, v řadě korporací spíše měsíců, což je v turbulentní době zoufale pomalé.

Datové sklady jsou také většinou stavěny pro denní zpracování dat. V noci, kdy je v datovém skladu a ve firemních aplikacích nejmenší provoz, se data automatizovanými procesy přenesou do datového skladu, očistí a připraví pro uživatele. To je dobrý přístup, dokud data kvůli rychlosti reakce nepotřebujeme zpracovávat už v momentu jejich změny. Na to klasický datový sklad nedokáže reagovat, integraci dat v reálném čase většinou řeší jiné nástroje jako real-time ODS, což je ale další prvek architektury vyžadující vysoké investice do vývoje i náklady na provoz.

Na trhu již řadu let existují nástroje, které nám mohou pomoct výše zmíněné nedostatky odstranit, ale teprve poslední dobou, díky čím dál většímu tlaku na rychlost a flexibilitu získávají více na popularitě. Jsou to nástroje pro datovou virtualizaci (v angličtině se můžete setkat i s pojmem data federation). Ve virtualizačních nástrojích tvoříme imaginární (virtuální) datový model. Zdrojová data zůstávají ve zdrojových systémech a nikam se nekopírují. Pomocí virtuálního modelu se pouze propojí a nabídnou cílovému uživateli. Uveďme jako příklad CRM systém s tabulkou zákazníků a účetní systém. Oba systémy pracují nezávisle a nevědí o sobě. Ve virtualizačním nástroji tyto aplikace, respektive data z těchto aplikací, propojíme a uživateli poskytneme konsolidovaný pohled na účetnictví přes zákazníky ze CRM, jako kdyby všechna data byla v jednom systému. Zároveň data můžeme očistit a upravit pro lepší vizuální zobrazení. Protože se přes tento virtuální model díváme přímo do zdrojových dat, nedochází ke zpoždění informace. Díváme se na reálná data přímo ze zdrojů.

Vývoj pohledů nebo také modelů je velice rychlý. Doslova na pár kliknutí jsme schopni vytvořit byznysový pohled na novou oblast dat a propojit ji s ostatními daty v datovém skladu, data laku, ODS nebo kdekoliv jinde. Potřebujeme datovou oblast upravit a přidat další informaci? Není problém. Prostě jen do výsledného modelu přetáhneme ze zdroje nový sloupec. Nevyhovuje nám tento model a chceme nový? Také není problém. Virtuálních modelů si můžeme vytvořit libovolné množství.

Velká výhoda spočívá v tom, že data nemusíme nikam fyzicky přenášet, vyvíjet složité ETL procedury a řešit dopady změn. Tento přístup má ale i své
nevýhody. Neřeší historizaci dat ani náročné transformace. Připojení virtualizačního nástroje přímo do databází zdrojových aplikací také nese jistá rizika,
ale o tom si můžete přečíst ve více technicky zaměřené části tohoto článku.

Co když tedy potřebujete sledovat historická data, očištěná a transformovaná v datovém skladu, ale zároveň byste je chtěli moct rychle propojit s jakýmikoliv daty ve vašich systémech? Případně k některým aplikacím můžete přistupovat přímo a u některých byste mohli ohrozit jejich fungování? Nebo chcete propojit data z datového skladu, data laku, ODS, interního systému a externího zdroje?  Zdrojem pro datovou virtualizaci může být téměř cokoliv. Od textových souborů až po výkonné analytické databáze. Datový sklad s historickými daty tak může být jeden ze zdrojů datové virtualizace a virtualizační nástroj vám spojí historická data s aktuálními daty ze zdrojových aplikací. Takových scénářů může být celá řada, záleží pouze na potřebách koncového uživatele.

Pokud Vás datová virtualizace zaujala a chtěli byste si přečíst, jak to celé funguje, můžete pokračovat na technickou část článku.

Datová virtualizace technicky a podrobně

Pro kvalitní BI analýzy a zobrazení podnikových dat potřebujeme zahrnout data z různých zdrojů jako jsou například ERP systémy, účetní systémy, CRM systémy, veřejně dostupná statistická data z internetu nebo ruční vstupy od uživatelů a manažerů. Standardní BI architektura nám říká, že bychom měli reportovat z datového skladu, případně z datamartů. Do datového skladu se data standardně dostávají ETL procesy. Bolest této architektury je příliš dlouhý proces aplikace nových byznysových požadavků. Obecně platí, že čím větší korporace, tím delší je čas od schválení byznys požadavku po jeho fyzickou implementaci. Další nevýhoda je zpracování dat na denní bázi, takže datový konzument dostává data s určitým zpožděním. Kromě BI nástroje máme ve firmě většinou i další datové konzumenty využívající stejné zdroje dat. Mohou to být například webové stránky, intranet, mobilní aplikace či další podnikové aplikace. Problém je stejný jako u BI nástroje. Pokud potřebujeme využívat data, která v datovém skladu nejsou připravena nebo potřebujeme data rychleji než jednou denně a zároveň nebudeme chtít porušovat dohodnutou architekturu, budeme mít pravděpodobně smůlu. Naskýtá se ale zajímavá možnost, jak tento problém elegantně vyřešit. Tato možnost je datová virtualizace a zprostředkovávají ji pro nás virtualizační nástroje.

Virtualizační nástroj pracuje na principu virtuálního datového modelu. Ve skutečnosti můžete mít fyzický datový sklad s dimenzionálním modelem vedle modelu z virtualizačního nástroje a nepoznáte rozdíl. Pokud už jste se někdy setkali s pojmem logický datový sklad nebo virtuální datový sklad, jedná se pravděpodobně o datovou virtualizaci, kdy model logického datového skladu je jen abstraktní logická vrstva nad daty ve zdrojových systémech. Na vstupní straně virtualizačního nástroje jsou všechny možné dostupné zdroje a technologie. Je to vlastně jeden z hlavních požadavků na takovýto systém. Nástroj by měl být schopen napojit se na datové zdroje bez rozdílu, jestli je to datový sklad, aplikační databáze ERP systému, data lake, on-premise či cloud prostředí.

Virtualizační server má většinou tři logické vrstvy. Není to vždy nutné, ale je to model osvědčený praxí. Každá logická vrstva hraje v celém řešení svojí roli.

 

Nejnižší/zdrojová vrstva je obraz zdrojových dat. Tato vrstva je interface do zdrojů. Po nadefinování konektivity do zdroje z něj naimportujeme objekty, které chceme později použít. Importujeme jen metadata objektů, nikoliv data. Přidání nového objektu do této vrstvy je otázkou sekund. Pokud se dotážeme na data přes nejnižší vrstvu, vždy dostaneme originální data ze zdrojového systému. Pouze s tím rozdílem, že data jsou ve formě „virtuální“ relační tabulky i když například originální zdrojová data jsou parquet file na HADOOP, excelový soubor, nebo jiný typ nerelačních dat.

Střední/integrační vrstva je hlavně o integraci a standardizaci dat. Výstupem je virtuální tabulka, kterou můžeme použít v dalších logických vrstvách. V integrační vrstvě řešíme propojení fyzických tabulek nastavením vazeb. Dále zde řešíme sjednocení textů, doplnění chybějících hodnot, doplnění defaultních hodnot podle byznys logiky, standardizaci hodnot jejich překladem nebo využitím číselníkové či vazební tabulky.

Nejvyšší/prezentační vrstva slouží jako interface směrem k uživateli. V této vrstvě vytváříme virtuální modely, které slouží jako výstup pro datové konzumenty. Virtuální modely vycházejí z integrační vrstvy a jejich vytvoření je velmi jednoduché. Většinou připravujeme model tak, že přetahujeme sloupce z tabulek v integrační vrstvě do nové tabulky v prezentační vrstvě. Pokud je to možné, virtualizační nástroj za nás vyřeší vazby a vše potřebné. Při vytváření modelů máme velkou svobodu a můžeme vytvářet modely tak, jak je potřebuje konzument. Pokud konzument potřebuje model „a la“ star schéma, vytvoříme star schéma. Stejně tak můžeme vytvořit průřez obchodními procesy pomocí dimenzionálního modelování a vytvořit tak virtuální datový sklad. Případně můžeme vytvořit velmi široké tabulky s mnoha sloupci pro potřeby některé firemní aplikace.

Uveďme si malý příklad, jak virtualizace funguje v praxi.

Představme si firmu, která má BI nástroj pro zobrazování firemních reportů. BI nástroj před zobrazením reportu musí získat data z datových zdrojů. A to tak, že vygeneruje sql dotaz na zdroj, zdroj zpracuje obdržený sql dotaz a zašle požadovaná data zpět do BI nástroje. BI nástroj následně data vizualizuje například formou reportu nebo dashboardu. V klasické architektuře je většinou BI nástroj napojen na datový sklad, nebo datamart.

V našem virtualizačním příkladě není BI nástroj napojen přímo na datový sklad, ale je napojen na virtualizační server. Pokud pošle reportingový nástroj dotaz do virtualizačního serveru a virtualizační server pozná, že data jsou ze tří různých systémů, rozdělí vstupní dotaz na tři menší dotazy a pošle je do zdrojových systémů v jazyce, ve kterém zdrojové systémy pracují. Když dorazí data ze zdrojových systémů zpět do virtualizačního serveru, data jsou spojena nebo jinak zkombinována v integrační vrstvě a výsledek je zaslán zpět přes prezentační vrstvu reportingovému nástroji jako jeden výstup. To, co probíhá na pozadí virtualizačního serveru, je datovému konzumentovi skryto. Všechny transformační kroky jako jsou filtrace, maskování, výpočty, textové funkce, agregace, spojení dat probíhá živě na vyžádání. To je hlavní idea datové virtualizace. Klasické ETL také provádí tyto transformace, ale na rozdíl od virtualizačního nástroje je vždy někam ukládá předtím, než je můžeme použít.

Přidanou hodnotou virtualizačních nástrojů je například data lineage, které nám poskytuje informace o mapování cílových atributů na zdrojové atributy. To nám samozřejmě velmi pomůže při dopadových analýzách, kdy dochází k technickým změnám na objektech datového zdroje. Dále může datová virtualizace sloužit jako integrační článek při migraci dat z on-premise prostředí do cloudu. Mnoho virtualizačních nástrojů má integrovaný datový katalog pro lepší vyhledávání informací, byznys pojmů a podobně. Některé nástroje mají přímou integraci s BI nástroji (například Denodo -> Tableau). Virtualizační nástroje mohou řešit bezpečnost dat. Row level security tedy nemusíme řešit na databázové úrovni na každém zdroji zvlášť, ale vyřešíme jí na jednom místě. A to se nebavíme o zdrojích, kde bezpečnost vůbec implementovat nejde. Většina nástrojů podporuje nejpoužívanější metody autentikace, jako jsou Native, LDAP/Active Directory, Kerberos, Windosws SSO, Oauth 2.0, SAML, SPNEGO. V rámci autorizace jsou podporovány role, integrace s LDAP user groups, různé přístupy na funkce uvnitř aplikace – metadata, execute, insert, create datasource, zabezpečení na různých datových levelech – schema, view, sloupec, řádek, dynamicky se měnící bezpečnost a další…

Okolo datové virtualizace je samozřejmě mnoho otázek ohledně dostatečného výkonu.

Ukažme si jeden příklad. Aplikace pošle dotaz, který se skládá z 8 operací – agregace, nahrazení hodnot, filtrace atd… Virtualizační server tento dotaz dekomponuje a zjistí, že 6 z 8 operací je schopen udělat zdrojový databázový server. Na virtualizační server pak zbývají dvě operace. Stejný příklad, ale zdroj dat je filesystem. Filesystem není schopen dělat žádné složité operace, a tak musí v tomto případě udělat virtualizační server 6 z 8 operací. Nejsme tedy dopředu schopni stanovit přesný výkon. Pokud se bavíme o výkonu virtualizačního řešení, musíme brát v úvahu výkon virtualizačního serveru, ale zároveň i výkon zdrojového serveru. Virtualizační server se vždy snaží využít co nejvíce výkonu ze zdroje a každý asi rozumí tomu, že pokud je na zdroji Excel nebo Exadata, je to velký rozdíl. Virtualizační nástroje se vždy snaží požadavek dekomponovat na jednotlivé části a poslat dotaz na zdroj v optimální formě.

 

Pokud například spojujeme dvě tabulky z různých zdrojů a filtrujeme atribut z tabulky „A“ a zároveň přes tento atribut spojujeme obě tabulky, virtualizační server automaticky filtruje tento atribut i na zdroji „B“ tak, aby na své úrovni spojoval co nejméně dat. Další příklad může být spojení dvou tabulek z různých zdrojů, kdy jedna tabulka inner joinem filtruje druhou. Virtualizační server nejprve stáhne data z jednoho zdroje a na základě výsledku pak filtruje dotaz do druhého zdroje. U spojování velkých tabulek se používá jiný trik. Místo toho, aby si virtualizační server stáhl obě velké sady dat k sobě a nad nimi pracoval, „naučí“ komunikovat oba dva zdroje mezi sebou a nechá tuto úlohu zpracovat jeden ze serverů. Pokud má možnost vytvářet temp tabulky v jedné z databází, může tabulku z druhé databáze přenést do temp tabulky první databáze a join provést zde.

Další z užitečných vlastností, které zajišťují vyšší výkon u virtualizace je cachování. Cachováním můžeme ochránit například transakční databáze před příliš mnoha dotazy. Můžeme požádat virtualizační server, aby některá data, třeba celou virtuální tabulku, nacachoval. Všichni dnes mají spojené cachování s in memory. To znamená, že data se načtou do paměti a tam se po určitou dobu drží. Toto není náš případ. Ve virtualizaci cachování znamená, že virtuální data z virtuálních tabulek jsou fyzicky uložena. Samozřejmě můžeme nadefinovat kam. Každá další query, která bude chtít využít toto virtuální view, se dotáže do cache tabulky a už se nedotazuje do zdrojové databáze. Přirovnání z databázového světa může být materializované view. A takových příkladů bychom mohli uvést nespočet. Mechanismus uvnitř virtualizačního serveru se vždy snaží minimalizovat datový tok po síti a přenášet co nejmenší datové bloky. Je to velká věda a virtualizační nástroje v tom musí být dobré. A opravdu jsou v tom skvělé. Tento chytrý mechanismus se nazývá optimizer.

Hlavní klíčové úlohy optimizeru jsou:

  • Kontrola a dekomponování příchozí sql query na menší části, pokud je to nutné nebo výkonově výhodnější.
  • Načtení metadat ze zdrojových tabulek. Zjistí si informaci o datovém zdroji, primárních klíčích, cizích klíčích, indexech, partitionách.
  • Načtení datových statistik, jako je odhad velikosti dat pro costbase optimizer.
  • Zjištění, jestli může zdroj procesovat všechna data, jestli je zdroj jen pro čtení nebo může vytvořit temp tabulku, jestli je zdroj masive parallel processing databáze, velikost databázového clusteru, a další důležité informace.

 

Na začátku článku jsme se bavili o logickém datovém skladu. Je tedy možné nahradit klasický datový sklad datovou virtualizací? Jednoznačná odpověď je ne. Datová virtualizace není kompletní řešení. Vždy budete potřebovat ve vaší datové architektuře další komponenty. Nicméně její zařazení do firemní datové architektury vám může přinést benefity. V případě kombinace s datovým skladem vám například může poskytnout komplexní pohled na historizovaná data a reálná data v čase dotazu. Virtualizace vám dovolí dělat rychlé prototypy datových modelů, které později můžete natrvalo implementovat do datového skladu. Dále vám dovolí dělat složitější analýzy, které se nebudou do budoucna opakovat a není potřeba náročná úprava modelu v datovém skladu. Nevýhoda datové virtualizace je, že není určena pro příliš komplikované dotazy, není určena pro data se složitými vazbami, pro data se špatnou datovou kvalitou a nedá se jednoduše řešit historizace dat. V tomto vyniká klasický datový sklad ve spojení s ETL. Pro milovníky moderních open source technologií a zaříkávačům datových skladů ještě uvádím několik zajímavých zapojení virtualizačního systému například s Hadoop. Technologie postavené okolo Hadoop mohou být použity jako zdroj historických dat (HDFS, Hive, Impala, Presto, SparkSQL). Hadoop můžete také využít pro cachování dat.

Pokud se rozhodnete tuto technologii vyzkoušet a později implementovat, měli byste postupovat podle osvědčených metod. Pro POC si vyberte úlohu, která má „reprezentativní“ složitost. Použijte pro testování hotové reporty. Vyberte úlohu, která prověří funkčnost a výkonnost. Při testování funkčnosti se zaměřte na sql dotazy generované reportingovým nástrojem a exekuční plány v cílové databázi. Při testování výkonnosti testujte na reálné kvantitě dat. Udělejte zátěžový test. Testujte reálné výstupy a reálný způsob využití. Porovnávejte výkon při zapnutí a vypnutí cachingu. Jednoduše řečeno, testujte tak, abyste co nejvíce nasimulovali reálné použití.

A jak správně vybrat vhodný virtualizační nástroj? Velmi důležité jsou vlastnosti a funkce. Zaměřte se hlavně na funkce, které chcete využívat. Ať už jsou to různé datové zdroje, možnosti transformace dat nebo bezpečnost. Důležitý je i výkon. Nemá cenu vybírat řešení, které výkonově nebude vyhovovat, nebo ještě hůře, bude způsobovat výkonové problémy v jiných firemních aplikacích. Produkt by měl být lokálně podporovaný. Zkušenosti ostatních uživatelů vám také leccos napoví. Uvažujte rovnou i o extra softwaru a hardwaru, který budete potřebovat pro master data management, čištění dat, datovou bezpečnost, speciální konektory a drivery, databázový server pro referenční tabulky a cache, atd…

Pro úplnost si uveďme některé nástroje, které jsou na trhu k dispozici. Nejdominantnější v Evropě jsou DataVirtuality, Denodo, Fraxses, TIBCO. Celosvětově je to pak Denodo a TIBCO. Níže je seznam TOP 10 virtualizačních nástrojů používaných celosvětově v současné době.

AtScale
DataVirtuality
Denodo Platform
Dremio
Fraxses
IBM InfoSphere Federation Server & IBM Data Virtualization Manager for z/OS
Red Hat JBoss Data Virtualization
Stone Bond Enterprise Enabler Virtuoso
TIBCO Data Virtualization
Zetaris

Zdroje:

TDWI Munchen 2021 konference – Data virtualization in real live projects / Rick F. van der Lans
http://vianovaarchitectura.nl/page/what-is-data-virtualization
Denodo Platform 8.0 – Demo Overview- https://www.youtube.com/watch?v=_ro0bqUQ1J0
Denodo 8.0 Standard Demonstration- https://www.youtube.com/watch?v=qKXkOAcdQl8
TIBCO Data Virtualisation Demonstration – https://www.youtube.com/watch?v=-Sx3ykvVUhs

Mohlo by vás zajímat

Číst další

Chcete nás kontaktovat?

Drop files here or
Max. file size: 2 MB.