- Časopis: Computerworld, 8/2007
- Název: Technologie pro data warehousing a data mining
- Autor: Lubomír Hanusek a Petr Máša, Adastra Corporation
- Klíčová slova: Data Warehousing, Data Mining, datový sklad, pokročilá analýza dat
Data warehousing a data mining jsou dnes běžně používanými pojmy ve většině velkých a středních institucí. Pojďme si objasnit, co všechno se pod těmito pojmy skrývá a proč firmy do těchto řešení investují nemalé prostředky.
Data warehousing tvoří spolu s Data Miningem páteř tzv. Business Inteligence řešení, jehož smysl je prozaický – poskytnout jeho uživatelům rychlou, přesnou a úplnou informaci o jejich klientech, zaměstnancích produktech, či hospodaření společnosti. Být informován znamená vědět kterým klientům máme nabídnout po telefonu úvěrovou kartu, u kterých klientů je vysoké riziko odchodu ke konkurenci, znát vývoj tržeb za posledních 30 dní v členění dle regionů a produktů, anebo také, jak se liší skutečný výkon společnosti od plánovaného. Mít informace také znamená znát na kliknutí myší detailní profil o každém klientovi, který se dovolá na call centrum. Získat cennou informaci však není až tak triviální, jak se může zdát.
Schéma architektury typického datového skladu
K hlavnímu zdroji informací patří jednak systémy přímo určené pro provoz firmy (ERP, SCM, CRM), jednak externí databáze (např. číselníky adres, obcí, telefonní seznamy, registry ekonomických subjektů, databáze neplatičů apod.). Tyto „generátory“ dat však většinou nejsou schopny požadovanou informaci uživatelům poskytnout a to hned z několika důvodů: rozšiřování o nové produkty, zavádění nových systémů, fůze a akvizice společností vede k tomu, že data jsou uložena na mnoha místech, platformách a odlišných strukturách i formátech; dalším problémem těchto dat je jejich kvalita, data na pobočkách či call centrech se pořizují ve stresu, a tedy nejsou úplná, obsahují chyby, překlepy či neplatné hodnoty; provozní systémy, které tvoří hlavní zdroj dat jsou navíc natolik vytížené svým provozem, že nějaké složité analýzy zde ani nepřipadají v úvahu. Ale i kdyby to možné bylo, data většinou nejsou uložena ve strukturách vhodných pro analýzy a obsahují často pouze aktuální stav bez historie. Primární systémy mají jediný cíl – zajistit operativu fungování firmy.
Získat agregovanou informaci pro zlepšení businessu tak znamená v první fázi převést data do vhodných struktur – datového skladu (DWH – data warehouse). Data warehouse není nic jiného než databáze, obsahující konsolidovaná data ze všech dostupných provozních systému a optimalizovaná nikoli pro rychlé zpracování transakcí, nýbrž pro reporting, analýzu a archivaci dat. Data z datového skladu se často stávají pro firmu natolik užitečná a provozně důležitá, že jeho omezení či vyřazení může znamenat ochromení chodu celé společnosti.
Datové pumpy – ETL
K převodu dat do datového skladu se využívají ETL (extraction, transformation, loading) nástroje. Ty jsou většinou součástí balíku zvolené databázové technologie. Lze ovšem zvolit i specializovaný nástroj. Jejich úkolem je vytáhnou v co nejkratší době – většinou bez jakýchkoli úprav – potřebná data ze zdrojových systémů („extraction“) a uložit je do dočasného úložiště (DSA, data staging area). Pak následuje fáze transformací („transformation“), během které dochází k nejpodstatnější části celého řešení – k čištění dat (doplnění chybějících hodnot, odstranění překlepů, převedení na shodné formáty, napárování na jednotné číselníky/dimenze), datové konsolidaci (unifikaci hlavních entit – zákazníci, zaměstnanci, dodavatelé, partneři, produkty apod.) a výpočtu agregací dle hlavních entit. K čištění se používají inteligentní nástroje obsahující typické vzorky nečistot a často napojené na externí číselníky jmen, adres, titulů atp. Teprve takto připravená data můžeme nahrát („loading“) do centrálního úložiště datového skladu. Tam by již data měla být čistá, úplná, konzistentní, historizovaná, konsolidovaná.
Datová tržiště – data marts
Další komponentu datových skladů tvoří datová tržiště (data marts). Jejich princip je obdobný jako v případě datových skladů. Rozdíl spočívá v tom, že jsou určeny pro pokrytí konkrétní problematiky daného okruhu uživatelů a jejich architektura je již většinou založená na tabulkách faktů (obsahující měřitelné údaje o prodejích, nákupech, aktivacích…) a tabulkách dimenzí (obsahující číselníky, podle kterých chceme výsledek analyzovat, např. region, produkt, období), což podstatně usnadňuje datovou analýzu. Datová tržiště obsahují rovněž spoustu odvozených a agregovaných atributů často používaných v daném oddělení. Výsledkem jsou pak datová tržiště pro oddělení marketingu, řízení rizik, HR, obchodu, anebo také pro účely dataminingu.
Při plnění datového skladu je většina jeho komponent nepřístupná. Proto se tento proces spouští v době nejnižšího provozu (o víkendu, v nočních hodinách). Dalším důvodem je rovněž požadavek na minimální zatížení provozních systémů.
Inmon vs. Kimball
V praxi existují dva přístupy k datovým skladům. Koncepce, s níž přišel Bill Inmon, obsahující dočasné úložiště, centrální úložiště a datová tržiště se říká třívrstvá architektura datového skladu. Jedná se o nejčistší řešení, které ovšem vyžaduje vyšší počáteční náklady na analýzu a relativně dlouhou dobu na úplnou realizaci (u velkých firem i několik let). Často se však setkáváme i s datovými sklady bez centrálního úložiště, kdy podstatu datového skladu tvoří pouze datová tržiště. Tzv. dvouvrstvou architekturu (koncept Ralfa Kimballa) volíme především tehdy, pokud je potřeba upřednostnit konkrétní oddělení či pobočku a dodat první výstupy datového skladu v relativně krátké době (v horizontu několika měsíců). Datový sklad se pak buduje postupně po jednotlivých datových tržištích a nejen výsledky, ale i finanční prostředky na vývoj jsou rozloženy v čase. Na druhé straně však nese tento přístup určitá rizika. Postupné budování datových tržišť může narazit na neřešitelný problém dodatečné integrace nových číselníků a celkové řešení pak může v určité fázi ztratit schopnost konsolidovaně interpretovat skutečnost. Toto řešení navíc vede k překrývání datových tržišť (jeden ukazatel se vyskytuje na více místech) a jakákoli změna ať již v transformacích, databázi či reportingu pak musí být bezchybně provedena ve všech instancích tohoto atributu, což sebou nese i vyšší náklady na vývoj i údržbu datového skladu.
ODS
Často se také vyskytuje potřeba pracovat sice s konsolidovanými, ale hlavně aktuálními daty s minimální dobou odezvy – např. na call centru, kdy potřebujeme u každého zákazníka znát aktuální profil, jeho aktivované či objednané produkty, zařazení do segmentu, poslaných marketingových nabídek. To vyžaduje další komponentu datového skladu – operativní datové úložiště (tzv. ODS, Operating Data Store). Pro účely maximální „operativnosti“ je operativní úložiště často napojeno na datové zdroje prostřednictvím EAI (enterprise application integration) platforem. Ty umožňují vzájemnou komunikaci mezi libovolnými dvěma aplikacemi v reálném čase a to bez nutnosti tyto dvě aplikace přímo vzájemně propojovat. Na rozdíl od ETL platforem, které zpracovávají události dávkově v předem stanoveném čase, EAI platformy reagují na jednotlivé události okamžitě.
OLAP
Data v datovém skladu jsou sice čistá, konsolidovaná, ale také často velmi objemná. Abychom byli schopni tato data efektivně analyzovat, často se ukládají do speciálních datových struktur typu OLAP (on-line analytical processing). Technologie OLAP nám dává možnost prohlížet údaje o nákupech, prodejích apod. v rozpadu podle libovolné dimenze či kombinací více dimenzí (čas a produkt) a na libovolném stupni agregaci (např. stát-region-okres-město-pobočka) a to v reálném čase bez nutnosti čekat na zdlouhavého procházení celé historie datového skladu. Tímto dostáváme do rukou výkonný analytický (a rovněž i reportovací) nástroj oblíbený zejména u manažerů. OLAP může být řešen tradiční cestou prostřednictvím klasických relačních databázových tabulek (tzv. ROLAP, relational OLAP), anebo s využitím technologie vícerozměrných datových krychlí (tzv. MOLAP, Multidimensional OLAP), popř. kombinací obou (tzv. HOLAP, hybrid OLAP).
Data mining pro pokročilé analýzy dat
Složitější vzorky chování, které již nejsme schopni prostřednictvím technologie OLAP detekovat, řešíme prostřednictvím technologií data miningu. Data mining se využívá zejména pro predikci (např. odhad budoucího chování klientů, tržeb, pohledávek), segmentaci (shlukování klientů s podobnými vlastnostmi) či pro popis dat. Mezi nejčastěji používané algoritmy predikce patří logistická či lineární regrese, metoda rozhodovacích stromů, neuronové sítě či v poslední době populární support vector machines. Ze shlukovacích algoritmům jsou to pak K-Means a EM clustering.
Výsledky z Data Miningu se zpětně propagují do datových tržišť, centrálního úložiště či přímo do provozních systému (např. CRM), odkud se dále využívají pro cílený marketing (prodej dalších produktů klientům s vysokou pravděpodobností nákupu), predikci odchodu zákazníků, kreditní skóring (rozhodnutí o schválení nebo zamítnutí žádosti o půjčku, případně předschvalování půjček), detekce pojistných podvodů apod. Data mining vyžaduje především rozsáhlou přípravu dat v podobě analytického datového tržiště a následné nasazení složitějších matematických algoritmů. Tyto zvýšené investice však mohou značně vylepšit nějaký business proces (např. cílení kampaní) a tím zvýšit zisk celé firmy. Data Mining, OLAP a nezapomeňme ani na reporting, patří mezi analytické komponenty BI řešení.
Konečně se dostáváme k samotným uživatelům. Ti mohou k takto připraveným datům a informacím přistupovat prostřednictvím celé řady klientských aplikací počínaje hojně využívaných tabulkových kalkulátorů napojených na OLAP kostky, přes speciální OLAP prohlížeče či reportovací nástroje, až po manažerské EIS či MIS systémy (Executive/Manager information systems) poskytující on-line přístup k relevantním informacím v účinné a přehledné formě. Mezi klientské nástroje patří rovněž aplikace pro Campaign Management (řízení marketingových kampaní), CRM aplikace (komunikace s klientem), nástroje pro plánování apod. Nezapomeňme, že data z datového skladu můžeme prohlížet i prostřednictvím standardního SQL.