Architektura - Datová virtualizace - Hlavní práce71079

3 Datová virtualizace

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

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

• 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í.

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))

<OrderDetail Quantity="3" ProductID="72" /> 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)

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 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)

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">

</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

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)

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)

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 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.

In document Hlavní práce71079_davn00.pdf, 2.6 MB Stáhnout (Stránka 24-33)