Koncept architektury reportovacích a datově analytických systémů

Koncept architektury reportovacích a datově analytických systémů Martin Závodný Katedra informačního inženýrství Provozně ekonomická fakulta České zemědělské univerzity Kamýcká 129, 165 21 Praha 6 – Suchdol [email protected] Abstrakt: V příspěvku je představen obecný koncept aplikační architektury reportovacích a datově analytických (RDA) systémů. RDA systém je jednou z komponent BI systémů, která má za cíl využívat data z datové vrstvy a ve vhodné formě je poskytovat uživatelům. Článek analyzuje jednotlivé komponenty těchto systémů a jejich významné vlastnosti. Rovněž jsou rozebrány faktory, které mají vliv na podobu RDA systému a je představen návrh řešení pro vývojové, testovací a produkční prostředí. Klíčová slova: Business Intelligence, reportovací a datově analytický systém, architektury, technologie Abstract: The contribution presents a general concept of application architecture of reporting and data analytic (RDA) systems. RDA system is one of the components of BI systems, which uses data from data layer and provides it to end users in a suitable analytic format. The article analyses individual components of these systems and its significant properties. Factors, which influence structure of RDA systems, are presented, as well, and solution design for development, testing and production environments is introduced. Keywords: Business Intelligence, reporting and data analytic system, architectures, technologies

1. Cíl Cílem článku je zaměřit se na oblast architektur Business Intelligence (BI) řešení a detailněji analyzovat a aktualizovat poznatky týkající se architektury jedné z částí BI systémů, a to reportovacích a datově analytických (RDA) systémů. RDA systémy jsou zde chápány jako jedna z vrstev BI systémů, která čerpá data z datových úložišť, zpracovává je a ve vhodné formě poskytuje koncovým uživatelům (jedná se zejména o reporty, multidimenzionální analýzy, metadata pro ad hoc dotazy, dashboardy a scorecardy). Článek se zabývá obecným konceptem aplikační architektury RDA systémů, analyzuje jednotlivé komponenty těchto systémů a uvádí jejich důležité vlastnosti. Rovněž jsou zmíněny faktory, které mají vliv na podobu RDA systému. Následující text může být čtenáři vodítkem při výběru RDA systému tak, aby co nejlépe posloužil jeho organizaci při naplňování analytických informačních potřeb. Článek je určen pro čtenáře mající alespoň základní přehled o BI systémech a technologiích.

18

SYSTÉMOVÁ INTEGRACE 2/2013

Koncept architektury reportovacích a datově analytických systémů

2. Metodika Prezentovaný článek vznikl na základě analýzy struktury RDA systémů (informace byly čerpány z dostupné literatury a produktové dokumentace komerčních RDA 1 systémů) a faktorů spojených s jejich nasazením do organizací a následným provozem. Identifikace těchto faktorů vycházela ze zkušeností autora, který se podílel na řadě implementačních projektů v oblasti RDA systémů. Výsledkem byl návrh zobecněné struktury RDA systému, uváděný v následujících kapitolách. Uváděné poznatky byly rovněž ověřeny v praxi konzultacemi se specialisty z oblasti BI. Záměrem tohoto článku nebylo provedení srovnání jednotlivých komerčních produktů, neboť takové srovnání má vzhledem k neustálému vývoji těchto produktů velmi omezenou časovou platnost, ale návrh cílového konceptu, ke kterému by moderní RDA systémy měly směřovat.

3. Definice RDA systémů a jejich zasazení do kontextu BI systémů 2

RDA systém je, v chápání tohoto článku, jednou z komponent BI systému , která má za cíl využívat data z datové vrstvy a ve vhodné formě je poskytnout uživatelům. Nejedná se o komponentu, která má primárně za cíl provádět transformace dat, ale o prezentační vrstvu BI řešení. Pokud jde o strukturu BI systémů, jedno z možných schémat jejich architektury (z pohledu směru toku dat), je znázorněno na obr. 1. Obrázek zachycuje jednotlivé komponenty BI systémů a ilustruje také začlenění RDA systémů do jejich struktury. Jednotlivé komponenty jsou níže stručně charakterizovány:  Vrstva datových zdrojů – zdrojové systémy obsahující data určená pro analýzy.  Vrstva datové integrace – nástroje pro přenos a transformaci dat ze zdrojových 3 4 systémů do datových úložišť (jedná se ETL nástroje a EAI nástroje ).  Datová vrstva – systém uložišť uchovávající data pro účely analýz. Mezi obecně přijímané architektury datové vrstvy patří například architektura centralizovaného datového skladu, resp. architektura nezávislých datových tržišť, viz např. (Novotný, Pour, & Slánský, 2004).

1

Z existujících systémů byly analyzovány nástroje Pentaho, Cognos, Business Objects, Microsoft BI, viz (Bouman, 2009), (IBM. 2012), (SAP. 2009), (Microsoft. 2010). 2 BI systémy patří do skupiny systémů pro podporu rozhodování. Tyto systémy zpracovávají data zejména z interních provozních systémů organizací a ve vhodné agregované formě je poskytují uživatelům, kteří na jejich základě činí rozhodnutí operativního, taktického nebo strategického významu. 3 ETL nástroje – nástroje pro extrakci, transformaci a nahrání dat z datového zdroje do cílové databáze 4 EAI (Enterprise Application Integration) nástroje – nástroje pro integraci a synchronizaci dat mezi systémy a aplikacemi SYSTÉMOVÁ INTEGRACE 2/2013

19

Martin Závodný

Reportovací a datově analytické systémy – systémy poskytující uživatelům možnost získávat reporty, vytvářet multidimenzionální analýzy a ad hoc dotazy, pracovat s dashboardy a scorecardy.  Metadata jednotlivých vrstev – vrstva obsahující metadata, tedy „data o datech“, týkající se především zdrojových systémů, dat, datových transformací a datových analýz. Většina komponent BI systémů byla poměrně obsáhle zpracována řadou autorů, v tomto článku se však zaměříme na komponentu, která vzhledem k vývoji v posledních letech vyžaduje určitou aktualizaci poznatků, a to na RDA systémy. 

Business Intelligence systém RDA systém Reporting Multidimenzionální analýzy

Scorecardy

Ad hoc dotazy

Dasboardy

Nezávislá datová tržiště

Operativní úložiště

Závislá datová tržiště

Jádro datového skladu

Dočasné úložiště dat

Metadata jednotlivých vrstev

Směr zpracování dat

Datová vrstva

Vrstva datové integrace ETL nástroje

EAI nástroje

Vrstva datových zdrojů

Interní systémy

Externí systémy

Obr. 1: Schéma architektury BI systémů upraveno dle (Novotný, Pour & Slánský, 2004)

20



4. Funkcionalita RDA systémů RDA systémy slouží uživatelům k provádění datových analýz a poskytování 5 analytických sestav . Tyto systémy nabízejí zejména následující funkcionality: 6  Multidimenzionální analýzy OLAP kostek.  Ad hoc dotazy – vlastní analýzy prováděné uživatelem RDA systému.  Reporty – předpřipravené sestavy, které uživatelé mohou zobrazovat. 7  Dashboardy – panel zobrazující klíčové reporty a metriky pro určitou řízenou oblast.  Scorecardy – sestavy zobrazující klíčové metriky a jejich vývoj v čase, zároveň je zachycena indikace, zda se daný ukazatel vyvíjí žádoucím směrem či nikoliv.  Monitoring událostí a notifikace – RDA systém umožňuje vyvolávat události (na základě hodnot definovaných indikátorů) a následně notifikovat o těchto událostech uživatele, případně také spouštět úlohy potřebné pro zpracování sestav. Vlastností těchto systémů je, že poskytují analytické výstupy širokému okruhu uživatelů a zohledňují přitom přístupová oprávnění. RDA systémy by se z pohledu uživatelů měly optimálně jevit jako portálové řešení, kdy jsou jejich jednotlivé funkcionality dostupné z jednoho místa. Strukturu portálu je doporučeno navrhovat obdobně jako strukturu souborového systému. Sestavy jsou umístěny do logicky členěných složek, ze kterých uživatelé vybírají. Složky s sebou nesou odkaz na metadata (viz kapitola 5.1 Metadata editor) a na multidimenzionální modely, které jsou využívány sestavami a také ad hoc dotazy. Složky se sestavami mohou být jak veřejné, tak soukromé, tj. přístupné pouze jejich vlastníkovi. RDA systémy také umožňují archivaci analytických výstupů pro pozdější použití.

5. Aplikační architektury RDA systémů Na níže uvedeném obrázku je znázorněna obecná aplikační architektura RDA systému. Ne všechny komponenty systému musí být využívány, záleží na konkrétních aplikačních potřebách dané společnosti. RDA systémy mají obvykle klasickou třívrstvou architekturu, tvořenou (viz obr. 2)  Databázovou vrstvou – RDA data a metadata.  Aplikační vrstvou – serverové komponenty.  Prezentační vrstvou – vývojářské, klientské a administrátorské nástroje. 5

Sestavou rozumíme v tomto článku analytický výstup, který RDA systém poskytuje (report, dashboard, scorecard, ad hoc analýza a multidimenzionální analýza). 6 OLAP (On-Line Analytical Processing) je technologie založenou na multidimenzionální databázi. Hlavním principem OLAP je multidimenzionální tabulka umožňující flexibilně měnit jednotlivé dimenze a umožnit tak uživateli sledovat data týkající se ekonomické reality podniku z různých pohledů (resp. z pohledu různých zaměnitelných dimenzí), podle (Novotný, Pour & Slánský, 2004). 7 Klíčové výkonnostní ukazatele společnosti. SYSTÉMOVÁ INTEGRACE 2/2013

21

Martin Závodný

Externí systémy

RDA systém - komponenty Vývojářské nástroje Metadata editor Designer multidimenzionálních modelů

Zabezpečení

Klientské nástroje Administrátorské nástroje Prohlížeč sestav

Designer sestav

Studio pro ad hoc analýzy

Monitoring událostí a notifikace

Studio pro multidimenzní analýzy

Programovací prostředí

Dashboard studio

ETL studio

Scorecard studio

Administrační konzole

Serverové komponenty

Webový server Autentizační zdroj

Aplikační server

Datový server Datová vrstva

RDA auditní data

Logovací DB

RDA data a metadata

RDA úložiště

Obr. 2: Schéma aplikační architektury RDA systému Pro snazší orientaci ve fungování RDA systémů je nyní uveden stručný popis jednotlivých komponent a objasnění jejich vzájemné spolupráce. Komponenty RDA systému  Vývojářské nástroje – nástroje pro zpracování dat datové vrstvy, nástroje pro přípravu metadatových modelů pro potřeby analýz (viz kapitola 5.1 Vývojářské nástroje), tvorbu uživatelských sestav, monitoring událostí a vývojové nástroje pro doprogramování specifických funkcionalit.

22


Koncept architektury reportovacích a datově analytických systémů    

   

Klientské nástroje – nástroje pro vlastní analýzu dat (tj. zobrazení předpřipravených sestav a ad hoc analýzy). Administrační nástroje – nástroje pro administraci systému (přístupová oprávnění, sledování výkonnosti systému, správa obsahu, aj.). Serverové komponenty – centrální bod RDA systémů zajišťující zpracování uživatelských požadavků a vygenerování analytických výstupů. RDA data a metadata – data a metadata potřebná pro fungování RDA systému (tj. zejména metadata datové vrstvy, definice výstupních sestav, definice přístupových oprávnění, definice datových transformací, konfigurační data, archivované sestavy, aj.). RDA auditní data – logovací databáze obsahující záznamy aktivit vykonaných v systému. Zabezpečení – autentizační zdroj identifikující identitu uživatelů. Datová vrstva – data, která RDA systém využívá pro potřeby analýz. Externí systémy – systémy, které s RDA systémem spolupracují, nemají však vztah k jeho primární funkci (např. dohledové systémy nebo systémy, které přebírají obsah RDA systému).

Způsob vzájemné kooperace komponent: Klientské nástroje zasílají požadavky na analytické sestavy na serverové komponenty. Serverové komponenty zajišťují zpracování požadavku klienta tím způsobem, že využívají definice sestav a metadata uložené v RDA úložišti, získávají data z datové vrstvy, aplikují zabezpečení a provedou výpočet finálního výstupu, který poskytují klientovi. Vývojářské nástroje umožňují vytvářet metadata, která jsou ukládána do RDA úložiště. Jde především o definice analytických sestav, definice metadat datové vrstvy, případně i o definice procesů zpracování dat. Nástroje komunikují se serverovými komponentami, které jim umožňují pracovat s RDA úložištěm, při respektování zásad 8 zabezpečení, s možností využívat data datové vrstvy . Administrátorské nástroje obdobně jako vývojářské nástroje umožňují správu systému a konfiguraci prostředí, rovněž umožňují pracovat s daty v RDA úložišti.

5.1 Vývojářské nástroje V následujících kapitolách jsou analyzovány jednotlivé typy vývojářských nástrojů.

5.1.1 Metadata editor Moderní RDA systém by měl při vývoji sestav a tvorbě ad hoc dotazů umožňovat pracovat s tzv. metadatovou vrstvou, kdy sestavy a ad hoc dotazy nejsou vytvářeny přímým odkazováním se (dotazováním) na fyzickou datovou vrstvu, ale na vrstvu, která je budována nad touto fyzickou vrstvou, a která je odstíněna od implementačních

8

Je možný i jiný koncept, kdy vývojářské nástroje pracují přímo s RDA úložištěm a serverové komponenty nevyužívají. V takovém případě se však nejedná o integrované řešení, které by využívalo všech prostředků RDA systému a v rámci tohoto příspěvku není tento koncept diskutován. SYSTÉMOVÁ INTEGRACE 2/2013

23

Martin Závodný

charakteristik datové vrstvy (viz ilustrace na obr. 3). To s sebou nese výhodu spojenou s větší přenositelností vytvářených řešení v RDA systému, což je vysvětleno dále. Sestavy

Metadatová vrstva

Fyzická datová vrstva

Obr. 3: Napojení sestav na metadatovou vrstvu Metadata editor je nástroj, pomocí nějž jsou v rámci tzv. metadatového modelu definovány datové entity, postavené nad fyzickým modelem datové vrstvy, které mohou být využívány pro analýzu dat a pro tvorbu analytických sestav. Jednotlivé entity metadatového modelu se odkazují na fyzické entity datového zdroje nebo na již existující entity vytvářeného metadatového modelu. Pokud uvažujeme relační datový zdroj, jsou entity metadatového modelu definovány pomocí SQL dotazů do datového zdroje (metadatový model tedy obsahuje definici pohledů nad entitami fyzické vrstvy). Metadata editor může nabízet doplňující datové funkce pro datové kalkulace nad rámec funkcí dostupných v databázovém systému. V metadatovém modelu mohou být entity a vazby mezi entitami modelovány identicky na entity fyzické vrstvy nebo být modifikovány. Pokud tedy na úrovni datového skladu nejsou datové entity dostupné v požadované struktuře, lze vytvořit vrstvu entit až na úrovni metadatového modelu. Model může být dokonce budován nad více datovými zdroji, takže RDA systém může sloužit jako integrační vrstva, kdy ve stejném modelu lze spojovat entity z fyzicky různých datových zdrojů. Z pohledu výkonnosti systému je samozřejmě vhodnější připravit data do vhodné formy pro datové analýzy již na úrovni datové vrstvy, avšak v případech, že je nutné vývoj zabezpečit co nejrychleji, je možné úpravy struktury entit a vazeb a případnou datovou integraci dat z více zdrojů provést až na úrovni RDA systému. Metadatová vrstva je používána i pro přemodelování entit určených pro ad hoc dotazování. Technické názvy tabulek a sloupců fyzické vrstvy mohou být 24



přejmenovány na uživatelsky významově srozumitelnější názvy. Na úrovni metadat je rovněž možné řešit tzv. datovou bezpečnost datové entity, kdy na základě určité klíčové hodnoty obsažné v datech entity jsou danému uživateli vyfiltrovány jen ty záznamy, k nimž (resp. k jejich klíčovým hodnotám) má přiřazena oprávnění. Metadata je možné modelovat i vícejazyčně a uživateli nabízet příslušnou jazykovou mutaci metadat. Lze také nastavovat význam jednotlivých atributů entit (zda se jedná o faktový údaj, zda o atribut, aj.) a definovat defaultní způsob agregace atributu v sestavě. Snazší přenositelnost řešení je dána následujícími vlastnostmi metadatové vrstvy. Vrstva metadat obsahuje definici připojení do datového zdroje, ze kterého využívá datové entity. Pokud společnost potřebuje přepojit řešení na jinou databázi se stejnou strukturou datových entit, jako byla v původní databázi, stačí pouze změnit definici připojeni v metadatové vrstvě a řešení bude funkční. To je výhodné v případě, že společnost využívá odlišné vývojové a produkční databáze a potřebuje řešení vyvinuté na vývojové databázi přenést na produkční databázi. Dojde-li ke změně datové entity (např. změna názvu entity) ve fyzické vrstvě databáze a tuto entitu využívá více sestav, stačí upravit odpovídající entitu v metadatové vrstvě. Není potřeba měnit každou sestavu, která danou entitu fyzické vrstvy využívá, ale pouze změnit entitu v metadatovém modelu. U řešení obsahující v definici sestav přímo dotazy do datového zdroje by jakákoliv změna ve fyzické vrstvě sebou nesla potřebu upravovat sestavy. Metadatový model lze rozdělit na logické celky a dát k dispozici RDA systému jen jeho část. Metadatový mode je uložen v RDA úložišti tak, aby mohl být dostupný klientským nástrojům ro další využití.

5.1.2 Designer multidimenzionálních modelů Do RDA systémů mohou patřit nástroje pro tvorbu multidimenzionálních modelů, ze kterých jsou následně generovány OLAP kostky. OLAP kostky umožňují sledovat data potřebná pro rozhodování, tzv. ukazatele, ve vztahu k jejich relevantnímu kontextu, tzv. dimenzím. Například v rámci obchodní společnosti může být navržena metrika pro sledování tržeb přes dimenze čas, produkt a region prodeje. Dimenze může mít zároveň hierarchickou strukturu úrovní, např. dimenze času může mít strukturu: rok, měsíc, den. Přes hierarchickou strukturu dimenze je pak možno metriku analyzovat. Metrika musí mít definováno pravidlo pro agregaci detailních hodnot na hodnoty agregované. Podrobněji o konceptu fungování OLAP kostek viz např. (Thomsen, 2002). OLAP kostky se nejčastěji připravují nad modely typu hvězdicové schéma nebo sněhová vločka, viz (Kimball, Ross, 2002). Z pohledu dalšího výkladu je důležité u OLAP kostky rozlišovat její následující stavební prvky:  Metrika – výkonnostní ukazatel, který je v rámci OLAP kostky sledován (např. tržby).  Dimenze – pohled, přes který může být metrika nahlížena (např. čas).  Úroveň – agregační úroveň dimenze (např. měsíc v dimenzi čas).  Hierarchie – způsob seřazení úrovní v dimenzi (např. rok, měsíc, den).  Prvek dimenze – konkrétní datový prvek dimenze (např. rok 2012). SYSTÉMOVÁ INTEGRACE 2/2013

25

Martin Závodný 

Atribut – dodatečné informace k prvku dimenze (např. přestupný rok).

Mezi důležité funkcionality nástrojů pro tvorbu multidimenzionálních modelů patří:  Znovupoužitelnosti vytvořených dimenzí – možnost sdílení dimenzí napříč OLAP kostkami, již jednou vytvořená dimenze může být opakovaně použita ve více kostkách (typicky např. časová dimenze).  Vytváření atributů pro prvky v dimenzích – možnost, aby každý prvek dimenze obsahoval kromě názvu prvku i další atributy (např. identifikátor prvku, zkrácený název prvku, popis prvku a případné další názvové aliasy).  Vytváření podmnožin prvků dimenze – možnost v rámci dimenze vytvářet pojmenované podmnožiny, které obsahují vybrané prvky z dimenze (např. v časové dimenzi pro úroveň dnů vytvořit podmnožinu obsahující jen pracovní dny).  Vytvářet u dimenzí alternativní cesty – možnost přeskakovat při procházení hierarchie některé z úrovní.  Zabezpečovat data kostky přes prvky dimenzí – přiřazovat uživatelům a uživatelským rolím oprávnění přistupovat jen na některé prvky dimenzí (např. v dimenzi zachycující organizační strukturu společnosti nastavovat uživatelům oprávnění zobrazovat pouze jejich oddělení, apod.).  Optimalizovat odezvy dotazů nad kostkami – na základě statistik četnosti spouštěných dotazů uživatelů nad kostkou optimalizovat odezvy kostek.  Inkrementální aktualizace dat kostek – možnost přidávat do kostek nová data bez nutnosti přepočítávat data celé kostky.  Pravidla pro výpočet hodnot metrik při určité kombinaci dimenzí – možnost definovat pravidla, která ovlivňují zobrazované hodnoty metrik při určité kombinaci dimenzí.  Pojmenované sady prvků v dimenzích založené na dotazu – možnost vytvářet pojmenované sady prvků dimenzí pomocí dotazu (např. z časové dimenze vybrat posledních 12 měsíců a sadu pojmenovat jako Year to Date).  Virtuální kostky – možnost vytvářet virtuální kostky spojením dvou a více existujících kostek, spojení je realizováno přes sdílené dimenze, analýzy metrik poté mohou být prováděny právě nad sdílenými dimenzemi.  Možnost částečného nebo úplného generování prvků dimenze – z dimenzních číselníků je možno vygenerovat všechny prvky dimenze nebo pouze ty prvky, pro které jsou k dispozici faktové údaje. Technologicky jsou kostky realizovány především koncepty MOLAP, ROLAP, HOLAP, DOLAP, které jsou již dostatečně objasněny v literatuře, viz např. (Thomsen, 2002). V minulosti se uplatňoval především postup založený na dávkovém předpočítání agregovaných hodnot v OLAP kostkách. S tím, jak roste výkon výpočetních zařízení, se však začíná prosazovat koncept, kdy zpracování multidimenzionálních dat probíhá v paměti na serveru RDA systému a analýzy jsou počítány v reálném čase, viz např. (Plattner, Zeier, 2012). Jedná se o tzv. in memory analytiku.

5.1.3 Designer sestav Základním nástrojem RDA systémů je designer sestav, který umožňuje vytvářet předpřipravené výstupy pro koncové uživatele. Designer sestav může být rozčleněn 26



do více nástrojů specifických pro daný typ sestavy nebo se může jednat o jeden univerzální nástroj. Mezi základní typy sestav vytvářených v RDA systémech patří reporty, dashboardy a scorecardy. Sestavy mohou být klasifikovány podle mnoha kritérií. Například podle toho, zda umožňují interakci s uživatelem (tj. filtrování hodnot), zda obsahují detailní čí agregovaná data, zda obsahují aktuální nebo historická data, jaké úrovni řízení jsou reporty určeny, zda se jedná o reporty obsahující grafické prvky, zda obsahují zabezpečení na úrovni dat, zda jsou spouštěné nebo předgenerované, nad jakými typy datových zdrojů jsou postaveny, zda umožňují přechod z agregovaných dat na detailní (tzv. drillování) a další. Při vytváření sestav pracují vývojáři s metadatovou vrstvou nebo multidimenzionálními modely a na jejich základě vytvářejí předpřipravený výstup pro uživatele (viz kapitoly 5.1.1 Metadata editor a 5.1.2 Designer multidimenzionálních modelů). Designer sestav by měl vývojářům nabízet zejména následující funkcionality:  Matematické a statistické funkce pro práci s daty,  Umožňovat využití metadatové vrstvy při tvorbě obsahu sestavy,  Umožňovat přímé dotazování do datové vrstvy,  Obsahovat škálu grafických prvků a možností pro formátování výstupů,  Obsahovat řídící prvky pro filtrování dat a ovlivňování chování sestavy,  Podporovat základní výstupní formáty,  Umožňovat vytvářet vícejazyčné výstupy,  Možnost doprogramování prvků,  Možnost využívat předdefinované šablony sestav.

5.1.4 Monitoring událostí a notifikace Nástroj, pomocí nějž jsou vytvářena pravidla pro vyvolání události a na jejich základě notifikováni vybraní uživatelé. Událost je v RDA systémech vyvolána zejména změnou hodnot definovaných indikátorů a také na základě časové podmínky. Událostmi mohou být rovněž řízeny a spouštěny úlohy potřebné pro zpracování některých sestav.

5.1.5 Programovací prostředí Jedná se o sadu nástrojů, které umožní doprogramovat doplňkové funkcionality (tzv. SDK – Software Development Kit). Pomocí SDK je možné přistupovat k metadatům v RDA úložišti a upravovat je. To může být výhodné, pokud je potřeba provádět hromadné změny obsahu, případně získávat informace o obsahu RDA systému. Do RDA systému lze pomocí SDK integrovat externí programové komponenty.

5.1.6 ETL studio Některé RDA systémy obsahují vlastní ETL nástroje. Jedná se především o RDA systémy, které využívají in memory zpracování a data si z datové vrstvy načítají do paměti serveru. Data jsou odtud dále zpracovávána podle požadavků uživatelů. Při vývoji transformačních procesů v ETL nástrojích je potřeba řešit standardní otázky jako jsou návrh mechanismus načítání (inkrementální nebo plný), v případě inkrementálního načítání pak způsob aktualizace dat v cílových tabulkách, řešit


27

Martin Závodný

algoritmus transformace data a případně i kvalitu zdrojových dat. Podrobněji viz např. (Kimball, Caserta, 2004).

5.2 Klientské nástroje RDA systém se z pohledu uživatele jeví jako portálové řešení. Moderním trendem je implementace klientských nástrojů do podoby aplikace spustitelné přes webový prohlížeč. Na rozdíl od klienta instalovaného na stanici uživatele, není při využití webového klienta v případě upgrade systému potřeba přeinstalovat nástroj na klientských stanicích. Jako varianta rozhraní pro datové analýzy mohou být s výhodou použity také nástroje obsažené v rámci kancelářských balíků (např. pro ad hoc analýzy využít tabulkový kalkulátor). Je potřeba však zajistit jejich integraci s RDA systémem. RDA systémy mohou podporovat i off-line analýzy na klientských nástrojích, kdy data ze serveru jsou stažena na klientskou stanici a analýzy prováděny zde, bez nutnosti připojení k serveru (to je výhodné pro mobilní zařízení).

5.2.1 Prohlížeč sestav Uživatelé vybírají sestavy ze složek a spouštějí je v prohlížeči. Nástroj umožňuje prohlížení a změnu vstupních parametrů u předpřipravených sestav. Uživatelé mohou volit například jazykovou mutaci sestavy, výstupní formát, případně si sestavu zálohují do svých osobních složek. Prohlížeč sestav může být optimalizován pro různé typy koncových zařízení (mobilní zařízení, pracovní stanice, aj.). Častým požadavkem uživatelů je mít možnost komentovat obsah sestav a komentáře sdílet s ostatními uživateli.

5.2.2 Studio pro ad hoc analýzy Nástroj slouží k ad hoc analýzám, které jsou prováděny za využití metadatové vrstvy. Jeho funkcionalita se blíží funkcionalitě designeru sestav, s tím rozdílem, že ovládání je uzpůsobeno pro běžné uživatele (analytiky) nikoliv vývojáře. Je žádoucí, aby metadatová vrstva byla pro účely ad hoc analýz připravena do takové podoby, aby datové entity a jejich atributy měly pro uživatele srozumitelné názvy. Studio pro ad hoc analýzy může být koncipováno tak, že atributy metadatové vrstvy jsou uživatelem v sestavě nejprve uspořádány do finální podoby a teprve poté je sestava spuštěna a jsou do ní načtena data. Anebo je možno spouštět dotazy automaticky při každé úpravě podoby sestavy (uživateli se průběžně zobrazují data s tím, jak vytváří sestavu). Studio má podporovat pokročilé grafické zobrazování dat.

5.2.3 Studio pro multidimenzionální analýzy Studio pro multidimenzionální analýzy nabízí uživatelům, obdobně jako nástroj pro ad hoc analýzy, možnost vytvářet vlastní dotazy, avšak nad multidimenzionálním datovým zdrojem (OLAP kostkou).

5.2.4 Dashboard studio Zobrazuje klíčové reporty a ukazatele v rámci jednoho přehledového panelu. Uživatelé mohou využívat již předpřipravené dashboardy, případně si mohou vytvářet dashboardy vlastní (s využitím již existujících sestav). Důležitou vlastností dashboardu 28



je možnost ovládat prvky dashboardu jedním řídícím prvkem, tj. volit filtrační parametry na jednom místě. Studio může zahrnovat i funkcionalitu, která umožňuje uživateli modifikovat prvky dashboardu (měnit typy grafů, přidávat filtry, vytvářet nové prvky, aj.).

5.2.5 Scorecard studio Využívá se, pokud je žádoucí vytvářet výstupy v podobě tzv. scorecardů. Jedná se o sestavy, které zobrazují klíčové metriky a jejich vývoj v čase, zobrazují zároveň indikaci, zda se daný ukazatel vyvíjí žádoucím směrem či nikoliv (tj. pro metriky existují referenční hodnoty, podle kterých je posuzován pozitivní či negativní vývoj dané metriky). Tento typ analýz se provádí například v případě, že je v podniku nasazena metodika řízení Balance Scorecard, viz např. (Kaplan,, Norton, 1996).

5.3 Administrační nástroje Nástroje pro administraci RDA systému zahrnují funkce pro konfiguraci systému, umožňují přiřazovat uživatelům přístupová oprávnění, monitorovat výkonnost systému, spravovat obsah systému, spouštět a načasovat úlohy nezbytné pro zpracování sestav a další činnosti.

5.4 Serverové komponenty Serverové komponenty zpracovávají požadavky klientů. Jsou tvořeny aplikačním serverem, který provádí datové analýzy a výpočty obsahu sestav, dále webovým serverem v případě, že uživatelské nástroje podporují práci ve webovém prohlížeči. Volitelně se může vyskytovat komponenta datový server. Na datovém serveru jsou uchovávána data získávaná z datové vrstvy, avšak upravené do podoby vyžadované RDA systémem (například vygenerované OLAP kostky, data načtená ETL nástrojem RDA systému pro potřeby in memory analýz). Serverové komponenty mohou být sestavovány s ohledem na očekávanou zátěž systémů jako víceserverové. S tím jsou spojeny otázky řešení rozložení zátěže mezi jednotlivé servery a způsob řízení požadavku na víceserverovém prostředí.

5.5 RDA data a metadata RDA úložiště je klíčová komponenta RDA systému, která v sobě uchovává data potřebná pro chod systému a pro provádění datových analýz. Úložiště obsahuje citlivá data, proto by mělo být dostatečně zabezpečeno, například šifrováním svého obsahu. Základní oblasti dat, které RDA úložiště obsahuje, jsou následující:  Struktura portálu (hierarchie složek se sestavami),  Definice uložených sestav,  Archivované sestavy,  Metadata datové vrstvy,  Multidimenzionální modely,  Uživatelská oprávnění a případně i přístupové účty (pokud nejsou přebírány z autentizačního zdroje),  Konfigurace systému,  Definice datových transformačních procesů, SYSTÉMOVÁ INTEGRACE 2/2013

29

Martin Závodný

Pravidla pro vyvolání událostí, Naplánované úlohy. Pokud je potřeba provést kopii systému, stačí přenést obsah RDA úložiště z jednoho prostředí do druhého (např. z vývojového do testovacího prostředí). RDA úložiště je vhodné zálohovat, protože pokud dojde k jeho výpadku nebo poškození dochází k nefunkčnosti systému. Zálohu RDA úložiště je možno využít pro případnou obnovu systému.  

5.6 RDA auditní data Logovací databáze je komponenta, která zaznamenává aktivitu uživatelů RDA systému. S ohledem na architekturu, která je popisována v tomto příspěvku, je vhodné logovat přístupy uživatelů do RDA úložiště do jeho jednotlivých entit. Na základě logovací databáze je možno provádět monitorování systému a sledovat četnost přístupů uživatelů k sestavám a analytickým funkcím. Logovací databáze tedy může být použita také jako zdroj pro analýzy realizované RDA systémem.

5.7 Datová vrstva Datová vrstva je komponenta, ze které RDA systémy čerpají data pro své analýzy. Datová vrstva může být různorodá a tvořena více datovými zdroji (relační, objektové, multidimenzionální databáze, textové soubory a další). Je vhodné, aby RDA systém nebyl přímo napojen na databázi produkčního 9 informačního systému (tzv. primární datový zdroj ), ale na databázi z ní odvozenou 10 (tzv. sekundární datový zdroj ). Toto doporučení je vhodné respektovat zejména kvůli tomu, aby nedošlo činností RDA systému k přetížení databáze produkčního informačního systému a v důsledku toho k omezení jeho provozu. Mezi sekundární datové zdroje můžeme typicky zařadit komponenty datového skladu (viz datová vrstva na obr. 1), mohou sem však patřit také datové extrakty vytvářené z primárního datového zdroje. Datové analýzy prováděné v RDA systémech velmi často zahrnují časové hledisko (tj. zachycují vývoj určité metriky v čase). Z tohoto důvodu je potřeba mít pro RDA systém k dispozici dostatečně dlouhou historii dat z primárních datových zdrojů. Potřeba historizace dat primárního zdroje je obvykle řešena v rámci sekundárního datového 11 zdroje (např. datové tržiště, jádro datového skladu). Pokud však zdroj, na který je RDA systém napojen neobsahuje historická data, ale pouze aktuální snímek dat a je požadováno provádění časových analýz, je potřeba historizaci dat zajistit přímo v RDA systému. Tento přístup není architektonicky zcela správný, neboť RDA systém v takovém případě supluje roli datového skladu, pro kterou není primárně určen, a data uchovává ve svém datovém úložišti (RDA úložišti nebo datovém serveru). Řešení historizace je potom závislé na potřebách analytických aplikací a není tolik otevřené vůči jiným systémům. Nicméně z pohledu snahy o minimalizaci počátečních nákladů na vybudování prostředí, umožňující provádění datové analytiky, je výše uvedený způsob ospravedlnitelný. 9

Databáze prvního uložení nově vzniklých dat. Databáze obsahující data odvozená z primárního datového zdroje. 11 Mechanismy a algoritmy historizace jsou popsány viz např. (Inmon, 2005). 10

30



Tento případ je typický pro společnosti, které nemají prostředky budovat historizované datové úložiště a mají RDA systém připojen přímo na databázi produkčního informačního systému nebo například využívají sekundární datový zdroj obsahující pouze aktuální snímek dat produkčního informačního systému. RDA nemusí nezbytně provádět historizaci na úrovni detailních transakčních dat, ale na úrovni agregací dat odpovídajícím potřebám analytických výstupů (např. reportovacích sestav). Objem uchovávaných historických dat může být proto řádově menší než objem detailních dat z primárních systémů. Technologicky může být historizace v RDA systémech řešena více způsoby v závislosti na potřebách analytických výstupů (ukládání časových snímků sestav, inkrementální generování OLAP kostek, aj.), viz (Inmon, H. W. 2005). Podstatou je však princip snímkování zdrojových dat k určitému datu. Některé RDA systémy v sobě mohou zahrnovat dokonce datové úložiště (v obr. 2 – datový server) včetně vlastního ETL nástroje. Pokud je RDA systém připojen přímo na produkční informační systém, je vhodné, aby datové analýzy, které mají potenciál přetížit tento systém, byly prováděny dávkově, mimo provozní dobu daného produkčního informačního systému (např. generování OLAP kostek, generování sestav, apod.). To s sebou samozřejmě nese nevýhodu v podobě toho, že data v analýzách nejsou vždy zcela aktuální. Pocházejí-li data určená pro analýzy z více než jednoho zdroje, je vhodné integraci dat provést na úrovni datové vrstvy (tj. v datovém skladu). Není-li to z pohledu kapacit a nákladů možné, RDA systém by měl nabídnout možnost integraci provést a data z více i různorodých zdrojů propojit (viz kapitola 5.1.1 Metadata editor).

5.8 Zabezpečení Velice důležitým faktorem je zabezpečení obsahu RDA systémů. Uživatele je potřeba nejprve autentizovat. K tomuto účelu je vhodné využít existující podnikový autentizační zdroj a využít pro RDA systému tzv. single sign-on, kdy je uživatel automaticky přihlášen do RDA systému bez toho, aby byl dotazován na uživatelské jméno a heslo. V případě, že takový autentizační zdroj není k dispozici, je potřeba uživatele vytvořit a spravovat přímo v RDA systému. Takový přístup samozřejmě není ideální, protože se jedná o jednoúčelové řešení. Co se týče autorizace, pravidla pro přístup k obsahu a funkcím RDA systému jsou uchovávány v RDA úložišti a jsou spravovány přes administrátorskou konzoli RDA systému. Oprávnění k obsahu a funkcím RDA systému může být řešeno ve 3 základních úrovních:  Funkční bezpečnost – uživatel má oprávnění v RDA systému provádět jen určité činnosti (např. administrovat systém, provádět ad hoc analýzy, vytvářet reporty, analyzovat OLAP kostky a další).  Objektová bezpečnost – každý prvek obsahu, může mít nastaveno, zda k němu může daný uživatel nebo uživatelská role přistupovat, zobrazovat jej a případně jej měnit (např. právo zobrazit určitou sestavu, právo ukládat report do složky reportů, aj.).  Datová bezpečnost – pokud analytická sestava nebo datová entita určená k ad hoc dotazování zahrnuje určitou množinu dat, může být z této množiny danému uživateli zobrazena jen část dat (např. sestava zachycující prodeje výrobků nadnárodní společnosti může řediteli společnosti zobrazovat celkový stav prodejů, SYSTÉMOVÁ INTEGRACE 2/2013

31

Martin Závodný

regionálnímu manažerovi pak jen prodeje za jeho region). Technologie řešení datové bezpečnosti je naznačena v kapitole 5.1.1 Metadata editor.

5.9 Externí systémy Na RDA systémy mohou být napojeny další systémy, které z RDA systémů odebírají data nebo do nich naopak určitá data dodávají. Může se jednat například dohledové systémy nebo systémy, které přebírají obsah z RDA systému (intranet, ERP systémy, CRM systémy aj.).

6. Řešení vývojového, testovacího a produkčního prostředí Zajímavou otázkou související s konceptem architektury RDA systému je řešení prostředí pro vývojové, testovací a produkční činnosti. V zásadě se nabízejí dvě základní možnosti, jak k této otázce přistoupit: Budovat fyzicky oddělené instance RDA systému pro každé prostředí Pro každou instanci existuje vlastní RDA úložiště, přesuny obsahu mezi jednotlivými prostředími je potřeba řešit fyzickým přenesením části RDA úložiště z jedné instance na druhou. Zabezpečení je řešeno pro každou instanci zvlášť, jednotlivé instance mohou být napojeny na různé (nebo i shodné) instance datové vrstvy (vývojová, testovací a produkční databáze). Při upgrade systému je potřeba upgradovat každou instanci, což je pracnější, avšak upgrade lze testovat na vývojovém prostředí a teprve poté jej provést i na ostatních. Tento koncept je výhodnější z pohledu snazšího řízení přístupových oprávnění, vyžaduje však administraci každého z prostředí zvlášť. Využívat jednu instanci RDA systému pro všechna prostředí RDA úložiště je společné pro všechna prostředí. Obsah RDA systému je logicky rozdělen na obsah pro vývojové, testovací a produkční prostředí a pomocí systému oprávnění je každá část zabezpečena tak, aby byla přístupná jen žádoucímu okruhu uživatelů. Lze si tedy představit, že RDA systém obsahuje v jedné instanci sytému složky pro každé prostředí a tyto složky jsou zabezpečeny. Určitá sestava je tak v instanci RDA systému obsažena vícekrát (jednou ve vývojové složce, jednou v testovací, jednou v produkční). Co se týče přístupu do datových zdrojů, je vhodné, aby RDA systém umožňoval definovat logický název datového zdroje a pod tento logický datový zdroj vytvořit připojení pro jednotlivá prostředí (pro vývojovou, testovací a produkční datovou vrstvu). Každé připojení potom zabezpečit tak, aby jej mohl využít jen žádoucí okruh uživatelů. To umožňuje využívat u identických sestav v různých prostředích (složkách) stejné označení datového zdroje. Odpadá nutnost přepojovat sestavu při přenášení mezi prostředími na jiný datový zdroj. Tento systém vyžaduje náročnější správu přístupových oprávnění. Na druhou stranu nevyžaduje starost o více fyzických prostředí. Problematický může být upgrade, kdy pro případné testování postupu upgrade musí být vytvořeno dočasně ještě jedna instance prostředí.

32



7. Faktory determinující podobu RDA systému Mezi nejvýznamnější faktory, které je potřeba zvážit při volbě architektury patří následující:  Požadavek na aktuálnost dat – má vliv zejména na architekturu datové vrstvy. Požadavek na aktuální data vyžaduje většinou implementaci operační databáze nebo přímé napojení RDA systému na zdrojový informační systém (toto není u kritických systémů doporučováno z pohledu možnosti negativního ovlivnění výkonnosti informačního systému). Zpoždění dat může nicméně vzniknout i v rámci RDA systému, byť je datová vrstva připravena a obsahuje aktuální data. Některé sestavy jsou totiž zpracovávány s určitou periodicitou (jsou např. generovány měsíčně), tím rovněž může docházet ke zpoždění.  Počet uživatelských požadavků na obsah RDA systému – ovlivňuje kapacitní podobu serverových komponent a odezvu systému  Typy prováděných analýz – ovlivňuje, jaká studia a vývojářské nástroje musí RDA systém zahrnovat.  Zabezpečení systému – zda je potřeba řešit funkční, datovou a objektovou bezpečnost.  Požadavek na audit systému – má vliv na to, zda je využívána logovací databáze.  Otevřenost systému – zda je možno doprogramovat chybějící funkcionalitu.  Potřeba provádět datové transformace – zda je potřeba, aby RDA systém zahrnoval vlastní ETL nástroj.

8. Závěr V příspěvku byl prezentován obecný koncept aplikační architektury RDA systémů a analyzovány významné vlastnosti komponent těchto systémů, z pohledu funkcionality. Pozornost byla věnována především vývojářským a klientským nástrojů, neboť ty jsou z pohledu využití RDA systému klíčové. V souvislosti s těmito nástroji byl v článku objasněn princip fungování metadatové vrstvy a rozebrány možnosti pro zabezpečení datových analýz a sestav získávaných z RDA systémů. Prostor byl věnován také administrátorským nástrojům, serverových komponentám, RDA úložišti, logovací databázi a externím komponentám. Byly rovněž uvedeny faktory ovlivňující podobu RDA systému a představeny návrhy pro řešení vývojového, testovacího a produkčního prostředí. V rámci omezeného rozsahu příspěvku nebylo možno postihnout všechny komponenty RDA systémů v úplném detailu. Doplnění by mohlo být provedeno například pro oblast fungování serverových komponent, struktury obsahu RDA systémů, struktury dat RDA úložišť, provozních charakteristik RDA systémů a dalších. Příspěvek byl vytvořen s podporou grantu č. 20121061 Interní grantové agentury Provozně ekonomické fakulty České zemědělské univerzity v Praze.


33

Martin Závodný

Reference Bouman, R., van Dongen, J., 2009: Pentaho Solutions: Business Intelligence and Data Warehousing with Pentaho and MySQL. Indianapolis: Wiley. ISBN 978-0-470-48432-6 IBM, 2012: Cognos Business Intelligence – Administration and Security Guide [Online] Dostupné na: http://public.dhe.ibm.com/software/data/cognos/documentation/docs/en/10.2.0/ug_cra. pdf [staženo 10.12.2012] Inmon, H. W., 2005: Building the Data Warehouse. Wiley Publishing, Indianapolis. ISBN 0-7645-9944-5 Kaplan, R. S., Norton, D.P., 1996: The Balanced Scorecard: Translating Strategy into Action, Harvard Business Review Press. 1 ed., ISBN 978-0875846514 Kimball, R., Caserta, J., 2004: The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning, Conforming and Delivering Data. Wiley Publishing. 1 ed., ISBN 978-0764567575 Kimball, R., Ross, M., 2002: The Data Warehouse Toolkit – The Complete Guide To Dimensional Modeling. Wiley Computer Publishing, New York, ISBN 0-471-20024-7 Microsoft, 2010. SQL Server 2008 R2 Books Online [Online] Dostupné na: http://www.microsoft.com/en-us/download/details.aspx?id=9071 [staženo 10.12.2012] Novotný, O., Pour, J., Slánský, D., 2004: Business Intelligence – Jak využít bohatství ve vašich datech. Grada Publishing, Praha. ISBN 80-247-1094-3 Plattner, H., Zeier, A., 2012: In-Memory Data Management: Technology and Applications. Springer. 2nd ed. ISBN: 978-3642295744 SAP, 2009. BusinessObjects Enterprise Administrator's Guide [Online] Dostupné na: http://help.sap.com/businessobject/product_guides/boexir31/en/xi31_bip_admin_en.pdf [staženo 3.12.2012] Thomsen, E., 2002: OLAP Solutions: Building Multidimensional Information Systems. Wiley Publishing, 2nd ed., ISBN: 978-0-471-40030-1

JEL: L86, M15

34


Koncept architektury reportovacích a datově analytických systémů

Recommend Documents