MODERNÍ DATABÁZE 2012 ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ 24. ročník

Transkript

1 KOMIX s.r.o. vydává sborník z konference MODERNÍ DATABÁZE 2012 ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ 24. ročník Hlavní téma: Zpracování velkých objemů dat a transakcí 11. října 2012 Konferenční centrum CITY TOWER, Praha Editor: Barbora Culková, KOMIX s.r.o.

2 Moderní databáze Architektura informačních systémů je tradiční česká konference, která si klade za cíl monitorovat trendy vývoje informačních technologií a architektury informačních systémů. Na konferenci dochází k výměně zkušeností a znalostí odborníků z řad dodavatelů informačních technologií, jejich zákazníků a akademického světa. KOMIX s.r.o., 2012 ISBN: Autoři jsou uvedeni v obsahu. Příspěvky jsou publikovány ve tvaru, v jakém je dodali autoři, bez podstatných změn.

3 OBSAH NOSQL DATABÁZE - SOUČASNÝ STAV VÝVOJE. 1 Prof. RNDr. Jaroslav Pokorný, CSc., Matematicko-fyzikální fakulta Univerzity Karlovy MODELOVÁNÍ XML SCHÉMAT. 12 Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý, Matematicko-fyzikální fakulta Univerzity Karlovy INTEGROVANÉ SYSTÉMY ORACLE PRO SVĚT SQL I NOSQL. 24 Josef Krejčí, ORACLE Česká republika NETEZZA - TO PRAVÉ ŘEŠENÍ PRO ANALYTICKÝ DATOVÝ SKLAD 31 Martin Pavlík, IBMm Česká republika INFORMIX WAREHOUSE ACCELERATOR.. 40 Jan Musil, IBM Česká republika ZPRACOVÁNÍ PROUDŮ DAT O UDÁLOSTECH V REÁLNÉM ČASE Jiří Gregor, Galeos, a.s. LINKED DATA A JEJICH APLIKACE V PRAXI. 54 Mgr. Martin Nečaský, Ph.D., Matematiko-fyzikální fakulta Univerzity Karlovy SDMT - ZPRACOVÁNÍ DAT S VELMI SLOŽITOU STRUKTUROU.67 Ing. Jan Vrána, KOMIX s.r.o.

4 NoSQL databáze současný stav vývoje , Praha Jaroslav Pokorný, MFF UK NoSQL databáze současný stav vývoje Jaroslav Pokorný MFF UK Malostranské nám. 25, Praha 1 Tel: pokorny@ksi.mff.cuni.cz www: Klíčová slova: NoSQL databáze, cloud computing, CAP teorém, slabá konzistence, horizontální škálování, Abstrakt: Motivací pro NoSQL databáze je dosažení horizontální škálovatelnosti databázového zpracování v dynamickém prostředí distribuovaných databází, které obsahují semistrukturovaná data bez pevného databázového schématu. Popíšeme základní charakteristiky těchto databází se zřetelem na jejich datový model, možnosti dotazování, implementaci a transakční zpracování. Ukážeme rovněž zatím spíše kontraverzní postavení NoSQL databází v architektuře informačního systému podniku. Závěrem zmíníme alternativy k NoSQL, zejména ve vztahu k relačním databázím, tj. NewSQL databáze, které splňují technické parametry NoSQL a současně zachovávají možnosti SQL. 1 Úvod Databázová technologie se vyvíjí více než 40 let. Ve slavné zprávě [1] o budoucnosti databází zdůrazňovali známí databázoví odborníci dvě určující hnací síly rozvoje databází: Internet a vědní obory produkující velké objemy vědeckých dat. V prvním případě se vývoj dostal k webovým databázím, ve druhém ke zpracování dat nazývanému e-science. Firmy jako Amazon, Facebook a Google dospěly brzy ke zpracování rozsáhlých distribuovaných dat, na které nestačily tradiční SŘBD. Šlo o problém škálování pomocí dynamického přidávání (ubírání) serverů z důvodu jak zvětšování objemu dat, tak počtu uživatelů. Problém velkých dat (Big Data problem) je hojně diskutován, ale i řešen na technologické úrovni webových databází. Zdánlivě nedotčené prostředí podnikových či korporátních databází se ale postupně rovněž měnilo směrem k velkým datům. Konzultační společnost McKinsey&Company oznámila ve zprávě [12], že průměrná investiční firma s méně než 1000 zaměstnanců má uložených 3,8 PByte dat, a zaznamenává nárůst dat o 40% ročně. Pojem velká data je samozřejmě relativní. Jsou podniky, kde ICT naráží na hranici stovek TByte, ale také stovek GByte. Co se týče typu zpracovávaných dat, jde jak o strukturovaná, tak semistrukturovaná a nestrukturovaná data. Důsledkem těchto skutečností je, že bylo nutné přehodnotit přístup ke správě dat. Rozmach těchto pokusů začíná v roce 2009, kdy se začaly objevovat databáze, které lépe reagují na změny velikosti dat, jejich uložení a přístupu. V souvislosti s webovými databázemi se objevily tzv. NoSQL databáze provázené rovněž změnami v technikách umístění dat v distribuovaném prostředí a požadavcích na transakční zpracování. Ač původně určené spíše pro webová data, současný vývoj ukazuje, že NoSQL databáze pronikají i do zpracování dat na úrovni podniku či korporace. Zhruba ve stejné době se v oblasti služeb objevuje další novinka cloud databáze, jejichž architektura a způsob zpracování dat představuje další způsob integrace. Podle [10] se v roce 2015 poskytovatelé cloudových služeb dotknou 20% informací na jejich cestě od vzniku k použití a 10% jich bude udržováno v cloudu. 1

5 NoSQL databáze současný stav vývoje , Praha Jaroslav Pokorný, MFF UK V článku ukážeme blíže principy NoSQL databází (sekce 2) a transakčního zpracování v těchto dynamických infrastrukturách (sekce 3). Sekce 4 ukazuje architektury nejznámějších NoSQL databází. V závěru jsou vedle shrnutí naznačeny některé další směry vývoje, zejména NewSQL databází. 2 NoSQL databáze Termín NoSQL databáze byl zvolen pro volně specifikovanou třídu nerelačních datových úložišť. Takové databáze nepoužívají (většinou) SQL jako svůj dotazovací jazyk. Termín NoSQL je proto zavádějící a v databázové komunitě je vykládán spíše jako not only SQL. V širším smyslu se sem zahrnují i XML databáze, grafové databáze či databáze dokumentů nebo objektové databáze. Někteří představitelé těchto softwarových prostředků nejsou dokonce databázemi v tradičním pojetí vůbec. Část NoSQL databází obvykle zjednodušuje nebo omezuje režii vyskytující se v relačních databázích s plnou funkčností. Na druhé straně jsou jejich data často organizována do jistých (řídkých) tabulek a přistupována pouze prostřednictvím primárního klíče. Data jsou rozmístěna do uzlů sítě Bez ohledu na různá omezení umožňují NoSQL databáze vyvíjet užitečné aplikace. Jak se v těchto databázích uplatňují rysy známé z tradičních přístupů ke zpracování dat, ukážeme v následujících odstavcích. 2.1 Datový model To, co je v klasických přístupech k databázím nejzákladnější - (logický) datový model, je v NoSQL databázích popsáno spíše intuitivně, bez jakýchkoliv formálních základů. I terminologie je podle toho velice různorodá. Současně se stírá rozdíl mezi konceptuálním a databázovým pohledem na data. Nejjednodušší NoSQL databáze, zvané úložiště typu klíč-hodnota (nebo velké hašovací tabulky), obsahují pouze množinu dvojic (klíč, hodnota). Klíčem je to, co se v relačních databázích nazývá jméno atributu nebo v SQL databázích jméno sloupce. Jinými slovy jde o množinu pojmenovaných hodnot. Klíč jednoznačně identifikuje hodnotu (typicky řetězec, ve více objektovém pojetí ale i ukazatel, kde je umístěna hodnota). Hodnota může být strukturovaná nebo nestrukturovaná (typicky BLOB). Přístup klíč-hodnota připomíná jednoduché abstrakce, jako jsou souborové systémy nebo hašovací tabulky, které umožňují rychlé vyhledávání. Podstatné zde ovšem je, že dvojice (klíč, hodnota) mohou být různých typů. V řeči relačního modelu dat nemusí pocházet ze stejné tabulky. Jakkoliv jde v implementaci o velmi rychlé a škálovatelné databáze, jejich nevýhodou je příliš jednoduchý datový model. Podobně jako u semistrukturovaných dat (např. XML) nejsou potřeba hodnoty NULL, protože ve všech případech jde o databáze bez schématu. V trochu složitějším přístupu se kombinace dvojic (klíč, hodnota) mohou shlukovat do skupin. Hovoří se pak o sloupcových NoSQL databázích nebo lépe rozšiřitelných záznamech, protože do skupin lze přidávat nové atributy (sloupce). Základem jsou dvojice (klíč, hodnota) rozšířené o složku času. Zřejmě nejobecnější jsou modely vedoucí k databázím nazývaným (poněkud nevhodně) dokumentově orientované NoSQL databáze. Jde vlastně o jisté semistrukturované dokumenty dokonce vybavené indexy. Příkladem takového dokumentu může být Jméno:"Jaroslav", Adresa:"Malostranské nám. 25, Praha 1 Vnoučata:{Klára: "7", Barbora: "6", "Magdalena: "3", "Kristina: "1", "Otakar: "3", Richard: "1"} Hodnotou např. Vnoučata:Barbora je 6 (s lepší interpretací např. 6 let). 2

6 NoSQL databáze současný stav vývoje , Praha Jaroslav Pokorný, MFF UK K zápisu datové struktury se v těchto případech obvykle využívá formát JSON 1. Zde používáme intuitivní značení pouze připomínající JSON. Grafové databáze jsou vlastně síťovými databázemi, jejich hrany a uzly reprezentují nějaká uživatelská data strukturovaná jako množiny dvojic (klíč, hodnota) - viz obrázek 1. Graf může např. reprezentovat trojice používané v datovém modelu RDF známém z webových aplikací a sociálních sítí. Grafová data mohou být jistě implementována pomocí relačního SŘBD, nicméně jejich zpracování, zejména rekurzivních dotazů je těžkopádné. Pro zjišťování cest v grafu je třeba použít mnoho operací spojení. Mezi představitele této kategorie NoSQL databází patří Neo4j 2, FlockDB 3 a InfiniteGraph 4. Id: 1 Jméno: Jan Věk: 18 Id: 107 Značka: členové Id: 100 Značka: zná Od: Id: 103 Značka: zná Od: Id: 106 Značka: je_členem Id: 2 Jméno: Eva Věk: 19 Id: 104 Značka: členové Id: 105 Značka: je_členem Od: Id: 3 Typ: skupina Jméno: cyklistika Obr. 1: Grafová data Ukážeme datový model dvou sloupcových NoSQL databází CASSANDRA a BigTable. V databázi CASSANDRA 5 se trojici <jméno, hodnota, časové_razítko> říká sloupec. Časová razítka modelují čas a slouží rovněž k rozlišování verzí hodnoty. Např. {Jméno:"Jaroslav", Adresa:"Malostranské nám. 25, Praha 1"} reprezentuje dva takové sloupce (časová razítka nejsou uvedena). Supersloupce (nemají časové razítko) obsahují několik sloupců a tvoří agregovanou pojmenovanou jednotku, např. Kdo: "Osoba1", {Jméno:"Jaroslav", Adresa:"Malostranské nám. 25, Praha 1"} Skupinou sloupců (column family) je (překvapivě) pojmenovaná struktura obsahující neomezené množství řádků. Každý má klíč (jméno záznamu řádku). Řádky jsou buď tvořeny sloupci a/nebo supersloupci. Ještě vyšší jednotkou obsahující předchozí struktury je prostor klíčů (key space), který je obvykle pojmenován jménem aplikace. Zajímavým rysem je, že lze specifikovat setříděnost v rámci řádku podle jmen sloupců a rovněž sloupců v supersloupcích

7 NoSQL databáze současný stav vývoje , Praha Jaroslav Pokorný, MFF UK V databázi BigTable 6 (též [6]) lze datový model charakterizovat jako třírozměrnou mřížku (kostku, tabulku) jejíž buňky jsou adresovány trojicemi <klíč_řádku, sloupec, časové_razítko> a obsahují hodnotu. Jeden nebo několik sloupců se v BigTable sdružují do pojmenovaných skupin sloupců (jiný pojem než v CASSANDRA). Sloupec se pak adresuje pomocí jméno_skupiny:kvalifikátor, např. Vnoučata:D2. Např. v okamžiku t2 je pro klíč hodnota v odpovídající buňce "Barbora". Skupin sloupců je pevný počet, ve skupině může být pro každý řádek různý počet sloupců. Tabulka v BigTable a prostor klíčů u CASSANDRA představují v principu totéž. Není těžké si představit dvojrozměrnou reprezentaci takové mřížky (viz tabulka 1). Každému řádku bude odpovídat tabulka s tolika řádky, kolik je pro řádek použito časových razítek. Sloupců bude mít tabulka tolik, kolik je skupin sloupců a kolik je sloupců v každé skupině. Vzhledem k tomu že skupiny sloupců jsou pro každý řádek různě velké, lze se celkově na takovou tabulku dívat jako na tabulku řídkých dat. Na fyzické úrovni je použito vertikální rozdělení dat, kdy skupiny sloupců jedné tabulky se nacházejí na různých uzlech. Např. skupiny sloupců Zákazník, Účty_zákazníka, Login_informace mohou být na třech uzlech chápány jako tři tabulky propojitelné přes ID_zákazníka. klíč_řádku časové razítko sloupec Jméno skupina sloupců Vnoučata D1 V1 D2 V2 D3 V3 t1 "Jaroslav" "Klára" 7 t2 "Jaroslav" "Klára" 7 "Barbora" 6 t3 "Jaroslav" "Klára" 7 "Barbora" 6 "Magdalena" 3 Tab. 1 Reprezentace dat v BigTable Dokumenty obsažené v řádcích tabulky jsou různě velké, lze do nich přidávat další data. Řádky jsou lexikograficky setříděny podle klíčů řádků. To je užitečné v případě, kdy je v tabulce klíčem URL. Je-li URL zapsáno obráceně, např. cz.cuni.mff.ksi, poskytuje při setřídění hierarchické možnosti přístupu k datům tabulky. Databáze v BigTable může obsahovat více takových tabulek. Výhodou těchto a podobných databází je bohatší datový model oproti jednouchému přístupu (klíč, hodnota). Data s takovým modelem spadají již spíše do kategorie semistrukturovaných dat. Jména sloupců vlastně představují značky přiřazené hodnotám. Pro aplikace tohoto přístupu se hodí např. databáze uživatelských profilů, informací o výrobcích či webovém obsahu (blogy, wiki, zprávy) apod. 2.2 Dotazování Dotazování v NoSQL databázích je tou nejméně propracovanou složkou. Jednou z možností dotazování nad NoSQL databázemi je (možná pro někoho paradoxně) omezený SQL. Např. v systému SimpleDB 7 má SELECT syntaxi SELECT výstupní_seznam FROM jméno_domény [WHERE výraz] [třídění] [limit limit]

8 NoSQL databáze současný stav vývoje , Praha Jaroslav Pokorný, MFF UK kde výstupní_seznam může být: *, itemname(), count(*), seznam atributů, přičemž itemname() se používá pro získání jména prvku. jméno_domény určuje doménu, odkud se vybírá. Ve výraz lze použít =, <=, <, > =, LIKE, NOT LIKE, BETWEEN, IS NULL, IS NOT NULL apod. třídění je pro jednotlivý atribut vzestupné nebo sestupné, limit omezuje velikost výstupu (implicitně 100, maximálně 2500). Operace spojení, agregace a zanořování poddotazů nejsou podporovány. Trochu širší podmnožinu SQL zvanou GQL (Goole Query Language) poskytuje např. Google AppEngine nástroj pro sestavení a spouštění webových aplikací v infrastruktuře Google. Další velmi omezenou variantu SQL používá databáze Hypertable 8. Její jazyk včetně aktualizačních a dalších příkazů se nazývá HQL (Hypertable Query Language). Dotazování (a aktualizační operace) se tedy většinou redukuje na přístup prostřednictvím klíče (např. jeho hašováním) přes jednoduché API. Typické API pro NoSQL databáze obsahuje jednoduché operace jako get(klíč), tj. extrakce hodnoty daného klíče, put(klíč, hodnota) (vytvoření nebo aktualizace hodnoty daného klíče), delete(klíč) (odstranění klíče a jeho hodnoty) a execute(klíč, operace, parametry), která vyvolá operaci na hodnotě dané klíčem. Hodnota je speciální datovou strukturou, např. seznam, množina, asociativní pole apod. Trojice v CASSANDRA a BigTable slouží na úrovni API pro vyhledávání i pro operace INSERT a DELETE. Procedurální přístup k dotazování je vlastní např. CouchDB 9. Díky horizontálnímu rozkládání dat (viz čl. 2.3) nepodporují NoSQL databáze operace spojení (JOIN) a uspořádání (ORDER BY). Toto omezení je aktuální také v případě, kdy je v každém uzlu použit plně funkční SŘBD. Je-li třeba, může být operace spojení implementována na straně klienta. Operace selekce je v NoSQL databázích rovněž často popsána na úrovni API, ale i kódu. Celkově se zdá, že rozvoj silnějších dotazovacích možností je ponechán na klientovi, např. přidáním vyhledávání podle klíčových slov, nebo dokonce využití relační databáze pro ukládání metadat o objektech, které se v NoSQL databázi vyskytují. Takový přístup neznamená nic jiného než ruční programování dotazů, což může být vhodné pro jednoduché úlohy a naopak velmi časově náročné pro jiné. 2.3 Uložení dat Relační databáze jsou většinou ukládány na disk nebo v nějaké oblasti paměti na síti. Množiny databázových řádků jsou přenášeny do paměti pomocí příkazu SELECT jazyka SQL nebo operací uložené procedury. Fyzický datový model pro NoSQL databáze je víceúrovňový. Databáze se fyzicky jeví jako množina provázaných tabulek (např. v hierarchii) a teprve ty jsou uloženy do souborového prostředí na disku a v síti. Využívají se i techniky sloupcově orientovaných databází, které s klíčem asociují množinu skupin sloupců. Takové skupiny jsou ukládány na různých uzlech sítě. Sloupcový přístup navíc umožňuje snadné přidávání informací a kompresi dat. V principu jde o variantu vertikálního rozkládání dat. Příklad typického hierarchického uložení nabízí fyzická úroveň v BigTable. Tabulka je rozdělena do tzv. tabletů, z nichž každý obsahuje řádky z nějakého intervalu (v souladu s daným uspořádáním). Tablet je identifikován jménem tabulky a koncovým klíčem intervalu. Stejné struktuře se v HBase 10 říká region identifikovaný jménem tabulky a počátečním klíčem. Řádky v regionu jsou uspořádány podle klíče od nějakého počátečního do koncového. V CouchDB je pro ukládání dvojic (klíč, hodnota) použit B-strom tak, že je podporováno setřídění podle klíče

9 NoSQL databáze současný stav vývoje , Praha Jaroslav Pokorný, MFF UK Princip architektury NoSQL databází využívaných v cloudech vyžaduje dynamickou škálovatenost je založen na tzv. horizontálním škálování (též scaling out), tj. rozložení databáze mezi mnoho (levných) strojů (serverů) dynamicky přidávaných či odebíraných podle zátěže provozu. Data jsou do databází jednotlivých uzlů sítě rozkládána způsobem, který se rovněž nazývá horizontální, podobně jak tomu bývá u paralelních relačních databázových systémů, kde se do uzlových databází relace rozkládá do fragmentů po skupinách řádků. Toto rozkládání, ať už hašováním nebo intervalově, je většinou uživatelsky orientované, což vede k řadě problémů, z nichž ten zásadní se týká dosažení ACID vlastností u transakcí (viz kap. 3). Pro úplnost uveďme, že data mohu být rozložena do uzlů sítě nejen horizontálně, ale i vertikálně, tj. např. dvě části záznamu jsou na různých uzlech. I tak lze podporovat horizontální škálování dat. Častou technikou je použití replikací. CASSANDRA používá pro rozložení dat na jednotlivé servery v prostoru klíčů distribuovanou hašovací tabulku (DHT). Tyto DHT jsou např. organizovány v kruhu s možností dynamizace vkládáním nového uzlu mezi dva uzly resp. sléváním sousedních uzlů. V uživatelském API se manipuluje s DHT opět pomocí operací put(klíč, hodnota) a get(klíč) hodnota. Např. DHT použitá v úložišti Valdemort 11 rozděluje data do kruhu uzlů, přičemž data z uzlu K, jsou replikována do uzlů K+1,,K+n, pro nějaké dané n (tzv. konzistentní hašování). Data NoSQL databází bývají uložena ve speciálních souborových systémech. Jako příklad datového úložiště použitelného pro vyšší systémy zmiňme velmi populární aktivitu Amazonu realizovanou v souborovém systému Single Storage Service (S3) 12. S3 dovoluje zapisovat, číst a odstraňovat objekty velikosti do 5 TByte pomocí jedinečného uživatelsky orientovaného klíče. S3 je nejúspěšnější pro multimediální objekty a zálohování. Takové objekty jsou typicky velké a zřídka aktualizované. Obecnější použití má dnes open source software Hadoop 13 založený na frameworku MapReduce pro zpracování dat a distribuovaném souborovém systému HDFS (Hadoop Distributed FileSystem). Nad HDFS je vybudována databáze HBase. Srovnání Hadoop s relačními databázemi lze nalézt v [13]. NoSQL databáze využívají více vnitřní paměti. Některé (ale ne všechny) NoSQL databáze jsou navrženy tak, že pro zvýšení rychlosti jsou jejich data umisťována v paměti s uložením dat na disk až při zastavení práce s databází nebo při zálohování dat. Takovým databázím se říká in-memory databáze a patří k nim např. Redis 14. NoSQL databáze mohou být umístěny na jednom serveru, ale většinou jsou navrženy k práci v oblaku serverů. Využívány jsou rovněž distribuované indexy. Protože zátěž lze rozložit na více počítačů, můžeme NoSQL databáze obecněji chápat jako speciální typ nerelačních distribuovaných SŘBD. 3 Transakční zpracování v NoSQL databázích V praxi podporují relační databáze vždy plně vlastnosti ACID. Databázová praxe však ukazuje, že ACID transakce jsou požadovány pouze v jistých případech použití. Např. databáze v bankách a obchodu musí vždy obsahovat správná data. Jde li o cloud computing, odpovídající cloud databáze by měla zaručovat ACID vlastnosti. Tato funkčnost je určující u mnoha korporátních cloud databázi. Naopak, být relační a ACID, není pro některé případy použití vůbec nutné (např. datové sklady, analýza rozsáhlých dat), navíc může přidávat ne nutnou režii. Při návrhu webových služeb, se na rozdíl od ACID vlastností považují za důležité jiné požadavky. Jedná se o konzistenci (consistency - C), dostupnost (availability - A)) a odolnost vůči rozdělení sítě (partitioning tolerance - P), zkráceně CAP

10 NoSQL databáze současný stav vývoje , Praha Jaroslav Pokorný, MFF UK Konzistence znamená, že kdykoliv jsou data zapsána, každý, kdo čte z databáze, bude vždy vidět poslední verzi dat. Pojem je tedy zřejmě odlišný, než jak je chápán u vlastností ACID. Dostupnost znamená záruku očekávání, že každá operace skončí v zamýšlené odezvě. Vysoká dostupnost je obvykle dosahována pomocí velkého množství propojených fyzických serverů působících jako jedna databáze s rozdělením dat mezi různé databázové uzly a využitím replik dat. Odolnost vůči rozdělení sítě znamená, že z databáze se může stále číst a zapisovat do ní, i když jsou její části zcela nepřístupné. Situací, která to může zapříčinit, je přerušení síťového spojení mezi význačným počtem databázových uzlů. Odolnost vůči rozdělení může být dosažena mechanismy, kterými jsou zápisy místo na určených nedosažitelných uzlech poslány uzlům, které jsou ještě přístupné. Po té, kdy se nedostupné uzly navrátí zpět, obdrží zápisy, které chyběly. O vzájemných vztazích těchto vlastností vypovídá CAP teorém, také nazývaný Brewerův teorém, navržený v kontextu webových služeb Brewerem v [3] (jako domněnka) a formálně dokázaný v [11]. CAP teorém tvrdí, že pro jakýkoliv systém sdílení dat je nemožné garantovat současně všechny tři uvedené vlastnosti. Speciálně ve webových aplikacích založených na strategii horizontálního škálování, je nutné se rozhodnout mezi C a A, připustíme-li odolnost vůči rozdělení sítě, tj. fakt, že pracujeme v nespolehlivém systému. Existují dva směry v řešení, jestli C nebo A. Jeden požaduje silnou konzistenci jako klíčovou vlastnost a zkouší maximalizovat dostupnost. Výhodou tohoto postupu je, že ACID vlastnosti umožňují jednodušeji vytvářet aplikace a řídit datové služby. Jinak musí být implementována složitá aplikační logika, která detekuje a kompenzuje nekonzistence. Druhý směr upřednostňuje dostupnost a zkouší maximalizovat konzistenci. Priorita dostupnosti má spíše ekonomické zdůvodnění. Nedostupnost webové služby, jako je např. e-obchod, může totiž znamenat finanční ztráty. Uvážímeli, že existence 2PC protokolu zajišťuje konzistenci a atomicitu z ACID, pak, založeno na CAP teorému, dostupnost v nespolehlivém systému nemůže být vždy zaručena a k jejímu zvýšení je nutné slevit z konzistence. Naopak korporátní SŘBD upřednostňují spíše C nad A a P. Databáze, které neimplementují plně ACID, mohou být pouze případně konzistentní (speciální případ slabé konzistence). Znamená to, že když jsou data zapisována, ne každý, kdo čte z databáze, bude nová data vždy hned vidět. V principu jde o to, že jestliže se vzdáme silné konzistence, můžeme získat lepší dostupnost, což vysoce zlepší škálovatelnost databáze. Takový přístup je vhodný pro zákaznické cloud databáze. Tento jev připomíná datová úložiště pro dokumenty z 90. let, kde ne příliš časté výskyty konfliktů při aktualizacích převažovaly a konzistence nebyla tím nejdůležitějším. Jiným příkladem jsou původní bankomaty, které vždy dávaly přednost dostupnosti nad konzistencí, samozřejmě s jistým rizikem. U webové databáze tak lze dosáhnout nízké latence, vysoké průchodnosti, což činí participující webové místo více responzivní pro uživatele. Modelů slabé konzistence je více. Např. databáze PNUTS [7] používá pojem konzistence v časové ose (time-line consistency). Současný odpovídající transakční model v NoSQL databázích používá vlastnosti BASE (Basically Available, Soft-state, Eventually Consistent) [14]. Systémy s BASE vlastnostmi se vzdávají silné konzistence. V podstatě dostupné v BASE odpovídá dostupnosti v CAP teorému. Je dosažena povolením dílčích chyb tak, aniž by došlo k chybě celého systému. Změkčení stavu znamená, že se databáze může měnit v čase dokonce bez vstupu a nemusí být po ten čas (v tomto stavu) konzistentní. To je důsledkem modelu případné konzistence. Případná konzistence znamená, že po čase se nakonec systém stane konzistentní. Vhodnější překlad pro eventual consistent by byl nakonec konzistentní. Pro transakční zpracování je, podobně jako u klasických distribuovaných databází, je podstatný způsob zpracování replik. Ten je buď synchronní, nebo asynchronní. Dosavadní zkušenosti s CAP teorémem naznačují, že při návrhu distribuovaného systému je nutný hlubší přístup k řešení závislý na aplikaci a technických podmínkách [4]. Je-li síť v pozadí distribuce umístěna např. v datacentru, jsou chyby v ní minimalizovány. Pak lze dosáhnout s vysokou pravděpodobností vysokého C i P. 7

11 NoSQL databáze současný stav vývoje , Praha Jaroslav Pokorný, MFF UK Pokročilé řešení konzistence můžeme nalézt u systému CASSANDRA. Konzistence je zde laditelná, tj. její stupeň lze ovlivnit návrhářem aplikace. To umožňuje použití v aplikacích s transakčním zpracováním v reálném čase. 4 Architektura NoSQL databází Jednotlivé architektury NoSQL databází používají různé možnosti distribuce, zajištění dostupnosti a přístupu k replikaci dat. Mnohé podporují ACID, jiné případnou konzistenci (CASSANDRA, Dynamo), některé, jako SimpleDB, nepodporují transakce vůbec. SimpleDB je založen na S3. Připomeňme, že S3 zaujímá ve světě NoSQL význačné místo. Architektura úložiště S3 dovoluje neomezenou škálovatelnost. S3 byl rovněž použit pro vybudování plně funkčního databázového systému s malými objekty a častými aktualizacemi [2] a další NoSQL databáze jako je Dynamo [9]. V tabulkách 2-4 jsou popsány typičtí představitelé NoSQL databází spolu s jejich základními charakteristikami zaměřenými na datový model, způsob dotazování, způsob zpracování replik (As asynchronní, S synchronní) a možnost transakcí (N žádné, L lokální transakce). Výraz {hodnota} znamená množinu hodnot. Sloupec CAP udává, které vlastnosti z CAP jsou preferovány. Jméno Výrobce Datový model Dotazovací jazyk CAP Rep T SimpleDB Amazon {(klíč, {hodnota})} omezený SQL AP As N Dynamo Amazon jako SimpleDB jednoduché čtení a zápis AP As N Redis Salvatore Sanfilippo {(klíč, hodnota)}, kde hodnota je jednoduchá typovaná, seznam, uspořádaná (podle ohodnocení) nebo neuspořádaná množina, hašovaná hodnota primitivní příkazy pro každý typ hodnoty CP As N Voldemort LinkedIn jako SimpleDB podobné Dynamo AP As N Tab. 2. NoSQL databáze typu klíč-hodnota Jméno Výrobce Datový model Dotazovací jazyk CAP Rep T BigTable Google {(klíč:hodnota, čtení libovolné buňky tabulky, CP As L {klíč:hodnota})} lze omezit rozsah + prohledávaných řádků, S sloupců, skupin sloupců HBase Apache je klonem BigTable JRUBY, interaktivní shell CP As L (nahrazuje HQL) PNUTS Yahoo (hašované nebo nalezení objektu, rozsahové AP As L uspořádané) tabulky, dotazy, složité predikáty, typovaná pole, flexibilní upořádání, top-k schéma CASSANDRA Apache (původně {(klíč:hodnota, {klíč:hodnota})} jednoduchá selekce přes klíč, rozsahový dotaz, řezy přes AP As L Facebook) vyjmenované sloupce nebo rozsahy sloupců Hypertable Hypertable jako BigTable HQL CP As L Tab. 3. Sloupcově orientované NoSQL databáze 8

12 NoSQL databáze současný stav vývoje , Praha Jaroslav Pokorný, MFF UK Jméno Výrobce Datový model Dotazovací jazyk CAP Rep T CouchDB Couchbase dokument jako seznam pohledy pomocí Javascript a AP As N pojmenovaných MapReduce (strukturovaných) položek MongoDB 15 10gen objektově strukturované manipulace objektů v kolekcích CP As N dokumenty ukládané (nalezení, odstranění, v kolekcích aktualizace, jednoduché selekce) Tab. 4. Dokumentově orientované NoSQL databáze Některé z NoSQL projektů jsou vyspělejší než ostatní, každý z nich se však pokouší řešit podobné problémy. Vzhledem k odlišnosti jednotlivých NoSQL databází se nezdá reálné, že bude vyvinut nějaký unifikovaný dotazovací standard nebo datový model, i když pokusy ovšem existují - viz jazyk UnQL 16 (Unstructured Query Language). Důležité je, že úložiště typu klíč-hodnota používané v NoSQL databázích pracují pro jisté druhy dat, ale vůbec nepracují dobře pro jiné druhy. V důsledku toho se firmy, které mají a používají NoSQL databáze, nevzdávají SŘBD s SQL. Pro některé aplikace pokračují v jejich používání. Problémem může být programování aplikací s NoSQL databázemi. Aplikace využívající možnost jisté nekonzistence musí být navrženy odlišně než ty, které mohou spoléhat na konzistenci plně zajištěnou SŘBD. 5 Závěr Ukázali jsme různé přístupy k NoSQL databázím, zejména rysy jejich datových modelů a možností dotazování, dále pak typy transakčního zpracování. Seznam různých open a closed source NoSQL databází lze nalézt v [5], dobře udržovanou a strukturovanou webovou stránkou je obsahující informace o 122 NoSQL databázích. NoSQL databáze zatím mají daleko k vyspělým databázovým technologiím a svou koncepcí nemůžou nahradit tradiční relační SŘBD. Pokrývají zatím pouze část cloudových aplikací (hlavně webových) intenzivních na datova. Z hlediska praxe se budoucnost NoSQL jeví v kontextu využití rozmanitých databázových prostředků aplikačně orientovaným způsobem, jejich širokém využití ve specializovaných projektech zejména s nestrukturovanými daty a vysokými požadavky na škálování. Ukázali jsme, že díky horizontálnímu škálování není možné dosáhnout jednoduše naplnění ACID vlastností. To ovšem neznamená, že jakýkoliv cloud computing je ochotno vzdát se zachování ACID vlastností. Např. SaaS aplikace požadují funkčnost na podnikové úrovni včetně ACID transakcí, ochrany dat a dalších rysů spojených s komerčními relačními SŘBD. NoSQL databáze by tedy neměly být v cloudu jedinou volbou. Existují však výjimky, např. firma DataStax - vedoucí poskytovatel NoSQL řešení pro podniky. Její systémy jsou založeny na databázi CASSANDRA. Zdá se, že přijetí NoSQL nebude zatím konkurovat využití relačních databází, které reprezentují velké investice a hlavně spolehlivost a vyspělou technologii Další architektury pro cloud computing, kde se bude využívat horizontálního škálování, zachování ACID a databázi, budou zřejmě vyžadovat další výzkum. V praxi se již takové systémy ale vyskytují. Patří mezi ně např. relační SŘBD MySQL Cluster 17, VoltDB 18 a Clustrix 19. Tyto databáze se dokonce řadí do kategorie tzv. NewSQL databází. Jde o nový trend příští generace vysoce škálovatelných a pružných transakčních relačních SŘBD zveřejněný v dubnu 2011 s charakteristikami:

13 NoSQL databáze současný stav vývoje , Praha Jaroslav Pokorný, MFF UK jsou navrženy pro horizontální škálování v architekturách založených na sdílení ničeho (podobně jako u NoSQL), garantují ACID, aplikace interagují s databází primárně pomocí SQL, používají pro souběžné zpracování řídící mechanismy bez uzamykání, aby uživatel nebyl blokován, systém poskytuje vyšší výkon než je dosažitelný tradičními systémy. Za další trend se považují hybridní systémy s více datovými úložišti založenými obecně na odlišných principech. Hybridním je i Valdemort s MySQL jako jedním z úložišť. Literatura [1] Abiteboul, S., et al.: The Lowell Database Research Self-Assessment. Communications of the ACM, Vol. 48, No. 5 (2005), [2] Brantner, M., Florescu, D., Graf, D., Kossman, D., Kraska, T.: Building a Database on S3. In: Proc. SIGMOD 08, June 9-12, Vencouver, Canada (2008), [3] Brewer, E.A.: Towards Robust Distributed Systems. Invited talk on PODC 2000, July , Portland, Oregon (2000). [4] Brewer, E.A.: CAP Twelve Years Later: how thee Rules Have Changed. Computer, February (2012), [5] Cattell, R.: Scalable SQL and NoSQL Data Stores, 2011, last updated January 28, [6] Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A., Burrows, M., Chandra, T., Fikes, A., Gruber, R. E.: Bigtable: A Distributed Storage System For Structured Data. In: Proc. of 7th USENIX Symposium on Operating Systems Design and Implementation (OSDI 06), [7] Cooper, B. F., et al: PNUTS: Yahoo! s hosted data serving platform. PVLDB, 1(2): , [8] Dean, D., Ghemawat, S.: MapReduce: Simplified Data Processing on Large Clusters. Communications of the ACM, January 2008/Vol. 51, No. 1, [9] DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P., and Vogels, W.: Dynamo: Amazon s Highly Available Keyvalue Store. In: SOSP 07, October 14 17, 2007, Stevenson, Washington, USA, ACM, pp [10] Gantz J., Reinsel, D.: Extracting Value from Chaos. IDC iview, June 2011, [11] Gilbert, S., Lynch, N.: Brewer's conjecture and the feasibility consistent, available, partitiontolerant web services. Newsletter ACM SIGACT News, Vol. 33, Issue 2 (2002) [12] McKinsey Global Institute: Big data: The next frontier for innovation, competition, and productivity. May 2011, ext_frontier_for_innovation. [13] Pokorný, J.: Databázové architektury: současné trendy a jejich vztah k novým požadavkům praxe. In: Sborník příspěvků 20. ročníku konference Moderní databáze, Hotel Legner, Zvánovice, KOMIX, 2006, pp [14] Pritchett, D.: BASE: An Acid Alternative. ACM Queue, May/June (2008)

14 NoSQL databáze současný stav vývoje , Praha Jaroslav Pokorný, MFF UK Summary The paper is focused on so called NoSQL databases. In context of cloud computing, architectures and basic features of these databases are studied, particularly their data model, ways of querying, implementation and storage techniques. We present also some concurrency models used in NoSQL databases that are mostly weaker than ACID transactions in relational SQL-like database systems. Finally, the paper contains an overview of some representatives of NoSQL databases including their basic characteristics. 11

15 Modelování XML schémat , Praha Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý MFF UK Modelování XML schémat Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý Katedra softwarového inženýrství, MFF UK Malostranské nám. 25, Praha 1, Tel: www: Klíčová slova: XML, XML-Schema, XML-schéma, UML Abstrakt: Cílem přednášky je poskytnout informace o možnostech modelování XML dat, vytváření abstraktních modelů dat tak, abychom mohli validovat, zda dokumenty jsou syntakticky korektní, zda odpovídají schématu, následně mohli dokumenty zpracovávat jako silně typované. Navíc lze při zveřejnění XML schématu dosáhnout vyšší standardizace při přenosu dokumentů. Modelování XML schémat je rovněž užitečné při nezbytných transformacích XML dokumentů, pokud potřebujeme změnit jejich strukturu. 1 Úvod XML (EXtensible Markup Language) je v současné době de-facto standard pro reprezentaci a přenos dat. Spolu s doprovodnými normami, jako jsou XML Schema, XPath, XQuery, XSLT atd., se stává mocným nástrojem. V důsledku toho velmi rychle roste množství a složitost softwarových systémů, které využívají vybrané XML standardy a technologie pro výměnu informací a ukládání dat. Tyto systémy zpracovávají informace v podobě XML dokumentů. Jednou z důležitých částí těchto systémů jsou analyzátory (parsery) a validátory, které zpracovávají syntaxi XML dokumentů a kontrolují jejich validitu proti definici v podobě XML schémat vyjádřených v nějakém jazyce, např. DTD, Schematron nebo XML Schema. Systémy obvykle nepoužívají pouze jeden formát, ale sadu různých XML formátů, každý v určitém logickém kontextu. Konkrétní XML schémata představují jednotlivé pohledy na aplikační oblasti softwarového systému. Můžeme tedy mluvit o rodině XML formátů využívaných v daném softwarovém systému. Jen malé procento aplikací je statických a nemění se během svého nasazení. Většina aplikací se mění s příchodem nových požadavků uživatelů a měnícím se prostředím. Pokud máme softwarový systém, který využívá rodinu XML formátů, stojíme před problémem evoluce formátu jako přirozenou součástí vývoje softwarového systému jako celku. XML schémata se mění, kdykoli přicházejí nové uživatelské požadavky nebo nastávají změny okolního prostředí. Každá taková změna může ovlivnit mnoho různých XML schémat. Bez technické podpory musíme ručně identifikovat změny v XML schématech a ručně zabudovat změny do aplikace, aby se vyvíjela souběžně se změnou formátů. Tento fakt přináší výzvu pro výzkum a vývoj takových metod a nástrojů, které by vývojáře v této evoluci XML schémat podporovaly. Pravděpodobně nikdy nebudeme moci vše vyřešit automatizovaně, stále zůstávají případy, kdy je rozhodnutí vývojáře nevyhnutelné, ale automatizovaná podpora evoluce umožňuje identifikovat všechny zasažené části aplikace a provede vývojářem vybrané změny korektně a efektivně. V naší výzkumné skupině jsme se v několika posledních letech zaměřili na oblast podpory korektní a efektivní evoluce rodiny XML formátů. Od jednoduché myšlenky šíření změn mezi propojenými XML formáty, jsme naše úsilí postupně rozšířili směrem ke kvalitnímu podpůrnému nástroji nazvaném nejprve XCase, později exolutio. V tomto příspěvku se o tomto nástroji později zmíníme. 12

16 Modelování XML schémat , Praha Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý MFF UK Konsorcium OMG (Object Management Group) již nějaký čas podporuje myšlenku modelem řízeného vývoje (Model Driven Development MDD, příp. Model Driven Architecture - MDA, nebo Model Driven Engineering - MDE ). Nástroj exolutio se snaží aplikovat tyto principy na vývoj a integraci nových formátů XML do společného rámce v rámci jejich evoluce. Zbytek příspěvku je strukturován takto: V sekci 2 se zaměříme na teoretické zázemí podpory evoluce - náš konceptuální a logický model pro XML. V sekci 3 se představí exolutio, náš nástroj, ve kterém se snažíme realizovat výsledky našeho zkoumání. V sekci 4 uvádíme jeden experiment, ilustrující využití nástroje exolutio při evoluci XML schémat. 2 Konceptuální a logický model pro XML Základní princip modelem řízeného vývoje je práce s modely na různé úrovni abstrakce. Jejím smyslem je jednodušší orientace ve složitém systému. Bertrand Russell řekl: Abstrakce je sice obtížná, ale je zdrojem praktické síly (Abstraction, difficult as it is, is the source of practical power). OMG doporučuje 4 úrovně modelů: Doménový model (Computation Independent Model CIM), Konceptuální model (Platform Independent Model PIM), Logický model (Platform Specific Model PSM), Fyzický/Implementační model (Implementation Specific Model ISM). Doménový model popisuje doménu, tj. modelovanou skutečnost, zpravidla tak, jak je. Často se zde používají různé modely byznys procesů, popisující aktivity, kterými si příslušná organizace vytváří zisk. V rámci procesů se konzumují a produkují artefakty, kterými mohou být také XML dokumenty. Jejich struktura se ale na této úrovni zpravidla nespecifikuje přesně. Uvažme např. vysokou školu, kde jeden ze základních procesů bude Absolvování předmětu. Tento proces na byznys úrovni konzumuje informace o studentech a předmětech, produkuje výsledné hodnocení studentů. Konceptuální model popisuje přesně data a funkce, které bude realizovat elektronická podpora vybraných doménových procesů. Data i funkce zde již jsou popsány přesně, ale na konceptuální úrovni není specifikováno, jak mají být data reprezentována, či realizovány funkce, ale jejich informační obsah a efekt je uveden přesně. Např. pro uvažovaný podpůrný informační systém vysoké školy bude specifikovat přesně obsah Hodnocení studenta z předmětu jako entitu, která má následující atributy: identifikaci studenta, identifikaci předmětu, odkaz na zkouškový termín, identifikaci examinátora a vlastní hodnocení. Logický model se zabývá logickou reprezentací konceptuálních dat na určité platformě. Stejná konceptuální data lze při reprezentaci logicky různě uspořádat, stejnou funkci lze různě realizovat. Použijeme-li jako platformu např. relační databázový systém, pak pro entitu Hodnocení studenta z předmětu zde bude tabulka Hodnocení studentů z předmětů, která bude mít sloupce: cizí klíč studenta, cizí klíč předmětu, cizí klíč zkouškového termínu, cizí klíč examinátora a vlastní hodnocení studenta (výčtový typ, nebo cizí klíč do číselníku hodnocení). Fyzický/Implementační model představuje fyzické uložení dat a fyzickou realizací funkcí. Na rozdíl od logického modelu se již přímo obrací na fyzické prostředky systému segmenty pamětí, sektory na vnějších médiích, instrukce fyzického, či virtuálního stroje. Pro uvažovaný příklad by fyzická reprezentace záznamu z tabulky Hodnocení studentů z předmětů byla uložena na některých sektorech vnější paměti. To za nás ale zařídí systém řízení relační báze dat (interpret SQL). Z hlediska modelování XML dat jsou pro nás důležité dvě úrovně této hierarchie konceptuální a logická. V doménovém modelu nemusí být informace popsána dostatečně přesně, implementační úroveň je zase pro účely modelování příliš detailní a zajišťují ji zpravidla hotové nástroje. Konceptuální model pro XML a jeho deriváty se opírá o schéma na úrovni PIM podle MDD. Lze jej zachytit pomocí diagramů tříd v UML a modelovat reálné koncepty a vztahy mezi nimi. Obsahuje tři druhy elementů: třídy, atributy a vztahy. Vzorek PIM je znázorněn na Obr 1. Pokud není 13

17 Modelování XML schémat , Praha Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý MFF UK uvedena četnost a volitelnost vztahu, je implicitně definována jako [1..1]. Součástí konceptuálního modelu jsou také integritní omezení na úrovni PIM, která by měla být popsána v jazyce OCL. Na jejich zpracování se v současné době pracuje, nejsou ale probírána v rámci tohoto příspěvku. Obr 1: Příklad konceptuálního modelu (PIM) Při komunikaci s aplikací, která udržuje konceptuální data z modelu na Obr 1, bude zapotřebí reprezentovat všechna data, nebo jejich určitou část pro konkrétní platformu a konkrétní logickou část, která se zpracovává. Na Obr 2 je uveden logický model (PSM), který popisuje logickou strukturu objednávky nákupu provedeného zákazníkem (Purchase). Toto logické schéma (PSM schéma) určuje, jak je tato součást reality strukturována v určitém schématu XML představuje jeden možný pohled na konceptuální data. Z gramatického hlediska je PSM schéma modelováno XML elementy a atributy. Můžeme je prezentovat opět ve stylu diagramů tříd UML. Výhodou tohoto způsobu je fakt, že projektant pracuje způsobem, který zná a který je pohodlnější než editace XML schéma např. v jazyce XML Schema. Formálně existuje mapování z každého PSMschématu do schéma PIM. Obr 2: Příklad logického schéma objednávky (PSM) Pro vstup informací z objednávky bude vhodné logické schéma z Obr 2, pro stručný výpis objednávek by mohlo postačit jiné schéma (zjednodušené) viz Obr 3. 14

18 Modelování XML schémat , Praha Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý MFF UK Obr 3: Jiný příklad logického schéma (PSM) Tato schémata je již možno chápat jako dostatečně přesný model XML PSM-schémat, ze kterých je možné generovat definiční popisy v různých jazycích (DTD, Schematron, XML Schema). 2.1 Interpretace PSM schématu proti PIM schématu PSM-schéma představuje pohled na část schématu PIM. Třída, atribut nebo vztah v PSM-schématu mohou být mapovány na třídu, atribut nebo vztah ve schématu PIM. Jinými slovy, je třeba určit mapování, které určuje sémantiku prvků z PSM-schématu ve smyslu prvků schéma PIM. Mapování musí splňovat určité podmínky, které zajistí soulad mezi schématy PIM a PSM. Tato interpretace PSM schématu proti schématu PIM je to, co nazýváme mapování. To je hlavní rys našeho konceptuálního modelu. Propojuje konstrukce na platformově specifické úrovni s konstrukty na platformově nezávislé úrovni a umožňuje vývoj schématu XML a integraci schémat mezi sebou. Jeho přesná definice však není triviální a je nad rámec tohoto příspěvku. 3 Nástroj exolutio Realizaci výsledků našeho výzkumu představuje nástroj s názvem exolutio Existuje také starší verze našeho konceptuálního modelu a jeho implementace ve formě nástroje XCase. Pro jednoduchost se budeme držet pouze aktuální verze. Nástroj exolutio umožňuje uživateli modelovat konceptuální schéma na úrovni PIM. Pak může vyvíjet celou radu logických schémat na úrovni PSM, které budou představovat pohledy interpretované proti schématu PIM. Tyto pohledy umožňují zpracování odpovídající části modelu na platformě XML. 3.1 Architektura nástroje exolutio Architektura nástroje exolutio je založen na architektonickém vzoru Model-View-Controller (MVC) viz Obr 4. To znamená, že všechna data projektu máme uložena v komponentě označené Model. Data uložená v modelu jsou uživateli prezentována podle aktuálně nastaveného pohledu v komponentě Pohled (View). Kdykoliv uživatel vydá nějaký příkaz, je zpracován komponentou označenou jako Správce (Controller). Ta zajistí přes rozhraní komponenty Model provedení všech potřebných změn v modelu. Komponenta Pohled registruje provedené změny a aktualizuje 15

19 Modelování XML schémat , Praha Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý MFF UK vizualizaci. Součástí příkazů může být i požadavek na změnu použitého pohledu. Vazby mezi jednotlivými komponentami jsou natolik volné, že je možné např. použít více vizualizací. Pro realizaci používáme Windows Presentation Foundation [22] (pro desktopovou i webovou aplikaci). U konzolové verze aplikace exolutio se vizualizace omezuje, i když sdílejí stejný model a stejného správce. 3.2 Komponenta Model Obr 4: Celková architektura nástroje exolutio (MVC) Komponenta Model představuje část nástroje exolutio, který se na základě našeho konceptuálního modelu skládá z tříd pro každou modelovanou složku - jako jsou třídy, vztahy nebo atributy na každé z modelovaných hladin (PIM a PSM). Existuje zde také (meta-)třída pro schéma PIM a PSM, schémata pro celý projekt. Kromě zřejmých vlastností komponenty, jako je práce s vlastnostmi tříd nebo kolekcemi atributů třídy, ještě každá třída implementuje metody pro serializaci obsahu do formátu XML a zpětnou rekonstrukci složky. Když ukládáme nebo načítáme projekt, jednoduše stačí zavolat metodu pro serializaci nebo rekonstrukci všech nalezených objektů ve správném pořadí. Každé schéma obsahuje seznam všech složek jednotlivých druhů v tomto schématu, takže můžete snadno procházet např. všechny vztahy v určitém schématu. Protože jedním z hlavních rysů našeho nástroje je vizualizace vztahů mezi dvěma úrovněmi abstrakce (PIM a PSM), jeden z nejčastějších dotazů je: "Dej mi všechny PSM třídy, které mají tuto třídu PIM jako jejich zdroj". V podstatě jsme nuceni projít každé PSM-schéma v projektu a pro každou PSM třídu v tomto schématu zkontrolovat, zda je u ní uveden vztah k odpovídající třídě PIM. Navíc tento model obsahuje metody pro snadný přechod jak na PIM, tak na PSM-schémata. Příkladem může být metoda pro vyhledávání všech atributů PSM třídy včetně těch, které zdědila ze strukturálních reprezentativních konstrukcí. Dalším příkladem může být metoda, která dostane všechny neinterpretované potomky interpretované PSM třídy. 3.3 Komponenta Pohled (View) Komponenta Pohled (View) slouží pro dva účely: zobrazuje informace z modelu uživateli a poskytuje uživatelsky přívětivé rozhraní pro zadávání a spouštění řídicích příkazů. PIM schémata jsou zobrazována jako diagramy UML, uspořádání schématu je ponecháno na preferencích uživatele. Pro PSM-schémata implicitně používáme automatické hierarchické uspořádání, které zdůrazňuje skutečnost, že PSM-schéma je strom / les. Vedle vizualizací schémat, poskytuje komponenta Pohled několik oken a ovládacích prvků, které pomáhají uživateli orientovat se v modelovaných projektech. Zobrazují souvislosti mezi jednotlivými prvky a můžeme sledovat různé odkazy, např. najít interpretaci atributu nebo třídu odkazovanou ze strukturálního representanta. Komponenta Pohled může být spuštěna buď jako desktopová aplikace, nebo uvnitř webového prohlížeče pomocí technologie Silverlight plugin. Pak může tato 16

20 Modelování XML schémat , Praha Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý MFF UK komponenta sloužit jako prohlížeč, který může být použit jako doprovod k dokumentaci publikovaných standardů XML schémat. Interaktivní vizualizace rodiny schémat spojených do společného modelu může značně usnadnit práci návrháře systému, který chce přijmout standard třetí strany a potřebuje jasný přehled o celém problému domény a jednotlivých schématech. Obr 5: Struktura řídicí komponenty Správce nástroje exolutio 3.4 Komponenta Správce (Controller) Komponenta Správce (Controller) je jádrem nástroje exolutio. Obsahuje všechny operace a algoritmy, které činí z exolutia unikátní nástroj. Snaží se být uživatelsky příjemná, proto obsahuje pro každý obvyklý příkaz možnosti Undo / Redo. Kdykoliv uživatel zadá příkaz přes zobrazený pohled, to je tento předán správci. Správce dostane všechny potřebné parametry získané z pohledu, jako např. co je příkazem požadováno, aktuálně vybrané komponenty, nové jméno pro komponentu, apod. Správce vytvoří odpovídající příkaz, který ve většině případů bude realizován některou z našich složených operací a předá jí všechny požadované parametry. Operace při provádění odpovídajícím způsobem aktualizuje model. Obr 6: Náhled pracovní plochy nástroje exolutio 17

21 Modelování XML schémat , Praha Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý MFF UK Pak se umístí příkaz Undo do zásobníku. Tento příkaz v sobě obsahuje všechny informace, které jsou potřebné pro změnu modelu zpět do stavu, ve kterém byl před vykonáním příkazu. Jinými slovy, můžeme jednoduše zavolat zpětný chod a správce ví, co je třeba udělat a zda je to možné. Tímto způsobem lze ukládat provedené příkazy, aby bylo možno provádět operace Undo a Redo podle potřeby obvyklým způsobem. V jsme popsali teoretické zázemí pro atomické (jednoduché, dobře definované) operace a kompozitní (složené, uživatelsky přívětivé) operace, které budou realizovat vlastní práci s modelem. Jedním z našich cílů také bylo, aby se obě úrovně abstrakce (PIM a PSM) daly používat nezávisle na sobě, pokud je to možné při zachování konzistence, i pokud existují mezi úrovněmi nějaké vazby. Operace proto pracují na svých úrovních a do jiné úrovně se šíří pouze tehdy, pokud existuje odpovídající vztah. Vzhledem k tomu, že máme poměrně složitý systém provozu, museli jsme vycházet z jednodušších kroků. To znamená, že mezi našimi atomickými operacemi je možné najít například operaci, která vytvoří atribut. Nedělá nic jiného, než že právě vytvoří atribut. Nezadává název atributu, není nastaven jeho datový typ, atd. V případě, že máme jiné atomické operace, můžeme je skládat a vytvářet složitější a uživatelsky příjemné typy. Základní kompozitní operace může být již zmíněná operace vytvoření atributu, která se doplní přejmenováním atributu, nastavením jeho četnosti a jeho datového typu. Pokud se jedná o PSM atribut, je nutné nastavit také jeho XForm (formát). Odpovídající operace pak představují předdefinované sekvence 4, nebo 5-ti operací, což je docela jednoduché. Další jednoduchý příklad může být vypuštění atributu. Příslušná kompozitní operace nastaví jeho mohutnost, jméno a typ na výchozí hodnoty a teprve poté atribut smaže. Důvodem je to, že když chceme tuto operaci zrušit (Undo), chceme, aby bylo možno název a jiné hodnoty atributu zotavit, takže není správné jen atribut odstranit. Zatím jsme popsali, jak sestavit atomické a kompozitní operace. Nicméně, tyto operace pracovaly na svých úrovních abstrakce. Nyní se musíme ujistit, že pokud existuje vztah mezi PSM-schématem a schématem PIM, udržíme model v konzistentním stavu. Toho je dosaženo šířením. Před každou atomickou operací se zjišťuje, zda není zapotřebí šíření efektu na jiné úrovni. Pokud ano, vytvoří se (zpravidla) kompozitní operace na jiné úrovni abstrakce a integruje se do právě probíhajícího procesu. Pouze v případě, že toto šíření uspěje, je posléze provedena původní atomická operace, která tuto akci způsobila. Tímto způsobem propagace se dosáhne toho, že když proces skončí, může být odvolán (Undo), jako každá jiná operace. 4 Příklad: Informační systém o veřejných zakázkách Náš přístup ke konceptuálnímu modelování XML schémat jsme vyzkoušeli na XML schématech z reálného světa, konkrétně na schématech použitých v Informačním systému o veřejných zakázkách (ISVZ - Je to informační systém, kde veřejné instituce zveřejňují data o jimi vypsaných a zadaných zakázkách. Veřejné instituce zasílají informace o zakázkách do tohoto systému jako XML zprávy formátované podle jednoho ze 17-ti XML schémat používaných ISVZ. Jsou to schémata pro oznámení o zakázkách, oznámení o výběru dodavatele, atd. Přijaté informace jsou poté zveřejněny v podobě HTML stránek. Cílem experimentu bylo ukázat, že náš přístup by ušetřil čas, pokud by autoři XML formátů pro ISVZ použili pro návrh XML schémat a jejich evoluci podle změn v legislativě náš nástroj exolutio, proti jejich ruční tvorbě a úpravám. V současnosti ISVZ poskytuje pouze textovou dokumentaci XML formátů a sadu vzorových XML dokumentů. Naším prvním úkolem je tedy vytvořit konceptuální schéma ve formě PIM (platformově nezávislého, konceptuálního) schématu, které by modelovalo doménu veřejných zakázek Poté vytvořit sadu PSM (platformově závislých, logických) schémat XML formátů, která budou namapována na schéma PIM. Schéma PIM obsahuje třídy, které modelují veřejné zakázky, jejich zadavatele a dodavatele (Obr 7). Dále modelujeme například ceny a kontaktní informace. Dodavatel je asociován se zakázkou přímo, zadavatel je se zakázkou asociován cestou asociací has_contact a main. Každá zakázka má další kontaktní informace místo, kde je dokumentace k zakázce a místo, kam se posílají nabídky na 18

22 Modelování XML schémat , Praha Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý MFF UK realizaci zakázky. Evidujeme 4 různé ceny. Očekávaná cena, nabízená cena, nasmlouvaná cena a konečná reálná cena, která je známa po dokončení zakázky. PSM schéma Obr 8(a) zobrazuje formát, který veřejná instituce používá pro zaslání oznámení o zakázce do ISVZ. Schéma Obr 8(b) zobrazuje formát pro oznámení o výběru dodavatele. Můžeme měřit množství ruční práce, která je potřeba pro návrh PIM a PSM-schémat jako počet vykonaných atomických operací. Počet atomických operací potřebných na vytvoření PIM a PSM schémat je na obrázku Obrázek 3(a). Ukazuje, že byly použity pouze operace pro tvorbu a změnu. Zde je potřeba ruční tvorba schémat v našem nástroji, takže tu žádné přímé výhody oproti ruční tvorbě XML schémat samotných nenajdeme. I tak ale exolutio šetří čas, protože pro každou provedenou operaci kontroluje, jestli se neporuší konzistence mezi XML formáty. V případě ručního psaní XML schémat musí tyto kontroly provádět sám návrhář. Obr 7: (a) PIM schéma modelující doménu ISVZ (b) PIM schéma upravené dle požadavků Když už máme PIM schéma a sadu PSM-schémat pro XML formáty používané v ISVZ, máme 3 cíle. Prvním cílem je ukázat, jak exolutio zprostředkovává tvorbu PSM-schémat na základě již existujícího schématu PIM. Nové schéma, které přidává detaily o zadavateli veřejné zakázky, je na obrázku Obr 8(c) a počet operací nutný k jeho tvorbě je na obrázku Obr 9(b). Opět byly použity pouze operace pro vytvoření a změny. I když musel návrhář schéma tvořit ručně, experiment ukazuje, že mu náš přístup šetří práci a brání mu v chybách. Je to tím že exolutio umožňuje tvorbu PSM-schémat na základě již existujících schémat PIM, což je rychlejší než tvorba samotného PSMschématu a zajišťuje, že návrhář vytvoří PSM-schéma konzistentně se schématem PIM. 19

23 Modelování XML schémat , Praha Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý MFF UK Obr 8: PSM schémata modelující XML formáty pro (a) zasílání oznámení o zakázkách (b) hlášení o výběru dodavatele (c) reprezentující detail o zadavateli Druhým cílem je zvýšit kvalitu modelovaných XML schémat. Jak si čtenář mohl všimnout, kvalita ISVZ XML formátů je nízká. Návrháři nevyužili standardních postupů při návrhu XML schémat. Konkrétně například nevyužili hierarchické podstaty XML. Informace o kontaktech jsou modelovány XML elementy s prefixy cont_, docs_ atd. Bylo by lepší odebrat prefixy a uzavřít sémanticky příbuzné elementy do oddělených XML elementů, například uzavřít informace o kontaktech do elementu contact, který by měl podelementy main a doc, nebo uzavřít informace o dodavateli do elementu supplier. Tyto změny jsme tedy udělali sami. Počet atomických operací potřebných na tyto změny je na obrázku Obr 9(c). V tomto kroku už byly použity i jiné typy atomických operací, například mazání. Opět se ukázalo, že práce v nástroji exolutio šetří čas udržováním konzistence XML formátů a schéma PIM. Upravené PSM-schéma z obrázku Obr 8(b) je na obrázku Obr 10. 4(b). Obr Je 9: vidět Počty že atomických informace operací je nyní reprezentována provedených ručně hierarchicky. (tmavá šedá) a automaticky propagačním mechanizmem (světlá šedá) Třetím cílem je ukázat, jak exolutio pomáhá při změnách v XML schématech. Udělali jsme tedy různé změny vyplývající ze změn v legislativě a z požadavků na novou funkcionalitu ISVZ. V obou případech bylo potřeba měnit schéma PIM. Nová funkčnost vyžadovala modelovat kontaktní osoby jako informaci oddělenou oproti dosavadní reprezentaci atributem contact_person. Proto jsme změnili atribut na třídu Person asociovanou s Contact a se dvěma novými atributy first_name 20

24 Modelování XML schémat , Praha Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý MFF UK a surname pomocí našich evolučních operací. Nová legislativa vyžadovala hlásit nejenom počet obdržených nabídek pro každou zakázku, ale i jednotlivé nabídky, což zahrnuje jak nabízejícího dodavatele, tak i nabízenou cenu. Proto jsme nahradili atribut number_of_bids třídou Bid s několika novými atributy. Změnili jsme sémantiku asociací supplied_by a offered jejich přepojením ze třídy Contract do nové třídy Bid. Nakonec jsme oddělili vítěznou nabídku od ostatních rozdělením asociace spojující Bid a Contract na dvě, offer a win. Změněné schéma PIM je na obrázku Obr 10(b). Jelikož se změnilo schéma PIM, PSM-schémata se musela změnit také. To bylo zajištěno naším mechanizmem propagací změn. Obrázky Obr 10(b) a Obr 10(c) zobrazují, jak byla schémata Obr 8(b), Obr 8(c) automaticky změněna propagacemi změn. Nakonec přišel požadavek na úpravu XML formátu (PSM-schématu) pro oznámení o zakázkách na Obr 8(a) tak, aby bylo možné specifikovat nejen počet let a měsíců na dokončení zakázky, ale také přesné datum kdy by zakázka měla být dokončena. Proto jsme zavedli nový atribut exp_date, který je možné použít ekvivalentně s atributy exp_months a exp_years. Tato změna byla správně automaticky vypropagována do schéma PIM na Obr 7(b) - jelikož se jedná o konceptuální změnu. Odtud pak do ostatních PSM-schémat na Obr 10(c). Počet operací v těchto posledních krocích je na obrázku Obr 9(d). Tmavší část ukazuje ručně spuštěné operace, světlejší pak operace automaticky spuštěné propagačním mechanismem a tedy ušetřenou práci. Obr 10: (a) PSM schéma se společnými částmi ostatních PSM schémat (b) upravené PSM schéma pro hlášení o výběru dodavatele zakázky (c) upravené PSM schéma pro reprezentaci detailů zadavatele 21

25 Modelování XML schémat , Praha Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý MFF UK 5 Závěr Příspěvek se snažil ukázat, že při práci s rodinou XML formátů je vhodné postupovat obdobně, jako při návrhu jiných datových modelů. Používaná schémata XML dokumentů je výhodné navrhnout a modelovat na konceptuální úrovni. Jejich konkrétní výřezy (pohledy) pak transformovat na logickou platformu XML schémat, ale se zachováním vazeb k původnímu konceptuálnímu modelu. Pro zpracování a evoluci použitých XML schémat je vhodné mít k dispozici nějakou programovou podporu. Ilustrovali jsme to na nástroji exolutio a jeho použití při modelování a úpravách XML schémat. Automatizace přináší zjednodušení práce a zejména zcela novou úroveň spolehlivosti při realizaci změn. Literatura A. Boronat, J. A. Cars ı, and I. Ramos. Algebraic Specification of a Model Transformation Engine. In: FASE 06: Proc. of the 9th Int. Conf. Fundamental Approaches to Software Engineering. Vienna, Austria, volume 3922 of LNCS, str Springer, F. Cavalieri. EXup: an Engine for the Evolution of XML Schemas and Associated Documents. In EDBT 10: Proc. of the 2010 EDBT/ICDT Workshops. str. 1 10, New York, NY, USA, ACM. S. V. Coox. Axiomatization of the Evolution of XML Database Schema. Program. Comput. Softw., 29(3): , K. Czarnecki and S. Helsen. Feature-Based Survey of Model Transformation Approaches. IBM Syst. J., 45(3): , E. Domínguez, J. Lloret, A. L. Rubio, and M. A. Zapata. Evolving XML Schemas and Documents Using UML Class Diagrams. In: DEXA 05: Proc. of the 16th Int. Conf. on Database and Expert Systems Applications, volume 3588 of LNCS, str Springer, J. Klímek, L. Kopenec, P. Loupal, and J. Malý. XCase - A Tool for Conceptual XML Data Modeling. In: Advances in Databases and Information Systems, volume 5968/2010 of Lecture Notes in Computer Science, str Springer Berlin / Heidelberg, March URL: J. Klímek, J. Malý, and M. Nečaský. exolutio A Tool for XML Data Evolution, URL: J. Klímek and M. Nečaský. Integration and Evolution of XML Data via Common Data Model. In: Proceedings of the 2010 EDBT/ICDT Workshops, Lausanne, Switzerland, March 22-26, 2010, New York, NY, USA, ACM. Microsoft. Windows Presentation Foundation (WPF). December URL: J. Miller and J. Mukerji. MDA Guide Version Object Management Group, M. Nečaský, J. Klímek, J. Malý, and I. Mlýnková. Evolution and Change Management of XMLbased Systems. Journal of Systems and Software, 85(3): , M. Nečaský, I. Mlýnková, and J. Klímek. Model-Driven Approach to XML Schema Evolution. In: R. Meersman, T. S. Dillon, and P. Herrero, editors, OTM Workshops, volume 7046 of Lecture Notes in Computer Science, str Springer,

26 Modelování XML schémat , Praha Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý MFF UK OMG: Model Driven Architecture (MDA): The Architecture of Choice for a Changing World. Object Modeling Group, March UML: OMG: Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification Version 1.0. Object Modeling Group, April URL: OMG: Unified Modeling Language, Object Management Group, nov URL: OMG: XML Schema Definition Language (XSD) 1.1, Recommendation 5 April URL: Richta, K.: Jazyk OCL a modelem řízený vývoj. In: Moderní databáze Komix Poděkování Tento příspěvek vznikl za částečné podpory Nadačního fondu AVAST. Summary The lecture is to provide information about XML data modeling, creating an abstract data model so that we can validate whether the documents are syntactically correct, whether they correspond to the schema documents, and can then be processed as a strongly typed. In addition, by publication of XML schema we can achieve greater standardization in the transfer of documents. Modeling XML schema is also useful for the necessary transformations of XML documents, if we need to change their structure. 23

27 Integrované systémy Oracle pro svět SQL i NoSQL , Praha David Krch, Oracle ČR Integrované systémy Oracle pro svět SQL i NoSQL David Krch Oracle ČR Adresa: V Parku 2308/8, Praha Tel: david.krch@oracle.com www: Klíčová slova: Abstrakt: Většina organizací ve snaze o chytřejší fungování ukládá čím dál větší objemy dat a používá stále sofistikovanější postupy pro jejich zpracování a analyzování. Ve spojení s požadavky na rychlejší zpracování a na snižování nákladů na IT se to může jevit jako neřešitelný problém. Zajímavé řešení však již několik let představuje rozrůstající se rodina integrovaných systémů Oracle. Na přednášce bude představena Oracle NoSQL Database, možnosti její integrace s tradiční Oracle Database a integrované systémy představující výkonnou a spolehlivou platformu pro provoz obou databázových technologií. 1 Přínosy integrovaných systémů Oracle Většina organizací v současnosti hledá způsoby jak zefektivnit fungování své IT infrastruktury - zvýšit její výkon a snížit náklady na její provoz. Tradičním řešením je konsolidace do architektury jednotných technologických vrstev, které má přinést lepší možnosti sdílení výkonu jednotlivých komponent mezi různými aplikacemi. Firmy tak investují značné prostředky do vrstvy univerzálních diskových polí, univerzální SAN infrastruktury, síťové infrastruktury, univerzálních serverů a obvykle také do vrstvy virtualizačních technologií. Na takto vytvořenou univerzální infrastrukturu, složenou často z technologií různých výrobců, pak konsolidují jednotlivé aplikace. Tento přístup rozhodně přináší úspory ve srovnání s provozem jednotlivých aplikacích na samostatných dedikovaných komponentách a nabízí zákazníkovi prakticky neomezenou flexibilitu. Univerzalita jednotlivých vrstev s sebou přináší také značnou režii a především vede ke vzniku velmi složité infrastruktury. Navíc díky široké škále možných kombinací komponent a jejich konfigurací je velká šance, že konkrétní vytvořená konfigurace je ve světě unikátní a tudíž může přinášet i unikátní problémy. Oracle již v roce 2008 představil alternativní přístup k budování IT infrastruktury postavený na tzv. integrovaných systémech (v angličtině Engineered Systems). Základní myšlenkou tohoto přístupu je radikální zjednodušení IT infrastruktury vedoucí ke snížení nákladů na její provoz a současně i k významnému zvýšení výkonu. Místo aby si zákazník pořizoval samostatně jednotlivé technologické vrstvy a sám je instaloval, využije integrovaných systémů specializovaných pro určitý typ úloh, které v sobě již mají předkonfigurované všechny potřebné hardwarové a softwarové komponenty. Například systém určený pro provoz databáze v sobě zahrnuje nejen databázové servery, operační systém a databázový software, ale také veškerá potřebná datová úložiště a vysokorychlostní síťovou infrastrukturu propojující jednotlivé komponenty. Na první pohled se může zdát, že integrované systémy jdou proti trendu konsolidace. Důležité ale je uvědomit si, že i když je flexibilita pro dnešní IT oddělení velmi důležitá, jen zřídka dochází ke kompletní změně např. databázové vrstvy. Často se pak setkáváme se situací, kdy zákazník nákladně vybuduje univerzální infrastrukturu na základě tradičních vrstev, ale velká část takové univerzální infrastruktury (často i většina) slouží pro množství různých aplikací využívajících Oracle Database či Fusion Middleware. I když se tedy v čase mění konkrétní rozložení zátěže mezi jednotlivými 24

28 Integrované systémy Oracle pro svět SQL i NoSQL , Praha David Krch, Oracle ČR aplikacemi, procento zdrojů potřebných pro databázovou nebo middleware vrstvu se obvykle nemění. Flexibilita vybudované tradiční infrastruktury tak zůstává nevyužita, zatím co se projevuje režie spojená s touto flexibilitou. Vysoká úroveň vzájemné integrace jednotlivých softwarových a hardwarových komponent integrovaných systémů Oracle vede nejen ke zjednodušení IT infrastruktury, ale umožňuje využít i některé unikátní technologie zajišťující často až k řádově vyšší výkon integrovaných systémů oproti tradičním systémům. Jedním z takových prvků je propojování jednotlivých serverů i integrovaných systémů mezi sebou pomocí síťové technologie Infiniband, která s přenosovou rychlostí 40 GBit/s přináší významné zrychlení přenosů dat, minimalizaci latence ale i zásadní snížení spotřeby CPU při přenosu dat ve srovnání tradičními technologiemi, jako je Fiber Channel (8 Gbit/s) nebo Ethernet (1 Gbit/s nebo 10 Gbit/s). Důležité je také to, že integrované systémy Oracle využívají všeobecně uznávané standardy a jsou sestaveny z běžně dostupných komponent, což zajišťuje snadnou možnost jejich integrace do stávajícího prostředí zákaznických aplikací a neuzavírá zákazníka do omezení obvyklých u proprietárních systémů. V další části budou detailněji popsány hlavní přínosy využití integrovaných systémů Oracle. 1.1 Rychlejší a jednodušší zprovoznění infrastruktury V tradiční architektuře univerzálních vrstev jsou jednotlivé komponenty obvykle navrhovány nezávisle na sobě a řeší pouze partikulární technologický problém, zákazník pak musí investovat značné prostředky do integrace jednotlivých komponent finální zprovoznění takové infrastruktury často trvá i několik měsíců. V integrovaných systémech Oracle jsou všechny obsažené komponenty již předintegrovány a při dodávce pouze technik Oracle provede automatizovanou záverečnou konfiguraci aby byly zohledněny požadavky zákazníka např. na síťové adresy apod. Řádově během hodin až jednotek dnů může zákazník systém používat v provozu. 1.2 Vysoký výkon I když jednotlivé komponenty v tradiční architektuře mohou v dané oblasti poskytovat špičkový výkon, výsledné řešení složené z řady takových komponent v sobě obvykle díky své složitosti obsahuje mnoho skrytých úzkých hrdel, které znemožňují plné využití výkonu těchto komponent. Integrované systémy Oracle jsou navrženy bez úzkých hrdel tak, aby bylo možné plně využít výkon všech integrovaných komponent. Také testování se provádí za systém jako celek a na zátěži, pro kterou je určen. Totéž platí i pro uváděné výkonnostní parametry. To umožňuje zákazníkovi jednodušeji určit potřebnou konfiguraci a její skutečný výkon. Vysoká míra integrace jednotlivých softwarových a hardwarových komponent navíc umožňuje poskytovat v integrovaných systémech řadu unikátních funkcí, které ve výsledku vedou k často i řádově vyššímu výkonu, než u srovnatelných tradičních systémů. 1.3 Snadnější správa Aby jednotlivé univerzální technologie pokryly širokou škálu možných použití, vyžadují obvykle rozsáhlou konfiguraci. To klade vysoké požadavky na jejich obsluhu a ve výsledku vede k tomu, že u větších zákazníků vznikají specializované týmy pro správu konkrétní technologické vrstvy. Při ladění výkonu systému jako celku či řešení jiných závažných situací je pak v některých případech problémem určit zodpovědnou osobu. V integrovaných systémech odpadá řada tradičních vrstev a správa ostatních je významně automatizovaná díky tomu, že je dopředu známý typ zátěže, pro který budou použity. V 25

29 Integrované systémy Oracle pro svět SQL i NoSQL , Praha David Krch, Oracle ČR databázových systémech tak například odpadá celá problematika ladění rozložení dat na disky, správa sdíleného souborového systému a logických svazků. 1.4 Jednotná podpora Tradiční IT infrastruktura je obvykle složena z dodávek různých výrobců a jednotlivé komponenty jsou konfigurovány a patchovány nezávisle na sobě. To zesložiťuje komunikaci zákazníka s dodavateli při řešení případných problémů. Navíc díky škále možných kombinací jednotlivých komponent ja jejich širokým možnostem konfigurace je reálné, že zákazníkem provozovaná konfigurace je zcela unikátní, což s sebou může nést i výskyt zcela unikátních problémů. Testování takové infrastruktury při jakékoliv změně (rekonfigurace, patchování některé z vrstev) je pak zcela na bedrech zákazníka. Výhodou integrovaných systémů je skutečnost, že veškeré obsažené komponenty jsou dodávány jediným dodavatelem v tomto případě firmou Oracle. Oracle také poskytuje podporu na systém jako celek. Oracle navíc provádí testování všech patchů a různých konfiguračních doporučení na integrovaném systému jako celku. Díky unifikované konfiguraci systémů je proto významně minimalizována možnost, že by při implementaci doporučeného postupu došlo u konkrétního zákazníka k neočekávaným problémům. Dostupnost souhrnných patchů implementujících doporučené opravy na všech vrstvách integrovaného systému dále zjednodušuje proces patchování. 1.5 Úspory Snazší implementace i jednodušší správa vedou k nezanedbatelným úsporám. Díky vyššímu výkonu a například i díky unikátním mechanismům komprese dat je zákazník schopný zajistit splnění provozních požadavků s menšími konfiguracemi, což může vedle úspor za napájení, chlazení a pronájem prostor vést i k potřebě menšího počtu licencí. 1.6 Vysoká dostupnost Základním principem integrovaných systémů Oracle je skutečnost, že i když se jedná o systémy dodávané jako celek, svou vnitřní strukturou tvoří vysoce dostupný systém složený z clusteru nezávislých serverů a dalších plně redundantních technologií. Výpadek některé z komponent tak neomezí dostupnost systému jako celku. Využití pokročilých softwarových technologií jako je Oracle Real Application Clusters, Automatic Storage Management, clustery WebLogic Serverů, nebo Oracle Coherence pak umožňují v každé chvíli plně využít výkon všech serverů integrovaného systému a sečíst tak jejich výkon. 1.7 Škálovatelnost výkonu S vyjímkou Oracle Database Appliance umožňují všechny integrované systémy Oracle postupné zvyšování výkonu propojováním několika integrovaných systémů dohromady, čímž může dojít k rozložení investic dle potřeby a k postupnému vytvoření jednotného systémů tvořeného clusterem desítek serverů s řádově až tisíci procesorovými jádry určenými pro provoz databázových či middleware vrstev aplikací. Takový výkon pak lze buď využít pro provoz jedné náročné aplikace nebo jej dynamicky rozdělovat mezi řadu různých aplikací. 26

30 Integrované systémy Oracle pro svět SQL i NoSQL , Praha David Krch, Oracle ČR 2 Integrované systémy pro SQL 2.1 Oracle Exadata Database Machine Oracle Exadata Database Machine byla vůbec prvním integrovaným systémem Oracle a je proto také v současnosti nejrozšířenější. Počet instalací již v polovině roku 2011 překročil systémů. Jde o systém navržený pro databázové aplikace s vysokými požadavky na výkon a dostupnost. Je možné jej použít jak pro provoz datových skladů, transakčních aplikací i konsolidovaná prostředí kombinující obojí. V závislosti na zvoleném modelu obsahuje různý počet databázových serverů s procesory Intel Xeon a speciální Exadata Storage Servery sloužící jako sdílená úložiště dat. Nabízené konfigurace přitom jsou sestaveny tak, aby byla vždy zajištěna vyváženost výkonu databázových serverů a Storage Serverů a nevznikala tak úzká hrdla. Díky technologii Real Application Clusters je možné využít současně výkon více serverů pro provoz společné databáze. Oproti běžným architekturám nabízí Oracle Exadata Database Machine několik unikátních technologií zajišťujících často i řádově vyšší výkon datázových operací: Smart Scan - odsunutí části databázové logiky přímo na Exadata Storage Servery. Storage Servery jsou schopny významně urychlit složité analytické operace a zmenšit objem dat přenášených do databázových serverů, protože přímo na úrovni datového úložiště mohou předfiltrovat data ještě před tím, než jsou poslány do databázového serveru. Toto předfiltrování probíhá s vysokou mírou paralelizace a tudíž i vysokým výkonem. Storage Index Storage Index je paměťová struktura, kterou si automaticky vytvářejí jednotlivé Exadata Storage Servery. Ta obsahuje pro určité rozsahy datových bloků minimální a maximální hodnoty některých sloupců tabulek. Storage Server může pomocí této struktury zcela eliminovat fyzické čtení určitého datového bloku z disku, pokud pomocí Storage Indexu zjistí, že blok nemůže obsahovat hledaná data. Hybrid Columnar Compression tato unikátní technologie umožňuje spojit výhody osvědčené Oracle Database a speciálních tzv. sloupcových databází. Umožňuje uložit vybrané tabulky či partitions fyzicky po sloupcích (místo obvyklého uložení po řádcích) a zkomprimovat. Protože sloupcové uložení zajistí vyšší podobnost dat uložených u sebe, dosahují použité algoritmy kompresního poměru 10:1 až 15:1, ale v některých případech i 50:1. Použití komprese je z pohledu aplikace zcela transparentní, i nad komprimovanými tabulkami lze využít plnou funkcionalitu Oracle Database. Inteligentní Flash Cache Storage servery obsahují transparentně řízenou vrstvu Flash paměti, pomocí které mohou významně zvýšit výkon při práci s daty z pohledu počtu I/O operací za sekundu. Storage Servery navíc získávají z databázových serverů dodatečná metadata o typu ukládaných a načítaných datových bloků a mohou tak inteligentně řídit strategii cachování. Více o Oracle Exadata Database Machine: Oracle Sparc SuperCluster Oracle Sparc SuperCluster je systém, který sdílí s Oracle Exadata Database Machine řadu společných konceptů i konkrétních technologií. Jedná se opět o integrovaný systém zahrnující cluster databázových serverů (tentokrát ale na platformě Sparc T4) a sadu Exadata Storage Serverů. Zatím co Exadata je však systém určený pro běh databázové logiky, Sparc SuperCluster umožňuje díky pokročilým technologiím virtualizace v jednom systému kombinovat jak databázovou logiku využívající Oracle Database, tak i aplikační logiku provozovanou na WebLogic Serveru, případně i další technologie. Mezi zajímavé technologie Sparc SuperCluster patří: 27

31 Integrované systémy Oracle pro svět SQL i NoSQL , Praha David Krch, Oracle ČR Exadata Storage Servery pro ukládání dat databázových dat s všemi výhodami výkonného a inteligentního zpracování zmiňovanými v případě Exadata tj. Smart Scan, HCC, inteligentní Flash Cache. Optimalizovaná komunikace softwarových komponent jednotlivé komponenty Oracle Fusion Middleware, jako je např. Oracle WebLogic Server využijí ve Sparc SuperCluster výhod komunikace přes Infiniband a dalších softwarových optimalizací díky kterým dochází k významnému zrychlení middleware logiky ve srovnání s využitím tradičního 10GBit Ethernetu. procesory Oracle Sparc T4 nová generace procesorů Sparc nabízí až 5x vyšší výkon v single-thread operacích oproti generaci T3 a v některých úlohách tak předčí i procesory Intel Xeon nebo IBM Power. pokročilé virtualizační technologie Oracle VM for Sparc a Solaris Containers umožňující vytvoření řady různých virtuálních prostředí bez negativního dopadu na výkon systému kompatibilita se staršími prostředí Sparc/Solaris díky zpětné kompatibilitě je SuperCluster ideální technologií pro migraci systémů provozovaných na starších verzích Solaris či starších verzích procesorů Sparc. Umožňuje také využít všech pokročilých technologií zabudovaných do léty osvědčeného operačního systému Solaris. Integrovaná ZFS Storage - pro ukládání instalací software aplikací apod. Více o Oracle Sparc SuperCluster: Oracle Database Appliance Oracle Database Appliance (ODA) představuje integrovaný systém určený pro menší systémy a prostředí vyžadující vysokou dostupnost databází. Na rozdíl od ostatních integrovaných systémů nebyl primárním cílem maximální výkon, ale především maximální jednoduchost. Tomu odpovídá i funkcionalita, nenajdete v něm sice některé technologie zajišťující vysoký výkon ostatních databázových integrovaných systémů, důraz zde ale byl kladen na jednoduchost použití a možnost škálování od skutečně minimálních konfigurací. Systém zahrnuje ve společném šasi dva databázové servery s procesory Intel Xeon a sdílený diskový prostor. ODA využívá Oracle Linux a Oracle Database Enterprise Edition. Servery je možné provozovat buď v režimu běžného failover clusteru, kdy je jedna databáze dostupná vždy pouze z 1 uzlu, ale v případě výpadku jsou příslušné procesy automaticky spuštěny na druhém serveru. Druhou možností je provoz v režimu Real Application Clusters, kdy lze pro přístup ke každé z databází využívat výkon obou uzlů současně. Mezi další zajímavé funkce ODA patří: Snadné zprovoznění zprovoznění databázového clusteru není o mnoho složitější, než zprovoznění moderního televizního přijímače. Po zapojení do napájení a k Ethernet síti je třeba vyplnit pouze několik základních parametrů, jako je jméno serveru a IP adresy a je zahájena zcela automatická konfigurace všech komponent. Cca do 1-2 hodin je plně redundantní databázový systém zcela funkční. Snadná aplikace oprav místo aplikace množství samostatných aktualizací na jednotlivé HW a softwarové komponenty zde může zákazník využívat pravidelně vydávaného souhrnného balíku oprav zahrnujícího aktualizace databázového software, clusterware, OS Linux, i firmware serveru a disků. Možnost postupného licencování ODA umožňuje postupnou aktivaci výkonu v rozsahu 2 až 24 procesorových jader s tím jak rostou požadavky zákazníka. Zákazník má možnost licencovat pouze aktivní jádra a tudíž rozložit investici v čase a minimalizovat riziko. 28

32 Integrované systémy Oracle pro svět SQL i NoSQL , Praha David Krch, Oracle ČR 3 Integrované systémy pro Big Data / NoSQL 3.1 Oracle Big Data Appliance Oracle Big Data Appliance (BDA) je integrovaný systém kombinující optimalizovaný hardware s předkonfigurovanou kompletní sadou software pro řešení sběru a organizace dat typu Big Data. Je navržena pro extrémní analytické požadavky nad všemi typy dat, pro které poskytuje vysoký výkon, dostupnost, škálovatelnost, bezpečnost a podporu. Pomocí Big Data Connectors lze jednoduše zajistit efektivní integraci tohoto systému s Oracle Exadata/Sparc SuperCluster, resp. obecně s Oracle Database a umožnit tak provádění souhrnných analýz nad tradičními podnikovými daty uloženými v Oracle Database i novými typy dat primárně uloženými v BDA. Hardware Big Data Appliance je tvořen rackem obsahujícím cluster 18 serverů Oracle/Sun s celkovou úložnou kapacitou 648 TB. Každý server má 2 šestijádrové procesory Intel Xeon a 48 GB paměti, celkem tedy rack obsahuje 216 procesorových jader a 864 GB paměti. Všechny servery jsou opět propojeny vysokorychlostní infrastrukturou Infiniband. I zde je možné výkon a kapacitu celého řešení zvyšovat propojením více Big Data Appliance do jednoho rozsáhlého systému. Software Big Data Appliance tvoří tyto hlavní komponenty: Cloudera Distribution including Apache Hadoop obsahující o Apache Hadoop framework pro distribuované dávkové zpracování rozsáhlých objemů dat metodou MapReduce. o Hadoop Distributed File System (HDFS) distribuovaný souborový systém zajišťující spolehlivé ukládání rozsáhlých objemů dat ve formě souborů na jednotlivé servery clusteru o Cloudera Manager správa prostředí Hadoop Oracle NoSQL Database distribuovaná databáze typu Key-Value využívající osvědčenou technologii Oracle BerkeleyDB. Klíčovým požadavkem při návrhu Oracle NoSQL Database přitom byla neomezená škálovatelnost systému a s tím spojená vysoká míra nezávislosti jednotlivých databázových uzlů. Inteligentní klient databáze sleduje aktuální topologii databázového clusteru a zajišťuje rozdělování dat mezi databázovými uzly. Stejně rozhoduje i o tom, ze kterého uzlu clusteru provede čtení dat v závislosti na aplikací požadovaných parametrech konzistence dat. Oracle NoSQL Database má oproti jiným distribuovaným databázovým systémům jednoduchou správu a podporuje širokou škálu různých úloh, včetně možnosti transakčního zpracování. Navíc však nabízí spolehlivý provoz a profesionální podporu vyžadovanou zákazníky podnikových systémů. Primárním použitím Oracle NoSQL Database jsou úlohy vyžadující ukládání dat s minimální latencí nebo jejich rychlé získávání na základě klíče. Komunikace s Oracle NoSQL Database probíhá přes snadno použitelné Java API. Oracle Enterprise Linux a Oracle Java VM Orcle Big Data Connectors o Oracle Loader for Hadoop umožňuje využít Hadoop MapReduce pro efektivní natažení dat do Oracle Database. Oracle Loader for Hadoop může být použit jako závěrečný krok zpracování dat ve frameworku MapReduce pro uložení zpracovaných dat do Oracle Database, kde mohou být data snadněji integrována s daty běžných informačních systémů a dále analyzována běžnými ad-hoc analytickými nástroji. Výhodou Oracle Loader for Hadoop je to, že přímo Hadoop cluster vytváří datové sady ve formátu používaném databází Oracle, což ve spojení s vysokou úrovní paralelizace zvyšuje výkon operace loadování dat. 29

33 Integrované systémy Oracle pro svět SQL i NoSQL , Praha David Krch, Oracle ČR o Oracle Direct Connector for Hadoop Distributed File System umožňuje připojit data uložená na BDA v HDFS ve formě textových souborů k Oracle Database a díky funkcionalitě externích tabulek využít tato data přímo uvnitř běžných SQL příkazů, ve kterých tak lze snadno kombinovat data uložená n HDFS a data uložená v běžné Oracle Database. Přístup k datům v HDFS je optimalizován pro rychlé zpracování dat s vysokou mírou paralelizace a automatickým rozkládáním zátěže. o Oracle Data Integrator Application Adapter for Hadoop umožňuje využít snadno použitelné grafické prostředí Oracle Data Integrator pro návrh a spouštění ETL úloh umožňujících transformaci dat a jejich finální uložení v Oracle Database. o Oracle R Connector for Hadoop umožňuje využít populární statistický jazyk R pro zpracování dat uložených v HDFS a rozšiřuje tak možnost použití R na prostředí rozsáhlých datových sad. Obdobná funkcionalita umožňující transparentní přístup z R k datům v Oracle Database je součástí Oracle Advanced Analytics. Více o Oracle Big Data Appliance: 30

34 Netezza to pravé řešení pro analytický datový sklad , Praha Martin Pavlík, IBM ČR Netezza to pravé řešení pro analytický datový sklad Martin Pavlík IBM Česká republika, spol. s r.o. V Parku 2294/4, Praha 4 Chodov, Tel: martin_pavlik@cz.ibm.com www: Klíčová slova: Netezza, datový sklad, analýzy, corporate performance management, business intelligance, IBM. Abstrakt: Příspěvek je v první řadě reakcí na jeden z nejviditelnějších trendů poslední doby ve světě využití technologií pro potřeby businessu. Tímto trendem je výrazný posun odpovědností a správy velké části technologických řešení z IT oddělení do útvarů, která mají s IT jen málo společného. Tento trend je velmi viditelný zejména v oblasti řešení pro řízení výkonnosti společností (v oblasti tzv. Corporate performance managementu). Až reakcí na tento trend je vývoj a zdokonalování nových technologií pro analýzu velkého množství dat, kde jednou z klíčových technologií, které se vyskytují v současné době na trhu, je IBM Netezza, jejímuž hrubému popisu je věnována druhá část příspěvku. V závěru se zamyslíme nad tím, jaká je budoucnost warehousingu jako taková a jak by mohl vypadat jeden z možných scénářů. 1 Svět IT a businessu dva různé světy? Z pozice technického specialisty orientovaného na problematiku datových skladů a řešení pro oblast corporate performance managementu (dále jen CPM), je velmi zajímavé sledovat, jak dynamická tato oblast je a jak zásadně se zvláště v poslední době tato specializovaná oblast mění. Jsouce svědkem těchto změn je člověk nucen chtě nechtě provádět i poměrně netriviální mentální kotrmelce. Pravdy, které se jevily jako dogmata, jsou najednou tytam a na celou řadu věcí je dnes možné nahlížet zcela nestandardním, ale přitom překvapivě jednoduše efektivním způsobem. 1.1 Přesun velké části odpovědností z IT na business Na to, že se oblast problematiky datových skladů a CPM řešení dostává čím dál tím více ze sféry specializovaných IT oddělení a stává se tak doménou jednotlivých business oddělení, je již asi zbytečné upozorňovat. Tento trend je tady již několik let a má své příznivce i odpůrce. Z našich osobních zkušeností u jednotlivých společností v České republice je možné v naší zemi vidět obě zmíněné skupiny. Na straně IT jednak existuje celá řada pracovníků, která se může díky přesunu klíčových dovedností na pracovníky businessu cítit méněcenných a může mít obavy o své pracovní místo. Jednak zde ale existují i taková IT oddělení, která přijímají tento trend s nadšením, protože přesun celé řady prací na business oddělení, zbavuje IT oddělení zodpovědnosti za věci, kterým pracovníci IT zcela nerozuměli a které vykonávali jen proto, že se týkaly datové vrstvy a ta je do dnešní doby pro většinu business pracovníků naprosto tabu. Na straně businessu je tento trend přijímán veskrze pozitivně. Zatím. Business oddělení jsou ta, která definují své potřeby týkající se řešení pro oblast CPM a logicky i požadují, aby tato řešení k nim měla co nejblíže a mohli si je spravovat sami uživatelé z řad businessu. To, na co ale business uživatelé často nejsou připraveni, je jejich téměř úplná zodpovědnost za dané řešení. Každá mince 31

35 Netezza to pravé řešení pro analytický datový sklad , Praha Martin Pavlík, IBM ČR má dvě strany a tady to platí dvojnásob. V okamžiku, kdy se IT oddělení vzdá zodpovědnosti za značnou část vlastní implementace řešení, nechce se zabývat problémy, které si vyrobí lidé v businessu. I zde se ukazuje, že naprosto zásadním aspektem úspěchu absorbování tohoto trendu je komunikace. Je tím míněna komunikace mezi IT a businessem. Oba tyto světy jsou často od sebe na hony vzdálené a doslova mluví každá z nich jiným jazykem. Dokonce by se dalo říci, že jsou od sebe tak daleko, že některá klíčová slova jedné skupiny jsou zaklínadlem pro skupinu druhou. Je velmi zajímavé sledovat, jak se pozornost business auditoria jakéhokoliv workshopu rapidně zhorší po vyslovení takových pojmů, jakými jsou procesor, ETL, apod. Stejným zaklínacím efektem působí na obecenstvo z řad IT např. pojem zisk před zdaněním, auditem a opravnými položkami. 1.2 Metadata klíč ke společné řeči businessu a IT Metadata představují prostředek, který dokáže případné třecí plochy mezi businessem a IT do značné míry eliminovat. To, co si představit pod pojmem metadata je přinejmenším v IT světě poměrně dobře známé. Většinou jsou jako metadata označována data o datech. Pracovníci IT si jako metadata představují např. popisy datových struktur, ETL procesů, apod. Málo známý je ale tento pojem mezi pracovníky business oddělení. Přitom ale metadata mají zásadní význam i tam. Jedná se o tzv. business metadata, která nepředstavují nic jiného než jednoznačné definice jednotlivých používaných pojmů a definice závislostí mezi nimi. Největší přínos pro fungování organizace ale metadata přinášejí v okamžiku, kdy se business metadata a technická IT metadata propojí dohromady. V ten okamžik začne být jednoznačně definováno, že ten a ten business pojem zmiňovaný ve všech BI reportech připravovaných pro jednání představenstva společnosti má datovou oporu v konkrétním sloupci, tabulce, databázi a serveru a že se data do tohoto sloupce dostala prostřednictvím určitého ETL procesu, který se spouští každý den v šest ráno a byl naposledy spuštěn tehdy a tehdy a přenesl do příslušné tabulky ten a ten počet datových záznamů. Zásadnost tohoto propojení světa businessu a IT vychází z toho, že se vše neustále vyvíjí. A to platí i pro požadavky business uživatelů. S existencí příslušně propojené metadatové vrstvy může v případě nutnosti IT pracovník provést příslušný zásah do datové či datově integrační infrastruktury tak, aby vyhověl požadavku, který je definován jazykem businessu. Bez existence této vrstvy velmi reálně hrozí, že IT pracovník bude mít velký problém s pochopením toho, co po něm vlastně business chce a má tak v zásadě dvě možnosti: Buď se zeptá a bude doufat, že se zeptá té správné osoby, která mu neznámý pojem použitý v zadání úkolu objasní tak, jak je ve společnosti vnímán, a nebo se pokusí vysvětlit si neznámý pojem po svém a bude doufat, že se ve svém výkladu zadání trefil do představ zadavatele ze strany businessu. Přítomnost univerzální metadatové vrstvy propojující IT a business metadata je základem úspěchu jakéhokoliv CPM management řešení, protože právě v této vrstvě je možné provést odstínění business pracovníků od světa IT. Lidé z business oddělení potřebují, aby ve svých reportech a analýzách viděli hodnoty, jejichž významu rozumí a jsou schopni jej popsat svým business jazykem tak, aniž by museli znát přesná jména databázových tabulek a sloupců, natož pak uměli psát SQL dotazy. Ideální pro ně je, když mají možnost si i sami vydefinovat podobu vlastních reportů a analýz a při této práci chtějí samozřejmě pracovat s pojmy, kterým rozumí. Vůbec je nemusí zajímat detaily datového modelu od toho je právě dokáže odstínit kvalitní metadatový model. Aby tato univerzální vrstva metadat mohla vzniknout, je samozřejmě zapotřebí, aby existoval někdo, kdo je na pomezí businessu a IT a na úrovni metadat pomáhá definovat vazby mezi světem businessu a IT. Protože je tento proces často velmi bolestivý a jeho součástí je i definice odpovědností za jednotlivé části metadatové vrstvy, naráží tato osoba často na velmi tuhý odpor některých jedinců v organizaci. Je naprosto nezbytné, aby tato osoba měla dostatek pravomocí k tomu, aby pasivitu odpůrců tohoto řešení zlomila. 32

36 Netezza to pravé řešení pro analytický datový sklad , Praha Martin Pavlík, IBM ČR 1.3 Business uživatelé a jejich schopnost uvařit datový sklad V okamžiku kdy je tématem přenesení velké části zodpovědností za podobu reportů a analýz na business a business uživatelé jsou také těmi, kdo provádí celou řadu ad-hoc analýz a vytvářejí si vlastní ad-hoc reporty, hrozí poměrně výrazně, že svou aktivitou, nemaje potuchy o tom, co za hrůzné SQL konstrukce na pozadí jejich aktivit vznikají, datový sklad takříkajíc uvaří. To je přesně důvod, proč celá řada IT administrátorů vnímá zodpovědnost za CPM řešení v rukou businessu za potenciálně velmi nebezpečný stav. Velmi dobře si pamatuji na schůzky s některými našimi zákazníky týkající se dodaného CPM řešení, kde si business uživatelé stěžovali na velmi špatnou výkonnost systému v případě, že si začnou definovat svoje vlastní ad-hoc dotazy či chtějí provádět vlastní ad-hoc analýzy. Tenkrát jsme jim s kolegy říkali, že to, co způsobuje onu pomalost systému není koncové CPM řešení, ale databázová vrstva pod ním. Snažili jsme se jim vysvětlit, že pokud nejsou dopředu schopni definovat, jak budou jejich ad-hoc reporty a analýzy vypadat, jen těžko bude moci IT oddělení připravit příslušnou databázovou infrastrukturu tak, aby jejich dotazy byly vykonávány rychle. Naštěstí v poslední době do naší země začaly přicházet technologie, které tuto naši předchozí odpověď staví do jiného světla a které jistě potěší všechny koncové uživatele CPM řešení. Tyto technologie přichází s poměrně logickým pozorováním: Využití relačních databází jako podkladové datové vrstvy pro analytické ad-hoc dotazy sice přináší na jedné straně koncovým business uživatelům velkou flexibilitu, nicméně klasické relační databáze, které jsou optimalizované pro využití v rámci OLTP aplikací, nejsou na analyticky laděné dotazy stavěny. Analytické dotazy tak vedou k nechvalně proslulým full-scanům, jejichž důsledkem jsou neúnosné časy odezev databázového systému. Slabá výkonnost klasických relačních databází pak samozřejmě příslušným způsobem odrazuje analyticky laděné uživatele z řad businessu (nejčastěji se v tomto případě rekrutují z řad oddělení marketingu, řízení rizik či finančního controllingu) od toho, aby řešení používali. 1.4 Efektivní řešení pro oblast datových skladů Technologická řešení nejrůznějších dodavatelů nabízí celou řadu přístupů, jak se s analyticky laděnými ad-hoc dotazy smysluplně popasovat. V zásadě je možné tyto přístupy principiálně rozdělit do tří kategorií: Databázové akcelerátory udržující navíc kopii velké části dat (až jednotky TB) v paměti RAM Sloupcové databáze ukládající relační data po sloupcích Databázové technologie využívající masivního paralelismu a zpracování dotazů z velké části na úrovni HW Někteří dodavatelé technologií nabízejí i více než jeden z těchto přístupů a umí je i vhodně kombinovat. Všechny přístupy mají vedle diametrálních rozdílů i některé společné prvky. Mezi ty společné patří především snaha o minimalizaci čtení dat z disku, protože čtení z disku je stále řádově pomalejší než čtení dat z paměti RAM. Propastný rozdíl mezi rychlostí čtení dat z pevného disku a pamětí RAM byl inspirací pro technologie paměťových databázových akcelerátorů, které se starají o to, aby co největší část dat datového skladu či datového tržiště, jež je použita při analytických dotazech, byla replikována do paměti RAM a náročné analytické dotazy mající full-scanový charakter mohly proběhnout na úrovni paměti RAM. Myšlenka je to velmi hezká a vedle výhod samozřejmě přináší i určité nevýhody. První z nich je samozřejmě nutnost synchronizace mezi daty na disku a v paměti RAM, ale toto je v dodávaných řešeních poměrně obstojně řešeno. Druhou nevýhodou je nutnost mít pořízeno velké množství paměti RAM nejčastěji stovky GB až jednotky TB. Aby byl problém s velikostí paměti RAM méně palčivý, jsou paměťově orientované technologie vybaveny i příslušnou efektivní kompresí dat a nezřídka využívají i principů sloupcově orientovaných databází. 33

37 Netezza to pravé řešení pro analytický datový sklad , Praha Martin Pavlík, IBM ČR Sloupcové databáze jsou takové databázové systémy, které interně data ukládají po sloupcích. Každý sloupec je navíc ukládán obvykle samostatně. Tento přístup má řadu benefitů, z nichž nejvýznamnější jsou: minimalizace objemu dat, který je nutné přečíst z disku, pouze na sloupce, jež jsou skutečně potřeba hodnoty uložené ve sloupcích jsou vlastně indexem, takže jednoduché indexy zde existují samy o sobě vysoká rychlost zpracování agregací možnost využití paralelního čtení / zápisu / agregací každé vlákno může pracovat s jedním sloupcem data ve sloupcích v DWH se dají obvykle velmi dobře komprimovat Samozřejmě, že i sloupcové databáze mají své nevýhody. Těmi, které se asi nabízí na první pohled, jsou problémy vyplývající z toho, že sloupcová technologie musí chtě nechtě interagovat s klasickým relačním řádkově orientovaným světem. S problémy výkonnostního charakteru se tak můžeme setkat v okamžiku, kdy potřebujeme provést konverzi řádkově orientovaného datového zdroje do sloupcové technologie. Problém je samozřejmě větší s větším objemem dat v řádu stovek GB až TB. Poslední, a v praxi velmi často používaný přístup, je využití principu hrubé síly. Vychází z teze, že v okamžiku, kdy analytik dopředu neví, na co se bude chtít zeptat a dost možná bude potřeba projít na principu full-scanu obrovské množství dat, není nic lepšího, než problém vyřešit hrubou silou prostřednictvím metody rozděl a panuj s využitím skutečně masivního paralelismu a realizací mnoha operací (dekomprimace, projekce, selekce, efektivní přístupová oprávnění) na úrovni specializovaného hardwaru, který tak zajistí, že se k jádrům paralelně běžících procesorů dostanou až ta data, která projdou poměrně velmi jemným hardwarovým sítem. U těchto systémů se navíc využívá principu tzv. shared nothing architektury, který spočívá v tom, že každá podúloha, která vznikne rozdělením primární velké úlohy na menší části, má k dispozici kompletně vyhrazenou sadu prostředků zahrnující vlastní disk, cache paměť, jádro HW akcelerátoru provádějící výše zmíněné operace (dekomprimace, projekce, ) na HW úrovni a konečně samozřejmě konvenční jádro CPU. Nedochází zde tedy k žádným časově náročným a neefektivním komunikačním bojům, které se objevují v případě sdílení těchto prostředků. V okamžiku, kdy se používá taktika hrubé síly, berou i v tomto případě za své standardní databázové prostředky jakými jsou např. indexy, table spaces či statistiky. Neexistence zmíněných standardních databázových prostředků znamená u řešení prostřednictvím masivního paralelismu a hrubé síly další výhodu a tou jsou velmi nízké nároky na správu takového systému. Zákazník dostává v podstatě black-box, který se efektivním způsobem sám postará o naprostou většinu funkcí, jež od něj koncový business uživatel očekává. Jak je vidět, základních přístupů, jak se popasovat s náročnými analytickými potřebami koncových business uživatelů, je několik a jednoduše není možné říci, který z nich je v daném případě nejvýhodnější. Jediné, co možné říci jistě je, že pro opravdu velké objemy dat (nad 10 TB) není vhodné využití paměťových akcelerátorů. V takovém případě je vhodné sáhnout po sloupcové databázi či speciálním řešením, jež je postaveno na kombinaci HW a SW a využívajícím masivního paralelismu. V případě toho později jmenovaného pak není zásadním problémem se popasovat se skutečně obrovskými objemy dat v řádu PB. Mnohdy může být nejvýhodnějším řešením vyvážená kombinace různých diskutovaných přístupů. Jednotliví výrobci technologií samozřejmě vyzdvihují vlastnosti té své, která jde zatím téměř vždy jedním z těchto tří diskutovaných směrů a mnohdy se neohlížejí na skutečné potřeby koncových zákazníků. Změní se někdy tato, pro koncového zákazníka často nepříjemná skutečnost? Nechme se překvapit. 2 IBM Netezza A kam tedy patří Netezza? A co je to vůbec zač? 34

38 Netezza to pravé řešení pro analytický datový sklad , Praha Martin Pavlík, IBM ČR Společnost Netezza vznikla v roce 2001 a byla první společností na světě, která přišla s konceptem data warehouse appliance, tj. kombinací jednotek zajišťujících jednak masivní hardwarově orientovaný paralelismus zpracování náročných analytických úloh, jednak využívající cenově dostupné a přitom spolehlivé úložiště dat a v neposlední řadě pak osvědčený databázový software. Netezza jako první přišla a dnes i pod hlavičkou IBM (k akvizici došlo 11. listopadu 2010) stále rozvíjí svůj základní koncept, který je založen na zpracování dat na úrovni speciálně připraveného hardware ještě před tím, než je začne zpracovávat klasický procesor prostřednictvím databázového software. Tento koncept umožňuje analytikům provádět své analýzy mnohonásobně rychleji a to vše s minimálními administrativními nároky. To, čím se Netezza výrazně odlišuje od konkurence, je jednoduchost celého řešení, což má naprosto zásadní pozitivní dopad na flexibilitu, kterou mohou disponovat koncoví uživatelé systému. To jde ruku v ruce s obsahem předchozí kapitoly, kterou se jako pomyslná červená nit táhne téma výrazného posunu správy jednotlivých technologických aplikací přímo koncovými business uživateli. Business a analyticky orientovaní uživatelé jsou Ti, kteří si sami určují, jak se bude daná koncová aplikace chovat a za chodu mění kritéria pro datové selekce použité při konkrétních analýzách či v rámci rozhodování. Netriviální změny kritérií vedou k obrovské variabilitě databázových dotazů a jen systémy, které jsou dobře připraveny na ad-hoc charakter dotazování, mohou náročného koncového business uživatele uspokojit. Důkazem toho, že práce s Netezzou je opravdu jednoduchá, jsou zejména četné reference zákazníků, kteří byli schopni zprovoznit a následně pak udržet systém v chodu za naprosto minimálního zásahu databázového administrátora, který v zásadě většinu času věnuje pouze správě datového modelu. Díky tomu, že Netezza patří do výše zmiňované třetí skupiny technologií, tj. technologií využivající masivní paralelismus a shared nothing architekturu s podporou speciálního HW, tak klasické, v jiných systémech tak běžné, administrátorské činnosti jakými jsou např. správa indexů, table space, práce s logy, apod., v appliance IBM Netezza vůbec neexistují. Do nedávna neexistovala ani organizace Netezza Professional Services zajišťující dodávku služeb, jež souvisejí se správou databáze Netezza. Je tomu tak proto, že nebyla vůbec potřeba. Po akvizici Netezzy společností IBM tato organizace přece jen vznikla, ale její členové se specializují zejména na práce a činnosti, které souvisejí s migracemi ze stávajícího databázového prostředí zákazníků IBM do systému IBM Netezza. 2.1 Architektura systému IBM Netezza Systém IBM Netezza je dodáván zákazníkům ve formě racku. Může se jednat o full-rack, poloviční rack či rack čtvrtinový. Může se jednat také o několik racků v řadě. V současné době je podporováno až 10 propojených racků a kapacita takového 10-rackového systému pro uživatelská data je cca 1,3 PB dat. V každém full-rackovém systému IBM Netezza dochází ke kombinaci dvojice SMP serverů (dále budou označovány jako host) s 12 MPP blade servery fungující na principu sharednothing architektury (dále budou označovány jako S-Blades). S-Blade obsahuje 8 jader Intel procesoru a 8 jader speciální aritmeticko-logické jednotky (označované jako FPGA = Field Programmable Gate Array) a odpovídající paměť RAM. 1 jádro Intel procesoru, 1 jádro FPGA a odpovídající část paměti RAM v S-Blade pak reprezentuje určitou paralelní logickou jednotku, ke které je přiřazen právě jeden disk. Poměr mezi jádrem Intel procesoru, jádrem FPGA a diskem je 1:1:1, což je přesně to, co reprezentuje shared-nothing architekturu. Díky tomu, že je ve fullrackovém systému jednotek S-Blade 12 a každá z nich má po 8 jádrech Intel procesoru a FPGA, existuje ve full-rackovém systému 96 naprosto paralelních jednotek. 35

39 Netezza to pravé řešení pro analytický datový sklad , Praha Martin Pavlík, IBM ČR Obr. 1 Asymetrická architektura MPP systému IBM Netezza Architektura IBM Netezza poskytuje i odpovídající schopnost fault-tollerance, která je u jednotlivých popsaných komponent zajištěna následujícím způsobem: SMP Host Ve full-rackovém systému je vždy dvojice SMP hostů s OS Linux Red Hat v režimu active / Pasove Disk RAID 1 pro uživatelská data a RAID 10 pro systémová data. Disků je v systému 96, ale jen 92 se aktivně využívá. 4 zbývající disky jsou určeny právě pro případ výpadku některého z aktivních disků. 2 z 12 jednotek S-Blade tedy nemá přiřazeno 8 disků, ale jen 6. Celkový stupeň paralelismu v IBM Netezza je tedy 92. S-Blade V případě výpadku jednotky S-Blade je 8 disků, které jsou k ní přiřazeny, automaticky přerozděleno jak jen rovnoměrně je to možné zbývajícím S-Blade jednotkám. V žádném případě, ale nedochází v případě výpadku jakékoliv komponenty k výpadku celého systému. Zdvojena je i příslušná síťová infrastruktura uvnitř appliance. Zpracování SQL dotazů a paralelizovatelných algoritmů pak funguje na principu rozděl a panuj, kdy je SQL dotaz přijat na straně SMTP hostu, kde je vyhodnocen optimální query plan, dojde ke kompilaci dotazu a příslušné tzv. snippety (parametry pro aritmeticko-logickou jednotku FPGA) jsou paralelně zaslány na jednotlivé jednotky S-Blade. Zde zpracování funguje dle obrázku níže. Výsledek částí dotazu je pak z jednotlivých paralelních jednotek posbírán a na SMTP hostu je následně zkonstruován odpovídající výsledek. 36

40 Netezza to pravé řešení pro analytický datový sklad , Praha Martin Pavlík, IBM ČR Obr. 2 Zpracování dotazu na úrovni paralelní jednotky S-Blade Jak již bylo řečeno výše, technologie IBM Netezza je maximálně jednoduchá a společnost IBM má mnoho zákazníků, kteří technologii ke své spokojenosti používají způsobem, kde není využit žádný z pokročilejších konceptů zmíněných v další části popisu. Hrubá síla paralelního zpracování spolu s automaticky fungujícím níže popsaným konceptem tzv. zónových map jsou pro jejich spokojenost naprosto dostatečné. Pro minimalizaci čtení dat z disku používá Netezza koncept tzv. zónových map, který je ve své koncepci částečně blízký konceptu indexů používaných v jiných databázích. Pro každý sloupec, pro který je zónova mapa vytvořena, je systémem udržována tabulka intervalu hodnot, kterých daný sloupec nabývá v datech, jež jsou uložena na konkrétním disku. Systém pak při vyhodnocování konkrétního SQL dotazu ví, zdali se hledaná hodnota na konkrétním disku nachází či nikoliv a v případě, že tomu tak není, neobtěžuje se jeho čtením. Zónové mapy jsou automaticky vytvářeny pro všechny sloupce datových typů integer, date a time stamp. V případě, že je vhodné vytvořit zónové mapy i nad sloupci jiných datových typů, je to samozřejmě možné. Údržba zónových map je plně automatická a administrátor se o ni nemusí vůbec starat. Největší benefit přináší využití zónových map v okamžiku, kdy jsou data v tabulce setřízena. Aby mohla být data v tabulkách setřízena i podle několika sloupců zároveň, přišla společnost IBM s konceptem tzv. Clustered Based Tables, kde je možné mít tabulku setřízenou zároveň až podle čtyř sloupců. Koncept Clustered Based Tables je založen na tzv. Hilbertových křivkách a nemá žádné dodatečné nároky na úložný prostor. V každém řešení využívající masivní paralelismus je výkonnost do značné ovlivněna výkonností nejpomalejší paralelní jednotky. A rychlost jednotlivé paralelní jednotky je pak ovlivněna nejvíce objemem dat, který je uložen na odpovídajícím disku. Rovnoměrné rozložení dat je tedy základem pro zajištění dobré výkonnosti systému. Typicky se data distribuují na jednotlivé paralelní jednotky / disky dle kritérií definovaných administrátorem. Mělo by se jednat o sloupec či kombinaci sloupců, které jsou co nejvíce selektivní a vystupují v joinech. V případě, že žádný sloupec pro distribuci dat není vybrán, Netezza se postará o náhodné rozdělení záznamů na jednotlivé jednotky tak, aby bylo zajištěno přibližně rovnoměrné rozdělení dat mezi ně. Na tomto místě jen zopakujme, že existuje mnoho společností, které nedefinují žádný distribuční klíč, tj. atribut pro distribuci dat mezi paralelní jednotky, ani nepoužívají koncept clustered based tables a i tak jsou s řešením maximálně spokojeni. Jednoduchost správy (v tomto případě naprosto žádná administrace a správa) je pro tyto společnosti větším přínosem než další zlepšování výkonnosti systému, který už tak funguje dostatečně rychle. Systém IBM Netezza používá specifický mechanismus, kterým nahrazuje používání transakčních logů. U každého záznamu v databázi jsou mj. udržovány i tři speciální skryté sloupce: CreateXID číslo transakce, při které byl záznam vytvořen 37

41 Netezza to pravé řešení pro analytický datový sklad , Praha Martin Pavlík, IBM ČR DeleteXID číslo transakce, při které byl záznam zneplatněn Rowid unikátní číslo řádku identifikující logicky unikátní řádky, jež měnily hodnoty v čase Každá databázová operace typu update je vždy realizována jako dvojice delete + insert. Záznam, který se do tabulky dostal, či z ní byl odstraněn v rámci transakce, která dosud ještě nebyla potvrzena commitem je pak snadno (na HW úrovni FPGA a s využitím zónových map, které automaticky existují a používají se i pro tyto speciální skryté sloupce) odfiltrována, protože systém si udržuje informaci o transakcích, které commitem potvrzeny byly, a které ne. Stejný mechanismus filtrace je použit např. i při realizaci on-line backupu. Pro větší ozřejmění použitého mechanismu přikládáme následující schéma: Obr. 3 Transakce v systému IBM Netezza V okamžiku, kdy v systému dochází k velmi častým databázovým operacím UPDATE a DELETE, roste objem dat v systému a musí se periodicky spouštět operace odmazávání neplatných záznamů tzv. GROOMING. Toto se typicky samozřejmě děje automaticky prostřednictvím skriptů nejčastěji pak v souvislosti s operací zálohování. 3 Závěr a opatrný pohled do budoucnosti Hlavním účelem tohoto příspěvku bylo seznámit čtenáře s trendy, které v poslední době zřetelně působí na zákazníky v oblasti performance management. Řešení IBM Netezza je jen reakcí na tento trend směřující k větší samostatnosti a flexibilitě jednotlivých business oddělení. V této souvislosti je potřeba zmínit i to, že i společnosti, jakými je např. Gartner konstatují, že klasický koncept budování obrovských datových skladů (enterprise data warehouse), který je založen na hezké myšlence mít všechna data společnosti na jednom místě, víceméně selhal. Nikdo totiž v době, kdy tento koncept vznikal, nemohl reálně dohlédnout, jaké budou jednak potřeby koncových business uživatelů a jednak, jaké typy dat budou dnešení pokročilé technologie schopny zpracovávat a jaké zajímavé informace z těchto dat mohou tyto pokročilé technologie získat pro potřeby businessu. Klasický obrovský datový sklad, který by na úrovni relační databáze udržoval (byť v jednotlivých logických vrstvách L0, L1, L2) celé informační bohatství organizací bude podle významných analytiků v blízké budoucnosti nahrazen konceptem tzv. logického datového skladu, který bude na centrální úrovni pouze spravovat centrální přístup k datům. Data jako taková ale fyzicky budou uložena v technologiích, které jsou optimální pro jejich efektivní zpracování. Koncový uživatel se pak pouze bude logického datového skladu ptát a nebude se starat o to, v které fyzické části logického datového skladu jsou konkrétní data, která uspokojí jeho informační potřebu, uložena. Na to, než se tento concept stane realitou si ale ještě budeme muset chvíli počkat. 38

42 Netezza to pravé řešení pro analytický datový sklad , Praha Martin Pavlík, IBM ČR Obr. 4 Architektura logického datového skladu 39

43 Informix Warehouse Accelerator , Praha Jan Musil, IBM ČR Informix Warehouse Accelerator Ing. Jan Musil IBM Česká republika V Parku 2294/4, Praha 4 jan_musil@cz.ibm.com Klíčová slova: Informix, relační databáze, datové sklady Abstrakt: Rodina databázových serverů IBM Informix se neprezentuje pouze jako rodina serverů pro transakční zpracování, ale má i významnou podporu pro analytické zpracování. Společně s verzí Informix 11.7 přichází s unikátní technologií Informix Warehouse Accelerator, která umožňuje zrychlit analytické operace sto až tisíci násobně. Tato technologie patří do skupiny tzv. databázových technologií třetí generace. 1 Úvod IBM Informix Dynamic Server je zákazníky z dlouhodobého hlediska považován za nejstabilnější, nejspolehlivější a nejrobustnější databázový server na trhu. To dokazuje například hodnocení nezávislé společnosti VendorRate, kdy celková spokojenost zákazníků s produktem je ve všech sledovaných oblastech hodnocena jako mimořádná. Procentuální vyjádření celkové spokojenosti je 93%. Společnost IBM jednoznačně deklaruje, že produktová řada IBM Informix je do budoucna technologicky i obchodně stabilní, a že každých 18 měsíců bude k dispozici nová hlavní verze produktu a každé tři měsíce vylepšená verze s takovými novými vlastnostmi, které jsou zákazníky aktuálně žádány. Již nyní známe produktovou řadu s výhledem minimálně na tři další plánované hlavní verze s rámcovým popisem nových vlastností. Již nyní tedy víme, jaké budou oblasti vylepšení a nové funkce verze plánované na rok 2017! Mimochodem, závazek, že každých 18 měsíců mohou Informix zákazníci očekávat novou hlavní verzi databázového serveru, byl dodržován od okamžiku, kdy došlo k akvizici společnosti. Jinak by pod křídly IBM nevznikly verze 9.3, 9.4, 10, 11.1, 11.5 a Jednou z oblastí, kde došlo k výraznému vylepšení funkcionality, je oblast zpracování analytických dotazů s použitím zcela nové komponenty Informix Warehouse Accelerator (IWA). IWA představuje moderní a vysoce výkonnou databázovou technologii 3. generace pro zpracování analytických dotazů. IWA využívá jak výhod ukládání dat v paměťové databázi, tak transformaci z ukládání dat podle řádků na ukládání podle položek a vedle paralelního zpracování používá speciální postupy pro binární kompresi dat tak, aby dotazy mohly být zpracovávány přímo v registrech počítače. Technologie je zcela transparentní pro existující aplikace bez nutnosti jejich jakýchkoliv modifikací, nevyžaduje žádné speciální ladění analytických dotazů a nevyžaduje žádný specializovaný HW, ani další specializované SW komponenty. Výhodami technologie je možnost současného provádění transakčních a analytických zpracování bez vzájemného ovlivňování výkonnosti, jednoduchá implementace a konfigurace prostředí akcelerátoru a z pohledu výkonnosti několikaset násobné zrychlení zpracování analytických dotazů ve srovnání s tradičním prostředím relačních databází. 2 Problém zpracování analytických dotazů Pokud pro provoz a správu dat datového skladu používáme relační databázové stroje, můžeme pro optimalizaci přístupu k zpracovávaným datům použít například partitioning tabulek, partitioning databází, můžeme maximalizovat paralelní zpracování jak na databázové úrovni, tak s použitím masivně paralelní HW architektury, můžeme přidělit maximum zdrojů databázového serveru a 40

44 Informix Warehouse Accelerator , Praha Jan Musil, IBM ČR podobně. I přes veškerou snahu však stále narážíme na omezení, která vedou k tomu, že analytické dotazy do datových skladů se zpracovávají dlouho, prakticky je nelze spustit současně s transakčním zpracováním na jednom serveru a v neposlední řadě je třeba stále tyto analytické dotazy optimalizovat tak, aby plán přístupu k datům byl, pokud možno, co nejefektivnější. Obecně lze říci, že databázové technologie tzv. druhé generace, které se používají v drtivé většině, a které ukládají data po jednotlivých záznamech a pro přístup k nim je potřeba velkého množství vstupně výstupních operací na disku, nejsou příliš vhodné pro analytické dotazy. Dle blogu Freda Ho ze společnosti IBM [1], který se odvolává na studii IDC [2], získávají stále více na aktuálnosti databáze třetí generace, kde si můžeme dovolit zapomenout na koncept diskového partitioningu, koncept různých indexovacích strategií a koncept buffer managementu, protože tyto nové systémy nám nabídnou zpracování analytických dotazů v paměťových databázích s vícejádrovými procesory a klastrovanými servery s vysoce komprimovanými daty uloženými na disku nikoliv po záznamech, ale po jednotlivých sloupcích. Nástup databázových technologií třetí generace lze podle stejné studie IDC [2] očekávat do pěti let. IDC odhaduje následující charakteristiky databázových technologií třetí generace. 1) Většina dat v datových skladech bude uložena po sloupečcích 2) Většina OLTP databází bude udržována částečně nebo zcela v paměti 3) Většina databázových serverů, které zpracovávají rozsáhlé databáze, budou škálovatelné horizontálně prostřednictvím klastrování 4) Většina problémů se sběren dat a jejich reportování bude řešena databázemi, které nemají již vůbec formalizované datové schéma 3 Praktická realizace databázové technologie třetí generace Praktickou realizaci konceptu databázových technologií třetí generace nabízí IBM pro své zákazníky, kteří provozují datové sklady na databázové platformě Informix. Rozhodnutí poskytnout stávajícím a budoucím IBM Informix zákazníkům technologii podporující rychlé zpracování analytických dotazů vyplývá také ze skutečnosti, že 40% současných Informix zákazníků provozuje aplikace datových skladů. Nová technologie databázové platformy třetí generace se jmenuje Informix Warehouse Accelerator (IWA) a jak je patrné již z názvu technologie, hlavním cílem je zrychlit stávající analytické dotazy, zpracovávané aktuálně na konvenční (druhogenerační) databázové platformě Informix. Vedle již zmíněné mimořádné výkonnosti, dle praktických zkušeností zákazníků se dotazy zrychlily sto až tisícinásobně (!), jsou dalšími výhodami plná transparentnost řešení ve vztahu k původní aplikaci, což znamená, že analytický dotaz se pošle původnímu databázovému serveru jako před tím, optimalizátor ovšem rozhodne, zda se dotaz bude zpracovávat lokálně (konvenčně) nebo se pošle akcelerátoru (viz. Obrázek č. 1). Pokud se dotaz zpracovává v akcelerátoru, pak požadovaná data jsou poslána zpět původnímu databázovému stroji a ten je zprostředkuje aplikaci. Z tohoto pohledu nejsou třeba naprosto žádné změny na straně aplikace, ani žádné rekonfigurace stávajícího databázového serveru. Další důležitou výhodou je oddělení transakčního zpracování od analytického mezi dva různé počítače, případně mezi dvě různé instance databázového serveru, pokud vše běží na jednom počítači o této alternativě lze ale uvažovat spíš v případě testovacího nebo demonstračního režimu. V neposlední řadě je třeba zmínit, že nová technologie nevyžaduje žádné speciální ladění, případně optimalizaci dotazů, vytváření indexů nebo distribučních statistik optimalizátoru. Podporovanými datovými schématy jsou hvězdice a sněhové vločky (tedy vzájemně svázané tabulky faktů a tabulky dimenzí). Akcelerovat, tedy přenést data a jejich strukturu z tradiční relační databáze do IWA lze buď pro celé schéma datového skladu, nebo jeho podmnožinu. Akcelerované schéma s daty na úrovni IWA se nazývá data mart. 41

45 Informix Warehouse Accelerator , Praha Jan Musil, IBM ČR Obr. 1: Architektura řešení Informix Warehouse Accelerator 4 Konfigurace a architektura řešení Konfigurace Informix Warehouse Acceleratoru (dále jen IWA) je velmi jednoduchá. Po nainstalování software na provozní platformu, kterou je 64bit Intel s operačním systémem Linux RHEL nebo SLES, se provede několik jednoduchých konfiguračních kroků. Konfigurace spočívá v určení diskové oblasti, kde budou uložena akcelerovaná data datového skladu, dále pak se určí počet uzlů tohoto databázového serveru třetí generace, paměť přidělená každému uzlu a na závěr způsob komunikace s původním databázovým serverem (vzdálená nebo lokální). Z pohledu procesů, v prostředí IWA běží pouze dva typy procesů (uzlů). Prvním typem jsou koordinační uzly, zodpovědné za komunikaci s relačním databázovým serverem, zpracování požadavků a koordinaci druhého typu uzlů, což jsou tzv. výkonné (pracovní) uzly. Koordinační uzly jsou také zodpovědné za administraci systému. Míra paralelizmu zpracování analytických dotazů je dána počtem výkonných uzlů. Výkonné uzly komunikují pouze s koordinačními uzly. Jak koordinačním uzlům, tak výkonným uzlům je přidělena sdílená paměť. Takto přidělená sdílená paměť by měla být tak velká, aby zde bylo možné načíst kompletní data potřebná pro analytický dotaz. Jak si vysvětlíme dále, tato data jsou komprimována vysoce účinným komprimačním algoritem. Dle doporučení, výkonným uzlům, které spravují veškerá data, potřebná pro analytický dotaz, je vhodné přidělit dvě třetiny celkové paměti počítače. Koordinačním procesům, které nevyžadují příliš paměti, lze přidělit 5 až 10% dostupné paměti. Při akceleraci dat potřebných pro analytický dotaz, jsou transformovaná data (způsob jejich transformace bude popsán později) rozdělena mezi jednotlivé výkonné uzly následujícím způsobem. Tabulka faktů, která je pochopitelně nejrozsáhlejší, je rovnoměrně rozdělena mezi všechny výkonné uzly, čímž je zajištěn paralelizmus zpracování dotazů na první úrovni. O další úrovni paralelismu budeme hovořit později. Vzhledem k tomu, že tabulky dimenzí neobsahují velký objem dat, každý uzel má k dispozici úplnou jejich kopii. Administrace a inicializace instance IWA se provádí prostřednictvím jednoduchého řádkového příkazu. Definici data martů a akceleraci dat lze provádět buď z prostředí grafického Smart Analytics Studia (ISAO), vytvořeného na platformě Eclipse nebo z příkazové řádky prostřednictvím vytvořených Java příkazů. Aby mohl být analytický dotaz akcelerován, musí být všechny tabulky, se kterými pracuje, součástí data martu, jehož data jsou transformovaná do IWA. Definici data martu 42

46 Informix Warehouse Accelerator , Praha Jan Musil, IBM ČR lze provádět manuálně z grafického nebo řádkového prostředí, ovšem po analýze toho, s jakými tabulkami analytický dotaz pracuje. Aby nebylo nutné provádět tuto analýzu manuálně, lze vytvořit strukturu data martu automaticky po automatické analýze SQL analytických dotazů. 5 Transformace dat Po vytvoření data martu, tedy struktury schématu, který je potřeba pro akcelerované analytické SQL dotazy, je třeba transformovat data z původní databáze do IWA. Data jsou při transformaci jednak převedena z řádkového ukládání do položkového, jednak komprimována pomocí Huffmanovo algoritmu do binárního tvaru. Jelikož se při analytických dotazech provádí agregace nad tabulkovými položkami, je výhodnější právě použít položkové ukládání dat, protože pro agregace potřebujeme co nejrychleji zpracovat co nejvíce hodnot jednotlivých položek. Při řádkovém ukládání dat je třeba načíst kromě potřebné hodnoty příslušné položky i ostatní nepotřebné hodnoty zbylého záznamu, což je pro analytické dotazy nevýhodné. Ukládání po záznamech je naopak výhodnější pro transakční zpracování, kdy potřebujeme zpracovat informaci uloženou v celém nebo v části jednotlivého záznamů. U binární komprese pomocí Huffmanova algoritmu je několik položek tabulky spojeno do buňky a tyto buňky jsou na základě frekvenční analýzy zakódovány binárními hodnotami. Čím je frekvence výskytu hodnot v buňce vyšší, tím kratší je binární hodnota, kterou jsou data buňky zakódovaná. Kódování do binárního tvaru umožňuje vysokou míru komprese dat, která je nutné pro uložení dat data martu do paměti počítače, kde běží IWA. Druhou výhodou binární komprese je skutečnost, že agregace a vyhodnocení podmínek analytického dotazu se provádí pomocí Single Instruction Multiple Data (SIMD) paralelismu přímo v registrech Intelové platformy, na které je IWA instalován. Intel Xeon platforma má 128bitové registry. Pokud má buňka kratší délku (což zaručuje extrémní komprese Huffmanovým algoritmem), pak lze paralelně jednou instrukcí zpracovat více záznamů najednou. Tím zajistíme paralelismus druhé úrovně. 6 Závěr První zásadní výhodou celého řešení je jednoduchá integrace do stávající databázové infrastruktury. Na straně původního databázového serveru není třeba provádět žádné změny v konfiguraci, veškerá konfigurace se provádí při implementaci IWA řešení. Další výhodou je, že není třeba cokoliv měnit ve stávající aplikaci. Aplikace stále komunikuje s původním databázovým serverem, jehož optimalizátor rozhodne, zda se bude dotaz akcelerovat, či nikoliv. Významnou implementační výhodou je skutečnost, že integrace IWA a jeho spuštění nijak neohrozí dostupnost dat. Pokud by z nějakého důvodu nebylo možné dotaz akcelerovat, provede se lokálně, jako dříve. Zákazníci se tedy nemusí obávat, že nasazováním řešení může dojít z nějakého důvodu k výpadku v dostupnosti dat. Zásadní výhodou je pak několikanásobné zrychlení provádění analytických dotazů. Máme k dispozici statistiky porovnání doby provedení analytického zpracování bez IWA a s IWA. Zpracování trvající od minut do desítek minut a i déle bez akcelerátoru, trvala několik sekund s akcelerátorem. Literatura [1] Fred Ho, Fred Ho's Blog, The 3rd Generation of Database Technology, IBM developerworks (ibm.com/developerworks), [2] Carl W. Olofson, The Third Generation of Database Technology: Vendors and Products That Are Shaking Up the Market, IDC, Feb 2010 [3] IBM Informix Warehouse Accelerator Administration Guide, Informix Product Library Version 11.70, IBM Corporation 2010,

47 Informix Warehouse Accelerator , Praha Jan Musil, IBM ČR Summary The document gives the overview of the most interesting technologies in version IBM Informix Informix Warehouse Accelerator (IWA) significantly improves the response time of the analytical queries. IWA is the implementation of the 3rd generation database technology defined by IDC. Analytical queries are speed up times. The architecture of the solution allows to store the data sequentially by column (columnar data stores) instead of row oriented data store. The technology uses a high efficient compression which transform data into binary form which allows SIMD (Single-Instruction, Multiple- Data) parallelism of the operations run directly in registers. The main advantages of the technology are the application transparency, simple configuration and administration, no tuning, no indexes, no statistics for optimizer and also using of the inexpensive HW. 44

48 Zpracování proudů dat o událostech v reálném čase , Praha Technologie a aplikační možnosti. Jiří Gregor, GALEOS, a.s. Zpracování proudů dat o událostech v reálném čase. Technologie a aplikační možnosti Ing. Jiří Gregor GALEOS, a.s. Michelská 300/60, Praha 4 Tel: info@galeos.cz www: Klíčová slova: Business Event Processing (BEP), Complex Event Processing (CEP), reálný čas, událost, jednoduchá událost, komplexní událost, významná událost, okamžitá reakce, řízení v reálném čase, Business Intelligence, Progress Apama, korelační enginy, řízení podle KPI (Key Performance Indicators) Abstrakt: Zpracování událostí v reálném čase (CEP Complex Event Processing) opouští zažité modely práce s informacemi, ve kterých je rozhodování založeno na datech z datových skladů nebo relačních databází. Zpracování totiž musí proběhnout tak rychle, že není možné ani žádoucí zdržovat se ukládáním dat. Cílem je zpracovat v co nejkratším čase obrovské množství dat z různých zdrojů, vyhledat mezi nimi souvislosti, porovnat je s připravenými scénáři a vydat doporučení nebo automaticky provést rozhodnutí. Technologie CEP nacházejí uplatnění všude tam, kde je rychlost naprosto kritickým parametrem, například v algoritmickém obchodování na kapitálových trzích, v telekomunikacích, telematice nebo v bankovnictví. 1 Úvod Technologie CEP (Complex Event Processing) umožňují sledovat různě komplexní události již v okamžiku, kdy události nebo data o nich vznikají, a reagovat na ně. Nabízí obdobnou schopnost společného zpracování a vyhodnocování dat z různých zdrojů, jakou nabízí business intelligence, liší se však rychlostí. To je dáno tím, že není zapotřebí čekat na uložení dat. Události jsou identifikovány přímo v jejich proudu. Pro každou nebo téměř každou organizaci platí, že v ní i kolem ní téměř neustále probíhají události, které ovlivňují kvalitu služeb, dodávku produktů, spokojenost zákazníků, úroveň prodejů, náklady nebo jiný významný parametr. Schopnost zjišťovat tyto události a okamžitě na ně reagovat znamená významnou konkurenční výhodu. K tomu slouží technologie označované jako Business Event Processing (BEP) či Complex Event Processing (CEP). Používání těchto pojmů se v praxi překrývá. V následujícím textu dáváme přednost výrazu CEP. 2 Jednoduché, komplexní a významné události Pro účely tohoto textu budeme rozlišovat tři základní typy událostí. Za jednoduchou událost můžeme pokládat například: aktivaci prvku v síti, 45

49 Zpracování proudů dat o událostech v reálném čase , Praha Technologie a aplikační možnosti. Jiří Gregor, GALEOS, a.s. změnu ceny na burze, příchozí volání, žádost o provedení platby, změnu GPS souřadnic, uložení předmětu na určité místo zaznamenané RFID čipem, změna stavu stroje (zapnutí, vypnutí apod.), signál změny stavu zaslaný senzorem (který měří teplotu, rychlost, pohyb atd.) Některé takové jednoduché události jsou zajímavé a důležité i samy o sobě. Častěji se ale jejich skutečný dopad ukazuje až v souvislostech. Proto je lze považovat za stavební bloky pro budování komplexních událostí. Takovými komplexními událostmi jsou například: zadání většího počtu objednávek ve velmi krátkém čase, přičemž tento počet objednávek převyšuje kapacitu střediska, všechny prvky sítě, které jsou potřebné pro poskytnutí určité služby, mají momentálně volnou kapacitu, přílet letadla se všemi nároky na odbavení cestujících, servis, doplnění paliva, zásob atd., které z toho vyplývají. Tyto komplexní události se většinou skládají z jednoduchých událostí třemi různými způsoby: spojení jednoduchých událostí podle času a místa. Takovou komplexní událostí mohou být například výběry z bankomatů stejnou kartou, které jsou od sebe vzdáleny více než 10 km, přičemž čas mezi výběry je kratší než 5 minut; spojení na základě kvantity, například spojení jednoduchých událostí, jejichž součet překračuje stanovenou mez (například celková požadovaná částka, celkové nároky na kapacitu apod.) sled událostí (nastane událost A, do 15 minut nastane některá z událostí B nebo C a v dalších dvou minutách neproběhne událost D) Za významnou událost označujeme takovou komplexní událost, která vyžaduje okamžitou reakci. To znamená, že každá z výše popsaných komplexních událostí může označena jako významná událost, pokud jsou spojeny některé další podmínky. Například: to, že kapacita střediska neumožňuje vyřídit všechny objednávky ve stanoveném čase se stává významnou událostí po zjištění, že dvě z těchto objednávek přicházejí od VIP zákazníků; skutečnost, že všechny potřebné prvky sítě mají dostatečnou volnou kapacitu pro poskytnutí určité služby, je významnou událostí, pokud lze z profilu zákazníka usuzovat, že by měl o službu zájem; zjištění, že pokud má letadlo odletět podle jízdního řádu, musí být doplňování paliva zahájeno do 90 minut, což kapacita tankovacích zařízení neumožňuje. Okamžitou reakci může vyžadovat i jednoduchá událost (například aktivace čidla, která znamená nepovolené vniknutí do objektu). Tyto jednoduché události však jsou většinou ošetřeny v rámci jednoho specializovaného informačního systému a nevyžadují podporu CEP. 46

50 Zpracování proudů dat o událostech v reálném čase , Praha Technologie a aplikační možnosti. Jiří Gregor, GALEOS, a.s. Významné události se odehrávají bez ohledu na informační technologie. Informační technologie ale mohou přinést schopnost včas je identifikovat a okamžitě na ně reagovat. Měřítka toho, jakou rychlost reakce lze pokládat za dostatečnou, se liší podle oboru. Někdy stačí hodiny nebo dokonce dny, při koordinaci kapacit to mohou být minuty, při obraně proti podvodům se může jednat o sekundy nebo zlomky sekund. 3 CEP versus Business Intelligence Ke zpracování dat z různých zdrojů slouží již tradičně nástroje Business Intelligence (BI). Umožňují vidět souvislosti a přijímat správná rozhodnutí. Mnohdy to jsou sofistikované a výkonné nástroje, ale není v jejich možnostech zajistit potřebnou rychlost. Mohou tedy kupříkladu poskytnout cenné informace o tom, že v určité fázi procesu pravidelně vznikají zdržení nebo výpadky, ale nedokážou vyvolat akci ve chvíli, kdy se tak děje. Jsou velmi vhodné pro vytváření výkazů, hodnocení různých činností nebo vystavování faktur, jejich použitelnost pro okamžité řízení je omezená. To je dáno i tím, že data jsou do datových skladů přenášena zpravidla dávkově (například jednou denně), aby nebyla zpomalena činnost provozních informačních systémů. Technologie CEP jsou oproti tomu vhodné tam, kde je zapotřebí reagovat v reálném čase nebo v řádu minut. To lze nejlépe ukázat na již zmíněných situacích. - BI ukáže, že určité středisko pravidelně bývá v určité denní doby přetížené a že během takových přetížení zákazníci čekají na vyřízení svého požadavku příliš dlouho. Často umožní i zjistit, jaké jsou finanční dopady takového přetížení: kolik zákazníků není ochotno čekat, o kolik zakázek firma přichází a jaký to má dopad na spokojenost zákazníků. CEP oproti tomu upozorní, že momentálně hrozí, že významný zákazník nebude obsloužen, a nápravné opatření tudíž musí být podniknuto během několika vteřin. - BI poskytne informaci, že kapacita telekomunikační sítě je v určitých denních dobách dostatečná pro poskytnutí dalších služeb a kteří zákazníci zpravidla mají o takové služby zájem. To může být užitečné například při sestavování nových tarifů. CEP oproti tomu upozorní, že právě teď je správný čas nabídnout konkrétnímu zákazníkovi službu všechny prvky sítě mají dostatek volné kapacity a zákazník s vysokou pravděpodobností nabídku uvítá. - BI umožní vidět, že kapacita tankovacích zařízení není racionálně využívána. CEP upozorní na nutnost provést, okamžitou změnu v harmonogramu, jinak letadlo neodletí včas. CEP je tedy technologie užitečná a často nutná tam, kde je okno příležitosti časově omezené, a kde je zapotřebí reagovat okamžitě. A takových situací ve většině oborů přibývá. Stačí připomenout, že ještě v relativně nedávných dobách stačilo makléřům na burzách reagovat na změnu ceny v řádu minut, takže byli schopni situaci konzultovat s kolegou nebo nadřízeným. Dnes rozhodují milisekundy. A nejde zdaleka jen o burzy. Například cross-selling (prodej dalších služeb stávajícím zákazníkům) v telekomunikacích, finančních službách, prodeji na internetu nebo jejich kombinaci. S doplňující nabídkou je často zapotřebí přijít během několika vteřin nebo nejvýše minut, potom příležitost končí. K tak rychlé reakci je zapotřebí vyhodnotit data o zákazníkovi, o produktech, o momentální kapacitě a o tarifu, který zákazník využívá. Podobně je tomu s obranou proti podvodům. Rozhodnutí o tom, zda transakci povolit nebo zablokovat, musí být učiněno nejvýše během několika vteřin. Nejde jen o řešení jednotlivých případů. Mnoho organizací je řízeno podle KPI nebo jiných ukazatelů, a nástroje BEP umožňují zahrnovat do jejich kalkulací i ty události, které právě probíhají. Manažer může skutečně on-line sledovat, jak se mění vytížení kapacit a co to znamená pro finanční ukazatele. Může sledovat reakci na reklamní kampaň i s dopady pro návratnost investice do reklamy a budoucí požadavky na kapacitu. Pochopitelně v přehledné grafice. 47

51 Zpracování proudů dat o událostech v reálném čase , Praha Technologie a aplikační možnosti. Jiří Gregor, GALEOS, a.s. CEP proto doplňuje schopnosti BI všude tam, kde záleží na čase reakce, tedy v procesech operativního (dispečerského) řízení, kterým poskytuje tzv. průběžnou inteligenci (není oreintovaná na zpracování v dávkách, ale je řízena událostmi). 4 IT architektura pro zpracování událostí V další části ukážeme základní prvky architektury BEP řešení: Korelační enginy. Jedná se o nástroje pro vyhledávání souvislostí v obrovských objemech dat s obrovským výkonem. Mohou jimi protékat v podstatě neomezené objemy dat z různých zdrojů (například telekomunikační síť a informační systémy operátora). Korelační enginy je filtrují, tedy třídí ta data, která jsou relevantní pro posuzovanou událost a hledají v nich scénáře, jichž dokážou posoudit tisíce v řádu milisekund. Korelační engine pracuje ve vnitřní paměti a nevyžaduje pro svoje fungování žádnou vnější databázi. O práci korelačního stroje řekneme více během přednášky. S korelačními enginy jsou dodávány také řídící nástroje, které umožňují nasadit a řídit více korelačních enginů zároveň. To lze ilustrovat na produktu Progress Apama Correlator, který pracuje s patentovanou technologií HyperTree. Tato technologie nerealizuje procesní kroky v sekvenčním pořadí, jak je tomu v tradičních počítačových programech. Monitoring, analýza a vyvolání akce jsou pojaty jako nezávislé, byť logicky propojené, segmenty. Kromě toho je systém schopen paralelně sledovat statisíce instancí scénářů (proběhla událost A a nyní se čeká, zda v určitém časovém limitu bude následovat událost B). Obr. 1 Schéma vnitřní struktury Apama Event Correlator Prostředí pro vytváření aplikací. CEP poskytuje jazyk a kompletní prostředí pro vývoj událostních aplikací. IT specialista tedy pracuje v jednoduchém skriptovacím jazyce ne nepodobném javě. Zadává de facto popis konečného automatu, který obsahuje: - jednoduché události, které události mají být sledovány, - scénáře sestavené z těchto událostí (komplexní události), - další pravidla, výpočty KPI apod. 48

52 Zpracování proudů dat o událostech v reálném čase , Praha Technologie a aplikační možnosti. Jiří Gregor, GALEOS, a.s. Obr. 2 Zjednodušená ukázka událostní aplikace vytvářené v rámci CEP. V tomto případě se jedná o algoritmické obchodování. Ten, kdo událostní aplikace vytváří, určuje rovněž, jak budou události zobrazovány uživatelům (manažerům a dispečerům). Kromě toho může vytvářet tzv. smart bloky, a umožnit tak pokročilejším uživatelům, aby spojováním, případně parametrizací těchto bloků zadávali vlastní požadavky na scénáře. Dispečerské rozhraní (dashboard pro vizualizaci dění v reálném čase) ukazuje v přehledné grafice momentální dění, včetně dopadů událostí na různé ukazatele, a případně upozorňuje na nutnost okamžitě reagovat. Některé CEP produkty umožňují, aby určité scénáře (požadavek na sledování sledu událostí spojených se splněním určitých podmínek) zadávali i sami koncoví uživatelé bez podpory IT experta, jak je i zmíněno v předcházejícím odstavci. 49

53 Zpracování proudů dat o událostech v reálném čase , Praha Technologie a aplikační možnosti. Jiří Gregor, GALEOS, a.s. Obr. 3 Příklad uživatelského rozhranní (obrana trhu) Simulační nástroje. Jak vyplývá z názvu, umožňují tyto nástroje přehrávat události, které se odehrály v minulosti, případně zjišťovat, jaký dopady by měly různé varianty událostí, které teprve mohou nastat. Použití těchto nástrojů (testování scénářů) často vyžaduje i forenzní audit. Zajímavé je, že tyto nástroje většinou předpokládají využití nějaké velmi výkonné databáze. Do této databáze je možné data opatřená časovými razítky uložit a odsud je pak přehrávat podle času vyznačeného na razítkách, což v zásadě simuluje tok událostí, jako by přicházel z originálních zdrojů. Adaptéry (integrační vrstva) přebírají data z nejrůznějších zdrojů: systémů, aplikací, technologických zařízení, telekomunikačních sítí, vnějších poskytovatelů apod. Samozřejmým požadavkem je, aby adaptéry byly schopny přebírat data z jakéhokoliv prostředí, kde tato data vznikají. Tedy z informačních systémů, ale také různých řídících systémů, technických zařízení, mediačních zařízení telekomunikačních sítí apod. Komerční systémy CEP obsahují řadu takových připravených adaptérů i vývojové prostředí umožňující vytvářet další. Kromě přebírání momentálně vznikajících dat musí CEP zajistit tzv. data enrichment, tedy doplnit tato data o další informace uložené v databázích vnitropodnikových systémů resp. konvenčních aplikací. Kombinace událostí, z níž vyplývá, že určitá služba nebude poskytnuta včas, dostává kupříkladu jiný význam ve světle zjištění, že se jedná o VIP zákazníka. Jindy je zapotřebí zkontrolovat stav účtu, zjistit zbývající kredit apod. Toto doplňování údajů může být kritickým bodem CEP, protože je do značné míry závislé na rychlosti a kapacitě jiných (non real time) databází. Je zřejmé, že se jedná o složité a náročné systémy. Tím je dáno, že počet dodavatelů CEP je poměrně úzký. Forrester Research považuje za dva absolutně nejlepší produkty Progress Apama a Sybase Aleri Event Stream Processor, do sektoru leaders pak řadí ještě IBM, StreamBase a Tibco. Co se týče kapacity, integračních schopností a dalších vyloženě technologických rysů, je možné konstatovat, že všechny tyto nástroje splňují nároky i těch největších nasazení. Sada produktů Progress Apama, kterou implementuje společnost Galeos, má dominantní postavení na burzách (algoritmické obchodování i dohled nad děním na trzích). Je také často využívána 50

54 Zpracování proudů dat o událostech v reálném čase , Praha Technologie a aplikační možnosti. Jiří Gregor, GALEOS, a.s. v telekomunikacích, logistice, průmyslu (a všude, kde se pracuje s RFID) i finančních službách (především ochrana proti podvodným transakcím). Za její hlavní konkurenční výhodu bývá označována uživatelská přívětivost, možnost velmi snadno přizpůsobit manažerské rozhraní konkrétním uživatelům a poměrně unikátní možnosti přehrávání historických událostí a scénářů. Obr. 4 Architektura CEP řešení Progress Apama 5 Aplikace CEP v praxi V rámci přednášky zmíníme některé praktické zkušenosti z využití CEP aplikací tam, kde se Galeos podílel na implementaci. Zde uvedeme jen jejich velmi stručný popis: 1. Monitoring konvergovaných bilingových procesů velkého mobilního operátora (účtování různých typů služeb konzumovaných stejným zákazníkem). CEP aplikace byla použita jako nástroj pro odhalení výkonnostních problémů některých aplikací, které klasické monitorovací systémy nebyly schopné identifikovat. Během implementace tak postupně vznikal nástroj pro monitorování a řízení interních SLA (Servis Level Agreement). 2. U dalšího mobilního operátora s více než 10 miliony zákazníky jsme nasadili CEP pro řízení marketingových kampaní v reálném čase. 3. Ochrana před zneužitím platebních karet. Využití CEP lze nejlépe ilustrovat typickým jednoduchým scénářem. Jestliže v proudu dat o platbách rozpoznáme několik plateb téže kartou v krátkém časovém rozmezí, ale různých lokalitách, jde o podezřelé transakce. Banka může 51

55 Zpracování proudů dat o událostech v reálném čase , Praha Technologie a aplikační možnosti. Jiří Gregor, GALEOS, a.s. okamžitě reagovat zvýšením dohledu, upozorněním dohlížitele nebo automaticky spustit ochrannou akci. Na závěr uvedeme několik dalších oblastí, kde jsou technologie CEP typicky využívány. 1. Algoritmické obchodování. Nástrojů pro automatizovaný prodej a nákup (v reálném čase) existuje celá řada. Zde máme na mysli jejich nejvýkonnější představitele používané v rámci aplikací označovaných jako high frequency- trading, někdy též low-latency trading. To je ostatně oblast, pro kterou byly CEP technologie původně vytvořeny a na které lze dobře ukázat, v jakém prostředí přináší CEP největší přidanou hodnotu. a) Trhy jsou extrémně konkurenční. I zpoždění v řádu milisekund znamená nevyužitou příležitost. Cena se již pohnula a konkurent již nakoupil za lepších podmínek. b) Existuje celá řada veřejných nebo komerčně dostupných proudů dat. Burzy, clearingová centra a další organizace je zveřejňují 24 hodin denně, často v sekundových intervalech. O objemu disponibilních dat si lze udělat představu i podle objemu peněz, které se za tato data na trhu zaplatí (v desítkách miliard USD ročně). Úspěšné strategie pak využívají kombinace krátkodobých (v extrému milisekundových) arbitráží nad cenami (z burz), disponibilními penězi (clearingová centra), informacemi (analytici), možným hedgingem (trh futures) a řadou dalších. 2. Obrana trhu. Je velkou výhodou, pokud regulátor dokáže rozpoznat nedovolené transakce již v okamžiku, kdy jsou prováděny. Umožní to okamžitou reakci. Kromě toho, dodatečné hledání problematické transakce v oddělených proudech dat představuje velmi obtížný úkol. Ovšem velikost a složitost trhu je obdobná, jako jsme uvedli v předcházejícím bodě. Kromě regulátorů využívají takto CEP i jednotliví hráči, kteří chtějí mít jistotu, že ve svém podnikání jsou v souladu s předpisy (compliance). 3. Společné zpracování dat z různých monitorovacích nástrojů a bezpečnostních zařízení (kamery, vstupní systémy, sensory apod.) umožňují identifikovat situaci či osobu a okamžitě reagovat. Zákazníky takových řešení mohou být jak bezpečnostní složky, tak provozovatelé velkých areálů s vysokou mírou rizika, organizace odpovědné za ochranu liniových staveb apod. 4. Telematika je další typickou oblastí, kde je zapotřebí zpracovávat velké množství dat v reálném čase. To nemusí zahrnovat jen klasické řízení provozu, ale také poskytování služeb, respektive jejich personalizovanou nabídku v závislosti na lokalitě. Včetně situací tak kuriózních, nicméně reálných, jako je rozpoznávání přátelských situací, kdy letecký dopravce využívá informace dostupné na sociálních sítích ke zlepšení nabídky klientům během cesty. V každém případě je možné konstatovat, že s tím, jak jsou organizace nuceny řešit stále komplexnější problémy, konkurence se zostřuje a regulátoři přicházejí se stále přísnějšími požadavky, přibývá také příležitostí pro CEP. Přibývá dokonce situací, které je bez CEP téměř nemožné uspokojivě vyřešit. 52

56 Zpracování proudů dat o událostech v reálném čase , Praha Technologie a aplikační možnosti. Jiří Gregor, GALEOS, a.s. Literatura [1] K Mani Chandy, W. Roy Schulte: Event processing. Designing IT systems for Agile Companies. McGraw Hill [2] Progress Software: White papers [3] The Forrester Wave: Complex Event Processing Platforms 53

57 Linked Open Data a jejich aplikace v praxi , Praha Martin Nečaský, Tomáš Knap, MFF UK Linked Open Data a jejich aplikace v praxi Martin Nečaský a Tomáš Knap Katedra softwarového inženýrství, Matematicko-fyzikální fakulta Univerzity Karlovy v Praze {necasky,knap}@ksi.mff.cuni.cz Klíčová slova: Linked Open Data, otevřená data, RDF Abstrakt: Linked Open Data je nový koncept pro práci s daty na webu. Vzniká tzv. web dat tj. web, který je tvořen provázanými a strojově čitelnými daty. V první části přednášky se posluchači dozví, co Linked Open Data jsou a uvidí reálná Linked Open Data, např. od vlády Velké Británie, medicínská Linked Data, atd. Ve druhé části jim budou představeny existující nástroje pro práci s Linked Open Data. V poslední části se potom seznámí s výsledky výzkumu týmu MFF UK v oblasti Linked Open Data i s jeho praktickými výstupy, např. s českými daty publikovanými dle těchto principů. 1 Úvod Představme si aplikaci, která srovnává rozpočty českých měst, obcí a krajů s celkovým součtem jejich veřejných zakázek přepočtených na jednoho obyvatele a sleduje, jak se součet mění v jednotlivých letech s měnící se politickou reprezentací. Nebo si představme jinou aplikaci, která ukazuje souvislost výše výdajů města či městské části na bezpečnost a prevenci kriminality s nahlášenými (a příp. vyřešenými) kriminálními případy. Aplikace bychom se mohli pokusit vytvořit, ale pravděpodobně to brzy vzdáme. Potřebujeme totiž získat potřebná data, převést je do jednotného formátu, vyčistit je a propojit. Tento proces také někdy označujeme angl. pojmem maching data. Jeho časové i finanční náklady jsou však dnes příliš vysoké. Důvodem je, že data často nejsou vůbec otevřeně zveřejňována a pokud jsou, tak v proprietárních formátech a vzájemně nepropojená. To má dvě hlavní příčiny [2]. První příčinou je přístup databázových správců, kteří chápou své databáze jako uzavřené systémy, do kterých jen velmi neradi pouštějí někoho jiného. Tento přístup má své kořeny již v 70. letech minulého století, kdy jen zkušení experti byli schopni s databází pracovat a pouze IT oddělení organizace vlastnící databázi bylo schopno pochopit strukturu a význam dat. To je však dnes již zastaralý přístup. V dnešním internetovém věku jsou miliony svobodných vývojářů schopni a připraveni vytvářet hodnotné aplikace využívající data z takových databází. Druhou příčinou je přístup současných vývojářů, který vede k tzv. uzamčení dat v aplikaci, která s daty pracuje (tj. vytváří je a/nebo je konzumuje). Informační architektura mnoha aplikací je totiž postavena tak, že metadata a datová schémata nejsou dobře separována od logiky aplikace. I když jsou občas zpřístupněna prostřednictvím API (např. webové nebo REST služby), dochází často ke změnám API s tím, jak se mění samotná aplikace. Navíc API se pro uživatele tváří jako samostatný datový ostrůvek nepropojený se souvisejícími datovými ostrůvky (např. data ve Wikipedii nebo specializovaných databázích). Propojení si musí uživatel vytvářet sám. To vše vede k obtížné využitelnosti dat mimo původní aplikace. Tento článek je stručným úvodem do světa tzv. Linked Open Data (zkr. LOD) [4]. LOD jsou data, která jsou publikovaná na webu v otevřené podobě spolu se svými metadaty a která jsou vzájemně propojována. Metadaty rozumíme schémata popisující strukturu a sémantiku dat, příp. i další data o datech, např. autora dat či datum publikace. Propojení mezi daty jsou také chápána jako data a jsou opět zveřejňována v otevřené podobě. Propojení může vytvářet nejenom autor samotných dat, ale i kdokoliv jiný. 54

58 Linked Open Data a jejich aplikace v praxi , Praha Martin Nečaský, Tomáš Knap, MFF UK Stručně ukážeme, že LOD umožní vytváření aplikací podobných těm zmíněným v úvodu. Položme si ale nejprve legitimní otázku: Proč by organizace měla svá data zveřejňovat? Pro formulaci kladné odpovědi uvažujme na chvíli dva typy dat: (a) data produkovaná veřejnou správou za peníze daňových poplatníků a (b) data produkovaná organizacemi či jednotlivci z vlastních zdrojů. U prvního typu dat by mělo být (až na osobní či jiné chráněné údaje) jejich zveřejnění a propojování samozřejmostí. U druhého typu už odpověď není tak jednoznačná. Na datech mnoho organizací zakládá svoji činnost a data jsou jejich konkurenční výhodou. Data jsou tedy pro ně samostatnou komoditou s vlastní hodnotou. A to právě může být důvod pro jejich (alespoň částečné) zveřejnění. Pokud jsou data zajímavá, bude mít jejich zveřejnění následující důsledky: Data budou využívána v jiných aplikacích, které se tak na datech stanou závislé. Navíc se k datům dostane více uživatelů. Data budou žít vlastním životem ostatní je budou čistit a propojovat na jiná související data, čímž podstatně zvýší jejich hodnotu. To mohou být jistě modely, přinášející organizaci zajímavou hodnotu. Zbytek článku je strukturován následujícím způsobem. V kapitole 2 představíme obecný koncept otevřených dat. V kapitole 3 se zaměříme na technologické principy LOD. V obou kapitolách budeme demonstrovat výhody otevřených dat a principů LOD na datech veřejné správy. V kapitole 4 pak ukážeme dva příklady využíti LOD v praxi. V poslední kapitole 5 potom představíme výzkumný projekt, v rámci kterého výzkumníci na MFF UK vyvíjejí nové nástroje pro práci s LOD. 2 Otevřená data Než se budeme věnovat konceptu LOD, představíme krátce současný stav ve světě otevřených dat (tj. nebudeme nejprve uvažovat písmeno L). I když svá data publikují otevřeně i organizace mimo veřejnou správu, my pojem otevřených dat vysvětlíme z pohledu veřejné správy, neboť právě pro ni jsou otevřená data důležitá především. Jako otevřená data můžeme označit data publikovaná na webu, která splňují následující kritéria: technická otevřenost, tj. data jsou zveřejněna ve standardním strojově čitelném formátu, legislativní otevřenost, tj. data jsou zveřejněna pod otevřenou licencí, dostupnost a původnost, tj. data jsou zveřejněna jako jeden celek a nezměněná (např. ne statistiky ale data, na základě kterých se dají statistiky spočítat), přehlednost, tj. data jsou snadno dohledatelná (např. jsou katalogizována v katalogu dat, který je možné prohledávat). Jako první se systematickým zveřejňováním dat v otevřené podobě začala zabývat vláda USA. V květnu roku 2009 zprovoznila katalog 1, který sdružuje odkazy na různá data publikovaná vládou USA v různých proprietárních (např. Excel či PDF) i standardizovaných (např. XML) formátech. Katalog záhy získal podporu prezidenta Obamy a stal se tak oficiálním národním katalogem dat. Prezident v prosinci téhož roku vydal direktivu, která nařizovala všem vládním institucím a agenturám identifikovat ve svých databázích alespoň tři datové sady a zařadit je do katalogu. Podobným směrem se vydaly další země ale i různé instituce 2, namátkou zmiňme např. Velkou Británii 3, Keňu 4 či Světovou banku

59 Linked Open Data a jejich aplikace v praxi , Praha Martin Nečaský, Tomáš Knap, MFF UK V současnosti je pro ČR asi nejinspirativnější zemí Rakousko. Zde začala v březnu roku 2011 působit pracovní skupina složená ze zástupců rakouské federální vlády a 4 měst včetně Vídně a Lince. Postupně její aktivity vedly k založení vládního katalogu dat a katalogů Vídně a Lince 6. Pracovní skupina se pravidelně schází a systematicky pracuje na mapování datových sad vlastněných zapojenými institucemi a jejich zveřejňování a katalogizaci. Zástupci pracovní skupiny v únoru 2012 navštívili i Českou republiku a v PSP ČR představili výsledky svojí práce zástupcům české veřejné správy 7. Proč ale státy, města a instituce ve světě začaly v uplynulém roce tak masivně podporovat myšlenku otevřených dat? 1. Otevřená data jsou důležitým a nedílným prvkem konceptu transparentní veřejné správy. 2. Odborná veřejnost získává podklady pro svobodnou vědeckou a výzkumnou činnost a je tak schopna daleko efektivněji vyvíjet tlak na racionálnější fungování veřejné správy. 3. Odborná veřejnost může svobodně vytvářet softwarové aplikace, které zpřístupňují data laické veřejnosti ve srozumitelné podobě. 4. Veřejná správa šetří prostředky, protože se může věnovat jen tvorbě strategicky důležitých a zákonem daných informačních systémů. Zbylé nechává na odborné veřejnosti, nevládních organizacích a iniciativách, atd. 5. Veřejná správa systematizuje sběr a zveřejňování dat. Lépe se odhalují zdroje duplicitních dat. Veřejná správa získává přehled o tom, kde jsou tvořena jaká data. To v důsledku vede k dalšímu šetření prostředků. I vláda České republiky začíná podnikat první oficiální kroky k otevření svých dat. V září roku 2011 se připojila k iniciativě vlády USA zvané Open Government Partnership (zkr. OGP) 8. V dubnu 2012 potom vláda schválila akční plán OGP pro Českou republiku 9 [3], ve kterém se k březnu roku 2012 zavazuje vytvořit český katalog otevřených dat a zabudovat do legislativy pravidla vedoucí k uveřejňování dat veřejné správy v katalogu. Dále se zavazuje k otevření těch nejdůležitějších databází, jako je např. Obchodní rejstřík či výsledky voleb. Prototyp katalogu buduje iniciativa OpenData.cz a je dostupný na adrese Je však nutné podotknout, že mnoho dat a informací veřejná správa již poskytuje. Např. obchodní rejstřík je alespoň částečně dostupný ve strojově čitelné podobě (formát XML) prostřednictvím systému ARES Ministerstva financí. Podobně rozpočty měst, krajů a dalších institucí jsou dostupné prostřednictvím systému ÚFIS opět spravovaného Ministerstvem financí. Způsob zveřejňování má však několik nedostatků, především nedodržuje principy legislativní otevřenosti, dostupnosti a přehlednosti. Z technologického pohledu je také problémem, že data nejsou identifikovatelná a vzájemné propojená. To už jsou ale hlavní principy LOD, které probereme v následující kapitole. 3 Linked Open Data Jak uvádějí autoři [2], myšlenka současného webu, tj. zveřejňování dokumentů v podobě webových stránek vzájemně propojených hypertextovými odkazy, je dnes zřejmá a nikdo se nad ní nepozastaví. V době svého zrodu v 90. letech minulého století to však byla zcela nová myšlenka, kterou ne každý přijímal a jejíž dopady v té době nedokázal nikdo odhadnout. Současný web můžeme označit pojmem web dokumentů. 6 Vídeň: Linz: (založen 4. října 2011) Autoři tohoto článku se přímo podíleli na znění akčního plánu v oblasti zpřístupňování dat a informací. 56

60 Linked Open Data a jejich aplikace v praxi , Praha Martin Nečaský, Tomáš Knap, MFF UK Principy Linked Open Data (LOD) mají za cíl rozšířit web dokumentů o tzv. web dat. Jsou dnes přijímány podobně, jako byla na počátku přijímána myšlenka webu dokumentů. Většina organizací nerozumí myšlence publikování dat v otevřené podobě, nemluvě o jejich propojování. Propojování je přitom klíčové pro plné využití potenciálu otevřených dat. Propojení dat znamená zasadit publikovaná data do kontextu jiných souvisejících dat. Nejenže usnadňuje vyhledávání v datech, ale především zvyšuje jejich hodnotu tím, že je obohacuje o kontext, tj. související data. Propojená data jsou tak nejvyšším kvalitativním stupněm uveřejnění dat. Není však reálné dosáhnout jej v jednom kroku. Existuje řada předstupňů, které dobře shrnul sir Tim Berners-Lee ve svém projevu na Gov 2.0 Expo 2010, Washington DC, v podobě dnes již proslulého (alespoň v LOD komunitě) 5-ti hvězdičkového modelu. Dobře vystihuje cestu od otevřených k propojeným datům: Data jsou dostupná na webu (v libovolném formátu) pod otevřenou licencí. Data jsou dostupná ve strukturované podobě (např. tabulka v Excelu místo obrázku s naskenovanou tabulkou). Je použit neproprietární datový formát (např. CSV místo Excelu). Entity, o kterých jsou zveřejňována data, mají přiřazeny jednoznačné identifikátory v podobě URI, takže jsou na webu identifikovatelné a možné na ně ukazovat. Data jsou vzájemně propojená. Principy LOD jsou sadou technologických principů (nebo můžeme také říkat doporučení či angl. best practices ) pro 5-ti hvězdičkové publikování a propojování strukturovaných dat na webu. Principy zavedl opět Tím Berners-Lee [4] a jsou následující: 1. Používejte URI jako jedinečná pojmenování entit, o kterých publikujete data. 2. Používejte HTTP URI, aby lidé mohli přistupovat k reprezentacím vašich entit prostřednictvím prohlížeče či jiné klientské aplikace. 3. Když někdo přistupuje k URI, zašlete mu data reprezentovaná ve formátu RDF. Místo jednoduchého zaslání dat můžete nabídnout i službu pro dotazování nad RDF daty pomocí jazyka SPARQL. 4. K vašim entitám doplňte také vazby na URI související entity ve vaší vlastní datové sadě i v jiných datových sadách. Pokud jsou data publikovaná dle výše uvedených principů, můžeme je označit jako LOD. Již dnes můžeme najít na webu mnoho zdrojů, které zveřejňují data jako LOD. Data z různých zdrojů jsou vzájemně provázána. Výše zmiňovaná myšlenka webu dat se tak již stala realitou. Podobu webu dat k září 2011 ukazuje obrázek 1 (zdroj: Zobrazená síť je také někdy nazývána LOD cloud. 57

61 Linked Open Data a jejich aplikace v praxi , Praha Martin Nečaský, Tomáš Knap, MFF UK Obrázek 1: Současná podoba webu dat (tzv. LOD cloud) Demonstrujme si principy na příkladu českých veřejných zakázek. Na MFF UK probíhá projekt, který převádí data o veřejných zakázkách do LOD podoby. Uvažujme např. město Semily. V datové sadě MFF UK má následující HTTP URI: Můžete vyzkoušet přistoupit k URI z klientské aplikace, např. z webového prohlížeče. Zjistíte, že URI je tzv. dereferencovatelné URI, tj. po přístupu server vrací RDF data o entitě identifikované uvedeným URI. Pokud klient využívá mechanismu content negotiation, server zajistí navrácení RDF dat v požadované reprezentaci. Klient tak může místo přímé RDF reprezentace požádat např. o HTML reprezentaci čitelnou pro uživatele. To nastává právě v případě, kdy přistoupíte z webového prohlížeče. Ukázku výsledku znázorňuje obrázek 2. 58

62 Linked Open Data a jejich aplikace v praxi , Praha Martin Nečaský, Tomáš Knap, MFF UK Obrázek 2: Data Semilech v datové sadě MFF UK Formát RDF je poměrně jednoduchý formát reprezentující data o entitě pomocí trojic v následující podobě: subjekt predikát objekt. Jedna trojice specifikuje jednu hodnotu jedné vlastnosti entity. Subjektem je URI entity. Predikátem je specifikace vlastnosti. Objektem je potom hodnota vlastnosti. Hodnota může být jednoduchá (tj. dále nestrukturovaná). Hodnotou ale může být i URI jiné entity. Potom se jedná o vazbu mezi dvěma entitami. V RDF má každá vlastnost, např. název organizace, vždy přiřazeno jedinečné pojmenování ve formě URI, podobně jako je tomu u entit. Toto URI je potom používáno pro specifikaci vlastnosti v predikátu trojice přiřazující hodnotu vlastnosti entitě. Např. datová sada MFF UK přiřazuje vlastnosti název organizace HTTP URI a vlastnosti zadavatel veřejné zakázky HTTP URI V našem konkrétním příkladu s městem Semily potom část RDF reprezentace přiřazující městu jeho název a vypsané veřejné zakázky tvoří následující trojice: < gr:legalname "Město Semily". < pc:contractingauthority < < pc:contractingauthority < < pc:contractingauthority < 59

63 Linked Open Data a jejich aplikace v praxi , Praha Martin Nečaský, Tomáš Knap, MFF UK Poznamenejme, že existuje řada notací pro zápis dat reprezentovaných v podobě RDF. Existuje např. notace pro zápis v jazyce XML. Nejkompaktnější a pro člověka nepřehlednější je potom notace Turtle. Výše uvedený příklad RDF trojic je právě zápis v notaci Turtle. Všimněme si, že predikáty jsou ve tvaru gr:legalname a pc:contractingauthority. Jedná se o standardní zápis URI zkrácený pomocí mechanismu prefixů přiřazených jmenným prostorům. Prefix gr: tak zastupuje jmenný prostor s URI a prefix pc: pak jmenný prostor s URI Poslední tři uvedené trojice s predikátem pc:contractingauthority přiřazují zadavatele k veřejným zakázkám. Tvoří tedy vazby mezi různými entitami. Jedná se o vazby v rámci dat v jedné doméně (opendata.cz). Obecně je ale samozřejmě možné vytvářet vazby mezi entitami z různých domén. Vazby umožňují navigaci mezi entitami. Ze Semil se tak můžeme přímo v prohlížeči navigovat na konkrétní veřejnou zakázku Semil. Jednu z nich ukazuje obrázek 3. Obrázek 3: Data o vybrané semilské veřejné zakázce A z detailu veřejné zakázky je potom možné přejít na smluvní cenu za zakázku dohodnutou s dodavatelem ve smlouvě, jak ukazuje obrázek 4. Cena totiž ještě nemá jednoduchou hodnotu. Jedná se o entitu strukturovanou na částku, měnu atd. 60

64 Linked Open Data a jejich aplikace v praxi , Praha Martin Nečaský, Tomáš Knap, MFF UK Obrázek 4: Smluvní cena semilské veřejné zakázky Je tedy zřejmé, že RDF umožňuje publikovat data webu včetně propojení mezi daty i z různých datových sad publikovaných různými organizacemi. Umožňuje tedy budovat výše zmiňovaný web dat. Základním využitím webu dat je jeho procházení. Má však i pokročilejší využití a to v podobě standardizovaného dotazovacího prostředku nad RDF daty jazyka SPARQL. Můžeme si tak propojená data, která nás zajímají, uložit do svého úložiště (angl. označujeme úložiště RDF dat pojmem triple store ) a nad daty se dotazovat pomocí jazyka SPARQL. Většina zdrojů publikujících RDF data nabízí webovou službu pro dotazování pomocí jazyka SPARQL, tzv. SPARQL endpoint. V tomto příspěvku nemáme prostor pro detailnější popis jazyka SPARQL. Uveďme jen, že jeho logika je podobná jazyku SQL s tím rozdílem, že ve WHERE podmínkách je specifikován tzv. grafový vzor, jehož výskyty jsou potom vyhledávány v datech. Pro aktivního čtenáře uvádíme bez dalšího vysvětlení zajímavý dotaz na zajímavého dodavatele IT služeb do společnosti Lesy ČR, s.p. Dotaz lze spustit nad daty MFF UK prostřednictvím nabízeného SPARQL endpoint 10. PREFIX rdf: < PREFIX rdfs: < PREFIX vcard: < PREFIX gps: < PREFIX pc: < PREFIX dc: < PREFIX gr: < PREFIX br: < SELECT DISTINCT?name?orgName?contractTitle?priceval?mainObject WHERE {?supplier br:officialnumber " ".?supplier gr:legalname?name.?tender pc:supplier?supplier.?tender pc:offeredprice?a.?a gr:hascurrencyvalue?priceval.?contract pc:awardedtender?tender.?contract dc:title?contracttitle.?contract pc:contractingauthority?org.?contract pc:mainobject?mainobject

65 Linked Open Data a jejich aplikace v praxi , Praha Martin Nečaský, Tomáš Knap, MFF UK?org gr:legalname?orgname. } ORDER BY?orgName?priceval Při zpracování dat z více zdrojů dojde k situaci, kdy oba datové zdroje používají pro vlastnosti se stejnou nebo podobnou sémantikou různá pojmenování, tj. různá URI. To samozřejmě vede k nemožnosti strojového zpracování pokud např. SPARQL dotaz očekává určité URI pro vybranou vlastnost (např. jméno osoby) a pracuje nad zdrojem, který pro tuto vlastnost používá jiné URI, pak nebude fungovat. Pro tyto účely jsou využívány mechanismy známé ze světa ontologií. Je např. možné specifikovat, že dvě různá URI reprezentují tu samou vlastnost, tj. že mají stejnou sémantiku. Nebo můžeme specifikovat, že jedno URI reprezentuje vlastnost, která je specializací vlastnosti reprezentované jiným URI. Tyto vztahy mezi různými URI umožňují řešit výše uvedené problémy. Specifikace vztahů je součástí tzv. ontologie, což je (zjednodušeně řečeno) datové schéma doplněné o specifikaci sémantiky vzhledem k jiným ontologiím právě pomocí vazeb tohoto typu. Specifikace je vyjádřena pomocí jazyka pro popis ontologií. Pro LOD je používán standardní jazyk OWL [6]. V tomto článku se však touto problematikou nebudeme detailněji zabývat. Ukažme si pouze příklad možného využití. Pro publikaci dat o veřejných zakázkách existují dvě různé ontologie: LOTED (Linked Open TED, pro její jmenný prostor použijme prefix loted:) a PCO (Public Contracts Ontology, pro její jmenný prostor použijme prefix pc:) 11. První vychází ze struktury dat o veřejných zakázkách, které zveřejňuje ve strojově čitelné podobě EU portál TED (Tenders Electronic Daily) 12. Druhou vyvíjí iniciativa OpenData.cz pro účely porovnávání veřejných zakázek a párování zakázek a dodavatelů. Obě ontologie se na úrovni sémantiky částečně překrývají. Např. obě ontologie zavádějí vlastní pojmenování pro datum publikace výzvy pro podávání nabídek k veřejné zakázce (HTTP URI pc:publicationdate vs. loted:pd) a termín pro podání nabídek (HTTP URI pc:tenderdeadline vs. loted:dt). Je zřejmé, že pokud spojíme data o veřejných zakázkách ze dvou zdrojů, přičemž jeden reprezentuje svá data dle LOTED, zatímco druhý dle PCO, nebude software zpracovávající data oběma rozumět. Vlastnosti definované v PCO jsou však explicitně navázány na ekvivalentní vlastnosti definované v LOTED pomocí ontologických prostředků. Software, který umí pracovat s PCO vlastnostmi a využívá ontologických prostředků, potom umí automaticky pracovat i s LOTED vlastnostmi (a naopak). Výzkumný tým na MFF UK 13 pracuje na postupném převádění vybraných dat veřejné správy do podoby LOD tak, aby v blízké budoucnosti mohl veřejné správě demonstrovat výhody LOD principů. Pro tyto účely vyvíjí studenti a výzkumníci na MFF UK portfolio nástrojů pro práci s LOD. Nástrojům je věnována kapitola 5 tohoto článku. 4 Příklady využití LOD ve světě Před tím, než se budeme věnovat nástrojům vyvíjeným na MFF UK, se podívejme na několik příkladů ze světa, které demonstrují možnosti praktického využití principů LOD. Ukážeme, že LOD není jenom koncept vhodný pro veřejnou správu, ale může z něj profitovat i soukromá sféra. Příklady jsou přejaty z [2]. 4.1 Profily států na portálu reegle.info Reegle je populární informační portál na poli obnovitelné energie a energetických úspor s více než návštěvníky měsíčně. Portál integruje data publikovaná v podobě LOD z mnoha externích

66 Linked Open Data a jejich aplikace v praxi , Praha Martin Nečaský, Tomáš Knap, MFF UK zdrojů (např. data OSN, světové banky, DBPedia.org či Eurostatu) a nabízí je prostřednictvím 243 individuálních profilů jednotlivých států. Část svých dat dále zveřejňuje v podobě LOD. Portál Reegle uvádí, že hlavním benefitem využívání a poskytování dat v podobě LOD je, že umožňuje relativně malému týmu lidí udržovat rozsáhlou databázi různých typů informací týkajících se energetiky. Místo neustálého sledování změn a jejich zaznamenávání v databázi je databáze portálu přímo navázaná dle LOD principů na externí zdroje. Přidaná hodnota portálu je právě toto provázání, nikoliv data ze samotných zdrojů. Reegle navíc využívá svého know-how k odvozování nových dat. Vazby a nová data publikuje jako LOD. Nabízí tak vývojářům možnost jednoduše přistoupit k datům jak samotného portálu Reegle tak z externích zdrojů na jednom místě. To zajišťuje potřebné šíření dat nejenom prostřednictvím portálu ale i prostřednictvím aplikací vyvinutých těmito vývojáři. 4.2 Legislativa Velké Británie Portál legislation.gov.uk je oficiální vládní archiv legislativních dokumentů Velké Británie. Nabízí přístup ke kompletní legislativě více než 800 let zpětně (nejstarší dokumenty jsou z roku 1267). Kromě uživatelského rozhraní publikuje data také dle principů LOD. Jako entity s vlastními URI zde vystupují nejenom dokumenty, ale i jejich části. První výhodou je možnost strojově přistupovat do legislativních dokumentů či jejich částí. Hlavní výhodou ale je, že externí subjekty mohou svá data či dokumenty navazovat na související legislativu. Toho využili např. autoři projektu ESD toolkit 14, v rámci kterého vytvořili kontrolované slovníky týkající se veřejné správy, např.: práva a povinnosti orgánů veřejné správy služby poskytované orgány veřejné správy potřeby občanů Pojmy v těchto slovnících a vazby mezi nimi jsou publikovány v podobě LOD. Navigací v takto publikovaných datech se můžeme dozvědět, že orgán veřejné správy může poskytovat službu udělování licencí k pouličnímu obchodování, pokud má právo k udělování obchodních licencí a licencí k pouličnímu prodeji. Dozvíme se, že toto právo opravňuje orgán poskytovat i další služby, např. monitorovat a regulovat pouliční obchodníky a udělovat pokuty, ale neopravňuje jej rozhodovat v otázkách licencí pro poskytování pouliční zábavy (např. pouliční hudba apod.). Projekt ESD toolkit nedávno začal propojovat práva a povinnosti na legislativu uveřejňovanou v rámci legislation.gov.uk jako LOD. Vazby lze již nyní využít např. pro získání legislativního předpisu upravující dané právo nebo povinnost za účelem kontroly, zda je daný orgán povinen poskytovat danou službu či zda ji neposkytuje neoprávněně. Cílem je také snižování nákladů kontrolou duplicit v prováděných službách [5]. 5 Nástroje pro práci s LOD vyvíjené na MFF UK Výzkumná skupina XRG na Katedře softwarového inženýrství MFF UK 15 pracuje na trojici nástrojů, které lze dohromady označit jako ETL Framework, který umožňuje extrahovat data z různých zdrojů (např. HTML, XML, Excel, atd) a převádět do RDF

67 Linked Open Data a jejich aplikace v praxi , Praha Martin Nečaský, Tomáš Knap, MFF UK ukládat data v RDF úložišti, čistit je a provazovat navzájem i na jiná data dostupná prostřednictvím webu dat (tj. tvořit LOD) analyzovat a vizualizovat výsledná LOD Základní architektura frameworku je znázorněna na obrázku 5. Tři základní komponenty frameworku představíme ve zbytku kapitoly. 5.1 Extraktor Obrázek 5: Architektura ETL frameworku pro práci s LOD Extraktor je komponenta, která umožňuje dolovat data z různých zdrojů, které nepublikují svá data jako LOD (jako jsou např. (X)HTML stránky nebo Excel tabulky), a převádět je do RDF formátu. V současné době shromažďuje např. data o veřejných zakázkách, z obchodního rejstříku, rozpočty měst a obcí, rejstříky škol atd. a ukládá je do RDF formátu dle různých ontologií. Převedená data jsou zasílána do RDF úložiště (využívající databázový systém OpenLink Virtuoso 16 ) prostřednictvím webové služby, kde jsou uloženy do tzv. špinavé databáze (dirty database). 5.2 Úložiště Data uložená ve špinavé databázi jsou postupně čistěna, propojována s jinými daty ve veřejně dostupném webu dat, a je posouzena jejich kvalita. Následně jsou data uložena (spolu se skóre určující jejich kvalitu a dalšími metadaty o původu dat) v tzv. čisté databázi (clean database). Úložiště obsahuje další komponenty různých typů: komponenty čistící data, komponenty propojující data, komponenty hodnotící kvalitu dat a komponenty pro agregaci dat. Cílem komponent čistících data je opravovat chyby v příchozích datech. Jedná se o třídy jazyka Java implementující definované rozhraní a mající soubor RDF dat jako vstup a výstup. Komponenta může například kontrolovat (vůči obchodnímu rejstříku), zda má podnikatelský subjekt platné identifikační číslo. Protože data popisující stejné koncepty (např. osoby, veřejné zakázky) lze identifikovat různými identifikátory (URI), obsahuje úložiště komponenty pro propojování dat. Podporují specifikaci pravidel (skripty), která se aplikují na vstupní soubor RDF dat a snaží se odhalit, zda data popisují nový koncept nebo koncept již uložený v čisté databázi. V druhém případě vytvoří komponenta vazbu, která specifikuje, že dané dva identifikátory reprezentují ten samý koncept. V budoucnu bude rovněž podporováno vytváření jiných typů vazeb mezi daty. Komponenty hodnotící kvalitu dat přiřazují skóre jednotlivým souborům RDF dat v čisté databázi. Přiřazení skóre je založeno na různých dimenzích datové kvality. V současné době se určuje skóre podle toho, zda daný soubor RDF dat splňuje stanovené konzistenční pravidla, např. "Přidělená