Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Datová virtualizace jako součást Business Intelligence
DIPLOMOVÁ PRÁCE
Studijní program: Informační systémy a technologie Studijní obor: Aplikovaná informatika
Autor: Bc. Narek Davtyan
Vedoucí diplomové práce: doc. Ing. Ota Novotný, Ph.D.
Praha, listopad 2020
Prohlášení
Prohlašuji, že jsem diplomovou práci Datová virtualizace jako součást Business Intelligence vypracoval samostatně za použití v práci uvedených pramenů a literatury.
V Praze dne 30. listopadu 2020 ...
Bc. Narek Davtyan
Poděkování
Rád bych zde poděkoval vedoucímu této práce doc. Ing. Otovi Novotnému, Ph.D. za odborné vedení, věnovaný čas a velmi cenné rady při tvorbě této práce.
Abstrakt
Diplomová práce se zabývá datovou virtualizací a možnostmi jejího využití v ekosystému Business Intelligence jakožto nového způsobu datové integrace. Hlavním cílem práce je na základě vybraných dat vytvořit různé verze logických datových skladů realizovaných pomocí zvolených nástrojů umožňujících datovou virtualizaci.
První teoretická část se věnuje datové integraci jako takové a pojmy spojené s datovou integrací, které se zároveň týkají datové virtualizace, a budou tím sloužit jako teoretický podklad pro následnou praktickou část.
Právě datová virtualizace se poté rozebere podrobněji v další části teorie, ve které proběhne analýza celé technologie včetně její architektury, managementu, možnostmi využití, nevýhod oproti jiným způsobům datové integrace a také prozkoumání současného stavu na trhu datové virtualizace.
Praktická část se již bude věnovat samotné tvorbě pilotních řešení logických datových skladů i s popisem využitých dat, průběhem realizace a získaných výsledků. Data využita pro tvorbu datových skladů se budou týkat akciového trhu Spojených států amerických, a to konkrétně vývoji cen akcií indexu S&P 500 a jiných významných indikátorů vývoje akciového trhu. Na závěr dojde k detailnějšímu vyhodnocení výsledků a celého průběhu realizace.
Klíčová slova
Business Intelligence; datová virtualizace; datový sklad; datová integrace; akciový trh
Abstract
Master’s thesis deals with data virtualization and its capabilities of being utilized in the Business Intelligence ecosystem as a new method of data integration. Main goal of the thesis is to create different versions of logical data warehouses that are based on a chosen dataset and with tools enabling data virtualization.
First theoretical part is dedicated to data integration as a whole and terms connected with data integration, while also related to data virtualization, which will serve as a theoretical basis for the subsequent practical part.
Data virtualization itself will be the subject of the next part of this thesis. The technology will be described in detail, including its architecture, management, use cases, drawbacks and with analysis of the current market for data virtualization tools.
The practical part will be focused on developing logical data warehouses, including the description of the datasets used for creation, development progress and gained results. Data used for this development will be about the stock market in the USA, specifically the companies in the S&P 500 index and other significant indicators of the US stock market. In the end there will be final evaluation of the results and the progress of realization.
Keywords
Business Intelligence; data virtualization; data warehouse; data integration; stock market
Obsah
Úvod ... 10
1.1 Cíle práce a způsob jejich dosáhnutí ... 10
1.2 Struktura práce ... 10
1.2.1 Teoretická část ... 10
1.2.2 Praktická část ... 11
1.3 Předpoklady a omezení práce ... 11
1.4 Výstup a přínosy práce ... 11
2 Datová integrace ...12
2.1 Business Intelligence ...14
2.2 Datové sklady ... 15
2.2.1 Vrstvy datového skladu ...16
2.2.2 Dimenzionální modelování ... 17
2.2.3 Logický datový sklad ... 18
2.2.4 Master Data Management ... 18
2.3 ETL – Extract, Transform, Load ...19
2.4 Enterprise Information Integration / Enterprise Application Integration ... 20
2.5 Adaptéry a konektory ... 20
2.6 Trh datové integrace ...21
3 Datová virtualizace ... 23
3.1 Definice ... 24
3.2 Architektura ... 24
3.3 Management ... 33
3.3.1 Bezpečnost ... 33
3.3.2 Výkonnost ... 34
3.3.3 Cache ... 36
3.4 Výhody a možnosti využití ... 37
3.5 Nedostatky ... 39
3.6 Propojení s datovými sklady a Business Intelligence ... 40
3.7 Trh datové virtualizace ... 43
4 Tvorba datových skladů ... 47
4.1 Vybrané nástroje pro realizaci ... 47
4.1.1 Denodo Platform ... 48
4.1.2 PolyBase ... 50
4.2 Data pro implementaci ... 50
4.2.1 Vytvoření dat ... 51
4.2.2 Implementační model ... 52
4.2.3 Popis dimenzionálních a faktových tabulek ... 53
4.3 Kritéria hodnocení ... 55
4.4 Realizace datové virtualizace v Denodo ... 56
4.4.1 Zhodnocení realizace v Denodo ... 66
4.5 Realizace datové virtualizace v PolyBase ... 68
4.5.1 Zhodnocení realizace v PolyBase ... 75
5 Závěr ... 78
6 Reference ... 79
Seznam obrázků
Obrázek 1 Proces konverze datové struktury (vlastní zpracování) ... 13
Obrázek 2 Architektura Business Intelligence (zdroj: (5)) ... 15
Obrázek 3 Rozdíl mezi produkční databází a datovým skladem (zdroj: (5)) ...16
Obrázek 4 Vrstvy datového skladu (zdroj: (8)) ... 17
Obrázek 5 Trh datové integrace podle Gartnera z července 2019 (zdroj: (15)) ...21
Obrázek 6 Tvorba virtuálních pohledů (vlastní zpracování) ... 26
Obrázek 7 Příklad tvorby obalu pro HTML stránku (zdroj: (13)) ... 29
Obrázek 8 Příklady datových zdrojů datové virtualizace a jejich propojení (zdroj: (13)) ... 31
Obrázek 9 Propojenost datové virtualizace s datovými sklady (zdroj: (3)) ... 42
Obrázek 10 Anketa využívání datové virtualizace firmami (zdroj: (23)) ... 45
Obrázek 11 Trh datové virtualizace podle Forrester Research z Q4 2017 (zdroj: (23)) ... 46
Obrázek 12 Komponenty Denodo Platform 7.0 (zdroj: (33))... 48
Obrázek 13 Všechny dostupné datové zdroje Denodo Platform 7.0 (zdroj: (33)) ... 49
Obrázek 14 Implementační model datového skladu amerického akciového trhu (vlastní zpracování) ... 52
Obrázek 15 Hlavní rozhraní Denodo (vlastní zpracování) ... 57
Obrázek 16 Management databází ve Virtual DataPort (vlastní zpracování) ... 58
Obrázek 17 Konfigurace serverů ve Virtual DataPort (vlastní zpracování) ... 58
Obrázek 18 Nastavení datových zdrojů ve Virtual DataPort (vlastní zpracování) ... 59
Obrázek 19 Vytváření vzdálených tabulek ve Virtual DataPort (vlastní zpracování) ... 60
Obrázek 20 Nastavení pohledu ve Virtual DataPort (vlastní zpracování) ... 60
Obrázek 21 Exekuční panel Virtual DataPortu (vlastní zpracování) ...61
Obrázek 22 VQL Shell ve Virtual DataPort (vlastní zpracování) ...61
Obrázek 23 Vytvořené faktové a dimenzionální tabulky (vlastní zpracování) ... 63
Obrázek 24 Graf zobrazující denní vývoj ceny akcií společnosti Microsoft (vlastní zpracování) ... 64
Obrázek 25 Graf zobrazující celkový dluh a HDP USA v milionech dolarů (vlastní zpracování) ... 64
Obrázek 26 Graf zobrazující celkový počet žádostí o nezaměstnanecké pojištění proti průměrné hodinové mzdě všech zaměstnanců v USA (vlastní zpracování) ... 64
Obrázek 27 Společnosti s detailními informacemi (vlastní zpracování) ... 65
Obrázek 28 Graf zobrazující průměrné ceny ropy a benzínu v různých letech (vlastní zpracování) ... 65
Obrázek 29 Graf zobrazující ceny dolaru proti euru a celkové korporátní tržby po zdanění v USA od roku 1999 (vlastní zpracování) ... 66
Obrázek 30 Instalace doplňku PolyBase (vlastní zpracování) ... 68
Obrázek 31 Běžící služby PolyBase (vlastní zpracování) ... 68
Obrázek 32 Extenze datové virtualizace v Azure Data Studio (vlastní zpracování) ... 69
Obrázek 33 Volba datového zdroje v Azure Data Studio (vlastní zpracování) ... 70
Obrázek 34 Spojení s CSV souborem pomocí CData ODBC driveru (vlastní zpracování) ... 71
Obrázek 35 Seznam vytvořených externích zdrojů v SSMS (vlastní zpracování) ... 71
Obrázek 36 Seznam vytvořených virtuálních tabulek a navazujících pohledů (vlastní zpracování) ... 73
Obrázek 37 Dotazování se na vzdálenou tabulku přes PolyBase (vlastní zpracování) ... 73
Obrázek 38 Dotazování se na tabulku přímo ze samotné databáze, ve kterém je uložena (vlastní zpracování) ... 74 Obrázek 39 Dotazování se na vzdálenou tabulku přes PolyBase (vlastní zpracování) ... 74 Obrázek 40 Dotazování se na tabulku přímo ze samotné databáze, ve kterém je uložena (vlastní zpracování) ... 74 Obrázek 41 Vývoj ceny zlata (fialová barva) oproti ceny ropy (oranžová barva) od roku 1986 (vlastní zpracování) ... 75 Obrázek 42 Měsíce, ve kterých bylo prodáno více než 100.000 nemovitostí, sledováno od roku 1963 (vlastní zpracování) ... 75
10
Úvod
1.1 Cíle práce a způsob jejich dosáhnutí
Primárním cílem práce je na základě vybraných dat vytvořit 2 datové sklady dle jednotného modelu, ale vytvořeného pomocí 2 různých nástrojů pro datovou virtualizaci. Tyto realizace pak budou v poslední fázi podrobněji vyhodnocené na základě předem stanovených kritérií.
Data budou vybrána z veřejně dostupných zdrojů a budou převedena do takové formy, ve které bude možná smysluplná realizace datových skladů.
Prvním dílčím cílem práce je pak přehledné představení pojmů spojených s datovou integrací – tj. Business Intelligence, datové sklady, ETL/ELT, Enterprise Information Integration / Enterprise Application Integration a datová virtualizace – s využitím definic nejenom od významných akademických či komerčních publikací, ale také článků od analytických společností. Po představení technologií pak dojde také k porovnání vybraných nástrojů, a s nimi spojené výhody a nevýhody. K tomu budou sloužit jak vlastní zkušenosti s nástroji, tak dostupné informace o možnostech vybraných nástrojů.
Dalším dílčím cílem je analýza a popis dat využitých pro realizaci a návrh architektury datových skladů, které budou dále využity pro konkrétní realizace.
1.2 Struktura práce
Práce bude rozdělena do dvou částí, teoretické a praktické, a ty budou dále vyčleněny do kapitol a podkapitol, které již budou naplňovat cíle práce.
1.2.1 Teoretická část
• Rozebrání pojmu datová integrace a její zařazení v systému Business Intelligence.
• Podrobný popis pojmů spojených s datovou integrací a datovou virtualizací – datové sklady, Master Data Management, ETL/ELT, Enterprise Information Integration / Enterprise Application Integration atd.
• Vymezení datové virtualizace a náhled do smyslu této technologie, tzn. rozebrání její architektury, managementu celé technologie, i s ohledem na bezpečnost a výkon, její možnosti využití, vnímané nedostatky, propojení s datovými sklady a Business Intelligence, a také analýza současné nabídky řešení datové virtualizace na trhu.
Vzhledem k širšímu významu samotného pojmu zde také bude muset dojít k přesnějšímu vymezení.
11 1.2.2 Praktická část
• Podrobnější popis vybraných nástrojů pro realizaci logických datových skladů, odůvodnění výběru těchto nástrojů a shrnutí jejich struktury.
• Návrh architektury logických datových skladů a popis dat použitých pro tvorbu včetně relací mezi tabulkami.
• Stanovení kritérií pro hodnocení a jejich vah určených dle Fullerovy metody vícekriteriálního rozhodování
• Tvorba samotných řešení datových skladů a podrobný popis postupu při tvorbě logických datových skladů.
• Zhodnocení výsledků podle daných kritérií.
1.3 Předpoklady a omezení práce
Na trhu je velké množství nástrojů datové virtualizace či nástrojů které mají funkcionality určené pro virtualizaci dat. A vzhledem k širokému, mnohdy komplikovanému, dělení různých nástrojů, kdy některé nástroje jsou čistě jednotnou platformou datové virtualizace, zatímco jiné jsou pouze doplňkem většího databázového systému, byly nástroje pro následnou realizaci vybrané jak podle hodnocení výzkumnými společnostmi Gartner a Forrester Research (případně dalšími méně významnými zdroji), tak i dle dostupnosti řešení pro akademické/testovací účely. Velkou váhu mělo také subjektivní zhodnocení celkové atraktivity pro práci s nástrojem.
Za omezení se ovšem dá považovat i dostupnost a smysluplnost dat týkajících se kapitálového trhu Spojených států amerických, kdy je sice možné získat velké množství dat z veřejně dostupných zdrojů, ovšem nemusí být v dostatečně kvalitě pro následné využití při tvorbě logického datového skladu. I z tohoto důvodu byla některá data z konečného modelu vypuštěna.
1.4 Výstup a přínosy práce
Hlavním výstupem diplomové práce je vytvoření dvou různých verzí logických datových skladů a následně vyhodnocení těchto výstupů na základě předem stanovených kritérií, která berou v potaz různé dimenze manažerského rozhodování při potřebě implementace technologie do vlastní organizace. Ze samotných realizací budou také vyplývat její výhody i nevýhody pro zařazení do ekosystému Business Intelligence a případného doplnění či nahrazení tradičních datových skladů. Tento výstup tedy může sloužit jako základ pro budoucí výzkum a rozhodování v implementaci datové virtualizace v organizaci čtenáře.
Dalším výstupem je celková analýza technologie datové virtualizace (ale i technologií spojených s datovou integrací), která může sloužit jako první bod studie daných technologií pro čtenáře. Vzhledem k tomu, že konkrétně datová virtualizace není v České republice velice známou technologií, může práce být jedním z prvních představitelů této technologie.
12
2 Datová integrace
Datovou integraci definuje analytická společnost Gartner jako -
„soubor postupů, architektonických technik a nástrojů, které slouží k dosažení konzistentního přístupu a dodání dat přes široké spektrum oblastí datových subjektů a typů datových struktur v organizaci pro dosažení požadavků užívání dat všech aplikací a byznys procesů.“
(1)
Jednodušší definici pak přináší společnost IBM, která datovou integraci označuje za kombinaci technických a byznysových procesů využívaných pro slučování dat z různých zdrojů do smysluplné a hodnotné informace. (2)
Správa pohybu dat mezi systémy, aplikacemi, datovými uložišti nebo organizacemi je kritická pro efektivitu jakékoliv organizace. Je známým faktem, že dostupná a důvěryhodná data jsou důležitým aspektem úspěchu organizací. Proces transformace dat do důvěryhodné podoby je součástí data governance a datové kvality, ale dostupnost dat, tzn. přenos dat do správného místa, ve správném čase a ve správné podobě, je již součástí datové integrace. (3)
Často je nejvíce komplexní částí procesu integrace dat transformace dat do jednotné a společné formy. Pochopení dat a jakých struktur a propojení je potřeba dosáhnout vyžaduje hlubší nejenom technické, ale i byznysové znalosti. Když je určitá aplikace v organizaci nahrazena novou (ať už vlastní či koupenou) aplikací, je pochopitelně potřeba data ze staré migrovat do nové. Nová aplikace může již být v produkčním užití a může shromažďovat nová data. Za nejlepší praxi se považuje vytvoření mezi zdrojovou (starou) a destinační (novou) aplikací vrstvy pro konverzi, ve které bude probíhat správa metadat a vyhledávání transformací. To umožní přenos a transformaci z formátu vyžadujícího zdrojovým systémem do struktury vyžadující destinačním systémem. Díky tomu pak aktualizace dat nemusí probíhat přímou aktualizací cílové datové struktury, ale budou prováděna samotným aplikačním kódem. Někdy ovšem je potřeba při procesu datové migrace působit přímo na cílovou či zdrojovou datovou strukturu. (3)
13
Obrázek 1 Proces konverze datové struktury (vlastní zpracování)
Většina organizacích větší podoby má stovky až tisíce aplikací, každá mající vlastní databázi či jiné datové uložiště. Je proto důležité, aby tyto systémy mohli mezi sebou komunikovat v podobě sdílení dat. Efektivní management datových uložišť je pak často středem pozornosti při plánování informačních technologií. I přes to, že tradiční datová rozhraní byla vyvinuta pro to, aby mezi sebou komunikovaly dvě strany z bodu do bodu, kdy jedna strana data odesílá a druhá odebírá, tak většina požadavků datové integrace zahrnuje vícero aplikačních systémů, která potřebují být v reálném čase informována o změnách v datech. Proto je v podstatě nemožné z pohledu řízení implementovat všechna rozhraní jako řešení „z bodu do bodu“. Dnes existují různá řešení centralizující data pro konkrétní případy užití ke
zjednodušení a standardizování datové integrace pro organizaci. Tyto různé způsoby řešení se budou probírat v následujících částech této práce. (3)
Datová integrace jako taková se těžko rozděluje na typy, i kvůli odlišným způsobům
interpretace samotného pojmu či samotného kontextu, ve kterém se pojem zrovna probírá.
Pokud jej budeme brát jako způsob slučování dat do jedné smysluplné podoby, pak můžeme její podstatu rozdělit na následující přístupy (4):
• Data consolidation (česky datová konsolidace), která dostává data dohromady z různých separátních systému a vytváří jednu verzi dat v jednom datovém uložišti.
Např. ETL technologie podporuje datovou konsolidaci.
• Data propagation (česky datová propagace), což je přístup vyznačující kopírování dat z jedné lokace do druhé. Je tzv. event-driven (řízena událostmi) a může být
synchronní i asynchronní. Příklady podporujících technologií můžou být Enterprise Application Integration nebo Enterprise Data Replication.
• Data federation (česky datová federace), technicky vzato podobná, či někdy i skoro totožná, datové virtualizaci jakožto formy virtuální databáze vytvářející jednotný datový model složený z heterogenních dat z různých systémů. Enterprise Information Integration je příkladem technologie podporující datovou federaci. Ta používá
datovou abstrakci pro poskytnutí jednotného pohledu na data z různých zdrojů.
• Data warehousing, kde data warehouse (česky datový sklad) vyznačuje pouze samotné uložiště ve kterých se data ukládají, ale pojem ve slovesném tvaru se již používá jako
14
implikace pro čištění, přeformátování a ukládání dat, a tudíž se dá považovat jako další typ datové integrace.
• Data virtualization (česky datová virtualizace), která používá rozhraní pro dodávání jednotného pohledu na data z různých zdrojů a z odlišných modelů v reálném čase. Na data se díky tomu díváme jednotně i přes to, že jsou uložena na rozdílných místech.
2.1 Business Intelligence
Samotný pojem Business Intelligence není jakkoliv podřadný datové integraci, představuje totiž sadu procesů, aplikací a technologií, jejichž cílem je účinně a účelně podporovat rozhodovací procesy ve firmě. Podporují analytické a plánovací činnosti podniků a organizací.
(5) Dá se říct, že všechny pojmy a přístupy probírané v této práci spadají právě pod Business Intelligence jakožto pojmu zastřešujícího většinu datových procesů sloužících pro analýzu či plánování.
Samotný termín Business Intelligence zavedl v roce 1989 Howard J. Dresner, který jej popsal jako „sada konceptů a metod určených pro zkvalitnění rozhodnutí firmy“. Vyzdvihuje zde význam datové analýzy, reportingu a dotazovacích nástrojů, které provádějí uživatelé množstvím dat a pomáhají mu se syntézou hodnotných a užitečných informací. (5)
Existuje pak mnoho dalších dodatečných definic, které různě analyzují termín Business Intelligence, ale ze všech jasně vyplývá, že se Business Intelligence orientuje na vlastní využití informací v řízení a rozhodování, nikoliv na základní zpracování dat a realizaci běžných obchodních, finančních a dalších transakcí. (5)
Obecně pak lze Business Intelligence rozdělit do několika vrstev: (5)
• Vrstva pro extrakci, transformaci, čištění a nahrávání dat – do této vrstvy spadají především systémy pro ETL a systémy pro integraci aplikací (EAI)
• Vrstva pro ukládání dat – sem spadají již datové sklady, datová tržiště, operativní datová uložiště a dočasná uložiště dat
• Vrstva pro analýzy dat – zde nalezneme reportingové systémy, OLAP (On-Line Analytical Processing) systémy a činnosti týkající se dolování dat.
• Prezentační vrstva – tady se jedná již o nástroje pro koncové uživatele jako jsou např.
systémy EIS (Executive Information Systems) nebo portálové aplikace založené na WWW technologiích
• Vrstva oborové znalosti – zahrnující oborové znalosti a know-how pro nasazování řešení BI pro konkrétní situaci
Kromě toho pak aplikace BI využívají nástroje pro zajištění datové kvality, nástroje pro správu metadat a obecné technické znalosti (ať už programovací či technologické schopnosti). (5) Celková architektura Business Intelligence vyobrazující její komponenty a vazby je pak následující:
15
Obrázek 2 Architektura Business Intelligence (zdroj: (5))
2.2 Datové sklady
Již před lety bylo jasné, že je potřeba mít databázi pro účely reportingu oddělenou od systémů datových zdrojů. Existuje pro to několik pádných důvodů.
Zdrojové systémy, jako jsou např. systémy pro plánování podnikových zdrojů (tzv. ERP systémy), systémy pro řízení vztahů se zákazníky (tzv. CRM systémy), nebo řízení dodavatelských zásob (tzv. SCM systémy), jsou postavené na systémech zachycování dat a zpracování transakcí. Není zde tudíž prostor optimalizace pro analytiku a reporting. I přes to, že se mohou jejich data zachycovat v relačních databázích, tak je nutné vzít v potaz, že jsou strukturována, logicky i fyzicky, zcela odlišně tak, aby podporovala jejich konkrétní cíl – tvorbu dat. (6)
Data ve zdrojových systémech jsou také často nekonzistentní. Tento fakt může být důsledkem rozdílů ve formách, strukturách, vztazích, byznys definicích nebo transformacích. Datovou nekonzistencí také nemyslíme špatnou datovou kvalitu, jelikož nekonzistence může být někdy validní z perspektivy byznysu, kdežto špatná datová kvalita má vždy negativní podtext.
Konzistentní data jsou důležitým prvkem při tvorbě datových skladů, jelikož bývají kritickým požadavkem byznysových analytiků. Díky tomu vznikl Master Data Management, kterému se práce věnuje v další části. (6)
Samotná datová kvalita vně datových zdrojů je další částím prvkem, kterému se věnujeme při tvorbě datových skladů. V minulosti při začátcích tvorby datových skladů bylo standardem, že datový sklad je pouze read-only (česky ke čtení) a datová kvalita se řešila při stažení zpátky do datových zdrojů. I přes to, že systémy pro zachycování dat se staly sami o sobě kvalitnější a uměly eliminovat špatně zachycená data, datová kvalita a úplnost zůstávají problémem.
Z pragmatického hlediska se datové sklady staly preferovanějším místem pro řízení datové kvality. Datová kvalita se často stává problémem až při užívání v delším horizontu. Pokud jsou
16
data aktuální, zpracování přes zdrojové systémy je bezproblémové. Problémy se skýtají až když se data stávají historickými, a tudíž negativně ovlivňují procesy reportingu. I proto se řízení datové kvality přesunulo do datových skladů. (6)
Obrázek 3 Rozdíl mezi produkční databází a datovým skladem (zdroj: (5))
Za současný všeobecně přijímaný koncept datových skladů můžeme vděčit americkému počítačovému vědci Billu Inmonovi. Ten definuje datový sklad jako „subjektově orientovaná, integrovaná, časově rozlišená a stálá kolekce dat pro podporu procesu manažerského rozhodování.“ (7)
Tuto definici pak můžeme rozebrat následovně: (7)
• Subjektově orientovaný – datové sklady jsou postaveny okolo primární datové entity nebo subjektů organizace
• Integrovaný – datový sklad integruje data z vícero systémů pro poskytnutí širšího pohledu na podniková data
• Stálý – datový sklad je popisován jako dlouhodobá podniková paměť kvůli své stabilní podstatě, kdy data nejsou aktualizována v reálném čase ale v průběhu času.
• Časově rozlišený – data jsou historicky rozlišována a nejsou vždy aktuální
2.2.1 Vrstvy datového skladu
Základní vrstvy datového skladu si pak můžeme rozdělit na následující vrstvy- (8)
• Zdrojové systémy – vrstva, která obsahuje všechna zdrojová uložiště, která se následně integrují do datového skladu. Není přímo součástí datových skladů, jde tudíž spíše o abstraktní vrstvu.
• Přistávací vrstva – prostor mezi zdrojovými systémy a dočasnými uložišti. Zde se nahrávají data ze zdrojů, čemuž napomáhá k tomu, že je zpracování dat oddělené od zdrojových systémů a v plné režii datového skladu, což je výhodné z výkonnostních důvodů. Této vrstvě také náleží jak relační, tak nerelační datové množiny.
• Dočasné uložiště – v této vrstvě probíhá kontrola a příprava dat pro následnou transformaci. Data v této vrstvě můžeme verifikovat. Poté můžeme provést změny dat, pokud neporušují byznysová pravidla, která mají nastavená. Všechna data v této vrstvě jsou také přesnou kopii současných dat ve zdrojovém systému (včetně jejich struktury).
Přistávací a dočasná vrstva může být implementována dvěma způsoby – Asynchronní nahrání a synchronní nahrání. U asynchronního se data stahují do přistávací vrstvy a až poté jsou
17
zpracovány, kdežto u synchronního se zdrojové systémy přímo napojují do dočasného uložiště, čímž se úplně přeskakuje vrstva přistávací. Po těchto vrstvách poté ještě následují: (8)
• Integrovaná datová vrstva – tato vrstva uchovává data v organizované podobě umožňující analýzu a výrobu jiných datových struktur. Do této vrstvy mohou mít uživatelé přístup, ale kvůli tomu, že se zde uchovávají všechna data s celou historií, tudíž se zpřístupňují odfiltrované aktuální záznamy. Vrstva má také 4 důležité charakteristiky – centralizovaná databáze (všechna data ze zdrojových systémů uložena rozdílnými způsoby), historizace dat (možnost analýzy dat z dřívějších období), škálovatelnost datových struktur (možnost rozšíření datových struktur bez nutnosti reorganizace současných) a nezávislost na užití.
• Přístupová vrstva – do této vrstvy se již mohou dostat koncoví uživatelé, jedná se totiž o vrstvu, ve které se vytváří datová tržiště podle požadavků jejich konzumentů. Vrstva obsahuje v první fázi sémantickou databázi, která poskytuje překlad zdrojových databázových struktur na byznys pojmy podle daných pravidel a omezení. Často je tato vrstva zakomponovaná v reportovacím nebo dotazovacím nástroji. Sémantická databáze obsahuje pouze data, jejichž spojením lze vytvořit základní obchodní pojmy.
Data z těchto struktur se následně použijí pro tvorbu datových tržišť, ze kterých se již odebírají data pro analýzu a reporting.
• Vrstva dodání informací – zde se již umožňuje byznysovým uživatelům přístup k datům. Většinou tuto vrstvu rozdělujeme na podvrstvy aplikační a prezentační, kde aplikační podvrstva umožňuje přístup analytickým nástrojům, které vyžadují jinou, pro byznysové uživatele těžko čitelnou, strukturu dat, a prezentační podvrstva umožňuje přímý vstup pro byznysové uživatele, a její struktura dat je pro ně čitelná.
Obrázek 4 Vrstvy datového skladu (zdroj: (8))
2.2.2 Dimenzionální modelování
Jádrem řešení tvorby datových skladů je dimenzionální modelování. Podstatou tohoto procesu je vytvoření základní logiky uložení nebo uspořádání dat tak, aby vyhovovala požadavkům na analytické a plánovací aplikace v rámci podnikového řízení. Při dimenzionálním modelování se definují všechny dimenze (včetně jejich obsahu s vnitřní hierarchií prvků a dílčími
18
charakteristikami jednotlivých dimenzí), soustava sledovaných ukazatelů a specifikují se vazby mezi ukazateli a odpovídajícími dimenzemi. (5)
Pro dimenzionální modelování je charakteristické, že úroveň detailu jeho řešení se může měnit.
Může se také zpřesňovat a konkretizovat v průběhu projektu podle účelu a aktuálních potřeb řešení. Charakteristiky dimenzí jsou následující: (5)
• Identifikace dimenze
• Plný název dimenze
• Hierarchická struktura dimenze
• Prvky dimenze, vyjádřené většinou jejich základní hierarchickou strukturou
• Počty prvků v dimenzi na jednotlivých hierarchických úrovních
• Zdroj dat pro dimenzi, resp. její prvky
• Definování kalkulovaných prvků v dimenzi, které se automaticky promítají do všech přiřazených ukazatelů k dimenzi a zajišťují požadované výpočty
Obecně jsou principy a postupy při modelování dimenzí ovlivněny konkrétním projektem, ale standardně se dodržujeme následující postupy: (5)
1. Výběr a základní obsahové vymezení řešené oblasti podnikového řízení 2. Návrh všech relevantních dimenzí a jejich charakteristik
3. Návrh ukazatelů, jejich dílčích charakteristik a granularity 4. Řešení vazeb mezi dimenzemi a ukazateli
5. Promítnutí řešení do návrhu tabulek dimenzí, návrhu tabulek faktů a návrhu schémat 2.2.3 Logický datový sklad
Výše popsané metodiky a praktiky tvorby datových skladů se již dají pomalu označovat za tzv.
tradiční způsoby tvorby datových skladů, jelikož v posledních letech také vzniká agilnější přístup ke tvorbě datových skladů, nazývaným jako logický datový sklad.
Klasické datové sklady spoléhají na ETL jakožto na prostředníka, který integruje data do skladu a aplikuje transformační procesy. Logické datové sklady pak kvůli stejným důvodům spoléhají na datovou virtualizaci jako jejich prostředníka. Samotná idea spočívá v tom, že se vytvoří model reprezentující všechna data potřebná pro konkrétní doménu, aplikaci nebo analytiku.
Na tento model pak bude možné se dotazovat stejně jako se dotazuje na klasickou databázi. (9)
2.2.4 Master Data Management
S datovými sklady, ale i s datovou virtualizací, je také spjatý pojem Master Data Managementu (dále jen MDM). Ten vyjadřuje potřebu centrálního skladu jako určitý repositář znalostí kritických byznys objektů podniku a navazujících pravidel a procesů. Důležité pro MDM je čistá, normalizovaná verze termínu používaných v podniku – ať už adresy, koncepty či jména – a informace ohledně jejich metadat. Kdykoliv je tedy určitý byznys objekt použitý skrz organizaci, tak by ideálně mělo být možné dohledat data užívaná těmito systémy i v MDM.
Samotná data jsou pak relativně statická (často se nemění) a netransakční, nespadají sem proto
19
objednávky, faktury nebo účetní zápisy. Ve své podstatě je MDM sám o sobě datovým skladem s jednou konkrétní rolí. (10) (11)
Stejně jako u jiných datových skladů, tak i MDM dává svým stakeholderům pohled „z vrchu“
na všechny datové entity a jejich společné reprezentace. Každopádně, MDM repositář je také centrálním uložištěm všech metadat. Uchovává především omezení týkající se byznys objektů.
Tím můžou být referenční data jako jsou třeba stavy objednávky, typ zákazníka, kategorie produktu aj. Při přenosech dat mezi systémy tedy nepřenášíme pouze primární datové entity (zákazníci, produkty...), ale množství dalších entit, které definují jejich vlastnosti. V mnoha případech se na MDM data můžou její vlastníci dotazovat, tudíž tato data mohou implementovat do svých systémů a procesů, což je považováno za způsob, jak vylepšit risk management, rozhodování a analytiku. (10) (11)
2.3 ETL – Extract, Transform, Load
Speciální odlišení od datových skladů si zaslouží také pojem ETL, jakožto všeobecně přijímaný akronym pro slova Extract, Transform a Load (česky extrakce, transformace a nahrání). ETL je jedním ze základních procesů datové integrace, jejíž cílem je zisk dat z aktuálně uloženého místa, změna do kompatibilní formy a nahrání do destinace. Celý význam datové integrace se točí okolo těchto tří základních činů. I přes to, že se jedná o jednoduchý koncept, existuje mnoho odlišných designů a technologických řešení pro implementaci.
Pro provedení „extrakční“ části ETL je potřeba mít přístup k datům v systému nebo datovém uložišti, ve kterém se zrovna nachází. Existují pak dva základní způsoby extrakce: zdrojový systém vytvoří kopii dat, nebo jiný systém (např. specializovaný extrakční systém) vstoupí do zdroje a data odchytí. Výhodou použití v procesu pouze zdrojový systém je především ten, že daný systém, který obsahuje požadovaná data, jim také rozumí a zná technologii, ve kterém jsou uložena. Potenciálně s tím ale můžou vzniknout kapacitní problémy. Často jsou danými systémy produkční databáze, u kterých bychom neměli zatěžovat jejich výkonnost přidáním dalších operací pro zpracování. (3)
Užití specializované extrakční aplikace pro zisk dat ze zdrojového systému má velice malý dopad na zdrojový systém, i když nějaké využití výpočetní techniky probíhá, tudíž zde stále zůstává využití kapacit, byť výrazně menší. V praxi je pak nejefektivnější, když extrakt vytváří technická podpora zdrojového systému, jelikož znalost systému a technologie, ve kterém jsou data uložena, bývají největšími překážkami centralizace vývoje extrakce. (3)
Transformace je pak proces, kterým se data přenášejí do formy kompatibilní s destinačním uložištěm. Ten může být jak extrémně jednoduchý až neuskutečnitelný, případně může vyžadovat sběr dodatečných informací. Transformační proces vyžaduje detailní byznys požadavky, které vlastníci daných dat vyvinuli nebo případně akceptovali, kdežto procesy extrakce a nahrání jsou čistě technické bez jakékoliv potřeby (či velice nízké) příspěvku od byznysu, kromě potřeby potvrzení, že se extrahují správná data. Transformační proces jako takový pak můžeme rozdělit do následujících způsobů (3):
• Jednoduché mapování, kde se textové či číselné hodnoty shodují jak ve zdroji, tak i v destinaci, a tudíž se musejí pouze zmapovat.
20
• Lookupy (česky vyhledání), kde ve zdroji může daná hodnota obsahovat pouze jeden
• Agregace a normalizace, kdy cílová datová struktura může vyžadovat zisk více částí dat ze zdroje, které můžou být v různých strukturách. To znamená, že jeden řádek ze zdroje může sloužit k mapování vícero hodnot v destinaci, nebo naopak. Jedná se o komplexnější formu transformace.
• Kalkulace, kdy cílová struktura vyžaduje kalkulaci zdrojových dat, aby v něm mohla být uložena, jelikož zdrojová data nesplňují nároky destinace.
„Loadovací“ část ETL procesu již zajišťuje to, že se data dostanou do cílové destinace. Existují debaty o tom, zda není efektivnější tuto část mít před transformační částí (a tudíž mít ELT proces), a jedná se o velmi relevantní diskuzi, jelikož se bere v potaz objemnost dat a rychlost zpracování dat. Je tedy možné dnes nalézt softwarová řešení preferující ELT způsob před ETL, a také mnoho organizací, která toto řešení upřednostní před klasickým ETL. (3)
Samotný proces nahrávání dat ale má stejně jako proces extrakce také dva způsoby přístupu – napsání kódu pro nahrání dat napřímo nebo upřednostnění existujícího aplikačního kódu pro nahrání dat do destinačního uložiště. Doporučované je upřednostnění existujícího kódu, jelikož tento kód má v sobě zakomponované znalosti o tom, jak má datová struktura v destinaci být. (3)
2.4 Enterprise Information Integration / Enterprise Application Integration
Dalším důležitým pojmem spjatým s datovou virtualizací, resp. datovou integrací, je také Enterprise Information Integration (dále jen EII, česky integrace podnikových informací).
S tímto pojmem je příbuzný také jiný pojem, se kterým si ho nesmíme plést, a to Enterprise Application Integration (česky integrace podnikových aplikací). Ten má cíl definovaný jako integraci primárních podnikových systémů a redukování počtu jejich vzájemných rozhraní.
Především tedy spojuje systémy a jejich transakce. Jednoduše řečeno „lepí“ různé systémy, které by spolu měly komunikovat, ale nekomunikují. (5) (12)
Oproti tomu EII naopak typicky sbírá informace z různých systémů a spojuje je dohromady.
Obecně se považuje za proces integrace informací pomocí datové abstrakce pro poskytnutí jednotného rozhraní pro pohled na všechna data vně organizace, která mají jednotnou strukturu a jmenné konvence pro reprezentaci daných dat. Tato definice je velice podobná datové virtualizaci a celkově by se pojem EII dal považovat i za synonymum k datové virtualizaci, jelikož její účel je jedním z účelů datové virtualizace. (12) (13)
Oba tyto systémy jsou typem middleware, tj. programových vybavení, které umožňují komunikaci dvou a více aplikací mezi sebou. Předpokladem je, že se tyto aplikace nedokážou propojit mezi sebou napřímo a je tedy potřebné mezi ně vložit spojovací článek.
2.5 Adaptéry a konektory
Pro přístup k datům uložených v jednom datovém zdroji, abychom je mohly konzumovat v jiné službě datové integrace a nahrávat do cílových zdrojů, potřebujeme také určité konektory. Ty
21
jsou svým způsobem také dalším typem základního middleware, které umožňují čtení a zapisování do různých strukturovaných, semistrukturovaných a nestrukturovaných datových struktur. (6)
Open database connectivity (ODBC) a Java database connectivity (JDBC) jsou široce využívané v relačních databázích a jiných strukturovaných zdrojích. ODBC bylo vytvořené Microsoftem jako rozhraní využívané aplikacemi Windowsu pro přístup do databází pomocí SQL. (14) JDBC bylo pro stejný účel vytvořeno firmou Sun Microsystems pro zpřístupnění aplikací na bázi Java pro přístup k databázím. Existují i další API (application programming interfaces) pro čtení a zapisování prostých databázových souborů, XML, byznys aplikace, Big Data databáze, cloud aplikace, REST služby a mnoho dalších zdrojů. Počet API se kontinuálně zvětšuje s množstvím nových typů datových zdrojů. Mnoho nástrojů datové integrace také umožňuje vytvoření přizpůsobených webových služeb pro přístup k datovým zdrojům, které nemají tyto možnosti v sobě interně integrované. (6) (14)
2.6 Trh datové integrace
Analytická společnost Gartner každoročně vydává analýzu trhu nástrojů datové integrace, pro kterou vytváří svojí charakteristickou „magic quadrant“ (česky magický kvadrant). Trh definuje jako všechny nástroje poskytovatelů, které umožňují konstrukci a implementaci přístupu k datům a infrastrukturu pro dodání různých integračních případů užití.
Obrázek 5 Trh datové integrace podle Gartnera z července 2019 (zdroj: (15))
22
Není překvapením, že i na trhu datové integrace dominují známé korporace, které se vyskytují i v hodnoceních jiných oblastí nabídky IT software. Firmy jako Informatica, IBM, SAP, Oracle nebo SAS jsou na trhu datové integrace tzv. lídry, čímž Gartner označuje značky, které nejvíce splňují dva sledované parametry – completeness of vision (česky naplnění vize) a ability to execute (česky schopnost provedení), kde v obou parametrech nejsilněji vychází americká firma Informatica. (15)
Nutno také poznamenat, že se do pozitivních hodnocení dostaly i nástroje datové virtualizace (jako např. Denodo Platform nebo TIBCO Data Virtualization), případně nástroje, které v sobě mají zakomponované možnosti datové virtualizace (např. SAP HANA nebo Oracle Data Integrator) což může značit zvyšující popularitu datové virtualizace jako takové v oblasti datové integrace. Nováčky v seznamu nástrojů datové integrace pak byly firmy Qlik (díky akvizici firmy Attunity a její platformy datové integrace) a SnapLogic. (15)
Gartner ve svém hodnocení také předpovídá, že do roku 2021 bude přes 80 % organizací využívat více možností dodávání dat pro provádění datové integrace. Očekává se také snížení počtu manuální činností datové integrace pomocí machine learningu a automatizace. (15) Pro to, aby mohly firmy být zahrnováni v kvadrantu musí technologické portfolio firem mít určité schopnosti, a to alespoň tři z následujících technických způsobů dodání dat: (15)
• Pohyb dat v bulk/batch
• Orchestrace datových služeb
• Datová virtualizace
• Datová replikace
• Datová synchronizace
• Pohyb dat pomocí zpráv
• Toková datová integrace
Nástroje dodavatelů by také měly mít podporu pro datové transformace, podporu pro data governance, designové a vývojové schopnosti (např. verzování kódu), podpora pro
Windows/UNIX/Linux, možnost nasazení funkcionality jako službu, možnost datového modelování, synchronizace a skladování metadat a možnost specifikování rolí pro vývoj. (15) Nakonec musí dodavatelé splňovat kvantitativní podmínky pro zahrnutí do kvadrantu, a to minimální tržby v hodnotě 30 milionů amerických dolarů, prezence na trhu (tj. subjektivní zhodnocení aktivity v rozvoji značky na trhu) a také podpora pro uživatele alespoň dvou z následujících světových regionů – Severní Amerika, Jižní Amerika, Asie/Pacifik nebo EMEA (souhrnná zkratka pro Evropu, Dálný východ a Afriku). (15)
I kvůli výše zmíněným kritériím je tedy možné, že se mnoho nástrojů datové virtualizace nedostalo do hodnocení celkového trhu datové integrace.
23
3 Datová virtualizace
Samotný pojem datové virtualizace je často nesprávně interpretovaný. Je snadné nalézt tento pojem spojený s jinými koncepty, například jako synonymum k výše zmíněné Enterprise Information Integration, tj. v našem kontextu technologie umožňující jednotný pohled na organizační data. To je sice v určité míře pravdou, platformy datové virtualizace umožňují pohled na všechna organizační data, není to ovšem přesná definice. Datová virtualizace je pojmem komplexnějším, jelikož v sobě obsahuje také určité části jiných konceptů.
Jedním z hlavních konceptů je tzv. zapouzdření. Zapouzdření v informačních technologiích můžeme obecně chápat jako určité „skrytí“ interních detailů vnitřku před dalšími objekty a přístup k nim pouze externím pohledem. Ve světě databází to jde přeložit jako skrytí implementačních aspektů datových uložišť, jako například lokace, přístupové mechanismy nebo API. Datový konzumenti pak vidí pouze jednoduchý interface pro přístup k datům a nemusí se zabývat technickými detaily pokrývající backend systému. (13)
Abstrakce je pak dalším konceptem blízce spojený s datovou virtualizací. Pokud si vezmeme její definici od D. T. Rosse, který abstrakci pokládá za proces, kterým identifikujeme důležité aspekty fenoménu a ignorujeme její detaily, můžeme koncept přiřadit k datové virtualizaci jako další její součást, jelikož ve světě databází můžeme abstrakci chápat jako skrytí nerelevantních tabulek, sloupců a řádků, které datový konzument vidět nepotřebuje. Vidí pouze agregované a předpřipravené sety relevantních dat. Tyto implementace se ve většině SQL databázových systémech nazývají jako views (tj. pohledy), které jsou základním kamenem datových virtualizací. (13)
Často je datová virtualizace spojována také s datovou federací (koneckonců bylo i období, kdy se datové virtualizaci říkalo servery datové federace, jelikož to byly produkty, které spojovali několik databází do jedné společné podoby), které vyznačuje spojování různých heterogenních datových uložišť do jedné společné formy. To je jedním z nejdůležitějších aspektů datové virtualizace, ovšem ne vždy datová virtualizace splňuje podmínky datové federace, například při potřebě virtualizace pouze jednoho konkrétního datového uložiště. Je zde také kladen na důraz autonomii datových uložišť, kdy přístup k různým datovým uložištím neznamená, že tato uložiště jsou již trvale navázaná na přístup a úpravy pouze přes „federaci“, tj. může se k nim přistupovat i samostatně bez jakéhokoliv napojení na datovou federaci (a tudíž i bez napojení na datovou virtualizaci). Dále je důležitá integrace, ve smyslu spojení všech datových uložišť tak, aby byla prezentována jako jedna součást, a rozdíly mezi datovými uložišti nebyly znát.
(13)
S datovou federací a datovou virtualizací je také propojen pojem datové integrace, kterým se práce zabývala v předešlé části. Ten vyznačuje proces samotné kombinace dat z heterogenních datových uložišť a z nich vytvoření jednotné formy datového uložiště.
24
3.1 Definice
Datová virtualizace byla již definována mnohokrát vícero zdroji, jak samostatně, tak i pod taktovkou pojmu datová federace. První z významných definic datové virtualizace ale můžeme nalézt v knize Ricka F. van der Lanse -
„Datová virtualizace je technologie, která nabízí datovým uživatelům unifikovaný, abstraktní a zapouzdřený pohled pro dotazování a manipulování s daty uloženými v heterogenním setu datových uložišť.“ (13)
Tato definice popisuje celou technologii a odděluje jí od dalších pojmů spojených s datovou virtualizací. Je to totiž technologie, která nabízí jeden propojený a zapouzdřený pohled na data, a tudíž uživatelé nemusí vědět odkud přesně data pocházejí, kde jsou uložená a jak jsou uložiště strukturovaná. Je to také stále abstraktní pohled, což znamená, že to jsou vždy pouze relevantní data agregovaná na takové úrovni, na které jí uživatelé potřebují. Část manipulování s daty pak zdůrazňuje, že se uživatelé na data mohou nejen dotazovat, ale také na nich využívat DML techniky (tj. ukládání, mazání a update dat).
Další významnější definici můžeme brát od webové stránky techopedia.com, která technologii definuje jako proces agregování dat z různých informačních zdrojů k vytvoření jednotného, logického a virtuálního pohledu na informace, aby mohla být přístupná aplikacemi, dashboardy a dalšími portály, aniž by musela vědět přesné lokace uložišť. (16)
Nakonec také nejstručnější definice od společnosti Informatica, která má definici pouze jako –
„Datová virtualizace je technika využívaná pro poskytnutí abstrakční složky mezi daty a jejími detaily, jako např. její lokace.“ (17)
3.2 Architektura
Objekty, které uživatel vidí na platformě datové virtualizace, mají často rozdílné názvy podle daného produktu. Nejčastěji se v nich vyskytuje slovo view (např. derived view, česky odvozený pohled), případně jsou nazývány jako logické datové objekty. Stejně tak si různé platformy pojmenovávají i data, ke kterým přistupují, ať už jako fyzický datový objekt, základní pohled nebo zdrojová tabulka. (13)
Zdrojovou tabulkou může být tabulka v SQL i NoSQL databázi, datové sklady, externí data z webových zdrojů, klasický flat file, HTML stránka nebo i PDF soubory. Ne všechny tyto zdroje také musejí být nutně tabulkami.
Převod do virtuální formy pak nazýváme mapováním. To znamená, že se platforma spojuje s externím zdrojem, ze kterého bere data a přetváří do virtuálního pohledu pomocí mapovacího procesu. (13)
Aby se zdrojová tabulka mohla stát zdrojem pro virtuální pohled, musí nejprve být importována. Importování zdrojové tabulky znamená, že se spojuje se samotným serverem datové virtualizace. Tento proces je jednoduchý, pokud je zdrojem klasická SQL databáze, kdy se stačí přihlásit na server datové virtualizace, odkud se spojí s databází, a v ní se platforma
25
datové virtualizace dostane do katalogu databáze. Katalog popisuje všechny tabulky a sloupce nacházejících se v databázi. Z tohoto katalogu se pak vybírá požadovaná tabulku, z níž platforma datové virtualizace extrahuje metadata a ukládá si je ve svém vlastním katalogu. (13) Při označení importu zdrojové tabulky také dochází k transformaci některých hodnot do více standardizované formy kvůli různorodosti způsobu ukládání hodnot v rozdílných datových typech (např. hodnoty uložené v MSSQL jako SMALLINT/TINYINT nebo i INT se v platformě datové virtualizace převedou do jednotného datového typu INTEGER). To znamená, že pro virtualizaci se musí hodnoty zkontrolovat, zda je možné je transformovat do známé formy, aby platforma dokázala rozumět všem hodnotám, které u sebe bude „ukládat“. (13)
Při importu dat server datové virtualizace také stahuje metadata a připojuje je k definici daných pohledů, která se vztahují k importovaným tabulkám. Metadata mohou být ohledně:
• Sítě, ze kterého zdrojové tabulky pocházejí
• Podrobný popis databázového spojení
• Název, vlastníka a datum tvorby zdrojové tabulky
• Struktura zdrojové tabulky, včetně sloupců a jejich názvů
• Pro každý sloupec zdrojové tabulky její datový typ a NULL specifikace (jestli je může či nemůže obsahovat)
• Dostupnost primárních a cizích klíčů
• Počet řádků ve zdrojové tabulce
Po úspěšném importu je pak obsah virtuální pohledy v platformě datové virtualizace totožný se zdrojovou tabulkou, a jde se na ní také stejně i dotazovat pomocí různých nadstaveb SQL.
(13)
Celý tento proces definice virtuální pohledy právě nazýváme jako mapování. Mapování definuje strukturu virtuálního pohledu a jak se data ze zdroje mají transformovat, aby se stala virtuálním pohledem. Proces obsahuje operace jako zvolení řádků, zvolení sloupců, spojování a odpojování sloupců od sebe, změna názvů tabulek a sloupců aj. Bez mapování virtuální pohled nebude nic obsahovat a nebude tedy být moci dotazována nebo aktualizována. (13) Mapování může být jednoduchým, ovšem i velice komplexním procesem. Pokud se například mapuje virtuální pohled složený z dat pouze z jedné SQL databáze bez jakýchkoliv dalších agregací, není tam mnoho prostoru pro komplexitu procesu. Ovšem při mapování z více typů zdrojů do jednoho virtuálního pohledu, a v něm provádění dodatečně náročné transformace, se komplexita procesu značně zvyšuje. Druhy možných transformací v datových virtualizacích jsou následující - (13)
• Filtrování řádků zdrojové tabulky
• Spojení dat z různých tabulek
• Sloupce ze zdrojové tabulky mohou být smazány z virtuálního pohledu
• Aplikace funkcí na manipulaci string hodnot
• Spojování sloupců ze zdrojové tabulky
• Změna názvů ze zdrojové tabulky
• Vytvoření nových, případně odvozených, sloupců ve virtuálním pohledu
26
• Využití statistických funkcí
• Čištění „špatných“ dat
• Sortování dat
• Využití ranking funkcí (číslování řádků)
• Pokročilejší funkce jako deduplikace, fuzzy joiny, analýza chování nebo volání externích funkcí napsaných v jiném kódu
Některé platformy nabízejí možnost virtuálních pohledů, které nejsou propojeny s žádnou zdrojovou tabulkou. To znamená, že si vývojář nadefinuje vlastní tabulku již na serveru datové virtualizace tak, jak ji chce mít (bez procesu mapování), a může si tím namodelovat strukturu svého datového skladu. Je ovšem pochopitelné, že do těchto tabulek v tom případě nemůže uživatel vstoupit a dotazovat se na ně. (13)
Stejně jako v klasických SQL databázích se můžeme odkazovat v jednom pohledu na jiný pohled, můžeme i v datové virtualizaci využívat tzv. nested virtual views (česky vnořené virtuální pohledy), což jsou virtuální pohledy, které se odkazují na jiné virtuální pohledy.
Výhodou pak může být, že se sdílejí metadata tabulek, což znamená, že například virtuální pohled V1 obsahuje specifikace, které využijí dva různí konzumenti, ale virtuální pohled V2 a V3
již obsahují konkrétní specifikace pro konkrétní potřeby daných konzumentů. (13)
Obrázek 6 Tvorba virtuálních pohledů (vlastní zpracování)
Co se týče importu nerelačních dat (tzn. data, která nejsou strukturována sloupci popisujících obsah řádek) do vrstvy datové virtualizace, bude to již proces více komplexní než v případě SQL databází.
27
XML dokument je kvůli své jednoduchosti využití široce využívaným způsobem ukládání dat, je tedy nezbytné pro něj mít možnost integrace i v datové virtualizaci.
XML má hierarchickou strukturu elementů s možností opakujících se skupin. To znamená, že třeba na následujícím příkladu má nejvyšší hierarchii element skupiny Customers (tzv. kořen) a na ní se vztahují již jednotlivé elementy Customer. Ty pak mají pod sebou elementy se skupinami Orders, které obsahují elementy Order. (18)
Výpis 1 Ukázka XML kódu (zdroj: (18))
<Customers>
<Customer CustomerName="Arshad Ali" CustomerID="C001">
<Orders>
<Order OrderDate="2012-07-04T00:00:00" OrderID="10248">
<OrderDetail Quantity="5" ProductID="10" />
<OrderDetail Quantity="12" ProductID="11" />
<OrderDetail Quantity="10" ProductID="42" />
</Order>
</Orders>
<Address> Address line 1, 2, 3</Address>
</Customer>
<Customer CustomerName="Paul Henriot" CustomerID="C002">
<Orders>
<Order OrderDate="2011-07-04T00:00:00" OrderID="10245">
<OrderDetail Quantity="12" ProductID="11" />
<OrderDetail Quantity="10" ProductID="42" />
</Order>
</Orders>
<Address> Address line 5, 6, 7</Address>
</Customer>
<Customer CustomerName="Carlos Gonzalez" CustomerID="C003">
<Orders>
<Order OrderDate="2012-08-16T00:00:00" OrderID="10283">
<OrderDetail Quantity="3" ProductID="72" />
</Order>
</Orders>
<Address> Address line 1, 4, 5</Address>
</Customer>
</Customers>
Tento koncept hierarchie a opakujících se skupin v klasických SQL databázích nemá svůj ekvivalent. Může se tedy musí použít proces flatteningu (česky zploštění), kdy se hierarchický model převede do formátu klasické „ploché“ tabulky, ze kterého pak bude možné dotazovat pomocí SQL jazyka. V našem případě by tedy příklad výše mohl být převeden třeba do následujícího stylu (13)
28
Tabulka 1 Zploštění XML struktury do tabulkové struktury (vlastní zpracování)
ORDER_ID PRODUCT_ID CUSTOMER_ID ORDER_DATE QUANTITY
10248 10 C001 2012-07-
04T00:00:00
5
10248 11 C001 2012-07-
04T00:00:00
12
10248 42 C001 2012-07-
04T00:00:00
10
10245 11 C002 2011-07-
04T00:00:00
12
10245 42 C002 2011-07-
04T00:00:00
10
10283 72 C003 2012-08-
16T00:00:00
3
Ne vždy se ovšem musí vyžadovat zploštění XML struktury, pokud by konzumentem byla webová služba (tj. data bychom nepotřebovali převést do formy čitelné pro SQL), může se ponechat hierarchická struktura, jelikož webové služby umí číst hierarchické struktury.
U JSON dokumentů, které vděčí za popularitu svojí rychlostí rozboru (parsování), pak probíhá podobný proces jako u XML, jelikož mají také charakteristicky hierarchickou strukturu a skupinové rozdělení. I zde se tedy zplošťuje do tabulkové formy.
Další podobné typy nestrukturovaných dat, jako jsou např. HTML stránky nebo Resource Description Frameworky (RDF’s), se pak do datové virtualizace přenášejí ještě o něco komplexnějším způsobem. Např. HTML stránky mají v sobě schované obrovské množství dat, které se vytahují tzv. web scrapingem (např. pomocí jazyka Python) a přenáší se do čitelnější formy. V datové virtualizaci se tento proces provádí také, musí se ale správně nadefinovat obal, který data přenese do tabulkové podoby. Vyvinutý kód, který umí navigovat v dané HTML stránce, pak přebírá ze stránky elementy a položky a zapisuje je do virtuálního pohledu. Musí také umět vyskakovat na další stránky, pokud je to potřeba. Tento proces není prostý a není zdaleka tak jednoduchý, jako v případě definování obalu pro převod XML dokumentu. (13)
29
Obrázek 7 Příklad tvorby obalu pro HTML stránku (zdroj: (13))
Webové služby dávají přístup externím datům jako jsou demografická data, data o počasí, ceny produktů a služeb a jiná komerční či nekomerční data. Komunikace je pak založena na platformě nezávislých standardech – především jazyka XML a protokolu HTTP. Nejznámějším je v tomhle směru protokol SOAP (Simple Object Access Protocol). Aplikace si mezi sebou posílají XML zprávy, které přenášejí dotazy a odpovědi jednotlivých aplikací. K popisu služeb slouží jazyk WSDL (Web Services Definition Language), který je založený na XML a popisuje, jak se se službou spojit, kde se nachází, jakou zprávu služba očekává a kterou poskytuje.
V tomhle směru je tedy převod do datové virtualizace podobný jako u výše zmiňovaného převodu XML dokumentů. Jediný rozdíl u webových služeb je potřeba definovat vstupní parametry. (13)
Výpis 2 Příklad SOAP (zdroj: (13))
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="urn:x-example:services:StockQuote">
<symbol>MOT</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Dalším známým typem webové služby je také REST (Representational State Transfer), který je rozdílný SOAP protokolu především v tom, že je protokolově nezávislý. Může využívat JSON nebo XML a struktura zasílaných zpráv není nikde definována (struktura služby může být
30
definována jazykem WADL, není ovšem vyžadována). REST je díky své jednoduchosti velmi oblíbená a mnohdy i preferována před SOAP protokolem.
Listové tabulky, jako jsou například populární Microsoft Excel nebo Google Sheets, jsou také jedním z nejrozšířenějších způsobů ukládání dat. Zde je už ale velká podoba s relačními tabulkami, jelikož se sloupce listu dají rozeznat jako sloupce pro virtuální pohled a řádky listu jako řádky pro virtuální pohled. Není zde potřeba provádět komplexnější procesy pro převod do datové virtualizace. Je tu ovšem rozdíl v počtu metadat, kdy listové tabulky nemají dostatek metadat pro ulehčení práce vývojáři při tvorbě logického datové skladu, ne vždy tedy platforma datové virtualizace přesně rozezná přesné sloupce a přesné řádky listové tabulky pro převod do virtuálního pohledu. (13)
NoSQL databáze, kterými značíme nové generace databázových serverů jako jsou např.
Hadoop, MongoDB, Oracle NoSQl nebo CouchDB, se již do virtuálního pohledu převádějí složitěji. Jsou to, většinou, open source databáze, které nepodporují klasický SQL (jak vidno od samotného názvu) a neukládají se v relační formě, ale ve formě jiného druhu – grafové, dokumentové, klíč-hodnota nebo sloupcově – což jsou struktury, které jim umožňují vyšší rychlost, dostupnost, škálovatelnost a celkovou jednoduchost. Jsou také designovány tak, aby udržely nadměrně vysoké množství dat. NoSQL databáze často nejsou kompatibilní s analytickými nástroji, není tedy možné z nich napřímo vytahovat konkrétní data pro detailnější analýzu. Často je řešením přenos NoSQL dat do SQL databází a v nich transformace do analyzovatelné podoby, to je ovšem časově náročné a cenné řešení problému, byť v dnešní době populární. V tomto směru může být řešením přenos NoSQL dat do datové virtualizace a v ní transformovat data do použitelné formy. I zde často musí datová virtualizace použít proces zploštění podobně jako u XML a JSON formátů. (13)
I samotná nestrukturovaná data, která nejsou naimplementovaná v NoSQL databázích, se mohou převádět do datové virtualizace. Jsou to data, která nemají přesně stanovený způsob interpretace. To znamená, že dva lidé mohou jednu věc interpretovat různě. Může se jednat třeba o Word dokumenty, e-maily, obrázky, videozáznamy, audiozáznamy či údaje ze sociálních médií (např. tweety ze Twitteru). I zde se musí definovat obal pro vstup do nestrukturovaných záznamů, aby se mohla vytáhnout data ve formě možné pro dotazování.
(13)
31
Obrázek 8 Příklady datových zdrojů datové virtualizace a jejich propojení (zdroj: (13))
Po definici virtuálních pohledů je potřeba je také zveřejnit uživatelům pro další práci. Různí uživatelé můžou vyžadovat různé způsoby připojování, většina platforem pro datovou virtualizaci ovšem poskytuje široký výběr možnost pro připojení, z nichž nejpopulárnější bývají: (13)
• SQL s ODBC
• SQL s JDBC
• SQL s ADO.NET
• SOAP/XML přes HTTP
• ReST (Representational State Transfer) přes JSON
• ReST with XML
• ReST with HTML
• JCA (Java Connector Architecture)
• JMS (Java Messaging Service)
• Java (POJO)
• SPARQL
Proces zveřejnění bývá jednoduchý a je možné pro každý virtuální pohled zpřístupnění vícero rozhraní pro uživatele, tj. do jedné tabulky se může uživatelem vstupovat jak přes SQL/JDBC, tak i přes SOAP. (13)
32
Další otázkou je, zda je možné data v tabulkách datové virtualizace možné měnit (tj. upravit, smazat či přidat manuálně nové řádky)? To záleží na vícero faktorech, nejdůležitější je ale právě zdroj, ze kterého tabulka vychází. Je-li zdrojem externí HTML stránka, tak úpravy nebudou možné, jelikož to vychází ze samotné definice těchto stránek. Stejně tak ani data z multidimenzionálních modelů nebude možné upravovat z prostředí datové virtualizace.
Naopak u SQL či NoSQL databází takový problém být s největší pravděpodobností nenastane.
(13)
Následujícím faktorem jsou přístupová práva, tj. zda má server datové virtualizace povolení k úpravě zdrojové tabulky? Ne vždy jsou administrátoři tabulek v datové virtualizaci zároveň administrátory zdrojů, ze kterých tabulky pocházejí. Musí se tedy pohlídat i tento faktor a nastavit správná přístupová pravidla pro všechny skupiny uživatelů. (13)
Třetí náležitostí je pak vztah řádků virtuálního pohledu ke zdrojové tabulce. To znamená, že pokud je jeden konkrétní řádek totožný se svým protějším zdrojem (všechny sloupce i hodnoty v řádku), můžou pak být prováděny změny. Pokud je ale virtuální pohled složen z vícero různých zdrojů, vytvářel se v ní složený sloupec nebo data jsou agregovaná, pak manuální změny řádků v ní nebude možno provést. (13)
Stejně jako jiné databázové servery i datová virtualizace podporuje transakce. Tím rozumíme proces, kdy se sekvence činností provádí uceleně jako jedna transakce. Takové transakce pak mají vlastnosti ACID – atomicita, konzistence, izolovanost a trvalost. Transakce zde budou fungovat dobře, pokud je zdrojem SQL databáze, kde většina z nich podporuje robustní transakční mechanismy, ovšem horší je to u jiných datových uložišť. Kupříkladu u zdroje přes webové služby by při transakcích došlo k trvalé změně bez možnosti rollbacku (česky navrácení). Je zde ovšem mechanismus kompenzace, který zajišťuje, že při transakci, který ukládá data, se spustí kompenzační transakce, která ta data smaže, ale potom je zase vloží do tabulky. Jedná se ovšem o složitější mechanismus vyžadující náročný vývoj pro správnou funkci. (13)
V úvahu je také potřeba vzít co se stane s tabulkami v datové virtualizaci, pokud se změní struktura zdrojové tabulky. Pokud se změní název tabulky, přejmenuje se nějaký sloupec v tabulce, přidá se do ní nový sloupec, smaže se nějaký sloupec a znovu se vytvoří s jiným datovým typem, co se pak stane s pohledem v datové virtualizaci? Řešením by měla být synchronizace, tj. periodické kontrolování rozdílů metadat mezi zdrojovou tabulkou a virtuálním pohledem. Pokud by byla detekována změna mezi tabulkami, záleželo by na reakci administrátora datové virtualizace, jak by chtěl reagovat. Možnosti jsou pak následující: (13)
1) Smazat obal vztahující se k zdrojové tabulce
2) Obal převést do nefunkčního stavu, ale ne smazat. To znamená, že obal je stále propojený se zdrojovou tabulkou, není ovšem přístupný a virtuální pohledy, které z ní tahají data, musí být upraveny, jinak zůstanou nefunkční.
3) Změny jsou automaticky postoupeny i do virtuálního pohledu. Platforma datové virtualizace změny navrhne administrátorovi, který pak musí rozhodnout o aplikaci změny.
