NoSQL databáze – současný stav vývoje

Transkript

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.
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: 978-80-905231-0-4
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.
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………………... 45
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.
Moderní databáze 2012 – Architektura IS
11. 10. 2012, Praha
Jaroslav Pokorný, MFF UK
Jaroslav Pokorný
MFF UK
Malostranské nám. 25, Praha 1
Tel: 221914265
e-mail: [email protected]
www: http://www.ksi.mff.cuni.cz/~pokorny/
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
11. 10. 2012, Praha
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, 118 00 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
11. 10. 2012, Praha
K zápisu datové struktury se v těchto případech obvykle využívá formát JSON1. 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, FlockDB3 a
InfiniteGraph4.
Id: 100
Značka: zná
Od: 23.4.2009
Id: 1
Jméno: Jan
Věk: 18
Id: 107
Značka: členové
Id: 103
Značka: zná
Od: 20.9.2010
Id: 106
Značka: je_členem
Id: 105
Značka: je_členem
Od: 8.8.2011
Id: 2
Jméno: Eva
Věk: 19
Id: 104
Značka: členové
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 CASSANDRA5 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, 118 00 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, 118
00 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.
1
http://www.json.org/
http://neo4j.org/
3
https://github.com/twitter/flockdb
4
http://www.infinitegraph.com/
5
http://cassandra.apache.org
2
3
11. 10. 2012, Praha
V databázi BigTable6 (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íč http://ksi.mff.cuni.cz 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
http://ksi....
časové
razítko
sloupec
Jméno
skupina sloupců Vnoučata
D1
V1
D2
V2
D3
V3
t1
t2
t3
"Jaroslav"
"Jaroslav"
"Jaroslav"
"Klára"
"Klára"
"Klára"
7
7
7
"Barbora"
"Barbora"
6
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 SimpleDB7 má SELECT syntaxi
SELECT výstupní_seznam
FROM jméno_domény
[WHERE výraz] [třídění] [limit limit]
6
7
http://www.google.com/base/
http://aws.amazon.com/simpledb/
4
11. 10. 2012, Praha
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 Hypertable8. 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ř. CouchDB9.
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 HBase10
ří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.
8
http://hypertable.org
http://couchdb.apache.org
10
http://hbase.apache.org/
9
5
11. 10. 2012, Praha
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 Valdemort11 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 Hadoop13 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ř. Redis14. 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.
11
http://project-voldemort.com
http://aws.amazon.com/s3/
13
http://hadoop.apache.org/
14
http://redis.io/
12
6
11. 10. 2012, Praha

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. 10. 2012, Praha
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
SimpleDB
Dynamo
Redis
Výrobce
Amazon
Amazon
Salvatore
Sanfilippo
Voldemort
LinkedIn
Datový model
{(klíč, {hodnota})}
jako SimpleDB
{(klíč, hodnota)}, kde hodnota je
jednoduchá
typovaná,
seznam,
uspořádaná (podle ohodnocení) nebo
neuspořádaná množina, hašovaná
hodnota
jako SimpleDB
Dotazovací jazyk
omezený SQL
jednoduché čtení a zápis
primitivní příkazy pro
každý typ hodnoty
CAP
AP
AP
CP
Rep
As
As
As
T
N
N
N
podobné Dynamo
AP
As
N
Dotazovací jazyk
čtení libovolné buňky tabulky,
lze
omezit
rozsah
prohledávaných
řádků,
sloupců, skupin sloupců
JRUBY,
interaktivní shell
(nahrazuje HQL)
nalezení objektu, rozsahové
dotazy, složité predikáty,
upořádání, top-k
CAP
CP
Rep
As
+
S
T
L
CP
As
L
AP
As
L
jednoduchá selekce přes klíč,
rozsahový dotaz, řezy přes
vyjmenované sloupce nebo
rozsahy sloupců
HQL
AP
As
L
CP
As
L
Tab. 2. NoSQL databáze typu klíč-hodnota
Jméno
BigTable
Výrobce
Google
Datový model
{(klíč:hodnota,
{klíč:hodnota})}
HBase
Apache
je klonem BigTable
PNUTS
Yahoo
CASSANDRA
Apache
(původně
Facebook)
(hašované
nebo
uspořádané)
tabulky,
typovaná pole, flexibilní
schéma
{(klíč:hodnota,
{klíč:hodnota})}
Hypertable
Hypertable
jako BigTable
Tab. 3. Sloupcově orientované NoSQL databáze
8
11. 10. 2012, Praha
Jméno
CouchDB
Výrobce
Couchbase
MongoDB15
10gen
Datový model
dokument jako seznam
pojmenovaných
(strukturovaných) položek
objektově
strukturované
dokumenty
ukládané
v kolekcích
Dotazovací jazyk
pohledy pomocí Javascript a
MapReduce
CAP
AP
Rep
As
T
N
manipulace objektů v kolekcích
(nalezení,
odstranění,
aktualizace,
jednoduché
selekce)
CP
As
N
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
UnQL16 (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 http://nosqldatabase.org/ 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 Cluster17, VoltDB18 a Clustrix19. 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:
15
http://www.mongodb.org
16
http://www.unqlspec.org/display/UnQL/Home
http://www.mysql.com/products/cluster/
18
http://voltdb.com/
19
http://www.clustrix.com/
17
9
11. 10. 2012, Praha

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), 111-118.
[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), 251-263.
[3] Brewer, E.A.: Towards Robust Distributed Systems. Invited talk on PODC 2000, July 16-19
2000, Portland, Oregon (2000).
[4] Brewer, E.A.: CAP Twelve Years Later: how thee „Rules“ Have Changed. Computer, February
(2012), 22-29.
[5] Cattell, R.: Scalable SQL and NoSQL Data Stores, 2011, last updated January 28, 2011.
[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),
http://www.usenix.org/event/osdi06/tech/
[7] Cooper, B. F., et al: PNUTS: Yahoo!’s hosted data serving platform. PVLDB, 1(2):1277–1288,
2008.
[8] Dean, D., Ghemawat, S.: MapReduce: Simplified Data Processing on Large Clusters.
Communications of the ACM, January 2008/Vol. 51, No. 1, 107-113.
[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. 205220.
[10]
Gantz J., Reinsel, D.:
Extracting Value from Chaos. IDC iView, June 2011,
http://idcdocserv.com/1142
[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) 51-59.
[12]
McKinsey Global Institute: Big data: The next frontier for innovation, competition, and
productivity.
May
2011,
http://www.mckinsey.com/Insights/MGI/Research/Technology_and_Innovation/Big_data_The_n
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. 5-14.
[14]
Pritchett, D.: BASE: An Acid Alternative. ACM Queue, May/June (2008) 48-55.
10
11. 10. 2012, Praha
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
11. 10. 2012, Praha
Modelování XML schémat
Karel Richta, Jakub Klímek, Martin Nečaský, Jakub Malý
MFF UK
Katedra softwarového inženýrství, MFF UK
Malostranské nám. 25, Praha 1, 118 00
Tel: +420 221 914 250
www: http://ksi.mff.cuni.cz/~richta
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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.
Obr 4: Celková architektura nástroje eXolutio (MVC)
3.2
Komponenta „Model“
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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 - http://www.isvz.cz). 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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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.
ObrJe
9: vidět
Počtyžeatomických
provedených ručně
(tmavá šedá) a automaticky propagačním
4(b).
informace operací
je nyní reprezentována
hierarchicky.
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
5
MFF UK
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. 262–277. Springer, 2006.

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, 2010.
ACM.

S. V. Coox. Axiomatization of the Evolution of XML Database Schema. Program. Comput.
Softw., 29(3):140–146, 2003.

K. Czarnecki and S. Helsen. Feature-Based Survey of Model Transformation Approaches. IBM
Syst. J., 45(3):621–645, 2006.

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. 343–352. Springer, 2005.

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. 96–103. Springer Berlin / Heidelberg, March 2010. URL:
http://www.springerlink.com/content/v45198r1v783xu13.

J. Klímek, J. Malý, and M. Nečaský. eXolutio – A Tool for XML Data Evolution, 2011. URL:
http://exolutio.com.

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, 2010. ACM.

Microsoft. Windows Presentation Foundation (WPF). December 2010. URL:
http://msdn.microsoft.com/en-us/library/ms754130.aspx.

J. Miller and J. Mukerji. MDA Guide Version 1.0.1. Object Management Group, 2003.

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):683 – 707, 2012.

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. 514–523. Springer, 2011.
22
11. 10. 2012, Praha
MFF UK

OMG: Model Driven Architecture (MDA): The Architecture of Choice for a Changing World.
Object Modeling Group, March 2012. UML: http://www.omg.org/mda/.

OMG: Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification Version 1.0.
Object Modeling Group, April 2008. URL: http://www.omg.org/spec/QVT/1.0/.

OMG: Unified Modeling Language, Object Management Group, nov 2007. URL:
http://www.omg.org/spec/UML/2.4.1/ .

OMG: XML Schema Definition Language (XSD) 1.1, Recommendation 5 April 2012. URL:
http://www.w3.org/XML/Schema .

Richta, K.: Jazyk OCL a modelem řízený vývoj. In: Moderní databáze 2010. Komix 2010.
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
11. 10. 2012, Praha
Integrované systémy Oracle pro svět SQL i NoSQL
David Krch, Oracle ČR
David Krch
Oracle ČR
Adresa: V Parku 2308/8, Praha
Tel: 221 438 150
www: http://www.oracle.com
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
Integrované systémy pro SQL
2
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 1.000 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:
http://www.oracle.com/technetwork/serverstorage/engineered-systems/exadata/dbmachine-x2-2-datasheet-175280.pdf
2.2
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
11. 10. 2012, Praha

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: http://www.oracle.com/us/products/servers-storage/servers/sparcenterprise/t-series/sparc-supercluster-ds-496616.pdf
2.3
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
11. 10. 2012, Praha
Integrované systémy pro Big Data / NoSQL
3
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
11. 10. 2012, Praha
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: http://www.oracle.com/technetwork/server-storage/engineeredsystems/bigdata-appliance/overview/bigdataappliance-datasheet-1453665.pdf
30
11. 10. 2012, Praha
Netezza – to pravé řešení pro analytický datový sklad
Martin Pavlík, IBM ČR
Martin Pavlík
IBM Česká republika, spol. s r.o.
V Parku 2294/4, Praha 4 – Chodov, 148 00
Tel: +420 731 435 691
www: http://www-01.ibm.com/software/cz/swreseni/netezza.html
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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 1000-12 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
11. 10. 2012, Praha
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 1000-12 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
11. 10. 2012, Praha
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
11. 10. 2012, Praha

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
11. 10. 2012, Praha
Obr. 4 Architektura logického datového skladu
39
11. 10. 2012, Praha
Informix Warehouse Accelerator
Jan Musil, IBM ČR
Ing. Jan Musil
IBM Česká republika
V Parku 2294/4, 148 00 Praha 4
[email protected]
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 11.7.
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
11. 10. 2012, 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
11. 10. 2012, 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
11. 10. 2012, 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), 20.2.2010
[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, 2011
43
11. 10. 2012, Praha
Jan Musil, IBM ČR
Summary
The document gives the overview of the most interesting technologies in version IBM
Informix 11.7. 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 100 – 1000 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, MultipleData) 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
11. 10. 2012, Praha
Zpracování proudů dat o událostech v reálném čase.
Technologie a aplikační možnosti.
Jiří Gregor, GALEOS, a.s.
Technologie a aplikační možnosti
Ing. Jiří Gregor
GALEOS, a.s.
Michelská 300/60, Praha 4
Tel: +420 241 480 558
www: www.galeos.cz
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
11. 10. 2012, Praha

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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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).
IT architektura pro zpracování událostí
4
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
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
11. 10. 2012, Praha
Literatura
[1] K Mani Chandy, W. Roy Schulte: Event processing. Designing IT systems for Agile Companies.
McGraw Hill 2010.
[2] Progress Software: White papers http://www.progress.com/cs/apama/apama-resources.html
[3] The Forrester Wave: Complex Event Processing Platforms
53
11. 10. 2012, Praha
Linked Open Data a jejich aplikace v praxi
Martin Nečaský, Tomáš Knap, MFF UK
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
http://www.xrg.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
11. 10. 2012, Praha
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.
Otevřená data
2
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 katalog1, 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é instituce2, namátkou zmiňme např. Velkou
Británii3, Keňu4 či Světovou banku5.
1
http://www.data.gov
2
http://www.data.gov/opendatasites
3
http://data.gov.uk
4
http://opendata.go.ke
5
http://data.worldbank.org
55
11. 10. 2012, Praha
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 Lince6. 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ávy7. 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 republiku9 [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 http://cz.ckan.net.
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
http://gov.opendata.at, Vídeň: http://data.wien.gv.at/, Linz: http://data.linz.gv.at/ (založen 4. října 2011)
7
http://www.opendata.cz/cs/event-austria12
8
http://www.opengovpartnership.org/
9
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
11. 10. 2012, Praha
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: http://linkeddata.org). Zobrazená síť je také někdy
nazývána LOD cloud.
57
11. 10. 2012, Praha
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:
http://ld.opendata.cz/resource/business-entity/00276111
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
11. 10. 2012, Praha
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
http://purl.org/goodrelations/v1#legalName
a vlastnosti zadavatel veřejné zakázky HTTP URI
http://purl.org/procurement/public-contracts#contractingAuthority
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:
<http://ld.opendata.cz/resource/business-entity/00276111>
gr:legalName "Město Semily" .
<http://ld.opendata.cz/resource/isvzus.cz/public-contract/4db48795-...>
pc:contractingAuthority <http://ld.opendata.cz/resource/business-entity/00276111> .
<http://ld.opendata.cz/resource/isvzus.cz/public-contract/45ac50e4-...>
<http://ld.opendata.cz/resource/isvzus.cz/public-contract/9d037679-...>
59
11. 10. 2012, Praha
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 http://purl.org/goodrelations/v1# a prefix pc: pak jmenný
prostor s URI http://purl.org/procurement/public-contracts#.
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
11. 10. 2012, Praha
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 endpoint10.
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#>
PREFIX gps: <http://www.w3.org/2003/01/geo/wgs84_pos#>
PREFIX pc: <http://purl.org/procurement/public-contracts#>
PREFIX dc: <http://purl.org/dc/terms/>
PREFIX gr: <http://purl.org/goodrelations/v1#>
PREFIX br: <http://purl.org/business-register#>
SELECT DISTINCT ?name ?orgName ?contractTitle ?priceval ?mainObject WHERE {
?supplier br:officialNumber "26457733" .
?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 .
10
http://ld.opendata.cz:8894/sparql
61
11. 10. 2012, Praha
?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 UK13 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.
Příklady využití LOD ve světě
4
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ž
200.000 návštěvníky měsíčně. Portál integruje data publikovaná v podobě LOD z mnoha externích
11
http://purl.org/procurement/public-contracts
12
http://ted.europa.eu
13
http://xrg.cz
62
11. 10. 2012, Praha
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 toolkit14, 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
14
http://standards.esd.org.uk/
15
http://www.xrg.cz
63
11. 10. 2012, Praha

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.
Obrázek 5: Architektura ETL frameworku pro práci s LOD
5.1
Extraktor
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 Virtuoso16) 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á
16
http://virtuoso.openlinksw.com/
64
11. 10. 2012, Praha
veřejná zakázka by měla obsahovat datum podepsání smlouvy s dodavatelem." Pokud není dané
pravidlo splněno, dojde ke snížení skóre daného souboru dat.
Abychom usnadnili konzumentům propojených dat agregovat data o dané entitě, která mohou (1)
pocházet z různých zdrojů s různou kvalitou dat a (2) být strukturována a mít sémantiku dle různých
ontologií, obsahuje úložiště modul poskytující agregované pohledy na data v čisté databázi. Kromě
toho doplňuje všechna agregovaná data popisnými metadaty o (1) původu dat (např. datum vytvoření
dat, licence dat, zdroj dat) a (2) kvalitě dat, které mají pomoci konzumentům dat rozhodnout se, která
data jsou pro ně užitečná v daném kontextu (pro danou úlohu).
5.3
Analyzátor a vizualizátor
RDF data uložená v úložišti mohou být konzumována několika způsoby pomocí webové služby pro
spotřebitele. První způsob je zaslat v požadavku URI konceptu, který konzumenta dat zajímá o (šipka
2a v obrázku 5); jako odpověď pak konzument dostane agregovaný popis konceptu spolu s kvalitou
takto agregovaných dat. Pokud konzument nezná URI konceptu, který hledá, může zadat seznam
klíčových slov (šipka 3a) a dostane jako odpověď (šipka 3b) identifikátory (URI) top K relevantních
konceptů. V neposlední řadě může konzument položit SPARQL dotaz (podobný SQL dotazu) a
získat data, která jsou výsledkem vyhodnocení dotazu; tato možnost je pro pokročilé uživatele.
Analyzátor a vizualizátor představuje jednoho takového konzumenta dat. Zjednoduší práci
vývojářům aplikací i uživatelům tím, že jim umožní specifikovat, která data vrácená úložištěm se
mají vizualizovat, jak se mají vizualizovat a také umožní definovat základní analýzy nad daty (např.
výpočet průměrné mzdy v podniku).
6
Závěr
V tomto článku jsme představili koncept otevřených dat a demonstrovali jeho přínosy z pohledu dat
veřejné správy. Dále jsme se věnovali sadě technologických principů umožňujících publikovat
otevřená data tak, aby byla identifikovatelná a vzájemně propojitelná. Taková data se nazývají
Linked Open Data (LOD). Nakonec jsme krátce představili softwarové nástroje vyvíjené na MFF UK
pro práci s LOD.
Ukázali jsme, že LOD již dnes tvoří poměrně rozsáhlou síť tzv. web dat. Ten je možné využít jako
velkou distribuovanou sdílenou databázi s velkým aplikačním i komerčním potenciálem. Je však
stále otázkou, zda je koncept životaschopný, neboť je zde stále mnoho problémů čekajících na
vyřešení. Zlom nastane ve chvíli, kdy organizace začnou běžněji LOD konzumovat nebo dokonce
produkovat. To, zda taková situace nastane, se pravděpodobně dozvíme ještě v první polovině tohoto
desetiletí.
Literatura
[1] The Memorandum on Transparency and Open Government. [online:
http://www.whitehouse.gov/the_press_office/TransparencyandOpenGovernment, ke dni
3.5.2012]
[2] F. Bauer, M. Kaltenböck. Linked Open Data: The Essentials – A Quick Start Guide for Decision
Makers. 2012. ISBN: 978-3-902796-05-9.
[3] Akční plán České republiky „Partnerství pro otevřené vládnutí“. Vláda ČR. [online:
http://www.vlada.cz/assets/ppov/boj-s-korupci/otevrene-vladnuti/Akcni-plan-OGP.pdf, ke dni
3.5.2012]
[4] Tim Berners-Lee. Linked Data – Design Issues, 2006. [online:
http://www.w3.org/DesignIssues/LinkedData.html, ke dni 3.5.2012]
[5] Choosing what services our council delivers and knowing what we must deliver. [online:
http://www0.esd.org.uk/esdtoolkit/News/NewsDetail.aspx?Item=633, ke dni 3.5.2012]
65
11. 10. 2012, Praha
[6] OWL Web Ontology Language – Document Overview. W3C Recommendation 27 October
2009. [online: http://www.w3.org/TR/owl2-overview/]
Poděkování
Práce na tomto článku byla podpořena z EU FP7 projektu LOD2 a Grantovou agenturou ČR
z projektu č. P202/11/P455.
Summary
Linked Open Data is a new concept for data management on the Web. There is emerging a new Web
of Data, i.e. Web that is formed by linked and machine readable data. In the first part of this lecture,
we will introduce the concept of Linked Open Data and we will demonstrate real examples, e.g. data
of UK Government or medical data. In the second part of the lecture, we will demonstrate existing
technologies and tools for working with Linked Open Data. In the last part, we will present the
results of the research being held at Charles University in Prague in the area of Linked Open Data
and its practical outputs, e.g. czech Linked Open Data.
66
11. 10. 2012, Praha
SDMT – Zpracování dat s velmi složitou strukturou
Jan Vrána, KOMIX s.r.o.
SDMT
Zpracování dat s velmi složitou strukturou
Ing. Jan Vrána Ph.D.
KOMIX s.r.o.
Holubova 1, Praha 5, 150 00
Tel: 225 989 811
www: www.komix.cz
Klíčová slova: Rozsáhlý systém, metadata, dynamické uložení dat, mobilní síť
Abstrakt: Pod pojmem „veliká“ nebo „rozsáhlá“ data jsou většinou vnímána data velikého objemu –
s velikým počtem záznamů, jejichž zpracování klade vysoké nároky na paměť, disky a procesor. Tento
příspěvek pojednává o jiném typu složitosti nebo rozsáhlosti dat a o systému SDMT (System
Database Management Tool), který tento typ dat efektivně zpracovává. Jedná se o data velmi složitá
svou strukturou. Výzvou pro budování systému SDMT byla data sestávající z mnoha tisíc entit a
stovek tisíc atributů, které podléhají změnám, a je potřeba nad nimi efektivně vyhodnocovat složité
dotazy.
1
Úvod
Pod pojmem „veliká“ nebo „rozsáhlá“ data jsou většinou vnímána data velikého objemu – s velikým
počtem záznamů, jejichž zpracování klade vysoké nároky na paměť, disky a procesor.
Před časem jsme byli konfrontováni s požadavkem, který, jak se ukázalo, vedl na systém s velmi
vysokou datovou náročností, avšak v poněkud netradičním smyslu. Jednalo se o požadavek na
vytvoření nástroje pro správu, vizualizaci a administraci nastavení telekomunikační sítě GSM
dnešního operátora O2.
1.1
Problematika GSM sítě
GSM síť se skládá ze stovek technologických oblastí uspořádaných do desítek síťových elementů
(ústředen, HLR, RNC, MGC, ISS,…) různých typů a složitosti. Každý síťový element má svou různě
složitou vnitřní strukturu. Od jednoduchých opakovačů až po složité páteřní komunikační uzly.
Jednotlivé uzly jsou spolu svázány vazbami různých úrovní a typů. Některé vazby mají přímo
fyzickou podobu kabelů spojujících jednotlivá zařízení. Jiné vazby mají mnohem méně hmatatelnou
podobu vzájemně si odpovídajícího nastavení příslušných parametrů svázaných uzlů. Toto nastavení
přímo vyplývá ze struktury komunikačních uzlů.
67
11. 10. 2012, Praha
Ústředna PRAHA
Ústředna BRNO
PRAHA
BRNO
Obr. 1 - Vazba mezi aktivními prvky sítě přes hodnoty parametrů
Mají-li spolu dva prvky komunikovat např. Ústředna Praha s Ústřednou Brno– (viz obr. 1), musí v
obou z nich existovat v jejich směrovacích tabulkách takové položky, které mají za následek
nasměrování části komunikace do správných fyzických propojení (např. drátů), fyzicky spojujících
oba komunikační uzly.
Mohou také existovat i mnohem jemnější vazby, které představují empirická pozorování nebo
zkušenosti, jak se dané prvky vzájemně nepřímo a odvozeně ovlivňují. Sníží-li se například z
nějakých důvodů propustnost jednoho uzlu, je potřeba přesměrovat část komunikace na některé jiné
uzly a zajistit tím dostatečnou propustnost celé sítě. Některé části a parametry sítě mohou navíc mít
jiný než přímo komunikační charakter. Část uzlů komunikační sítě se například zabývá evidencí
uživatelů a tarifikací používání sítě, poskytováním dalších nadstavbových funkcí a služeb, atd.
Správa takové sítě spočívá v udržování a nastavování jednotlivých parametrů v příslušných
komunikačních uzlech tak, aby síť jako celek vykazovala požadované vlastnosti (např. celkovou
propustnost, odolnost vůči lokálním výpadkům, poskytování doplňkových služeb, atd.). Typickou
administrační úlohou správy je například příprava sítě na plánovanou změnu rozložení zátěže
přesměrováním části zátěže na méně zatížené uzly, rekonfigurace sítě při výpadku některých uzlů,
začlenění nových uzlů do sítě nebo naopak, odebrání nepoužívaných nebo vadných uzlů ze sítě,
změna způsobu adresování (číslování) koncových stanic, změna způsobu tarifikace používání sítě,
zavedení nové služby do sítě, atd.
Každý zásah do sítě vyžaduje velice dobrou znalost její technologické konstrukce a fyzické topologie
a logických vazeb, ale také detailní znalost aktuálního nastavení všech parametrů ve všech
komunikačních uzlech, kterých se příslušná změna týká. Před zásahem do systému musí obsluha
shromáždit, prostudovat a dát vzájemně do souvislostí informace o stávajícím stavu a následně
navrhnout nové nastavení jednotlivých parametrů tak, aby měl zásah požadovaný efekt. S rostoucím
rozsahem a složitostí sítě velice rychle roste množství informací, které musí obsluha pro naplánování
a provedení každé změny zohlednit. V síti, která je rozsahem ekvivalentní například komunikační síti
v ČR, vyžaduje každá jen trochu větší změna usilovnou práci mnoha lidí, kteří většinu času tráví
procházením výpisů aktuálních hodnot všech parametrů všech uzlů v síti a dohledáváním parametrů,
jichž se bude daná změna týkat. To je práce velice náročná, ale hlavně neefektivní a je častým
zdrojem chyb.
V komerčním prostředí je obrovský tlak na jedné straně na pružnost, tj. na rychlost zavádění nových
služeb sítě a na druhé straně na zvyšování spolehlivosti sítě, protože každá minuta výpadku sítě
přestavuje obrovské přímé ztráty v podobě ušlého zisku a ještě větší ztráty v podobě poškození
dobrého jména operátora.
Počítačová podpora v podobě systému SDMT měla umožnit správcům sítě rychle a efektivně
procházet a prohlížet jednotlivé části sítě, jejich nastavení a vzájemné vazby, jejich vzájemné
porovnávání i sledování vývoje v čase a velice tak usnadnit a zefektivnit administrační zásahy.
Hlavní problémy, které měl systém SDMT řešit byly:
68
11. 10. 2012, Praha

Složité získávání informací o aktuálním nastavení parametrů sítě. Informace bylo nutné
získávat z různých zdrojů (binární konfigurační data, textové výpisy), které neměly
jednotnou formu.

Práce všech plánovačů nad jednotnými daty. Při plánování změny neměli jednotliví
plánovači snadný přístup k dříve naplánovaným a dosud nerealizovaným změnám a
vycházeli tak ve svých plánech z nesprávných vstupů.

Automatizovaná správa požadavků na změnu. Požadavky na změnu neměly jednotnou formu
a komunikace s realizátory požadavků (předání požadavku a zpětná vazba o jeho realizaci)
nebyla automatizovaná.

Automatizovaná i uživatelská kontrola provedených změn, možnost zobrazit stav sítě
v libovolném historickém okamžiku. Kontroly, že požadované změny byly provedeny
korektně, bylo nutné provádět opět ručně a vše manuálně porovnávat.
Aby mohl počítač poskytovat požadované informace rychle a efektivně, je nutné do něj uložit
informace o nastavení celé sítě se vší složitostí všech parametrů a jejich vzájemných vazeb. To je
právě jedna z úloh, které lze snadno formulovat a řešit v malém rozsahu, ale jejíž výpočetní nebo
paměťová složitost rychle roste s rostoucím rozsahem sítě.
Efektivní načtení a uložení informací o spravované síti a jejich následné zpracování je hlavním a
nejdůležitějším problémem vytvoření popisované počítačové podpory správy telekomunikační sítě.
Jedná se o problém uložení rozsáhlého obecného grafu a následných operací nad ním.
Technické řešení
2
2.1
Požadavky
Technologické požadavky na nový systém vycházely zejména z parametrů sítě, kterou měl spravovat.
Uvažovaná GSM síť sestává z:

Cca 200 komplexních uzlů (síťových prvků s různě složitou vnitřní strukturou).

Komplexní uzly se skládají z konkrétních tabulek parametrů a nastavení (entit), kterých je
celkem cca 13000 zhruba 400 typů.

Jednotlivé tabulky (entity) se skládají ze sloupců (atributů), těch je celkem cca 200 000 a
jejich vzájemně provázaných hodnot jsou desítky až stovky milionů.

Entity jsou propojeny vazbami, kterých je cca 20 000.
Aktuální hodnoty jednotlivých údajů jsou čerpány z různých souborů stahovaných z jednotlivých
síťových prvků.

Celkem se obraz stavu sítě čerpá z cca 600 souborů a

Celkem cca 140 000 položek (atributů) vstupních souborů.
V souvislosti s obměnami a modernizací technologií jednotlivých komunikačních uzlů dochází
k průběžným změnám struktury a obsahu zejména vstupních souborů. Za jeden rok dojde průměrně
ke změně cca 5% vstupních údajů (7 000 atributů).
Dalšími důležitými požadavky byly ekonomické požadavky:

Nízké pořizovací náklady a

Nízké provozní náklady.
Do kategorie nefunkčních požadavků patřil:

Vysoká provozní efektivita zpracování  vysoký výkon.
69
11. 10. 2012, Praha
2.2
Dostupné technologie
Při zvažování možných metod pro implementaci systému pro správu uvedené sítě bylo nutné hledat
metody použitelné na platformě relační databáze, protože alternativní platformy neposkytovaly
očekávaný výkon a dlouhodobou stabilitu architektury.
Z popsaných parametrů je zřejmé, že se jedná o skutečně rozsáhlou síť, pro uložení a zpracování
takové sítě běžně používané databázové systémy neposkytují dobrou podporu. Platforma relační
databáze v zásadě nabízí dva základní přístupy pro budování aplikace:

Aplikace řízená strukturou dat,

Aplikace řízená obsahem dat.
Aplikace řízená strukturou dat zachycuje maximum logiky v podobě struktury a vazeb jednotlivých
tabulek v databázi a odpovídajících částí programového kódu aplikace pro obsluhu jednotlivých
tabulek. Data zpracovává bez toho, že by se příliš řídila jejich obsahem. Schématicky tuto variantu
znázorňuje Obr. 2.
Aplikace
Databáze
Obr. 2 - Schéma aplikace řízené strukturou dat
Aplikace vybudovaná tímto přístupem umožňuje maximálně využít potenciálu relační technologie
vč. možnosti individuálního ladění jednotlivých dotazů a poskytne tak nejvyšší provozní výkon. Pro
uvažovanou složitost datového modelu by ale programový kód byl extrémně rozsáhlý s neúnosnými
náklady na jeho vývoj a další údržbu a rozvoj.
Aplikace řízená obsahem dat naproti tomu ukládá všechna data v co nejuniverzálnější relační
struktuře a maximum logiky zachycuje obsahem dat, tj. hodnotami a vzájemnými vazbami
jednotlivých řádků tabulek. V případě uvažované GSM sítě by to bylo uložení grafu v obecném tvaru
uzel-hrana. Schématicky tento přístup znázorňuje Obr. 3.
70
11. 10. 2012, Praha
Aplikace
Databáze
Hrana
Uzel
Obr. 3 - Schéma aplikace řízené obsahem dat
V tomto případě by všechny spravované informace včetně struktury a topologie celé sítě i hodnoty
jednotlivých parametrů byly uloženy ve zjednodušeném případě ve dvou relačních tabulkách.
Programový kód pro obsluhu naznačeného schématu by byl ve srovnání s předchozím případem
řádově menší, tudíž levnější na vývoj a následnou údržbu a rozšiřování.
Pro uvažovanou složitost a rozsah spravované sítě však aplikace postavená na tomto principu
vykazuje fatální výkonnostní nedostatky. Pro získání jedné hodnoty jednoho konkrétního parametru
je potřeba položit několik dotazů do uvedené relační struktury. Jelikož v uvedených tabulkách by
byly uloženy všechny údaje včetně statické topologie a struktury sítě, atributů, jejich vazeb a
aktuálních i historických hodnot, byl by počet jejich řádků v řádu stovek milionů až miliard
záznamů, což i při použití indexů vede na dlouhé doby vyhodnocení jednotlivých dotazů.
Vyhodnocení přehledových dotazů, pro které je potřeba získat a porovnat veliké množství hodnot
atributů by trvalo neúnosně dlouhou dobu.
Uvedené dvě na platformě relační databáze standardně dostupné metody bohužel vykazují zásadní
nedostatky, které prakticky vylučují jejich reálné použití pro implementaci uvažovaného problému.
2.3
Použité řešení
Aby bylo možné implementovat správu sítě uvažované složitosti, museli jsme vyvinout novou
metodu uložení a správy dat, která by převzala výhodné vlastnosti obou zmiňovaných metod a
zároveň eliminovala jejich zásadní nedostatky. Jedná se především o:

Zásadní redukci složitosti aplikace a tím i nákladů na vývoj a údržbu oproti aplikaci řízené
strukturou dat při maximálním zachování její provozní výkonnosti nebo

Zásadní zlepšení výkonnostních parametrů oproti aplikaci řízené obsahem dat při
maximálním zachování její jednoduchosti a tím i nízkých nákladů na vývoj a údržbu.
Hledání nové metody tedy bylo směrováno následujícími hlavními požadavky:

Zobecnění většiny podobných a opakovaných částí, zejména v oblasti statické struktury a
topologie sítě a zachycení a řízení těchto závislostí formou „obsahu“ dat, tj. metadat.
(vylepšení oproti aplikaci řízené jen strukturou dat)

Oddělení metadat od „business“ dat, což přinese jednak větší přehlednost a snazší údržbu
metadat ale zejména zásadní snížení objemu tabulek, ve kterých jsou uložena metadata a tím
zásadní zrychlení vyhodnocování dotazů nad metadaty (na strukturu a topologii sítě).

Maximální využití možností relační technologie pro uložení a správu „business“ dat, aby
bylo možné dosáhnout co nejlepšího provozního výkonu.
71
11. 10. 2012, Praha
Metodu splňující uvedené parametry se podařilo vyvinout a s její pomocí úspěšně implementovat
systém, který uvedenou GSM síť dokáže efektivně uložit a zpracovávat. Tuto metodu jsme nazvali
Dynamické Relační uložení Dat (DRD) a schéma aplikace na ní založené je znázorněno na Obr. 44.
Aplikace
Databáze
Agregační
vazba
Celek
Entita
Logická
vazba
Atribut
Obr. 4 - Schéma aplikace s dynamickým relačním uložením dat
Metoda Dynamického relačního uložení dat je založena na následujících principech:

Většina údajů o struktuře a topologii spravované sítě (tj. údaje o uzlech, jejich vzájemných
vazbách, vnitřní struktuře jednotlivých uzlů a tabulek parametrů a jejich vazbách), jakožto i o
vstupních souborech, ze kterých se čerpají aktuální data nastavení sítě a informace o jejich
vazbách na konkrétní atributy tabulek parametrů jednotlivých uzlů jsou uloženy v podobě
metadat v pevné statické relační struktuře (levá část schématu). To umožňuje, aby většina
obslužných programů byla univerzální a nezávislá na konkrétní topologii a struktuře
spravované sítě a tudíž, aby příslušný programový kód byl řádově méně rozsáhlý, tedy
levnější na výrobu a údržbu. Uložení strukturních metadat do pevné relační struktury také
umožní mnohem rychlejší vyhodnocování dotazů na strukturu sítě, které jsou při použití
univerzálního přístupu velmi časté.

Jednotlivé tabulky parametrů síťových uzlů a hodnoty jejich atributů vč. historických hodnot
jsou uloženy nativně jako tabulky relační databáze s příslušnou strukturou (pravá část
schématu). Tyto tabulky jsou vytvářeny a případně modifikovány dynamicky na základě
obsahu statického popisu struktury sítě.

Jednotlivé operace s hodnotami atributů jsou realizovány jako dynamicky sestavované SQL
příkazy, které provádějí standardní DML operace a mohou tudíž plně využít výhod a výkonu
nativních operací relační databáze. Takto vytvořených tabulek je sice vysoký počet, to ale
reálně ničemu nevadí, protože k nim přistupuje výhradně aplikace na základě obsahu
metadat. Díky tomuto způsobu uložení a zpracování „business“ dat je možné velmi efektivně
a rychle vyhodnocovat i rozsáhlé „přehledové“ dotazy nad celou spravovanou sítí.
72
11. 10. 2012, Praha
2.4
Vlastnosti řešení
Popsaná metoda Dynamického relačního uložení dat umožnila vyvinout systém pro vizualizaci a
správu parametrů GSM sítě popsaných parametrů. Vznikl tak systém, který je do dnešní doby
unikátní.
Z uživatelského hlediska přináší systém SDMT správcům GSM sítě zejména:

Zásadní zjednodušení a zrychlení všech plánovacích úkolů. Pracovníci plánování nemusí
před každou plánovanou změnou manuálně prohledávat a kontrolovat tisíce stran tištěných
výpisů nastavení nebo klást desítky on-line dotazů do technologických uzlů. Aplikace SDMT
jim na pár kliknutí poskytne všechny relevantní informace. „Business“ výsledkem je zásadní
urychlení např. zavádění nových služeb do sítě nebo rekonfigurace sítě např. v případě
výpadku nějaké části.

Zásadní snížení chybovosti procesu plánování pramenící zejména z chyb lidského faktoru
v podobě manuálního procházení textových a on-line výpisů, ale také z faktu, že údaje
v textových výpisech byly často už zastaralé a neplatné. Z „business“ hlediska je výsledkem
výrazné zvýšení spolehlivosti sítě, což má velmi vysoký přímý ekonomický dopad.
Z technologického hlediska metoda Dynamického relačního uložení dat prokázala požadované
vlastnosti a umožnila vytvořit reálně použitelnou aplikaci pro správu rozsáhlé datové sítě. Zejména
odstranila nežádoucí vlastnosti základních metod, tj.:

Zásadně redukovala objem programového kódu a tudíž náklady na jeho vytvoření a údržbu
oproti aplikaci řízené strukturou dat díky zobecnění většiny obslužných algoritmů a jejich
řízení obsahem metadat.

Zásadně zlepšila provozní výkonnost oproti aplikaci řízené obsahem dat, tj. snížila dobu
vyhodnocení operací nad spravovanou sítí. Zlepšení provozní výkonnosti je umožněno díky
mnohem lepšímu využití nativních vlastností relační databáze.
Na druhou stranu, metoda Dynamického relačního uložení dat ve vysoké míře zachovala žádoucí
vlastnosti obou referenčních metod:

Došlo jen k mírnému poklesu provozní výkonnosti oproti aplikaci řízené strukturou dat
z důvodu režie s načítáním metadat při generování výkonných SQL příkazů a proto, že
jednotlivé výkonné SQL příkazy není možné individuálně optimalizovat.

Došlo jen k mírnému nárůstu objemu programového kódu aplikace oproti aplikaci řízené
obsahem dat z důvodu nutnosti interpretovat obsah metadat a generovat odpovídající
výkonné SQL příkazy.
Porovnání vlastností jednotlivých metod je znázorněno na Obr. 5.
73
11. 10. 2012, Praha
Řízená strukturou dat
Řízená obsahem dat
Dynamicky relační
Cena
Odezva na dotazy
Obr. 5- Porovnání vlastností metod
Použitá technologie práce s košatou a dynamicky se vyvíjející strukturou dat umožnila systému
SDMT poskytnout uživatelům komfortní nástroj pro definici vlastních reportů nad sledovanými daty.
V těchto reportech si uživatel sám nastaví, jaké oblasti spojené přes jaké vazby chce sledovat; určí si
vstupní podmínky a kromě ad-hoc spouštění přímo v aplikaci si může určit i časy jejich pravidelného
spouštění a ukládání do databáze nebo textových výstupů. Typickými příklady takových reportů je
např. sledování vazeb GT analýz s GT resulty přes všechny síťové elementy, sledování kompletních
routingových cest pro vybrané circuit group ve vybraných ústřednách, kompletní výpisy vazeb
service setů a triggerů ve všech ústřednách apod. Uživatelé si tak mohou sami vytvořit potřebné
výstupy, které jim umožňují efektivně řídit zadávání změn.
Závěr
3
Podařilo se nám vyvinout dosud unikátní systém SDMT, který je schopen s využitím všech výhod
robustního prostředí relační databáze efektivně uložit a spravovat datový systém s velmi vysokou
mírou složitosti, konkrétně konfigurační data GSM sítě sestávající z datové sítě desítek až stovek
milionů hodnot jednotlivých atributů konfiguračních parametrů jednotlivých aktivních prvků GSM
sítě.
Vývoj systému a jeho komerční využití umožnila účelově vyvinutá metoda Dynamického relačního
uložení dat, která efektivně kombinuje přirozené metody uložení a správy dat v relační databázi,
odstraňuje jejich zásadní nedostatky a zachovává jejich výrazné přednosti.
Metoda Dynamického relačního uložení dat a systém SDMT byly vyvinuty pro správu
konfiguračních parametrů GSM sítě, ale jejich použití může být mnohem širší. Své uplatnění mohou
s úspěchem nalézt i v dalších systémech, které mají kombinaci následujících vlastností:

Relativně veliký objem dat

Velmi vysoká vnitřní složitost

Dynamicky se měnící struktura.
Tento charakter mají například následující oblasti:

Modelování a správa distribuovaného řídícího systému.
74
11. 10. 2012, Praha

Modelování a správa distribuční a produktovodné sítě.

Modelování a správa obchodní a logistické sítě.

Modelování, správa a odhalování závislostí v ekonomických, technologických a jiných
procesech.

Další.
75
Pořadatel konference Moderní databáze 2012 – Architektura informačních
systémů, společnost KOMIX s.r.o., děkuje:
hlavnímu partnerovi konference:
IBM Česká republika
partnerům konference:
Oracle Česká republika
Hewlett-Packard Česká republika
Avnet s.r.o.
Javlin, a. s.
GALEOS a. s.
Advokátní kancelář Dáňa, Pergl & Partneři
mediálním partnerům konference:
ICT manažer (www.ictmanazer.cz)
eProfil.cz (www.eprofil.cz)
IT Systems (www.systemonline.cz)
Edumenu.cz (www.edumenu.cz)
76
Pořadatel konference Moderní databáze 2012:
KOMIX s.r.o.
Avenir Business Park
Radlická 751/113e
158 00 Praha 5
Tel.: +420 257 288 211
Fax: +420 227 288 221
www.komix.cz
Editor: Barbora Culková, KOMIX s.r.o.
Rok vydání: 2012
ISBN: 978-80-905231-0-4
77

NoSQL databáze – současný stav vývoje

Transkript

Podobné dokumenty

Využití Linked Data pro sdílení dat o smlouvách veřejných institucí

Jak na MORSE 2

Plán školení Česká republika

Vodník - Jirra

Usnesení 4. řádného jednání dne 22. prosince 2010

kyticka

procella - Q-DAS

modelování business procesů a dalších aspektů business systému

243

BMW i3. - ACR auto, as

01. Kdy se začal formovat koncept relačních databází

Text studie (Ing. Zelený)

Dokument... - Obec Temešvár

Dostupné škálovateľné riešenia pre spracovanie veľkého objemu

Petr Šaloun and Dušan Chlapek

MIPS datové linky

Kompetence v environmentálním vzdělání - Envigogika

Sešit č. 5 - Jak získat jistotu a sebedůvěru ve

Monitorovací a řídicí systém pro datové sítě RACOM

XXIVth conference Hotel Sněžník Dolní Morava 16. 5

fond otakara motejla víte, co jsou otevřená data?

Text práce - Katedra geoinformatiky