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

Transkript

1 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ář

2 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

3 Data k dispozici: K dispozici tři tabulky: 1) Sázenka Vsazeno Datum sázky Konec platnosti ) Typ Domácí Hosté Výsledek 1.poločas Fotbal Sparta Liberec Výhra Prohra Celkový výsledek 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 3) Sázenka Sázka Kurz Vsazeno Datum sázenky Konec platnosti 1 A 1: B 1: C 1: B 1: D 3: D 3:

4 Zadání prvního reportu: Podkladová data: Sázenka Sázka Kurz Vsazeno Datum sázky Konec platnosti 1 A 1: B 1: C 1: B 1: D 3: D 3: 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 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

5 Zadání druhého reportu: Podkladová dat: Typ Domácí 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 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 záznamů 5 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

6 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

7 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? Sázenka Sázka Vsazeno 1 A B C 500 Jaké jsou platné dvojice Sázek ze Sázenky 1? Sázenka Sázka 1 Sázka 2 Vsazeno 1 A B A C B C 500 Jaké jsou platné trojice Sázek ze Sázenky 1? Sázenka Sázka 1 Sázka 2 Sázka 3 Vsazeno 1 A B C 500 7

8 Detailnějsí analýza prvního reportu: Co to znamená: V původní tabulce bylo 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

9 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 - A: cca H Vsazeno: 20 Vsazeno: 100 Výhra: Výhra: Trojice C - G - H Sázenka 1 Sázenka 41 C H D B A C B: cca B G H F G C: cca Vsazeno: 20 Vsazeno: 75 Výhra: Výhra:

10 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

11 Ukázka prvního reportu 11

12 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

13 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

14 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

15 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

16 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

17 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? # Sázka Počet 1 F D A R 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? Sázka Počet A B 345 D R Budou nás zajímat jen sázky s počtem vyšším než než Pokud se má sázka dostat do TOP10, musí být jistě vyšší než poslední ze stávajících TOP10 11 M M Q 1 S M Pak budeme třídit jen cca sázek, které mají novu hodnotu počtu vyšší než

18 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

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

20 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

21 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

22 Ukázka práce s metadaty 22

23 Zadání druhého reportu: Podkladová dat: Typ Domácí 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 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 záznamů 23 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

24 Zadání druhého reportu: Co to přesně znamená? Uživatel si vybere parametry: Typ Domácí Hosté Výsledek 1.poločas Výsledek 2.poločas... 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é Výsledek 1.poločas Výsledek 2.poločas... 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

25 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, 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

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

27 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

28 Ukázka druhého reportu: DEMO 28

29 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

30 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

31 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

32 Závěrem??? Otázky a odpovědi??? Děkujeme za pozornost... 32