IBM Komplexní reporting - case study POC pro sázkovou kancelář

Ondřej Bothe – Cognos Technical Professional, Martin Pavlík - IM Technical Professional 09/02/2010

IBM Komplexní reporting - case study – POC pro sázkovou kancelář

© 2010 IBM Corporation

Building a smarter planet

Definice „Case Study“

Cíl: – vytvoření dvou ukázkových reportů pomocí pokročilých reportovacích nástrojů

Zadání: – K dispozici ukázková data (celkem tři podkladové tabulky pro oba reporty) – Přibližný popis business problematiky – Problematika by měla být řešena „near-on-line“ Nemělo by se jednat o aktualizaci dat jednou za den, ale naopak v co nejmenších intervalech

Podmínky – Nejsou dány žádné omezující podmínky S výjimkou výkonu

2



Data k dispozici:

Sázenka

1)

K dispozici tři tabulky:

Vsazeno

Typ

500

1.1.2009

2.2.2009

2

3000

3.1.2009

15.1.2009

...

...

...

100

10.1.2009

13.1.2009

...

Hosté

Výsledek 1.poločas

...

Celkový výsledek

...

Fotbal

Sparta

Liberec

Výhra

...

...

Prohra

Fotbal

Slavia

Sparta

Prohra

..

...

Prohra

Fotbal

Viktoria

Příbram

Výhra

...

...

Výhra

Fotbal

Olomouc

Třinec

Výhra

...

...

Prohra

Fotbal

Bohemians

Brno

Prohra

...

...

Výhra

...

...

...

...

...

...

...

Hokej

Sparta

Slavia

Prohra

...

...

Prohra

Datum sázenky

Konec platnosti

3)

3

Domácí

Konec platnosti

1

3679

2)

Datum sázky

Sázenka

Sázka

Kurz

Vsazeno

1

A

1:3

500

1.1.2009

2.2.2009

1

B

1:2

500

1.1.2009

2.2.2009

1

C

1:67

500

1.1.2009

2.2.2009

2

B

1:2

3000

3.1.2009

15.1.2009

2

D

3:7

3000

3.1.2009

15.1.2009

...

...

...

...

...

...

3679

D

3:7

100

10.1.2009

13.1.2009 © 2010 IBM Corporation


Zadání prvního reportu: Podkladová data:

Sázenka

Sázka

Kurz

Vsazeno

Datum sázky

Konec platnosti

1

A

1:3

500

1.1.2009

2.2.2009

1

B

1:2

500

1.1.2009

2.2.2009

1

C

1:67

500

1.1.2009

2.2.2009

2

B

1:2

3000

3.1.2009

15.1.2009

2

D

3:7

3000

3.1.2009

15.1.2009

...

...

...

...

...

...

3679

D

3:7

100

10.1.2009

13.1.2009

Jedna sázenka může mít více sázek (události na které se sází) Každá sázenka má datum, kdy byla sazena a kdy končí poslední událost, na kterou je vsazeno Je dána celková částka, která je dána na Sázenku (sloupec Vsazeno) Za den: celkem je asi 70 000 Sázenek, průměrně Sázenka cca obsahuje 7 Sázek Cíl reportu: – Automatizovaný a uživatelsky příjemný pohled na data – Detail kombinace Sázek, pohled na základní ukazatele, jako je celková vsazená částka,...

4



Zadání druhého reportu: Podkladová dat: Typ

Domácí

Hosté


...

Celkový výsledek

...

Fotbal

Sparta

Liberec

Výhra

...

...

Prohra

Fotbal

Slavia

Sparta

Prohra

..

...

Prohra

Fotbal

Viktoria

Příbram

Výhra

...

...

Výhra

Fotbal

Olomouc

Třinec

Výhra

...

...

Prohra

Fotbal

Bohemians

Brno

Prohra

...

...

Výhra

...

...

...

...

...

...

...

Hokej

Sparta

Slavia

Prohra

...

...

Prohra

Informace o všech událostech z historie Vyhodnocení pravděpodobnosti výsledku události podle definovaných ukazatelů – Výběr parametrů a dopočítání pravděpodobnosti vzhledem k výsledkům s opačnými parametry

Porovnání různých variant nastavení paramaterů v rámci jednoho reportu Data ligového fotbalu za 10 let = cca 50 000 záznamů Cíl reportu: – Lepší přehled o historických výsledcích s on-line přístupem pro uživatele – Automatické porovnání variant, volba počtu variant 5



Otázka číslo I. Který z reportů bude pravděpodobněji pracnější? – A: První report (report TOP 10 kombinací) –B: Druhý report (vypočítání pravděpodobnosti na základě historických dat) –C: Oba stejně

6



Detailnějsí analýza prvního reportu: Business požadavky: – Zajímavý je detail na Sázku a jejich kombinace Zajímají nás Sázky s nejvyšší sazenou částkou (TOP 10) Zajímají nás platné dvojice Sázek s nejvyšší sazenou částkou (TOP 10) Zajímají nás platné trojice Sázek s nejvyšší sazenou částkou (TOP 10)

Jaké jsou platné „jednice“ Sázek ze Sázenky 1?

Jaké jsou platné „dvojice“ Sázek ze Sázenky 1?

Sázenka

Sázka

Vsazeno

1

A

500

1

B

500

1

C

500

Sázenka

Sázka 1

Sázka 2

Vsazeno

1

A

B

500

1

A

C

500

1

B

C

500

Jaké jsou platné „trojice“ Sázek ze Sázenky 1? Sázenka

Sázka 1 1

7

Sázka 2 A

Sázka 3 B

Vsazeno C

500 © 2010 IBM Corporation


Detailnějsí analýza prvního reportu: Co to znamená: – V původní tabulce bylo 70 000 Sázenek průměrně po 7 Sázkách za den Požadavky: On line reporting (přijatelná odezva) za více dní Výběr TOP 10 – Pro „jednice“ je problém v principu možné řešit přes reportovací nástroje, ale na hranici únosnosti Všechny transformace probíhají až v rámci reportingu,...

Ale - Kolik bude mít tabulka řádků pro platné „dvojice“ Dvojice Sázek, které se spolu vyskytují na alepsoň jedné Sázence - Kolik bude mít tabulka řádků pro platné „trojice“ Trojice Sázek, které se spolu vyskytují na alepsoň jedné Sázence

8



Otázka číslo II. Kolik existuje platných „trojic“, ze kterých probíhá výběr TOP 10? (Za jeden den)

Trojice A - B - C Sázenka 1

Sázenka 4

C

A

D

B

A

C

B

F

G H

- A: cca 2 500 000 – B: cca 25 000 000

Trojice C - G - H Sázenka 1

Sázenka 41

Vsazeno: 20

Vsazeno: 100

C

H

Výhra: 1 345

Výhra: 10 210

D

B

A

C

B

F

G

G

H

– C: cca 250 000 000 9

Vsazeno: 20

Vsazeno: 75

Výhra: 1 345

Výhra: 1 202 © 2010 IBM Corporation


Detailnějsí analýza prvního reportu: Co to znamená: - Pro reporting „dvojic“ a „trojic“ není možné úlohu vzhledem k počtu záznamů řešit přes reportingovou vrstvu Hlavní důvod je počet kombinací

10



Ukázka prvního reportu

11



Detailnějsí analýza prvního reportu: Řešení: - Zapojení ETL nástroje pro tvorbu předgenerovaných pohledů na data - Vytvoření jednic, dvojic a trojic a vyfiltrování TOP 10

Co to je ETL? – Nástroj na manipulaci s daty, zejména s velkými objemy dat – ETL = Extract, Transfer, Load – Standardní použití: Denní nahrávání dat do Warehousu

HW pro ETL při POC: HW: VMWare (virtuální PC) s 3 GB RAM, 1 jádro procesoru 2,9 GHz

12



Otázka číslo III. Jak dlouho trvá generování tabulky „trojic“ (včetně TOP 10) v ETL nástroji (bez optimalizací) – Při každém spuštění je: Načtena celá tabulka Sázka X Sázenka Vygenerování všech „trojic“ z této tabulky Seřazení výsledků dle 3 kritérií (Počet, Sázka, Výhra), vybrání TOP 10

– A: cca 45 minut – B: cca 3 hodiny – C: cca 10 hodin 13



Otázka číslo IV. Co v tomto ETL trvá nejdéle? – A: Načítání vstupu: Celá tabulka Sázka X Sázenka – B: Vygenerování všech „trojic“ z této tabulky – C: Sečtení kombinací, seřazení výsledků, vybrání TOP 10

14



Ačkoliv trvá příprava datové vrstvy dlouho, reporty jsou relativně svižné

Pojďme se podívat na to, jak vypadá ETL generující podklady pro report

15



Detailnějsí analýza prvního reportu: On-Line report ≠ 45 minut Řešení: Optimalizace

ETL pro účely inkrementálního načítání

– Je vždy nutné brát celou tabulku? Můžeme nastavit mechanismus, kdy bereme nové záznamy – Pokud máme omezený datový vstup, generování trojic je výrazně rychlejší – Seřazení a vybráni TOP 10 Nemusíme porovnávat (řadit) vše, ale: Přičíst nové jen k TOP 10 kombinacím, vše co je pod limitem nejhoršího můžeme odfiltrovat. Pokud mohou kombinace také ubývat, můžeme od TOP 10 odečíst ubývající a přičíst nové. Vše co je pod limitem nejhošího můžeme odfiltrovat.

16



Využití jiného přístupu v případě inkrementálního načítání Zjednodušení pro účel vysvětlení – Budeme uvažovat jen jednice, tj. Jednotlivé sázky – Budeme uvažovat jen metriku „Počet“

Co už máme z předchozího běhu? #

17

Sázka

Počet

Co přichází v novém inkrementu – Objevují se nové sázky – Přibývají počty k existujícím

Nevyhneme se přepočítání aktuálních počtů Můžeme se ale vyhnout třízení > 26M záznamů Jak?

1

F

10 000

Sázka

Počet

2

D

7 500

A

1 310

....

......

.......

B

345

9

A

1 300

D

11 000

10

R

1 000

R

1 400

11

M

970

S

11 500

.....

.....

.......

M

980

26M

Q

1

....

....

– Budou nás zajímat jen sázky s počtem vyšším než než 1 000 – Pokud se má sázka dostat do TOP10, musí být jistě vyšší než poslední ze stávajících TOP10

– Pak budeme třídit jen cca 1020 sázek, které mají novu hodnotu počtu vyšší než 1 000



Otázka číslo V. Jak pomohla optimalizace? Pomohla vůbec? – Inkrement má velikost cca 1/10 původního počtu sázenek (necelých 7 000) Celý proces nově trvá: – A: cca 5 minut – tj. 1/10 času proti full-loadu – B: cca 15 minut – tj. je to kratší, ale nejedná se o přímou úměru – C: cca 45 minut – nemůže to pomoci – čas bude bohužel stále stejný

18



Odpověď na otázku číslo V.

19



Detailnějsí analýza prvního reportu: ON-LINE Reporting – Jakou nastavit časovou periodu pro spouštění ETL? Délka zpracování se bude značně lišit podle aktivit sázejících Je nemožné stanovit správný časový interval – Řešení: ETL se nebude spouštět na základě času ETL process se spustí pokaždé, když doběhne předchozí Nutná odstávka na údržbu (nasazení nové verze) V definovaných časových oknech – Finální výkonnost Díky dobré škálovatelnosti řešení (paralelismus v procesech) je výkon v podstatě přímo úměrný výkonu HW Pří nárůstu požadavků a nebo při nárůstu dat je možné pouze rozšířit HW

20



Proč volit pro ETL a Reporting stejného dodavatele? (IBM InfoSphere Information Server & IBM Cognos) Může to být výhodné pro zákazníka – Technologie ETL a reportingu mohou být propojeny na úrovni metadat – Co jsou to metadata? Business metadata – Popis jednotlivých pojmů, jejich vzájemné provázání – Sledování změn, jasně definované zodpovědnosti

Technická metadata – datové modely, ETL procesy, …

Extrémně důležitá je ale především provázanost Technických a Business metadat / - Výrazně snažší, pružnější a tedy i levnější údržbu a realizaci změn

21



Ukázka práce s metadaty

22



Zadání druhého reportu: Podkladová dat: Typ

Domácí

Hosté


...

Celkový výsledek

...

Fotbal

Sparta

Liberec

Výhra

...

...

Prohra

Fotbal

Slavia

Sparta

Prohra

..

...

Prohra

Fotbal

Viktoria

Příbram

Výhra

...

...

Výhra

Fotbal

Olomouc

Třinec

Výhra

...

...

Prohra

Fotbal

Bohemians

Brno

Prohra

...

...

Výhra

...

...

...

...

...

...

...

Hokej

Sparta

Slavia

Prohra

...

...

Prohra

Informace o všech událostech z historie Vyhodnocení pravděpodobnosti výsledku události podle definovaných ukazatelů – Výběr parametrů a dopočítání pravděpodobnosti vzhledem k výsledkům s parametry opačnými

Porovnání různých variant nastavení paramaterů v rámci jednoho reportu Data: 3 ligy, 10 let = cca 50 000 záznamů Cíl reportu: – Lepší přehled o historických výsledcích s on-line přístupem pro uživatele – Automatické porovnání variant podle parametrů, volba počtu variant 23



Zadání druhého reportu: Co to přesně znamená? – Uživatel si vybere parametry: Typ

Domácí

Hosté



...

Celkový výsledek

Fotbal

Sparta

Liberec

Výhra

Prohra

...

Prohra

– Určí, které parametry se v rámci výpočtu pravděpodobnosti nemění a které ano. Podle toho se vygeneruje nový dotaz: Typ

Domácí

Hosté



...

Celkový výsledek

Fotbal

Sparta

Liberec

Výhra

???

???

???

– V tomto případě: Fixní parametry: Typ, Domácí, Hosté, Výsledek 1.poločasu Volné parametry: Zbytek – Business význam reportu: Jaké je pravděpodobnost, že pokud je Sparta domácí, hraje s Libercem fotbal a vyhrála první poločas, tak prohraje druhý poločas a celkově prohraje. Pravděpodobnost se počítá ze všech zápasů, kdy je Sparta domácí, hraje s Libercem fotbal a vyhrála první poločas

24



Detailnějsí analýza druhého reportu: Prvky, které musí mít možnost Business uživatel nastavit – Parametry 1. Jednoduché nastavení paremetrů Výhra/Prohra,.... 2. Nastavení toho, které parametry zůstávají při výpočtu pravděpodobnosti stejné, a které jsou zrušeny 3. Nastavení, kolik takovýchto kalkulací chce vidět na stránce Aby mohl lépe porovnávat varianty – Cíl reportu: Zobrazení více variant pravděpodobnosti v rámci uživatelem definovaných parametrů

25



Otázka číslo VI. Bude potřeba ETL? – A: ano – B: ne – C: nelze rozhodnout

26



Detailnějsí analýza druhého reportu: Proč NE ETL – Hlavně Není možné dopředu definovat, jaké parametry si uživatel vybere Není možné dopředu generovat předpřipravené pohledy – Dále Ani datový objem není nijak velký Technologie ETL by report tohoto typu prodražovala a komplikovala jeho údržbu

27



Ukázka druhého reportu: DEMO

28



Závěrem – optimální struktura pro reporting: Kde všude se dají dělat datové transformace? – – – – – –

Zdrojový systém Warehouse Datamart MetaData pro reporting Definice samotného reportu Výběr parametrů v reportu

– Jak vybrat V každé vrstvě má transformace svůj význam V každé vrstvě se dělají jiné transformace Jak z pohledu businessu Kde budu počítat čistý zisk Kdo bude zodpovědný za výpočet čistého zisku Tak z pohledu IT Objem dat Rychlost

29



Závěrem – použité technologie: Reporting: – IBM COGNOS BI, verze 8.4 Licence Cognos BI Admin, Cognos BI Professional, Cognos BI Consumer - licenčně relativně malý náklad v celkovém řešení Klíčové pro prezentaci dat uživateli Definice parametrů Graficky pěkné zobrazení

ETL – ETL - IBM InfoSphere DataStage – jeden z modulů IBM InfoSphere Information Serveru Licence na serverovou a klientskou část řešení – Volitelně pak další moduly IBM InfoSphere Information Serveru pro práci s metadaty Licence na jednotlivé uživatele

Databáze – Může být použita libovolná databáze (DB2, Oracle, MS SQL Server, Informix, ....) Výkonnost se může drobně lišit dle podpory nativního vs. ODBC driveru

30



Závěrem – navazující workshopy: Ukázka nástroje ETL a nástroje na čištění dat Case Study „Generali pojišťovna“ V případě zájmu: – Tvorba reportů v Report sudiu, koncepce Cognosu BI – Podrobnější rozebrání case study pro sázkovou kancelář – Komplexní správa metadat

31



Závěrem

??? Otázky a odpovědi ???

Děkujeme za pozornost... 32


IBM Komplexní reporting - case study POC pro sázkovou kancelář

Recommend Documents