Existuje však mnoho důvodů, proč své řešení svěřit do rukou zkušených dodavatelů nabízejících vyšší přidanou hodnotu a reference. Takoví dodavatelé totiž mohou snížit nejen současné, ale hlavně budoucí náklady na rozvoj, zvýší efektivitu celého řešení, sníží nároky na jeho administraci, redukují čas potřebný k nasazení nebo případně minimalizují riziko skrytých chyb.
Je nutné říci, že byť se mluví o datových skladech jako o komoditě, kterou stačí jednou prodat, vyvinout a dodat a následně již nekonečně opakovaně přeprodávat dále, je to v naprosté většině případů velmi mylná představa. Každý projekt má svá specifika, používá jiné vstupy, logiku dat, klade jiné požadavky na výstupy. Na druhou stranu nemá šanci uspět projekt, který alespoň částečně komoditizován není, tedy nepoužívá ucelené části, které byly vyvinuty na předešlých projektech. Šanci uspět nemá proto, že v době snížených firemních rozpočtů, zvýšených požadavků na efektivitu dodávky a špatné referencovatelnosti takového projektu se stává příliš dlouhým, drahým a s nejistým výsledkem. Zákazníci sázejí na zkušenost a jistotu a pochopitelně nechtějí platit za vývoj nových řešení.
Existuje více způsobů, jak potřebné efektivity dodávky dosáhnout – vždy to závisí na několika proměnných daného projektu. Těmi hlavními jsou zejména byznysová orientace projektu a zvolená technologická platforma. Omezíme-li se pouze na projekt datového skladu, který je nutnou součástí komplexního řešení business intelligence každé firmy, pak jeden ze způsobů efektivizace dodávky představuje použití platformy pro rychlý rutinní vývoj ETL (načítacích datových pump) s vysokou spolehlivostí (nízkou chybovostí). Postupnou evolucí trhu vznikly tři hlavní proudy vývoje ETL:
1. Standardní ETL nástroje (Informatica PowerCenter, Oracle Data Integrator, Microsoft Integration Services, Ab Initio atd.)
Takové nástroje přinášejí úsporu hlavně v přesně definovaných dílčích úlohách, pro které jsou určeny. Typicky jde o „klikací“ nástroje, které jsou sice robustní, ale na druhou stranu se v nich velice složitě udržuje jednotná logika zpracování, nejsou příliš přehledné a mají vysoké nároky na údržbu (např. při změně na úrovni logiky mapování zdrojových atributů na cílové apod.)
2. Předpřipravená řešení (appliance, fast track – Teradata, Netezza, Greenplum, HP NeoView, Microsoft PDW atd…)
Jde o předpřipravená řešení zvolené technologie, operačního systému, hardwaru a datového úložiště. Výhod těchto řešení je mnoho: výkonnost, snížené nároky na administraci, vysoká dostupnost, jednoduchá škálovatelnost a vysoká time-to-value hodnota. Nevýhody ale existují také: nízká míra flexibility při zpracování ETL, obtížné řešení nestandardních problémů a vysoká závislost na dodavateli.
3. Kombinace standardních ETL nástrojů a proprietárních nadstaveb
Byť to tak trochu vypadá jako úskok stranou k nestandardu, evoluce přináší vznik jedné z nejefektivnějších metod, která dává zákazníkovi kombinaci benefitů standardních ETL nástrojů s předpřipraveným řešením. Partneři výrobců jednotlivých ETL nástrojů si postupně budují své vlastní proprietární řešení částečně využívající výhody a znalosti plynoucí z množství realizovaných projektů. Znalosti jsou v tomto případě interpretovány pomocí práce s byznysovými a technickými metadaty.
Výhoda spočívá v tom, že oproti předpřipravenému řešení je implementační partner schopen přizpůsobit chování ETL stroje tak, aby fungoval přesně podle specifických požadavků zákazníka. Vzhledem k malé všeobecné znalosti tohoto trendu a nízké informovanosti klientů se u něj chvíli zastavme. Účelem datového skladu je získat požadované informace ze zdroje, načíst je, ztransformovat a dále poskytovat uživatelům. Celý tento proces má jasně definovaný zdroj – datový prvek primárního systému a cíl – datový prvek datového skladu. Problematickým místem bývá transformace mezi těmito dvěma prvky. Uvážíme-li příklad, že datový sklad má nezřídka několik tisíc takových transformací, je na místě úvaha, jak tento proces učinit co nejefektivnějším, nejspolehlivějším (nejméně chybovým) a nejpřehlednějším.
Transformace může být i poměrně netriviálního charakteru a může mít několik kroků. Takovou netriviální transformací může být uniformní logika integrace několika zdrojových systémů (CRM, produktových katalogů, výrobních dat, záznamů o různých typech hovorů, sloučení konsolidovaných a nekonsolidovaných finančních dat apod). Několik kroků má kvůli víceúrovňovým validacím, byznys kontrolám a transformacím tak, aby bylo zajištěno, že se data načetla do cíle v požadované podobě a kvalitě. Komplexnost celé úlohy pak pramení z faktu, že každá firma má jinou podobu a kvalitu zdrojových dat, jiné požadavky na použití cílových dat, a tím i jiné transformace nutné k jejich doručení. Tento fakt tak do jisté míry určuje unikátnost kombinace každé implementace a omezení použití univerzálního řešení typu appliance. Na druhou stranu nechceme každý mapping, každou transformaci opakovaně ručně zadávat do ETL nástroje. Řešením je tedy použití nadstavby zvoleného ETL nástroje a databázového stroje, které přímo podle požadavků na jednotlivé druhy transformací a validací dokáže zajistit spolehlivou, bezchybnou a kvalitní extrakci (E), načtení (L) a transformaci (T). Zde se dostáváme do zajetí metadat, která jsou hlavním nositelem logiky nadstavby.
Metadata v našem pojetí znamenají kombinaci systémových a technických metadat, tj. informace o datovém zdroji, jeho entitách, prvcích entit, jejich datových typech, obsahu a vazbách na jiné prvky. Datovým úložištěm informací o datových prvcích bývá nejčastěji case nástroj nebo metadatabáze umístěná vedle relační datové databáze DWH. Nástrojem, který vytváří vlastní ETL kód, je pak buď add-in do case-nástroje, nebo sada rutin vytvářejících ETL kód nad databází. Zde se dostáváme ke klíčové odpovědi, proč je tento přístup efektivní metodou vývoje ETL. ETL framework má dodavatel připraven pro použití, má v něm několik předpřipravených transformací, obsahuje technické validační patterny a má v sobě zakomponovanou logiku možnosti byznysových kontrol. Vycházíme-li z např. z předpokladu, že daný projekt využije 70% předdefinovaných transformačních pravidel, 70% technických validačních patternů a 20?% byznysových kontrol, pak stačí pouze dodefinovat zbývající malou část pravidel do již existujícího frameworku. Dodefinice využívá dosavadní funkcionalitu a úsilí na implementaci dodatečných pravidel se v celkovém úsilí projektu projeví zanedbatelně. Kromě úsilí má tento přístup ještě mnoho dalších podstatných výhod, které jiné metody poskytují pouze zčásti nebo vůbec:
- Time-to-value vývoj přináší významnou úsporu v čase i investovaném úsilí
- Jednotné a přehledné úložiště informací o datových prvcích, jejich validacích a kontrolách, které může tvořit základ dokumentace ETL kódu pro technické i byznys uživatele
- Transparentní generovaný ETL kód, jehož logika je uniformní napříč DWH
- Změna transformačních pravidel, validací a kontrol se konzistentně projeví všude v celém DWH
- Provádění změn nepředstavuje zásah do černé skříňky, změna ETL pravidel je běžným požadavkem a uskuteční se na jednom nebo několika jednotkách či místech
- Testování a UAT – transformace jsou definovány na jednom místě, a tudíž fungují stejně napříč všemi ETL
Historie a zkušenosti konzultačních a dodavatelských firem dokazují, že uvedený přístup znamená krok správným směrem, a přibývají další projekty, ve kterých je proprietární nadstavba ETL nástroje používána. U velkých projektů to platí na 100?%. Pro zákazníka z toho plyne, že by měl o tomto přístupu vědět a ve svých RFP a po dodavatelích jej vyžadovat.
Autor působí jako BI senior konzultant ve společnosti Adastra.
PŘEDPLATNÉ
ČLÁNKY DO MAILU