Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

Datové sklady a BI aplikace MFF – část 3 Duben 2004 Ing. David Pirkl.

Podobné prezentace


Prezentace na téma: "Datové sklady a BI aplikace MFF – část 3 Duben 2004 Ing. David Pirkl."— Transkript prezentace:

1 Datové sklady a BI aplikace MFF – část 3 Duben 2004 Ing. David Pirkl

2 7. Přednáška

3 Obsah Dokončení metodologie BDLC OLAP DM a CRM

4 Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

5 Architektura Je třeba mít plán  Nezačnete stavět dům bez plánu  O co je DW dražším projektem? Návrh architektury slouží  Pro komunikaci v rámci týmu  Určení plánu  Podklad pro učení nových členů týmu  Zaručuje flexibilitu a snadnost údržby  Pro znovu použití (na dalších projektech)

6 Architektura Využít Top-Down přístup  Od obecného k detailními Architektura musí vycházet z uživatelských požadavků

7 Architektura ÚroveňData (co)Technologie (jak)Infrastruktura (kde) (bezpečnost, síť, metadata, …) ETLPrezentace Uživatelské požadavky a audit Jaké informace potřebujeme k rozhodování? Jak zapadají do matice BUS architektury (DM a dimenze)? Jak můžeme získat data, jak je transformovat, jak je dostat k uživatelům? Jak se to děje dnes? Jak chceme analyzovat data? Jaké jsou hlavní business otázky? Jak měříme výkonnost firmy? Jaké HW a SW komponenty potřebujeme k úspěchu? Jaké používáme dnes? Model a Dokumentace architektury Dimensionální model: Jaké jsou hlavní fakta a dimenze které chceme sledovat? Jaké jsou vztahy mezi nimi? Jak tyto entity mají být strukturovány? Jaké specifické komponenty potřebujeme k dostání dat v užitečné formě na potřebné místo v potřebném čase? Jaké budou hlavní úložiště dat a kde budou situovány? Co budou uživatelé potřebovat k získání informací v užitečné podobě? Jaké druhy analýz a reportingu budeme potřebovat? Jaké jsou priority? Odkud a kam proudí data? Máme kapacity na přesun dat a na jejich uložení?Co za specifické komponenty potřebujeme? Kdo za ně bude odpovídat? Detailní model a specifikace Logický a fyzický model: Jednotlivé atributy, datové typy, domény, pravidla pro odvození atributů. Jak se zdroje dat mapují na cíle dat? Jaké produkty podporují potřebné vlastnosti? Jak je lze integrovat? Standardy pro psaní kódu, jmenné konvence, … Jaké jsou požadavky na reporty (šablony) – pro řádky, sloupce, hlavičky, filtry,...? Kdo potřebuje jaké? Jak často? Jak je třeba je distribuovat Jak je možné integrovat nástroje? Jak volat jejich utility, API, …? ImplementaceVytvořit databáze, indexy, backup, … Dokumentace. Napsat ETL kód. Automatizace procesu. Dokumentace. Implementace reportingového a analytického řešení, vytvořit první sadu standardních reportů, školení uživatelů. Dokumentace. Instalace a testování komponent infrastruktury. Propoj zdroje dat a DW s uživateli. Dokumentace.

8 Architektura Základní framework architektury (logický model)

9 Architektura Architektura by měla být řízena metadaty (metadata catalog)  Poskytuje parametry a informace pro všechny procesy (ETL, reporty, …)  Informace o DW, zdrojových systémech, ETL, …  Např. procedury pro zakládaní tabulek, indexů, uživatelů, spuštění skriptů, … (informace o tabulce a atributech v metadata katalogu, …)  Umožňuje např. rychlou změnu při upgrade provozních systémů, …

10 Architektura Data staging area (DSA) je vhodným místem pro archivování dat z provozních systémů Datový model DSA by měl být navržen tak, aby podporoval výkonnost ETL procesu a snadnost vývoje  ERD modely (kopie OLTP systémů)  Dimenzionální model  Pomocné tabulky  DSA – převod ERD modelů do dimenzionálních určených k načtení do 1. vrstvy DW (prezentační část)

11 Architektura Nástroje ETL je možné  Vyvinout sami  Zakoupit Komerční ETL nástroje jsou často poměrně drahé ale zaručují vysokou produktivitu (při správném využití)  Má smysl první etapu udělat ručně  Pak po schválení výsledků přejí na ETL nástroj

12 Architektura ETL proces – zabírá až 60 procent celkového vývojového času na projektu Potřeba vybrat a integrovat dat Problémy  Různé názvy sloupců  Chybné hodnoty  Neexistující referenční integrita  …

13 Architektura Možnosti získat data  Export z provozního systémů (flat file) Vhodné dohodnout rozhraní a přenechat odpovědnost na provozovateli OLTP systému  Přímé napojení  Replikace  Někdy je vhodné data komprimovat pro přenos a zase dekomprinovat

14 Architektura Typy extrakce  Inkrementální load Načtení dát nových (změněných) od posledního loadu Nová (změněná) data identifikována většinou flag v provozním systému nebo dle datumu (času) transakce, trigery, log file, … Datum (čas) transakce posledního loadu nutné uložit do metadata katalogu Většinou tak načítáme velké fakt tabulky  Full load Malé dimenze Při sledování SCD je nutné porovnat s původní dimenzí I v případě velkým faktových tabulek – jestliže není možné identifikovat v provozním systému co se změnilo od posledního loadu

15 Architektura Po načtení dat následuje transformace Transformace zahrnuje:  Integraci  SCD  Kontrola referenční integrity  Denormalizace  Čištění dat, spojování (merge), rozpojování  Konverze datových typů (např. ASCII, EBCDIC)  Odvození nových atributů, alokace hodnot na nižší granualitu (např. náklady) – využití business pravidel  Agregace  Audit obsahu dat (kontrolní součty, počty řádků, …)  Plnění auditních tabulek a metadat  Transformace dat pro specifické potřeby (např. pro Data miningové nástroje)  Null hodnoty – identifikace (např. speciálních kódu pro null hodnoty), nahrazení

16 Architektura Během načítání dat je třeba kontrolovat a monitorovat:  Naplánování úloh  Monitorovat proces načtení – ukládat potřebné informace např. pro možnost recovery (znovunačtení)  Řízení výjimky a špatná data identifikovaná při procesu ETL (např. duplicity) Exportovat, předat k vyřešení, načíst Identifikovat odpovědnou osobu za data (kvalitu)  Navrhnout postupy řešení chyb při načítání (např. výpadek proudu, DB, …)  Zaslání upozornění na chyby při loadu (nečekat až do rána, že neproběhlo)

17 Architektura Potřeba nastavit způsoby zálohování a recovery  Potřeba zajistit rychlost a jednoduchost zálohování a recovery Archivace  Fyzická – databáze  Logická – modely, skripty, … Seznam všech tabulek v DW (0. i 1. vrstva)  Zhodnotit jak náročné je bude obnovit  Které by nešly (obsahují historická dat)  Vybrat a rozhodnout co zálohovat  Nastavit procesy  Vyzkoušet recovery

18 Architektura Otázky bezpečnosti nejsou v 0. vrstvě (ETL) tak kritické – není-li určena pro dotazy  Pozor při přenášení dat po sítí při loadu

19 Architektura V metadata katalogu je vhodné udržovat metadata pro uživatele při získávání dat z DW  Kde co naleznou, popis, v jakých reportech se vyskytuje, … V prezentační vrstvě je třeba zajistit bezpečnost dat  Authentication Systém hesel, fyzické kontroly (otisky prstů, rohovky), omezení přístupu na základě IP adres, … Bezpečnost přístupu k databázi, reportům, exportovaným souborům  Authorization Co kdo může vidět – někdy vyžaduje hodně práce zabezpečit

20 Architektura Monitorovat využití DW Využití pro:  Zvýšení výkonnosti (agregace, indexy, view, …)  Podporu uživatelů, školení  Marketing DW  Plánování (rozvoje, upgrade architektury, …) Dobré reportovací nástroje by měly podporovat  Uživatelskou formulaci dotazů (business vrstva mezi daty a uživatelem)  Podporu využití agregací  Rozklad složitých SQL na více dotazů a jejich propojení ve výsledků  Tvorbu odvozených atributů  Ochranu před složitými dotazy, které mohou „položit“ DW

21 Architektura Reportingové nástroje  Desktop  Aplikační server  Součást RDBMS Reportingové řešení by mělo podporovat  Uživatelskou tvorbu reportů  Reportovací server  Parametrizované reporty  Plánovač plnění reportů (scheduler)  Interaktivní reporty  Propojení reportů  Report delivery (pull, push, , web, file system)  Metadata  Pokročilá prezentace (např. barevně označení položek nad určitý limit)  Podpora práce s semiaditivními ukazateli  Přímý zápis SQL plus SQL builder  API

22 Architektura Dále:  Calculace položet (if then, …)  Pivoting (cross tab)  Sorting  Kompletní formátování (mix tabulek, obrázků, grafů, report s více sekcemi, …)  Podpora grafů  Export výstupů (excel, word, …)  Uživatelsky přívětivý  Drop and down – tvorba reportů  Multitasking (nemuset čekat až report doběhne)  Cancel query  Podpora přístupy k různým zdrojům  Bezpečnost  Administrace (desktop, web)  …

23 Architektura Existuje několik skupin uživatelů z hlediska jejich technických znalostí OblastTyp uživatele Papírový uživatelTlačítkový uživatelJednoduchý ad-hocPokročilý uživatel Používání počítačeŽádná , WordWord, Excel, PowerPointMakra, tvorba WWW DWSpoléhá na pomoc ostatních Standardní reporty, default parametry, EIS Vytvoří jednoduché dotazy (QBE), modifikace existujících dotazů, změna parametrů, navigace v hierarchiích Tvorba dotazů, přímý přístup k databázi

24 Architektura Informační požadavky se rovněž liší Informační potřeby – kategorie Role uživatelePřístup k datům - kategorie NástrojePočet osob Monitoring na vysoké úrovni - klíčové metriky, flags Senior managementPřístup na "tlačítko"EIS - styl nástrojůMalý Sledování businessu - trh, produkty, zákaznicí, drill-down k detailu Střední management, marketing, prodejci, podpora zákazníků Standardní reporty – parametrizované OLAP style, reportingové nástroje, časování tvorby Velký Průzkum. Výjimky, nové problémy a příležitosti, vývoj obchodních případů (business case) Jako předchozí plus business analytici Ad hoc analýzaOLAP style, reporting, analytické nástroje pro ad-hoc dotazování Střední Kompletní analýza – kombinace dotazů, statistická analýza, vývoj modelů Business analytici a experti na analýzu Data mining - pokročilé analýzy Statistické nástroje, data mining nástroje, pokročilé analytické nástroje Malý

25 Architektura Potřeba poznat potřeby uživatelů -> navrhnout správné nástroje pro přístup k datům Vycházet z priorit nejdůležitějších uživatelů DW Vhodné využít web  Např. pro přístup k metadatům, reportům, …

26 Architektura Otázky infrastruktury je vhodné řešit s expertem z dané firmy (kde se buduje DW) Navržení HW  DW většinou prudce roste v prvních dvou letech (objem dat, dotazy)

27 Architektura Existuje mnoho variant řešení: Vývoj/Testování Warehouse 0. vrstva Aplikační server Desktop nástroje Warehouse Datové tržiště 0. vrstva Vývoj Aplikační server Desktop nástroje Aplikační server Desktop nástroje Aplikační server Reporting nástroje 1. vrstva 0. vrstva tržiště Tržiště Malé/Počáteční řešení Střední/2. kolo řešení Velké/Enterprise řešení

28 Architektura Třeba vzít v úvahu business požadavky Faktory  Velikost dat  Přírůstky, změny v datech, frekvence loadů, čas pro load  Počet uživatelů, jejich aktivita, typy analýz, kolik pracuje konkurenčně, rozložení časové zátěže  Složitost business – řešení  Požadavky na dostupnost (regionální, časovou)  Znalosti IS pracovníků (umí UNIX, Windows, DBA, …)  Finanční zdroje

29 Architektura Využití paralelního zpracování  Symmetric multiprocessing (SMP) Jeden počítač, sdílejí disk, paměť  Massively parrallel processing (MPP) Více počítačů, každý paralelně, např. tabulky přes několik počítačů, full table scan paralelně  Non-uniform memory architecture (NUMA) Kombinace SMP a NUMA Musí to HW a SW (OS, RDBMS) podporovat Při výběru OS zvážit i jaké jsou pro něj dostupné aplikace

30 Architektura CPU SMP CPU MPP CPU NUMA CPU

31 Architektura HW:  Disky (velikost, rychlost, RAID 1-5)  Paměť (čím více tím lépe) Nezapomenout na zdroje pro back-up Volba  OS: UNIX Windows  RDBMS  OLAP databáze  ETL tool

32 Architektura RDBMS – hlavní faktory pro uvažování:  Podpora DW  Bitmapové indexy  Optimalizátor dotazů Vhodné je se poučit z jiných DW projektů nebo dopředu otestovat výkonnost RDBMS Existují speciální relační databáze určené pro DW a ne pro transakční  Sybase IQ

33 Architektura Pro front-room nástroje zjistit nároky:  Paměť  Disk  Platforma U desktop aplikací vyřešit problém upgrade na nové verze, OS desktop stanic, paměť  Záleží na potřebách uživatele co bude za aplikace používat  Stanovit minimální požadavky dle skupin uživatelů (pasivní, analytici, …)

34 Architektura Potřeba zvážit nároky na síť  Kapacita, zatížení, množství přenesených dat  Bezpečnost – přenos přes síť (ssh) Databázová konektivita  Nativní ovladače  OBDC  OLE DB  JDBC Využití DNS serveru (ne přímý zápis IP adres), Active directory - metadata

35 Architektura Metadata – data o datech  „Je to užitečná definice, moc toho neříká“ Metadata  Pro ETL  Pro prezentaci Ohledně metadat je třeba:  Sepsat všechna metadata  Určit jejich důležitost  Určit odpovědnou osobu  Rozhodnout zda není vhodné koupit speciální nástroj na podporu metadat  Určit jejich uložení a back-up a recovery  Vystavit je uživatelům (procesům), kteří je potřebují  Zaručit jejich kvalitu a aktuálnost  Kontrola

36 Architektura Metadata:  Zdrojové systémy Umístění, modely, formát, vlastník, popis, frekvence změn, limity použití, dostupnost, způsob přístupu, práva přístupu, heslo, privilegia, extrakty z provozních systémů (formát, čas, zodpovědnost)  ETL Plánování (schedule) ETL pump, výsledky pump, jakých dat se týkalo (time stamp – pro inkrementální load), čas loadu, definice tabulek (dimenze, fakta, pracovní), skripty – popis, SCD pro každý atribut, umělé klíče pro produkční klíče (mapování), specifikace postupů čištění dat, transformace - popis, datový model, skripty – popis, agregace popis, auditní dimenze, nastavení bezpečnosti, specifikace back-up, recovery  RDBMS Model (logický, fyzický), partition, indexy, disk využití, bezpečnost, uživatelé, práva, view definice, uložené procedury, administrační skripty, back-up, recovery

37 Architektura Metadata  Prezentace Business jména sloupců, tabulek, hierarchií, reporty, business skupiny požadavků (marketing, obchod, …), uživatelská dokumentace, bezpečnost – privilegia, počty login, délka, počet dotazů, nejvíce využívané reporty (obecně, uživatelem) Metadata – prostě všechno

38 Architektura Je potřeba zajistit publikaci dat vs. ochanu data a bezpečnost Bezpečnost: Fyzické komponenty  Servery, stanice, kabely, switch, …  Nebezpečí Krádež Zničení/vandalismus Oheň Vlhkost Voda Prach Slunce, chemie Elektrické výpadky, zkraty Magnetismus

39 Architektura Informace: data, finanční dopady, reputace  Data, metadata, y, dokumenty, kopie, zálohy  Nebezpečí Vyzrazení strategie, plánů, rozpočtu, … Vyzrazení citlivých dat (čísla účtů, stavy účtů, …) Modifikace dat  Hrozby Odposlech Hacker útoky Fyzická krádež (notebook, dokumenty) Sociotechnika Trojské koně

40 Architektura SW  Nebezpečí Krádež kódu Krádež SW Trojské koně Viry Ataky na business  Nemožnost poskytovat služby (např. zahlcení serveru)  Nemožnost rekonstruovat data (např. objednávku)  Terorismus

41 Architektura Zajistit bezpečnost přenosu informací přes internet  Krytování Symetrické Asymetrické HW prvky k využití:  Routry (pro filtraci paketů)  Firewall Důležitý systém hesel  Neodhadnutelný  Odolný proti útoku hrubou silou (slovník slov) Heslo – písmena a číslice  Člověk – nebezpečí pro bezpečnost Hesla na papírku přilepená na monitor  Otisky palce, sítnice

42 Architektura Bezpečnost je proces  Potřeba zakomponovat do firemní kultury Je potřeba  Definovat bezpečnostní politiku  Získat podporu vedení  Školit a stále připomínat  Být ostražití, stále aktualizovat bezp. pravidla  Nedůvěřivý (Proč chtějí uživatelé vidět tyto data, pozorovat log, …)

43 Architektura Kroky  Taktické Využij antivirové programy (server, desktop), aktualizuj je Zvaž odstranění floppy disků a CD z stanic uživatelů Instaluj firewall, zakaž připojení přes modem ze stanic uživatelů, nastav bezpečnou komunikaci na internet (přes proxy server) Kontroluj SW instalovaný na počítačích Nastav a vyžaduj politiku hesel Škol uživatele v otázkách bezpečnosti Nastav kontrolní mechanizmy – kontrola logů, špatné přihlášení Zabezpeč back-up media Kontroluj nastavení práv uživatelů (vidí jen co mají?) Fyzicky zabezpeč servery Zajisti skartaci starých záloh, …

44 Architektura Strategické  Nezávislý bezpečnostní audit  Využití asymetrického kódování  Nahrazení hesel pokročilými technikami (otisky prstů, sítnice, magnetické karty) Z pohledu DW – využít bezpečnostní politiku, kterou firma implementovala dosud

45 Architektura Návrh a implementace architektury  Vycházet z principu  20 procent úsilí přinese 80 procent přínosu  Nastavit priority a na ty se zaměřit  Interaktivní proces – zpřesňování požadavků a návrhu architektury

46 Architektura Výstupy návrhu architektury  Plán technické architektury Shrne požadavky uživatelů Návrh budoucí architektury DW  Plán infrastruktury Někdy součástí Plánu technické architektury Popisuje servery, desktopy, síť

47 Architektura Uživatelské požadavky (Zahrnující business, data, otázky infrastruktury) Uživatelské požadavky (Zahrnující business, data, otázky infrastruktury) Matice BUS architektura Matice BUS architektura Model business datových procesů Model business datových procesů Logický a fyzický model dat Logický a fyzický model dat Plán technické architektury Plán technické architektury Matice vyhodnocení produktů Matice vyhodnocení produktů Výběr produktů Implementace Specifikace Infrastruktury (a model) Specifikace Infrastruktury (a model) Plán infrastruktury Plán infrastruktury DataTechnologieInfrastruktura

48 Plán technické architektury Během interview získej i požadavky na architektury  Její první návrh lze udělat už v průběhu interview nebo před a následně upřesňovat Spolupracuj s vybranými pracovníky (IS) na oponentuře a tvorbě architektury  Vypracovat draft plánu  Nechat oponovat Vytvoř model architektury (grafický)  Vhodný pro komunikaci Navrhni postup implementace architektury  Vyber prioritní oblasti  Odhadni čas a zdroje potřebné pro implementaci Proveď revizi dokumentu s managementem

49 Plán technické architektury

50 Plán – nemusí být na úroveň konkrétního produktu, ale měl by vycházet z potřeb uživatelů  Vize jak to do budoucnosti bude  Vypsat typy uživatelů, jejich potřeby na přístup k informacím, požadavky na reporting, …

51 Plán technické architektury

52 Plán infrastruktury Tři základní oblasti  Server (HW a OS) CPU, OS, Disk, Přírůstek dat, paměť  Síť Od OLTP do DW Od DW k uživatelům Zabezpečení, frekvence přenosu  Pracovní stanice HW, OS, konektivitu (ODBC, OLE DB, …) Plán je postupně upřesňován na základě vybraného SW podle plánu technické architektury

53 Výběr produktů Výběr na základě návrhu architektury, uživatelských požadavků  HW  DBMS  ETL tool  Nástroje pro prezentaci a přístup k datům Vhodné je testovat vybrané HW a SW komponenty  Vytvořit prototyp DW a testovat produkty  Nikdy je ale neotestujeme na reálné zatížení  Vhodné je např. domluvit s dodavatelem 90 denní testovací období a potom teprve podepsat smlouvu

54 Výběr produktů Vytvořit Matici vyhodnocení produktů  Nastavit priority (váhu) jednotlivým kritériím Musí mít … bylo by dobré kdyby mělo  Spolupracuj s výrobcem (ať objasní potřebné informace) Proveď průzkum trhu  WWW stránky  Publikace, časopisy  DW konference, fórum, portály Kritéria  Dle uživatelských potřeb pro daný ty nástroje  Výrobce Podpora Dokumentace Školení Konzultace Externí podpora (nezávislé forum na webu o produktu, …) Spolupráce s výrobce (dobrá, nekomunikativní, …) Velikost, budoucnost Reference

55 Výběr produktů Vybrat pro porovnání maximálně 5 produktů Uspořádat prezentaci výrobců  Získat informace na vyplnění Matici vyhodnocení produktů  Ukázka práce produktu  Domluvit ukázku u stávajícího zákazníka s podobným řešením Není-li možné rozhodnout – vytvoř prototyp (2 – 3 výrobci) a otestuj  Vhodné přenést na výrobce nebo s ním spolupracovat

56 Výběr produktů Otestovat produkty v plné šíři, ne jen omezeně  Jednoduché i komplexní funkce  Málo i hodně dat  Jeden a více uživatelů Tvorba prototypu – 4 až 6 týdnů Po 2 – 3 letech je vhodné výběr opakovat pro možný upgrade na nové technologie

57 Výběr produktů Na co si dát při tvorbě prototypu pozor  Definovat rozsah prototypu  Rozsah by neměl být moc velký  Vzít rozumnou velikost dat  Načíst data v syrovém stavu (neztrácet čas čištěním) Jednorázové ne vytvářet pro inkrementální  Naučit se v rámci tvorby prototypu co nejvíce o provozních systémech, problémech v datech, HW, SW potřebném  Získej názory uživatelů – ukázat jim výstupy  Nenechat se zaslepit očekáváním

58 Výběr produktů Instalace je závislá na to co je vybráno  HW a SW Potřeba dobře nainstalovat –může dosti ovlivnit výkonnost řešení  Spolupracovat se specialisty, dodavatelem, výrobcem Nezapomenout na:  Příprava místa na HW (servery)  Školení administrátorů  Testování po instalaci

59 Výběr produktů Čas potřebný na vytvoření plánu architektury Techno – politický Komplexní 12+ týdnů Jednoduché 1 – 6 týdnů Nerozumně Komplexní n týdnů Funkčně komplexní 8 – 12 týdnů Systémová komplexita Výstupy Datové zdroje Platformy Organizační komplexnost Jeden člověk Globální firma

60 8. Přednáška

61 Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

62 Fyzický design - Agregace Agregace mohou významně zvýšit výkonnost  Někdy nahrazeno OLAP databází Uchování agregací vedle detailních dat v databázi DW Agregace – obvyklé souhrny podle daných dimensí Je třeba vložit vrstvu, která dokáže rozpoznat, zda uspokojit uživatelský požadavek přímo z detailních dat nebo existuje agregace  Umí některé reportingové nástroje  Nebo je třeba vyvinout  Je to největší obtíž a výzva směrem k agregacím

63 Fyzický design - Agregace Přidat je rozumné agregace – zvyšuje nároky na prostor na disku Výběr dat pro agregaci  Dle potřeb uživatelů Např. na základě existujících reportů Vybrat atributy z dimenzí používané pro seskupení (region, kategorie produktu) Určit jejich kombinace – které atributy jsou používány společně  Dle statistické distribuce dat v DW Např. produktu je Kategorií – – nemá moc smysl agregovat (stále mnoho řádků) Kategorii – – agregovat Počítat frekvence výskytu řádků pro kombinace hodnot atributů dimenzí  Např. 12 měsíců x 256 produktů = XY možných řádků v faktové  V čase se mění – interaktivní cyklus Mažou nepoužívané, přidávají nové

64 Fyzický design - Agregace Všechny agregace v součtu by měly být optimálně asi stejně objemově velké jako původní tabulka Každá agregace má svoji faktovou tabulku  A zmenšené verze dimenzionálních tabulek (dle úrovně agregace)  Některá fakta musí být vypuštěna – mohou dávat smysl pouze na detailní úrovni Agregace pak často umožňují přímé porovnání s uloženými daty plánu (plány jsou často na agregované úrovni)  Lze uložit do jedné tabulky Agregované tabulky mohou být často rozšířeny o fakta typu min_prodej_kč, max_, count_

65 Fyzický design - Agregace Sales fact table Time_key (FK) Product_key (FK) Store_key (FK) Promotion_key (FK) Dollar_sold Units_sold Dollars_cost Promotion dimension Promotion_key Promotion_name Price_type Ad_type Display_type … Product dimension Product_key (PK) SKU Description Brand Category Department Package_type Size … Time dimension Time_key (PK) SQL_date Day_of_week Month Fiscal_period Season Store dimension Store_key (PK) Store_ID Store_name Address Region Division Floor_plan_type

66 Fyzický design - Agregace Sales fact table Time_key (FK) Product_key (FK) Store_key (FK) Dollar_sold Units_sold Dollars_cost Plan_dollars_sold Plan_units_sold Plan_dollars_cost Category dimension Product_key (PK) Category Department Time dimension Time_key (PK) Month Fiscal_period Season Store dimension Store_key (PK) Region Division Sales by Category-Region-Month Fact table

67 Fyzický design Je ovlivněno:  Logický datový model  Zvolený RDBMS  Objemem dat  Způsobem využití dat  Nástroji pro přístup k datům Je třeba:  Vytvořit plán fyzické implementace  Vytvořit a dodržovat standardy

68 Fyzický design Vytvoř jmenné a databázové standardy Fyzický model Revize Plánu agregací Počáteční Strategie indexace Databázová instance Fyzické uložení Monitoring užívání

69 Fyzický design Vytvořit standardy  Jména databázových objektů  Jména a cesty k fyzickým souborům Lze převzít (a případně modifikovat) již existující firemní standardy Příklad konvence – jméno složené ze tří částí  Hlavní část – co je to? (např. zákazník, produkt, účet)  Třída – typ objektu (např. průměr, počet, datum, flag)  Vlastnost – volitelný, popisuje předchozí dvě vlastnosti (např. počátek, konec, primární, sekundární)  Konvence: hlavni_vlastnost_třída Ucet_počateční_datum Prodeje_průměr Zvážit rozlišit logická a fyzická jména  Doporučeno stejné – co nejvíce popisné

70 Fyzický design - standardy Dohodnout se na seznamu slov (Hlavních části) s uživateli  Vytvořit seznam tříd a vlastností Vytvořit seznam používaných zkratek (např. desc = description) Vytvořit standardy pro pojmenování pracovních tabulek pro ETL Zvážit poměr mezi popisností názvu a jeho délkou  my_company_billingDW_customer_ID Pozor zda databáze je case senzitive  Brát jako by byla i když není  Připraveno pro migraci na novou databázi, která by mohla být

71 Fyzický design - standardy Využít pro názvy tabulek synonyma  Je pak jednoduší při změně struktury tabulky jenom změnit odkaz synonyma než měnit aplikace Alternativně lze využít view  Nebo materializované view  Zvážit výkonnost view tvořené z více tabulek Vytvořit standardy (adresářovou strukturu a jmenné konvence) pro umístění souboru  Zdrojové kódy  Skripty  Binární soubory  Databázové soubory  Modely  Dokumentace

72 Fyzický design - standardy DISK A RAID 1 Adresáře RDBMSObsahuje databázi ETLObsahuje ETL nástroj LOGObsahuje log soubory SCRIPT_PRODObsahuje produkční scripty METADATAObsahuje skripty pro metadata DIMENZEObsahuje scripty pro dimenze ZAKAZNIKObsahuje scripty pro dimenzi zákazník crt_zakaznik.sqlDDL - vytáří tabulku zákazník crt_cust_stage.sql DDL - vytáří data staging tabulky pro zákazníka crx_customer.sqlDDL - indexy nad tabulkou zakazník drx_customer.sqlDDL - drop indexy customer_stage.sqlScript pro 0.vrstvu upd_customer.sqlScript pro načtení do 1. vrstvy readmePopis obsahu adresáře …. FAKTAObsahuje scripty pro faktové tabulky SCRIPT_DEVObsahuje vývojové scripty DRIVE B RAID 5 DATABASE Obsahuje databázové soubory (vlastní data) DRIVE C NO RAID DATASTAGEObsahuje flat files TEMPDATTemp místo pro databázi JOBLOGSLogy z proběhlých úloh a scriptů

73 Fyzický design Fyzický model vychází z logického  Některé změny vlivem zvoleného RDBMS  Přidány pomocné tabulky (většinou nejsou součástí logického modelu)  Detailní nastavení datových typů, partition, specifikace umístění tabulky, umístění na disku databáze (souborů) Vhodné využít modelovacího (case) nástroje  Většinou je možné i využít pro tvorbu dokumentace (např. technický popis z jakých zdrojů se plní daný atribut, jaký je typ, transformace, …) Definovat entitní, doménovou a referenční integritu, null hodnoty  Někdy je výhodnější neimplementovat (když jsou čistá data) – nezatěžuje RDBMS – ale pozor na konzistenci dat

74 Fyzický design Model by měl obsahovat i indexy Modifikovat model dle potřeb uživatelských nástrojů  Např. vyžadují snow-flake Provedení přibližného odhadu velikosti databáze  Možno využít schopností modelovacího nástroje  „Ruční výpočet“ Délka (velikost) řádku Počet řádek, počet řádek přírůstku pro jeden load Pro indexy přidej stejně místa jak pro tabulku Temp space – pro budování indexu musí být dvojnásobný jak index  Pro třídění alespoň velký jak tabulka Započítat metadata tabulky Připočítej agregační tabulky (obecně velikost v souhrnu jako base tabulka) Obecně platí, že DW zabere v součtu 3 až 4 tolik místa jak atomická data Potřeba zahrnout i místo pro testování, vývoj, ETL

75 Fyzický design Nejvíce místa zabírají  Faktové tabulky  Indexy na nich Dimenze jsou v porovnání s faktovou tabulkou obecně zanedbatelné  Výjimka např. velké dimenze zákazníků

76 Fyzický design Vytvořit počáteční plán indexace  Bude se měnit v průběhu využívání DW – podle analýzy dotazů, doby odezvy, … Potřeba porozumět jak zvolený RDBMS využívá indexy a jak tvoří plán provedení dotazu B-tree indexy  Pro atributy s velku kardinalitou (např. customer_ID)  Klastrované vs. Neklastrované  Na jednom nebo více sloupcích Bitmapové indexy  Pro atributy s nízkou kardinalitou (např. pohlaví) Některé RDBMS disponují speciálními indexy Některé mají zabudovanou podporu star schéma (násobné join)

77 Fyzický design Faktová tabulka  Indexy na klíčích Jeden pro jeden klíč – RDBMS podporuje využití více indexů pro jeden dotaz Několik složených indexů – podle cesty dotazu  Lze v případě potřeby i indexy na faktech (když hodně dotazů typu prodej > 1000) Dimenzionální tabulka  Na primárním klíči  Bitmapové indexy na atributech dimenze  Na atributech sloužících pro join, filtrování, group by

78 Fyzický design Nastavit a zvážit indexy i pro efektivní ETL Při loadu dat  Zvětší-li se loadem tabulka o 10 až 20 procent je efektivnější smazat a znovu vytvořit index Kontroluj indexy a statistiky po loadu

79 Fyzický design Instalace a nastavení databáze  Zdokumentovat nastavení databáze plus důvod DW je náročny na paměť Blocksize  Záleží na potřebách Uložit scripty pro nastavení databáze Nastavit partition tabulek  Většinou podle atributu datum Nastavit umístění souborů na disku  Doporučuje se využít RAID disky (RAID 1 až 5)  Optimálně databáze a OS jeden disk, zdrojová data (flat soubory) druhý disk, tabulky a indexy další dva disky, transakční log další disk, temp další disk  Z hlediska dotazů je vhodné aby fakt na jednom disku a dimenze na jiném

80 Fyzický design Potřeba vybudovat systém pro monitoring využití DW  Load dat  Dotazy  Běh procesů  Využití zdrojů Důvody pro monitoring:  Výkonnost Ladění dotazů, indexy, agregace Výběr testovacích dotazů  Podpora uživatelů Sledovat vytíženost, logování uživatelů Pro plánování školení Proč se uživatel už dlouho nepřihlásil – neví jak, nemůže se připojit k databázi  Marketing Že DW je stále více využíván Kdo z uživatelů využívá nejvíce – konkurence mezi uživateli  Plánování Další rozvoj DW dle vzrůstajícího počtu uživatelů, konkurenčních dotazů, času loadu, velikosti databáze,….

81 9. Přednáška

82 Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

83 ETL Hlavní základní kámen dobrého DW V prvním kroku je třeba vytvořit plán ETL  Plán: Konceptuální model zdroj-cíl prodění dat (na jednu stránku) Testovat, implementovat nástroj pro ETL nebo využít SQL Graficky zobraz všechny komplexní transformace, generování umělých klíčů, SDC. Vytvořit prvotní plán sekvenčních kroků  Dimenze Vytvoř a testuj statický load dimensionální tabulky. Primárním cílem je otestovat infrastrukturu (připojení, přenos souborů, bezpečnost – práva) Vytvoř a testuj SCD proces pro jednu dimenzi Vytvoř load pro zbývající dimenze  Fakta a automatizace Vytvoř load historických dat do faktových tabulek (zahrnuje management umělých klíčů, a jejich substituci) Vytvoř a testuj inkrementální proces Vytvoř a testuj load agregací nebo load do OLAP vrstvy Vytvoř a testuj automatizaci celého procesu

84 Vrstvy datového skladu Datový sklad se většinou staví ve vrstvách: VrstvaPopisETL náročnost 0. vrstvaV nulté vrstvě se uchovávají data z jednotlivých provozních databází. Jedná se většinou o kopie provozních dat 1:1. Data neslouží přímo pro analýzy, ale jako vstup pro další vrstvy. Převod dat v zásadě 1:1, základní transformační kroky. 1. vrstvaData jsou uložena v datovém modelu datového skladu (tabulky fakt a dimenzí). Na data jsou aplikována integritní omezení. Tato vrstva slouží pro analýzy. Data jsou očištěná a konzistentní. Náročné transformace a čištění dat, mapování dat z 0. vrstvy na datový model datového skladu. 2. vrstvaSpeciálně připravená data pro podporu speciálních aplikací. V podstatě se jedná o jednotlivá datová tržiště. Náročné transformace z 0. a 1. vrstvy (speciální algoritmy).

85 ETL Obecně je nutné vyřešit dva základní problémy:  Transformace z různorodých zdrojů  Integrace data do datového skladu zdrojové DB transformaceintegrace homogenní DB DW

86 ETL Je třeba zajistit dostupnost zdrojových systémů pro potřeby loadu  Přímé napojení  Extrakty s danou strukturou Vychází se z vytvořeného dokumentu mapující vazby zdroj – cíl Je potřeba  Dodržovat standardy (jmenné, psaní kódu)  Psát srozumitelné komentáře  Hlavičky skriptů  Vytvořit knihovny obecně využívaných funkcí  Testovat funkčnost  Dokumentace

87 ETL Krok 1 – konceptuální model ETL  Základní, na jednu stránku  Mapování zdroj – cíl, poznámky k hlavním bodům  Je-li jeden hlavní systém – zdroje logické seskupení zdrojových tabulek  Tři základní fáze ETL Extrakce – ze zdrojových dat Transformace Load – do 1. vrstvy DW

88 ETL Zákazníci (RDBMS) Regiony (RDBMS) DMR systém (COBOL flat file, 2000 sloupců Jeden na zákazníka) Měřiče (MS Access) Čas (MS Excel) Zákazník Region Prodeje elektřiny Měřiče Čas odpočtu Měsíční spotřeba SCD pro demografické a účetní atributy 25 mil zakazniku, 10 tis nových nebo Změněných za den 15 tis oblasti Popisky potřebují upravit Kontrola RI 750 tis. Zakazníku Za den …. Kontrola RI Kdo spravuje 75 typů měřičů Starší nejsou v tomto systému

89 ETL Krok 2 – nástroj na ETL  Možnosti řešení Kód  T-SQL, PL/SQL, Delphi, … Nástroj  Grafické rozhraní, zrychlení procesů  Repositář dat, paralelismus  Dražší řešení  Informatika, DTS, warehouse Builder  Většinou na první fázi dělat „ručně“ Nezvyšovat náklady na DW Záleží na podmínkách

90 ETL Krok 3 – detailní plán  Detailně rozpracovat jednotlivé kroky  Rozhodnout se nad sekvencí kroků Nejprve dimenze Pak fakta (plus look-up na umělé klíče)  Zde jedna (i více) stránka pro jednu tabulku v DW Někdy smysl vycházet ze zdrojové tabulky  Doplnit pseudokódem pro transformaci  0. vrstva = data staging area Místo kde jsou načtená data čištěna, kombinována, archivována, transformována a přenášena do prezentačních vrstev (1. vrstva DW)

91 ETL Dimenze  Statická  SCD  Umělé – nejsou v datech (Časová dimenze) Krok 4 – naplnit jednoduchou statickou (ne SCD) dimenzionální tabulku  Load Ze souboru – výhoda, že soubory lze zálohovat a tak znovu použít při recovery, lze je při přenosu kryptovat, zapakovat Přímé napojení - stream

92 ETL Krok 4 – pokračování  I jednoduchá tabulka potřebuje Čištění dat Přiřazení umělých klíčů  Je třeba uchovávat tabulku mapování přirozených klíčů na umělé  Využívá se později i pro faktové tabulky  Obvykle umělý klíč – integer  Možno využít sekvencí  Hlavní transformace – konverze datových typů, kódování – čeština  Jsou-li zdrojová data pro dimenzi z více zdrojů (např. zákazník) Potřeba namapovat na sebe Někdy těžko lze – fuzzy logika (jméno, adresa, …) Existují na to nástroje Uložit do tabulky umělých klíčů přirozené klíče ze všech spojených záznamů (ze všech zdrojů)  Testovat zda vztahy mezi atributy dimenze jsou opravdu 1:1 nebo 1:N

93 ETL Krok 4 – pokračování  Pro load dat využít bulk funkci I pro load do 1. vrstvy je možné Insert into je pomalé a zapisuje se do log souboru – problém při velkých loadech Pro load dat do prezenční vrstvy – doporučení  Vypnout loggování  Pre-sort data dle primárního klíče (rychleji se načte při indexu na primární klíč)  Při full refresh tabulky – smaž původní data pomocí truncate table  Nelogguje se  Přidává-li se více jak 10 procent dat do tabulky je smysluplné drop a recreate index (záleží na podmínkách, počtu indexů, …)  I při ponechání indexů je dobré je časem přebudovat pro zamezení přílišné fragmentace (fillfactror na maximum)

94 ETL Krok 5 – SCD  Hlavně se používá technika Typ 2  Přístup Načíst všechna data a dívat se co se změnilo Využít inkrementálního načítání (načíst jen změny od minulého loadu) – viz dále u faktové tabulky  Hlavně u velkých tabulek  SCD typ 1 – je vlastně inkrementální načtení dimenzionální tabulky (jako full ale inkrementálně) Problém s položky smazanými v OLTP – byly smazány tak nemohou být načteny – pro DW to ale potřebujeme vědět  Triggery  Změny v OLTP – nemazat, deaktivovat Výhodně je načítat jen změny  A ještě více pokud OLTP udržuje informaci o typu změny

95 ETL Krok 5 – pokračování  Identifikovat změny  Porovnat s stávající dimenzí Neexistuje-li záznam – vložit Existuje-li – SCD (dle typu SCD)  Jestliže v dimenzi některé položky mají SCD typ 1 a některé SDC typ 2 musím u položek s typem 1 každou změnu promítnout do všech záznamů pro daný objekt v dimenzionální tabulce  Velké dimenze se zpracovávají podobně jako faktové tabulky

96 ETL Změněné záznamy Dimeze zákazník Customer_id Customer_type Jméno Adresa … Most recent key map Customer_id Customer_key Update key map Lookup max Customer key Add surrogaste Key and load record Záznamy s umělým klíčem Customer_key (PK) Customer_id Customer_type Jméno Adresa … Load to DBMS dimension table Umělý klíč

97 ETL Dnešní záznamy Customer_id Customer_type Jméno Adresa … Změněné záznamy dimenze zákazník Customer_id Customer_type Jméno Adresa … Včerejší verze dimenze Customer_id Customer_type Jméno Adresa … Diff compare Policy decision Input do Procesu Na předchozím slide

98 ETL Krok 6 – naplnit zbývající dimenze  Obdobně jako předchozí načíst i další tabulky  Vytvořit skript pro načtení Časové dimenze Někdy se využívá tabulkový procesor

99 ETL Faktové tabulky  Výhodné načítat inkrementálně Jen záznamy změněné od posledního loadu  Podobně i velké dimenze Krok 7 – načtení historických údajů  Vytvořit pumpy pro načtení historických dat  Interaktivní proces – nebude pravděpodobně dobře na první pokus V praxi řada výjimek (co započítat, co ne, …) – potřeba identifikovat tyto business pravidla Potřeba auditovat součty, počty, … a porovnat s výstupy z provozních systémů – zvyšuje důvěryhodnost DW

100 ETL Krok 7 – pokračování  Nahrazení přirozených klíčů umělými  Vhodné je zjišťovat aktuální umělé klíče ze speciálních tabulek, ne přímo z dimenzí (může být pomalé) Lze řešit v dimenze flagem – aktuální záznam a bitmapovým indexem nad ním  Jestliže se načítají faktová tabulka historicky musí se i historicky přiřadit umělé klíče (platné v čase transakce zachycené v faktové tabulce), ne vzít aktuální umělý klíč!!!

101 ETL Sales fact table Production ID Time_id Product_id Store_id Dollar_sold Units_sold Dollars_cost Plan_dollars_sold Plan_units_sold Plan_dollars_cost Most recent key map product_id product_key Most recent key map store_id store_key Most recent key map time_id time_key Sales fact table Surrogate key Time_key (FK) Product_key (FK) Store_key (FK) Dollar_sold Units_sold Dollars_cost Plan_dollars_sold Plan_units_sold Plan_dollars_cost Replace ID umělým klíčem Replace ID umělým klíčem Replace ID umělým klíčem Load fact table Into RDBMS

102 ETL Krok 7 – pokračování  Je-li null hodnota v klíči do dimenzionální tabulky – nahradit klíčem k speciálnímu záznamu v dimenzionální tabulce („Neuvedeno“)  Odvozená fakta je možné uložit fyzicky (jsou-li často přistupována, chceme index nad nimi) nebo vypočítáme až ve view

103 ETL Krok 8 – inkrementální načtení  Identifikovat co se stalo nového Nová transakce  Přidat záznam do fakt tabulky Update transakce  Změnit záznam ve fakt tabulce  Přidat změnový záznam Smazání transakce  Smazat záznam ve fakt tabulce

104 ETL Technika pro zajištění maximální dostupnosti DW Vhodná pro menší DW  Budou existovat 3 kopie faktové tabulky

105 ETL Load_fact_1 Active_fact_1 Dup_fact_1 From data staging 1. Load fact table Old_fact_1 2. Duplicate load_fact_1 3. Index 4. DW down 5. Rename Active_fact1 na old_fact_1 6. Rename load_fact_1 na Active_fact_1 8. Rename dup_fact_1 na load_fact_1 7. DW up 9. Drop old fact table

106 ETL Krok 9 – Agregace a OLAP  Agregace – někdy třeba rovněž vytvářet inkrementálně (full proces moc náročný časově)  Je-li agregován čas (z dnu např. na měsíce) volby: Nezahrnovat dosud neskončený měsíc Zahrnout – hodnota month-to-day (každý den se přepočítává)  OLAP – viz dále

107 ETL Krok 10 – automatizace  Načasovat jednotlivé kroky Lze na sebe jednotlivé kroky navázat (např. zápis do tabulky metadat, že už jeden proces skončil a druhý může začít, existence souboru, …)  Získat potřebná metadata Proces Start Konec Doba běhu Počet přesunutých řádků Status dokončení (úspěšně/neúspěšně) Diskové operace, CPU, … Viz Auditní dimenze u faktové tabulky

108 ETL Krok 10 – pokračování  Možný postup: Extrakce dimenzí a zápis metadat Extrakce faktů a zápis metadat Procesování dimenzí  Umělé klíče/SCD/….  Čištění dat, zápis metadata Procesování fakt  Umělé klíče, zápis nevyhovujících záznamů  Zápis nevyhovujících záznamů  Transformace dat Load dimenze Load fakta Agregace, OLAP Validace loadu proti metadatům Zaměň servery (pro 24 hod DW) Načti datové tržiště Aktualizuj metadata Zapiš metadata o loadu Otestuj správnost a úplnost loadu

109 ETL Hlavním problémem je kvalita zdrojových dat Obsáhlý problém (Data quality and cleaning) Kvalitní data  Přesnost  Kompletnost  Konzistence  Jedinečnost (stejné názvy pro atributy se stejnou informací)  Včasnost Kvalitní data – „pravda, jenom pravda a nic než pravda“

110 ETL Problémy v datech  Nekonsistentní používání kódů (Ano, true, T, …)  Jeden atribut uchovává více informací  Význam atributu záleží na hodnotě druhého atributu  Chybějící hodnoty  Duplicity  Chybné hodnoty  Překlepy OLTP systémy pro podporu transakcí  Aby doručili zboží  Kvalita dat není na prvním místě  Validace dat by mohla neúměrně zdržet zápis transakce  Problémy při ručním vkládání DW – přínos – ukazuje na kvalitu dat Pro zvýšení kvality potřeba získat podporu managementu

111 ETL – příklad transformace Kódování Měřítko Atributy appl A - balance appl B - bal appl C - currbal appl D - balcurr appl A - pipeline - cm appl B - pipeline - in appl C - pipeline - feet appl D - pipeline - yds appl A - m,f appl B - 1,0 appl C - x,y appl D - male, female Datový sklad

112 ETL Nejběžnějším problémem je integrace zákazníků  Standardizace jmen a adres  Householding – identifikace ekonomické jednotky  Existují specializované nástroje na tento problém Doporučení ke kvalitě dat  Je-li možnost (více potencionálních zdrojů dat) vybrat nejkvalitnější zdroj  Prozkoumat data – hledat možné problémy  Prezentuj nekvalitu dat managementu – nesmí dojít k názoru, že data jsou nekvalitní jen v DW  Spolupracuj s OLTP správci na odstranění chyb  Spolupracuj s uživateli na definici pravidel pro čištění dat  Využij specializované nástroje na čištění dat  Přenes odpovědnost za čištění dat na provozovatele OLTP (čisté extrakty pro DW) – je.li to možné

113 ETL Kontrola správnosti dat  Dotazy vůči provozním systémů Porovnání s DW Možnost automatizovat a ukládat do metadat  Ruční prohlídka Nejde-li testovat vůči provozním (např. informace v DW z více zdrojů) Hledat odchylky, možné chyby Spolupracovat s uživateli (experty)  Těžko kdy ale bude všechno pasovat se vším

114 ETL 0. vrstva  Často místo pro zálohy  Obsahuje detailní data  Je možné z nich rekonstruovat další vrstvy (?inkrementální load fakt a dimenzí?) Není třeba je zálohovat (data jejich, modely ano)  Může sloužit pro nové transformace (např. pro data mining) Potřeba kontrolovat dostupné místo na disku  Např. i místo přidělené pro růst databáze, zda nedojde k jeho vyčerpání během ETL – problém Někdy vhodné vytvořit speciální opravné pumpy

115 Praktický příklad 4 Tvorba modelu a naplnění 1. vrstvy  Využití DTS  SQL skripty Create Naplnění

116 Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

117 Uživatelské aplikace Důležitá část z hlediska „prodeje“ předchozího úsilí Vytvořit šablony (parametrizované) standardních reportů  Operativní  Taktické  Strategické Podpořit ad-hoc analýzu Podpořit plánování, stanovení rozpočtu, předpovědi, what-if analýzy  Čerpají data z DW a potřebují výsledky někam zapsat (často i verze)  Zápis do DW (vlastní faktová tabulka)

118 Uživatelské aplikace Potřeba využít flexibilních nástrojů, multidimenzionální pohled na data, data mining VerifikaceObjevování Jaký je průměrný prodej dle jednotlivých okresů? Jaké jsou nejlepší prediktory prodeje? Jaký je průměrný věk zákazníků? Co zapříčiňuje odchod zákazníka?

119 Uživatelské aplikace Potřeba zapojit uživatele Vhodné definovat počáteční množinu reportů co nejdříve po interview (sbírání uživatelských požadavků) Kroky:  1. Určení počáteční množiny reportů Vybrat 10 – 20 hlavních reportů Identifikovat kandidáty  Např. v excelu soupis reportů z interview, popis, řádku, sloupce, ukazatele, komu slouží  Ukázat uživatelům k doplnění Kategorizovat reporty  Výkonnost (prodej, podíl, hodnota)  Trendy  Odchylky, výjimky (Top n, odchylky od normálu)  Důvody odchylek  What-if  Dopady rozhodnutí, promocí, … Nastav priority  Identifikuj skupinu A (implementována v první fázi)  Skupina B – v druhé, skupina C – možná v třetí

120 Uživatelské aplikace Pozn: Je-li to možné nekopírovat původní reporty  Většinou nebudou přesně sedět čísla Potřeba dopředu vědět proč Uživatelé ztrácí důvěru v DW  Ukázat uživatelům něco nového

121 Uživatelské aplikace Kroky:  2. Určit strategii navigace Počet reportů bude rychle růst Potřeba najít způsob jejich uspořádání – přehledné pro uživatele  Podle obsahu, nebo dle oddělení, …

122 Uživatelské aplikace Welcome Sales volume report ForecastyingPricing analyst Inventory tracking To desktop application Market trend template Market topline template Produkt trend template Product topline template

123 Uživatelské aplikace Kroky  3. Vytvořit standardy tvorby reportů Dohodnout standardy pro tvorbu reportů Jmenné (jména reportů, atributů), formátovací (co v hlavičce – datum vytvoření, počet stran, zdroj dat, pro koho určeno), standardní zkratky – pro lepší uživatelskou orientaci Naplnit metadata těmito informacemi  4. Vytvořit reporty na detailní úrovni Vytvoř prvních 10 až 20 šablon reportů Dokumentace Metadata (popis reportů)  Název šablony  Popis  Frekvence plnění  Nastavitelné parametry  Default omezení (např. že je za aktuální rok)  Způsob výpočtu odvozených faktů  Poznámky Nechat zkontrolovat uživateli

124 Uživatelské aplikace Nasazení reportů Několik možností  Přístup přes Web Asi nejhodnější, možno rozšířit o přístup k metadatům  Speciální reportingové nástroje  Vlastní vývoj Načasovat plnění reportů  Nebo nechat vybrané on-line (např. pro zadání parametrů) Testovat reporty  Na různých strojích, různé dotazy  Porovnat s OLTP Rozdíly (jiná definice faktu, jinak počítá reportingový nástroj, správně v DW a špatně v OLTP – potřeba vysvětlit uživatelům) Podpora uživatelům – získat od nich zpětnou vazbu, zda jsou reporty bez chyb

125 Uživatelské aplikace V čase je třeba sledovat reporty  Přidávat nové  Aktualizovat staré (nové zdroje, změna stávajících)  Monitorovat výkonnost reportů (čas tvorby)  Sledovat využívání reportů Odstranit nepoužívané reporty

126 10. Přednáška

127 OLAP Popis – definice Způsoby uložení dat (MOLAP, ROLAP, HOLAP)  Výhody, použití Příklady výstupů Vypočítané ukazatele Bezpečnost na kosce Ukázka Analysis Services

128 OLAP SW technologie, která umožňuje analytikům a managerům získat informace z dat rychle, konzistentně a interaktivně za pomoci široké škály pohledů vytvořených z relačních dat a odrážejících pravou dimenzionalitu obchodního světa, kterou rozeznávají uživatelé. Bezpečnost Interaktivita Vizualizace Flexibilita OLAP

129 OLAP funkcionalita poskytuje dynamický multidimenzionální přístup k datům, analýzu dat a podporuje analytické a navigační aktivity OLAP funkcionalita je poskytována pomocí OLAP Serveru OLAP Server: Výkonný, víceuživatelský server vytvořený pro podporu a správu operací nad multidimenzionálními strukturami uložení dat

130 OLAP je FASMI Fast  Do 30 sekund (dle výzkumu v Holandsku)  Neovlivněno množstvím dat Analysis  Flexibilita (ad-hoc dotazy, vypočítané ukazatele)  Důraz na obchodní logiku Shared  Stejné výsledky pro všechny (konzistence dat)  Bezpečnost dat – oprávnění uživatelů Multidimensional  Základ analýz OLAP – dimenzionální modelování Information  Důraz na zpracování velkého objemu informací  Není důležité kolik GB bude potřeba

131 OLAP Multidimenzionální uložení dat – multidimenzionální databáze (krychle)  Uloženy data i agregace Produkt (druh) Čas (den) P U S Čt Pá S N Rohlík Zmrzlina Sýr Chleba Ostrava Brno Praha kusů chleba prodaného v Praze v pondělí Dimenze: Time, Product, Geography Hierarchie: Druh  Značka  … Den  Týden  Kvartál Město  Region  Země roll-up týden roll-up značka roll-up region

132 OLAP Druhy uložení OLAP:  MOLAP – Multi-dimensional OLAP Data i agregace uložení v multidimenzionální databází Rychlé, výkonné, pro menší objemy dat  ROLAP – Relational OLAP Data a agregace uloženy v relační databázi Pro velké objemy dat, rychle se měnící  HOLAP – Hybrid OLAP Kombinace MOLAP a ROLAP Agregace v multidimenzionální databázi, detailní data v relační Rychlé pro sumární informace, pomalejší pro detailní  DOLAP – Desktop OLAP Zjednodušená verze MOLAP nebo ROLAP

133 OLAP Možno definovat složité výpočty na úrovni OLAP databáze  Např. MDX jazyk – MS Analysis Services 2000

134 OLAP Výhody uložení dat v OLAP:  Rychlí přístup k datům  Uživatelský přívětivé Standardní rozhraní Drag and drop Vizualizace Příklad nástrojů  MS Analysis Server 2000  Oracle Discoverer  SAS Warehouse Administrator, SAS MDDB serverBusiness Warehouse (SAP)  Microstrategy  …

135 Praktický příklad 5 Vytvoření OLAP krychle  MS Analysis Services  Ukazatel: Prodej Kč, Prodej Ks  Dimenze: Zakaznik (Kraj – Mesto – Jmeno) Čas (Rok – Kvartal – Mesic – Den) Produkt (Kategorie – Subkategorie – Nazev) Dovozce (Nazev) Prodejce (Pobocka kraj – Mesto – Jmeno)  Prohlídka dat v MS Excel

136 Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

137 Nasazení Zkontrolovat připravenost (SW, HW) serveru a uživatelských stanic  Databázová konektivita, internet, přístup k databázi  SW instalovaný  Naplánovat nutné reinstalace, upgrade, …  Získat login pro jednotlivé uživatele  Test na různých stanicích Vytvořit strategii školení uživatelů  Důležité – aby uživatelé opravdu využívali DW  Seznámit s daty, jejich význammen, nástroji pro přístup k datům, metadaty  Customizované pro jednotlivé skupiny uživatelů dle jejich potřeb  Specializované kurzy pro pokročilé analytiky  Při prvním školení základy, ne se snažit jim říci vše, budou ještě další příležitosti

138 Nasazení Možné pro školení připravit speciální databázi s vzorkem dat  Rychlejší odpovědi, konzistentní přes více školení

139 Nasazení Body školení  Představení DW a projektu DW Web site Jak začít  Prohlídka dat Dimenze Fakta Jak je prohlížet  Uživatelské aplikace Předpřipravené reporty Jak se k nim dostat Jak je využívat  Další možnosti Tisk Export do Wordu, Excelu Manipulace s report – grafy, drill-down, …  Aplikace toho co se naučili na reálném příkladě  Diskuze

140 Nasazení Provádět školení, když už DW běží „bez chyb“  Jinak riziko, že uživatelé ztratí důvěru v DW, když ještě bude ve fázi plné chyb Nastavit politiku:“bez školení – DW není přístupný“  Zmenšit riziko rozčarování nad DW Nastavit strategii podpory uživatelů Umožnit uživatelům přístup k dokumentaci (DW, nástrojů pro přístup k datům) a metadatům  Vytvořit web portál datového skladu

141 Nasazení DW home page Fact of the month Warehouse community Learn about The warehouse Standard report A analysis What is new About the reports Customer services Sales activity Cool techniques Or analysis DW team DW discusion group User list And DW team contact Public status summary Conntact DW status Education and class schedule About data DW overview Data load status Call traccking Status inquiry Metadata browser

142 Nasazení Vlastní nasazení se může připodobnit k nasazení SW (verze)  Alfa verze DW Testovat technickou infrastrukturu, ETL, kvalitu dat, výkonnost, reporty, metadata Interaktivní proces odstraňování chyb Zapojen tým DW případně pokročilí business analyst  Beta verze DW přístupný malému počtu vybraných uživatelů  10 až 15  Musejí být flexibilní, motivovaní, dostupní  Zabere jim dost času – potřeba podpory jejich vedoucích  Budou pak pro uživatel zdrojem informací o DW Každá další etapa růstu DW by měla projít beta testováním  Finální verze Umožnit uživatelům přístup ve vlnách (po 10 až 15) – zvládnutelné lépe z hlediska podpory uživatelů

143 Nasazení Finální nasazení  Uživatel prošel školením a druhý den už může pracovat s DW Co je třeba zkontrolovat:  Desktop stanice Potřebný HW a SW Uživatel má přidělen přístup k DW  Kvalita dat Porovnány výstupy s OLTP Rozdíly vysvětleny, zdokumentovány a vysvětleny uživatelům  Otestovány uživatelské aplikace (a reporty)  Uživatel prošel školením  Je nastaven způsob podpory uživatelů (zaznamenávání problému a jejich řešení) Dokumentovat plán nasazení

144 Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

145 DW se stále se vyvíjející „organizmus“ Je třeba reagovat na změny požadavků, změny zdrojových systémů, … Správa DW – potřeba zajistit finanční fondy  Obecně bude potřeba na správu asi 50 procent zdrojů co na vývoj Není-li DW využíván je třeba zjistit příčiny  Business sponzor odešel z organizace, nebo už nepodporuje DW?  Naplňuje DW požadavky uživatelů?  Rozumí uživatelé dimensionálnímu modelu?  Prošli uživatelé školením?  Mají uživatelé podporu, vědí kam zavolat, jsou jejich problémy řešeny?  Neobsahují data chyby?  Jsou data dostupná včas (ve správné frekvenci)?  Je výkonnost DW dostatečná, není nutné příliš dlouho čekat na odezvu?  …

146 Správa a růst DW Jako v business  Je levnější si udržet stávajícího zákazníka DW než získat nového  Podporovat stávající zákazníky DW – zvyšovat jejich loajalitu k DW (budou o DW říkat ostatním) Důležité jsou první 2 týdny od nasazení  Uživatelé musí cítit podporu  Např. vyhlásit úřední hodiny pro dotazy na DW (uživatelé mohou přijít pro radu a kafe) Pokračovat ve školení  Pokročilá analýza  Refresh školení  Školení pro nové zaměstnance (pravidelně např. 1 za čtvrtletí)  Web stránky DW  Newsletter DW  Pravidelné semináře při kávě – řešit aktuální problémy, novinky, …

147 Správa a růst DW DW se stane kritickou aplikací pro firmu  Hlavní zdroj informací  Data musí být dostupná co nejdříve  Vysoké nároky na řízení DW Školení správců (nové trendy, nástroje, …) Monitorovat HW, SW, infrastrukturu  Síť, výkonnost, zaplnění disků, …  Ladění databáze (indexy, agregace, …) Upgrade nové technologie  Oddělit provozní a vývojové prostředí Změny provozních systémů  Změny ETL  Aktualizace metadat Modifikace provozních systému dle chyb zjištěných při loadu do DW Reakce na nové potřeby uživatelů (nové reporty, …)

148 Správa a růst DW Monitorovat a marketovat úspěch DW  Sledovat naplnění kritérií úspěchu DW  Sledovat Využití DW (počet login, doba strávená) Počet dotazů na podporu a čas potřebný na řešení  Zaznamenávat např. v DW (vlastní fakt tabulka)  Prezentovat managementu  Spočítat ROI Zaznamenat rozhodnutí učiněná po používání DW Část zisk přičíst na vrub DW

149 Správa a růst DW Marketovat DW  Oproti provozním systémům uživatelé DW nemusí používat Rozhodovali se bez informací před tím, řada z nich v tom chce pokračovat  Potřeba informovat o výhodách a úspěchu DW Např. „určit mluvčího DW“, který prezentuje DW  Udržovat komunikaci S business sponzorem Uživateli IS pracovníky DW týmem

150 Správa a růst DW DW se stále buduje  Na první etapu navazují další etapy  Jejich realizace opět dle popsané metodologie Využívá již nainstalované technologie a uživatelské nástroje Reviduje potřeby jejich upgrade nebo přidání nových Je vhodné ustanovit Řídící výbor DW  Složen ze zástupců IS a uživatelů S vlivem, s důvěrou v informační podporu rozhodování, s drivem k DW, s představou směrování celé firmy Rozhoduje o prioritách dalšího rozvoje DW, podstatných upgrade, financích na rozvoj Setkání přibližně jednou za čtvrtletí Ustanovit dokument strategie rozvoje DW

151 Správa a růst DW Řídící výbor  Je mu předložen k schválení seznam menších změn, jejich priority  Případně co bylo od minule uděláno za menší změny  Jsou mu předloženy návrhy na další etapy Provedeny pro ně hrubě studie proveditelnosti (čas, potřebné finance, …)

152 Gratuluji Právě jste dokončili tvorbu datového skladu a úspěšně jste ho nasadili!!!

153 Tipy a triky budování DW Potřeba získat podporu vedení Nejkritičtější je kvalita dat v provozních systémech  Dopad na náročnost ETL procesu Potřeba široké komunikace s uživateli  Učit práci s informacemi Začít jednoduchou aplikací – rychlí přínos výsledků  Proof-of-concept

154 11. Přednáška

155 Agenda CRM Analytické metody – Data Mining

156 CRM Existuje mnoho definic:  Zákaznicky orientovaná obchodní strategie umožněná současnou a vznikající technologií  Budování bližšího vztahu a poznání mezi zákazníkem a firmou  Zvyšování prodeje, loajality zákazníků, zefektivnění servisu pomocí znalosti zákazníka  CRM je koncept nebo manažerská disciplína zaměřená na to jak firma může zvýšit loajalitu svých nejziskovějších zákazníků za současného snížení nákladů a zvýšení zisku (Subbarathnam Swaminathan, CRM.Talk)  CRM se soustřeďuje na poskytování optimální hodnoty zákazníkovi – za pomoci komunikace se zákazníkem, způsobu prodeje zákazníkovi, servisem zákazníkovi jako i za pomoci tradičních prostředků jako jsou produkt, cena, promoce, způsob distribuce (Melinda Nycamp, Nycamp consulting group) Více

157 CRM CRM je a mnoho dalšího:  Firemní filozofie  SW, který implementuje marketingové, prodejní, servisní obchodní procesy  Velká řada aplikací  Způsob uspokojení zákaznických potřeb a očekávání Více

158 CRM 3 základní typy CRM interakce  Prodej – efektivní prodej, tvorba nabídek, znalostní systém, prodejní síť, forecasting  Marketing – zacílení na potencionální zákazníky, získání nových zákazníků, využití data miningu, campaign management, distribuční kanály  Servis – poprodejní podpora, call centum, www aplikace pro zákazníky Více

159 CRM CRM označuje zákaznicky orientovaný přístup k relevantnímu, nákladově efektivnímu a časově příhodnému prodeji zboží (služby) zákazníkovi a zaručující maximalizaci zisku firmy ZákazníkOrganizace

160 CRM Pouze 4% nespokojených zákazníků si stěžuje firmě Přes 90% nespokojených zákazníků se nevrátí Každý nespokojený zákazník to oznámí v průměru 9 známým Udržet zákazníka stojí v průměru pětinu až šestinu nákladů na získání nového zákazníka Spokojený zákazník je ochoten platit více Spokojený zákazník to oznámí v průměru 5 znaným

161 CRM Pravděpodobnost prodeje novému zákazníkovi je 15% zatímco stávajícímu 50% Firma může zvýšit zisk až o 85% udržením 5% zákazníků navíc Zákaznicky orientované firmy jsou o 60% ziskovější než tradiční firmy

162 CRM Source: Microstrategy IndividuálníJeden pro všechny Mass marketing One-to-one Marketingový přístup Produktový přístup

163 CRM Platba Dodávka Prodej Zpracování objednávky Podpora zákazníků Vedení Neosobní vztah Nekonzistentní pohled Slabá komunikace Stejné služby pro všechny Od: Izolovaný zákazník PodporaDodávka Lidské zdroje Prodej a marketing Výroba ŘeditelstvíFinance PodporaDodávka Lidské zdroje Prodej a marketing Výroba ŘeditelstvíFinance Důvěrný vztah Jednotný pohled na zákazn. Komunikace Služby dle hodnoty zakazn. Do: Zákaznická orientace

164 CRM Starý pohled: Supply Chain (ERP) Nový pohled: CRM

165 CRM Základní části řešení CRM  Collaborative CRM Front-end aplikace Zabezpečení kontaktu se zákazníkem Aktuální potřeby – Co se děje  Operativní CRM Operativní rozhodnutí Data pro Collaborative CRM Aktuální potřeby – Co se děje  Analytické CRM Proč se to děje? Back-end systém Získávání znalostí o zákaznících (Data Mining) Data pro operativní CRM Někdy označováno jako operativní CRM celé

166 CRM CRM aplikace Modely chování zákazníků Zákazníci Analýza zákazníků Vztah (CRM) Datový sklad Znalosti o zákaznících

167 CRM – loajalita zákazníka Nový zákazník Podpora stávajícího zákazníka Náklady Příjmy Loajální a spokojený zákazník Podpora prodeje cross-selling, up-selling, … Získání zákazníka

168 CRM Hodnota zákazníka (Life time value) Loajalita Cross selling Up selling Představ služby a produkty

169 CRM Marketing Prodej Podpora Operativní CRM Marketingové analýzy Prodejní analýzy Zákaznické analýzy Analytické CRM Web Call centrum Přímý prodej Collaborative CRM Plánování/Analýza Akce Zpětná vazba

170 CRM Analytické CRM Datový sklad MarketingProdejZákazníci ReportingOLAP Data Mining Segmentace Kampaně Churn (odchod zákazníka) Detekce podvodů Credit scoring Event Scheduling Predikce Plánování promocí Cross selling Operativní CRM Collaborative CRM

171 CRM Automatizace prodeje Předpovědi prodeje Hledání příležitostí Objednávkový Mgt. Náhrady, Slevový Mgt. Kategory Mgt. Prodej Marketingové předpovědi Kampaň Mgt. Event Mgt. Promoce Katalog Mgt. Marketingový mix Balíčky Marketing Předpověď potřeby podpory Průzkumy spokojenosti Zákaznická péče Reklamační řízení Náhrada zboží Call, web centrum Podpora Prodej Před prodejem Po prodeji Udržet zákazníkovu loajalitu Personifikace Zesílit zákazníkovu spokojenost ČasCRM úkol Řešení Analytické CRM Operativní CRM Collaborative CRM

172 CRM CRM DB Komunikace se zákazníkem Analytické CRM Operativní CRM Collaborative CRM Prodejny Fyzická Face-to-faceDirect mailCall centrum Telekomunikace SMSMobilWeb Internet Chat

173 CRM – kroky k úspěchu Celopodnikový konsenzus na vývoji a nasazení CRM řešení Vytvoření CRM projektového týmu Analýza obchodních potřeb Plán CRM aktivit Výběr CRM SW Výběr dodavatele Tvorba CRM aplikací a nasazení Údržba a růst CRM řešení Krok1 Krok2 Krok3 Krok4 Krok5 Krok6 Krok7 Krok8

174 CRM – začít v malém Datová architektura Cílení analýza zákazníků Využití kanálů - Mail - Call centrum - Web - Prodejní místa - … Fáze 2 Kampaně na podporu zákazníků Business processes reengineering Nákup CRM systému CRM orientace organizace Training CRM technologií Fáze 3 Prorůstání CRM v organizaci Dlouhodobé plánování Strategické řízení zákazníků Rozšíření systémů - Architektura - CRM Nové možnosti kanálů - Call centre - E-commerce Fáze 4 Dlouhodobé plánování CRM Vysoce ziskové kampaně Fáze 1 Současné obchodní problémy/příležitosti Optimální start: - Cross-selling - Churn - Direct mailing

175 CRM Úspěšné CRM stojí na pěti pilířích:  Strategie Zákazníci (cílový segment, potřeby, nároky, chování, zvyky,...) Trh (otevřenost trhu, velikost, růst, konkurence, …) Produkt (cena, balíčky, vlastnosti, …) Kanály distribuční (preference zákazníků, trendy, náklady, …) Zaměstnanci (schopnosti, znalosti, školení, motivace, …)  Informace DW, Householding, …  Funkcionalita Ohodnocení zákazníka Risk analýza Segmentace Modelování chování Cílený marketing (Campaign management)  Integrace Integrace kontaktu se zákazníkem a informací a analýz o zákazníkovi  Technologie Podpora funkcionality (reporting, DM, Statistika, …)

176 CRM – hodnota zákazníka Potencionální zákazník Nový zákazník Stávající zákazník Dřívější zákazník Cílový trh Nový zákazník Začátek vztahu Vysoká hodnota Vysoký potenciál Nízká hodnota Neřízený odchod Řízený odchod NáborAktivaceCRM management Zpětná vazba

177 CRM - metriky Kdo je náš zákazník?  Profilace  Demografie  “Firmografie” Jak se k němu můžeme dostat?  Segmentace Jak s námi zákazníci přicházejí do kontaktu ?  Face-to-face  Katalog  Direct mail  Internet

178 CRM - metriky Jaká je hodnota zákazníka pro firmu?  Ziskovost  Lifetime Value  Loajalita V jakém životním cyklu se zákazník nachází?  Počáteční fáze  Růst  Dospělost Jaké jsou zákazníkovy postoje? Jak se zákazník v čase mění?

179 CRM „Nábor“ zákazníků:  Jaké jsou charakteristiky dobrých zákazníků?  Na které potencionální zákazníky bych se měl zaměřit?  Jak mohu zvýšit odpovědi na promoce?  Jak mohu předpovědět, zda potencionální zákazník bude dobrý zákazník? Hodnota zákazníka v čase:  Jaká bude celoživotní hodnota zákazníka?  Cross marketing (Jaké další produkty mohu zákazníkovi prodat)? Retence a odchod zákazníků:  Kteří zákazníci pravděpodobně odejdou ke konkurenci?  Které zákazníky chci nechat odejít? Které zákazníky si chci udržet?

180 DM Analytické aplikace -> předávám slovo SPSS CR

181 Praktický příklad

182 Děkujeme za pozornost Ing. David Pirkl


Stáhnout ppt "Datové sklady a BI aplikace MFF – část 3 Duben 2004 Ing. David Pirkl."

Podobné prezentace


Reklamy Google