Integrace BI open source nástroj. Bc. Ivo La²ek. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta

eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·

Diplomová práce

Integrace BI open source nástroj· Bc. Ivo La²ek

Vedoucí práce:

Ing. Pavel Kordík, Ph.D.

Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský

Obor: Výpo£etní technika

10. £ervna 2010

iv

v

Pod¥kování Na tomto míst¥ bych rád pod¥koval Ing. Pavlu Kordíkovi Ph.D. za cenné podn¥ty, rady a pomoc p°i psaní této práce a svým blízkým za podporu v pr·b¥hu mého studia.

vi

vii

Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).

V Praze dne 13. 5. 2010

.............................................................

viii

Abstract The aim of this work is to interconnect the application FAKE GAME with appropriate tools by Pentaho group. It acquaints readers with the possibilities of Pentaho tools exploitation in order to solve common business intelligence (BI) tasks. Based on a concrete example of the data mining application FAKE GAME it demonstrates the use of selected tools to extend a functionality of other software packages and shows the ways of extending the functionality of Pentaho platform itself. As a result of this work the application FAKE GAME is enhanced by the ability to retrieve data from a wide variety of sources with a help of Pentaho Data Integration. Moreover FAKE GAME application is integrated with Pentaho Data Integration and Pentaho BI platform.

Abstrakt Tato práce si klade za cíl propojit aplikaci FAKE GAME s vhodnými nástroji z rodiny Pentaho. Seznamuje £tená°e s moºnostmi nástroj· z této rodiny pro °e²ení problém· z oblasti business intelligence (BI). Na konkrétním p°íklad¥ data miningové aplikace FAKE GAME demonstruje vyuºití vybraných nástroj· ve vlastních softwarových balících a ukazuje zp·soby roz²í°ení funkcionality platformy Pentaho. Výsledkem práce je roz²í°ení aplikace FAKE GAME o schopnost na£ítat data ze ²iroké ²kály zdroj· prost°ednictvím Pentaho Data Integration a integrace aplikace FAKE GAME s nástroji Pentaho Data Integration a Pentaho BI platform.

ix

x

Obsah 1 Úvod

1

2 Business Intelligence (BI)

5

1.1 1.2 1.3 2.1

2.2

Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Business Intelligence obecn¥ . . . . . . . . . . . . . . . 2.1.1 Vymezení pojmu . . . . . . . . . . . . . . . . . 2.1.2 Typický BI proces . . . . . . . . . . . . . . . . 2.1.3 Architektura BI systému . . . . . . . . . . . . . 2.1.3.1 Zdroje dat . . . . . . . . . . . . . . . 2.1.3.2 Sb¥r dat . . . . . . . . . . . . . . . . 2.1.3.3 Ukládání dat . . . . . . . . . . . . . . 2.1.3.4 Analýza dat . . . . . . . . . . . . . . 2.1.4 Metadata . . . . . . . . . . . . . . . . . . . . . Typy nástroj· pro BI . . . . . . . . . . . . . . . . . . . 2.2.1 Tabulkové procesory . . . . . . . . . . . . . . . 2.2.2 ETL nástroje . . . . . . . . . . . . . . . . . . . 2.2.3 Nástroje pro vytvá°ení report· . . . . . . . . . 2.2.4 Online analytical processing (OLAP) . . . . . . 2.2.5 Digitální nást¥nky (Dashboards) . . . . . . . . 2.2.6 Dolování dat (Data mining) . . . . . . . . . . . 2.2.7 Dolování proces· (Process mining) . . . . . . . 2.2.8 Informa£ní systémy o území (Local Information

3 Nástroje pro BI na trhu 3.1

3.2

Open Source BI nástroje . . . 3.1.1 Pentaho . . . . . . . . 3.1.2 Palo . . . . . . . . . . 3.1.3 JasperSoft . . . . . . . 3.1.4 Eclipse BIRT Project . 3.1.5 RapidMiner . . . . . . Proprietární software . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . xi

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System) . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

1 2 3

5 5 5 6 6 7 7 8 8 8 8 9 9 9 10 10 11 11

13

13 13 13 14 14 14 15

xii

OBSAH

4 Analýza existujících nástroj· 4.1

4.2 4.3 4.4 4.5

4.6

Nástroje z rodiny Pentaho . . . . . . . . . . . . . . 4.1.1 Pentaho Reporting . . . . . . . . . . . . . . 4.1.2 Pentaho Analysis . . . . . . . . . . . . . . . 4.1.3 Pentaho Data Integration (PDI) . . . . . . 4.1.4 Pentaho Data Mining . . . . . . . . . . . . 4.1.5 Pentaho BI platform . . . . . . . . . . . . . 4.1.5.1 Webové rozhraní . . . . . . . . . . 4.1.5.2 Pentaho Design Studio . . . . . . 4.1.6 Pentaho Dashboards . . . . . . . . . . . . . FAKE GAME . . . . . . . . . . . . . . . . . . . . . 4.2.1 Architektura systému a jeho roz²i°itelnost . Data Mining a jeho integrace v nástrojích Pentaho Moºnosti roz²í°ení Pentaho Data Integration . . . . 4.4.1 PDI API . . . . . . . . . . . . . . . . . . . . 4.4.2 Pluginy pro PDI . . . . . . . . . . . . . . . Moºnosti roz²í°ení Pentaho BI platform . . . . . . 4.5.1 Sekvence akcí . . . . . . . . . . . . . . . . . 4.5.2 Komponenty a pluginy . . . . . . . . . . . . 4.5.3 Jednotlivé sou£ásti pluginu . . . . . . . . . Záv¥rem . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

Realizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Popis PDI API . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Závislosti a pouºité knihovny . . . . . . . . . . . . . . . . . . 5.1.3 Roz²í°ení FAKE GAME automatizovaného Data Mining Flow Testování FAKE GAME s vyuºitím PDI API . . . . . . . . . . . . . 5.2.1 Unit testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Na£ítání dat z více zdroj· . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

5 Vyuºití PDI API v rámci FAKE GAME 5.1

5.2

6 Plugin pro PDI 6.1

6.2

Realizace . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Nastavení vývojového prost°edí . . . . . . . 6.1.2 Specický class loader . . . . . . . . . . . . 6.1.3 Struktura FAKE GAME pluginu pro PDI . Testování pluginu pro PDI . . . . . . . . . . . . . . 6.2.1 Unit testy . . . . . . . . . . . . . . . . . . . 6.2.2 Vytvo°ení testovacích transformací . . . . . 6.2.3 Porovnání s výsledky pluginu Weka scoring

7 Plugin pro Pentaho BI platform 7.1

Realizace . . . . . . . . . . . . . . . . 7.1.1 Struktura projektu . . . . . . . 7.1.2 Nastavení vývojového prost°edí 7.1.3 FAKE GAME plugin pro PDI .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

17

17 17 19 20 21 22 22 24 25 25 26 27 29 29 30 31 31 33 35 37

39

39 39 41 41 42 42 43

47

47 48 48 49 50 50 50 51

55

55 55 56 57

xiii

OBSAH

7.2

7.1.4 Roz²í°ení FAKE GAME automatizovaného Data Mining Flow Testování pluginu pro Pentaho BI platform . . . . . . . . . . . . . . 7.2.1 Unit testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2 Vytvo°ení testovacích sekvencí . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

58 59 59 60

8 Záv¥r

65

Literatura

69

A Seznam pouºitých zkratek

71

B Instala£ní a uºivatelská p°íru£ka - PDI v rámci FAKE GAME

73

C Instala£ní a uºivatelská p°íru£ka - plugin pro PDI

75

D Instala£ní a uºivatelská p°íru£ka - plugin pro Pentaho BI

77

E Ukázky nasazení FAKE GAME pluginu pro Pentaho BI

81

F Obsah p°iloºeného CD

87

8.1 8.2 8.3

Zhodnocení dosaºených cíl· . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Problémy integrace open-source nástroj· . . . . . . . . . . . . . . . . . . . . . 66 Dal²í práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

B.1 P°edpoklady . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 B.2 Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 B.3 Pouºití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 C.1 P°edpoklady . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 C.2 Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 C.3 Pouºití pluginu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 D.1 P°edpoklady . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 D.2 Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 D.3 Pouºití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

xiv

OBSAH

Seznam obrázk· 2.1 2.2

Architektura BI systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 P°íklad digitální nást¥nky v rámci Google Analytics . . . . . . . . . . . . . . 10

4.1 4.2 4.3 4.4

Pracovní plocha Pentaho BI platform . . . . . . . . . . . . . . . . . . . Operation Flow v aplikaci FAKE GAME. P°íklad DMBatchProle [14] Realizace návrhového vzoru Strategy v rámci FAKE GAME . . . . . . Skládání report· v rámci FAKE GAME . . . . . . . . . . . . . . . . .

. . . .

23 26 27 28

5.1

Ukázka transformace vytvo°ené pomocí PDI, kterou je FAKE GAME schopný zpracovat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka £tení dat z transformace za vyuºití návrhového vzoru Observer . . . . Vyuºití návrhového vzoru Template method pro £tení dat z transformace . . . Ukázka vy£tení dat z csv souboru . . . . . . . . . . . . . . . . . . . . . . . . . Transformace pro £tení dat ze dvou r·zných databází . . . . . . . . . . . . . . Transformace pro £tení dat ze dvou r·zných databází . . . . . . . . . . . . . .

39 40 42 43 44 45

5.2 5.3 5.4 5.5 5.6 6.1 6.2 6.3 6.4 6.5 6.6 7.1 7.2 7.3 7.4 7.5 7.6 7.7

. . . .

. . . .

. . . .

Ukázka rozhraní FAKE GAME pluginu pro PDI . . . . . . . . . . . . . . . . . Aplikace návrhového vzoru Facade za ú£elem odstín¥ní logiky FAKE GAME od zbytku PDI pluginu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transformace porovnávající výsledky klasikátor· vytvo°ených ve Wecce a výsledky klasikátor· vytvo°ených prost°ednictvím FAKE GAME . . . . . . . Zobrazení dosavadních výsledk· transformace v PDI . . . . . . . . . . . . . . Transformace pro porovnání výsledk· model· vytvo°ených pomocí FAKE GAME a Weky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Výsledek transformace pro porovnání výsledk· model· vytvo°ených pomocí FAKE GAME a Weky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka zobrazeného FAKE GAME reportu v rámci Pentaho BI platform . . . Dopln¥ní dal²ího zp·sobu na£ítání dat do jiº hotové architektury FAKE GAME Zm¥na zp·sobu generování obrázk· p°i vykreslení FAKE GAME reportu . . . Za£len¥ní pluginu do sekvence akcí v prost°edí Design Studio . . . . . . . . . Výb¥r typu reportu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vizualizace datového souboru - ukázka histogram· z FAKE GAME reportu v rámci Pentaho BI platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . Propojení FAKE GAME s komponentou starající se o £tení dat z rela£ní databáze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

47 50 52 53 54 54 55 59 60 61 61 62 63

xvi

SEZNAM OBRÁZK

C.1 Ukázka uºivatelského rozhraní FAKE GAME pluginu pro PDI . . . . . . . . . 76 D.1 Pracovní plocha v rámci Pentaho BI platform . . . . . . . . . . . . . . . . . . 78 E.1 Denice jednoduchého workow v prost°edí Action Sequence editoru - uºivatel je poºádán o výb¥r kongurace reportu, který si p°eje vid¥t. . . . . . . . . . . E.2 Vyhodnocení úsp¥²nosti klasikátoru pomocí ROC k°ivek. Datový soubor pro klasikaci kosatc·, testovací strategie cross validation. . . . . . . . . . . . . . E.3 Jednoduchý formulá° pro výb¥r strategie testování model· porovnávaných v rámci FAKE GAME reportu. Formulá° je kongurovaný pomocí Action Sequence editoru. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.4 Vyhodnocení testování sestavených model· - výb¥r toho nejlep²ího (v tabulce na obrázku je ozna£ený tu£n¥). Datový soubor pro odhad spot°eby vody mandarinkovníku, data rozd¥lena na trénovací a testovací mnoºinu. . . . . . . . . E.5 Propojení pluginu s komponentou pro odesílání e-mail· v prost°edí Action Sequence editoru. Je tak moºné snadno sestavovat sekvence, kde je výsledný report na záv¥r odeslán mailem. . . . . . . . . . . . . . . . . . . . . . . . . . . E.6 Andrewsovy k°ivky pro datový soubor EEG novorozenc· v rámci Pentaho BI platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.7 Feature ranking pro vstupy z datového souboru Odhad prodejní ceny aut. . .

81 82 82 83 84 85 86

Seznam tabulek 4.1 4.2 4.3

Seznam nejd·leºit¥j²ích servlet· pro práci s Pentaho BI platform . . . . . . . 24 Seznam datových typ· podporovaných v rámci Pentaho BI platform . . . . . 33 Seznam metod rozhraní org.pentaho.core.component.IComponent . . . . . . 34

5.1

Seznam testovaných soubor· dat . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.1

Výsledky porovnání klasikátor· vytvo°ených pomocí Weky a FAKE GAME

7.1

Adresá°ová struktura projektu tvo°ícího Pentaho BI plugin . . . . . . . . . . . 56

52

D.1 Seznam vstup· FakeGame pluginu pro Pentaho BI platform . . . . . . . . . . 79

xvii

xviii

SEZNAM TABULEK

Kapitola 1 Úvod 1.1

Motivace

Software tak, jak jsme jej donedávna znali, se m¥ní. Díky internetu dnes vytvá°íme aplikace velmi snadno dostupné pro uºivatele kdekoliv na sv¥t¥. Denn¥ p°icházíme do styku s mnoºstvím informací, o kterém se nám d°íve ani nesnilo. Práv¥ mnoºství informací a jejich dostupnost je dnes hybnou silou moderní civilizace. Ov²em informace samy o sob¥ nejsou zdaleka samospásné. Moºná je²t¥ d·leºit¥j²í neº jejich hromad¥ní je schopnost správn¥ je vyhodnotit, tedy dokázat nashromáºd¥ná data ut°ídit, stanovit jejich d·leºitost a prezentovat zji²t¥né skute£nosti v p°ehledné form¥. S rostoucím výkonem moderních po£íta£· a neustále se zvy²ující kapacitou záznamových médií jiº dnes není problém ukládat do nedávna tak°ka nep°edstavitelné mnoºství dat. Není v²ak v lidských silách v²echna takto nashromáºd¥ná data rozumov¥ pojmout. Práv¥ zde p°ichází ke slovu Business Intelligence jako soubor postup· a schopností podpo°ených odpovídajícími informa£ními technologiemi, které nám pomáhají dostupné informace správn¥ vyhodnotit. ijeme v období digitalizace a s trochou nadsázky by se dalo °íci, ºe papír denitivn¥ prohrává bitvu o své místo na slunci. Díky tomu udrºování rozsáhlých databází dávno není doménou jen velkých bankovních dom· a nadnárodních spole£ností. Stále více pror·stají informa£ní technologie do státní správy. I malé rmy pouºívají specializovaný software pro vedení ú£etnictví, udrºování informací o nabízeném zboºí. Zadávání a plánování práce probíhá p°es softwarové nástroje pro °ízení projekt·. Monitorujeme pohyb nebo aktivitu osob, a´ uº jsou to zam¥stnanci £i uºivatelé. V²echny tyto £innosti mají jednoho spole£ného jmenovatele. Tím je velké mnoºství r·znorodých údaj·, které máme ve nále k dispozici. Jejich správná analýza m·ºe p°inést obrovské úspory díky zefektivn¥ní pracovních proces·, lep²ímu cílení reklamy, dokonalej²í kontrole apod. Open-source má na tomto poli hrát nemalou roli. Podle prognóz analytické spole£nosti Gartner Research [15] a [16] se má podíl open-source nástroj· pro Business Intelligence na trhu do roku 2012 zp¥tinásobit. Hlavním d·vodem, pro£ se rmy k t¥mto nástroj·m uchylují, je podle výzkumu úspora náklad·. Open-source aplikace zatím v tomto oboru nedosahují funk£ní úrovn¥ svých velkých komer£ních prot¥j²k·, ov²em míra jejich nasazení rychle stoupá. 1

2

KAPITOLA 1. ÚVOD

Podle Gartner Research se pr·m¥rná cena za ro£ní p°edplatné pohybuje okolo 30 000 dolar·, ov²em objevují se i zakázky v hodnot¥ aº 500 000 dolar·, coº uº odpovídá sazbám za komer£ní produkty. Uºivateli komer£ních °e²ení jsou tradi£n¥ zejména rmy pohybující se ve nan£ním sektoru a telekomunika£ní spole£nosti. Open-source nástroje naproti tomu vyuºívají spí²e st°edn¥ velké rmy a dále je moºné je nalézt i ve vládním a ve°ejném sektoru nebo ve zdravotnictví. Velká £ást úsp¥chu open-source v oblasti Business Intelligence tkví práv¥ v jeho otev°enosti. Mnoho nezávislých softwarových vývojá°· vyuºívá existující balíky, nebo jejich £ásti a nasazuje je jako sou£ást vlastních °e²ení na míru. Jednodu²e tak vznikají nové BI platformy na základ¥ jiº existujícího kódu. Podle Gartner Research je situace na trhu pro open-source momentáln¥ p°íznivá. Potenciální konkurence v podob¥ poskytování Business Intelligence jako sluºby (software-as-aservice), coby cenov¥ výhodn¥j²í varianta, je minimáln¥ u £ty° hlavních komer£ních hrá£· v této oblasti (IBM, Microsoft, Oracle a SAP) zatím v plenkách. Pro organizace snaºící se redukovat své náklady je open-source v sou£asné dob¥ nejsch·dn¥j²í variantou. innost rmy Pentaho se v tomto kontextu jeví jako logické vyúst¥ní situace. Její obchodní model spo£ívá v podpo°e tým· vyvíjejících n¥kolik open-source nástroj· a nabízení t¥chto nástroj· pod svou hlavi£kou koncovým zákazník·m. Vytvá°í pomyslný most mezi vývojá°i a uºivateli jejich d¥l. Zárove¬ tato strategie (sdruºení r·zných v¥tví vývoje pod jednu st°echu) umoº¬uje t¥ºit ze vzájemných synergií. V neposlední °ad¥ Pentaho sponzoruje jednotlivé týmy a podporuje tak dal²í vývoj. P°edplatné pro uºivatele znamená záruku stability, technické podpory a pravidelné distribuce aktualizací. Oblast dolování dat (data mining) je v tomto softwarovém balíku zastoupena velmi známým a hojn¥ pouºívaným programem Weka. Ta v²ak zatím stále p·sobí spí²e jako samostatný program a není p°íli² integrována s ostatními nástroji z rodiny Pentaho. Otevírá se tak prostor k napojení FAKE GAME - aplikace vyvíjené na VUT, specializované na data mining a automatickou tvorbu report·. FAKE GAME by tedy mohl slouºit jako zajímavá alternativa k Wecce. Krom¥ toho m·ºe hlub²í studium nástroj· z rodiny Pentaho poskytnout cennou inspiraci pro roz²í°ení funk£nosti FAKE GAME a zacelení n¥kterých mezer jako nap°íklad absence moºnosti na£ítat data z databáze. 1.2

Cíl práce

Cílem práce je zejména:

• Seznámení se stávající situací v oblasti Business Intelligence s d·razem na open-source nástroje. • Seznámení s technologickými moºnostmi nástroj· z rodiny Pentaho. • Analýza moºností vyuºití nástroj· z rodiny Pentaho jako sou£ásti vlastních °e²ení. • Roz²í°ení aplikace FAKE GAME o moºnosti na£ítání a integrace dat z r·zných datových zdroj· s vyuºitím technologických prost°edk· nástroj· Pentaho.

1.3. STRUKTURA PRÁCE

3

• Analýza roz²i°itelnosti Pentaho BI platformy o dal²í funkcionalitu. • Integrace FAKE GAME do Pentaho BI platformy, zp°ístupn¥ní základní funkcionality aplikace v rámci platformy. 1.3

Struktura práce

Práce je rozd¥lena do n¥kolika £ástí:

•

Teoretický úvod: Vymezení pojmu Business Intelligence a popis jednotlivých technik a typ· nástroj· spadajících do tohoto oboru. Tato £ást zahrnuje i stru£ný p°ehled nejroz²í°en¥j²ích aplikací s d·razem na open-source °e²ení. Kapitoly 2 a 3.

•

Analytická £ást: P°edstavení stávající situace, seznámení s aplikacemi z rodiny Pen-

taho a FAKE GAME. Podrobný rozbor jednotlivých nástroj· z rodiny Pentaho, popis lozoe celého projektu, p°edstavení jeho architektury. Identikace moºností vyuºití stávajících funkcí ve vlastních aplikacích zejména s ohledem na FAKE GAME. Pr·zkum zp·sob· roz²i°ování funkcionality platformy i aplikace FAKE GAME. Výb¥r vhodných nástroj· a technik pro následnou realizaci. Kapitola 4.

•

Realizace a testování:

•

Záv¥r:

Vzhledem k tomu, ºe práce sestává v podstat¥ ze t°í projekt·, odpovídají kapitoly 5, 6 a 7 t¥mto projekt·m. Tyto kapitoly tedy obsahují popis konkrétní realizace jednotlivých projekt·. Rozbor propojení FAKE GAME a Pentaho za ú£elem na£ítání dat z r·zných zdroj· (kapitola 5). Postup p°i tvorb¥ plugin· pro n¥které nástroje z rodiny Pentaho (kapitoly 6 a 7). Výb¥r specických poznatk· nasbíraných p°i tvorb¥ °e²ení. Popis tvorby automatizovaných test· pro pluginy Pentaho BI platformy. Vzorové nasazení implementovaných komponent. P°edstavení výsledk· testování s reálnými daty. Zhodnocení dosaºených výsledk·. Nastín¥ní dal²ích moºností integrace obou projekt·.

4

KAPITOLA 1. ÚVOD

Kapitola 2 Business Intelligence (BI) 2.1

Business Intelligence obecn¥

2.1.1 Vymezení pojmu Pod pojmem Business Intelligence se obecn¥ rozumí soubor postup·, nástroj·, dovedností a znalostí vyuºívaných pro podporu rozhodování. N¥kdy bývá tento pojem zam¥¬ován s termínem Systém pro podporu rozhodování (Decision Support Systems DSS). Zde je t°eba °íci, ºe v p°ípad¥ BI se jedná o DSS zaloºený na datech. Dal²ími typy DSS mohou být nap°. DSS zaloºené na modelech nebo znalostní DSS. Zárove¬ [5] poukazuje na fakt, ºe pojem Business Intelligence má r·zné významy v r·zných kontextech. Z technického hlediska potom [5] denuje BI jako proces získávání, transformace, správy a analýzy obchodních dat za ú£elem podpory rozhodování. Trochu precizn¥j²í denici uvádí [7]. Op¥t BI ozna£uje mnoºinu nástroj· a technik. Ty umoº¬ují spole£nostem p°em¥nit svá obchodní data na aktuální a p°esné podklady pro rozhodování tak, aby byly dostupné správným osobám v co nejvhodn¥j²í form¥. Systémy pro Business Intelligence se tedy vyuºívají pro získání komplexního náhledu na stav spole£nosti, rozpoznání faktor·, které ovliv¬ují její £innost, a zárove¬ pomáhají vytvá°et a rozvíjet nové obchodní strategie. Cílem je umoºnit rozhodování podloºené reálnými daty za ú£elem získání konkuren£ní výhody díky schopnosti rychleji identikovat zm¥ny a reagovat na n¥, zvy²ovat ziskovost a efektivitu a obecn¥ vytvá°et p°idanou hodnotu pro spole£nost.

2.1.2 Typický BI proces Typický proces v rámci BI sestává podle [11] z p¥ti stup¬·:

•

Sb¥r dat: BI systém je schopný na£ítat data z r·zných zdroj· (nap°. databází, soubor·, webových sluºeb, z výstup· ostatních aplikací a systém·). Sb¥r dat zahrnuje i jejich p°edzpracování (£i²t¥ní, opravu neúplných záznam·, integraci) a p°ípravu pro následnou analýzu.

•

Analýza dat:

Dále jsou sesbíraná data p°evedena na uºite£né informace za pomoci nejr·zn¥j²ích technik zahrnujících tvorbu report·, modelování, vizualizaci dat a jejich 5

6

KAPITOLA 2. BUSINESS INTELLIGENCE (BI)

vyt¥ºování (data mining). Cílem je poskytnout globální a p°ehledný náhled na získaná data a umoºnit tak fundovaná rozhodnutí.

•

Pochopení situace (Situation awareness): Pod tímto pojmem rozumíme fázi, kdy

jsme jiº díky p°edchozím stup¬·m získali dobrý p°ehled o stávající situaci a máme tak poloºeny základy pro rozumné rozhodování. Jde tedy zejména o nalezení logických souvislostí mezi informacemi a odltrování ned·leºitých skute£ností.

•

Posouzení rizika: Celý BI proces je o tvorb¥ rozhodnutí na základ¥ odhadu budoucího vývoje. P°i tomto odhadu vycházíme z dat, která máme k dispozici. P°i tvorb¥ rozhodnutí je tedy t°eba porovnat rizika moºných variant, které se nám otevírají.

•

Podpora rozhodování (Decission support:) Jak jsem jiº zmínil, hlavním cílem BI je umoºnit manaºer·m rozhodovat se chyt°e podle aktuálních dat.

2.1.3 Architektura BI systému Typický BI systém sestává podle [5] ze £ty° skupin komponent a z metadat, která umoº¬ují spolupráci t¥chto komponent. Základní architektura BI systému je nazna£ena na obrázku 2.1.

Obrázek 2.1: Architektura BI systému

2.1.3.1 Zdroje dat Jako zdroje dat slouºí p°eváºn¥ Online Transaction Processing (OLTP) systémy pro podporu b¥ºných obchodních proces·. Typickými zástupci jsou nan£ní systémy, nebo nejr·zn¥j²í nástroje pro personalistiku, °ízení zdroj· a °ízení vztah· se zákazníky. Data je ov²em £asto

2.1. BUSINESS INTELLIGENCE OBECN

7

t°eba na£ítat i ze zastaralých legacy systém·. Krom¥ strukturovaných dat na£tených nap°. z rela£ních databází se tak setkáváme i s textovými soubory a excelovskými tabulkami, £asto vytvo°enými ru£n¥. Velká rozmanitost zdroj· dat a jejich £astá neúplnost klade velké nároky na jejich následný sb¥r.

2.1.3.2 Sb¥r dat Sb¥r dat zahrnuje zárove¬ jejich p°edzpracování a skládá se ze t°í fází:

•

Získání dat (Extracting): Zahrnuje na£tení dat z r·zných zdroj·, kterými mohou být nejr·zn¥j²í databáze, textové soubory, tabulky, výstupy webových sluºeb apod.

•

Transformace dat (Transforming): Vzhledem k r·znorodosti na£tených dat je po-

t°ebujeme p°ed dal²ím zpracováním p°íslu²n¥ upravit. Jedná se o jejich vy£i²t¥ní (odstran¥ní nesmyslných hodnot), sjednocení (p°evod odpovídajících záznam· na stejný formát) a agregaci (seskupení do logických celk·).

•

Nahrávání dat (Loading): skladu.

Nakonec jsou data nahrána do centrálního datového

Z anglických výraz· Extract, Transform and Load se pro ozna£ení tohoto sb¥ru a p°edzpracování dat uºívá zkratka ETL. ETL je základní sou£ástí BI systému a determinuje kvalitu dat pro zpracování v²emi dal²ími komponentami. V £e²tin¥ se pro ETL n¥kdy pouºívá pojem datová pumpa. Jedním z ukazatel· vysp¥losti takové datové pumpy je krom¥ kvality produkovaných dat i rychlost jejich "pumpování"do datového skladu. Objemy dat, s nimiº se pracuje jsou totiº obvykle velmi velké.

2.1.3.3 Ukládání dat Data zpracovaná pomocí ETL jsou dále uchovávána v datovém skladu (anglicky data warehouse). Datové sklady jsou realizovány bu¤ pomocí speciálních datových struktur, nebo s vyuºitím b¥ºných rela£ních databází. Od rela£ních databází se ov²em li²í. Podle denice Williama Inmona [2] je datový sklad:

• orientovaný na subjekt (ukládání dat ve snadno £itelných strukturách za cenu zvý²ených nárok· na pam¥óvý prostor - na rozdíl od rela£ních databází kladoucích d·raz na co nejmen²í redundanci dat) • zachovávající historii (zpravidla obsahuje i historické údaje a ne jen aktuální stav dat) • neprom¥nlivý (data se nahrávají ve v¥t²ích dávkách - nap°. jednou denn¥ - a dále uº se zpravidla nem¥ní) • integrovaný (data jsou seskupena podle logického významu bez ohledu na jejich zdroj) Data jsou ukládána s ohledem na rychlé provád¥ní sloºitých analytických dotaz· bez nutnosti záznamy p°íli² £asto m¥nit. Za tímto ú£elem obsahuje datový sklad faktové tabulky (obsahují vlastní analyzovaná data) a dimenze (tabulky obsahující záznamy slouºící k t°íd¥ní dat ve faktových tabulkách). Podle hierarchického uspo°ádání dimenzních tabulek rozeznáváme dv¥ nejoblíben¥j²í schemata datových sklad·:

8


•

Hv¥zda: Dimenzní tabulky jsou p°ímo navázány na faktové.

•

Vlo£ka:

Dimenzní tabulky mohou být na faktové navázány nep°ímo p°es dal²í dimenzní tabulky.

2.1.3.4 Analýza dat Nad daty v datovém skladu jiº operují nejr·zn¥j²í analytické nástroje. Cílem je poskytnout p°ehledný náhled na data p°ístupný i pro b¥ºné uºivatele bez hlub²ích technických znalostí - typicky manaºery rem, kte°í tak dostávají snadno dostupné relevantní podklady pro své rozhodování. Do této skupiny °adíme reportovací nástroje, OLAP (Online Analytical Processing) nástroje a technologie pro dolování dat (data mining). Dal²í °e²ení pracující s daty z datového skladu mohou zahrnovat digitální nást¥nky, informa£ní systémy, napojení systém· pro °ízení vztah· se zákazníky (Customer Relationship Management - CRM) apod. Podrobn¥ji jsou zmín¥né typy nástroj· rozebrány v následující kapitole 2.2.

2.1.4 Metadata Metadaty rozumíme informace o samotných datech proudících v systému. Jedná se nap°. o údaje o zdrojích dat, typu úloºi²t¥ v datovém skladu, p°ístupových právech a zp·sobu £tení a transformace jednotlivých záznam·. 2.2

Typy nástroj· pro BI

Zatím jsme se dívali na BI systém jako na celek a p°edstavili jsme si jeho obecnou architekturu. Existuje nep°eberné mnoºství nástroj·, které je moºné za°adit do kategorie Business Intelligence, av²ak jedná se jen o díl£í sou£ásti celého systému. Jednotlivé komponenty mohou docela dob°e fungovat i samostatn¥ a plnit svou funkci nezávisle. Dává smysl nap°. nasadit reportovací nástroj nad stávající remní databází a nemusíme kv·li tomu nutn¥ vytvá°et specializovaný datový sklad. Stejn¥ tak m·ºeme vyuºít ETL nástroje pro p°esun a transformaci dat v rámci stávajících remních proces·, aniº bychom p°esunutá data cht¥li nutn¥ analyzovat. Stejn¥ tak dolování dat lze provozovat samostatn¥ bez nutnosti budování datového skladu, mnohé data miningové nástroje zahrnují vlastní moºnosti p°edzpracování dat a denice vlastních datových tok·. Poj¤me si tedy p°edstavit jednotlivé skupiny BI aplikací.

2.2.1 Tabulkové procesory Vzhledem k jejich obrovské popularit¥ a vyuºití tém¥° v kaºdé rm¥ je do skupiny BI nástroj· moºné za°adit i tabulkové procesory. Nejznám¥j²ími zástupci jsou beze sporu Microsoft Excel a jeho open-source prot¥j²ek OpenOce Calc. Dal²ím zástupcem m·ºe být nap°. rovn¥º open-source KSpread. asto za£íná proces sb¥ru remních dat práv¥ od jednotlivých soubor· ve formátu n¥kterého tabulkového procesoru. Uspo°ádání dat do formátu tabulek je pro BI pom¥rn¥ typické, druhou velkou skupinu potenciálních zdroj· dat tvo°í rela£ní databáze, kde jsou data rovn¥º organizována tabelárn¥.

2.2. TYPY NÁSTROJ PRO BI

9

2.2.2 ETL nástroje Jedná se o nástroje realizující ETL proces popsaný v kapitole 2.1.3.2. Zpravidla je k dispozici gracké uºivatelské rozhraní, jehoº prost°ednictvím je moºné celý proces £tení, transformace a nahrávání dat pohodln¥ nakongurovat. Takto nadenovaný proces je následn¥ uloºen a m·ºe být zpracováván v p°ípad¥ pot°eby dávkov¥. Nejznám¥j²ími open-source nástroji z této kategorie jsou pravd¥podobn¥ Apatar, CloverETL nebo Pentaho Data Integration. Samoz°ejm¥ i komer£ní hrá£i mají své zástupce v této oblasti, jmenujme nap°. BusinessObjects Data Integrator, Oracle Warehouse Builder nebo Informaticu.

2.2.3 Nástroje pro vytvá°ení report· Základním produktem BI systém· jsou reporty. Reportovací nástroje v tomto kontextu slouºí pro návrh a generování t¥chto report·. Typicky je k dispozici aplikace pro vytvá°ení ²ablon. Zde je moºné nastavit v podstat¥ libovolný vzhled odpovídající remním standard·m. Nástroje disponují prost°edky pro pln¥ní report· daty z rozli£ných zdroj· po£ínaje r·znými druhy databází, p°es textové soubory, soubory tabulkových procesor·, XML a HTML soubory aº po webové sluºby a napojení na nejr·zn¥j²í proprietární °e²ení. Reporty je moºné generovat op¥t do mnoºství formát· jako PDF dokumenty, HTML stránky, XML soubory, ve formátu soubor· kancelá°ských aplikací atd. Ú£elem t¥chto nástroj· je vytvá°et p°ehledné obchodní reporty poskytující manaºer·m nap°. údaje o prodeji, výkonnosti jednotlivých odd¥lení, stavu lidských zdroj· ve rm¥, stavu nancí apod. Reporty jsou generovány prost°ednictvím provád¥ní p°eddenovaných dotaz· nad uloºenými daty. Vzhledem k tomu, ºe sestavení t¥chto dotaz· není úpln¥ triviální a v¥t²inou vyºaduje zásah vývojá°e nebo správce datového skladu, jsou tyto reporty p°eváºn¥ statické a moºnosti jejich ovlivn¥ní ze strany manaºera jsou velmi omezené. Reportovací nástroje £asto poskytují vlastní rozhraní a je tak moºné jejich funkcionalitu vyuºít v dal²ích aplikacích, které n¥jakým zp·sobem pot°ebují prezentovat zpracovávaná data.

2.2.4 Online analytical processing (OLAP) ir²í moºnosti, co se interaktivity tý£e, poskytují OLAP (Online Analytical Processing) nástroje. Ty umoº¬ují koncovým uºivatel·m procházet data podle r·zných dimenzí. Dimenzí se rozumí r·zná kritéria t°íd¥ní dat (nap°. podle regionu, typu výrobku, data, prodejce). Oproti klasickým report·m m·ºe tak uºivatel exibiln¥ a jednodu²e ovlivnit, jaká data chce zobrazit. Uspo°ádání dat, tak aby je bylo moºné efektivn¥ ltrovat podle t¥chto dimenzí, se °íká datová kostka neboli data cube. OLAP tedy jinými slovy znamená analýzu velkého mnoºství dat v reálném £ase. Na rozdíl od OLTP systém·, kde typickými operacemi jsou £tení a zm¥na relativn¥ malého po£tu záznam·, OLAP pracuje s velkými objemy dat a operace jsou zpravidla pouze £tecí. Sl·vko Online v názvu znamená, ºe p°es obrovské mnoºství zkoumaných dat (typicky mnoho milion· záznam·, zabírajících °ádov¥ gigabyty), musí systém reagovat dostate£n¥ rychle, aby bylo moºné data zkoumat interaktivn¥.

10


OLAP nástroje generují £asto velmi komplikované databázové dotazy a je tudíº nutné data p°edem uspo°ádat, jak jiº bylo popsáno v kapitole 2.1.3.3 o ukládání dat, aby systém dokázal reagovat rozumn¥ rychle. Podle toho, v jaké form¥ OLAP servery ukládají data, rozli²ujeme tyto typy:

• MOLAP (multidimensional OLAP) - data jsou na disku ukládána ve strukturách optimalizovaných pro vícerozm¥rný p°ístup. • ROLAP (relational OLAP) - data jsou uloºena v rela£ní databázi. • HOLAP (hybrid OLAP) - ukládá nejpodrobn¥j²í záznamy v rela£ní databázi, ale agregované hodnoty udrºuje ve vícerozm¥rných strukturách.

2.2.5 Digitální nást¥nky (Dashboards) Digitální nást¥nky jsou informa£ní systémy, jejichº jádrem je uºivatelské rozhraní zobrazující informace sesbírané z r·zných £ástí systému pohromad¥ a jednotným zp·sobem. M·ºe se jednat nap°íklad o nejd·leºit¥j²í informace shromáºd¥né z r·zných report· apod. Krom¥ digitálních nást¥nek jako desktopových aplikací se s nimi setkáváme u webových aplikací, jak nazna£uje obrázek 2.2, nebo jako malých roz²í°ení opera£ního systému, £i webového prohlíºe£e (widgets).

Obrázek 2.2: P°íklad digitální nást¥nky v rámci Google Analytics

2.2.6 Dolování dat (Data mining) V p°ípad¥ dolování dat (data mining) je cílem odhalit skryté a potenciáln¥ zajímavé informace. Na po£átku tedy na rozdíl od p°edchozích metod nemusíme p°esn¥ znát pravidla

2.2. TYPY NÁSTROJ PRO BI

11

a souvislosti mezi daty, která se chystáme zkoumat. Základy dolování dat jsou zaloºeny na statistických metodách jako je regresní analýza, postupem £asu se p°idaly dal²í metody jako je vyuºití neuronových sítí, genetických algoritm·, rozhodovacích strom· a algoritmy podp·rných vektor·. N¥které data miningové nástroje umoº¬ují vytvo°ené modely exportovat do formátu PMML (Predictive Markup Model Language), coº je formát zaloºený na XML, který umoº¬uje vým¥nu model· mezi jednotlivými aplikacemi. Ze znám¥j²ích open-source nástroj· podporují tento formát nap°. R Project, Weka a KNIME.

2.2.7 Dolování proces· (Process mining) O n¥co speci£t¥j²í je disciplína dolování proces·. Jde o analýzu záznam· událostí produkovaných informa£ními systémy. Na základ¥ t¥chto záznam· jsou hledány modely pracovních proces·, p°ípadn¥ jsou záznamy porovnávány s jiº existujícími modely. Pro analýzu záznam· se vyuºívá tak zvaný α-algoritmus [8].

2.2.8 Informa£ní systémy o území (Local Information System) Jak uº název napovídá, jedná se o informa£ní systémy poskytující statistická data vztaºená k n¥jakému místu. M·ºe se jednat nap°. o demogracké údaje.

12


Kapitola 3 Nástroje pro BI na trhu V p°edchozí kapitole jsme si p°edstavili obecnou architekturu BI systému a popsali jednotlivé sou£ásti. V praxi ne v²echny nástroje disponují v²emi popsanými funkcemi. V této kapitole se podíváme na nejvýrazn¥j²í zástupce z oblasti open-source software a stru£n¥ si p°edstavíme jejich moºnosti. V záv¥ru kapitoly se krátce zmíníme i o n¥kterých proprietárních °e²eních. 3.1

Open Source BI nástroje

3.1.1 Pentaho Pentaho sdruºuje pod svou hlavi£kou n¥kolik p·vodn¥ samostatných open-source projekt·:

•

Kettle pro ETL, momentáln¥ pod názvem Pentaho Data Integration

•

JFreeReport pro reportování, momentáln¥ pod názvem Pentaho Reporting

•

Mondrian a JPivot pro OLAP, momentáln¥ pod názvem Pentaho Analysis

•

Weka pro dolování dat, momentáln¥ pod názvem Pentaho Data Mining

Vývoj v²ech t¥chto produkt· Pentaho aktivn¥ podporuje a zárove¬ p°idává vlastní nástroj Pentaho BI Platform, coº je v podstat¥ webová platforma sdruºující v²echny nástroje dohromady a umoº¬ující jejich propojení navzájem. V rámci BI Platform je moºné provozovat dal²í nástroj, jímº jsou digitální nást¥nky - Pentaho Dashboards. Jedná se tedy opravdu o ucelený balík poskytující kompletní Business Intelligence °e²ení. K dispozici jsou dv¥ verze: open-source Community Edition a placená Enterprise Edition.

3.1.2 Palo Dal²ím zástupcem distribuujícím vlastní produkt zdarma je n¥mecká rma Jedox se svým balíkem Palo. Palo se skládá z následujících základních komponent:

•

Palo OLAP Server: Data jsou organizována vícerozm¥rn¥ a uloºena v pam¥ti, coº

umoº¬uje rychlé zpracování dotaz·. Palo OLAP Server umoº¬uje vyuºít API pro Visual Basic, PHP, C++, Javu a .NET. Je tak moºné jej relativn¥ jednodu²e roz²í°it o dal²í funkce. 13

14

KAPITOLA 3. NÁSTROJE PRO BI NA TRHU

•

Palo Web: Podobn¥ jako Pentaho i Palo nabízí pro p°ístup ke v²em svým základním

komponentám prost°ednictvím webového rozhraní. Je tak moºné produkovat webové reporty, organizovat OLAP databáze a monitorovat ETL procesy v systému.

•

Palo for Excel: K dispozici je roz²í°ení pro Excel (a OpenOce Calc), které slouºí v podstat¥ jako uºivatelské rozhraní pro práci s OLAP databází.

•

Palo ETL Server: Webový nástroj pro sb¥r dat z r·zných zdroj· zahrnujících rela£ní databáze, webové sluºby, ale disponující t°eba i p°ímým napojením na SAP.

Obchodní model je podobný jako u Pentaho. Balík je nabízen ve dvou verzích jako opensource a jako placená "premium version".

3.1.3 JasperSoft Spole£nost JasperSoft je známá p°edev²ím díky velmi populárnímu reportovacímu nástroji JasperReports. JasperReports je moºné vyuºít jako knihovnu (je napsaný v Jav¥), pokud pot°ebujeme ve vlastních aplikacích produkovat sostikované reporty. Reporty jsou denovány pomocí soubor· v XML formátu, které mohou být vytvo°eny ru£n¥, generovány automaticky n¥jakou vlastní aplikací, nebo sestaveny pomocí grackého nástroje (nap°. iReport). Postupem £asu se v rámci projektu vyvinuly i dal²í BI aplikace a nyní JasperSoft podobn¥ jako p°edchozí dva zástupci nabízí celý balík nástroj·: JasperETL, JasperAnalysis (op¥t zaloºený na kombinaci Mondrian a JPivot) a JasperServer (sdruºující jednotlivé komponenty v rámci webové platformy).

3.1.4 Eclipse BIRT Project Na rozdíl od ostatních se v p°ípad¥ projektu BIRT (Business Intelligence Reporting Tools) jedná pouze o reportovací nástroj postavený nad vývojovým prost°edím Eclipse. Umoº¬uje vytvá°et sostikované, interaktivní webové reporty. Sestává z n¥kolika variant nástroj· pro návrh report· a a dále z nástroj· pro následnou práci s nimi (prohlíºení, interaktivní funkce apod.). Denice report· se op¥t ukládá v XML formátu a data je moºné £erpat ze ²iroké ²kály zdroj· od SQL databází, p°es XML soubory a webové sluºby aº po staré dobré javovské objekty (POJO) a Java Data Objects (JDO). Dal²ím zajímavým aspektem projektu jsou ²iroké moºnosti nasazení vytvo°ených report·. Krom¥ jiº zmín¥ných prohlíºe£· je k dispozici Java API, umoº¬ující vyuºívání reportovacích funkcí ve vlastních aplikacích. Krom¥ toho nabízí BIRT i n¥kolik variant webových °e²ení pro sdílení a práci s reporty od odleh£eného repozitá°e aº po pln¥ funk£ní reportovací server. Nov¥ je na stránkách projektu nabízena i moºnost vyuºití hostovaného °e²ení - Birt onDemand.

3.1.5 RapidMiner RapidMiner je zam¥°ený zejména na dolování dat. Nicmén¥ disponuje i základními ETL funkcemi pro na£ítání dat a je moºné doinstalovat roz²í°ení pro produkci report· - zejména v PDF a HTML formátu. Aplikace umoº¬uje pomocí grackého rozhraní denovat proces zpracování dat a poskytuje r·zné druhy náhled· na n¥. K dispozici je ²iroká ²kála graf·. Dal²í

3.2. PROPRIETÁRNÍ SOFTWARE

15

aplikace z této rodiny v¥t²inou roz²i°ují funkce RapidMineru nebo na nich dále staví. RapidAnalytics je webový server slouºící jako repozitá°, umoº¬ující plánování report·, vzdálený p°ístup a správu p°ístupových práv. Na RapidMineru jsou potom zaloºené nap°. aplikace RapidSentilizer pro sb¥r novinek na internetu, jejich t°íd¥ní a vyhodnocování publikovaných názor· s pomocí technik pro dolování dat a dolování informací z text· (je tak moºné nap°. vyhodnocovat úsp¥²nost PR kampaní) a RapidDoc pro automatickou kategorizaci elektronických dokument·. 3.2

Proprietární software

Pro úplnost jmenujme krátce nejv¥t²í poskytovatele proprietárních BI °e²ení, a£koliv jejich hlub²í rozbor je nad rámec této práce. K nejvýrazn¥j²ím pat°í gigant Oracle s Oracle Business Intelligence Enterprise Edition Plus, n¥mecká softwarová a konzultantská rma SAP a jejich BusinessObjects (získaným koupí francouzské rmy Business Object v roce 2007), IBM a jejich BI °e²ení Cognos nebo Microstrategy a jejich stejnojmenná rodina nástroj· Microstrategy. Jedná se o zavedené rmy s velmi silnou pozicí na trhu, ov²em výhodou open-source aplikací m·ºe být jejich v¥t²í exibilita a schopnost rychleji reagovat na nové trendy, jakými je nap°. decentralizace BI proces· a v sou£asné dob¥ moderní cloud computing. V této souvislosti bych rád zmínil je²t¥ t°etí sm¥r, který se snaºí skloubit výhody obou p°ístup· spolehlivost proprietárního °e²ení a nízké po°izovací náklady typické pro open-source. Tímto p°ístupem je poskytování BI jako sluºby a ne jako balíkového produktu. Jedním ze zástupc· v této oblasti je i rma s £áste£n¥ £eským obsazením - GoodData. GoodData nabízí BI nástroje £ist¥ prost°ednictvím webového rozhraní. Data jsou nahrávána na server GoodData a dále je moºné s nimi pracovat prost°ednictvím webového prohlíºe£e. Tento p°ístup mimo jiné p°iná²í uº ze své podstaty snaz²í teamovou spolupráci a sdílení jednotlivých projekt·. Oba dynamické p°ístupy jak open-source, tak BI jako sluºba mohou ale dle mého názoru narazit na jistou konzervativnost velkých institucí, které jsou momentáln¥ uºivateli komer£ních produkt·. Tito klienti mohou pom¥rn¥ t¥ºce nést riziko nestability a poskytování vlastních dat t°etím stranám související s bezpe£nostními hrozbami. Jakkoliv jsou tyto d·vody v mnoha p°ípadech spí²e psychologické.

16

KAPITOLA 3. NÁSTROJE PRO BI NA TRHU

Kapitola 4 Analýza existujících nástroj· Jak jiº bylo nazna£eno v kapitole 1.2 aplikace FAKE GAME zatím nedisponuje ºádným sostikovan¥j²ím nástrojem pro na£ítání dat z r·zných zdroj·. Jako datový zdroj v sou£asnosti slouºí výhradn¥ textové soubory. Pentaho poskytuje mimo jiné i nástroje slouºící výhradn¥ tomuto ú£elu. Jeví se tedy jako ú£elné prozkoumat je a zjistit, zda není moºné vyuºít jejich potenciál v rámci FAKE GAME. Vzhledem k tomu, ºe Pentaho a FAKE GAME jsou si tématicky velmi blízké jako opensource Business Intelligence nástroje, má smysl rovn¥º zjistit, zda je moºné FAKE GAME n¥jakým zp·sobem s Pentaho integrovat a vyuºít tak potenciál ²iroce pouºívané a uznávané platformy, kterou Pentaho bezesporu je. Zárove¬ pro Pentaho m·ºe FAKE GAME znamenat dopln¥ní portfolia data miningových funkcí. V dal²ích n¥kolika kapitolách tedy podrobn¥ji prozkoumáme oba softwarové balíky, zejména pak jejich moºnosti propojení s jinými systémy. 4.1

Nástroje z rodiny Pentaho

Jak jiº bylo °e£eno jedná se o celý balík nástroj· pro Business Intelligence. Je to produkt stejnojmenné rmy zaloºené v roce 2004 n¥kolika veterány v oblasti Business Intelligence. Tento balík tvo°í n¥kolik p·vodn¥ nezávisle vyvíjených nástroj·, které jsou postupn¥ integrovány navzájem práv¥ pod hlavi£kou Pentaho. Následuje tedy vý£et jednotlivých komponent.

4.1.1 Pentaho Reporting Jádrem Pentaho Reporting je Pentaho Report Designer (vyvinul se z p·vodn¥ samostatného nástroje JFreeReport). Jde o klasickou grackou aplikaci ur£enou pro návrh vzhledu report· a denici zdroj· dat, kterými se má report naplnit. V²echny takto navrºené reporty je moºné rovnou exportovat do souboru poºadovaného formátu (na výb¥r je PDF, HTML, textové soubory, CSV soubory, soubory pro Excel a Rich text format soubory). Druhou moºností je publikovat vytvo°ené soubory p°ímo v rámci Pentaho BI Platform. Reporty jsou tak dostupné uºivatel·m p°es webové rozhraní. Díky tomu je moºné jim nastavit r·zná p°ístupová práva, nebo nap°. nastavit jejich pravidelné generování a rozesílání zainteresovaným osobám e-mailem. Tuto moºnost - tedy distribuovat výsledné produkty p°es BI 17

18

KAPITOLA 4. ANALÝZA EXISTUJÍCÍCH NÁSTROJ

Platform - nabízí, jak pozd¥ji uvidíme v podstat¥ v²echny nástroje z rodiny Pentaho. Tento p°ístup umoº¬uje jejich vzájemné propojení a tím tvorbu komplexn¥j²ích °e²ení. Pentaho Report Designer disponuje t°emi typy datových zdroj·:

•

Data source - Je vyuºíván pro p°ístup k rela£ním, OLAP, Pentaho metadata a XML datovým zdroj·m. Jedná se tedy o nejobvyklej²í zdroje dat.

•

Custom data source - Umoº¬uje vyuºívat datové zdroje, které nejsou p°ístupné pomocí JDBC nebo XQuery. Tato moºnost vyºaduje naprogramování n¥kolika t°íd v Jav¥, které umoºní p°ístup k poºadovanému datovému zdroji.

•

Data properties - Pomocí Data properties datového zdroje je moºné p°edat jedno-

duché hodnoty jako nap°. název rmy nebo aktuální datum. Vyuºívá se pro p°edání t¥chto hodnot jako vstup· v p°ípad¥, ºe je report spou²t¥n v n¥jaké sekvenci akcí v rámci Pentaho BI Platform (více informací o sekvencích akcí je uvedeno v kapitole 4.5.1).

Pro p°ístup k rela£ním databázím je vyuºíváno JDBC (Java Database Connectivity), p°ípadn¥ JNDI (Java Naming and Directory Index) pro ur£ení datového zdroje v rámci webového serveru. Data se získávají b¥ºnými SQL dotazy. Pentaho je standardn¥ dodáváno s drivery pro tyto databáze:

• Hypersonic • MySQL • Postgres • Derby • DB2 • H2 • Oracle Není v²ak problém dodat v p°ípad¥ pot°eby drivery vlastní. P°ístup k OLAP datovým zdroj·m (v rámci Mondrian) je op¥t realizován p°es JDBC, ov²em musíme nahrát i soubor s popisem schematu p°íslu²ného zdroje (.mondrian.xml). Data získáváme pomocí MDX (Multidimensional Expressions), tedy standardního dotazovacího jazyka pro OLAP databáze). Pentaho Metadata zdroje jsou p°ístupné rovn¥º p°es JDBC v kombinaci s validním metadata modelem (reprezentovaným .xmi souborem). Informace £teme díky Pentaho MQL (Metadata Query Language). MQL je syntax, který uplat¬uje Pentaho Metadata pro generování SQL dotaz· nad metadaty. Pentaho Metadata je projekt vyuºívaný v rámci Pentaho BI Platform a Pentaho Reporting. Jeho cílem je usnadnit koncovým uºivatel·m p°ístup k datovým zdroj·m. Umoº¬uje administrátor·m denovat ur£itou abstraktní vrstvu nad samotnou databází, která dokáºe

4.1. NÁSTROJE Z RODINY PENTAHO

19

prezentovat uloºené informace koncovým uºivatel·m ve stravitelné form¥. Zárove¬ lze nastavit individuální zabezpe£ení a p°ípadn¥ omezit p°ístup k n¥kterým dat·m nebo upravit formát dat a lokalizovat uloºené záznamy. XML datové zdroje jsou p°ístupné standardn¥ p°es XQuery. Je t°eba, aby ve²kerá data byla uloºena v jednom souboru. V neposlední °ad¥ je moºné získávat data i z dal²ího nástroje z rodiny Pentaho a tím je Pentaho Data Integration (popsáno podrobn¥ v kapitole 4.1.3). Díky tomu získáváme zprost°edkovan¥ p°ístup k dal²í obrovské ²kále datových zdroj·, které nemusí p°ímo podporovat Pentaho Report Designer. Nasazení je jednoduché - musíme pouze vybrat soubor s p°íslu²nou transformací navrºenou pomocí Pentah Data Integration a krok transformace, z n¥hoº si p°ejeme data £íst.

4.1.2 Pentaho Analysis Pod krycím názvem Pentaho Analysis se, jak je v p°ípad¥ Pentaho obvyklé, skrývá p·vodn¥ samostatný nástroj Mondrian. Ve dvou v¥tách: Mondrian je OLAP stroj naprogramovaný v Jav¥. Provádí dotazy napsané v MDX (Multi-Dimensional eXpressions) jazyce, £te data z rela£ní databáze a prezentuje je ve vícerozm¥rné form¥ prost°ednictvím Java API. Princip OLAP byl obecn¥ popsán jiº v kapitole 2.2.4. Zde se tedy podíváme na konkrétní realizaci v rámci Mondrian. Systém se skládá ze £ty° vrstev:

•

Prezenta£ní vrstva - Ozna£uje jednodu²e uºivatelské rozhraní pro koncové uºivatele.

Umoº¬uje klást dotazy a pracovat se získanými daty. Je mnoho zp·sob·, jak zobrazovat vícerozm¥rné soubory dat. Mezi n¥ pat°í pivotové tabulky (pivot tables ), nejr·zn¥j²í druhy graf·, ale i pokro£ilé vizualiza£ní nástroje jako interaktivní mapy apod. V p°ípad¥ Mondrian m·ºou jako takovéto klientské rozhraní slouºit komponenty napsané ve Swingu nebo JSP, grafy vykreslené jako obrázky, nebo mohou být data poslána pomocí XML jiné aplikaci. V²echna klientská °e²ení mají spole£nou gramatiku, ve které odesílají (MDX) dotazy OLAP serveru a v níº dostávají odpov¥di.

•

Dimenzionální vrstva - Parsuje, validuje a provádí MDX dotazy. Tedy odesílá poºadavky na £tení jednotlivých hodnot sb¥rné vrstv¥.

•

Sb¥rná vrstva - Je zodpov¥dná p°edev²ím za udrºování cache agregovaných záznam·.

Agregovanými záznamy rozumíme p°edpo£ítaný soubor m¥°itelných hodnot (bun¥k) seskupených podle ur£ité mnoºiny dimenzí. Dimenzionální vrstva tedy vy²le poºadavek na mnoºinu bun¥k. Pokud je tato mnoºina v cache, nebo je moºné ji odvodit zobecn¥ním uloºených záznam·, je vrácena. V opa£ném p°ípad¥ vy²le správce sb¥rné vrstvy poºadavek na ukládací vrstvu.

•

Ukládací vrstva - Je zodpov¥dná za uchovávání dat. V p°ípad¥ Mondrian se jedná o rela£ní databázi. Základní ideou je p°enechat databázi co nejvíce operací. Agregované hodnoty jsou získávány provád¥ním GROUP BY dotaz·. Vedlej²ím efektem tohoto p°ístupu (kdy Mondrian nevyºaduje ºádné vlastní úloºi²t¥) je velmi snadná integrovatelnost celého systému jako prostého JAR archivu.

20


Pro klientské aplikace je k dispozici proprietární API, které se ov²em neli²í od JDBC. Hlavní rozdíl je v dotazovacím jazyce, kdy se místo SQL vyuºívá jiº zmi¬ované MDX. Jednoduchý výpis p°evzatý z dokumentace [17] demonstruje p°ipojení k Mondrian serveru, odeslání MDX dotazu a získání odpov¥di:

import mondrian.olap.*; import java.io.PrintWriter; Connection connection = DriverManager.getConnection( "Provider=mondrian;" + "Jdbc=jdbc:odbc:MondrianFoodMart;" + "Catalog=/WEB-INF/FoodMart.xml;", null, false); Query query = connection.parseQuery( "SELECT {[Measures].[Unit Sales], [Measures].[Store Sales]} on columns," + " {[Product].children} on rows " + "FROM [Sales] " + "WHERE ([Time].[1997].[Q1], [Store].[CA].[San Francisco])"); Result result = connection.execute(query); result.print(new PrintWriter(System.out)); Je tedy z°ejmé, ºe pro práci s Mondrian pot°ebujeme n¥jakou klientskou aplikaci. V p°ípad¥ Pentaho máme takovou aplikaci k dispozici jako webové rozhraní v rámci Pentaho BI Platform. Ta obsahuje komponentu p°ímo pro p°ístup k Mondrian. Tato komponenta vyuºívá ke své £innosti JPivot, coº je knihovna JSP tag· speciáln¥ ur£ených pro vykreslování OLAP tabulek a graf·. JPivot je dal²í samostatný open-source projekt, ale velmi £asto je vyuºíván práv¥ ve spojení s Mondrian. Jak tedy nad rela£ní databází vybudujeme vícerozm¥rnou? V p°ípad¥ Mondrian má toto na starosti kongura£ní soubor ve formátu XML, kde denujeme kompletní datové schema a namapujeme jej na tabulky v rela£ní databázi. V sou£asné dob¥ je t°eba tyto XML soubory vytvá°et ru£n¥ pomocí textového editoru.

4.1.3 Pentaho Data Integration (PDI) Uº nás asi nep°ekvapí, ºe p·vodní název Pentaho Data Integration byl Kettle. Op¥t samostatný projekt, nutno podotknout, ºe z uºivatelského hlediska opravdu povedený. Jedná se o klasický ETL nástroj. V rámci PDI rozeznáváme dva typy úkon·:

•

Transformation - Rozum¥jme transformaci n¥jakých dat. Typicky se jedná o proces,

který si p°edstavíme pod zkratkou ETL. Tedy vy£tení dat z n¥jakého zdroje, jejich následná úprava a op¥tovné uloºení.

•

Job - Pod pojmem job rozumíme n¥jaký úkol, zpravidla opakovan¥ spou²t¥ný, nesouvisí

nutn¥ primárn¥ se p°esunem dat. M·ºe se klidn¥ jednat i o spu²t¥ní transformace nap°. kaºdý první den v m¥síci. asto se jedná o údrºbu, jako pravidelné mazání nebo p°esun soubor·, rozesílání mail·, spou²t¥ní externích skript· atd.


21

PDI zahrnuje t°i základní aplikace:

•

Spoon - Nejzásadn¥j²í nástroj z celé skupiny. Je to gracké uºivatelské rozhraní umoº¬ující velmi jednodu²e "naklikat"poºadovanou sekvenci akcí, která se má vykonat. Zárove¬ jsou k dispozici ladící nástroje pro debugging a prolování. V kaºdém kroku je jak je u podobných aplikací obvyklé - moºné zobrazit náhled na aktuální stav dat.

•

Pan

•

Kitchen - Obdobný jako Pan, ov²em v tomto p°ípad¥ se stará o spou²t¥ní Jobs.

- Jednoduchý program, který dokáºe spou²t¥t transformace vytvo°ené pomocí Spoon z p°íkazové °ádky. Hodí se tedy pro dávkové vyvolávání transformací.

Nabídka operací na výb¥r je opravdu ²iroká. Od základních jako r·zné operace se soubory v p°ípad¥ Jobs, nebo zám¥ny v °et¥zcích, aritmetické operace apod. v p°ípad¥ transformací aº po opravdu mocné akce, umoº¬ující zadat v jednom kroku kód v JavaScriptu, Jav¥ nebo SQL, coº dává vývojá°i prakticky neomezené moºnosti. K tomu p°i£t¥me moºnost tvorby zano°ených transformací a slu²nou °ádku vstupních a výstupních formát·. Data lze získat mimo samoz°ejmé vstupy jako jsou databáze a soubory i z OLAP server· (ne jenom Mondrian), RSS, S3, Salesforca, SAP a dal²ích. V p°ípad¥ transformací prochází celým systémem data v podob¥ jednotlivých °ádek pomyslné tabulky. Je to forma, na kterou se dají namapovat v podstat¥ v²echny podporované typy vstup·. P°i pokro£ilej²í práci s PDI je dobré mít na pam¥ti, ºe data v aplikaci z pochopitelných d·vod· putují ve streamu jako sekvence t¥chto °ádek. Ke kaºdé °ádce se tedy kaºdý krok dostane pouze jednou a nem·ºe se jiº vracet. To ovliv¬uje nap°íklad operace typu JOIN, kde musí práv¥ z t¥chto d·vod· p°icházet na vstupy data jiº se°azená. N¥které kroky toto obcházejí tak, ºe vyºadují vyhrazení odkládacího souboru. To ale m·ºe £asto znamenat úzké hrdlo z hlediska výkonu. Streamový p°ístup totiº umoº¬uje paralelní zpracování, kdy zpracování ve v²ech krocích b¥ºí sou£asn¥ (nad r·znými °ádkami). Co se nasazení v jiných systémech tý£e, máme na výb¥r. Krom¥ zmi¬ovaných aplikací Pan a Kitchen umoº¬ujících dávkové spou²t¥ní disponuje PDI i vlastním API, které je moºné vyuºít v dal²ích Java aplikacích. Podrobn¥ji je tato problematika rozebrána v kapitole 4.4.1. Z druhé strany mají vývojá°i moºnost roz²i°ovat PDI díky jeho pluginové architektu°e. Tento p°ístup je popsán v kapitole 4.4.2.

4.1.4 Pentaho Data Mining Pentaho Data Mining alias Weka (Waikato Environment for Knowledge Analysis). Projekt vyvinutý na univerzit¥ Waikato, v sou£asné dob¥ distribuovaný pod hlavi£kou Pentaho. Data miningový nástroj kompletn¥ napsaný v Jav¥, díky tomu velmi snadno p°enositelný. Weka podporuje standardní data miningové úkoly jako je p°edzpracování dat, klastrování, klasikace, regrese, feature selection. K dispozici je n¥kolik vizualiza£ních nástroj· pro r·zné náhledy na data. Lze pouºít p°ímo jako knihovna p°íslu²ných algoritm· ve vlastních programech. Zárove¬ v²ak disponuje grackým rozhraním pro pohodln¥j²í práci. Gracké rozhraní je rozd¥leno do t°í £ástí:

22


•

Explorer je hlavním ovládacím prost°edím. Poskytuje p°ístup k hlavním komponentám programu, s pomocí nabídek v jednotlivých panelech je moºné nastavit kompletní data miningový proces nad datovým zdrojem, zárove¬ poskytuje gracký náhled na na£tená data.

•

Knowledge Flow zp°ístup¬uje podobné funkce jako Explorer, ov²em data miningový proces sestavujeme podobn¥ jako u PDI vkládáním jednotlivých komponent a jejich propojováním.

•

Experimenter slouºí, jak uº název napovídá, k opakovanému spou²t¥ní a vyhodnocování proces· v r·zných konguracích, p°ípadn¥ s r·znými daty.

Krom¥ grackého rozhraní je moºné ke stejným funkcím p°istupovat i z p°íkazové °ádky. Weka umí na£ítat data pouze z textových soubor· nebo z rela£ních databází (p°es JDBC). Tyto omezené moºnosti je ale moºné roz²í°it jejím propojením s PDI. Na druhou stranu opravdu sostikované moºnosti propojení jsou dostupné pouze v komer£ní verzi Pentaho.

4.1.5 Pentaho BI platform Nástroje, které jsme zatím vid¥li, fungují do zna£né míry samostatn¥. Je sice moºné nap°. data pro Pentaho Data Integration £erpat z Mondrian serveru a zárove¬ dále napojit na Pentaho Report Designer, ale stále nám chybí jednotné rozhraní, kde by bylo moºné toto provád¥t. Chybí nám Pentaho BI platform.

4.1.5.1 Webové rozhraní Pro koncové uºivatele je nejzásadn¥j²í webové rozhraní platformy. Na tomto míst¥ bych rád vyjasnil n¥kolik pojm·. V dal²ím textu rozumím pod pojmem Pentaho BI platform vºdy toto webové rozhraní. V propaga£ních materiálech Pentaho a v jejich dokumentaci se tento pojem pouºívá st°ídav¥ pro webové rozhraní systému a zárove¬ pro celý balík jiº probraných nástroj·. Toto vná²í do text· neskute£ný zmatek a dokáºe za£áte£níkovi °ádn¥ zamotat hlavu. ili Pentaho BI platform je webová aplikace napsaná v Jav¥, provozovaná implicitn¥ na aplika£ním serveru Tomcat. Testována byla i na serveru JBoss. Aby zmatk· nebylo málo, dodám, ºe se jedná vlastn¥ o dv¥ webové aplikace. Jakousi pracovní plochu na jedná stran¥ a administra£ní konzoli na stran¥ druhé. Stáhneme-li Pentaho BI platform v implicitní konguraci, dostáváme zabalený samotný aplika£ní server (tedy Tomcat), na n¥mº je jiº aplikace nainstalovaná, zárove¬ je v balíku dodávána databáze Hypersonic uº napln¥ná pot°ebnými daty. Nicmén¥ migrace na jiné databáze jako MySQL, Oracle nebo PostgreSQL není v tomto p°ípad¥ p°íli² sloºitá a je celkem dob°e popsaná v dokumentaci [20]. Administra£ní konzole je v open-source verzi pom¥rn¥ okle²t¥ná a není na ní nic sloºitého. Slouºí zejména ke správ¥ uºivatel· a jejich oprávn¥ní, dále je moºné spravovat datové zdroje (místo ru£ního nastavování JNDI v kongura£ních souborech serveru) a zprost°edkovává informace o na£asování pravideln¥ spou²t¥ných úkol·. Komer£ní verze pak p°idává monitorovací nástroje pro sledování b¥hu jednotlivých komponent jako PDI, Mondrian atd.


23

Obrázek 4.1: Pracovní plocha Pentaho BI platform

Kone£n¥ se dostáváme k jádru v¥ci. Po p°ihlá²ení se nám zobrazí pracovní plocha, která nevypadá zpo£átku nijak mocn¥ (viz obrázek 4.1). Na první pohled nás zaujme moºnost vytvo°it ad-hoc jednoduchý report, nebo si prohlédnout data p°ístupná p°es Mondrian. Pravá síla se ale skrývá na obrázku v levé £ásti obrazovky. Pracovní plocha je vlastn¥ hodn¥ propracovanou digitální nást¥nkou, která nám dává p°ístup k °e²ením (v anglické terminologii solution ) uloºeným v repozitá°i platformy. Na vysv¥tlenou: e²ením je v tomto kontextu adresá°, v n¥mº jsou uloºeny ve²keré zdroje pot°ebné k dosaºení n¥jakého cíle. Základem jsou zpravidla dva typy soubor·:

• index.xml - Velmi jednoduchý xml kongura£ní soubor. Popisuje, jak se °e²ení zobrazí v rámci platformy (pod jakým názvem, s jakou ikonou apod.). • Jeden nebo více .action soubor· - Op¥t xml soubor, tentokrát popisující úkol, který se má vykonat, v podob¥ jednoduchého workow - sekvence akcí. P°i spu²t¥ní jsou pak postupn¥ na základ¥ tohoto souboru volány r·zné komponenty systému s parametry uvedenými práv¥ zde. Výstupy jednotlivých komponent (akcí) je moºné napojovat na vstupy dal²ích a jednoduchý syntax souboru umoº¬uje i denici základních cykl· a podmínek. Tyto soubory jsou podrobn¥ rozebrány v kapitole 4.5.1. Repozitá° pak není nic jiného neº vyhrazený adresá° v rámci aplikace:

PENTAHO_HOME/pentaho-solutions Sem nahráváme na²e °e²ení. Obsah repozitá°e je pak zobrazen v rámci pracovní plochy podle toho, k jakým °e²ením máme oprávn¥ní p°istupovat. BI platform totiº disponuje mechanismem pro ud¥lování oprávn¥ní p°ístupu k jednotlivým °e²ením pro r·zné uºivatele.

24


Adresa servletu

http://localhost:8080/pentaho/Home http://localhost:8080/pentaho/Login http://localhost:8080/pentaho/Admin

http://localhost:8080/pentaho/Navigate http://localhost:8080/pentaho/UserContent http://localhost:8080/pentaho/getImage

Funkce servletu

Pracovní plocha. P°ihla²ovací dialog. Administra£ní rozhraní - lze provád¥t b¥ºnou údrºbu, obnovovat nastavení serveru (nap°. vynutit nové na£tení a inicializaci plugin·), spravovat naplánované úlohy atd. Pr·zkumník repozitá°e. P°ehled naplánovaných úloh. Servlet pro p°ístup k obrázk·m uloºeným v do£asném adresá°i platformy. Pouºívá se nap°. pro zobrazení graf· a jiných obrázk· v rámci reportu.

Tabulka 4.1: Seznam nejd·leºit¥j²ích servlet· pro práci s Pentaho BI platform Zmínil jsem se o komponentách. Pentaho BI platform zp°ístup¬uje základní funkcionalitu v²ech zatím zmín¥ných nástroj· z této rodiny práv¥ prost°ednictvím komponent. Je k dispozici nap°. komponenta pro rozb¥hnutí PDI transformace a vy£tení dat z ní, komponenta pro £tení dat z Mondrian serveru, zobrazení reportu, ale i dal²í samostatné komponenty - nap°. pro odesílání e-mail·, nebo zpracování JavaScriptu. Komponenty jsou podrobn¥ rozebrány v kapitole 4.5.2. Takto vytvo°ená °e²ení mohou být pak p°ístupná p°es pracovní plochu p°ímo, nebo prost°ednictvím webové sluºby (pokud to dává smysl - tedy pokud sekvence produkuje smysluplný strukturovaný výstup). Krom¥ toho m·ºeme pomocí platformy naplánovat nap°. pravidelné spou²t¥ní vybraných °e²ení. M·ºeme tak vytvo°it nap°. °e²ení, které vy£te z databáze údaje o prodejích za poslední m¥síc, vytvo°í z n¥j report a ten ode²le na n¥kolik e-mail·. Takovéto °e²ení pak naplánujeme na spu²t¥ní kaºdý první den v m¥síci. Na záv¥r doplním seznam nejd·leºit¥j²ích servlet· pro práci s platformou (adresy p°edpokládají implicitní konguraci, kdy Tomcat naslouchá na portu 8080) - p°ehled je uveden v tabulce 4.1.

4.1.5.2 Pentaho Design Studio Velkolep¥ zn¥jící jméno je ve skute£nosti krycí název pro pom¥rn¥ jednoduchý plugin pro Eclipse. Na stránkách projektu [13] zd·vod¬ují auto°i bombastické pojmenování aplikace zejména výhledem do budoucna, kdy by Design Studio m¥lo tvo°it jakési jednotné prost°edí pro vývoj v rámci Pentaho. V sou£asné dob¥ se do této skupiny vejdou dva nástroje. Prvním je Report Design Wizard (pozor nezam¥¬ovat s Pentaho Report Designer popsaným v kapitole 4.1.1). Tento projekt je v²ak na SourceForge prezentaci projektu ozna£en jako Legacy. Moºná z d·vod· ur£ité redundance práv¥ se zmín¥ným Pentaho Report Designer. Zajímav¥j²í je v tomto ohledu Action Sequence Editor. S jeho pomocí je moºné pom¥rn¥ pohodln¥ spravovat .action soubory bez nutnosti editovat ru£n¥ xml. Nejpouºívan¥j²í kom-

4.2. FAKE GAME

25

ponenty mají v rámci tohoto editoru své vlastní dialogy pro intuitivn¥j²í nastavení jejich kongurace. Pro komponenty mén¥ pouºívané nebo nov¥ doprogramované je pak k dispozici generické prost°edí pro nastavení vstup·, výstup·, parametr· a zdroj· dat.

4.1.6 Pentaho Dashboards Pentaho Dashboard je vlastn¥ framework pro denici digitálních nást¥nek, které se následn¥ zobrazují op¥t v rámci Pentaho BI Platform. V sou£asné dob¥ je k dispozici nová verze tohoto frameworku, která v mnohém zjednodu²ila tvorbu nást¥nek. V p·vodní verzi bylo nutné denovat nást¥nky pom¥rn¥ zmate£ným zp·sobem v n¥kolika souborech obsahujících JavaScript, HTML a denici styl· zobrazení nást¥nky. V sou£asné dob¥ se obejdeme pouze se dv¥ma soubory:

• index.xml - Jako u v²ech °e²ení v rámci Pentaho BI Platform repozitá°e obsahuje název nást¥nky a její popis. • template.html - Obsahuje denici samotného obsahu nást¥nky - jak statického obsahu, tak dynamicky generovaných £ástí. Dynamicky generované £ásti jsou vlastn¥ javaScriptové objekty, které zpravidla £erpají obsah z výstup· p°edem denovaných sekvencí akcí. M·ºeme tedy nap°. denovat sekvenci akcí starající se o vy£tení dat z databáze, která na výstupu generuje graf jako obrázek a následn¥ tento obrázek zobrazit pomocí javaScriptového objektu typu xaction. Denice by pak mohla vypadat nap°. takto:

regionVarianceBarChart = { name: "myDataChart", type: "xaction", solution: "dashboards", path: "sample_dashboard_components", action: "myDataChart.xaction", listeners:\["group"\], parameters: \[\["GROUP","group"\]\], htmlObject: "object_2", executeAtStart: false, } K dispozici jsou komponenty pro zobrazení jednoduchého textu, formulá°·, tabulek aº po ty komplexní vyuºívající nap°. JPivot, nebo Google Maps API. 4.2

FAKE GAME

V p°ípad¥ FAKE GAME se jedná o data miningový software vyvíjený na VUT. Hlavním cílem projektu je poskytnout nástroj pro automatizovanou tvorbu report· bez nutnosti zásahu uºivatele. Toto je pom¥rn¥ revolu£ní my²lenka, vzhledem k tomu, ºe tvorba report· pomocí konkuren£ních °e²ení vyºaduje £asto pokro£ilou znalost dané problematiky.

26


Hlavní devizou FAKE GAME je automatické vytvá°ení model· aniº by bylo nutné je ru£n¥ nastavovat. Jednotlivé modely jsou r·zn¥ kongurovány a dále ²lecht¥ny nap°. vyuºitím genetických algoritm·. FAKE GAME pro dosaºení lep²ích výsledk· pouºívá ensemble metody, tedy p°ístup, kdy jsou r·zné modely vzájemn¥ kombinovány.

4.2.1 Architektura systému a jeho roz²i°itelnost Koncept umoº¬ující automatické zpracování je podle dostupné dokumentace [14] tak zvaný Operation Flow (sled jednotlivých operací). Jednotlivé operace (po£ínaje na£tením dat, jejich p°edzpracováním aº po vizualizaci dat, tvorbu a vyhodnocení model·) jsou z°et¥zeny v jednoduché sekvenci, jak je patrné z obrázku 4.2.

Obrázek 4.2: Operation Flow v aplikaci FAKE GAME. P°íklad DMBatchProle [14] Kaºdá díl£í operace m·ºe vyprodukovat svou £ást výsledného reportu. Zárove¬ mohou díl£í operace p°edp°ipravovat data pro operace následující. Ve²kerá data putující v systému mezi jednotlivými operacemi jsou ukládána na Blackboard. Jedná se o hierarchickou stromovou strukturu podobnou souborovému systému. Sekvence operací m·ºe být r·zná. Jejich uspo°ádání ur£uje v rámci FAKE GAME Prole. Na obrázku 4.2 je zobrazený p°íklad DMBatchProle. Ten je ur£ený pro dávkové zpracování a automatickou produkci reportu. Je schopný sám ur£it, o jakou úlohu se jedná (moºnosti jsou: samoorganiza£ní problém, regresní problém nebo klasika£ní problém). Jednotlivé proly je dále moºné kongurovat pomocí XML soubor·. Jak je z obrázku patrné, typický prol sestává z inicializa£ní fáze následované na£tením dat (v tomto p°ípad¥ z textového souboru), pokra£uje p°edzpracováním dat, jejich p°ípadnou redukcí. Dále se provádí r·zné vizualizace, sestavení model· na základ¥ p°edané kongurace a jejich testování a vyhodnocení výsledk·. Výsledky operací jsou shrnuty v reportu.

4.3. DATA MINING A JEHO INTEGRACE V NÁSTROJÍCH PENTAHO

27

Je tedy z°ejmé, ºe pro dopln¥ní funkcionality do FAKE GAME je t°eba upravit stávající DMBatchProle, nebo vytvo°it prol nový. Sestavování prol· funguje ve FAKE GAME na základ¥ návrhového vzoru Strategy [6]. Jeho konkrétní realizace je znázorn¥na na obrázku 4.3.

Obrázek 4.3: Realizace návrhového vzoru Strategy v rámci FAKE GAME

Pro realizaci prvního úkolu tedy bude nejjednodu²²í nahradit v kontextové t°íd¥ OperationFlow operaci ImportFile operací, která provede PDI transformaci a na£te z ní pot°ebná data. Obdobn¥ m·ºeme postupovat p°i pot°eb¥ dodání jakékoliv dal²í operace. Jediné, co je v·£i FAKE GAME t°eba splnit je implementace p°íslu²ného interface IOperation. Dal²ím zajímavým aspektem je tvorba výsledného reportu. Jak jiº bylo °e£eno, kaºdá operace m·ºe vyprodukovat £ást výsledného reportu reprezentovanou rozhraním ISubreport. Konkrétní t°ídy implementující toto rozhraní zpravidla obsahují instanci t°ídy SubreportContainer, coº je skute£ná reprezentace "subreportu". Kaºdá £ást reportu se totiº skládá z r·zných objekt· (obrázky, texty tabulky apod.). Tyto objekty se p°idávají práv¥ do instance t°ídy SubreportContainer. Tato skute£nost je zachycena zjednodu²eným class diagramem na obrázku 4.4. Kaºdý SRObject umí vyvolat instanci t°ídy, která jej dokáºe vykreslit. Zp·sob vykreslení závisí na konkrétní implementaci abstraktní t°ídy SRRenderer. Takovou konkrétní implementací je nap°. SRHTMLRenderer, který vytvá°í report ve formátu HTML.

4.3

Data Mining a jeho integrace v nástrojích Pentaho

Pokud uvaºujeme nad moºnostmi propojení FAKE GAME a Pentaho je nasnad¥ prozkoumat, jak je data mining jiº implementován v rámci platformy. P°i hlub²ím pátrání objevíme n¥kolik jednodu²²ích plugin· pro PDI. Jmenovit¥ jde o Univariate Statistics plugin, který ned¥lá nic sv¥toborného. Pouze je na výstupu schopný vyprodukovat n¥které statistické hodnoty jako je minimum, maximum, po£et poloºek na vstupu, aritmetický pr·m¥r atd. Dal²ím je ARFF Output Plugin, pro ukládání dat ve formátu ARFF (Attribute-Relation File Format) a Reservoir Sampling Plugin, který umoº¬uje vybrat pevný po£et °ádek ze

28


Obrázek 4.4: Skládání report· v rámci FAKE GAME

vstupu (aniº bychom p°edem znali jejich celkový po£et), p°i£emº kaºdá °ádka má stejnou pravd¥podobnost být vybrána. Nicmén¥ vlajkovou lodí Pentaho v oblasti data mining je Weka, takºe nás asi nep°ekvapí, ºe nejzajímav¥j²í implementace vyuºívají práv¥ ji. Jedná se o komponentu pro provád¥ní wekovských knowledge ows v rámci Pentaho BI platform a o dva pluginy pro PDI. Ov²em pouze první plugin - Weka Scoring Plugin - je dostupný jako Open Source. V podstat¥ v²echny modely sestavené pomocí Weky je moºné exportovat jako serializované Java objekty. Weka Scoring Plugin umoº¬uje takto serializované modely na£íst a aplikovat na vstupní data. Výsledkem je pro kaºdou vstupní instanci bu¤ její klasikace, nebo £íselný odhad výstupní hodnoty. V p°ípad¥ klasikace máme dv¥ moºnosti reprezentace výsledku: p°ímo jako výstupní t°ídu, nebo nep°ímo jako vý£et pravd¥podobností p°íslu²nosti ke v²em t°ídám (output probabilities ). V rámci placené verze PDI Pentaho dodává navíc Knowledge Flow Plugin, který umoº¬uje na£ítat a provád¥t knowledge ows vytvo°ené pomocí Weky. Dokonce je moºná jejich úprava p°ímo v prost°edí PDI. Jeho zprovozn¥ní vyºaduje navíc p°idání pluginu i do samotné Weky. Tento plugin umoºní Wecce p°ijímat v rámci knowledge ow data z PDI transformací. Dal²í funkcí zp°ístupn¥nou jen platícím uºivatel·m je speciální komponenta pro BI platform, která umí zrealizovat v podstat¥ to samé jako Knowledge Flow Plugin, tedy na£íst a provést knowledge ow vyexportované z Weky. Tentokrát ale p°ímo ve webovém prost°edí BI platform. Funk£n¥ se tak poslední dv¥ zmín¥né implementace dost kopírují, nicmén¥ mají pravd¥podobn¥ své opodstatn¥ní vzhledem k pom¥rn¥ vysoké po°izovací cen¥ BI Platform se jist¥ najde hodn¥ uºivatel·, kte°í vyuºívají v komer£ní verzi nap°. jen PDI v kombinaci s Wekou.

4.4. MONOSTI ROZÍENÍ PENTAHO DATA INTEGRATION

29

Z hlediska FAKE GAME vidím na základ¥ t¥chto poznatk· dv¥ zajímavé moºnosti. První je obdoba Weka Scoring Plugin. FAKE GAME disponuje modely, které Weka nemá. Pro uºivatele Petaho m·ºe tedy být zajímavé tyto r·zné implementace porovnat. Zárove¬ je v tomto sm¥ru práce obou program· dosti podobná a plugin pro FAKE GAME by mohl fungovat velmi podobn¥ jako jiº známé a zaºité °e²ení. FAKE GAME totiº také disponuje moºností exportovat modely v serializované podob¥. Dal²í uºite£nou implementací by z mého pohledu byla integrace FAKE GAME p°ímo do BI platform. Zde dob°e zapadá do celkového konceptu platformy, kdy nad daty, která získáme nap°. pomocí PDI nebo vy£teme z Mondrian serveru dokáºe provést b¥ºné data miningové operace (v tomto p°ípad¥ se velmi hodí celková lozoe tvorby report· bez nutnosti zásahu uºivatel·) a vyprodukovat komplexní zprávu zobrazitelnou p°ímo v prost°edí pracovní plochy platformy. Za tímto ú£elem by tedy bylo t°eba vytvo°it komponentu pro BI platform, která umoºní za°adit FAKE GAME mezi akce pouºitelné prost°ednictvím kongurace .action soubor·. 4.4

Moºnosti roz²í°ení Pentaho Data Integration

Dosavadní pr·zkum ukázal relativn¥ velký potenciální p°ínos, který skýtá vyuºití PDI a to hned dv¥ma zp·soby. Jednak jako knihovnu, kdy FAKE GAME bude vyuºívat PDI API pro interpretaci a spou²t¥ní transformací vytvo°ených pomocí PDI. FAKE GAME tak získá nejen opravdu ²irokou paletu zdroj·, z nichº bude schopný na£ítat data, ale i mnoºství uºite£ných nástroj· pro p°ípravu t¥chto dat, jejich £i²t¥ní apod. Opa£ným sm¥rem jde nasazení FAKE GAME jako pluginu pro PDI. V této kapitole si popí²eme technické nároky obou t¥chto implementací.

4.4.1 PDI API Základem PDI API je t°ída Trans reprezentující kompletní transformaci. Obsah transformace je uchováván v instanci t°ídy TransMeta. Transformaci spustíme metodou execute, s volitelnými parametry. Celé zpracování probíhá ve vláknech, proto je t°eba po£kat na dokon£ení jejich práce metodou waitUntilFinished. Uvádím krátký p°íklad provedení takové transformace na£tené ze souboru:

public static void runTransformation(String filename) { try { StepLoader.init(); EnvUtil.environmentInit(); TransMeta transMeta = new TransMeta(filename); Trans trans = new Trans(transMeta); trans.execute(null); trans.waitUntilFinished(); if ( trans.getErrors() > 0 ) { throw new RuntimeException( "Errors during transformation execution." );

30

}


} } catch ( KettleException e ) { System.out.println(e); }

Pomocí PDI API lze transformaci i r·zn¥ upravovat. Na tomto míst¥ bych ale cht¥l podotknout, ºe se ve skute£nosti nejedná o API v pravém slova smyslu, tedy o ve°ejn¥ deklarované rozhraní pro ostatní aplikace, které garantuje alespo¬ elementární zp¥tnou kompatibilitu. V p°ípad¥ sloºit¥j²ích operací s transformací je vývojá° nucen pono°it se pom¥rn¥ hluboko do vnit°ní implementace PDI a vystavuje se tak hrozb¥ nekontrolovatelných zm¥n v dal²ích verzích programu. I uvedený p°íklad je platný pro PDI do verze 3. Ve verzi 4 do²lo k pom¥rn¥ rozsáhlým zm¥nám a dokonce v rámci takto jednoduchého p°íkladu je t°eba volání

StepLoader.init(); EnvUtil.environmentInit(); nahradit

KettleEnvironment.init(); P·vodní volání bohuºel není zp¥tn¥ kompatibilní.

4.4.2 Pluginy pro PDI P°íslu²ná dokumentace[1] je pom¥rn¥ strohá. Lep²ím zdrojem informací je zkoumání zdrojových kód· existujících plugin·. Kaºdý plugin pro PDI musí obsahovat minimáln¥ £ty°i t°ídy implementující následující rozhraní:

• StepMetaInterface - Uchovává informace o nastavení pluginu, umoº¬uje jeho ukládání a na£ítání, denuje mnoºinu vstupních a výstupních hodnot, s nimiº plugin pracuje. • StepInterface - Samotné výkonné jádro pluginu. Mimo jiné implementuje metodu processRow, která zpracovává jednotlivé °ádky dat proudící systémem. • StepDataInterface - T°ída implementující toto rozhraní je ur£ena pro udrºování provozních informací jako nap°. otev°ené soubory, r·zné kurzory a streamy. Význam t°íd implementujících toto rozhraní není úpln¥ jednozna£n¥ z°ejmý. N¥které existující pluginy je trochu zmate£n¥ vyuºívají i jako odkladi²t¥ uºite£ných funkcí. • StepDialogInterface - Denuje uºivatelský dialog pro úpravu nastavení pluginu. Vzhledem k pom¥rn¥ komplikované struktu°e rozhraní StepMetaInterface a StepInterface, která ob¥ p°edepisují p°ibliºn¥ 50 metod k implementaci se doporu£uje zd¥dit v¥t²inu metod od t°íd BaseStepMeta a BaseStep a p°epsat jen metody, které se mají

4.5. MONOSTI ROZÍENÍ PENTAHO BI PLATFORM

31

chováním li²it od implicitního. Toto není úpln¥ ²ástný p°ístup z hlediska kvality návrhu. Kaºdopádn¥ vnit°ní struktura PDI je trochu zmate£ná, coº spolu s absencí kvalitní dokumentace v této oblasti vývojá°e k takovému p°ístupu v podstat¥ nutí a v¥t²ina plugin· t°etích stran této obezli£ky vyuºívá. Na názvech konkrétních t°íd záleºí. PDI o£ekává, ºe jméno t°ídy implementující StepMetaInterface bude kon£it na Meta a jméno t°ídy implementující StepDialogInterface bude kon£it na Dialog. Prex musí mít ob¥ t°ídy stejný. Tedy nap°. MujPluginMeta a MujPluginDialog. Samotná instalace pluginu je velmi jednoduchá. Plugin tvo°í .jar soubor se zkompilovaným zdrojovým kódem pluginu, dále ikona reprezentující plugin v grackém rozhraní, volitelné dal²í knihovny pot°ebné pro chod pluginu a soubor plugin.xml v tomto formátu:

V²echny tyto soubory je nutné nakopírovat do adresá°e PDI_HOME/plugins/steps. 4.5

Moºnosti roz²í°ení Pentaho BI platform

4.5.1 Sekvence akcí Jak jsme vid¥li v kapitole 4.1.5 základním zp·sobem roz²í°ení funk£nosti Pentaho BI platform je denice vlastního °e²ení. Tedy sestavení .action souboru. Poj¤me se nyní podívat podrobn¥ji na jeho strukturu:

Nazev reseni 1 ERROR <documentation> Ivo Lasek <description>Popis reseni Navod k pouziti

32


Vidíme tedy, ºe kaºdá sekvence akcí obsahuje na po£átku popisnou £ást denující vesm¥s zp·sob jejího zobrazení v rámci pracovní plochy a úrove¬ logování. Dále je moºné denovat vstupy, výstupy a zdroje. Jako vstupy mohou slouºit parametry p°edané v url p°i vyvolání sekvence, nebo data p°ijatá p°i volání webové sluºby. Výstupy vytvá°í jednotlivé komponenty v pr·b¥hu zpracování sekvence. V poli outputs tedy m·ºeme deklarovat, které z nich sekvence opravdu vrací. Pole resources obsahuje seznam soubor·, které pot°ebují pouºité komponenty ke své £innosti - m·ºe se jednat nap°. o uloºenou PDI transformaci. Následuje vlastní seznam akcí. Volání komponent je popsáno v £ásti action-definition. Pro ilustraci uvádím p°íklad volání komponenty provád¥jící PDI transformaci:

KettleComponent Pentaho Data Integration <monitor-step> Denujeme tedy název komponenty, kterou chceme volat. Dále máme podobn¥ jako u celé sekvence moºnost denovat vstupy, výstupy a zdroje pot°ebné pro £innost komponenty. V uvedeném p°íklad¥ denujeme jako zdroj soubor s transformací, jehoº název o£ekáváme jako vstup celé sekvence p°edaný parametrem transformation-file. Komponenta je


Název datového typu content bigdecimal inputstream integer list long object property-map property-map-list result-set

string string-list

33

Podporované hodnoty

Stream dat vyprodukovaný komponentou. Odpovídá typu BigDecimal v Jav¥. Odpovídá typu InputStream v Jav¥. Odpovídá typu Integer v Jav¥. Odpovídá typu java.util.List v Jav¥. Odpovídá typu Long v Jav¥. Odpovídá typu Object v Jav¥. Mapa °et¥zc·. Seznam map °et¥zc· - v podstat¥ p°ipomíná tabulku. Seznam polí objekt·. Umoº¬uje reprezentovat data ve form¥ tabulky. Na rozdíl od typu property-map-list je s jeho pomocí moºné p°edávat r·zné datové typy, nejenom °et¥zce. Reprezentován rozhraním IPentahoResultSet. Odpovídá typu String v Jav¥. Seznam °et¥zc·.

Tabulka 4.2: Seznam datových typ· podporovaných v rámci Pentaho BI platform schopna vrátit prom¥nné execStatus, outRows apod. Ty namapujeme na výstupy s názvem kettle-execution-log a transformation-output-rows atd. V £ásti component-definition uvádíme konstantní nastavení komponenty, které nepot°ebujeme ovliv¬ovat vstupními parametry. Tyto denice akcí je moºné °et¥zit a napojovat výstupy akcí na vstupy jejich následník·. Velmi primitivním zp·sobem tak m·ºeme sestavovat jednoduché skripty. Jednotný formát dat pro p°enos mezi komponentami je °e²en konverzí na n¥kolik jednoduchých datových typ·, které jsou platformou podporovány. Jejich vý£et je uveden v tabulce 4.2.

4.5.2 Komponenty a pluginy Uº mnohokrát jsem se zmi¬oval o komponentách jako hlavních funk£ních jednotkách v rámci platformy. Je tedy na £ase podívat se podrobn¥ji, jak taková komponenta funguje. Pokud vyvolám v rámci platformy n¥jakou sekvenci akcí, a´ uº jako webovou sluºbu, p°es aplikaci t°etí strany nebo prost°ednictvím uºivatelského rozhraní, dochází k následujícímu cyklu zpracování: 1. Volající si vyºádá spu²t¥ní sekvence. 2. Daná sekvence je vyhledána a na£tena z repozitá°e. 3. Dochází k její validaci, tedy k validaci .action souboru. 4. V²echny obsaºené komponenty jsou na£teny a inicializovány.

34


Metoda done

executeAction getLogger init validateAction validateSystemSettings

innost metody

Volána po ukon£ení £innosti komponenty. Vhodná pro úklid, jako nap°. uzav°ení pouºívaných zdroj·. Samotné provedení stanoveného úkolu. Vrací logovací objekt pro komponentu. Volána po na£tení komponenty. Obsahuje inicializa£ní rutiny. Zde by si komponenta m¥la ov¥°it, zda má v²echny pot°ebné vstupy a zdroje. Pokud metoda vrátí false, sekvence se p°eru²í a úkol komponenty se nevykoná. Chová se podobn¥ jako p°edchozí metoda s tím rozdílem, ºe by m¥la ov¥°it správnost systémových nastavení, jako je nap°. p°ipojení k databázi, nastavení p°ipojení k mailovému serveru apod.

Tabulka 4.3: Seznam metod rozhraní org.pentaho.core.component.IComponent 5. Následuje fáze validace jednotlivých komponent, kdy si kaºdá komponenta nap°. ov¥°í, zda dostává správné vstupy, p°ípadn¥ zda jsou správn¥ o²et°eny výstupy. 6. Spustí se provád¥ní celé sekvence, které spo£ívá v postupném spou²t¥ní komponent podle .action souboru. 7. Sekvence je ukon£ena, p°ípadné výstupy jsou vráceny volajícímu. Aby na²e vlastní komponenty mohly fungovat v rámci BI platform, musí jako vºdy implementovat p°íslu²né rozhraní. V tomto p°ípad¥ se jedná o IComponent. Jeho metody jsou shrnuty v tabulce 4.3. Doposud vypadá toto °e²ení pom¥rn¥ sch·dn¥. Bohuºel samotná implementace rozhraní nesta£í. Komponenta se n¥jakým zp·sobem musí dostat ke svým vstup·m, prezentovat výstupy, £íst systémová nastavení a pro tyto informace je t°eba sáhnout pom¥rn¥ hluboko do útrob celého systému. Vývojá°i tedy shrnuly nejb¥ºn¥j²í úkony v jakémsi API [9], které p°edstavuje t°ída ComponentBase. Podobn¥ jako u plugin· pro PDI je tedy vývojá° nucen d¥dit od této t°ídy, coº m·ºe být v mnoha p°ípadech svazující. Nemluv¥ o nep°ehlednosti rozsáhlého kódu zd¥d¥ného od rodi£ovské t°ídy. Na kaºdý pád se díky tomuto p°ístupu stávají komponenty pom¥rn¥ úzce závislé na vnit°ní implementaci celého systému a tak náchylné ke zkáze zp·sobené potenciálními zm¥nami struktury projektu v jeho dal²ích verzích. Na²t¥stí zde na rozdíl od PDI existuje zda°ilá alternativa v podob¥ lépe zvládnuté pluginové architektury, která se v platform¥ objevila teprve nedávno (s verzí 3.0 a byla dále rozpracována ve verzi 3.5 - tedy v posledním stabilním vydání). Pluginy a zejména v jejich rámci zp°ístupn¥né Akce p°edstavují odleh£enou variantu komponent bez návaznosti na vnit°ní strukturu celého projektu. Podrobn¥ji je tato problematika rozebrána v následující kapitole.


35

4.5.3 Jednotlivé sou£ásti pluginu Pluginy v rámci Pentaho BI platform poskytují hned n¥kolik zp·sob·, jak upravit chování platformy. K dispozici jsou následující moºnosti:

•

Úprava menu pracovní plochy. Spo£ívá v prosté denici p°íslu²né poloºky v kongura£ním souboru pluginu plugin.xml, o n¥mº bude °e£ vzáp¥tí.

P°ekrývání existujícího obsahu.

•

V sou£asné dob¥ je moºné p°izp·sobit pouze spou²t¥cí obrazovku a menu v rámci pracovní plochy. Vyuºívá se XUL (XML User interface Language), coº je standard pro denici uºivatelských rozhraní vyvinutý v rámci projektu Mozilla. V p°ípade BI platform umisújeme jeho denici op¥t do souboru plugin.xml.

•

Denice statického obsahu.

•

Denice nových typ· obsahu. BI platform standardn¥ umí zpracovat n¥které typy

Nový statický obsah implementujeme v rámci platformy velmi jednodu²e. Denujeme cestu k p°íslu²nému souboru a url, pod níº bude dostupný v plugin.xml. soubor·. e£ byla o .xaction souborech, podobn¥ je tom nap°. u denic report· (.prpt soubory). V rámci pluginu máme moºnost denovat dal²í obsah, který zatím platforma nepodporuje a ur£it t°ídu, která umí p°íslu²ný obsah zpracovat (tak zvaný ContentMetaProvider).

•

Generátor obsahu. Jde o javovskou t°ídu implementující rozhraní IContentGenerator. Základem t°ídy je metoda createContent, která - jak uº název napovídá - dokáºe vyprodukovat n¥jaký obsah a p°edat jej do výstupního streamu. Ten je pak platforma schopna zobrazit uºivateli.

•

Lifecycle listener.

•

Nové komponenty.

Asi nejzajímav¥j²í moºností je p°edstavení nových funk£ních celk· - velmi podobných komponentám popsaným v p°edchozí kapitole. V rámci plugin· je budeme nazývat Akcemi. Na rozdíl od komponent není t°eba d¥dit od ºádné t°ídy. Musíme pouze implementovat p°íslu²ný interface. Velmi p°íjemná je práce se vstupy a výstupy. Akce by se m¥la chovat jako klasická javovská beana. Ve²keré nastavování vstup· a výstup· se d¥je na základ¥ reexe pomocí klasických setter· a getter·. Vývojá° se tak nemusí starat o to, kde a jak jsou data v rámci platformy uloºena.

•

Webové sluºby. A£koliv v podstat¥ v²echny Akce je schopna platforma vystavit jako

Pentaho nám dává moºnost provést n¥které p°ípravné rutiny v r·zných fázích ºivota pluginu. M·ºeme reagovat na t°i typy událostí: inicializace pluginu (init), jeho na£tení (loaded) a jeho deaktivace (unloaded). Za tímto ú£elem je t°eba vytvo°it t°ídu implementující rozhraní IPluginLifecycleListener a platformu upozornit na jeho existenci op¥t prost°ednictvím souboru plugin.xml.

webové sluºby na základ¥ jejich rozhraní, máme k dispozici moºnost denovat i webové sluºby jako takové v p°ípad¥, ºe vzhledem k jejich funkcionalit¥ nedává p°íli² smysl prezentovat je b¥ºným uºivatel·m v rámci pracovní plochy.

36


•

GWT RPC sluºby.

Od poslední vydané verze podporuje Pentaho i vytvá°ení sluºeb vyuºívajících GWT RPC (Google Web Toolkit Remote Procedure Call). V rámci platformy je k dispozici GWT RPC proxy servlet. Ten dokáºe nasm¥rovat p°íchozí poºadavky p°íslu²ným objekt·m, které je umí obslouºit. V²echny poºadavky z klientské £ásti aplikace musí tedy sm¥°ovat práv¥ na tento servlet. Vyuºití známého frameworku GWT vná²í do jinak pom¥rn¥ statických plugin· notnou dávku interaktivity a do budoucna vypadá jako velmi slibný trend. Vzhledem k tomu, ºe je ale tento mechanismus pom¥rn¥ mladý, je dostupná jen základní dokumentace a ºádná nativní komponenta jeho moºnosti v sou£asné dob¥ nevyuºívá, ozna£il bych jeho nasazení zatím spí²e za experimentální.

Typický plugin tvo°í soubor plugin.xml a adresá° lib, který obsahuje pot°ebné JAR soubory. Strukturu souboru plugin.xml nazna£uje následující výpis:

<static-paths> <menu-items> <menu-item/>

4.6. ZÁVREM

37

Jak vidíme soubor plugin.xml tvo°í jakýsi rozcestník, podle kterého jsou inicializovány a zaregistrovány v²echny sou£ásti pluginu p°i jeho na£tení platformou. P°edstavený p°ístup umoº¬uje pluginy do platformy exibiln¥ p°idávat a zase je z ní odebírat, aniº bychom se jakkoliv museli dotknout struktury samotné aplikace. 4.6

Záv¥rem

Na základ¥ prezentovaných informací jsem se rozhodl za ú£elem napln¥ní cíl· stanovených v úvodu (v kapitole 1.2) vytvo°it t°i projekty. V prvním p°ípad¥ jde spí²e o dopln¥ní funkcí do stávajícího projektu, tedy o roz²í°ení FAKE GAME o volání PDI API a zpracování takto získaných informací. V dal²ích dvou p°ípadech jde o vytvo°ení plugin· za ú£elem zp°ístupn¥ní základní funkcionality FAKE GAME v rámci Pentaho. Prvním je plugin pro PDI, velmi podobný jiº existujícímu Weka Scoring pluginu. Díky n¥mu je moºné velmi snadno porovnávat v prost°edí PDI modely vytvo°ené pomocí FAKE GAME a modely vytvo°ené prost°ednictvím Weky. T°etím a posledním °e²ením je plugin p°ímo pro BI platform, který tvo°í jakýsi most mezi FAKE GAME a zbylými nástroji z rodiny Pentaho. Dal²í £len¥ní práce do kapitol tedy odpovídá jednotlivým projekt·m.

38


Kapitola 5 Vyuºití PDI API v rámci FAKE GAME

Obrázek 5.1: Ukázka transformace vytvo°ené pomocí PDI, kterou je FAKE GAME schopný zpracovat.

5.1

Realizace

5.1.1 Popis PDI API Samotný zp·sob nasazení PDI API je pom¥rn¥ p°ímo£arý a popsal jsem jej jiº v kapitole 4.4.1. Zde se podíváme na n¥která úskalí, na n¥º jsem b¥hem práce narazil a která bohuºel nejsou v materiálech Pentaho moc dob°e zdokumentovaná. Zdrojový kód uvedený v kapitole 4.4.1 sice ukazuje, jak transformaci spustit, ale uº není p°íli² z°ejmé, jak z ní dostat n¥jaká data. V tomto ohledu máme dv¥ moºnosti. 39

40

KAPITOLA 5. VYUITÍ PDI API V RÁMCI FAKE GAME

První °e²ení spo£ívá v provedení celé transformace a vy£tení výsledku metodou getResult(). Následující fragment kódu ukazuje, jak m·ºe takový postup vypadat.

trans.execute(null); // Transformace se vykonává paraleln¥, // proto je pot°eba vy£kat na ukon£ení v²ech vláken. trans.waitUntilFinished(); // Nakonec na£teme výsledek, z n¥hoº je moºné získat seznam °ádek. List rows = trans.getResult().getRows(); Záhy ale zjistíme, ºe je takto získaný výsledek krom¥ n¥kterých statistických údaj· (jako doba provád¥ní, po£et zpracovaných záznam· apod.) prázdný. Samotná data musíme do výsledku zkopírovat zvlá²tním korkem transformace s názvem Copy rows to result z kategorie Job. Tento krok musí za°adit bu¤ p°ímo uºivatel p°i vytvá°ení transformace, nebo je t°eba vyuºít ²ir²ích moºností PDI API a p°idat jej automaticky. Postup je popsaný v dokumentaci [18]. Je z°ejmé, ºe takovéto °e²ení skýtá mnohá úskalí. Krom¥ problém· s identikací správného místa pro automatické vloºení kroku Copy rows to result u sloºit¥j²ích transformací vidím hlavní problém ve zp·sobu práce s daty. Celá transformace se provede a následn¥ jsou ve²kerá výsledná data zkopírována do jednoho úloºi²t¥ v pam¥ti. Vzhledem k jejich potenciáln¥ velkému rozsahu bychom tak vytvo°ili zbyte£n¥ úzké hrdlo v podob¥ omezené kapacity pam¥ti. Druhý p°ístup, který jsem nakonec zvolil, spo£ívá ve vytvo°ení instance vlastní t°ídy naslouchající na vybraném kroku a zpracovávající jednotlivé °ádky dat po jedné. Tedy ve zkratce vyuºití návrhového vzoru Observer [6]. Základní princip je znázorn¥n na obrázku 5.2. T°ída OutputRowListener tedy implementuje zejména metodu rowWrittentEvent p°ijímající data z výstupu sledovaného kroku a p°eposílá takto získaná data dále do útrob FAKE GAME.

Obrázek 5.2: Ukázka £tení dat z transformace za vyuºití návrhového vzoru Observer

5.1. REALIZACE

41

Op¥t je t°eba dávat pozor na n¥které záludnosti. Oproti kódu z kapitoly 4.4.1 musíme transformaci p°ed spu²t¥ním p°ipravit - tedy nalézt vybraný krok (podle jeho názvu) a p°edat mu ná² OutputRowListener.

trans.prepareExecution(null); BaseStep step = trans.findRunThread(outputStepName); step.addRowListener(new OutputRowListener()); Samotnou transformaci pak nelze spou²t¥t metodou execute, která by p°epsala námi vloºené nastavení, nýbrº metodou startThreads, tedy:

trans.startThreads(); trans.waitUntilFinished();

5.1.2 Závislosti a pouºité knihovny FAKE GAME vyuºívá pro správu projektu nástroj z dílny Apache - Maven. PDI krom¥ Subversion pro správu verzí nevyuºívá ºádný specializovaný nástroj. Ve²keré závislosti si vývojá° stáhne z repozitá°e projektu umíst¥né v adresá°i libext/. Pentaho BI platform vyuºívá pro správu závislostí rovn¥º nástroj z dílny Apache, ov²em tentokrát je jím odleh£ené Ivy. Nicmén¥ p°íslu²né repozitá°e jsou alespo¬ v p°ípad¥ Pentaho kompatibilní s Mavenem. Vzhledem k tomu, ºe Pentaho BI platform obsahuje i komponentu pro provád¥ní PDI transformací do²el jsem k záv¥ru, ºe je moºné tyto závislosti p°ece jen z repozitá°· Pentaho vydolovat. Tento nápad jsem i zrealizoval a vyprodukoval seznam závislostí jak ve formátu pro Maven, tak ve formátu Ivy. Bohuºel v pr·b¥hu práce do²lo ke zm¥n¥ verze PDI z verze 3 na verzi 4. Rozhodl jsem se vlastní kódy p°izp·sobit verzi 4, coby aktuáln¥j²ímu vydání. K t¥mto kód·m v²ak v repozitá°ích je²t¥ nejsou k dispozici odpovídající knihovny. Bylo tedy nakonec p°eci jen nutné nahrát p°íslu²né knihovny do repozitá°· projektu FAKE GAME.

5.1.3 Roz²í°ení FAKE GAME automatizovaného Data Mining Flow Zbývá tedy upravit stávající DMBatchProfile znázorn¥ný na obrázku 4.2. V n¥m jsem roz²í°il krok ImportFile tak, ºe pokud je p°i spu²t¥ní p°edána cesta k souboru s transformací a název kroku, z n¥hoº chceme £íst data, pouºije se místo implicitního na£ítání dat ze souboru m·j krok, který spustí PDI transformaci a p°edá na£tená data do FAKE GAME. Zjednodu²ený diagram konkrétní realizace je na obrázku 5.3. Denoval jsem novou operaci ImportPDI ekvivalentní ke stávající operaci ImportFile. Její kongurace, tedy zejména cesta k souboru s transformací a název kroku z n¥hoº £teme data p°ená²í instance t°ídy ImportPDIConfig. Ta je na po£átku b¥hu programu uloºena na Blackboard, odkud je moºné ji kdykoliv získat, jak je v rámci FAKE GAME zvykem. Abych dosáhl co moºná nejvy²²í znovupouºitelnosti kódu, navrhl jsem mechanismus na£ítání dat podle návrhového vzoru Template method [6] realizovaného t°ídou AbstractImport, která obstarává logiku na stran¥ FAKE GAME - zejména úpravy po na£tení dat (jako nap°.

42


Obrázek 5.3: Vyuºití návrhového vzoru Template method pro £tení dat z transformace

zji²t¥ní, o jaký data miningový problém se jedná apod.). Samotná logika na£tení dat je soust°ed¥na v rámci konkrétních potomk· abstraktní t°ídy AbstractBaseLoader. V tomto p°ípad¥ tedy LoadPDIPreprocessor zaji²úje kompletní logiku volání PDI API popsanou d°íve. 5.2

Testování FAKE GAME s vyuºitím PDI API

Pro otestování funk£nosti v²ech t°í projekt· jsem zvolil dva p°ístupy. Jak automatizované testování v podob¥ unit test·, tak i testování s reálnými daty. Jako data pro testování jsem vybral n¥kolik soubor·, které byly jiº d°íve vyuºívány bu¤ pro testování projektu FAKE GAME, nebo p°ímo k °e²ení reálných problém·. Krom¥ - v data miningové oblasti obligátního - souboru pro klasikaci kosatc· jsem testoval s údaji o prodejních cenách aut, EEG novorozenc· a spot°eb¥ vody mandarinkovníku. Podrobnosti o jednotlivých souborech dat jsou uvedeny v tabulce 5.1. Datové soubory jsem vybíral tak, aby pokrývaly jak regresní, tak klasika£ní problémy, je zde zastoupen p°ípad neúplného datového soubor (Cars) a datový soubor obsahující v¥t²í mnoºství záznam· pro výkonnostní testování (EEG).

5.2.1 Unit testy B¥hem testovací fáze jsem doplnil unit testy pro nov¥ doprogramované t°ídy v rámci projektu FAKE GAME. Poda°ilo se mi dosáhnout 92% pokrytí t¥chto nov¥ p°idaných t°íd (m¥°eno nástrojem EclEmma). Nepokryté £ásti kódu zahrnují p°edev²ím o²et°ení vnit°ních chyb PDI, které není dost dob°e moºné explicitn¥ vyvolat.

43

5.2. TESTOVÁNÍ FAKE GAME S VYUITÍM PDI API

Ozna£ení Instancí Vstupních atribut· Výstupních atribut· Typ problému Iris Cars Mandarin EEG

150 160 4139 42027

4 45 11 54

3 1 1 4

klasika£ní regresní regresní klasika£ní

Tabulka 5.1: Seznam testovaných soubor· dat

5.2.2 Na£ítání dat z více zdroj· P°i testování integrace dvou r·zných softwarových balík· je klí£ové vyty£it hranici, kdy je²t¥ testujeme nov¥ dodanou funk£nost a kdy uº testujeme p·vodní balíky, které by m¥ly být otestované samostatn¥. Vzhledem k tomu, ºe hlavní zodpov¥dnost mnou dodaného °e²ení je p°etransformovat data vy£tená pomocí PDI API a p°edat je do aplikace FAKE GAME k dal²ímu zpracování, leºí hlavní úskalí práv¥ v r·zných typech dat. V první fázi testování jsem tedy vytvo°il n¥kolik jednoduchých transformací, které v podstat¥ jen vy£tou data z datových soubor·. P°íklad takové opravdu jednoduché transformace je na obrázku 5.4. Následn¥ jsem opakovan¥ spou²t¥l FAKE GAME v reºimu DMBatchReport s r·znými vstupními parametry (zejména typy testování) a nastavoval postupn¥ tyto transformace jako zdroje dat. Sledoval jsem, zda produkované reporty odpovídají report·m vyprodukovaným p·vodním p°ístupem - tedy £tením dat p°ímo ze souboru. N¥které soubory nebylo moºné p·vodním p°ístupem zpracovat, protoºe vyºadovaly ur£ité p°edzpracování (které umoº¬uje práv¥ vyuºití PDI), ale nebylo sloºité vyhodnotit správnost mnou produkovaných report· i bez porovnání.

Obrázek 5.4: Ukázka vy£tení dat z csv souboru Testování prokázalo, ºe FAKE GAME s vyuºitím PDI API je schopný v²echny tyto soubory zpracovat. Transformace na obrázku 5.4 je sice velmi jednoduchá, na druhou stranu v p°ípad¥ na£ítání dat pouze z jednoho zdroje není £asto t°eba ºádných komplikovaných struktur. V druhé fázi testování jsem p°ikro£il k na£ítání dat z r·zných datových zdroj·. Vytvo°il jsem op¥t n¥kolik testovacích transformací, které by m¥ly co nejkomplexn¥ji pokrývat p°edpokládané vyuºití PDI. Cílem je zjistit, zda je FAKE GAME schopný tyto transformace vykonat, vy£íst z nich data a zpracovat je. Testované zdroje dat zahrnují p°edev²ím databázové tabulky, textové soubory, CSV soubory, excelovské tabulky a XML soubory. Data jsou následn¥ upravována a agregována s vyuºitím transforma£ních krok·. Tyto testovací transformace jsou k dispozici na p°iloºeném CD v adresá°i etc/tests/pdi_trans.

44


P°íklad takové transformace je uveden na obrázku 5.1. Zde dochází k na£ítání dat pro klasikaci kosatc·. Pro pot°eby tohoto experimentu jsem na£etl p°íslu²ná data do databáze a £ást uloºil do csv souboru. Dal²í £ást dat jsem rozd¥lil mezi excelovskou tabulku a textový soubor tak, ºe data v textovém souboru obsahují pouze seznam rozm¥r· kosatc· a excelovská tabulka obsahuje t°ídy odpovídajících záznam·. Záznamy v obou t¥chto souborech jsou ozna£eny identika£ními £ísly, aby bylo moºné je navzájem spárovat. Záznamy jsou tedy na po£átku se°azeny, následn¥ spojeny operací JOIN, po mapování názv· sloupc· tak, aby korespondovaly se záznamy z ostatních zdroj·, jsou data sjednocena. Pro testovací ú£ely p°idávám i na£ítání £ásti dat z XML souboru. Mapování do odpovídajícího výstupního formátu je dosaºeno s pomocí kroku umoº¬ujícího vykonání krátkého programu v JavaScriptu.

Obrázek 5.5: Transformace pro £tení dat ze dvou r·zných databází V transformaci uvedené na obrázku 5.5 jsou data na£tena ze dvou r·zných databází a následn¥ propojena. Propojení op¥t probíhá na základ¥ identika£ního £ísla p°i°azeného záznam·m v obou tabulkách. Pro zajímavost jsem doplnil do vstupních dat je²t¥ dva sloupce s náhodnými hodnotami, jednou se jedná o náhodn¥ vygenerované £íslo, v druhém p°ípad¥ je toto £íslo vºdy umocn¥no na druhou. Je pom¥rn¥ zajímavé sledovat, jak dopadl feature ranking, kdy se náhodné vstupní parametry umístily p°ekvapiv¥ vysoko. Výsledek vyst°iºený z výsledného reportu vyprodukovaného pomocí FAKE GAME uvádím na obrázku 5.6 (na obrázku jsou náhodn¥ generované vstupy znázorn¥ny ºlutou a alovou barvou). Tento výsledek m·ºe být zp·soben men²ím po£tem instancí a relativn¥ ²irokou ²kálou vstupních parametr·, kdy ºádná díl£í hodnota jednotlivých vstup· opravdu pravd¥podobn¥ neovliv¬uje kone£ný výsledek p°íli² výrazn¥.

5.2. TESTOVÁNÍ FAKE GAME S VYUITÍM PDI API

Obrázek 5.6: Transformace pro £tení dat ze dvou r·zných databází

45

46


Kapitola 6 Plugin pro PDI

Obrázek 6.1: Ukázka rozhraní FAKE GAME pluginu pro PDI

6.1

Realizace

Zatímco roz²í°ení funkcí FAKE GAME jsem implementoval p°ímo v rámci projektu, pro PDI plugin jsem vytvo°il samostatný projekt, který hostuji v rámci Google Project Hosting [3]. Zde je dostupný i Subversion repozitá°, odkud je moºné získat lokální kopii projektu. Plugin funguje velmi podobn¥ jako jiº zmín¥ný Weka Scoring plugin. Je schopný na£íst serializovaný objekt reprezentující model nebo klasikátor vyprodukovaný pomocí FAKE GAME. Klasikátory a modely jsou jiº kompletn¥ nastavené a nau£ené. Samotná £innost pluginu spo£ívá v tom, ºe nad p°ivedenými daty provede výpo£et odpovídající nahranému modelu a výsledkem je £íselné ohodnocení kaºdé instance reprezentující bu¤ odhadnutou hodnotu nebo (v p°ípad¥ klasikátoru) t°ídu, do které instance pat°í. U klasikátor· je moºné p°epnout na zobrazení pravd¥podobností p°íslu²nosti k jednotlivým t°ídám (output probabilities ). 47

48

KAPITOLA 6. PLUGIN PRO PDI

6.1.1 Nastavení vývojového prost°edí Samostatnou kapitolou p°i vývoji plugin· pro Pentaho nástroje je nastavení vývojového prost°edí. Není úpln¥ triviální, proto se zde o této problematice krátce zmíním. Pentaho pro tvorbu v podstat¥ v²ech projekt· vyuºívá vývojovou platformu Eclipse. V°ele doporu£uji ji v p°ípad¥ práce na nich vyuºívat rovn¥º. Z repozitá°e je pak £asto moºné stáhnout kompletní projekt i s nastavením (toto se týká zejména Pentaho BI platform). Pluginy pro PDI jsou na£ítány dynamicky p°i spu²t¥ní aplikace z adresá°e PDI_HOME/plugins/steps. P°i p°ímo£arém p°ístupu by tak vývoj pluginu znamenal neustále opakování t¥chto £inností: 1. Uloºení zm¥n. 2. Kompilace zdrojových kód· a vytvo°ení JAR archivu. 3. Nakopírování JAR archiv· a kongura£ního souboru plugin.xml do adresá°e s pluginy. 4. Spu²t¥ní PDI. A takto stále dokola p°i kaºdé zm¥n¥ kódu. Abychom mohli výsledný plugin rozumn¥ ladit je t°eba provést malý trik. Krom¥ projektu s pluginem vytvo°íme je²t¥ jeden projekt, kam stáhneme z repozitá°e lokální kopii PDI. V projektu, kde je umíst¥no PDI vytvo°íme v adresá°i plugins/steps sloºku pro ná² nový plugin a nakopírujeme sem p°íslu²ný soubor plugin.xml, kde jsou uvedeny cesty ke knihovnám, na nichº je ná² nový plugin závislý. M·ºeme sem nakopírovat i tyto knihovny, ale nekopírujeme archiv se samotným pluginem! V projektu s na²ím pluginem nastavíme závislost na projektu s PDI. Zbývá nastavit parametry spou²t¥ní v projektu s na²ím pluginem. Jednak je t°eba zm¥nit pracovní adresá° na ko°enový adresá° projektu s PDI a jako hlavní (Main) spustitelnou t°ídu nastavíme org.pentaho.di.ui.spoon.Spoon. Díky této úprav¥ m·ºeme spou²t¥t PDI v rámci prost°edí Eclipse i s pln¥ nakongurovaným vlastním pluginem.

6.1.2 Specický class loader P°edchozí postup nám umoºní pohodln¥ vyuºívat v²ech ladících moºností vývojového prost°edí. Jeden typ chyb takto ale neodhalíme. Pokud b¥ºí PDI samostatn¥ vyuºívá pro pluginy zvlá²tní class loader. P°i aplikaci vý²e uvedeného postupu nám na£tení v²ech pot°ebných t°íd zajistí vývojové prost°edí. V p°ípad¥ FAKE GAME se tak projevily problémy aº p°i ostrém nasazení. N¥které t°ídy FAKE GAME vyuºívají pro dynamické nahrávání t°íd (nap°. na základ¥ informací zapsaných v kongura£ních souborech) systémový class loader, tedy volání:

Class c = ClassLoader.getSystemClassLoader().loadClass(className); Závislosti pluginu tak nebyly dostupné (musí se k nim p°istupovat p°es class loader vyhrazený pro pluginy). Tato informace byla ve zdrojových kódech napevno zapsaná a nebylo moºné class loader zm¥nit nap°. voláním p°íslu²ného setteru, jak je tomu zvykem v p°ípad¥ n¥kterých jiných

6.1. REALIZACE

49

projekt·. Musel jsem tedy p°istoupit k p°epsání takto implementovaných t°íd. Abych zachoval jejich p·vodní funkcionalitu zvolil jsem °e²ení, kdy pro dynamické na£ítání t°íd pouºívám class loader, jenº nahrál volající t°ídu. Tedy:

Class c = getClass().getClassLoader().loadClass(className); Takto je zachována v podstat¥ p·vodní funkcionalita, kdy se za b¥ºných okolností pouºívá implicitn¥ systémový class loader a zárove¬ je FAKE GAME schopný fungovat i jako plugin. V takovém p°ípad¥ vyuºívá class loader, který jej na£etl.

6.1.3 Struktura FAKE GAME pluginu pro PDI Struktura pluginu odpovídá p°edepsané struktu°e popsané v kapitole 4.4.2. Jednotlivé názvy základních t°íd respektují p°edepsané jmenné konvence:

• FakeGamePlugin Obsahuje samotnou výkonnou £ást programu, tedy volání logiky týkající se vyhodnocení jednotlivých instancí za pouºití p°íslu²ného modelu. • FakeGamePluginData V tomto p°ípad¥ není t°eba ukládat n¥jaké mezivýsledky, takºe neobsahuje ºádnou zvlá²tní logiku, pouze metody, které implementuje v podstat¥ kaºdý plugin pro PDI. • FakeGamePluginMeta Stará se o práci s kompletní kongurací pluginu, o její ukládání a na£ítání, volá logiku deserializace model· a klasikátor·. • FakeGamePluginDialog Zobrazuje a obsluhuje uºivatelské rozhraní v podob¥ kongura£ního dialogu. V této souvislosti bych ale rád zmínil je²t¥ jeden aspekt návrhu architektury pluginu. FAKE GAME rozli²uje dva typy model·:

• ConnectableModel pro regresní problémy a • ConnectableClassifier pro klasika£ní problémy. Od t¥chto t°íd d¥dí v²echny klasikátory a modely. Samotné tyto dv¥ t°ídy v²ak nemají spole£ného p°edka ani spole£né rozhraní a není k nim tedy moºné p°istupovat jednotn¥. Vzhledem k tomu, ºe by bylo pon¥kud ne²ikovné a nep°ehledné p°i jakékoliv práci s nimi neustále rozli²ovat, o který typ se jedná, doplnil jsem jisté zjednodu²ení s vyuºitím návrhového vzoru Facade [6]. PDI plugin totiº od obou typ· vyºaduje v podstat¥ stejné operace:

• Na£íst objekt na základ¥ jeho serializované podoby. • Vyhodnotit instanci reprezentovanou p°edanou °ádkou dat a vrátit výsledek v podob¥ jednoho nebo více sloupc· p°idaných do této °ádky. • Dal²í drobné operace, jako vrácení po£tu a názv· vstup· apod.

50


Výsledek je znázorn¥n na zjednodu²eném diagramu na obrázku 6.2. Je z n¥j patrné, ºe plugin, reprezentovaný zde t°ídou FakeGamePluginMeta je kompletn¥ odstín¥n od vnit°ní logiky FAKE GAME prost°ednictvím t°ídy ModelsFacade a nadále komunikuje pouze s ní. ModelsFacade pak deleguje úkoly na p°íslu²né t°ídy FAKE GAME (v diagramu ozna£ené mod°e). Nejenºe ModelsFacade skrývá rozdíly mezi klasikátory a modely, ale zárove¬ p·sobí jako obálka na jejich libovolný po£et. V souboru m·ºe být uloºeno i více serializovaných model·. V takovém p°ípad¥ zobrazí plugin výsledek vyhodnocení kaºdého z nich. I tuto logiku zapouzd°uje ModelsFacade.

Obrázek 6.2: Aplikace návrhového vzoru Facade za ú£elem odstín¥ní logiky FAKE GAME od zbytku PDI pluginu.

6.2

Testování pluginu pro PDI

6.2.1 Unit testy Vytvá°ení unit test· pro PDI plugin bylo o n¥co sloºit¥j²í, neº v p°ípad¥ testování vyuºití PDI API. P°ed vyvoláním konkrétních test· bylo £asto t°eba simulovat z velké £ásti nakongurované prost°edí PDI. To si samoz°ejm¥ vyºádalo rozsáhlej²í práci s vnit°ní strukturou PDI, od které je jinak vývojá° b¥hem vytvá°ení plugin· do zna£né míry odstín¥n. I z t¥chto d·vod· se poda°ilo dosáhnout pouze 75% pokrytí kódu pluginu, kdy zbytek se ukázalo jako efektivn¥j²í otestovat jinou cestou. Do automatizovaných test· v této £ásti nezahrnuji t°ídy starající se výhradn¥ o zobrazení grackého uºivatelského rozhraní, jejichº automatické testování je zpravidla komplikované a b¥ºen¥ bývá efektivn¥j²í testovat je jinými zp·soby.

6.2.2 Vytvo°ení testovacích transformací V p°ípad¥ testování pluginu pro PDI není t°eba experimentovat s r·znými typy transformací, protoºe data do pluginu p°ichází ve stále stejné podob¥ dané vnit°ním rozhraním PDI nezávisle na tom, odkud byla na£tena. Co m·ºe p·sobit problémy jsou r·zná data. Op¥t jsem tedy vyuºil soubory dat vyuºívané jiº d°íve pro FAKE GAME, popsané v kapitole 5.2. Sestavil jsem n¥kolik transformací, které jsou schopné vy£íst data z datových soubor·, vyhodnotit je pomocí mého pluginu a uloºit výsledky do souboru. Pomocí uºivatelského rozhraní FAKE GAME jsem vygeneroval n¥kolik model· a uloºil je v serializované podob¥.

6.2. TESTOVÁNÍ PLUGINU PRO PDI

51

Tyto modely jsem následn¥ nahrál prost°ednictvím pluginu, spou²t¥l sestavené transformace a sledoval, zda výsledky odpovídají výsledk·m získaným s pomocí FAKE GAME. Je t°eba podotknout, ºe v sou£asné dob¥ je FAKE GAME schopný vhodným zp·sobem exportovat pouze jednoduché modely jako polynomiální, lineární, exponenciální apod. Do budoucna je v²ak po£ítáno s moºností exportovat kompletní ²kálu pouºitelných model·, kterými program disponuje, do formátu zpracovávaného pluginem pro PDI. Krom¥ testování s daty jsem ov¥°oval manuáln¥ i funk£nost pluginu, kterou nebylo moºné dob°e pokrýt unit testy. Tedy zejména funkce uºivatelského rozhraní a správné ukládání a na£ítání nastavení pluginu jak do soubor· s denicemi transformací, tak do repozitá°· PDI. Testované transformace jsou op¥t uloºené v adresá°i etc/tests/pdi_plug na p°iloºeném CD. Krom¥ testovacích ú£el· mohou slouºit i jako výborný zdroj p°íklad· pouºití pluginu, protoºe pokrývají v podstat¥ v²echna jeho moºná nasazení.

6.2.3 Porovnání s výsledky pluginu Weka scoring Ve nále jako jakýsi "Proof of concept"jsem sestavil rovn¥º p°íklad jiº avizovaného nasazení ve spolupráci s pluginem Weka Scoring. Ve Wecce jsem vytvo°il neuronovou sí´ typu Multilayer Perceptron a nau£il ji klasikovat na vzorovém souboru dat o kosatcích z UCI databáze [23]. S pomocí FAKE GAME jsem vytvo°il klasikátor sloºený z polynomiálních model·, dále klasikátor na bázi sít¥ GAME a kone£n¥ t°i polynomiální modely, které na výstupu modelují vºdy jednu z klasikovaných t°íd. Jako trénovací mnoºinu pro nau£ení model· jsem ve v²ech p°ípadech pouºil polovinu záznam· z datového souboru. Záznamy jsem vybral náhodn¥ tak, aby byly zastoupeny v²echny t°ídy rovnom¥rn¥. V prost°edí PDI jsem vytvo°il p°íslu²nou transformaci s vyuºitím plugin· Weka Scoring a FAKE GAME (viz. obrázek 6.3). Transformace na£te testovací data a p°id¥lí jim identika£ní £ísla, aby bylo moºné jednotlivé instance klasikované r·znými klasikátory lépe slu£ovat. Data jsou rozdistribuována p°íslu²ným plugin·m. FAKE GAME plugin je schopný v rámci jednoho kroku klasikovat pomocí více klasikátor·, pro názornost jsem v²ak pro kaºdý klasikátor vytvo°il krok vlastní. Kaºdý plugin tedy p°id¥lí na základ¥ vstupních dat kaºdé instanci odhadnutou výstupní t°ídu. Výsledky jsou slou£eny, sjednoceny a uloºeny do souboru. Vytvo°ení této transformace bylo pon¥kud svízelné. Jak jsem se jiº zmi¬oval v pr·b¥hu mé práce do²lo k vydání nové verze PDI, která pom¥rn¥ zásadním zp·sobem m¥ní rozhraní plugin·. Díky t¥mto zm¥nám nefungují v poslední verzi PDI v podstat¥ ºádné dosavadní pluginy a tedy ani Weka Scoring plugin. Abych mohl transformaci ve £tvrté verzi PDI spou²t¥t, musel jsem mírn¥ p°epracovat i Weka Scoring plugin, coº bylo na²t¥stí moºné vzhledem k dostupnosti jeho zdrojových kód·. Jedná se v²ak pouze o provizorní úpravy pro pot°eby této práce. Kompletní upgrade pluginu nechávám rad¥ji jeho autorovi. V kaºdém bod¥ transformace je moºné zobrazit výsledky dosavadních krok·. Úsp¥²nost klasikace tak m·ºeme sledovat p°ímo v prost°edí PDI, nebo jej uloºit do libovolného výstupního formátu pro p°ípadné dal²í zpracování. Na obrázku 6.4 je ukázka zobrazení výsledk· v prost°edí PDI. V prvním sloupci vidíme referen£ní hodnoty klasikovaných t°íd. Následují výsledky klasikace pomocí wekovské neuronové sít¥ a dále výsledky klasikátor· FAKE GAME (polynomiální a GAME). Poslední t°i sloupce ukazují výsledky model· modelujících vºdy jednu z výstupních t°íd.

52


Obrázek 6.3: Transformace porovnávající výsledky klasikátor· vytvo°ených ve Wecce a výsledky klasikátor· vytvo°ených prost°ednictvím FAKE GAME

Klasikátor

Multilayer Perceptron Polynomiální klasikátor Sí´ GAME

Pouºitý software Po£et chyb Po£et chyb v % Weka FAKE GAME FAKE GAME

2 2 3

2.7 % 2.7 % 4.0 %

Tabulka 6.1: Výsledky porovnání klasikátor· vytvo°ených pomocí Weky a FAKE GAME Výsledky porovnání klasikátor· uvádím v tabulce 6.1. Zde je uveden pro kaºdý pouºitý klasikátor po£et chybn¥ klasikovaných instancí. Vidíme, ºe nejh·°e dopadla v tomto p°ípad¥ sí´ GAME, stejnou úsp¥²nost pak m¥la vícevrstvá neuronová sí´ a klasikátor sloºený z polynomiálních model·. Inkriminovaná transformace je uloºena v adresá°i etc/tests/pdi_plug/iris na p°iloºeném CD. V dal²ím experimentu jsem provedl podobnou proceduru, tentokráte pro regresní problém - ur£ování spot°eby vody mandarinkovníku. Op¥t jsem datový soubor rozd¥lil náhodn¥ na dv¥ £ásti - 2998 instancí jsem pouºil jako trénovací data, 1141 instancí potom jako data testovací. Sestavil jsem o n¥co komplexn¥j²í transformaci (na obrázku 6.5), která op¥t na£te trénovací data, rozdistribuuje je, následn¥ sjednotí výsledky a v tomto p°ípad¥ rovnou i spo£ítá celkovou chybu jednotlivých model· metrikou RMS (Root Mean Square). Jako modely vytvo°ené pomocí FAKE GAME jsem pouºil lineární regresní model a polynomiální model. V rámci Weky jsem vytvo°il lineární regresní model. Výsledek práce transformace je zobrazen na obrázku 6.6. Vidíme tedy, ºe výsledky lineárních model· vytvo°ených pomocí Weky a FAKE GAME se p°íli² neli²í. Nejlep²ích výsledk· v²ak v tomto p°ípad¥ do-

6.2. TESTOVÁNÍ PLUGINU PRO PDI

Obrázek 6.4: Zobrazení dosavadních výsledk· transformace v PDI

sáhl model polynomiální vytvo°ený pomocí FAKE GAME.

53

54


Obrázek 6.5: Transformace pro porovnání výsledk· model· vytvo°ených pomocí FAKE GAME a Weky

Obrázek 6.6: Výsledek transformace pro porovnání výsledk· model· vytvo°ených pomocí FAKE GAME a Weky

Kapitola 7 Plugin pro Pentaho BI platform

Obrázek 7.1: Ukázka zobrazeného FAKE GAME reportu v rámci Pentaho BI platform

7.1

Realizace

Podobn¥ jako v p°ípad¥ PDI pluginu jsem vytvo°il samostatný projekt hostovaný v rámci Google Project Hosting [4]. Zde je op¥t moºné získat lokální kopii zdrojových kód· ze Subversion.

7.1.1 Struktura projektu Pro vytvo°ení samotného projektu je velmi výhodné vyuºít p°edp°ipravený groovy skript, který je moºné stáhnout ze stránek projektu Suboor [22]. Jeho pouºití je velmi jednoduché: 55

56

KAPITOLA 7. PLUGIN PRO PENTAHO BI PLATFORM

Adresá°

src/ test-src/ dist/ lib/ package-res/ solutions/

Obsah adresá°e

Zdrojové kódy. Unit testy. Adresá° s distribucí pluginu JAR archivy, na kterých plugin závisí - v tomto p°ípad¥ game-core.jar a v²echny jeho závislosti. Dal²í soubory, které plugin pot°ebuje ke své £innosti. V tomto p°ípad¥ nap°. kaskádové styly denující vzhled reportu. Adresá° obsahuje vzorová °e²ení vyuºívající plugin. P°i volání ant install jsou tato °e²ení nakopírována do repozitá°e BI serveru.

Tabulka 7.1: Adresá°ová struktura projektu tvo°ícího Pentaho BI plugin

groovy ~/bin/projcreator.groovy mujprojekt -o acme -p -d /cesta/k/bi-serveru Tento skript vytvo°í kompletní adresá°ovou strukturu pro vývoj Pentaho BI pluginu a nastaví p°íslu²né Ant skripty. P°íkazem ant pak projekt zkompilujeme a p°ipravíme k distribuci. P°íkazem ant install jej nasadíme na server. Seznam základních adresá°· projektu a jejich obsahu je uveden v tabulce 7.1.

7.1.2 Nastavení vývojového prost°edí Jak jsem jiº uvedl, pro vývoj Pentaho je velmi výhodné vyuºívat Eclipse. V p°ípad¥ Pentaho BI platform je to tém¥° nutnost. Abychom mohli pluginy pro platformu ladit, musíme si opat°it její zdrojové kódy. Za tímto ú£elem je nutné p°ipravit si následující nástroje: Java Development Kit, aplika£ní server Tomcat, sestavovací nástroj Ant a vývojové prost°edí Eclipse s pluginy XML Task, Subclipse a IvyIDE. Pokud je máme úsp¥²n¥ nainstalované, m·ºeme se pustit do stahování zdrojových kód· platformy. Jedná se o 22 projekt· z Pentaho repozitá°e, jejichº seznam je uvedený v dokumentaci [21]. Z repozitá°e by se nám m¥ly stáhnout kompletní projekty pro Eclipse i s nastavením závislostí mezi sebou navzájem. Závislosti na knihovnách t°etích stran °e²í Ivy, lépe °e£eno v rámci Eclipse plugin IvyIDE. P°i zapnuté volb¥ Build Automatically je tento proces automatický. V mém p°ípad¥ ale do²lo k problém·m s n¥kterými závislostmi, které bu¤ nebyly v repozitá°ích uloºeny v·bec, nebo nebyly zrovna dostupné. Tento problém je asi nejjednodu²²í °e²it dohledáním p°íslu²ných knihoven na internetu a uloºením v lokální cache p°ípadn¥ v lokálním repozitá°i Ivy. Te¤ musíme p°ipravit Tomcat s nainstalovanou Pentaho BI platform. V projektu bi-platform-build nastavíme v souboru dev_override.properties cestu k lokální instalaci Tomcatu a spustíme p°íslu²ný Ant skript p°íkazem:

ant -f dev_build.xml dev-rebuild Skript zkompiluje v²echny staºené projekty, v rámci workspace vytvo°í kopii aplika£ního serveru a provede instalaci celé aplikace. V rámci r·zných opera£ních systém· je adresá°ová

7.1. REALIZACE

57

struktura nainstalovaného Tomcatu r·zná. P°ed spu²t¥ním zmín¥ného skriptu je nutné dbát na to, aby v nastaveném domovském adresá°i Tomcatu byly p°ítomny tyto sloºky: server/, common/, logs/ a lib/. V mém p°ípad¥ (instalace pod linuxovou distribucí Ubuntu) bylo t°eba vytvo°it symbolický link do adresá°e server/lib/. V Eclipse je potom t°eba nakongurovat takto vytvo°ený aplika£ní server tak, aby bral v úvahu v²echny staºené zdrojové kódy. Postup je popsaný v dokumentaci [12]. P°ed spu²t¥ním serveru je t°eba dbát na to, aby ºádná jiná aplikace nevyuºívala port 8080 a aby byla spu²t¥na databáze a nakongurována pro Pentaho. Nejjednodu²²í zp·sob, jak toho docílit je spustit databázi Hypersonic, která je p°ibalena do distribuce vytvo°ené pomocí zmín¥ného Ant skriptu. V mém p°ípad¥ se v této fázi i p°esto objevily problémy s p°ipojením k databázi, protoºe b¥hem procesu nasazování aplikace na server skript nenahraje p°íslu²ný JDBC ovlada£. Situaci je moºné °e²it p°idáním ovlada£e na Class Path serveru p°ímo v prost°edí Eclipse. V této fázi je po spu²t¥ní serveru pomocí Eclipse konzole dostupná Pentaho BI platform na adrese http://localhost:8080/pentaho. Pokud p°idáme projekt s na²ím pluginem mezi zdrojové kódy v nastavení aplika£ního serveru a nahrajeme jej na server, m·ºeme jej pohodln¥ ladit v prost°edí Eclipse.

7.1.3 FAKE GAME plugin pro PDI K vytvo°ení pluginu pro BI platform jsem zvolil p°ístup prost°ednictvím Akcí - tedy odleh£ené verze Komponent - popsaný v kapitole 4.5.3. Samotná realizace na stran¥ Pentaho je pom¥rn¥ p°ímo£ará a spo£ívá v implementaci p°íslu²ného rozhraní - v mém p°ípad¥ IStreamingAction, které nazna£uje, ºe se jedná o akci schopnou vrátit n¥jaká rozsáhlej²í data v podob¥ streamu. V mém p°ípad¥ Akce vrací kompletní HTML report. Ten je pak moºné zobrazit uºivateli. Akce vlastn¥ vrací dva streamy. Jeden p°edstavuje kompletní report ve formátu HTML (zobrazitelný uºivateli) a druhý stream obsahuje tento report zabalený v ZIP archivu tak, aby jej bylo moºné p°edat dal²ím komponentám (nap°. komponent¥ schopné rozesílat e-maily). Hlub²ím prozkoumáním ostatních komponent jsem zjistil, ºe v podstat¥ v²echny sou£ásti Pentaho schopné £íst a p°edávat dál strukturovaná data je p°edávají ve form¥ typu result-set (viz tabulka 4.2). Akce produkující FAKE GAME report tedy na vstupu p°ijímá tento datový typ a dále jej p°evádí na formát vhodný pro FAKE GAME. Dal²í vstupy jsou kongura£ní. Chování Akce je moºné ovlivnit její kongurací v rámci .action souboru následujícím zp·sobem:

FakeGameAction FAKE GAME Action

58


<experimentSeries> Test FAKE GAME Action DEBUG Nep°ekvapí nás, ºe na vstup komponenty tedy p°ivedeme data. Její chování m·ºeme ovlivnit volbami experimentSeries a trainTestStrategy. Ty odpovídají nastavení, kterým lze chování FAKE GAME ovlivnit p°i spou²t¥ní z p°íkazové °ádky a indikují, zda se mají experimenty opakovat (volby "true"nebo "false") a ur£ují testovací strategii (volby: "crossvalidation", nebo "train-test", nebo "whole-set"). Tyto volby mohou být zadané napevno p°i volání komponenty, nebo mohou být p°ivedeny na vstup z jiných zdroj· (nap°. parametry p°edané v url). Akce vyºaduje na vstupu rovn¥º ZIP archiv s kongurací samotných model·, které se mají v rámci reportu vyhodnotit. FAKE GAME pouºívá za tímto ú£elem adresá°, v n¥mº jsou uloºeny soubory s kongurací konkrétních model·. To se p°íli² neslu£uje s lozoí ostatních komponent Pentaho, které obvykle p°ijímají takováto nastavení v podob¥ streamu jako kongura£ní soubory. Tomu odpovídá i celý framework pro provád¥ní Sekvencí akcí a p°edávání vstup· Akcím. Abych tuto disproporci odstranil, p°istoupil jsem práv¥ k na£ítání zabaleného kongura£ního adresá°e. Akce potom archiv vnit°n¥ zpracuje a do FAKE GAME p°edává uº cestu k rozbalenému adresá°i, jak je pro n¥j typické. Nastavení komponenty je samoz°ejm¥ moºné provád¥t i pohodln¥ji v generickém prost°edí Design Studia (kapitola 4.1.5.2).

7.1.4 Roz²í°ení FAKE GAME automatizovaného Data Mining Flow Pro p°ípad na£ítání dat v rámci BI platform a generování report· zobrazitelných v jejím prost°edí bylo t°eba FAKE GAME poupravit o n¥co více neº v p°ípad¥ práce s PDI API. Za tímto ú£elem jsem v rámci pluginu vytvo°il nový prol DMPentahoBIProfile vycházející ze stávajícího DMBatchProfile. Li²í se ve zp·sobu importu dat, kdy místo t°ídy ImportFile potaºmo ImportPDI nasazuje novou t°ídu ImportPentahoBI, která je schopna p°eloºit data ve formátu IPentahoResultSet. S výhodou je vyuºito jiº existujícího nasazení návrhového vzoru Template method popsaného v kapitole 5.1.3 tak, ºe ImportPentahoBI pouze dopl¬uje zpracování nového formátu dat v podob¥ t°ídy LoadResultSetPreprocessor, zbytek úprav v rámci FAKE GAME obstarává jiº hotová t°ída AbstractImport. Situace je znázorn¥na na obrázku 7.2. Jedná se o dopln¥ní jiº hotové struktury z obrázku 5.3. T°ídy p°idané v rámci pluginu pro BI platform jsou vyzna£eny oranºov¥. Krom¥ jiných vstup· bylo pot°eba upravit i výstup prolu, tedy generovaný report. Formát HTML sice vyhovuje pot°ebám BI platform velmi dob°e, ov²em problém je v generování cest k obrázk·m. K t¥m se v rámci platformy p°istupuje p°es k tomu ur£ený servlet

7.2. TESTOVÁNÍ PLUGINU PRO PENTAHO BI PLATFORM

59

Obrázek 7.2: Dopln¥ní dal²ího zp·sobu na£ítání dat do jiº hotové architektury FAKE GAME

getImage (viz. tabulka 4.1). Musel jsem tedy doplnit nový "vykreslova£"report·, coº díky exibilnímu systému jejich generování v rámci FAKE GAME (popsanému v kapitole 4.2.1) nep°edstavovalo velký problém. Realizace je znázorn¥na na obrázku 7.3. Oranºovou barvou jsou vyzna£eny nov¥ dodané t°ídy, které si vyºádal plugin pro Pentaho BI platform. Jak je vid¥t, z valné £ásti bylo moºné vyuºít jiº existující t°ídy.

7.2

Testování pluginu pro Pentaho BI platform

7.2.1 Unit testy P°i automatickém testování pluginu pro BI platform jsem zvolil pon¥kud odli²ný p°ístup neº v p°edchozích dvou p°ípadech. Zde je totiº moºné s výhodou vyuºít za tímto ú£elem p°edprogramované mikroplatformy, jejímº prost°ednictvím je moºné v rámci unit test· jednotlivé pluginy spou²t¥t. Vytvo°il jsem n¥kolik jednoduchých sekvencí akcí skládajících se z p°edání testovacích vstup· a volání mnou naprogramovaného pluginu. Mikroplatforma sekvenci vykoná a vrátí její výstup. Ten je pak moºné vyhodnotit. V tomto p°ípad¥ se tedy jedná z v¥t²í £ásti o regresní testování. Bez tohoto p°ístupu by bylo automatické testování velmi komplikované z podobných d·vod· jako testování pluginu pro PDI - tedy nutnost dostat p°ed v¥t²inou test· prost°edí BI platform do konzistentního stavu. Testovací sekvence jsem navrhl tak, aby obsahovaly data jak k °e²ení klasika£ních problém·, tak k °e²ení regresních s vyuºitím r·zných metod vyhodnocování výsledných model·, dosáhl jsem tak 86% pokrytí. Automatizované testy jsou dostupné v adresá°i projektu (src/FGPentahoBIPLugin) na p°iloºeném CD.

60


Obrázek 7.3: Zm¥na zp·sobu generování obrázk· p°i vykreslení FAKE GAME reportu

7.2.2 Vytvo°ení testovacích sekvencí Krom¥ automatizovaných test· jsem op¥t sestavil i n¥kolik scéná°· pro ru£ní testování v podob¥ sekvencí akcí. První p°i²lo na °adu testování s r·znými daty. S výhodou jsem vyuºil jiº vytvo°ených PDI transformací popsaných v kapitole 5.2.2. Ty jsem za£lenil do sekvencí akcí s pomocí komponenty Pentaho Data Integration a takto na£tená data (jejich p°ehled je uveden v tabulce 5.1) p°edal mé komponent¥ Fake Game Action. Na obrázku 7.4 je ukázka integrace pluginu v sekvenci akcí v prost°edí Design Studia, v tomto p°ípad¥ se jedná o na£tení dat o prodejních cenách aut prost°ednictvím PDI. Vzhledem k tomu, ºe komponenta poskytuje na výstupu report ve formátu HTML nebo zazipovaný, je moºné jej zobrazit p°ímo uºivateli, nebo nechat odeslat e-mailem. Cílem tedy bylo ov¥°it odolnost komponenty proti r·zným typ·m vstupních dat a schopnost zpracovat i jejich v¥t²í mnoºství. Komponenta je schopná zpracovat v²echny testované zdroje dat, zpracování se m·ºe u v¥t²ích datových soubor· protáhnout, zejména kv·li vnit°ním výpo£t·m FAKE GAME. Doba provád¥ní je závislá krom¥ mnoºství dat i na po£tu testovaných model· a na testovací strategii, kdy nejdéle zpravidla trvá výpo£et se strategií cross validation implicitn¥ nastavenou na 10 opakování. Krom¥ testování s r·znými daty jsem v n¥kterých sekvencích akcí testoval i s r·znými konguracemi. Pentaho BI platform umoº¬uje vyºádat si od uºivatele zadání pot°ebných vstup·, jak je vid¥t na obrázku 7.5. Sestavil jsem t°i typy kongurací. V rámci reportu je tedy moºné zobrazit:

• Vizualizaci dat • Feature ranking • Výsledky testování jednotlivých model· - v tomto p°ípad¥ je dále moºné zvolit typ testování


61

Obrázek 7.4: Za£len¥ní pluginu do sekvence akcí v prost°edí Design Studio

Obrázek 7.5: Výb¥r typu reportu

Pro ilustraci uvádím na obrázku 7.6 výsek vyprodukovaného FAKE GAME reportu zobrazující vizualizaci dat v podob¥ histogram· pro jednotlivé vstupy v rámci °e²ení problému spot°eby vody mandarinkovníku. V dal²í fázi jsem testoval správnou integraci v platform¥ tak, ºe jsem zkombinoval mou komponentu s ostatními v rámci sekvencí akcí a sledoval, zda jsou schopné mezi sebou komunikovat. D·raz jsem kladl krom¥ zpracování PDI transformací na na£ítání dat z databáze (na obrázku 7.7) a propojení s komponentou odesílající e-maily. Dal²í ukázky nasazení FAKE GAME pluginu pro Pentaho BI platform sesbírané b¥hem testování uvádím v obrazové p°íloze E. V²echny zmín¥né sekvence akcí jsou dostupné na p°iloºeném CD (v rámci Pentaho BI serveru je to sloºka pentaho-solutions/bi-developers/FakeGame). V¥t²inu by m¥lo být moºné spou²t¥t nezávisle na umíst¥ní, n¥které v²ak z pochopitelných d·vod· vyºadují p°izp·sobení podmínkám na lokálním stroji (nap°. nastavení p°ipojení k databázi, SQL skripty pro vytvo°ení p°íslu²ných tabulek jsou v takovém p°ípad¥ rovn¥º uloºeny na p°iloºeném CD).

62


Obrázek 7.6: Vizualizace datového souboru - ukázka histogram· z FAKE GAME reportu v rámci Pentaho BI platform


63

Obrázek 7.7: Propojení FAKE GAME s komponentou starající se o £tení dat z rela£ní databáze.

64


Kapitola 8 Záv¥r 8.1

Zhodnocení dosaºených cíl·

V rámci této práce jsem navrhl a implementoval t°i °e²ení integrace dvou open-source nástroj·. Zejména FAKE GAME takto získal ²irokou ²kálu dal²ích moºností práce s daty a v rámci platformy i n¥kolik dal²ích kanál· distribuce výsledných report·. Uve¤me si základní p°ehled nových funkcí podle implementovaných °e²ení.

FAKE GAME s vyuºitím PDI API m·ºe nov¥:

• Na£ítat data z p·sobivého mnoºství zdroj· zahrnujícího valnou v¥t²inu pouºívaných rela£ních databází, XML soubory, textové (nejenom CSV) soubory, excelovské tabulky, webové sluºby, OLAP databáze a mnoho dal²ích v£etn¥ napojení na proprietární software jako nap°. SAP. • Datové zdroje libovoln¥ kombinovat, zejména slu£ovat a provád¥t r·zné druhy JOIN operací a to i mezi r·znými typy zdroj·. Není tedy problém nap°. na£ítat £ást dat ze soubor· a £ást z databází. • Roz²í°it své schopnosti p°edzpracování dat. V rámci transformací je moºné data redukovat, £istit, provád¥t konverze a mapovat výstupní hodnoty. S pomocí JavaScriptu m·ºe uºivatel velmi exibiln¥ dopl¬ovat vlastní funkce p°ed tím, neº jsou data p°edána ke zpracování pomocí samotného FAKE GAME.

FAKE GAME plugin pro PDI: • Roz²i°uje ²kálu wekovských model·, které je moºné v rámci PDI vyuºít, o modely specické pro FAKE GAME. • Vzhledem k tomu, ºe je s jeho pomocí moºné velmi snadno porovnávat výsledky model· vyprodukovaných pomocí FAKE GAME a výsledky model· z Weky, m·ºe slouºit k efektivnímu výb¥ru nejlep²ího °e²ení.

FAKE GAME plugin pro Pentaho BI platform zprost°edkovává b¥h FAKE GAME v rámci platformy, £ímº mu dává moºnosti v²ech jejích klasických komponent, tedy: 65

66

KAPITOLA 8. ZÁVR

• Moºnost °adit FAKE GAME do sekvencí akcí a tak vyuºívat schopností ostatních komponent jako jsou r·zné zdroje dat (v£etn¥ PDI transformací), moºnost odesílat výsledné reporty e-mailem, nebo je tisknout, sestavovat jednoduché work ows zahrnující generování report·. • Moºnost plánovat automatická spou²t¥ní produkce report·. • Moºnost denovat jednoduché uºivatelské rozhraní pro zadání základních kongura£ních parametr·. • Kompletní správu p°ístupových práv k jednotlivým report·m, ²iroké moºnosti sdílení report· v rámci platformy. Krom¥ napln¥ní zmín¥ných cíl· otevírá integrace FAKE GAME v rámci populární Pentaho BI platformy dal²í moºnosti propagace tohoto nástroje mezi komunitou uºivatel· opensource BI. V samotné práci jsem se pokou²el vypíchnout aspekty vývoje pro Pentaho, které nejsou p°íli² dob°e (nebo v·bec) popsány v dokumentaci projektu. M¥la by tak poslouºit mimo jiné i jako základ pro práci dal²ích vývojá°·, kte°í by m¥li o n¥který nástroj z této rodiny zájem. Po stru£ném úvodu do problematiky BI práce obsahuje ucelený p°ehled nástroj· z rodiny Pentaho, které jsou v¥t²inou v projektové dokumentaci popisovány samostatn¥ bez nazna£ení ²ir²ích souvislostí. 8.2

Problémy integrace open-source nástroj·

Integrování open-source °e²ení skýtá r·zná úskalí z nichº nejpal£iv¥j²ím je ur£itá ºivelnost jejich vývoje. B¥hem práce jsem n¥kolikrát musel £elit problém·m zp·sobeným zm¥nou vnit°ní struktury projekt·, kdy nov¥ implementované funkce nejsou zp¥tn¥ kompatibilní s p·vodn¥ vyuºívanými. Nejproblemati£t¥j²í byla práce s PDI, které b¥hem psaní této práce prod¥lalo p°erod od verze 3 k verzi 4, tedy zm¥na majoritní verze. Ta s sebou nesla zm¥ny základní lozoe projektu, které se projevily ve v²ech oblastech integrace - v mém p°ípad¥ i b¥hem tvorby pluginu i p°i vyuºití PDI API. Na základ¥ takto nabytých zku²eností bych doporu£oval, pokud je to jen trochu moºné, zakotvit na vybrané stabilní verzi a té se drºet. asto to ale moºné není, u open-source projekt· p°iná²ejí mnohdy nové verze opravu kritických chyb a je velmi ºádoucí drºet krok s jejich vývojem. V takovém p°ípad¥ se mi b¥hem práce osv¥d£ilo maximáln¥ odd¥lit dv¥ integrovaná °e²ení s vyuºitím nap°. návrhového vzoru Facade. Jde v podstat¥ o jistou formu loose coupling, kdy nap°. plugin nedovoluje integrovaným projekt·m komunikovat p°ímo. Pokud se poda°í provést takovýto £istý °ez a zapouzd°it p°íslu²nou funkcionalitu, je zohledn¥ní p°ípadných zm¥n v jednom projektu snaz²í a minimalizujeme riziko zanesení chyb i do druhého integrovaného °e²ení. 8.3

Dal²í práce

Zejména v p°ípad¥ plugin· a´ uº pro PDI nebo Pentaho BI platform je jist¥ prostor pro dopln¥ní dal²ích funkcí. Pokud FAKE GAME bude v budoucnosti podporovat moºnost tvorby

8.3. DALÍ PRÁCE

67

knowledge ows tak, jak je známe nap°. z Weky, otevírá se moºnost vytvo°ení dal²ího pluginu pro PDI, který by tyto knowledge ows dokázal zpracovat v prost°edí PDI, podobn¥ jako je tomu u pluginu Weka KnowledgeFlow. Hlavní p°íleºitost ale vidím p°ímo v BI platform¥ a v t¥sn¥j²í integraci FAKE GAME. Stávající °e²ení je moºné roz²í°it tak, aby fungovalo jako webová sluºba v kontextu platformy. Takovou úpravou se otevírají ²iroké moºnosti nasazení FAKE GAME nikoliv jako softwarového balíku, který je nutné instalovat a udrºovat, ale jako p°edp°ipravené data miningové sluºby. Nejenom samotní uºivatelé, ale i aplikace by pak mohly p°istupovat p°es jednotné rozhraní a vyuºívat schopností FAKE GAME daleko jednodu²²ím a transparentn¥j²ím zp·sobem neº doposud. V poskytování softwaru jako sluºby osobn¥ vidím dal²í vývojový stupe¬ sou£asných aplikací. Tento p°ístup °e²í dne²ní obvyklé problémy s distribucí aplikací, s jejich p°ípadným zpoplatn¥ním, správou aktualizací apod. Snadná pouºitelnost takových °e²ení vede následn¥ k daleko ²ir²ím moºnostem nasazení.

68

KAPITOLA 8. ZÁVR

Literatura [1] J. Bleuel. Writing your own Pentaho Data Integration Plug-In. http://wiki.pentaho.com/display/EAI/ Writing+your+own+Pentaho+Data+Integration+Plug-In, stav ze 5. 4. 2010. [2] W. H. Inmon. What is a data warehouse? Prism Tech Topic, 1(1), 1995. [3] I. La²ek. FakeGame plugin for Pentaho Data Integration. http://code.google.com/p/fakegame-pdi-plugin/, stav z 10. 4. 2010. [4] I. La²ek. Plugin for Pentaho BI enabling production of FAKE GAME reports. http://code.google.com/p/fakegame-pentaho-bi-plugin/, stav z 10. 4. 2010. [5] L. Niu, J. Lu, and G. Zhang. Cognition-Driven Decision Support for Business Intelligence, chapter Business Intelligence, pages 1929. Springer Berlin / Heidelberg, 2009, 2009. [6] R. Pecinovský. Návrhové vzory, volume 1. Computer Press, 1st edition, 2007. [7] S. Rizzi. Encyclopedia of Database Systems, chapter Business Intelligence, pages 287 288. Springer US, 2009. [8] W. van der Aalst, A. Weijter, and L. Maruster. Workow mining: Discovering process models from event logs. IEEE Transactions on Knowledge and Data Engineering, 16:2004, 2003. [9] Internal BI Component API - BI Platform - Pentaho Wiki. http://wiki.pentaho.com/display/ServerDoc2x/Internal+API, stav ze 8. 4. 2010. [10] The Pentaho BI Platform 3.0. http://wiki.pentaho.com/display/ServerDoc2x/ BI+Server+2.x-3.x+Community+Documentation, stav ze 26. 4. 2010. [11] Business Intelligence - What is Business Intelligence? http://www.cmis.csiro.au/bi/what-is-BI.htm, stav ze 4. 3. 2010. [12] Debugging with Tomcat in Eclipse in 2.0. http://wiki.pentaho.com/display/ServerDoc2x/ 05.+Debugging+with+Tomcat+in+Eclipse+IDE+in+2.0+using+Sysdeo+ Eclipse+Tomcat+Launcher, stav z 10. 4. 2010. 69

70

LITERATURA

[13] Design Studio - BI Platform - Pentaho Wiki. http://wiki.pentaho.com/display/ServerDoc2x/Design+Studio, stav z 5. 4. 2010. [14] FAKE GAME Automated Data Mining Flow. http://fakegame.sourceforge.net/doku.php?id=developer_fakeflow, 4. 4. 2010.

stav

ze

[15] Gartner Predicts that Open-Source Business Intelligence Tools Production Deployments Will Grow Five-Fold through 2012. http://www.gartner.com/it/page.jsp?id=1246990, stav ze 2. 3. 2010. [16] Open-Source Business Intelligence Tools Production Deployments Will Grow Five-Fold through 2012. http://www.gartner.com/DisplayDocument?id=1210513, stav ze 2. 3. 2010. [17] Pentaho Commercial Open Source Business Intelligence - mondrian Architecture. http://mondrian.pentaho.org/documentation/architecture.php, stav ze 3. 4. 2010. [18] Internal BI Component API - BI Platform - Pentaho Wiki. http://wiki.pentaho.com/display/EAI/ Pentaho+Data+Integration+-+Java+API+Examples, stav z 10. 4. 2010. [19] Latest Pentaho Data Integration (aka Kettle) Documentation. http://wiki.pentaho.com/display/EAI/ Latest+Pentaho+Data+Integration+(aka+Kettle)+Documentation, 26. 4. 2010.

stav

z

[20] Conguring the Platform for Other Databases. http://wiki.pentaho.com/display/ServerDoc2x/ Configuring+the+Platform+for+Other+Databases, stav ze 30. 3. 2010. [21] Exploring the Pentaho Repository in 2.0. http://wiki.pentaho.com/display/ServerDoc2x/ 02.+Exploring+the+Pentaho+Repository+in+2.0, stav z 10. 4. 2010. [22] Suboor - Template Ant scripts to help you get started building complex Java projects quickly. http://code.google.com/p/subfloor/ wiki/HowToCreateANewProject, stav z 10. 4. 2010. [23] UC Irvine Machine Learning Repository. http://archive.ics.uci.edu/ml/index.html, stav z 15. 4. 2010.

P°íloha A Seznam pouºitých zkratek ARFF BI

Attribute-Relation File Format

Business Intelligence

CRM

Customer relationship management

DSS

Decision support system

ERP

Enterprise Resource Planning

ETL

Extract, Transform, and Load

GWT

Google Web Toolkit

HTML JAR

Java ARchive

JDBC JDO

Java Database Connectivity

Java Data Objects

JNDI JSP

HyperText Markup Language

Java Naming and Directory Interface

Java Server Pages

MDX

Multi-dimensional eXpressions

MQL

Metadata Query Language

OLAP

Online Analytical Processing

OLTP

Online Transaction Processing

POJO

Plain Old Java Object

PDF

Portable Document Format

PDI

Pentaho Data integration 71

72

PR

PÍLOHA A. SEZNAM POUITÝCH ZKRATEK

Public Relation

RMS

Root Mean Square

RPC

Remote Procedure Call

RSS

Really Simple Syndication

SQL

Structured Query Language

XML

eXtensible Markup Language

XUL

XML User interface Language

P°íloha B Instala£ní a uºivatelská p°íru£ka PDI v rámci FAKE GAME B.1

P°edpoklady

• Nainstalovaný Java Runtime Environment verze 6 B.2

Instalace

P°iloºené CD obsahuje v adresá°i fakegame verzi FAKE GAME zkompilovanou pro pouºití z p°íkazové °ádky. Zárove¬ obsahuje v adresá°i pentaho/pdi-ce PDI 4.0, ve kterém je moºné jednodu²e vytvá°et transformace z nichº je FAKE GAME schopen £íst data. Pouºití je velmi jednoduché. P°íslu²né adresá°e sta£í nakopírovat na lokální disk. B.3

Pouºití

Pomocí PDI vytvo°íme v podstat¥ libovolnou transformaci, která vy£te z n¥jakého zdroje data a upraví je do formátu vhodného pro FAKE GAME. To znamená, ºe výsledný krok by m¥l obsahovat pouze £íselné vstupy a názvy sloupc· ozna£ující výstupní atributy musí být ozna£eny vyk°i£níkem na za£átku (nap°. !price). V p°ípad¥ klasika£ních problém· je t°eba zakódovat výstupní t°ídy kódem 1 z N a v²echny p°íslu²né sloupce musí být op¥t ozna£eny vyk°i£níkem na za£átku. V transformaci m·ºeme zvolit libovolný krok, u kterého data na výstupu spl¬ují vý²e popsané poºadavky (nemusí být nutn¥ poslední). P°i volání FAKE GAME potom tento krok identikujeme podle jeho názvu. Transformaci uloºíme do souboru. Spu²t¥ní FAKE GAME tak, aby pouºil jako zdroj vytvo°enou transformaci je velmi jednoduché a spo£ívá v p°edání cesty k souboru s transformací (parametr -p) a názvu kroku z jehoº výstupu chceme data £erpat (parametr -s). Krom¥ toho je moºné pomocí dal²ích volitelných parametr· p°edat obvyklé volby FAKE GAME jako zp·sob testování model·. Povinným parametrem z·stává cesta k adresá°i s konguracemi model·. Volání z p°íkazové °ádky m·ºe tedy vypadat nap°. takto: 73

74PÍLOHA B.

INSTALANÍ A UIVATELSKÁ PÍRUKA - PDI V RÁMCI FAKE GAME

java -jar game-batch.jar -p "/path/to/transformation/file.ktr" -s "Output" cfg/fake/quick_linear V tomto p°íkladu spustíme transformaci uloºenou v souboru /path/to/transformation/file.ktr a data vy£teme z kroku nazvaného Output. Výsledný report je uloºen do adresá°e se zdrojovou transformací. V rámci p°iloºeného CD obsahuje adresá° etc/tests/pdi_trans celou ²kálu vzorových transformací. Pro správnou funkci n¥kterých z nich je t°eba nastavit databázové p°ipojení odpovídající lokální konguraci a naimportovat p°íslu²né databázové tabulky (sql exporty jsou rovn¥º uloºené v tomto adresá°i).

P°íloha C Instala£ní a uºivatelská p°íru£ka plugin pro PDI C.1

P°edpoklady

• Nainstalovaný Java Runtime Environment verze 6 C.2

Instalace

Na p°iloºeném CD je k dispozici kompletní instalace PDI 4.0 1 s jiº integrovanými pluginy pro FAKE GAME a Weku v adresá°i pentaho/pdi-ce. Sta£í nakopírovat tuto instalaci do libovolného adresá°e na lokálním disku a spustit skript spoon.sh (p°ípadn¥ spoon.bat pro Windows). Po startu m·ºeme vytvo°it repozitá° PDI (v databázi, nebo jako soubor na disku). Tato operace v²ak není nutná a nabídku je moºné bez obav zav°ít. C.3

Pouºití pluginu

Co se pouºívání PDI tý£e, doporu£uji projít dokumentaci projektu [19]. Samotný FakeGame plugin je umíst¥n ve skupin¥ krok· Transform. Jeho ovládání je velice jednoduché. V ovládacím dialogu (obrázek C.1) m·ºeme zvolit soubor s uloºeným serializovaným modelem vyprodukovaným pomocí FAKE GAME. Pokud vybereme soubor s klasikátory je moºné volbou Show output probabilities ovlivnit zobrazení výsledku klasikace. Na modely nemá tato volba vliv. Po nahrání modelu si m·ºeme prohlédnout jeho serializovanou podobu v záloºce Serialized model/classier (pro kontrolu). Na vstupy pluginu je t°eba p°ivést data ve stejn¥ pojmenovaných sloupcích jako byly sloupce dat p°i u£ení pluginu (na po°adí nezáleºí). P°ípadné p°ejmenování sloupc· je asi nejjednodu²²í realizovat pomocí kroku Select Values ze skupiny Transform. Toto mapování 1

Pozor, verze PDI p°iloºená na CD je vývojová verze, protoºe stabilní vydání PDI 4.0 nebylo v dob¥ psaní

této práce je²t¥ k dispozici. V této verzi nejsou podporovány n¥které star²í pluginy jako nap°. práv¥ plugin pro Weku. Ten jsem upravil alespo¬ tak, aby v hotových transformacích dokázal zpracovat p°íslu²ná data není v²ak moºné m¥nit jeho nastavení.

75

76

PÍLOHA C. INSTALANÍ A UIVATELSKÁ PÍRUKA - PLUGIN PRO PDI

Obrázek C.1: Ukázka uºivatelského rozhraní FAKE GAME pluginu pro PDI

je moºné zkontrolovat v záloºce Fields mapping. V²echny sloupce musí mít sv·j namapovaný ekvivalent. V opa£ném p°ípad¥ transformace selºe. Na p°iloºeném CD v adresá°i etc/tests/pdi_plug jsou umíst¥ny vzorové transformace vyuºívající FakeGame plugin. Ty jsou asi nejlep²ím zdrojem, jak se seznámit s tímto pluginem.

P°íloha D Instala£ní a uºivatelská p°íru£ka plugin pro Pentaho BI D.1

P°edpoklady

• Nainstalovaný Java Development Kit (JDK) verze 6 • Nastavená systémová prom¥nná JAVA_HOME na cestu k adresá°i s JDK D.2

Instalace

Na p°iloºeném CD v adresá°i pentaho/bi-platform je op¥t k dispozici p°edp°ipravená instalace BI pltaform 1 i s aplika£ním serverem a integrovaným FakeGame pluginem. Instalace je tak velmi jednoduchá a spo£ívá v nakopírování adresá°e biserver-ce na lokální disk. Server i s p°íslu²nou databází spustíme pomocí skriptu start-pentaho.sh (p°ípadn¥ start-pentaho.bat pod Windows). Tomcat naslouchá implicitn¥ na portu 8080, pokud tedy nedojde k n¥jakým konikt·m s jiº b¥ºícími aplikacemi, bude BI platform dostupná pomocí prohlíºe£e na adrese http://localhost:8080/pentaho. První zobrazení stránky m·ºe chvíli trvat, protoºe Tomcat pot°ebuje n¥jaký £as na nastartování. D.3

Pouºití

Manuál pro pouºití Pentaho BI platform je k dispozici na webu [10]. V tomto popisu se zam¥°ím zejména na aspekty týkající se p°ímo FakeGame pluginu. P°edpokládám tedy znalost práce se sekvencemi akcí popsané ve zmín¥né dokumentaci. Pro p°ihlá²ení vybereme n¥kterého z existujících uºivatel· (nejlépe Joe s administrátorskými právy). Po p°ihlá²ení budeme p°esm¥rováni na pracovní plochu (obrázek D.1). Zde 1

Bohuºel i v p°ípad¥ Pentaho BI platform nebyla v dob¥ psaní této práce k dispozici stabilní verze s

podporou plugin·. Z toho d·vodu jsem na p°iloºené CD musel umístit vývojovou verzi, která obsahuje n¥které chyby. Ty se projevují nap°. p°i editaci p°ístupových práv, nebo £asování spou²t¥ní jednotlivých sekvencí akcí. Na samotný chod FakeGame pluginu by v²ak tyto chyby nem¥ly mít vliv.

77

78PÍLOHA D.

INSTALANÍ A UIVATELSKÁ PÍRUKA - PLUGIN PRO PENTAHO BI

je p°ipravena sloºka FakeGame se vzorovými transformacemi. V¥t²inu transformací je moºné spou²t¥t rovnou. N¥které v²ak vyºadují nastavení p°ipojení k databázi a vytvo°ení p°íslu²ných tabulek (pot°ebné SQL skripty jsou rovn¥º k dispozici na p°iloºeném CD).

Obrázek D.1: Pracovní plocha v rámci Pentaho BI platform Hlavní síla pluginu v²ak spo£ívá v jeho za£len¥ní do vlastních sekvencí akcí, ty je moºné vytvá°et pomocí nástroje Design Studio [13]. Název p°íslu²né komponenty je FakeGameAction a její vstupy jsou uvedeny v tabulce D.1. Krom¥ vstup· je t°eba akci p°edat je²t¥ zazipovaný adresá° s kongurací reportu a jednotlivých model·. Ten se p°edává jako zdroj, tedy v terminologii Pentaho resource. Jeho název je configZip. Na výstupu potom komponenta vrací dva streamy, v Pentaho terminologii ozna£ené jako content. Výstup ozna£ený jako response nese report ve formátu HTML a je ur£ený pro zobrazení koncovým uºivatel·m v rámci pracovní plochy. Výstup s názvem zippedReport obsahuje archiv s reportem ve formátu HTML a v²emi pot°ebnými soubory pro jeho zobrazení. Oba výstupy je pak moºné p°edat dal²ím komponentám, zippedReport je nap°íklad vhodný v kombinaci s komponentou na odesílání e-mail·.

79

D.3. POUITÍ

Název vstupu

experimentSeries trainTestStrategy data

Popis vstupu

Indikuje, zda se mají provád¥t série experiment· (moºné hodnoty: true, false). Zp·sob testování model· (moºné hodnoty: train-test, cross-validation, whole-set) Samotná vstupní data ve formátu result-set. Vstupní data by m¥la být v £íselném formátu. Názvy výstupních hodnot pro u£ení jsou ozna£eny vyk°i£níkem (nap°. !output), p°ípadné výstupní t°ídy jsou zakódovány kódem 1 z N.

Tabulka D.1: Seznam vstup· FakeGame pluginu pro Pentaho BI platform

80PÍLOHA D.

INSTALANÍ A UIVATELSKÁ PÍRUKA - PLUGIN PRO PENTAHO BI

P°íloha E Ukázky nasazení FAKE GAME pluginu pro Pentaho BI Tato obrazová p°íloha obsahuje ukázky nasazení FAKE GAME pluginu pro Pentaho BI platform. Jde zejména o ukázky vyprodukovaných report· a prost°edí pro konguraci práce pluginu v rámci platformy.

Obrázek E.1: Denice jednoduchého workow v prost°edí Action Sequence editoru - uºivatel je poºádán o výb¥r kongurace reportu, který si p°eje vid¥t.

81

82

PÍLOHA E. UKÁZKY NASAZENÍ FAKE GAME PLUGINU PRO PENTAHO BI

Obrázek E.2: Vyhodnocení úsp¥²nosti klasikátoru pomocí ROC k°ivek. Datový soubor pro klasikaci kosatc·, testovací strategie cross validation.

Obrázek E.3: Jednoduchý formulá° pro výb¥r strategie testování model· porovnávaných v rámci FAKE GAME reportu. Formulá° je kongurovaný pomocí Action Sequence editoru.

83

Obrázek E.4: Vyhodnocení testování sestavených model· - výb¥r toho nejlep²ího (v tabulce na obrázku je ozna£ený tu£n¥). Datový soubor pro odhad spot°eby vody mandarinkovníku, data rozd¥lena na trénovací a testovací mnoºinu.

84


Obrázek E.5: Propojení pluginu s komponentou pro odesílání e-mail· v prost°edí Action Sequence editoru. Je tak moºné snadno sestavovat sekvence, kde je výsledný report na záv¥r odeslán mailem.

85

Obrázek E.6: Andrewsovy k°ivky pro datový soubor EEG novorozenc· v rámci Pentaho BI platform.

86


Obrázek E.7: Feature ranking pro vstupy z datového souboru Odhad prodejní ceny aut.

P°íloha F Obsah p°iloºeného CD . | |-| | |-|-| | |-| | | \--

etc |-- data \-- tests fakegame pentaho |-- bi-platform \-- pdi-ce src |-- game-core |-- FakeGamePlugin \-- FGPentahoBIPlugin text |-- pdf \-- tex \-- figures

Testovaná data Transformace vyuºité p°i testování Instalace FAKE GAME Instalace Pentaho BI pltaform Instalace PDI Zdrojové kódy projektu FAKE GAME Zdrojové kódy pluginu pro PDI Zdrojové kódy pluginu pro BI platform Text práce ve formátu pdf Zdrojový text práce ve formátu LaTeX Pouºité obrázky

87

Integrace BI open source nástroj. Bc. Ivo La²ek. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta

Recommend Documents