Možnosti In-Memory reportingových nástrojů

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií

Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie

Možnosti In-Memory reportingových nástrojů DIPLOMOVÁ PRÁCE

Student

:

Bc. Lukáš Cígler

Vedoucí

:

doc. Ing. Jan Pour, CSc.

Oponent :

Ing. Martin Falta

2014

Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze které jsem čerpal.

V Praze dne 5. května 2014

........................... podpis

Poděkování Děkuji vedoucímu mé diplomové práce, doc. Ing. Janu Pourovi, CSc. za jeho odborné vedení, cenné rady, připomínky a pozornost, kterou mé práci věnoval. Dále bych chtěl také poděkovat Ing. Ondřejovi Hlavičkovi ze společnosti Menzies Aviation (Czech), s.r.o. za rady a připomínky k praktické části práce a čas, který mi s ochotou věnoval. Děkuji i společnosti Red Gate Software Ltd., za poskytnutí plné verze produktu SQL Data Generator 3.

Abstrakt Diplomová práce se zabývá in-memory zpracováním dat, jeho využitím v reportingu a oblasti Business Intelligence (BI) obecně. Hlavním cílem teoretické části práce je představit in-memory principy, poukázat na odlišnosti od zpracování dat na pevném disku a získat přehled možností, jak uplatnit in-memory technologii v řešení BI. Výstupem této části je analýza přínosů a nedostatků in-memory řešení, diskutovaných vždy z různých pohledů. Praktickou část diplomové práce tvoří výkonnostní benchmark, který srovnává výkonnost zpracování dat za použití principů in-memory a konvenčního zpracování dat na pevném disku. Srovnání použitých metod je realizováno v prostředí reportingových nástrojů QlikView a Reporting Services. Pro testování je použito několik vzorků dat, přičemž oba zmíněné nástroje při každém měření pracují se stejnými daty. V závěru kapitoly je uvedeno vyhodnocení testování, které obsahuje naměřené výsledky a diskutuje silné a slabé stránky obou principů zpracování dat. Samotný závěr práce diskutuje výhody a nevýhody in-memory zpracování dat a definuje klíčové otázky, které by si mělo vedení podniku položit před investicí do inovace současného řešení BI. Zároveň závěr obsahuje doporučení pro další možné rozšíření této práce.

Klíčová slova Business Intelligence, In-Memory zpracování dat, Reporting, QlikView, Reporting Services, Výkonnostní benchmark

Abstract Diploma thesis focuses on in-memory data processing, its use in reporting and Business Intelligence (BI) in general. The main goal of the theoretical part is to introduce the in-memory principles, highlight the differences from hard drive data processing and overview possible implementations of in-memory technology in BI solution. The output of this section is an analysis of advantages and disadvantages of in-memory solutions in various perspectives. The practical part of the thesis consists of the performance benchmark that compares the performance of data processing using the in-memory principles and conventional hard drive methods. The performance comparison is realized in the reporting tools environment, QlikView for in-memory approach and Reporting Services for hard drive based method. Several data sets are used for testing in both mentioned tools. End of the chapter provides the assessment of testing results and discusses the strengths and weaknesses of both principles of data processing. The conclusion of this work discusses the advantages and disadvantages of in-memory data processing and defines the key questions that company management should ask before investing in innovation of the present BI solution. Moreover the conclusion contains recommendations for possible further follow-up work.

Keywords Business Intelligence, In-Memory data processing, Reporting, QlikView, Reporting Services, Performance benchmark

Obsah 1

Úvod ................................................................................................................... 1 1.1 1.2 1.3 1.4 1.5

Vymezení tématu práce a důvod pro výběr tématu.......................................................1 Cíle práce a způsob jejich dosažení ...............................................................................2 Struktura práce ................................................................................................................2 Výstupy práce a očekávané přínosy ..............................................................................3 Předpoklady a omezení práce.........................................................................................4

2

Rešerše zdrojů .................................................................................................... 5

3

In-Memory BI ....................................................................................................... 7 3.1 Nástup 64bitových operačních systémů........................................................................7 3.2 Paměťové komponenty ...................................................................................................8 3.2.1 Pevný disk ...........................................................................................................9 3.2.2 Operační paměť ................................................................................................10 3.3 Databázové koncepty ....................................................................................................12 3.3.1 „Diskově založené“ databáze...........................................................................12 3.3.2 In-Memory databáze..........................................................................................12 Funkcionalita in-memory databázového systému ....................................................13 3.4 Přednosti a nedostatky in-memory principů v BI ........................................................15 3.5 In-memory v architektuře BI..........................................................................................16 3.5.1 Zdrojové systémy..............................................................................................17 3.5.2 Transformační (integrační) vrstva ...................................................................18 3.5.3 Datová vrstva ....................................................................................................18 3.5.4 Analytická vrstva...............................................................................................19 3.5.5 Prezentační vrstva ............................................................................................20 3.5.6 Vrstva oborové znalosti....................................................................................20 3.6 Závěr kapitoly .................................................................................................................23

4

Praktická úloha.................................................................................................. 25 4.1 Postup řešení praktické části .......................................................................................25

5

Použité prostředí ............................................................................................... 27 5.1 Hardwarové vybavení ....................................................................................................27 5.2 Softwarové nástroje .......................................................................................................28 5.2.1 SQL Server 2012 Enterprise Edition ................................................................28 5.2.2 SQL Server Management Studio......................................................................29 5.2.3 SQL Data Generator 3 .......................................................................................30 5.2.4 QlikView 11 ........................................................................................................31 5.2.5 SQL Server Reporting Services .......................................................................36

5.2.6 Process Explorer...............................................................................................37 5.3 Závěr kapitoly .................................................................................................................37

6

Realizace výkonnostního testu ........................................................................ 38 6.1 Vytvoření databázových instancí .................................................................................38 6.2 Generování dat ...............................................................................................................41 6.3 Testování v QlikView .....................................................................................................46 6.3.1 ETL proces ........................................................................................................47 6.3.2 Časová dimenze ................................................................................................51 6.3.3 Vytváření reportu ..............................................................................................51 6.3.4 Měření doby zpracování ...................................................................................54 6.4 Testování v Reporting Services....................................................................................55 6.4.1 ETL proces ........................................................................................................55 6.4.2 Časová dimenze ................................................................................................56 6.4.3 Vytváření reportu ..............................................................................................56 6.4.4 Měření doby zpracování ...................................................................................59 6.5 Vyhodnocení benchmarku ............................................................................................60 6.6 Závěr kapitoly .................................................................................................................63

7

Shrnutí analýzy jako vstup do modelu MBI ..................................................... 64

8

Závěr.. ................................................................................................................ 66

Terminologický slovník ........................................................................................... 68 Seznam literatury ..................................................................................................... 71 Seznam obrázků a tabulek ...................................................................................... 73 Seznam obrázků ..........................................................................................................73 Seznam tabulek ...........................................................................................................73

1 Úvod

1

1 Úvod Dnešní informační společnost je typická rostoucím objemem jak strukturovaných, tak nestrukturovaných dat. To je pochopitelně dané vývojem naší společnosti, její globalizací a masivní informatizací. Studie „Digitální vesmír“ od společnosti IDC uvádí, že objem dat se celosvětově každé dva roky více než zdvojnásobí (IDC, 2011). Při růstu objemu zpracovávaných dat jsme nuceni čelit a vypořádat se s požadavky na snižování rychlosti odezvy při jejich zpracování. Tyto nároky jdou paradoxně proti sobě. S rostoucím množstvím dat v podnicích se zvyšuje i složitost analýz, měření vlastní výkonnosti a komplexnost rozhodovacího procesu, který je velmi důležitý k prosazení se v dnešním silně konkurenčním tržním prostředí. S tímto faktem se musí dnes a denně vypořádávat snad všechny oblasti informačních technologií, Business Intelligence1 nevyjímaje. S nástupem 64bitových systémů a přetrvávajícím poklesem cen hardwarové infrastruktury (zejména operační paměti a procesorů) se otevřela cesta, jak zmiňovaným rostoucím nárokům vyhovět. Díky tomu se trendem posledních let v oblasti BI stalo ukládání komprimovaných dat a jejich zpracování přímo v operační paměti. Od toho je odvozen termín „in-memory BI“, jak již název této práce napovídá. In-memory technologie není pouze úzce zaměřené řešení pro zpracování velkých dat, ale v dnešní době může pokrývat komponenty na všech úrovních architektury BI, od práce nad daty lokální klientské stanice, až po analýzu několik TB velkého datového skladu, běžícího v paměti vzdáleného serveru. In-memory computing tak může výrazně snížit dobu mezi sběrem dat a jejich interpretací. Jaké možnosti tyto řešení nabízí? Jaký je rozdíl oproti konvenčním doposud hojně používaným řešením? Moje diplomová práce se těmito tématy bude zabývat a bude se snažit odpovědět nejen na zmíněné otázky.

1.1

Vymezení tématu práce a důvod pro výběr tématu

O oblast BI jsem se začal zajímat v době mého působení na bakalářském stupni studia Vysoké školy ekonomické v Praze. Už na Střední průmyslové škole elektrotechnické v Ječné ulici (obor počítačové systémy) mě oslovila oblast databází, kde jsem se seznámil s relačními databázemi, dotazovacím jazykem SQL a v praxi hojně využívaným prostředím MS SQL Serveru. Studium na VŠE mi v této problematice značně rozšířilo rozhled, a tak jsem se začal postupně ubírat směrem k oblasti BI. Se zájmem sleduji trendy v oblasti BI, novinky na trhu produktů a realizované projekty zejména u telefonních operátorů a bankovních institucí působících na trhu ČR. Díky tomu

1

Termín Business Intelligence se bude v práci nadále vyskytovat pod zkratkou BI

1 Úvod

2

jsem si vybral relativní novinku na trhu, in-memory reporting v oblasti BI, za téma své diplomové práce. Konkrétně jsem se rozhodl zaměřit na nástroj QlikView od společnosti Qlik (dříve též známá jako QlikTech). QlikView je jedním z nástrojů, které podporují právě zmiňované in-memory zpracování dat s možností jejich další analýzy včetně reportingu. Tématem této diplomové práce je dále i porovnání vybraných reportingových nástrojů na principu výkonnostního testování, které srovnává vysoce konvenční doposud využívané řešení s moderním in-memory nástrojem. Jako nástroj pro konvenční metodu zpracování dat jsem vybral Reporting Services na platformě SQL Serveru 2012 od společnosti Microsoft, který srovnávám s již zmiňovaným QlikView. Konvenční metodou se zde rozumí běžná metodu zpracování a analýza dat na pevném disku.

1.2

Cíle práce a způsob jejich dosažení

Tato práce si ukládá za splnění dva hlavní cíle. Prvním, převážně teoretickým, je uvedení čtenáře do problematiky in-memory zpracování dat a jeho principů využívaných v analýze a reportingu. Na začátku jsou zhodnoceny hlavní důvody rozvoje in-memory architektury spolu s jejím rostoucím nasazováním v praxi. Dalším krokem je poukázání na odlišnost od standardní architektury BI. Splnění těchto „dílčích“ cílů umožní diskutovat výhody a nevýhody in-memory řešení v oblasti BI. Pro představení a porovnání konkrétních nástrojů je tu druhý cíl, praktická část. Cílem praktické části je výkonnostní benchmark (výkonnostní porovnání) mnou vybraného konvenčního reportingového nástroje2 a nástroje využívajícího principů in-memory zpracování dat3. Praktická úloha testuje dobu odezvy při spouštění mnou připravených reportů nad čtyřmi různě objemnými instancemi databáze, které jsem předtím naplnil daty specializovaným, k tomu určeným nástrojem. Výkonnostní benchmark porovnává dobu odezvy v závislosti na objemu dat a principu zpracování dat testovaného nástroje. Testování je realizované v obou nástrojích nad stejnými vzorky dat.

1.3

Struktura práce

Struktura práce vychází z cílů, které jsem si stanovil a způsobu pro jejich dosažení (viz předchozí podkapitola). Práce je členěna do dvou hlavních částí, teoretické a praktické.

2

MS Reporting Services na platformě MS SQL Server 2012

3

Qlik QlikView 11

1 Úvod

3

První část předkládá čtenáři obecné principy in-memory zpracování dat. Pro uvedení problematiky do celkového kontextu práce je nejprve stručně uvedena historie vývoje systémů a hardwaru klíčového pro nástup in-memory technologie, jsou vymezeny základní pojmy a popsána architektura řešení BI. V dílčím závěru první části práce je představen koncept in-memory BI s poukázáním na výhody a nevýhody oproti standardnímu BI řešení. Druhá, praktická část je zaměřena na výkonnostní benchmark. Představuje hardwarové a softwarové vybavení použité k realizaci úlohy. Je zde uveden postup konfigurace použitých nástrojů, příprava dat, nad kterými jsou vytvářeny reporty a vlastní metoda testování. V závěru je uvedeno porovnání výsledků měření, diskuse nad těmito výsledky a samotný závěr této diplomové práce.

1.4

Výstupy práce a očekávané přínosy

Hlavním výstupem práce je přehledné grafické srovnání konvenčního a in-memory reportingového nástroje za použití metody výkonnostního benchmarku. Oproti doposud publikovaným srovnáním je fakt, že tato práce testuje zmiňované nástroje na lokální klientské stanici (laptopu), zatímco existující studie se zabývají především výkonností zpracování dat na vzdáleném serveru. To je v době, kdy zastoupení SME4 tvoří více jak 99,8 % z celkového podílu podniků EU (Veber, Srpová, 2012), významný fakt. Srovnání by mělo čtenáři pomoci odpovědět na otázku: „Jaká technologie je pro mě či mé zaměstnance za daných podmínek ideální?“ Výstup je určen zejména manažerům a majitelům nejen malých a středních podniků, ale i lidem se zájmem o problematiku in-memory computingu obecně. Mezi výstupy práce mohu zařadit i úvodní převážně teoreticky zaměřené kapitoly, které slouží jako faktický a terminologický rámec pro běžného čtenáře, který není v problematice natolik zběhlý. Navíc na výstupu přináší řadu pohledů, které jsou klíčové pro rozhodnutí, jak, případně zdali vůbec nasadit in-memory řešení do podniku. Taktéž kapitoly z praktické části, které se věnují jednotlivým použitým softwarovým nástrojům, mohou posloužit jako inspirace při rozhodování u vlastní práce (ať už aplikace pro generování „náhodných“ dat, které ocení lidé pracující s databázovými systémy, nebo vlastní testované reportingové nástroje). Jedním z výstupů je i formulář obsahující poznatky dosažené v této práci, který poslouží jako vstup do modelu MBI (Management Byznys Informatiky).

4

Zkratka SME – Small and Medium Enterprises (Malé a Střední Podniky)

1 Úvod

1.5

4

Předpoklady a omezení práce

Hlavním předpokladem pro tuto práci, zejména její praktickou část, je správné pochopení principů in-memory zpracování dat. Jen tak lze naplno využít jejich potenciál. Práce též předpokládá základní orientaci čtenáře v oblasti relačních databází a problematice BI. Omezení v teoretické části vidím v nemožnosti poskytnout čtenáři detailnější informace o in-memory zpracování dat po technologické stránce. Práce vzhledem k svému zaměření seznamuje s principy tohoto řešení, namísto aby analyzovala konkrétní technologii do hloubky. U praktické úlohy je hlavním omezením nedostupnost odpovídajících výpočetních prostředků pro realizaci výkonnostního testování (benchmarku). Další pro mě osobně podstatné omezení byla krátká doba k otestování nástrojů pro generování dat. U zvoleného RedGate Data SQL Generator 3.0 se jednalo pouze o 14 dní. Než se mi podařilo vše vyladit k maximální spokojenosti, tato doba vypršela a musel jsem kontaktovat zákaznickou podporu. Společnost RedGate mi však vyšla vstříc a poskytla mi licenční klíč pro aktivaci plné verze produktu. Sadu nástrojů SQL Server 2012 Enterprise Edition jsem měl k dispozici ke stažení na portálu Microsoft DreamSpark, kam mají přístup všichni studenti Katedry informačních technologií VŠE v Praze. QlikView je k dostání v desktopové části aplikace zdarma.

2 Rešerše zdrojů

5

2 Rešerše zdrojů Při zpracování této diplomové práce jsem vycházel z řady zdrojů. Ty bych dále rozdělil do skupin odborných publikací, závěrečných prací vysokých škol a dokumentací s tutoriály od výrobců softwarových nástrojů, se kterými v praktické úloze pracuji. Publikace Business Intelligence v podnikové praxi (Pour, Maryška, Novotný, 2012) představuje principy, technologické aspekty, podstatu BI a analytických aplikací obecně. Pomáhá pochopit, proč jsou analytické aplikace v podniku, potažmo informatice, stejně tak důležité jako transakční aplikace, ne-li důležitější. Kniha je skvěle organizovaná, od základních principů, přes ukázku modelování v konkrétním nástroji až nástin implementace. Pro tuto diplomovou práci však v knize chybí in-memory principy v hlubším detailu a může tak sloužit nezasvěceného čtenáře jako obecný úvod do BI. Rozsáhlý článek In-memory database systems (Steve Graves, 2002) představuje principy a základní koncepci in-memory databází. Popisuje hlavní rozdíly mezi klasickými „on-disk“ a in-memory databázemi, jejich výhody a omezení. Dále se zabývá hardwarovou infrastrukturou (klíčovými komponentami jejího řešení), která je pro efektivní provoz in-memory databází nezbytná. V závěru článku uvádí nejsilnější hráče na trhu in-memory řešení včetně silných a slabých stránek jimi vyvíjených softwarových produktů. Studie Big Data Analytics (Philip Russom, 2011) společnosti TDWI5 uvádí důvody pro nárůst objemu dat ve společnosti. Popisuje a pomáhá pochopit jejich charakteristiku i náležitosti strukturovaných a nestrukturovaných dat, které začínají převažovat nad daty strukturovanými. Hlavní částí studie je analýza podnikového prostředí, které cítí stále akutnější potřebu vypořádat se s velkými daty a vytěžit z nich co nejvíce ve svůj prospěch. V závěru dává doporučení, jakými přístupy a metodami toho dosáhnout. Studie Managing Big Data (Philip Russom, 2013) opět z archivu TDWI je navazující studií na předchozí studii Big Data Analytics z roku 2011. V úvodu opakuje podstatu velkých dat a jejich další nárůst v posledních letech. Oproti předešlému zdroji se již zaměřuje na konkrétní přístupy a vhodně zvolené technologie od předních světových dodavatelů jako je SAP, Oracle, Dell, Pentaho a další. Závěrem podává seznam nejlepších praktik a doporučení v oblasti správy velkých dat. Diplomová práce Petra Soukupa High-Performance Analytics (Soukup, 2013) na téma „Vysoce výkonné analýzy“ se zabývá problematikou velkých dat. Inspirující pro mě byla praktické část práce, kde autor provádí srovnání v rychlosti zpracování dat pomocí pevného disku a pomocí in-memory analýzy přímo v paměti. Testování probíhá na specializova-

The Data Warehousing Institute, je společnost zabývající se vzděláváním a výzkumem v oblasti BI a DWH. Sdružuje přední informatické odborníky, nejlepší praktiky, strategie, techniky a nástroje pro poskytnutí úspěšného řešení. Odkaz na portál: http://tdwi.org/ 5

2 Rešerše zdrojů

6

ném serveru. K práci mám jedinou kritickou připomínku. Autor uvádí rozmanitost zdrojových dat nad databází NorthWind. Bohužel nevyřešil příliš šťastně generování zdrojových dat, jelikož nastavil poměr záznamů v tabulce Orders (Objednávky) a Order Details (Detaily objednávky) striktně v poměru 1:1. V praxi to znamená, že by každá objednávka obsahovala pouze jednu položku z tabulky Products (Produktů). V praktické úloze, kterou autor realizuje, to nemá takový velký vliv, jelikož pro vlastní testování vytváří zvláštní tabulku s přesně vybranými sloupci celé databáze. Pokud by pracoval s výběrem dat z obou provázaných tabulek (např. výpočet příjmů za období z určitého produktu) viz praktická část mé vlastní práce, mohlo by dojít ke značnému zkreslení měření výkonu zpracování dat oproti reálným podmínkám v praxi. Další uvedené diplomové práce se zabývají nástrojem QlikView, jeho funkcionalitou, případně srovnáním s dalšími in-memory nástroji na trhu. Práce Tomáše Janoška Aplikace typu BI v podnikové praxi (Janošek, 2010) se věnuje funkcionalitě QlikView. Na hodnocení QlikView je zaměřena práce Tomáše Staška Tvorba dashboardov v nástroji QlikView (Staško, 2011) a srovnáním QlikView s dalšími nástroji na trhu se věnuje diplomová práce Martina Kopeckého Porovnání nástrojů pro Data Discovery (Kopecký, 2012), která též řeší a objasňuje problematiku velkých dat. Nemohu opomenout pro tuto práci tak podstatný zdroj informací, jako je kompletní manuál ke QlikView (Qlik, 2013) a webový portál Qlik6 komunity, kde lze nalézt mnoho návodů a video tutoriálů. Dalším zdrojem informací pro práci s nástroji použitými v praktické části, byla publikace Business intelligence v SQL Serveru 2008 : reportovací, analytické a další datové služby (Ľuboslav Lacko, 2009), která mimo jiné seznamuje s prostředím SQL Serveru. Pro další využití při testování však nedosahuje potřebného detailu popisu nástrojů. Zmíněný portál TDWI již řadu let publikuje čtvrtletník pod názvem BI Journal.

6

http://www.qlikcommunity.com/

3 In-Memory BI

7

3 In-Memory BI In-memory Business Intelligence je metoda pro analýzu dat, která v posledních letech zaznamenává značný rozmach. Koncept in-memory computingu přitom není nic nového na trhu informačních technologií. Tato myšlenka se objevila již před zhruba 30 lety. V té době ovšem nebyla proveditelná v širším měřítku, protože nebyly k dispozici 64bitové systémy. Před nástupem 64bitových operačních systémů, bylo maximální využitelné množství paměti necelé 4 GB, což sotva postačovalo na provoz nejjednodušších řešení BI. Postupem času se 64bit. systémy stávaly dostupnější i z hlediska hardwarové infrastruktury a tím se mohlo začít uvažovat o jejich masivním nasazování a zapojení do BI. Účelem této kapitoly je vysvětlit rozdíly mezi technologiemi diskového zpracování dat v kontrastu s in-memory principy, možnosti jejich nasazení v BI řešeních a následná diskuse silných a slabých stránek. Kapitola též představuje koncept in-memory databází a uvádí, jaké důvody vedly k jejich prosazení. Nejprve je však potřeba uvést čtenáře do problematiky in-memory principů s důrazem na odlišnosti od standardní „on-disk“ koncepce.

3.1

Nástup 64bitových operačních systémů

Co je to operační systém není potřeba rozepisovat. Co znamená označení x86 a x64 u operačních systémů? Jak to souvisí s tématem in-memory zpracování dat? Jakou návaznost má 64bitový systém na hardwarové možnosti běžně používaných zařízení? Účelem této kapitoly je na uvedené otázky odpověď. S rostoucím objemem dat roste i náročnost výpočtů nad těmito daty, zvyšuje se náročnost běžných aplikací a rychlost zařízení, která tyto data zpracovávají, s nimi musí pochopitelně držet krok. Před relativně nedávnou dobou začal masivní nárůst zastoupení 64bitových systémů, v domácnostech běžných uživatelů nevyjímaje. Jelikož 64bitové verze operačních systémů jsou historicky mladší než 32bitové, je zřejmé, že tato technologie procházela jistým vývojem. Mezi prvními znaky jejího příchodu byly změny u procesorů, kde se začala objevovat 64bitová alternativa. Všechny novější procesory jsou samozřejmě schopné pracovat i s 32bitovým operačním systémem (Kerner, 2007). Každý procesor obsahuje instrukční sadu. Ta se dá představit jako jakási sada nástrojů, díky kterým procesor dokáže pracovat s daty. U procesorů spočívá velká část činnosti v práci s adresami, které odkazují na data v operační paměti. Pokud je však procesor spojen s pamětí pouze 32bitovou sběrnicí, po které posílá jak adresy, tak také odebírá data, nezbývá mu nic jiného, než se omezit na tuto velikost. Označení x86 (32bit.) a x64 (64bit.) tedy vypovídá o sadě instrukcí, se kterou procesor pracuje a komunikuje s dalšími komponentami prostřednictvím zmíněného operačního systému.

3 In-Memory BI

8

První procesory 64bitové architektury vyvinula společnost AMD v roce 2001, ovšem jejich plná podpora vývojáři operačních systémů započala až v roce 2003. Masivní rozšíření do podnikové sféry i do domácností běžných uživatelů osobních počítačů se datuje ještě o několik let později (Kerner, 2007). Hlavní odlišností 32bitových a 64bitových operačních systémů tedy je maximální množství adresované operační paměti (RAM). Jak zjistit kolik operační paměti dokáže takový systém adresovat? Výpočet je triviální. Pokud je adresa v paměti dlouhá 32 nebo 64 bitů a každý bit má pouze dvě úrovně hodnot (0 nebo 1), dokáže systém adresovat pro: ● 32bit: 232 = 4 294 967 296 B (4 GB RAM), ● 64bit: 264 = 18 446 744 073 709 551 616 B (16 EB RAM),. Z výpočtu je zřejmá hlavní výhoda 64bitové architektury operačních systémů, kterou je téměř neomezené množství dostupnosti operační paměti. Dalším z důvodů rozšiřování in-memory computingu je rostoucí rychlost procesorů, které alokovanou operační paměť obsluhují. O zvyšování rychlosti procesorů hovoří všeobecně známý Morův zákon.

3.2

Paměťové komponenty

Obecně řečeno, dnešní počítače mají dva hlavní typy paměťových mechanismů. Pevný disk (HDD - Hard Disk Drive) a operační paměť (RAM - Random Access Memory). Mezi nimi jsou koncepčně významné rozdíly, které uvádí následující tabulka: Tabulka 1 - Klíčové vlastnosti HDD a RAM (Autor) Vlastnost

Pevný disk

Operační paměť

Paměťový prostor

velký

malý

Rychlost zpracování dat

pomalé

rychlé

Cena za 1 GB paměti

nízká

vysoká

Uložení dat v čase

dlouhodobé

krátkodobé

Tato kapitola má za úkol stručně, bez přílišného zaměření na technologické detaily popisovaných komponent, poukázat na hlavní rozdíly pevných disků a operační paměti počítače. Do diplomové práce je zařazena z toho důvodu, jelikož pevné disky a paměti jsou klíčovými komponentami v architektuře řešení BI.

3 In-Memory BI

3.2.1

9

Pevný disk

Pevný disk je zařízení, které se používá k trvalému, časově téměř neomezenému uchování dat. Pevné disky pracují na principu magnetického záznamu. Disk obsahuje kovové, keramické nebo skleněné plotny, nad kterými se z každé strany pohybuje čtecí a současně i zápisová hlava. Ta zajišťuje čtení a zápis dat. Organizace dat na disku je realizovaná pomocí stop, sektorů a cylindrů. Stopy jsou soustředné kružnice, které jsou očíslovány od stopy nejbližší vnějšímu okraji plotny. Každá stopa je rozdělena na sektory, které mají zároveň velikost nejmenší adresovatelné jednotky disku. Dnes je velikost sektorů nejčastěji 4096 bajtů, tedy 4 KB. Velikost alokační jednotky si ale může uživatel při formátování disku přizpůsobit podle svých potřeb. Cylindr je označení pro všechny stopy ploten, které jsou fyzicky umístěné nad sebou. Díky nim se hlavy pevného disku využívají rovnoměrně a disk má vyšší výkon. Proto se disk při zapisování neplní po plotnách, nýbrž po cylindrech, aby se průběžně využívaly všechny hlavy, jež jsou umístěny na jednom společném rameni, která drží čtecí hlavy disku (Peloušek, 2012). Operační systémy pracují s jednotkou označovanou jako cluster. Jednotlivé clustery v sobě shlukují určité množství sektorů, jejichž počet se může lišit v závislosti na použitém souborovém systému (NTFS, FAT32). Velikost clusterů je v určitém rozmezí volitelná, takže pokud uživatel často pracuje s malými soubory, jsou pro něho vhodnější clustery s menší velikostí, naopak k ukládání velkých souborů jsou vhodnější velké clustery. Současné HDD disponují jedním hlavním nedostatkem. Nevýhodou pevných disků je jejich mechanické řešení, které zapříčiňuje relativně pomalé přístupové doby k uloženým datům oproti jiným paměťovým komponentám. Toto omezení je dané fyzikálními vlastnostmi konstrukce disku, který musí pro čtení nebo zápis dat provést následující operace: ● vystavit hlavu na správnou pozici, ● počkat na utlumení rozkmitu hlavy způsobené její setrvačností, ● vyčkat na pootočení plotny do pozice, od které začne zápis nebo čtení dat. Z toho důvodu nelze do budoucna od HDD očekávat příliš velký nárůst výkonu. Tento problém řeší SSD (Solid State Drive) disky. Navíc disponují vysokým výkonem. Při zápisu a čtení dat se hodnoty zápisu mnohdy pohybují na hranici 300-550 MB/s v závislosti na ceně disku. SSD však zatím nedosahují takových kapacit, jako je tomu u HDD, což je pro velké objemy dat pochopitelně nežádoucí. S tím souvisí i zásadní nevýhoda SSD - jejich vysoká cena za 1 GB úložného prostoru v porovnání s korunovými, či dokonce haléřovými položkami u plotnových pevných disků. Vývoj průměrné ceny HDD v přepočtu na 1 GB úložného prostoru uvádí následující tabulka 2.

3 In-Memory BI

10

Tabulka 2 – Průměrná cena kapacity pevných disků (McCallum, 2013) Rok

Průměrná cena za 1 GB

2013

$0,05

2010

$0,09

2005

$1,24

2000

$11,00

1995

$1 120

1990

$11 200

1985

$105 000

1980

$437 500

Pro zvýšení bezpečnosti uložených dat se zejména na serverech v podnikové sféře používá technologie RAID (Redundant Array of Independent Disks), což je označení pro pole nezávislých disků s redundancí. Redundance znamená v tomto případě nadbytečná duplikovaná data. RAID umožňuje spojit několik fyzických disků v jeden logický disk, kde je jeden nebo více disků redundantních a data jsou stále dostupná i v případě, že jeden z disků v poli selže mechanickou nebo jinou poruchou. Snižující se cena pevných disků a stálé rozšiřování jejich kapacity vede k možnosti poměrně snadno uchovávat velké objemy dat, v takřka neomezeném časovém horizontu. Tím se dostáváme k dalšímu problému souvisejícím s velkým objemem dat, kterým je jejich zpracování.

3.2.2

Operační paměť

Operační paměť je na rozdíl od pevného disku energeticky závislá komponenta, určená pro dočasné uložení zpracovávaných dat a spouštěného programového kódu (vlastní aplikace). Operační paměť má mnohonásobně rychlejší přístupovou dobu k adresovaným datům, než pevný disk. Procesor může data adresovat přímo pomocí instrukční sady (viz kapitola 3.1). Strojové instrukce jsou adresovány pomocí instrukčního ukazatele a k datům se obvykle přistupuje pomocí adresace prvku paměti. Operační paměť je spojena s procesorem pomocí sběrnice. Protože dnešní procesory svým výkonem převyšují jakékoliv komponenty osobních počítačů i serverů, obvykle se mezi procesor a operační paměť vkládá malá a rychlá vyrovnávací paměť typu cache (procesory dnešní doby disponují integrovanou cache pamětí).

3 In-Memory BI

11

Většina dnešních moderních počítačů má padesátkrát až pětsetkrát více volného prostoru na pevném diskovém úložišti, než v operační paměti. Laptop, na kterém jsem realizoval výkonnostní benchmark (viz kapitola 4 - Praktická úloha) má 8 GB RAM a 500 + 120 GB volného místa na pevných discích. U serverů je tento poměr velmi flexibilně škálovatelný. Dalo by se říct, že téměř bez hranic, závislý pouze na finančních možnostech podniku, který o takové řešení má zájem. Čtení a zápis dat na pevném disku je mnohem pomalejší než provádění stejných operací nad stejnými daty v operační paměti. To je jeden z důvodů, proč 1 GB operační paměti vyjde z finančního hlediska přibližně 800krát až 1000krát dráž, než 1 GB volného místa na pevném disku. Tabulka 3 ukazuje historický vývoj ceny operační paměti, která zapříčinila dostupnost in-memory technologií. Tabulka 3 – Průměrná cena kapacity operační paměti (McCallum, 2013) Rok

Průměrná cena za 1 GB

2013

$5,5

2010

$12,37

2005

$189

2000

$1 107

1995

$30 875

1990

$103 880

1985

$859 375

1980

$6 328 125

Další důležitý rozdíl zmíněných paměťových médií je v tom, co se stane s daty, když je počítač vypnut. Data uložená na pevném disku nejsou ovlivněna a jsou k dispozici i po dalším zapnutí/restartu systému, ale data uložená v operační paměti se nenávratně smažou. To je důvod, proč i v in-memory computingu musí být data k dispozici na pevném disku, který slouží jako úložiště pro zdrojová data in-memory databází. Slabinu dočasného uložení dat v paměti řeší operační paměti typu NVRAM. NVRAM (Non-Volatile Random Access Memory) je označení pro energeticky nezávislé operační paměti. Obvykle se řeší jako statická RAM s přídavným záložním zdrojem napájení. Proto jsou tyto paměti schopné obnovit data po restartu systému. Na rozdíl od běžných řešení, kde se kombinuje pevný disk a klasická operační paměť, toto řešení nevyžaduje žádný pevný disk. Nicméně NVRAM zůstávají pro většinu uživatelů i nadále nedostupné, jelikož výrobní náklady této technologie jsou velmi vysoké.

3 In-Memory BI

3.3

12

Databázové koncepty

Cílem kapitoly je představit koncept klasických a in-memory databází, poukázat na jejich hlavní odlišnosti. Text by měl zároveň objasnit důvody, které vedly k průniku in-memory konceptu do řešení BI. Cílem kapitoly není pouze popsat problematiku in-memory databází, ale zároveň zhodnotit přednosti a nedostatky zmiňovaných konceptů. Oba druhy databází uchovávají data před jejich zpracováním na pevním disku. Nasnadě je tedy otázka, jaký je mezi nimi rozdíl. Klíčovou roli tu hraje zpracování dat. Zatímco u klasických databází jsou data zpracovávána na pevném disku, v in-memory databázích se nejprve musí data načíst do operační paměti a až poté je možné je analyzovat.

3.3.1

„Diskově založené“ databáze

Databáze na principu zpracování dat na pevném disku jsou navrženy tak, aby efektivně zapisovaly a vyhledávaly data na pevném disku. Princip těchto databází předpokládá, že se kompletní zpracovávaná data nevejdou do relativně malé operační paměti osobního počítače nebo serveru. Proto musí být navrženy tak, aby čtení dat z pevného disku bylo pokud možno co nejefektivnější. Výhodou diskových databází je takřka neomezený prostor pro ukládání dat. Nevýhodou naopak relativně pomalé operace s daty, které limituje rychlost pevných disků. Když se řekne tradiční řešení BI, každý si většinou vybaví systém správy relačních databází (RDBMS), kterým je například MS SQL Server, Oracle a mnoho dalších. Tyto systémy byly od počátku navrhovány pro práci s daty transakčních aplikací. To znamená zejména vkládání dat do databáze a aktualizace záznamů. Naopak provádět vysoce výkonné dotazování, výpočty, agregace a spojování dat je nad těmito systémy s velkým objemem dat pomalé a neefektivní. Jedná se o dva vzájemně se rozcházející cíle, které vyžadují zcela odlišný přístup k architektuře řešení BI. Proto nelze dosáhnout za použití jednoho přístupu efektivity u transakčních i analytických aplikací současně. Relační databáze jsou tak vhodné pro provoz transakčních aplikací, jako je ERP, CRM, SCM, webových stránek apod., kde jsou transakce často opakovány a měněny. Naopak nejsou příliš vhodné pro podporu analytických aplikací, které obvykle pracují s velkým množstvím dat při použití velmi složitých výpočtů.

3.3.2

In-Memory databáze

In-memory databáze pracují na zcela opačném principu, než klasické „on-disk“ databáze. Předpokládají, že mohou kompletní data databáze zpracovat v operační paměti a eliminovat tak pomalé přístupové doby k datům na pevném disku. To může být při velkých objemech dat problém. Je proto potřeba data komprimovat vzhledem k velikosti dostupné

3 In-Memory BI

13

operační paměti. Komprese dat je zjednodušeně řečeno zpracování dat, za účelem zmenšení jejich objemu, ovšem za předpokladu současného zachování informací v datech obsažených (Graves, 2002). Výhodou in-memory databází je tedy mnohem vyšší rychlost zpracování dat. Nevýhodou pak nutnost načíst data do operační paměti předtím, než se vůbec mohou jakkoli analyzovat či zpracovávat pro další účely. In-memory databáze současně používají jinou logiku vnitřní struktury uspořádání dat. Klasický model relačních databází ukládá data do řádků jednotlivých tabulek a je vhodný pro zmíněné transakční aplikace. Pro in-memory databáze je ovšem výhodnější „sloupcový model“, který pro analytické aplikace pracuje s celými sloupci a provádí v nich nejrůznější agregační funkce. To je dáno často se opakujícími hodnotami ve sloupcích tabulky. Ze stejného důvodu je možné používat pro in-memory databáze vysoký kompresní poměr dat. Tohoto principu využívá např. platforma QlikView, se kterou pracuji v praktické části práce. Zmíněný princip se též nazývá jako asociační přístup. Jednoduše řečeno se mezi souvisejícími datovými položkami vybudují při načítání dat do databáze ukazatele, které na data odkazují. Pokud je pak v databázi více redundantních záznamů, ukazatele zabírají v paměti výrazně menší datový objem než samotná data. Díky tomu in-memory databáze výrazně urychlují vyhledávání a zpracování dat (Graves, 2002).

Funkcionalita in-memory databázového systému Základní principy funkcionality in-memory databázových systémů přibližuje text níže. Zároveň klade důraz na odlišnosti oproti klasickým databázím (Graves, 2002). Ukládání dat do mezipaměti (Caching) Vhledem k nízkému výkonu konvenčních diskových databází způsobeným přístupem k pevnému disku, používá většina běžných systémů pro jejich správu ukládání dat do vyrovnávací paměti (cache). Caching zahrnuje synchronizaci dat do vyrovnávací paměti, která zajišťuje, že obraz stránky databáze v paměti cache je v souladu se stránkou fyzickou databáze na disku. Cache vyhledávání také určuje, která data požadované aplikace jsou načtena do vyrovnávací paměti. V případě jejich potřeby jsou tak připravena k použití pro budoucí zpracování. Díky tomuto principu se eliminují nároky na výkon operační paměti, jelikož částečnou funkci v procesu zpracování dat zde zastane procesorová jednotka. Přenos dat V konvenčním databázovém systému, před zpracováním dat pomocí libovolných aplikací, je nutné tyto data nejprve načíst z pevného disku. Tento proces podrobněji znázorňuje následující obrázek 1.

3 In-Memory BI

14

Obrázek 1 – Tok dat v konvenčním databázovém systému (Graves, 2002)

Plné šipky představují tok dat, zatímco přerušované šipky požadavky na data. 1) Aplikace pošle databázi7 požadavek na libovolný datový záznam skrze svoje aplikační rozhraní. 2) Databáze dá souborovému systému pokyn k načtení dat z pevného disku. 3) Souborový systém vytvoří kopii těchto dat, odešle je do vyrovnávací paměti a předá další kopii dat databázi. 4) Databáze si ponechá jednu kopii dat ve vyrovnávací paměti a další pošle aplikaci. 5) Aplikace zpracuje obdržená data a předá je databázi prostřednictvím aplikačního rozhraní. 6) Databáze zkopíruje upravená data do vyrovnávací paměti, které jsou následně zapsány do souborového systému. Ten je opět připraví do cache. 7) Data jsou konečně zapsána zpět na pevný disk, jakožto fyzické paměťové médium. Výše uvedený princip platí pro konvenční „on-disk“ databáze. In-memory databáze fungují na zcela odlišném principu. Jednoduše řečeno, in-memory databáze při zpracování dat nevyužívají jakýkoliv přenos dat mezi operační paměti a pevným diskem (mimo načítá kom-

7

Database Runtime je velmi obtížně přeložitelný termín. V praxi vykonává činnost obslužného správce databáze, který řídí primárně vstupní požadavky aplikací a výstupní požadavky na odeslání požadovaných dat.

3 In-Memory BI

15

pletních dat do paměti), který by snižoval spotřebu kapacity operační paměti. Používá se zde ukazatel přímo na data v paměti (viz kapitola 3.3.2). Zpracování transakcí Aby se zabránilo fatální ztrátě dat například při výpadku elektrické energie, využívají konvenční databázové systémy transakční log soubory, které jsou při zpracování dat uložené ve vyrovnávací paměti a po proběhnutí transakcí jsou uloženy na pevný disk. V případě výpadku systému se tak dají obnovit některá ztracená data, jelikož jsou o nich uvedené záznamy ve zmiňovaných log souborech. V praxi se ovšem log soubory uchovávají pouze omezenou dobu (např. několik hodin, maximálně dní). Poté se ztráta dat řeší zálohováním kompletní databáze nebo její části v závislosti na objemu dat. Obdobně v in-memory databázových systémech se používají log soubory. Jejich využití je ale značně krátkodobější. Při zpracování transakce se začne vytvářet log soubor, který bokem ukládá obraz zpracovávaných dat. Po úspěšném dokončení transakce je ihned smazán. V opačném případě, kdy je transakce z jakéhokoli důvodu přerušena, se ukládaný obraz dat obnoví zpátky do in-memory databáze. Největším rozdílem mezi „on-disk“ a in-memory databázovými systémy je fakt, že při fatálním selhání systému jsou veškerá data v paměti ztracena. Tento problém řeší již jednou zmiňované operační paměti typu NVRAM (viz kapitola 3.2.2).

3.4

Přednosti a nedostatky in-memory principů v BI

In-memory BI je oblastí business intelligence, která těží z technologie in-memory databázových systémů (IMDB), které byly vyvinuty pro splnění rostoucích požadavků na výkonnost informačních systémů. Nazývají se též main-memory databázové systémy (MMDB). In-memory řešení BI pracují na zcela odlišném principu než tradiční řešení. Jak již bylo zmíněno v podkapitole zabývající se odlišnostmi klasických a in-memory databází (3.3.2), in-memory řešení potřebuje načíst kompletní soubor dat do operační paměti, kde jsou data následně zpracovávána (Graves, 2002). Tím odpadá doba potřebná pro přístup k datům na pevný disk a získání výkonnostní výhody, jelikož zpracování dat v paměti je řádově rychlejší než na pevném disku. Výhody a nevýhody řešení konvenčních diskových principů oproti in-memory principům jdou proti sobě. Pomalé zpracování téměř neomezeného množství dat na pevném disku, proti rychlému zpracování omezeného množství dat v operační paměti. To jsou dva klíčové úhly pohledu, které by měli BI analytici při výběru nejvhodnějšího řešení brát v potaz. Bez ohledu na výkon takového řešení se naskýtá zásadní problém. Tím je omezená kapacita operační paměti. První možností pro řešení takového problému může být výběr pouze

3 In-Memory BI

16

nejaktuálnějších dat, která budou do analýzy vstupovat. Takový přístup má však za následek efektivitu kompletního řešení BI, jelikož bez kompletních dat a dlouhodobějších historických údajů se nedocílí požadované vypovídacích schopnosti informací pro další rozhodování. Druhou možností je vypořádat se s kapacitním omezením operační paměti přímo, jejím rozšířením. To je dnes možné díky existenci 64bitových systémů, které dokážou obsluhovat téměř neomezené množství RAM. Pro taková řešení se před několika lety začaly konstruovat servery, které měly k dispozici 2-4 TB operačním paměti. V dnešní době jsou k dostání zařízení pro in-memory computing, která disponují 32 nebo 64 TB operační paměti. Taková řešení nejsou rozhodně levnou záležitostí. Jejich cena se včetně nasazení v podniku pohybuje řádově v desítkách milionů Kč. (Oracle, 2014) Je důležité si uvědomit, že potřebná velikost operační paměti se neodvíjí jen od množství zpracovávaných dat, ale také od počtu současně připojených uživatelů k systému. Škálovatelnost hardwaru se tak stává další z klíčových záležitostí pro úspěšné nasazení řešení BI v podniku. Opět je potřeba si uvědomit, že se zvyšováním výkonnosti hardwaru jeho cena exponenciálně roste. Dalším klíčovým omezením in-memory řešení je absence trvalého uložení dat v paměti. Jelikož se data v paměti na rozdíl od pevného disku okamžitě smažou při restartování zařízení či odpojení od zdroje elektrické energie, je potřeba je do operační paměti znovu nahrát (Graves, 2002). Během této doby není možné server využívat k výpočetnímu výkonu. To je třeba mít na paměti a provádět údržbu serverů plánovaně mimo špičky. Jak již bylo zmíněno v kapitole 3.2.2, existují i operační paměti typu NVRAM, které umožnují trvalé uložení dat přímo v operační paměti. Tyto řešení nabízí např. společnosti Oracle, nebo SAP s jejich in-memory platformou SAP HANA. Uvedená řešení jsou však zatím cenově velmi nákladná (SAP, 2014).

3.5

In-memory v architektuře BI

Cílem kapitoly je představit možnosti architektury BI, integraci in-memory platformy do stávajícího konvenčního řešení BI a plnohodnotné in-memory BI. Součástí textu je zhodnocení výhod a nevýhod, které jednotlivé řešení nabízí. Před samotným představením architektury BI je vhodné nejprve pojem definovat. Termín BI definuje řada autorů velmi různorodě. Pro potřeby této práce jsem zvolil následující definici, která vymezuje BI jako: „Business Intelligence je sada procesů, aplikací a technologií, jejichž cílem je účinně a účelně podporovat rozhodovací procesy ve firmě. Podporují plánovací a analytické činnosti podniků a organizací a jsou postaveny na principech multidimenzionálních pohledů na podniková data (Novotný et al., 2005).“

3 In-Memory BI

17

Obrázek 2 – Obecná koncepce architektury BI (Novotný et al., 2005)

Uvedená definice nahlíží na BI z technologického i manažerského pohledu. Pro tuto kapitolu je podstatný především technologický náhled. Obrázek 2 znázorňuje obecnou koncepci architektury BI z pohledu jednotlivých vrstev. Následující kapitoly popisují jednotlivé vrstvy architektury podle (Novotný et al., 2005).

3.5.1

Zdrojové systémy

Podle výše zmíněné definice, slouží BI ke zpracování a analýze stávajících podnikových dat, ze kterých vyvozují nové užitečné informace. Proto se za nejnižší vrstvu BI řešení označují zdrojové systémy. Ty v ideálním případě uchovávají podniková data obsažená v provozních informačních systémech, která vznikají po celou dobu existence podniku. Mezi zdrojové systémy se nejčastěji řadí systémy typu ERP, CRM, SCM, webové aplikace, sešity Excelu a mnoho dalších (viz obrázek 2). Uvedené systémy se též nazývají jako transakční systémy a slouží pro podporu denního provozu podniku. Pro potřeby efektivního využití BI je žádoucí, aby do další analýzy nevstupovala ze zdrojových systémů veškerá podniková data. Podniky zaznamenávají obvykle mnoho nepotřebných dat, bez ohledu na jejich datovou kvalitu. Proto je na této nejnižší vrstvě naprosto

3 In-Memory BI

18

klíčová analýza zdrojových systémů podniku a výběr pouze těch dat, která jsou z pohledu vedení podniku podstatná.

3.5.2

Transformační (integrační) vrstva

Tato vrstva při implementaci řešení BI plynule navazuje na nejnižší vrstvu zdrojových systémů. Jejím úkolem je vybrat, načíst, transformovat a uložit data z primárních systémů k dalšímu zpracování. Základními prvky této vrstvy nástroje ETL8 a EAI9. ETL systémy obecně slouží k extrakci, transformaci a přenosu dat mezi dvěma či více systémy. ETL též bývá označováno jako datová pumpa a patří k nejvýznamnějším komponentám celého BI. Při ETL procesu se získávají data ze zdrojových systémů (Extraction), upravují se po požadované formy pro cílovou datovou základnu (Transformation), do níž se následně nahrají (Loading). Nástroje ETL pro potřeby BI tedy slouží k přenosu dat ze zdrojových systémů do datové vrstvy řešení BI. Přenášejí data v určitých naplánovaných intervalech (např. den, týden, měsíc) a pracují v dávkovém režimu. Systémy označované jako EAI na rozdíl od ETL přenášejí data v reálném čase. Jsou určeny pro integraci podnikových aplikací. Jejich využití pro potřeby BI spočívá v tom, že změny v datech produkčních systémů se okamžitě projeví i v datové základně BI. Díky tomu je možné používat datové sklady v reálném čase. Není tak potřeba provádět nahraní dat, které zatěžuje systémy na obou stranách procesu. Obecně však pracují systémy EAI na dvou úrovních: ● na úrovni datové integrace, kde slouží pro integraci a distribuci dat mezi systémy podniku, ● na úrovni aplikační integrace, kde jsou využity nejen pro integraci a distribuci dat, ale zároveň pro sdílení vybraných funkcí podnikových systémů, čímž výrazně redukují počet použitých aplikačních rozhraní.

3.5.3

Datová vrstva

Jak již název datové vrstvy napovídá, slouží k ukládání dat získaných ze zdrojových systémů. Základními komponentami této vrstvy jsou datový sklad a datové tržiště. Dalšími ne vždy využívanými komponentami jsou potom dočasné úložiště dat a operativní úložiště dat.

8

Extract, Transform, Load

9

Enterprise Application Integration

3 In-Memory BI

19

Datový sklad (DWH – Data Warehouse) je hlavní komponentou této vrstvy, ne-li celého řešení BI. Jeho účelem je uchování dat pro podporu rozhodování managementu podniku. K tomu musí splňovat určité kritéria: ● Stálý – data jsou načítána z různých vstupních datových zdrojů, operativních databází a existují v DWH po celou dobu jeho existence. Uložená data jsou zde dostupná pouze v režimu čtení, což znamená, že DWH nefunguje jako databáze transakční aplikace a není tyto data možné měnit běžnými uživatelskými nástroji. ● Integrovaný – ukládají se zde data v rámci celého podniku. ● Subjektově orientovaný – data jsou zde ukládána podle jejich typu, nikoliv podle aplikací, ve kterých byly pořízeny. ● Časově rozlišený – uložená data musí nést informaci o dimenzi času (ať už přirozenou, či umělou). Díky tomu je možné provádět analýzy dat v určitých obdobích. Datové tržiště (DM – Data Mart) funguje na obdobném principu jako datový sklad. Klíčový rozdíl je pouze v tom, že DM je určený pro omezený okruh uživatelů. V praxi to může být např. oddělení společnosti nebo určitá divize výrobního podniku. DM vznikají často jako decentralizované datové sklady, které se časem integrují do celopodnikového řešení. Často také mohou pomoci pro pokrytí daného okruhu uživatelů (vyřešení určitého problému podniku), ve chvíli, kdy není možné čekat nebo investovat do vývoje centrálního datového skladu. Dočasné úložiště dat (DSA – Data Staging Area) slouží pro dočasné uložení extrahovaných dat z produkčních systémů. Jeho využití je efektivní zejména v řešeních s nadměrně zatíženými produkčními systémy, u kterých je při přesunu dat potřeba minimalizovat propad jejich výkonnosti. Data jsou tak z DSA po transformaci odstraněna a DSA je opět připraveno pro zpracování další dávky dat z produkčních systémů. Operativní úložiště dat (ODS – Operational Data Store) je ne vždy využívanou komponentou řešení BI. Jeho primárním účelem může být sběr a sledování aktuálních dat zdrojových systémů ihned po jejich zpracování. Ty mohou být poté odeslána do datového skladu. Předností tohoto přístupu je fakt, že data jsou téměř ihned k dispozici pro další zpracování. Druhou možností je použití ODS jakožto podpůrného datového skladu, ve kterém jsou prováděny jednoduché analýzy nad relativně malým množstvím dat (pouze aktuální snímek dat).

3.5.4

Analytická vrstva

Analytická vrstva slouží k provádění výpočtů a odvozování nových znalostí. Základním předpokladem pro její fungování je zpracování podnikových dat, které se pro tyto účely připravily na nižších vrstvách.

3 In-Memory BI

20

Hlavní komponentou analytické vrstvy je reporting, který je zároveň i stěžejním prvkem této diplomové práce. Reporting, se pro další potřeby porozumění textu, může definovat jako dotazování do analytických databází pomocí jejich standardních rozhraní. Dá se dělit na dvě skupiny: ● Standardní reporting – předpřipravené dotazy spouštěné v předem nastavených časových periodách, ● Ad-hoc reporting – jednorázové dotazy formulované uživatelem, které přinášejí odpovědi na specifickou otázku. Výsledné reporty jsou uživateli k dispozici v následující prezentační vrstvě. Podstatnou součástí analytické vrstvy řešení BI jsou i OLAP databáze (On-Line Analytical Processing). Jedná se o multidimenzionální databáze určené k dotazování nad souhrnnými daty. Jsou optimalizované pro vysoký výkon analytických aplikací, k čemuž obsahují již souhrnná data v jednotlivých sledovaných dimenzích. Dalšími nástroji, o kterých je potřeba se zmínit, jsou nástroje pro Data mining (dolování dat z databází). Jedná se o velmi specifickou disciplínu využívající informatických, matematických a statistických funkcí (algoritmů). V dnešní době se používají většinou pro analýzy prediktivního charakteru, např. tržní chování cílových skupin zákazníků. Pro tuto práci jsou však nástroje data miningu téměř nepodstatné a postačí v této vrstvě jen uvést jejich existenci.

3.5.5

Prezentační vrstva

Pomocí specializovaných aplikací zajišťuje komunikaci koncových uživatelů podniku s ostatními komponentami řešení BI. Mezi nejpodstatnější patří sběr požadavků na analytické aplikace a následná prezentace výsledků těchto analýz. Kvalita prezentace a vizualizace informací ve finále rozhoduje o efektivitě kompletního řešení BI. Mezi aplikace prezentační vrstvy dnes patří nejrozšířenější specializované nástroje, které slouží pro tvorbu a zpřístupnění reportů pro uživatele. Dále jsou hojně využívány webové portály, díky kterým uživatelé přistupují ke svým reportům přes rozhraní webového prohlížeče, nebo mobilního zařízení.

3.5.6

Vrstva oborové znalosti

Zahrnuje oborovou znalost uživatelů řešení BI, podnikové know-how a tzv. best-practices nasazování řešení BI pro konkrétní situaci v organizaci. Tato vrstva není na první pohled viditelná, ale je nesmírně důležitá pro úspěšnou implementaci řešení BI a jeho další úspěšný provoz v podniku.

3 In-Memory BI

21

Integrace in-memory platformy do řešení BI

Obrázek 3 – Hybridní koncepce architektury BI (Hlavička, 2012)

Hybridní koncepce architektury BI (viz obrázek 3) obsahuje, na rozdíl od klasické architektury, komponentu in-memory databáze. Jak již název této práce napovídá, jedná o klíčovou komponentu moderních in-memory řešení BI. Velmi zjednodušeně se dá její funkcionalita přirovnat k OLAP databázi s mnohem vyšším výkonem při zpracování dat a za použití odlišných principů pro práci s daty. Použité přístupy v in-memory databázích a důvody pro její integraci do architektury BI zhodnocují kapitoly 3.3 a 3.4. Výhody takového řešení uvádí následující body. ● Zvýšení rychlosti zpracování dat – in-memory databáze se jednoznačně hodí pro zpracování většího množství dat nebo pro složitější analýzy nad těmito daty. Při použití kombinace výhod datového skladu, in-memory databáze, případně datových tržišť, mohou být některá data a operace nad nimi přeneseny právě do in-memory databáze. Ta díky své hlavní přednosti značně zvýší výkon kompletního řešení BI. ● Odstínění zátěže vedlejších i zdrojových systémů – tento bod úzce souvisí s předchozím. Různé systémy disponují různou dobou odezvy, která se navíc mění se stupněm zátěže těchto systémů. Přidáním komponenty in-memory databáze do řešení BI, se tak značně odlehčí zátěž vedlejších systémů, včetně systémů zdrojových. ● Možnost nastartovat proces zlepšení datové kvality – dostupnost informací je základním předpokladem datové kvality. Díky zvýšení výkonnosti analýzy dat

3 In-Memory BI

22

uživatel získá informace v požadovaném čase (nebo alespoň výrazně aktuálnější informace). Nevýhodou hybridního řešení je nutnost aktualizace dat in-memory databáze. Při kombinaci standardního s in-memory řešením BI se předpokládá, že in-memory databáze bude sloužit jako podpůrný prostředek ke zvýšení výkonu řešení BI jako celku. Aktualizaci dat je v takovém případě ideální řešit v závislosti na zatížení primárních systémů. To znamená spouštět aktualizaci dat v noci, mino špičku, nebo několikrát denně přes systém centrálního „schedulingu“.

Obrázek 4 – In-memory koncepce architektury BI (Hlavička, 2012)

Kromě výhod uvedených u hybridního řešení BI, poskytuje kompletně in-memory řešené BI následující přínosy. ● Jednodušší provoz a údržba systému – Jelikož analytické aplikace pracují nad obrovským množstvím dat, vyžaduje se od nich vysoký výpočetní výkon. S kompletním in-memory řešením není již potřeba složitě budovat architekturu BI po výše uvedených vrstvách (nákup HW, SW, implementace, integrace aplikací a dat, ladění systému). In-memory řešení je možné získat od jediného dodavatele v mnohem kratším čase a tím snížit náklady na provoz a údržbu systému. Pokud je údržba systému v kompetenci interních zaměstnanců podniku, je na první pohled patrné, že koncepce této architektury je značně jednodušší než obecná a hybridní architektura BI (viz srovnání obrázků 2, 3 a 4).

3 In-Memory BI

23

● Masové rozšíření BI – Díky jednoduššímu nasazení, nárůstu výkonu i novému typu BI aplikací postupně dojde k postupnému rozšíření řešení BI mezi širší okruh uživatelů. Vzhledem k tomu, že in-memory řešení je velmi flexibilně škálovatelné, budou si ho moci v budoucnu dovolit i malé a střední podniky. ● Standardizované BI aplikace – S příchodem koncepčně „jednoduchého“ in-memory řešení BI není třeba vyvíjet aplikace šité zákazníkovi na míru, nebo vyvíjet kompletní řešení na „zelené louce“. Již dnes několik dodavatelů nabízí hotové řešení BI pro standardizované systémy typu ERP, CRM a další. Ty obsahují předdefinované komponenty pro jednotlivé vrstvy (ETL, vlastní datový model, sady reportů a dashboardů). Nevýhodou je v tomto případě cena řešení, jelikož je potřeba udržovat veškerá data v paměti serveru, disponujícím energeticky nezávislou operační pamětí NVRAM (viz kapitola 3.2.2).

3.6

Závěr kapitoly

Pokud shrneme výše uvedené poznatky, vyplyne několik klíčových důvodů, které vedly k většímu rozšíření in-memory řešení, nejen na trhu BI. ● Rozšíření 64bitových systémů, včetně jejich stability (viz kapitola 3.1). Ještě donedávna panovala mezi uživateli doslova panika při výběru operačního systému, který měl být nasazen na jejich server. V tomto ohledu měl dozajisté navrch operační systém Linux. Ke spokojenosti řady uživatelů v tomto ohledu udělal Microsoft se svým produktem Windows Server obrovský krok kupředu. S jinými operačními systémy nemám zkušenosti, a tak nemůžu soudit jejich historické renomé. ● Klesající cena operační paměti, ze které vyplývá její dostupnost pro širší spektrum uživatelů a nasazení většího objemu RAM. ● Příchod operační paměti typu NVRAM, u které odpadá potřeba znovu nahrání aktualizovaných dat do operační paměti (v horším případě po plánovaném či neplánovaném restartu zařízení), jelikož dokáže trvale uchovat data přímo v operační paměti. Odpadá tak potřeba použití pevných disků, na kterých se data trvale uchovávají. ● Rostoucí výkon procesorů a modernizace jejich architektury, které musí veškerou alokovanou operační paměť obsluhovat. Problematika in-memory databází ovšem není černobílá a musí čelit i řadě argumentů od jejích kritiků. Pochopitelně jsou tyto argumenty na místě a je třeba brát je v potaz, při rozhodování o volbě optimálního řešení. ● Současné řešení i přes svůj pomalý výkon postačuje. Tento argument je zcela na místě a myslím, že by si ho měl jakožto otázku položit každý, kdo se chystá pro ino-

3 In-Memory BI

24

vaci současného řešení v jakékoliv oblasti IT. Je potřeba zvážit, jaký přínos bude mít nasazení nového řešení do podniku a tento přínos porovnat s náklady na inovaci řešení. Samozřejmě je nutné uvažovat i finanční možnosti z pohledu představenstva společnosti. Po vyhodnocení těchto měřítek je relativně snadné se rozhodnout, má-li inovace smysl. ● Operační paměť v požadované velikosti je pro podnik velmi nákladná. Je fakt, že nejmodernější řešení jsou velmi nákladné. Stejně tak řešení za využití operační paměti NVRAM jsou novinkou na trhu a stojí nemalé peníze. Pro běžná řešení jsou však v dnešní době servery i osobní počítače dostupnější než kdy dříve. Opět je potřeba pečlivě analyzovat a konzultovat s odborníky, jaké řešení je pro zákazníka nejvhodnější. ● Moderní SSD řeší omezení klasických pevných disků. Pravdou je, že SSD jsou výrazně rychlejší než klasické HDD. Bohužel jejich malá kapacita nejde ruku v ruce s jejich výkonem. SSD se v řešení BI používají tam, kde není potřeba zpracovávat a uchovávat tak velké objemy dat. Dále se též hojně využívají jako mezistupeň při přenosu dat mezi datovým skladem či zdrojovými systémy a in-memory databází. Možnosti integrace in-memory databáze do stávajícího řešení BI zhodnocuje druhá část kapitoly 3.5. Zároveň uvádí výhody a nevýhody použití hybridního řešení BI (klasická koncepce v kombinaci s in-memory databází) a čistě in-memory BI.

4 Praktická úloha

25

4 Praktická úloha Kapitola navazuje na poznatky získané v teoretické části práce. Má za úkol představit metodu in-memory zpracování dat na praktické úloze a porovnat jí s konvenční metodou zpracování dat na pevném disku formou výkonnostního testování. Praktická úloha bude realizována v konkrétních softwarových nástrojích podporujících tu či onu metodu zpracování dat. K testování je použito prostředí lokální klientské stanice (laptop). K realizaci úlohy bylo zapotřebí několik vstupů: ● hardware – osobní počítač (bližší specifikace viz kapitola 5.1), ● softwarové nástroje – operační systém, lokální databázový server, konvenční reportingový nástroj, in-memory reportingový nástroj, generátor dat, ● vzorky testovacích dat – 4 instance databáze o různém datovém objemu (viz kapitola 5.2.2, 5.2.3 a 6.2), ● vytvořené reporty s vizualizací a kalkulací dat na souhrnné úrovni. Výstupem, tedy i cílem výkonnostního benchmarku jsou tabulky a grafy, které přehledně znázorňují výsledky jednotlivých měření. Naměřené hodnoty udávají dobu zpracování při vytváření výsledných reportů v jednotkách času (dobu odezvy), v závislosti na objemu dat a zvolené metodě zpracování dat. Pro každou metodu zpracování dat budou provedeny 4 série měření doby odezvy, vždy na větším objemu dat o velikosti původního databázového souboru cca. 1 GB, 2 GB, 3 GB a 5 GB. Nad těmito vzorky dat budou generovány reporty, které budou mít s přibývajícím množstvím dat rostoucí tendenci zatížení. Pro konvenční metodu zpracování dat na pevném disku budou tedy provedena 4 měření. Obdobně u in-memory metody zpracování dat. Pro relevantní testování je zapotřebí provádět test obou metod na zařízení stejné konfigurace. Též v reportingových nástrojích je zapotřebí použít stejné dotazovací funkce a kalkulace, přestože nástroje používají odlišnou syntaxi kódu a mají jiné návrhové rozhraní. Výstupy praktické úlohy umožní naplnit jeden z hlavních cílů této diplomové práce, a to diskutovat vhodnost použití, efektivitu a srovnání obou aplikovaných metod zpracování dat.

4.1

Postup řešení praktické části

Tato část práce popisuje zvolenou metodu řešení praktické úlohy. Postup jednotlivými kroky znázorňuje následující procesní diagram na obrázku 5 (čtěte zleva doprava, odshora dolů). Svislé organizační jednotky označují dílčí celky práce, jednotlivé procesy potom navazující kroky řešení úlohy.

4 Praktická úloha

26

Obrázek 5 - Proces řešení praktické úlohy (Autor)

Pro objasnění procesu řešení praktické úlohy shrnu schéma v několika bodech: ● instalace aplikačního software, ● příprava testovacích dat, ● vytvoření 4 instancí stejné databáze (každá z nich bude naplněna jiným počtem záznamů při datovém objemu 1, 2, 3 a 5 GB, respektive 5,5, 11, 16,5 a 27,5 milionu záznamů databáze), ● konfigurace generátoru dat (připojení na databázi, nastavení datových typů aj.) a spuštění generování dat pro každou ze 4 instancí databáze (smyčka 4x označuje cyklus pro každou instanci databáze Northwind), ● připojení nástrojů k datové bázi a vlastní testování (viz kapitola 6), ● vyhodnocení dosažených výsledků. Další komentář výše uvedený obrázek nepotřebuje, jelikož se jednotlivým blokům procesního diagramu věnují k tomu určené kapitoly 5 – Použité prostředí a 6 – Realizace výkonnostního testu.

5 Použité prostředí

27

5 Použité prostředí K realizaci výkonnostního benchmarku bylo zapotřebí nainstalovat a nakonfigurovat potřebný software na použité hardwarové specifikaci. V této kapitole představím jak hardwarové prostředky, tak softwarové nástroje, se kterými budu dále pracovat. Součástí představení softwarových nástrojů jsou i jejich výhody, omezení oproti obdobným nástrojům, poznatky a doporučení, které jsem při jejich použití získal.

5.1

Hardwarové vybavení

Při volbě HW, na kterém byl výkonnostní benchmark realizován, jsem měl na výběr ze stolního (desktopu) i přenosného počítače (laptopu). Studie ukazují, že prodej laptopů na trhu osobních počítačů celosvětově převyšuje prodej desktopů. Podíl prodaných laptopů se v roce 2013 vyšplhal téměř k 65 % z celkového počtu prodaných PC (Deloitte, 2013). Tento trend je přitom rok od roku silnější a bude nadále pokračovat. I proto jsem pro testování vybral laptop o následující specifikaci (viz tabulka níže). Tabulka 4 - Specifikace laptopu, na kterém byla praktická úloha realizována (autor) HP ProBook 6470b Procesor

Intel Core i5 3230M, 2,6 GHz - 3,2 GHz TurboBoost

Operační paměť

8 GB DDR3 1 333 MHz

Systémový disk

SSD SATA III – 120 GB

Datový disk

HDD SATA I – 500 GB, 7200 ot. /min.

Grafická karta

Intel HD Graphics 4000

Operační systém

Windows 7 Professional x64

V komponentové specifikaci nelze přehlédnout SSD10, jakožto systémový disk, na kterém mám nainstalovaný operační systém. Díky jeho odlišným vlastnostem oproti HDD bylo nutné zajistit instalaci použitých nástrojů a umístění dat na „Datový disk“. To umožnilo získat relevantní výsledky měření při konvenční metodě zpracování dat, právě na zmíněném pevném disku. SSD – Solid State Drive, je typ datového média, které na rozdíl od běžných magnetických pevných disků neobsahuje žádné pohyblivé části (plotny a čtecí hlavu). SSD ukládají data na bázi podobné flash paměti. Díky tomu dosahují výrazně vyšších přenosových rychlostí a tomu odpovídajících přístupových dob. 10

5 Použité prostředí

5.2

28

Softwarové nástroje

V této kapitole jsou představeny softwarové nástroje, které jsem použil pro zpracování praktické úlohy. Kromě základních informací je ke každému nástroji uveden účel jeho použití, případně získané poznatky, které považuji za stěžejní. Nástroje jsou uvedeny v tom pořadí, jak byly v úloze chronologicky využity. Pro přehlednost uvádím následující tabulku: Tabulka 5 – Seznam použitých SW nástrojů (autor) Použité SW nástroje Označení nástroje

Popis / účel použití

SQL Server 2012 Enterprise Edition

Databázový systém / provoz databází

SQL Server Management Studio

Administrace testovacích instancí databáze

SQL Data Generator 3.0

Generování vzorků dat

QlikView 11

Reportingový nástroj na principu in-memory zpracování a analýzy dat. Vytváření a spouštění reportů.

SQL Server Reporting Services

Reportingový nástroj na klasickém principu zpracování dat na pevném disku. Vytváření a spouštění reportů.

Process Explorer

Sledování zatížení procesoru reportingovými nástroji

5.2.1

SQL Server 2012 Enterprise Edition

Microsoft SQL Server je relační databázový a analytický systém. Označení RDBMS (Relational DataBase Management System) představuje systém řízení báze dat založený na relačním datovém modelu, kde relace tvoří vazby či propojení mezi jednotlivými tabulkami databáze. Z toho důvodu tabulky obsahují primární a cizí klíče, jakožto jednoznačné identifikátory, které jednoznačně označují každý záznam databáze (Lacko, 2009). MS SQL Server je komerční systém společnosti Microsoft vydávaný v mnoha verzích. Pro potřeby této práce jsem použil SQL Server Enterprise Edition, která mimo jiné obsahuje sadu nástrojů pro podporu BI řešení, což byl můj základní požadavek. Existuje i řada dalších verzí, např. Express, Standard, Web, Datacenter aj. Každá z nich se snaží přizpůsobit na míru určité kategorii zákazníků. V praktické úloze je MS SQL Server použit k provozu testovacích instancí databází. Zároveň slouží jako primární systém pro správu a uchování dat, na který se připojují vybrané reportingové nástroje.

5 Použité prostředí

5.2.2

29

SQL Server Management Studio

Microsoft SQL Server Management Studio je primární nástroj pro správu databázového serveru SQL Server té samé společnosti. Databázový server je v tomto případě koncipován jakožto služba běžící na pozadí desktopové aplikace Management Studia, které se používá ke konfiguraci a správě všech komponent SQL Serveru (databázový stroj a analytické, reportingové či integrační služby). Aplikace je součástí instalace mnou vybraného balíku nástrojů SQL Server 2012 Enterprise Edition. Pro uživatele je klíčovým prvkem prohlížeč objektů, který umožňuje vybrat objekt bez jakéhokoliv psaní a spouštění skriptů. Editor SQL skriptů je však uživateli samozřejmě k dispozici. SQL Server Management Studio také poskytuje prostředky pro modelování a návrh databázových struktur, zálohování datových struktur, správu uživatelů, jejich práv a mnoho dalšího. Nástroj je v praktické části použit pro vytvoření jednotlivých instancí databáze Northwind, kterou společnost Microsoft nabízí volně ke stažení.11 Ty jsou poté naplněny generovanými daty o objemu 1GB, 2GB, 3GB a 5GB. Od toho jsem také odvodil a zvolil pojmenování databází Northwind ve čtyřech instancích: ● Northwind_1 (cca 5,5 milionů záznamů), ● Northwind_2 (cca 11 milionů záznamů), ● Northwind_3 (cca 16,5 milionů záznamů), ● Northwind_5 (cca 27,5 milionů záznamů). Datový model a další informace o databázi podrobně řeší kapitola s názvem Realizace výkonnostního testu. SQL Server Management studio též obsahuje databázi pro správu a vyhodnocování výkonu vytvořených reportů v prostředí MS Reporting Services. Databáze nazvaná ReportServer, která se nachází ve stejném adresáři jako uživatelem vytvořené databáze, ukládá informace o průběhu generování reportů (jména uživatelů, vstupní data, parametry, časové záznamy z průběhu zpracování dat aj). Tato funkcionalita mi posloužila při vyhodnocování výsledků praktické úlohy. Záznamy s dobou trvání zpracování dat jsem použil pro potřeby výkonového srovnání nástrojů QlikView a Reporting Services, potažmo in-memory a konvenční technologie zpracování dat na pevném disku.

Skripty pro vytvoření databáze v prostředí MS SQL Serveru jsou dostupné na této adrese: http://www.microsoft.com/en-us/download/details.aspx?id=23654 11

5 Použité prostředí

5.2.3

30

SQL Data Generator 3

SQL Data Generator je výhradně komerční nástroj britské společnosti Red Gate Software. Jak již název produktu napovídá, SQL Data Generator12 slouží primárně pro generování testovacích dat nad platformou MS SQL Serveru. Je tak určen především databázovým architektům, kteří potřebují otestovat a optimalizovat výkonnost databáze nad velkým množstvím dat, než uvedou databázi do ostrého provozu. Na rozdíl od jiných nástrojů připojujících se na databázový server pomocí ODBC nebo OLE DB ovladačů, využívá nativní přístup k serveru, díky němuž disponuje vyšším výkonem při generování dat (Red Gate, 2014). Zmíněné ovladače naproti tomu dokáží lépe pracovat s uživateli, jejich právy pro správu databáze z hlediska bezpečnosti apod. Aplikace má přehledné grafické rozhraní a intuitivní ovládání, což jsem při práci velmi ocenil. Pro každou tabulku je zde možnost nastavit obsah jednotlivých atributů a počet záznamů (řádků), které se do tabulky vygenerují. Generování potom probíhá v transakcích, kde si uživatel může nastavit počet záznamů na jednu transakci. SQL Data Generator disponuje stejnými datovými typy jako MS SQL Server 2012, který jsem použil. Nejvíce jsem ocenil funkci generování referenčních klíčů, které se berou ze sloupce primárních či cizích klíčů referenční tabulky. Nutno podotknout, že nástroj je k dispozici po dobu 14 dnů bez jakéhokoliv omezení. Některé další nástroje, které jsem při procesu získávání testovacích dat vyzkoušel, mají bohužel omezený počet záznamů, které v bezplatné licenci generují. To je samozřejmě omezení, které pro mě bylo nepřijatelné. Při instalaci nástroje se integrují do SQL Server Management Studia základní funkce pro spuštění generování dat do uživatelských databází na základě projektů vytvořených v SQL Data Generatoru. To je užitečné ve chvíli, kdy se uživatel nachází v prostředí SQL Server Management Studia a nechce zbytečně zapínat další aplikaci. V průběhu generování dat do testovacích instancí databází jsem odhalil velký nedostatek tohoto nástroje. V případě generování velkého množství dat (desítky až stovky milionů záznamů), kdy se snadno dosáhne zaplnění operační paměti, generování dat se mnohonásobně zpomalí. V mém případě zabralo generování testovacích dat do databáze Northwind_3 cirka 40 minut a do Northwind_5 cca 17 hodin, což je obrovský rozdíl. Přitom se jedná o data o objemu 3 GB a 5 GB. Informace o průběhu generování jsou k nahlédnutí ve formě reportů v Příloze A. SQL Data Generator byl v praktické části použit pro generování dat do jednotlivých instancí databáze Northwind, která sloužila jako báze dat pro další práci v reportingových nástrojích QlikView a Reporting Services.

12

Nástroj je dostupný ke stažení na této adrese: http://www.red-gate.com/dynamic/products/sqldevelopment/sql-data-generator/download

5 Použité prostředí

5.2.4

31

QlikView 11

V předchozích podkapitolách jsem uváděl základní funkcionalitu a poznatky o nástrojích, které byly nezbytné pro vypracování praktické části. Jelikož je QlikView díky jeho použité in-memory technologii stěžejním nástrojem této diplomové práce, zaměřím se na něj podrobněji než na předchozí mnohem známější nástroje, které jsou na trhu také o poznání delší dobu. O společnosti Qlik Společnost Qlik působí na trhu analytických softwarů již od roku 1993. Do roku 2012 byla společnost známá pod názvem QlikTech, přičemž QlikView je jejím doposud jediným prodávaným nástrojem. Po celou dobu své existence prosazuje vizi intuitivního, uživatelsky přívětivého nástroje, který zákazníkům dodá řešení v extrémně krátké době. Zpočátku se společnost zaměřovala na řešení ad-hoc analýzy dat přímo koncovými uživateli, ale už v té době se Qlik snažil prosazovat in-memory databáze. Postupem času se ukázalo, že se vydali tou správnou cestou a Qlik je v současné době nejrychleji rostoucí společností na poli informačních technologií, poskytující řešení BI, s působením ve více než 100 zemích po celém světě. V roce 2012 se dokonce prosadila na 3. místě nejrychleji rostoucích technologických společností, za giganty, jakými jsou Apple a LinkedIn (Qlik, 2014). Vyhodnocováním postavení podniků na trhu se věnuje řada renomovaných analytických společností. Dovolím si tvrdit, že nejznámější a taktéž nejuznávanější z nich, je společnost Gartner. Ta každoročně představuje i hodnocení podniků na trhu BI produktů. Hodnocení probíhá na základě předem stanovených kritérií. Dle analýzy Gartner patří Qlik do sektoru lídrů trhu spolu se společnostmi, jako je Microsoft, SAP, IBM a další (viz obrázek 6). Dle analýzy Gartner, s názvem Magic Quadrant for Business Intelligence and Analytics platforms, vděčí Qlik svému umístění zejména za (Gartner, 2014): ● jedinečnost platformy nástroje QlikView při využití in-memory technologie, ● snadné intuitivní používání pro koncové uživatele, ● nenáročnost produktu na IT odborníky, škálovatelnost a integrace v podniku, ● rychlost a nízká cena implementace. Hlavně díky těmto aspektům byl QlikView v roce 2014 celosvětově nejčastěji nasazovaným BI nástrojem. Ze závěru analýzy vyplývají i určitě slabé stránky řešení. Jako nejpodstatnější jsou uvedeny: ● správa metadat, uživatelů, řízení bezpečnosti, ● nedostatečná nabídka možných vizualizací dat.

5 Použité prostředí

32

Obrázek 6 – Magický kvadrant pro BI a analytické platformy (Gartner, 2014)

Přehled platformy a architektura QlikView Tato podkapitola poskytuje čtenáři stručný přehled nad QlikView platformou, tj. jejich komponent a vztahů mezi nimi. QlikView platforma se skládá ze tří základních částí, jak znázorňuje obrázek 7 – Schéma QlikView platformy (Qlik, 2014): ● desktopové části, ● serverové části, ● vnější spotřeba obsahu.

5 Použité prostředí

33

Obrázek 7 – Schéma QlikView platformy (Qlik, 2014)

Uvedené schéma kromě komponent této platformy znázorňuje i životní cyklus obsahu a jeho průběh platformou, což je důležité si uvědomit pro pochopení účelu komponent QlikView. Společnost Qlik neoznačuje svojí platformu běžně jako BI, nýbrž jako Business Discovery. Ve finále jde ale pouze o názvosloví se stejným účelem. Životní cyklus obsahu napříč platformou začíná jeho vytvořením. Pro tento účel platforma obsahuje komponentu QlikView Developer, který slouží pro načítání dat ze zdrojových systémů a mnoha typů dokumentů. QlikView Developer je aplikace na desktopové části platformy. Jeho hlavní využití je v ETL procesu, kde se vytváří tzv. „Load script“, který definuje připojení na datové zdroje, výběr požadovaných dat, jejich transformaci, parametry některých atributů a umístění dat do cílových tabulek. Detailněji se na tento proces zaměřuje kapitola Realizace výkonnostního testu. Další využití QlikView Developeru se nachází ve tvorbě prezentační vrstvy dat. Ta umožnuje tvorbu vizualizovaných reportů, které uživateli poskytují přehled nad konsolidovanými daty ve formě grafů, tabulek a nejrůznějších indikátorů. Desktopový klient může pracovat jak samostatně, tak přes serverovou část platformy. K reportům spouštěným na serveru se potom uživatel připojuje přes webové rozhraní svého prohlížeče. Nutno podotknout, že desktopová část je zcela zdarma. Druhou fází v životním cyklu obsahu procházejícího platformou QlikView je jeho obnova, publikování a distribuce. Tuto úlohu zabezpečuje serverová část platformy. QlikView Ser-

5 Použité prostředí

34

ver zpracovává data na principu in-memory databáze a slouží k zajištění komunikace mezi serverem a klientem. Druhým blokem v serverové části platformy je QlikView Publisher, který podporuje aktualizaci datové základny ze zdrojových systémů. Samotná aktualizace se spouští dle potřeby, buď pravidelně v předem naplánovaném čase, nebo ad-hoc, v závislosti na okolnostech. Zároveň také slouží k distribuci reportů k jejich uživatelům. Poslední komponentou serverové části QlikView je AccessPoint, který zastává funkci webového portálu, kde uživatelé nahlížejí do svých reportů. Publisher a AccessPoint jsou volitelné součásti platformy a jejich pořízení není nutné pro základní funkcionalitu QlikView jako celku v modelu klient – server. Závěrečnou fází životního cyklu obsahu v podniku je jeho užívání. Jak je ze schématu patrné (viz obrázek 7), QlikView platforma podporuje mnoho prostředků pro připojení se k serverové části řešení, jako webový prohlížeč, mobilní zařízení a samozřejmě samotná QlikView aplikace. Její výhodou je možnost práce s „offline“ daty, které je možné po připojení k firemní síti či internetu ze serveru aktualizovat.

Obrázek 8 – QlikView architektura z pohledu uživatelských rolí (Qlik, 2014)

5 Použité prostředí

35

Schéma architektury na výše uvedeném obrázku 8 - QlikView architektura z pohledu uživatelských rolí, nahlíží na řešení BI z pohledu zastoupení zaměstnanců podniku a jeho uživatelů při práci s nástroji QlikView. Důležité pro pochopení QlikView řešení je uvědomit si spojitost mezi těmito dvěma předchozími schématy v tom, jakými možnostmi jednotlivé komponenty řešení disponují a pro koho jsou určeny. Za zmínku stojí relativně složitá licenční politika společnosti Qlik, která vychází ze zpoplatnění všech uvedených komponent, kromě desktopové části, v závislosti na počtu uživatelů, kteří s ní budou s podniku pracovat. V praxi to pro vedení firmy znamená poměrně nejednoznačný náklad spojený s nástupem na platformu QlikView, pokud nemají již zpracovaný přehled o tom, kdo jaké role bude při práci se systémem zastávat. Toto se přirozeně detailně řeší až s konzultanty partnerské společnosti Qlik, která bude systém v podniku implementovat. Pro moji diplomovou práci byla v praktické části použitá pouze desktopová část platformy, kterou zastupuje aplikace QlikView 11.2 Personal Edition v 64bitové verzi. Použitá technologie V návaznosti na poznatky z teoretické části práce QlikView používá in-memory asociativní technologii. Asociace mezi daty určitého stupně podobnosti automaticky vytváří spojení a při využití zpracování dat přímo v operační paměti, se tak dosahuje velmi vysokých rychlostí na uživatelské požadavky. Asociativní technologii přibližuje následující obrázek.

Obrázek 9 – Srovnání tradiční a asociativní technologie (Qlik, 2010)

Tradiční relační přístup je zachycen na obrázku 9 vlevo. Asociativní technologie je založena na rozdíl od relační, na spojování dat již na úrovni databázového stroje, nikoliv aplikační úrovni, kde se v tradičním BI řešení vytvářejí multidimenzionální OLAP kostky. Každé

5 Použité prostředí

36

pole je tak spojeno s každým polem v dalších tabulkách. To v praxi znamená, že se uživatel při analýze nemusí pro data vracet do vrstvy níže (Qlik, 2010). Asociativní princip spojování dat má ale i svoje nevýhody. Největším problémem, na který jsem narazil a uživatelé s ním mají velké problémy, je asociace zdrojových dat, která k sobě nepatří, i když jsou vazby ve zdrojovém systému navrženy správně. Většinou za to může asociace stejně pojmenovaných atributů různých tabulek. V praktické části jsem proto musel ošetřit ETL proces ze zdrojové báze dat v MS SQL Serveru. Je potřeba na správnost propojení dat klást velký důraz, jinak jsou data načtená do QlikView nepoužitelná pro další zpracování a analýzy. V praktické části jsem použil desktopovou část nástroje QlikView k vytváření a spouštění reportů pro in-memory metodu zpracování dat. Zároveň jsem musel získat data ze zdrojového systému pomocí ETL procesu, který je v QlikView realizovaný pomocí „Load scriptu“ s SQL synatxí. Skript si uživatel musí podle potřeb nadefinovat.

5.2.5

SQL Server Reporting Services

Microsoft SQL Server Reporting Services (dále jen Reporting Services) je nástroj pro tvorbu a generování reportů na platformě MS SQL Serveru. Pro účely této práce je zástupcem konvenčního reportingového nástroje. Pro vizualizaci dat obsahuje množství tabulek, grafů a dalších prvků, které přehledně zobrazí data jak na detailní, tak souhrnné úrovni. Reporting Services jsou v současnosti obsaženy v sadě nástrojů vybraných edic Microsoft SQL Serveru s podporou BI. Ve verzi Enterprise edition se nástroj skrývá pod označením SQL Server Data Tools, což je ve skutečnosti známé Visual studio 2010. Reporting Services umožňují uživatelům snadno a rychle vytvářet reporty nad databází SQL Serveru. K tomu slouží tři základní prvky, kde se definují vybraná data, se kterými uživatel dále pracuje. ● Datové zdroje (Data sources) – zde se vytváří připojení k jedné či více databázím, ze kterých jsou vybírána data pro jednotlivé datové sady ● Datové sady (Datasets) – na tomto místě se pomocí SQL selectu vybírají potřebná data k interpretaci v reportech ● Parametry (Parametres) – slouží k filtrování dat reportů, kde uživatel nastavuje rozsahy dat, která do reportu budou vstupovat (např. časové rozmezí, skupinu zákazníků, vybrané regiony atd.) Nástroj Reporting Services jsem v práci použil na vytváření a spouštění reportů pro konvenční metodu zpracování dat na pevném disku. Pro vytvoření odpovídajících reportů k testování bylo nutné vytvořit stejné reporty jako ve srovnávaném nástroji QlikView (stejný výběr dat a identické kalkulace nad těmito daty). Metodu testování podrobně přibližuje následující kapitola s názvem Realizace výkonnostního testu.

5 Použité prostředí

5.2.6

37

Process Explorer

Process Explorer je jednoduchá aplikace, určena pro správu úloh operačního systému Windows a monitorování spuštěných procesů. Poskytuje rozšířenou funkcionalitu jako ve Windows integrovaný Správce úloh. V praktické úloze jsem Process Explorer využil pro sledování zatížení procesoru nástrojem QlikView. Jelikož program umí sledovat jednotlivé procesy nezávisle na sobě, mohl jsem odečíst z grafu zátěže procesoru čas, který po spuštění generování reportu QlikView pro tuto operaci potřeboval.

5.3

Závěr kapitoly

Text této kapitoly čtenáře seznámil s použitými softwarovými nástroji, se kterými dále pracuji v praktické části práce. Kapitola předložila základní informace, poznatky a doporučení o uvedených nástrojích. Největší důraz byl kladen na přiblížení QlikView platformy a vysvětlení principu QlikView asociativní technologie, jejíž pochopení je nezbytné pro porozumění následující kapitoly Realizace výkonnostního testu a smyslu samotného porovnávání metod zpracování dat konvenční diskovou a in-memory metodou.

6 Realizace výkonnostního testu

38

6 Realizace výkonnostního testu Náplní této kapitoly je krok po kroku předvést, jakým způsobem byl realizován výkonnostní benchmark pro porovnání aplikovaných metod zpracování dat. Může tak posloužit jako návod či průvodce pro obdobné testování reportingových nástrojů Reporting Services a QlikView. Kapitola je stěžejní částí této diplomové práce. Zároveň navazuje na předchozí část, jelikož pracuje s uvedenými nástroji. Dílčí podkapitoly korespondují s procesním diagramem tak, jak byla úloha chronologicky vypracována, viz obrázek 5: Proces řešení praktické úlohy. Cílem kapitoly je provést objektivní analýzu dvou metod zpracování dat v prostředí vybraných reportingových nástrojů. Analýza srovnává konvenční metodu zpracování dat na pevném disku oproti in-memory metodě zpracování dat z hlediska jejich výkonu. Výstupem zde bude grafické znázornění výsledků výkonnostního benchmarku a zhodnocení silných a slabých stránek testovaných metod zpracování dat.

6.1

Vytvoření databázových instancí

Úvodním krokem při přípravě dat k vlastnímu testování bylo vytvoření databází, ve kterých se budou strukturovaná data uchovávat. Pro tento účel jsem zvolil volně distribuovanou databázi Northwind, kterou pro testovací využití nabízí společnost Microsoft. Po stažení a rozbalení obsahuje archiv 3 soubory. První dva z nich jsou databázový a transakční soubor (Northwnd.mdf a Northwnd.ldf) a stačí je připojit k existujícím databázím na platformě SQL Serveru pomocí funkce „Attach database“. Třetí soubor instnwnd.sql je spustitelný skript pro vygenerování databáze. Ten je nutné otevřít a spustit v nástroji SQL Server Management Studio. Jelikož jsem pro testování potřeboval více vzorků dat, bylo potřeba vytvořit několik instancí databáze Northwind. Jak již zmiňuje předcházející kapitola, rozhodl jsem se pro 4 instance databáze o velikosti 1, 2, 3 a 5 gigabajtů primárního databázového souboru SQL Serveru. Pro každou z jednotlivých instancí bylo potřeba přepsat ve skriptu názvy souborů databáze, které se vygenerují předtím, než je skript postupně zaplní daty. Zde je úvodní část skriptu pro vytvoření databáze a k ní potřebných souborů. V tomto případě připravený pro vytvoření databáze Northwind_1. USE master GO if exists (select * from sysdatabases where name='Northwind_1') drop database Northwind_1 GO DECLARE @device_directory NVARCHAR(520) SELECT @device_directory = SUBSTRING(filename, 1, CHARINDEX(N'master.mdf', LOWER(filename)) - 1)

6 Realizace výkonnostního testu

39

FROM master.dbo.sysaltfiles WHERE dbid = 1 AND fileid = 1 EXECUTE (N'CREATE DATABASE Northwind_1' ON PRIMARY (NAME = N''Northwind_1''', FILENAME = N''' + @device_directory + N'northwnd.mdf'') LOG ON (NAME = N''Northwind_1'_log'', FILENAME = N''' + @device_directory + N'northwnd.ldf'')') GO V další části skriptu následuje vytváření tabulek databáze s jejich atributy, nastavení referenčních vazeb mezi tabulkami a naplnění defaultními daty. Zde již není nutné cokoliv upravovat. Po vygenerování databáze Northwind obsahuje data fiktivní společnosti, která podniká v oblasti dovozu a vývozu potravin. Databáze obsahuje záznamy o zákaznících, dodavatelích, zaměstnancích podniku, produktech, jejich kategoriích a informace o objednávkách. Následující tabulka podává bližší přehled o tabulkách databáze Northwind a v nich obsažených informacích. Tabulka 6 – Přehled tabulek databáze Northwind (Autor) Název tabulky

Obsažené informace

Orders

Všechny realizované objednávky podniku.

Order Details

Podrobnosti o objednávkách. Každá objednávka obsahuje několik položek (produktů) a objednané množství.

Employees

Detailní informace o zaměstnancích podniku.

EmployeeTerritories

Oblasti prodeje, které spadají pod zaměstnance podniku.

Territories

Teritoria a jejich popis.

Region

Regiony a jejich popis.

Products

Produkty, se kterými podnik obchoduje.

Categories

Kategorie produktů podle jejich typu.

Suppliers

Dodavatelé podniku, kteří zajišťují dodání produktů na sklad.

Customers

Zákazníci společnosti, se kterými se uzavírají obchody.

Shippers

Přepravci, kteří doručují expedované zboží ke koncovým zákazníkům.

Po vygenerování obsahuje databáze Northwind tabulky CustomerDemographics a CustomerCustomerDemo, které mají sloužit pro ukládání demografických dat o zákaznících podniku. Neobsahují však žádná data a pro mojí praktickou úlohu nenašly využití. Rozhodl jsem se tudíž pro jejich smazání. Proto je následující datový model neobsahuje.

6 Realizace výkonnostního testu

Obrázek 10 – Upravený datový model databáze Northwind v prostředí SQL Server Management Studia (Autor)

40

6 Realizace výkonnostního testu

41

Datový model obsahuje tabulky databáze včetně označení primárních a cizích klíčů, referenční vazby mezi tabulkami a výčet jejich atributů s popisem datových typů. Jak je z datového modelu na obrázku 10 patrné, slouží jako datová základna pro informační systém podniku Northwind. Napomáhá tak k podpoře jeho podnikání. Databáze se výborně hodí pro využití v praktické úloze mojí diplomové práce díky časovému rozlišení realizovaných objednávek a dalším vazbám na objednávky, nad kterými jdou vytvářet dimenze pro výběr a zpracování dat. Instance databáze Northwind, vytvořené výše uvedeným postupem, slouží jako základ pro další krok praktické úlohy. Tím je generování testovacích dat.

6.2

Generování dat

K realizaci výkonnostního testu bylo zapotřebí získat data, která dokáží dostatečně zatížit počítač, na kterém bude zpracování těchto dat probíhat. Jelikož pro takový účel databáze Northwind neobsahuje dostatečné množství dat, musel jsem najít jiný způsob, jak je získat. Získání takových dat je možné buďto jejich vygenerováním, nebo stažením reálných podnikových dat. K takto objemným reálným datům bohužel nemám přístup, a proto jsem musel zvolit první možnost, jejich vygenerování některým z dostupných nástrojů. Následující tabulka uvádí počet řádků tabulek databáze Northwind bezprostředně po jejím vytvoření. Tabulka 7 – Počet záznamů databáze Northwind (Autor) Název tabulky

Počet záznamů tabulky

Orders

830

Order Details

2155

Employees

9

EmployeeTerritories

49

Territories

53

Region

4

Products

77

Categories

8

Suppliers

29

Customers

91

Shippers

3

6 Realizace výkonnostního testu

42

Pro generování dat bylo nutné najít vhodný nástroj, který bude splňovat několik základních požadavků. Kritéria pro výběr nástroje jsem stanovil následovně: ● možnost připojení na platformu MS SQL Serveru 2012, ● podpora datových typů, které jsou v databázi zastoupeny, ● schopnost náhodného generování primárních klíčů z cizích klíčů referenční tabulky, ● možnost omezení rozsahu dat (zejména typu Date/Time, Money, Integer), ● podpora uživatelem vlastních definovaných seznamů, ● nastavení počtu generovaných záznamů. Při výběru nástrojů jsem nejprve vyzkoušel DTM Data Generator, který však v omezené verzi nepovolí uživateli vygenerovat více než 10 záznamů na tabulku. Druhým nástrojem byl SQL Data Generator (viz kapitola 5.2.3), který oproti DTM Data Generatoru disponuje širší funkcionalitou, příjemnějším uživatelským rozhraním a v době do 14 od instalace produktu je nástroj bez jakéhokoliv omezení funkcionality. Pro komerční využití nabízí společnost Red Gate produkt za cenu 369 amerických dolarů (Red Gate, 2014). Dalším krokem před samotným generováním testovacích dat, bylo si určit, jaké tabulky bude nejvhodnější pro potřeby výkonnostního testování rozšířit (jaká data generovat). Vzhledem k tématu diplomové práce, jsou stěžejním prvkem pro měření v praktické části získané reporty. Jejich forma a obsah se nutně odvíjí od dat, které se při jejich vytváření zpracovávají. Rozhodl jsem se tudíž pro sestavení reportu, který bude uživateli prezentovat kalkulaci nad velkým objemem dat objednávek společnosti ve vybraném časovém období spolu s další dimenzí, v mém případě regiony zákazníků. Hlavní tabulky, na které jsem se tedy zaměřil, byly tabulky Orders a Order Details. Poté jsem mohl přistoupit k vlastnímu nastavení generátoru dat. Po spuštění nástroje SQL Data Generator a vytvoření projektu pro generování dat do konkrétní instance databáze, bylo třeba připojit se k MS SQL Serveru a vybrat instanci databáze, do které se generovaná data budou ukládat. Abych mohl ověřit obě metody zpracování dat při různém objemu testovacích dat, musel jsem generovat data ve čtyřech iteracích, pro každou instanci databáze Northwind zvlášť. Princip připojení je zachycen na obrázku 11. V mém případě se jednalo o lokální server CIGI-HP a v druhém kroku přípravy projektu o instanci databáze Northwind_2.

6 Realizace výkonnostního testu

43

Obrázek 11 – Nastavení připojení generátoru dat na databázový server (Autor)

Následně se po úspěšném založení projektu, autentizaci a připojení k databázi zobrazí pracovní prostředí SQL Server Generatoru. To obsahuje levý sloupec se seznamem tabulek. Při jejich rozbalení se objeví seznam atributů tabulky, jejich datové typy a označení primárních či cizích klíčů. Nad seznamem tabulek je uvedený název serveru a databáze, na kterou je uživatel připojený. Hlavní částí pracovní plochy je prostor určený k nastavení jednotlivých atributů. Uživatel zde vybírá budoucí generovaný obsah pro každý sloupec tabulky, přičemž má možnost zvolit si klíč (interní algoritmus nástroje) pro generování obsahu, tzv. „Seed“. Možný generovaný obsah se uživateli nabízí samozřejmě v souladu s datovým typem vybraného sloupce. Dále je k dispozici možnost povolení nulových hodnot záznamů, včetně jejich procentuálního zastoupení v celkovém počtu řádků. Pro mě velmi užitečným pomocníkem byla oblast náhledu dat, kde je vidět, z jakého zdroje se data berou a v jakém finálním formátu se budou do databáze ukládat. Pracovní prostředí SQL Data Generatoru včetně nadefinovaných sloupců tabulky znázorňuje obrázek 12.

6 Realizace výkonnostního testu

44

Obrázek 12 – Pracovní prostředí nástroje SQL Data Generator 3.0 (Autor)

Pro uživatele prahnoucí po vytváření tabulek, nastavení klíčů, vazeb a omezení atributů tabulky na úrovni SQL Serveru, podporuje SQL Data Generator vytvoření spustitelného SQL skriptu. Jedná se sice o složitější metodu, ale uživateli zajišťuje ošetření dat a jejich rozsahu již na úrovni databáze. Nemůže se potom stát, že si nedopatřením vygeneruje nevyhovující data a aplikace postavená nad databází bude podávat nesmyslné výsledky. Databázový stroj potom na hodnotu mimo povolený rozsah pole upozorní chybovým hlášením. Skript pro vytvoření tabulky Order Details v plánu generování dat: CREATE TABLE [dbo].[Order Details] ( [OrderID] [int] NOT NULL, [ProductID] [int] NOT NULL, [UnitPrice] [money] NOT NULL CONSTRAINT [DF_Order_Details_UnitPrice] DEFAULT ((0)), [Quantity] [smallint] NOT NULL CONSTRAINT [DF_Order_Details_Quantity] DEFAULT ((1)), [Discount] [real] NOT NULL CONSTRAINT [DF_Order_Details_Discount] DEFAULT ((0)) ) GO ALTER TABLE [dbo].[Order Details] WITH NOCHECK ADD CONSTRAINT [CK_Discount] CHECK (([Discount]>=(0) AND [Discount]<=(0.25))) GO ALTER TABLE [dbo].[Order Details] WITH NOCHECK ADD CONSTRAINT [CK_Quantity] CHECK (([Quantity]>(0)) AND [Quantity]<=(200))) GO

6 Realizace výkonnostního testu

45

ALTER TABLE [dbo].[Order Details] WITH NOCHECK ADD CONSTRAINT [CK_UnitPrice] CHECK (([UnitPrice]>=(3) AND [UnitPrice]<=(350))) GO ALTER TABLE [dbo].[Order Details] ADD CONSTRAINT [PK_Order_Details] PRIMARY KEY CLUSTERED ([OrderID], [ProductID]) GO CREATE NONCLUSTERED INDEX [OrderID] ON [dbo].[Order Details] ([OrderID]) GO CREATE NONCLUSTERED INDEX [OrdersOrder_Details] ON [dbo].[Order Details] ([OrderID]) GO CREATE NONCLUSTERED INDEX [ProductID] ON [dbo].[Order Details] ([ProductID]) GO CREATE NONCLUSTERED INDEX [ProductsOrder_Details] ON [dbo].[Order Details] ([ProductID]) GO ALTER TABLE [dbo].[Order Details] WITH NOCHECK ADD CONSTRAINT [FK_Order_Details_Orders] FOREIGN KEY ([OrderID]) REFERENCES [dbo].[Orders] ([OrderID]) GO ALTER TABLE [dbo].[Order Details] WITH NOCHECK ADD CONSTRAINT [FK_Order_Details_Products] FOREIGN KEY ([ProductID]) REFERENCES [dbo].[Products] ([ProductID]) GO Ze skriptu je jasně zřetelné vytvoření tabulky Order Details, nastavení omezení všech atributů a nastavení referenční integrity k dalším tabulkám databáze Northwind. Omezení rozsahu je patrné např. u atributů Discount (Sleva na produktu) a Quantity (Objednané množství). Nejsložitější bylo v této tabulce nastavit provázané primární klíče OrderID a ProductID, která v praxi určují, kolik bude mít každá objednávka položek. Při náhodném generování tak velkého počtu záznamů docházelo ke generování duplicitních hodnot primárních klíčů, což je samozřejmě nepřípustné a generování bylo zrušeno. Byl jsem proto nucen hledat jiné řešení získání dat do těchto sloupců. Nakonec jsem problém vyřešil až naprogramováním jednoduché vlastní aplikace v jazyce Java. Program na výstupu generoval textový soubor se dvěma sloupci čísel, u kterých jsem měl podmínkou ošetřené duplicitní hodnoty. Textový soubor byl pak použit jako vstupní zdroj připravených dat pro vložení do sloupců tabulky Order Details. Zdrojový kód programu obsahuje příloha B. Druhou stěžejní tabulkou byla tabulka Orders. Zde bylo zajímavé zejména nastavení atributů OrderDate (datum objednávky), RequiredDate (požadované datum dodání) a ShippedDate (datum expedice objednávky) tak, aby hodnoty dat odpovídaly pokud možno realitě. Rozsahy dat jsem zvolil následovně: ● OrderDate – 1. 1. 1996 až 28. 2. 2014, ● RequiredDate – 31. 1. 1996 až 31. 3. 2014,

6 Realizace výkonnostního testu

46

● ShippedDate – 15. 1. 1996 až 31. 3. 2014. Při zachování stejného „seedu“ pro všechny 3 atributy si tak záznamy v každém řádku odpovídají rozdílem několika dnů a vypadají reálně. Záznamy se liší pouze náhodností výběru ze zvolených intervalů. Pro generování názvů zemí, regionů, měst, ulic a poštovních směrovacích čísel disponuje SQL Data Generator šablonami a předdefinovanými seznamy (všech zemí světa, amerických měst apod.). Po kompletním nastavení tabulek Orders a Order Details zbývalo jen učit počet generovaných záznamů. Tabulka 8 udává počet záznamů/řádků obou klíčových tabulek v každé z vytvořených instancí databáze Northwind. Za povšimnutí stojí fakt, že počet řádek tabulky Order Details je u každé instance databáze zhruba čtyřnásobný. Může za to mnou zvolený algoritmus generování primárních klíčů (viz příloha B), kde jsem nadefinoval minimálně jeden a maximálně sedm položek pro objednávku. Při počtu milionů náhodně generovaných záznamů na uzavřeném intervalu celých čísel 1 až 7, se průměrná hodnota logicky pohybuje okolo čtyř položek na jednu objednávku. Tabulka 8 – Počet záznamů klíčových generovaných tabulek (Autor) Instance databáze

Tabulka Orders

Tabulka Order Details

Northwind_1

1 100 000

4 398 285

Northwind_2

2 200 000

8 800 266

Northwind_3

3 300 000

13 203 799

Northwind_5

5 500 000

22 005 412

V okamžiku, kdy jsem měl všechny instance databáze naplněné testovacími daty, mohl jsem přistoupit k připojení reportingových nástrojů na tyto data, návrhu reportů a k vlastnímu testování metod zpracování dat.

6.3

Testování v QlikView

Tato kapitola se věnuje přípravě reportu použitého pro testování in-memory metody zpracování dat v nástroji QlikView. K testování byla použita desktopová část 64bitové verze nástroje QlikView 11.2 SR4 Personal Edition. Edice je určená k provozu na koncových stanicích uživatelů k prohlížení reportů a pro vývojáře k vývoji reportů či dashboardů. Po spuštění QlikView a založení nového dokumentu skrz menu nástroje, se uživateli zobrazí průvodce pro výběr datových zdrojů. Jak již bylo zmíněno v kapitole 5.2.4, QlikView dokáže nahrávat data z velkého množství nejrůznějších zdrojů. Pro moje potřeby bylo používání průvodce zbytečné, jelikož jsem pracoval pouze s jednou bází dat v SQL Serveru. Mohl jsem ho tedy zavřít. Z mého pohledu není průvodce QlikView pro tvorbu aplikace

6 Realizace výkonnostního testu

47

nejlépe řešený. Obsahuje pouze nejzákladnější funkcionalitu QlikView a hodí se tak pouze pro seznámení s nástrojem, nebo tvorbu extrémně triviálních aplikací. Hlavní okno nástroje je rozdělené na dva hlavní celky. Horní část obsahuje klasické textové menu, pomocí kterého může uživatel využívat všechny dostupné funkce nástroje. Pro nejpodstatnější funkce je pak k dispozici nástrojová lišta, kterou si může uživatel standardně upravovat. Pro uživatele jsou nejdůležitější editor skriptu, datový model, nahrání dat a prvky pro návrh vlastního reportu či dashboardu.

6.3.1

ETL proces

V této fázi jsem mohl přistoupit k načtení dat potřebných pro výkonnostní testování. Prvním krokem bylo sestavení ETL skriptu, který slouží k načtení dat ze zdrojového systému. Editor pro tvorbu ETL „Load skriptu“ zachycuje následující obrázek 13.

Obrázek 13 – Editor pro tvorbu ETL vrstvy nástroje QlikView (Autor)

Z obrázku je patrné rozložení prvků editoru. Hlavní část je vyhrazena pro úpravu a náhled skriptu, kde je vidět struktura skriptu, který mi sloužil pro nahrání dat z databáze

6 Realizace výkonnostního testu

48

Northwind_1. První část skriptu slouží pro nastavení datových typů (např. měsíc je při uvedeném nastavení v aplikaci označován číslem, nikoliv jeho názvem). Obdobně lze nastavit formát měny, data, času apod. Ve spodní části jsou k dispozici tlačítka, pomocí kterých se provádí připojení k jednotlivým datovým zdrojům. Vlevo, po stisknutí tlačítka „Connect...“, se spustí průvodce pro připojení k databázi prostřednictvím ODBC a OLE DB ovladačů. Uživatel nastaví připojení k serveru a databázi. To se promítne v ETL skriptu vložením řádku, který slouží pro připojení k datovému zdroji. V dalším kroku se provádí výběr dat z tabulek databáze, která uživatel potřebuje ve vyvíjené aplikaci. Do skriptu se opět začnou vkládat jednotlivé „Loady“ s výběrem požadovaných atributů tabulky. Pro lepší orientaci v kódu je možné vložit před řádek název cílové tabulky. Lze tak dosáhnout i jiného pojmenování tabulky, než je tomu ve zdrojové databázi. Pravá dolní část editoru obsahuje tlačítka pro extrakci dat ze souborů MS Excel, QlikView Data, XML, HTML, textových a mnohých dalších typů souborů. QlikView pro výše uvedený ETL proces disponuje vlastním ETL jazykem. Ten je ovšem syntaxí velmi podobný rozšířenému dotazovacímu SQL jazyku a je pro uživatele srozumitelný a snadno pochopitelný. Integrovanou ETL vrstvu považuji za velkou přednost nástroje. Jako nevýhodu QlikView ETL vrstvy oproti nástrojům, se kterými jsem dříve pracoval, vidím v absenci náhledu datových toků při spuštění a ladění ETL procesu. Pro uživatele je tak mnohem náročnější odhalit chyby v této stěžejní vrstvě. Tohoto nedostatku však využívají další společnosti na trhu, které se zabývají vývojem konektorů pro QlikView k vizualizaci ETL procesu. Jednou takovou aplikací je například ETL-Tools QlikView Connector od společnosti DB Software Laboratory (DB Software Lab, 2014). Největším problémem, na který jsem v praktické úloze při vytváření ETL procesu narazil, je dodržení původní formy datového modelu zdrojové databáze. QlikView totiž zjednodušuje automatické načítání dat při ETL procesu tím, že stejně pojmenované sloupce spojuje prostřednictvím pomocných tabulek. Pro ilustraci uvedu atribut Country, který obsahují zdrojové tabulky Employees, Customers a Suppliers. Je potřeba tyto atributy přejmenovat např. na Emp_Country, Cus_Country a Sup_Country, jinak dochází k nežádoucímu vytváření vazeb při vytváření datové základy QlikView aplikace. Tím se narušuje funkcionalita datového modelu. Je žádoucí takto ošetřit všechny rizikové sloupce a při vytváření ETL vrstvy pozorně sledovat datový model. Asociativní technologie totiž vytváří vazby mezi některými stejně pojmenovanými atributy různých tabulek i přesto, že ve zdrojové databázi mezi nimi žádná vazba není nastavena. Po úspěšném odladění ETL skriptu jsem konečně mohl do QlikView nahrát data ze zdrojové databáze Northwind na SQL Serveru. Zpracování „Load skriptu“ a postupné nahrávání dat do aplikace QlikView zachycuje obrázek 14. Okno informuje uživatele o průběhu zpracování a počtech záznamů nahraných ze zdrojových do cílových tabulek, případně chybách vzniklých při ETL procesu.

6 Realizace výkonnostního testu

49

Obrázek 14 – Okno s probíhajícím ETL procesem (Autor)

Po úspěšném nahrání testovacích dat v požadované podobě si uživatel nepochybně chce uložit svojí odvedenou práci. Proto je dobré vědět, jakým principem funguje QlikView při práci se svými soubory. QlikView ukládá dokumenty s nataženými daty formou komprimovaných souborů, včetně logiky výpočtů, definice transformace dat a rozvržení objektů v návrhovém prostředí. Dosahuje tak několikanásobného zmenšení velikosti pracovního souboru, než je datová velikost původního zdroje dat (zdrojové databáze). To je jeden ze základních předpokladů pro práci s daty přímo do operační paměti. V mém případě bylo dosaženo cca osminásobné komprese oproti velikosti databázového souboru SQL Serveru. Hlavním důvodem pro komprimované ukládání dat je již zmiňované zpracování těchto dat v operační paměti, které nedosahují takových kapacit, jako je tomu u pevných disků. Jelikož QlikView pracuje s vlastní datovou základnou, bylo potřeba pro každou ze čtyř vytvořených instancí databáze Northwind připravit vlastní ETL skript. Všechny instance jsou provozovány na stejném lokálním serveru. Ve skriptu tedy stačilo pouze změnit název instance databáze a odvozené názvy tabulek ve formátu NazevDB.NazevTabulky. Dobu potřebnou pro získání a nahrání dat ze zdrojových databází přehledně znázorňuje graf na obrázku 15.

6 Realizace výkonnostního testu

50

Obrázek 15 – Měření doby potřebné k ETL procesu z jednotlivých databází (Autor)

Při získávání, transformaci a nahrávání záznamů je vhodné znát ukazatel, kolik záznamů dokáže server nebo koncová stanice při ETL procesu zpracovat: ● 5,5 milionů řádků – 141 026 řádků / sec., ● 11 milionů řádků – 144 736 řádků / sec., ● 16,5 milionů řádků – 129 921 řádků / sec., ● 27,5 milionů řádků – 82 831 řádků / sec. Z výsledků je patrné, že s rostoucím počtem záznamů nelineárně roste doba potřebná k zpracování dat ze zdrojového systému. V případě prvních dvou vzorků dat jsou výsledky téměř lineární. To je dáno především výkonem hardwaru, který jsem měl k dispozici. Každopádně to nic nemění na faktu, že je na platformě QlikView potřeba počítat s prodlužující se dobou trvání ETL procesu při zvyšujícím se objemu dat. ETL proces na QlikView in-memory platformě vybízí k položení důležité otázky. Tou je vlastní potřeba aktualizovaných dat, které chce mít uživatel k dispozici. V porovnání s reportingem v nástroji Reporting Services, který je součástí platformy SQL Serveru, je potřeba pro získání nejnovějších informací do QlikView in-memory databáze dostat aktuální data. V mojí praktické úloze je zdrojová báze dat uchovávaná v databázi provozované na SQL Serveru. V případě změny dat nebo přidání dat do databáze, uživatel pracující s Reporting Services získá aktuální výsledky. U platformy QlikView při zachování stejné architektury řešení nikoliv, jelikož zde nastává potřeba „loadu“ aktuálních dat ze zdrojové-

6 Realizace výkonnostního testu

51

ho systému. Tento fakt je potřeba brát v potaz a aktualizaci dat řešit v závislosti na objemu dat v noci mimo špičku či několikrát denně centrálním plánováním, nebo u menších objemů dat ad-hoc aktualizací přímo uživatelem koncové stanice. V případě serverového řešení přibývá řada dalších aspektů k uvážení (např. hybridní BI řešení s kombinací datových skladů, tržišť a in-memory databáze). To je však téma minimálně na samostatnou diplomovou práci.

6.3.2

Časová dimenze

Vytváření časových období, které jsou pro společnost zajímavé sledovat, se realizují prostřednictvím časové dimenze. Lze vytvořit vlastní časovou tabulku určením počátku a konce časového období, nastavením formátu data a nadefinováním obsahu časové dimenze (roky, měsíce, dny, kvartály atd.). Pro uživatele QlikView se však naskýtá jednodušší postup. Pokud obsahují zdrojová data sloupec ve formátu Date/Time, například datum objednávky, zle časovou dimenzi získat již na ETL vrstvě. To zajistí funkce Year, Month a další, které vyberou z kompletního záznamu požadovanou část. Výsledný záznam se v QlikView přidá jakožto další sloupec tabulky. V mojí praktické úloze jsem takto vygeneroval časovou dimenzi let a měsíců, kterou využívám při vytváření reportů. Zde uvádím výčet funkcí, které QlikView pro práci nejen s časovou dimenzí nabízí: ● Year(OrderDate) as Rok, ● Month(OrderDate) as Měsíc, ● Day(OrderDate) as Den, ● Hour(OrderDate) as Hodina, ● Minute(OrderDate) as Minuta, ● Second(OrderDate) as Vteřina. Příkaz pro odvození kvartálu roku z atributu typu Date/Time QlikView neumí. Uživatel si ho ale může sám jednoduše vypočítat kombinací dvou funkcí. ● Ceil(Month(OrderDate) / 3) as Kvartál.

6.3.3

Vytváření reportu

Tato kapitola se zabývá postupem návrhu reportu v nástroji QlikView, který sloužil pro měření výkonnosti zpracování dat in-memory metodou. Popisuje jednotlivé prvky reportu (výběrové seznamy, grafy a tabulky), jejich vnitřní logiku a smysl použití. V této fázi realizace praktické úlohy jsem měl připravená veškerá data v požadované formě. Mohl jsem tedy přistoupit k tvorbě finálního reportu.

6 Realizace výkonnostního testu

52

V prvním kroku je zapotřebí si udělat představu, k čemu výsledný report slouží, jaké prvky bude obsahovat a jaká data budou potřeba pro výpočty vizualizačních prvků. Mnou navržený report slouží zejména k otestování výkonu použité metody zpracování dat. To však nic nemění na faktu, že by měl disponovat vyjadřovací schopností o podnikání společnosti, jejíž data analyzuje. Rozhodl jsem se proto pro znázornění tržeb společnosti v čase, zastoupení těchto prodejů napříč regiony a vytvořením seznamu objednávek, které splňují vybraná kritéria. Výslednou podobu reportu znázorňuje obrázek 16.

Obrázek 16 – Výsledný report vytvořený v nástroji QlikView (Autor)

Výběr dat se v QlikView realizuje pomocí seznamů polí, tzv. „list boxů“, ve kterých stačí označit požadované hodnoty (viz zeleně označené hodnoty). Více hodnot lze označit táhnutím myší, nebo přidržením Ctrl a výběrem další hodnoty. Jak je z uvedeného reportu patrné, seznamy polí představují zároveň i dimenze pro omezení výběru dat. Nejprve tedy bylo potřeba vložit na pracovní plochu seznamy polí, na jejichž základě se měly omezovat data objednávek. Vložení se provede kliknutím pravým tlačítkem na pracovní plochu, příkazem „Select fields…“ a výběrem požadovaných polí do „Fields Diasplayed in Listboxex“. Ty se následně zobrazí na pracovní ploše. Jedná se o seznamy Region, Year a Month. Záhlaví seznamu lze samozřejmě přepsat, jinak se defaultně zobrazí vybraný název sloupce příslušné tabulky. Po vložení výběrových polí jsem mohl začít pracovat na vytvoření logiky použitých grafů. Spojnicový graf s názvem „Tržby z prodeje“ zobrazuje průběh prodejů společnosti ve vy-

6 Realizace výkonnostního testu

53

braných letech a měsících. Roky a měsíce v tomto případě zastávají časovou dimenzi. Bylo proto nutné vložit ve vlastnostech grafu, na záložce „Dimensions“ hodnoty Year a Month do pole „Used Dimensions“. Aby graf mohl zobrazovat průběh prodejů, bylo nejdříve nutné nadefinovat jeho vnitřní logiku. K tomu slouží záložka „Expressions“ kde bylo potřeba nadefinovat funkci pro výpočet průběhu grafu. To je možné buď přímo v poli „Definition“, nebo v editoru výrazu, kde má uživateli k dispozici výběr ze všech dostupných funkcí z několika kategorií. K výpočtu prodejů v daných období jsem nadefinoval následující funkci, která počítá tržbu z jedné objednávky (jednotková cena * množství) a vytváří z nich sumu pro konkrétní období podle data objednávky. sum(if (InYear (OrderDate, Today(), 0), UnitPrice*Quantity)) K promítnutí prodejů ve všech dosavadních letech, ve kterých společnost podniká, slouží poslední parametr vložené funkce InYear(). Předchozí roky jsem tak do grafu dostal vložením další stejné funkce tlačítkem „Add“, při pouhém upravení parametru 0, který díky funkci Today() vyjadřuje aktuální rok. Dá se tak docílit např. zobrazení posledních deseti let v grafu, nezávisle na tom jaký je auktuální rok. Funkce pro předchozí roky tedy vypadají následovně. sum(if (InYear (OrderDate, Today(), -1), UnitPrice*Quantity)) sum(if (InYear (OrderDate, Today(), -2), UnitPrice*Quantity)) sum(if (InYear (OrderDate, Today(), -3), UnitPrice*Quantity)) atd... V poslední fázi návrhu grafu jsem již jen přidal do grafu popisky os x a y, vytvořil mřížku grafu na záložce „Axes“ a vložil název grafu v záložce „General“. Graf umožňuje řadu dalších nastavení od změny typu grafu, až po nespočet kosmetických vizuálních úprav. Druhým grafem reportu je „Procentuální zastoupení tržeb v regionech“, který zobrazuje podíl tržeb v městech vybraných regionů. Použitou dimenzí je v tomto případě „City“. Pro detailnější náhled není problém vytvořit kombinaci dimenzí „Region“ a „City“. Uživatel by poté vybíral z rozevíracího seznamu přímo na grafu podřazenou dimenzi měst. Pro vypočtení celkového objemu prodejů, je grafu nadefinována funkce pro jeho výpočet obdobným způsobem, jako tomu bylo u předchozího grafu. Sum(UnitPrice*Quantity) Další komponentou vytvořeného reportu je náhledová tabulka objednávek, ve které jsou přehledně vypsané objednávky včetně jejich položek. Tabulka obsahuje ilustrativně vybrané informace o každé objednávce. Původně jsem tabulku realizoval pomocí kontingenční tabulky, kde uživatel ze seznamu objednávek mohl rozevírat její detaily. Každá objednávka tak obsahovala i výpočet celkové ceny. V porovnávaném prostředí Reporting Services, jsem se při tomto řešení dostal na dobu zpracování dat, nad daty nejmenší instance databáze Northwind_1, v trvání cca 8,5 hodin. To by znamenalo neúnosně dlouhé zpracování reportu nad daty instance Northwind_5, která obsahuje pětkrát tolik záznamů, než

6 Realizace výkonnostního testu

54

Northwind_1. Byl jsem proto nucen přistoupit ke zjednodušení logiky zpracování dat v reportu do podoby znázorněné obrázkem 16. Vlevo od tabulky „Detaily objednávek“ je vložený seznam s identifikačním číslem objednávek. Ten slouží čistě pro kontrolu stavu a obsahu objednávek. Doplňkovou součástí reportu je ukazatel doby poslední aktualizace dat dokumentu. V platformě QlikView se jedná o velmi důležitou informaci vzhledem k tomu, že uživatel je nucen aktualizovat data ze zdrojového systému. Ukazatel ho tak informuje o aktuálnosti či neaktuálnosti informací, které vidí před sebou na obrazovce prostřednictvím vygenerovaného reportu. K tomu slouží následující funkce. ='Poslední aktualizace dat:' & Reloadtime()

6.3.4

Měření doby zpracování

Po vytvoření sestavy reportu již nezbývalo nic jiného, než otestovat výkon QlikView in-memory zpracování dat. Měření probíhalo následujícím způsobem. Při práci s nástrojem QlikView jsem nepřišel na to, jak na jeho desktopové části zjistit dobu potřebnou pro zpracování reportu/dashboardu. QlikView nabízí několik časových funkcí, např. funkci pro zobrazení času posledního načtení dat do dokumentu nebo zobrazení systémového času. Nikoliv doby zpracování dat. Odpovědi se mi nedostalo ani na zákaznické podpoře a komunitním fóru. Byl jsem proto nucen hledat jinou cestu pro získání požadovaných hodnot. Jelikož nástroj při zpracování dat extrémně zatěžuje centrální procesorovou jednotku (CPU), vydal jsem se cestou monitorovacích nástrojů. Vzhledem k technologii QlikView, kde výběr dat probíhá interaktivně v reálném čase při označení požadovaných polí v dimenzi, lze rychlost zpracování dat měřit dvěma způsoby. Prvním možným způsobem je měření jednotlivých zpracování (aktualizace výsledků) dat při uživatelově výběru. Málokdy se ve finálním reportu objeví výběr pouze z jedné dimenze. V mém případě se jednalo o výběr prodejů v požadovaném roce, vybraných měsících a regionech. V tomto případě bych musel měřit všechny 3 fáze výběru. QlikView ovšem disponuje funkcí uzamčení výběru datových polí, kde si pro další otevření dokumentu zapamatuje uživatelem vybrané položky dimenzí. Při opětovném nahrání dat do dokumentu se tak provede kompletní přepočet a data se zpracují znovu již na nových datech. Tímto způsobem jsem docílil měření doby generování reportu v jedné fázi. Dobu zpracování dat jsem měřil pomocí nástroje pro monitorování zatížení procesoru, viz kapitola 5.2.6, kde jsem z grafu odečítal čas vytížení procesoru při generování reportu. Nástroj dokáže sledovat vybrané spuštěné aplikace nebo procesy nezávisle na sobě, což je v tomto případě usnadnění pro odečtení zátěže. Výsledky měření poskytuje kapitola 6.5 – Vyhodnocení benchmarku.

6 Realizace výkonnostního testu

6.4

55

Testování v Reporting Services

Tato kapitola se věnuje přípravě reportu použitého pro testování konvenční metody zpracování dat na pevném disku. K testování byl použit nástroj MS Visual Studio 2010 SP1, který podporuje službu SQL Server Reporting Services. Základním předpokladem pro objektivní testování porovnávané metody zpracování dat, bylo vytvořit report korespondující s reportem z předchozí kapitoly (srovnávaného nástroje QlikView), zpracovávající současně stejná data. Pouze s tím rozdílem, že Reporting Services pracují s jinou technologií zpracování a analýzy dat. Po spuštění nástroje a založení nového projektu na úvodní obrazovce nástroje, se uživateli zobrazí prázdná plocha se sloupcem datových zdrojů, datových sad a vlastních reportů. Okno nástroje je rozdělené na tři hlavní celky. Horní část obsahuje klasické textové menu, pomocí kterého může uživatel využívat všechny dostupné funkce nástroje. Levá část slouží pro zobrazení sloupce s přehledem uživatelových datových zdrojů, sad a parametrů. Zbytek pracovní plochy je určený k návrhu vlastního reportu. Prvním krokem před návrhem reportu, bylo připojení se na zdrojovou bázi dat a vybrání potřebných dat, vstupujících do reportu.

6.4.1

ETL proces

Při získávání dat pro potřeby reportingového nástroje Reporting Services, jsem na rozdíl od QlikView nemusel složitě připravovat data k nahrání do nástroje. Reporting Services je služba platformy MS SQL Server, a tak pro připojení k databázi stačí jednoduše nastavit připojení nástroje k serveru (SQL Server je nastaven jako defaultní volba) a vybrat požadovanou databázi, viz obrázek 17. Řetězec pro připojení vypadá ve finále následovně: Data Source=CIGI-HP;Initial Catalog=Northwind_3 Výběr dat se v Reporting Services realizuje prostřednictvím datových sad (Datasets). K tomu slouží „Query designer“, ve kterém se vybere v předchozím kroku nadefinovaný zdroj dat a prostřednictvím SQL dotazu se vyberou potřebné tabulky se sloupci, jejichž data uživatel bude v reportu používat. Případně se může v SQL nadefinovat další omezení při výběru dat (např. klauzulí WHERE). V tomto kroku se uplatňují všechny potřebné transformace dat. Pro transformaci dat jsou k dispozici veškeré funkce jazyka SQL a další dostupné transformační funkce nástroje.

6 Realizace výkonnostního testu

56

Obrázek 17 – Připojen služby Reporting Servicesí k databázi (Autor)

6.4.2

Časová dimenze

Časovou dimenzi lze v Reporting Services vytvořit na úrovni ETL vrstvy velmi podobným způsobem jako tomu bylo v QlikView. Zdrojová data sloupce ve formátu Date/Time jsem pomocí funkcí Year a Month převedl do požadovaného formátu. Výsledný záznam se přidá jako další položka datové sady. V mojí praktické úloze jsem takto vygeneroval časové dimenze let a měsíců, které používám při analýze dat. V nastavení datové sady se takto získané pole nadefinují v záložce „Fields“. Zde uvádím použití funkcí, které jsem použil k dostání časové dimenze ze sloupce s datem objednávky. =Year(Fields!OrderDate.Value) =Month(Fields!OrderDate.Value)

6.4.3

Vytváření reportu

Po úspěšném vybrání zdrojových dat, které si uživatel může ověřit v náhledu dat „Query designeru“, nezbývalo než se pustit do návrhu vlastního reportu. Výsledný report obsahuje

6 Realizace výkonnostního testu

57

stejné prvky, jako report navržený v nástroji QlikView. V této kapitolo proto uvedu pouze odlišnosti a náležitosti, kterými se postup jeho vytváření v Reporting Services liší. Report v jeho finální podobně zachycuje následující obrázek 18.

Obrázek 18 - Výsledný report vytvořený v nástroji QlikView (Autor)

Výběr dat se v prostředí Reporting Services realizuje pomocí filtrů omezujících datovou sadu. V horní části obrázku 18 je vymezený prostor pro vstupní parametry, ze kterých uživatel vybírá před vlastním generováním reportu. Po výběru parametrů následuje stisknutí tlačítka „View report“. Jak parametry, potažmo vstupní filtry v Reporting Services fungují, vysvětluji níže na příkladu výběru regionů. Report vytvářený v obou prostředích disponuje funkcí omezení dat podle určených regionů. V Reporting Services je pro takovou funkcionalitu nutné provést několik kroků. V první řadě bylo potřeba vybrat data, na jejichž základě se budou data objednávek filtrovat. Těmi jsou zkratky regionů. Jelikož každá objednávka spadá pod určitý region, musel jsem data regionů nejprve vyfiltrovat, abych dostal při výběru seznam regionů, který bude obsahovat každý region pouze jedenkrát. Pro tento účel mi posloužila pomocná datová sada, kterou jsem si nazval Region_codelist. Tu definuje jednoduché omezení opět pomocí SQL příkazu. SELECT DISTINCT Region AS Expr3 FROM Customers

6 Realizace výkonnostního testu

58

V dalším kroku bylo zapotřebí vytvořit parametr Region. Ten jsem získal po kliknutí pravým tlačítkem na seznam parametrů a výběrem funkce „Add Parameter…“. Nastavení parametru je pochopitelně stěžejní fází pro jeho správnou funkčnost. Název lze zvolit takřka dle libosti. Pole „Prompt“ vyjadřuje text, který se objeví u seznamu hodnot parametru před vlastním generováním reportu. Zvolil jsem tedy pro koncového uživatele srozumitelné, „Vyber region“. Dále je nutné vědět, o jaký datový typ záznamu se jedná, v tomto případě datový typ Text. Pokud má výběr umožňovat zvolit z více dostupných položek, je nasnadě zaškrtnout „Allow multiple values“. Další záložka „Available Values“ slouží pro výběr dat, která budou v seznamu k dispozici. Zvolil jsem proto možnost „Get values from query“, vybral datovou sadu obsahující mnou omezený seznam regionů a jako „Value field“ dříve vytvořený Region_codelist. Tím jsem úspěšně vytvořil parametr pro zadání zákaznických regionů. Závěrečnou fází bylo přidání parametru do hlavní datové sady reportu. K tomu slouží ve vlastnostech datové sady záložka „Filters“. Tlačítkem „Add“ se přidá filtr. V případě regionů jsem do pole „Expression“ vybral pomocnou datovou sadu Region_codelist včetně datového typu Text. Pokud jsem v předchozím kroku zvolil možnost výběru více položek pro omezení dat, je potřeba zvolit jako operátor „In“. V případě výběru pouze jedné možnosti postačí operátor „=“. Do pole „Value“ jsem vybral z kategorie parametrů v předchozím kroku vytvořený parametr @Region. Obdobným postupem jsem do reportu začlenil i pole pro výběr časového období, ve kterém budou zanalyzována data objednávek. Seznam parametrů potom vypadá následovně.

Obrázek 19 – Parametry omezující datovou sadu reportu v Reporting Services (Autor)

6 Realizace výkonnostního testu

59

Spojnicový graf „Tržby z prodeje“ evidentně koresponduje s grafem vytvořeným v nástroji QlikView. Časovou dimenzi zde reprezentuje osa x, na které jsou nanášeny měsíce a vybraný rok. To jsem v nastavení grafu realizoval pomocí pole „Category Groups“, kam stačilo z datové sady přetáhnout pole Months. Samotný průběh tržeb ve vybraných letech vyznačuje pole „Series Groups“, do kterého jsem umístil pole datové sady Years. Vnitřní logika grafu počítá celkové tržby z uzavřených objednávek. Pro její definici v nastavení vlastností grafu slouží pole „Values“. Funkce potom vypadala následovně. =Sum(Fields!UnitPrice.Value*Fields!Quantity.Value) Koláčový graf stejně jako v předchozím případě znázorňuje prodeje napříč vybranými městy regionů. Do pole „Category Groups“ jsem tedy umístil dimenzi měst, City. Výpočet grafu je stejný jako u „Tržeb z prodeje“, jen vyjádřený jinou dimenzí. Poslední komponentou navrhovaného reportu je tabulka s objednávkami. Do jednotlivých sloupců jsem vložil požadované pole datové sady, od čísla objednávky až po množství, identifikační číslo a cenu produktů objednávky. První sloupec tabulky, číslo objednávky, jsem upravil funkcí „Add Group“, která slouží pro sjednocení stejných, po sobě jdoucích záznamů, sloupce či řádku tabulky. Tím jsem docílil zobrazení pouze jednoho čísla objednávky pro všechny její položky. Obdobně bych mohl postupovat i pro datum objednání a další doručovací údaje. Pro potřeby výkonnostního testování to však bylo nepodstatné. Zároveň jsem chtěl dodržet stejnou formu reportu, jako u porovnávaného nástroje QlikView. V této fázi jsem docílil funkcionalitou stejného reportu jak v QlikView, tak v prostředí Reporting Services. Nezbývalo tedy, než přistoupit k měření doby zpracování dat konvenční metodou na pevném disku.

6.4.4

Měření doby zpracování

Měření doby zpracování výsledného reportu bylo v Reporting Services o poznání jednodušší záležitostí. Jelikož jsem omezení vstupních dat pro vytváření reportu nastavil před samotným generováním pomocí parametrů, stačilo pouze změřit dobu, za kterou se na obrazovce zobrazil hotový report. Platforma MS SQL Server 2012 disponuje pro ladění výkonnosti funkcemi pro zaznamenávání průběhu zpracování reportů. Data o průběhu zpracování ukládá do předem vytvořené databáze ReportServer, která je k dispozici v seznamu uživatelových databází. Tato funkcionalita není po instalaci balíčku nástrojů SQL Serveru defaultně povolená. Musel jsem jí proto povolit v nástroji SQL Server Management Studio, po připojení k službám Reporting Services a ve vlastnostech reportovacího serveru na záložce „Logging – Enable report execution logging“. Zároveň lze nastavit, po kolik dní se budou data o zpracování

6 Realizace výkonnostního testu

60

reportů uchovávat. Defaultně se data uchovávají po dobu 60 dnů. Starší data jsou mazána ve 2 hodiny ráno serverového času (u lokální stanice systémový čas). Informace o průběhu zpracování vyjadřuje několik atributů. Pro mě nejpodstatnější byl atribut s názvem TimeDataRetrieval, který udává čas v milisekundách, od spuštění náhledu reportu, přes obdržení dat, výpočty nad daty, až do konce tohoto procesu a zobrazení zpracovaného reportu uživateli. Orientace v databázi je poměrně nepřehledná, proto jsem pro náhled výsledků použil předpřipravené „View“. Use ReportServer select * from ExecutionLog3 order by TimeStart DESC Při měření zpracování dat diskovou metodou jsem narazil na jeden problém. Při zpracování dat největší instance z hlediska objemu dat, databáze Northwind_5, mi prostředí Reporting Services po několika hodinách zpracovávání reportu podávalo chybové hlášení s označením System.OutOfMemoryException. Při zpracování dat totiž docházelo k úplnému zaplnění operační paměti. Abych výkonnostní test dotáhnul do konce, dokoupil jsem si druhý paměťový modul a rozšířil tak dostupnou operační paměť laptopu na 8 GB, což jsem měl stejně v plánu nezávisle na diplomové práci. Zároveň jsem v konfiguračním souboru RSReportServer,config musel upravit parametr WorkingSetmaximum, který udává velikost alokované paměti pro reportovací server. Pro dodržení zásad testování jsem provedl všechny testy znovu na nové konfiguraci. Výsledky měření poskytuje kapitola 6.5 – Vyhodnocení benchmarku.

6.5

Vyhodnocení benchmarku

Výkonnostní benchmark porovnává výkonnost zpracování dat dvou aplikovaných metod. K testování bylo v obou metodách použito totožných vzorků dat různého datového objemu. Zdrojová data byla připravena do čtyř instancí databáze Northwind. První metodou je in-memory analýza dat, kterou v praktické úloze zastupuje část prováděná na platformě QlikView. Druhou, konvenční metodu zpracování dat pevným diskem, reprezentuje testování ve službě Reporting Services, která pracuje na platformě Microsoft SQL Serveru. Testování probíhalo vytvářením funkcionalitou identických reportů v obou nástrojích. Report byl v každém nástroji vygenerován nad všemi vzorky zdrojových dat a po jeho úspěšném vygenerování byl zaznamenán čas, který nástroj potřeboval pro zpracování dat a následné zobrazení výsledku. Dosažené výsledky měření ilustruje graf na následující straně (viz obrázek 20).

6 Realizace výkonnostního testu

61

Obrázek 20 – Výsledky měření aplikovaných metod zpracování dat (Autor)

6 Realizace výkonnostního testu

62

Spojnicový graf zachycuje všechna provedená měření v závislosti na počtu záznamů zdrojových dat a aplikované metodě zpracování a analýzy dat. Vzhledem k řádově velmi rozdílným výsledkům obou metod bylo obtížné stanovit jednotku času, kterou zpracování dat zabralo. Rozhodl jsem se pro průběh křivek zvolit jednotky hodin v kombinaci s logaritmickým měřítkem osy y. V klasickém měřítku zanikal průběh in-memory metody zpracování dat, jelikož se překrýval a splýval s osou x. Pro doplnění vypovídací schopnosti grafu přikládám tabulku s daty zpracování ve standardním časovém formátu. Tabulka 9 – Výsledky měření aplikovaných metod zpracování dat (Autor) Vzorek dat

Konvenční metoda [hh:mm:ss]

In-Memory metoda [hh:mm:ss]

Počet záznamů [mil.]

Northwind_1

1:49:46

0:00:04

5,50

Northwind_2

3:57:11

0:00:06

11,0

Northwind_3

6:51:32

0:00:09

16,5

Northwind_5

13:06:01

0:00:13

27,5

Z grafu je na první pohled patrná naprosto jasná dominance in-memory metody zpracování dat z hlediska její rychlosti. Při měření na prvním vzorku dat dosahuje in-memory metoda přibližně 1660x rychlejšího dosažení výsledku, než metoda zpracování dat na pevném disku. Při použití druhého vzorku dat je tento rozdíl cirka 2300násobný a v případě posledního vzorku dat dokonce více než 3600násobný, což je obrovský rozdíl. „Disková metoda“ zpracování dat má při proložení do klasického měřítka grafu exponenciální průběh, který markantně roste s vyššími objemy dat. To přičítám i výkonnosti použitého hardwaru, na kterém jsem úlohu zpracovával. Naopak in-memory metoda si zachovává i při velkých objemech dat vynikající výkonnost, reprezentovanou takřka ideálně lineárním průběhem. Při použití in-memory zpracování dat je potřeba vzít do úvahy nutnost nahrávání dat do operační paměti, které u konvenční metody odpadá, jelikož se data zpracovávají přímo v místě jejich uložení. V odkazu na kapitolu 6.3.1 je potřeba zmínit, že doba nahrání dat ze zdrojových systémů s jejich přibývajícím objemem exponenciálně roste. Proto je před výběrem řešení pro zpracování dat nutné zhodnotit, jak náročné analýzy podnikových dat zákazník potřebuje a jak často je bude provádět. To vše s ohledem na frekvenci aktualizací dat ze zdrojových systémů. Pro objektivní srovnání obou metod je nutné podotknout, že platforma SQL Serveru není koncipována pro provoz serverové části na koncovém zařízení běžného uživatele (v mém případě lokální server běžící na laptopu). Testovací hardware byl tak značně zatížen pracu-

6 Realizace výkonnostního testu

63

jícím serverem. Přesto výkonnostní testování potvrdilo řádový rozdíl v rychlosti zpracování dat in-memory metodou.

6.6

Závěr kapitoly

Text této kapitoly čtenáře seznámil s postupem zpracování a výsledky výkonnostního benchmarku. Jeho vyhodnocení potvrdilo výkonnostní výhodu in-memory řešení, která byla ilustrována na příkladu reportingového nástroje při zpracování několika vzorků velmi objemných dat (z pohledu použitého hardwaru). Kapitola předložila základní informace pro práci s reportingovými nástroji QlikView a Visual Studio, respektive služnou Reporting Services a platformami, na kterých nástroje pracují. Jednotlivé podkapitoly se snažily krok po kroku provádět čtenáře návrhem reportů v obou nástrojích a vlastními metodami testování s důrazem na úskalí a nedostatky uvedených nástrojů.

7 Shrnutí analýzy jako vstup do modelu MBI

64

7 Shrnutí analýzy jako vstup do modelu MBI Tabulka 10 – Faktor In-Memory zpracování dat (Autor) Název faktoru

In-Memory BI

Autor

Lukáš Cígler

Datum poslední úpravy

2013-05-03

Popis, obsahové vymezení

In-memory Business Intelligence (BI) je nové pojetí konceptu BI, které pro zvýšení výkonu ve své architektuře používá komponentu in-memory databází. Existuje několik přístupů k in-memory koncepci. Prvním přístupem je kompletní in-memory řešení, nebo integrace in-memory databáze do stávajícího řešení BI. Efekty, výhody uplatnění faktoru

● Umožňuje díky výkonu in-memory databáze analyzovat data doslova v reálném čase, s dobou odezvy pouhých několika sekund. Hodí se pro zpracování velkých objemů dat a pro složité výpočty nad těmito daty.

● Pomáhá odstínit zátěž vedlejších i zdrojových systémů. Různé systémy disponují různou dobou odezvy, která se navíc mění se stupněm zátě-že těchto systémů. Přidáním komponenty in-memory databáze do řešení BI se tak značně odlehčí zátěž vedlejších systémů, včetně systémů zdrojových.

● Nastartování procesu zlepšení datové kvality. Dostupnost informací je základním předpokladem datové kvality. Díky zvýšení výkonnosti analýzy dat uživatel získá informace v požadovaném čase (nebo alespoň výrazně aktuálnější informace).

● Jednodušší provoz a údržba systému. Jelikož analytické aplikace pracují nad obrovským množstvím dat, vyžadují vysoký výpočetní výkon. S kompletním in-memory řešením není již potřeba složitě budovat architekturu BI po výše uvedených vrstvách (nákup HW, SW, implementace, integrace aplikací a dat, ladění systému). In-memory řešení je možné získat od jediného dodavatele v mnohem kratším čase a tím snížit náklady na provoz a údržbu systému.

● Standardizované BI aplikace – S příchodem koncepčně „jednoduchého“ in-memory řešení BI není třeba vyvíjet aplikace šité zákazníkovi na míru, nebo vyvíjet kompletní řešení na „zelené louce“. Již dnes několik dodavatelů nabízí hotové řešení BI pro standardizované systémy typu ERP, CRM a další. Ty obsahují předdefinované komponenty pro jednotlivé vrstvy (ETL, vlastní datový model, sady reportů a dashboardů).

● Masové rozšíření BI. Díky jednoduššími nasazení, nárůstu výkonu i novému typu BI aplikací postupně dojde k postupnému rozšíření řešení BI mezi širší okruh uživatelů. Vzhledem k flexibilitě škálování řešení, si ho budou moci v budoucnu dovolit i malé a střední podniky.

7 Shrnutí analýzy jako vstup do modelu MBI

65

Problémy, otázky uplatnění faktoru

● Cena nejvýkonnějších řešení zůstává díky vysoké ceně operačních pamětí prozatím velmi vysoká. Díky tomu si mohou in-memory BI pro zpracování opravdu velkých objemů dat dovolit jen velké společnosti.

● Pro úspěšnou implementaci řešení je potřeba zvolit vhodný přístup pro danou situaci, ve které se podnik nachází. Na základě potřeb podniku je klíčové vybrat komponenty řešení tak, aby plně vyhovovaly jeho potřebám.

● Využití in-memory databází bez použití energeticky nezávislých operačních pamětí typu NVRAM s sebou nese zásadní nedostatek takového řešení. Tím je potřeba nahrání dat do in-memory databáze ze zdrojových systémů nejen při plánované aktualizaci, ale i při výpadku systému. Presentace Poznámky

8 Závěr

66

8 Závěr Tématem diplomové práce bylo zpracování a analýza dat v operační paměti. In-memory zpracování dat se protlačilo na trh s rostoucí poptávkou po vyšší výkonnosti analytických systémů. In-memory principy se tak pochopitelně nevyhnuly ani oblasti Business Intelligence (BI). Práce se v její teoretické části zabývá důvody nástupu in-memory zpracování dat a jeho masovým rozšířením zejména v oblasti BI. Objasňuje a diskutuje rozdíly mezi principy a technologiemi konvenčního diskového a in-memory zpracování dat. Dále přináší základní faktický rámec o oblasti in-memory databází a architektuře řešení BI. Výstupem této části je zhodnocení předností a nedostatků in-memory principů zpracování a analýzy dat, jejich možné nasazení pro potřeby řešení BI a poukázání na klíčové aspekty, které je potřeba při výběru in-memory konceptu brát v potaz. Hlavním cílem práce bylo porovnat obě zmíněné metody zpracování dat z hlediska jejich výkonu. K tomu slouží praktická část diplomové práce, kterou tvoří výkonnostní srovnání (benchmark) dvou vybraných reportingových nástrojů. Reportingovým nástrojem zastupujícím in-memory řešení je QlikView od společnosti Qlik. Nástrojem pracujícím konvenční diskovou metodou je Reporting Services na platformě SQL Serveru 2012 od společnosti Microsoft. V úvodu praktické úlohy je definována metodika testování. Dále jsou uvedeny jednotlivé nástroje, se kterými jsem v úloze pracoval včetně nejdůležitějších poznatků, které považuji pro práci s nimi za podstatné. Poté následuje vlastní realizace výkonnostního testu, pro který bylo potřeba připravit několik vzorků dat, připojit reportingové nástroje na zdrojové databáze, vytvořit testovací reporty a konečně naměřit výsledky zpracování dat. Oba nástroje úspěšně posloužily při tvorbě výkonnostního benchmarku a lze je obdobně využít pro podobné úlohy v praxi. Hlavní přínos práce spatřuji v přehledném, graficky znázorněném vyhodnocení výkonnostního benchmarku. Naměřené výsledky jasně prokazují obrovskou výkonnostní převahu in-memory zpracování dat oproti běžným „on-disk“ principům. Zároveň výstupní kapitoly první části práce mohou mnohým uživatelům a manažerům podniků usnadnit rozhodování při volbě nasazovaného řešení BI. Aktuální potřeba interpretace dat, vytěžení pokud možno maximální informační hodnoty při jejich zpracování a poměr ceny takového řešení, je vyšší než kdy jindy. Je zřejmé, že s rostoucím objemem podnikových dat, si již společnosti nevystačí se dosavadními řešeními. Současný i budoucí trend v řešení BI vidím ve využití potenciálu jak konvenčních, tak in-memory principů zpracování dat. Je potřeba maximálně vytěžit z jejich vhodné kombinace a tím eliminovat nedostatky té či oné technologie. Současně ani finanční možnosti podniků nejsou takové, aby si mohly dovolit pořídit to nejlepší dostupné hardwarové vybavení pro svoji podnikovou infrastrukturu.

8 Závěr

67

V praxi mohou čtenáři využít poznatky získané jak v teoretické, tak praktické části práce. Zároveň jsem pro samotný závěr vytvořil sadu klíčových otázek, které by si mělo vedení společnosti položit, pokud se bude rozhodovat, jakou metodu zpracování dat zvolit, potažmo jakou koncepci in-memory řešení BI vybrat. ● Jak velká data je zapotřebí analyzovat? ● Jaké technologické prostředky má společnost k dispozici, případně jakou mají data pro společnost hodnotu, pokud by se mělo investovat do hardwarové infrastruktury či částečné inovace stávajícího řešení? ● Jaký je očekávaný denní, měsíční a roční přírůstek dat? ● Jak často se podniková data mění? ● Je potřeba data analyzovat jen jednou za určité období (den, týden), nebo společnost potřebu zpracování dat v reálném čase, se zpožděním jen několika málo sekund? Při použití in-memory technologií může společnost analyzovat data doslova v reálném čase, vytěžit z nich maximální informační hodnotu a naplno tak využít nových tržních příležitostí, využít doslova sílu okamžiku. Jako námět pro další rozšíření diplomové práce z hlediska zkoumání výkonu in-memory metody zpracování dat se nabízí detailní testování QlikView platformy na serverové části. Za hlubší analýzu by stálo udělat srovnání řešení při různých principech propojování zdrojových dat. Například porovnání stejných dat ve schématu „star a snowflake“, nebo při použití rozdílných propojení tabulek pomocí odlišných přístupů „SQL joinů“. Zároveň by bylo zajímavé realizovat výkonnostní benchmark nad stejnými daty, použitými v praktické úloze této práce, ovšem za využití specializovaných výkonných serverů pro obě metody zpracování dat.

Terminologický slovník

68

Terminologický slovník Termín Benchmark

Business Intelligence

Business Discovery

Caching

Customer Relationship Management

Zkratka -

BI

Význam [zdroj] Metoda srovnání hodnot určité veličiny za použití jasně vymezené metody (Autor). Sada procesů, aplikací a technologií, jejichž cílem je účinně a účelně podporovat rozhodovací procesy ve firmě. Podporují plánovací a analytické činnosti podniků a organizací a jsou postaveny na principech multidimenzionálních pohledů na podniková data [30].

-

Termín společnosti Qlik pro označení nástrojů Data Discovery (Autor).

-

Technologie využívaná ve výpočetní technice, která se umisťuje mezi dva systémy s rozdílným výkonem a vyrovnává tak rychlost přístupu k datům (Autor).

CRM

Komplex aplikačního a základního software, technických prostředků, podnikových procesů a personálních zdrojů určených pro řízení a průběžné zajišťování vztahů se zákazníky firmy, a to v oblastech podpory obchodní činnosti, zejména prodeje, marketingu a zákaznických služeb [26]. Vizuální zobrazení nejdůležitějších informací, které jsou potřebné pro dosažení jednoho nebo více cílů na jediné obrazovce monitoru tak, aby bylo umožněno snadné sledování (Few, 2006).

Dashboard

-

Data Mart

DM

Datové tržiště je tematicky orientovaný datový sklad (Autor).

Data Staging Area

DSA

Dočasné úložiště extrahovaných dat z produkčních systémů, které slouží pro podporu rychlého a efektivního výběru dat [26].

Data Warehouse

DWH

Datový sklad je integrovaný, subjektově orientovaný, stálý a časově rozlišený souhrn dat, uspořádaný pro podporu potřeb managementu (Inmonn, 2002).

Enterprise Resource Planning

ERP

Typ aplikačního software, který umožňuje řízení a koordinaci všech disponibilních podnikových zdrojů a aktivit. Mezi hlavní vlastnosti ERP patří schopnost automatizovat a integrovat klíčové podnikové procesy, funkce a data v rámci celé firmy [26].

Extraction, Transformation and Loading

ETL

Nástroje určené k získávání dat ze zdrojových systémů, jejich transformaci do požadované formy a finální nahrání do specifické datové struktury (Autor).

Terminologický slovník

Termín

69

Zkratka

Význam [zdroj]

Hard Disk Drive

HDD

Pevný disk, který slouží k dočasnému nebo trvalému uchování dat. Data zapisuje na plotny magnetickou indukcí [14].

Hardware

HW

Veškeré fyzicky existující vybavení počítače včetně jeho periferií, síťových prvků, nosičů dat a dalších zařízení (Autor).

In-memory databáze

-

Databáze, které uchovávají a zpracovávají data přímo v operační paměti. K uložení dat používají značnou kompresi a ke zpracování dat specifických principů, odlišných od relačních databází [4].

Metadata

-

Data o datech. Z pohledu řešení BI zahrnují zejména datové modely, popisy funkcí, business a transformačních pravidel, reportů či požadavků na reporty apod. (Slánský, 2004).

Non-Volatile RAM

NVRAM

Energeticky nezávislá RAM vybavená záložním zdrojem napájení [4].

Object Linking and Embedding Database

OLE DB

Databázová technologie sloužící k poskytování univerzálního přístupu k datům (Microsoft).

OLAP

Informační technologie založená na koncepci multidimenzionálních databází. Jejím hlavním principem je několikadimenzionální tabulka umožňující rychle a pružně měnit jednotlivé dimenze, a měnit tak pohledy uživatele na modelovanou ekonomickou realitu [30].

ODBC

Standardizované aplikační rozhraní pro přístup k databázovým systémům. Jeho snahou je poskytovat přístup nezávislý na operačním systému, programovacím jazyku a databázovém systému (Microsoft).

Operational Data Store

ODS

Databáze vytvořená pro účely integrace dat z různých zdrojových systémů a pro další zpracování těchto dat (Autor).

Random Access Memory

RAM

Paměť s přímým přístupem, u níž je libovolné místo v paměti přístupné za stejnou vybavovací dobu [4].

RDBMS

Databázový systém, který spravuje uživatelské databáze, komunikaci s klienty, vstupní a výstupní data a jejich integritu [12].

Report

-

Výstupní dokument reportingové činnosti, který vizualizuje informace formou tabulek, grafů a dalších grafických prvků (Autor).

Reporting

-

Činnosti spojené s dotazováním se do databází pomocí standardních rozhraní těchto databází (např. SQL příkazů v rámci relačních databází) [30].

On-Line Analytical Processing

Open Database Connectivity

Relational DataBase Management System

Terminologický slovník

Termín

70

Zkratka

Význam [zdroj]

Software

SW

Veškeré programové vybavení počítače včetně operačního systému (Autor).

Solid State Drive

SSD

Paměťové médium pro dočasné nebo trvalé uchování dat, které neobsahuje pohyblivé mechanické části. Data ukládá na energeticky nezávislou flash paměť (Autor).

Structured Query Language

SQL

Nejrozšířenější databázový jazyk umožňující uživateli IS komunikovat s databázovým systémem. Jazyk umožňuje zejména definovat datové struktury, manipulovat s daty (operace Insert, Update, Delete, Select) a řídit přístup k datům (Slánský, 2004).

Supply Chain Management

SCM

Typ podnikových aplikací pro podporu pokročilého plánování, rozvrhování a řízení dodavatelských řetězců [26].

Seznam literatury

71

Seznam literatury [1] IDC. Extracting Value from Chaos [online]. 2011 [cit. 2014-03-19]. Dostupné z: [2] VEBER, SRPOVÁ a kol. Podnikání malé a střední firmy. 3. aktualizované vydání. Praha: Grada, 2012. 336s. ISBN 978-80-247-4520-6. [3] POUR, MARYŠKA, NOVOTNÝ. Business Intelligence v podnikové praxi. Praha: Professional Publishing, 2012. 276s. ISBN: 978-80-7431-065-2. [4] GRAVES Steve. In-memory database systems [online]. 2002 [cit. 2014-04-16]. Dostupné z: [5] RUSSOM, Philip. Big Data Analytics [online]. 2011 [cit. 2014-03-18]. Dostupné z: [6] RUSSOM, Philip. Managing Big Data [online]. 2013 [cit. 2014-03-18]. Dostupné z: [7] SOUKUP, Petr. High-Performance Analytics [online]. Diplomová práce. Praha: Vysoké škola ekonomická v Praze, 2013 [cit. 2014-03-27]. Dostupné z: [8] JANOŠEK, Tomáš. Aplikace typu BI v podnikové praxi [online]. Diplomová práce. Praha: Vysoké škola ekonomická v Praze, 2010 [cit. 2014-03-28]. Dostupné z: [9] STAŠKO, Tomáš. Tvorba dashboardov v nástroji QlikView [online]. Diplomová práce. Praha: Vysoké škola ekonomická v Praze, 2011 [cit. 2014-03-28]. Dostupné z: [10] KOPECKÝ, Martin. Porovnání nástrojů pro Data Discovery [online]. Diplomová práce. Praha: Vysoké škola ekonomická v Praze, 2012 [cit. 2014-03-29]. Dostupné z: [11] QLIK. QlikView Reference Manual. 2013. 960s. Dostupné s instalací produktu QlikView 11 [12] LACKO, Ľuboslav. Business intelligence v SQL Serveru 2008 : reportovací, analytické a další datové služby. Praha: Computer Press, 2009. 456s. ISBN: 978-80-251-2887-9 [13] KERNER Matthew. A History of Modern 64-bit Computing [online]. 2007 [cit. 201404-21]. Dostupné z: [14] PELOUŠEK Jakub. Jak pracují pevné disky [online]. 2012 [cit. 2014-04-26]. Dostupné z: [15] McCALLUM Jonh C. Average cost of hard drive storage [online]. 2013 [cit. 2014-0422]. Dostupné z: [16] McCALLUM Jonh C. Average historic price of RAM [online]. 2013 [cit. 2014-04-22]. Dostupné z:

Seznam literatury

72

[17] ORACLE. Server and Storage Systems [online]. 2014 [cit. 2014-04-23]. Dostupné z: [18] SAP. What is SAP HANA? [online]. 2014 [cit. 2014-04-26]. Dostupné z: [19] SAP. Whitepaper - SAP HANA Performance [online]. 2012 [cit. 2014-04-26]. Dostupné z: [20] HLAVIČKA, Ondřej. Potenciál in-memory BI [online]. 2012 [cit. 2014-03-13]. Dostupné z: [21] DELOITTE. Technology, media & telecommunications predictions 2014 [online]. 2013 [cit. 2014-04-01]. Dostupné z: [22] RED GATE. SQL Data generator [online]. 2014 [cit. 2014-04-14]. Dostupné z: [23] GARTNER. Magic Quadrant for Business Intelligence and Analytics Platforms [online]. 2014 [cit. 2014-04-06]. Dostupné z: [24] QLIK. Who is Qlik? [online]. 2014 [cit. 2014-04-14]. Dostupné z: [25] QLIK. The associative experience [online]. 2010 [cit. 2014-04-10]. Dostupné z: [26] GÁLA, POUR, ŠEDIVÁ. Podniková informatika. 2., přepracované a aktualizované vydání. Praha: Grada, 2009. 496s. ISBN: 978-80-247-2615-1. [27] SLÁNSKÝ, David. Řešení úloh Business Intelligence se zaměřením na prostředí telekomunikačních společností [online]. Disertační práce. Praha: Vysoké škola ekonomická v Praze, 2004 [cit. 2014-04-09]. Dostupné z: [28] MICROSOFT. Northwind and Pubs sample databases for SQL Server 2000 [online]. 2014 [cit. 2014-04-16]. Dostupné z: [29] DB SOFTWARE LAB. QlikView connector – Overview [online]. 2014 [cit. 2014-0419]. Dostupné z: [30] NOVOTNÝ, POUR, SLÁNSKÝ. Business Intelligence: Jak využít bohatství ve vašich datech. Praha: Grada, 2005. 256s. ISBN 80-247-1094-3.

Seznam obrázků a tabulek

Seznam obrázků a tabulek Seznam obrázků

Obrázek 1 – Tok dat v konvenčním databázovém systému (Graves, 2002) ..................... 14 Obrázek 2 – Obecná koncepce architektury BI (Novotný et al., 2005) .............................. 17 Obrázek 3 – Hybridní koncepce architektury BI (Hlavička, 2012)...................................... 21 Obrázek 4 – In-memory koncepce architektury BI (Hlavička, 2012) .................................. 22 Obrázek 5 - Proces řešení praktické úlohy (Autor) ............................................................ 26 Obrázek 6 – Magický kvadrant pro BI a analytické platformy (Gartner, 2014) ................... 32 Obrázek 7 – Schéma QlikView platformy (Qlik, 2014) ....................................................... 33 Obrázek 8 – QlikView architektura z pohledu uživatelských rolí (Qlik, 2014) .................... 34 Obrázek 9 – Srovnání tradiční a asociativní technologie (Qlik, 2010) ............................... 35 Obrázek 10 – Upravený datový model databáze Northwind v prostředí SQL Server Management Studia (Autor) ............................................................................................... 40 Obrázek 11 – Nastavení připojení generátoru dat na databázový server (Autor) .............. 43 Obrázek 12 – Pracovní prostředí nástroje SQL Data Generator 3.0 (Autor) ..................... 44 Obrázek 13 – Editor pro tvorbu ETL vrstvy nástroje QlikView (Autor) ............................... 47 Obrázek 14 – Okno s probíhajícím ETL procesem (Autor) ................................................ 49 Obrázek 15 – Měření doby potřebné k ETL procesu z jednotlivých databází (Autor) ........ 50 Obrázek 16 – Výsledný report vytvořený v nástroji QlikView (Autor)................................. 52 Obrázek 17 – Připojen služby Reporting Servicesí k databázi (Autor) .............................. 56 Obrázek 18 - Výsledný report vytvořený v nástroji QlikView (Autor) ................................. 57 Obrázek 19 – Parametry omezující datovou sadu reportu v Reporting Services (Autor) .. 58 Obrázek 20 – Výsledky měření aplikovaných metod zpracování dat (Autor)..................... 61 Obrázek 21 – Report o generování testovacích dat databáze Northwind_3...................... 74 Obrázek 22 - Report o generování testovacích dat databáze Northwind_5 ...................... 74

Seznam tabulek

Tabulka 1 - Klíčové vlastnosti HDD a RAM (Autor) ............................................................. 8 Tabulka 2 – Průměrná cena kapacity pevných disků (McCallum, 2013) ........................... 10 Tabulka 3 – Průměrná cena kapacity operační paměti (McCallum, 2013) ........................ 11 Tabulka 4 - Specifikace laptopu, na kterém byla praktická úloha realizována (autor) ....... 27 Tabulka 5 – Seznam použitých SW nástrojů (autor) ......................................................... 28 Tabulka 6 – Přehled tabulek databáze Northwind (Autor) ................................................. 39 Tabulka 7 – Počet záznamů databáze Northwind (Autor) ................................................. 41 Tabulka 8 – Počet záznamů klíčových generovaných tabulek (Autor) .............................. 46 Tabulka 9 – Výsledky měření aplikovaných metod zpracování dat (Autor) ....................... 62 Tabulka 10 – Faktor In-Memory zpracování dat (Autor) .................................................... 64

73

Přílohy

74

Příloha A: Reporty z generování dat

Obrázek 21 – Report o generování testovacích dat databáze Northwind_3

Obrázek 22 - Report o generování testovacích dat databáze Northwind_5

Přílohy

75

Příloha B: Aplikace pro generování klíčů tabulky Order Details package generator; import import import import import

java.io.BufferedWriter; java.io.DataOutputStream; java.io.FileOutputStream; java.io.FileWriter; java.util.Random;

/** * @author Lukas Cigler */ public class Generator { /** * @param args the command line arguments */ public static void main(String[] args) { int lines = 1000; try{ Random rand = new Random(); BufferedWriter out = new BufferedWriter(new FileWriter("file.txt")); int idObjednavky = 1; int maximalniVelikostObjednavky = 6; int[] pouziteProdukty = new int[maximalniVelikostObjednavky]; int velikostObjednavky = 1+rand.nextInt(maximalniVelikostObjednavky); int maxIdProduktu = 77; int k = 0; for (int i=0;i
Přílohy

System.out.print(line); out.write(line); if (k>=velikostObjednavky){ velikostObjednavky = 1+rand.nextInt(maximalniVelikostObjednavky); k = 0; idObjednavky++; } } out.close(); System.out.println("Hotovo"); }catch(Exception e){ System.out.println("Soubor neexistuje"); } finally{ } } }

76