SAS Slovakia Newsletter / Tipy a triky

Potrebujete dátový sklad, ale nemáte rozpočet na jeho stavbu? 

Alebo ako navrhnúť dátový sklad pre zdravotnú poistovňu počas dodania BI projektov

Steve Morton, anglický konzultant a zakladateľ spoločnosti Applied System Knowledge Ltd. pripravil pre SAS Global Forum 2010 príspevok, v ktorom ponúka "lessons learned" pri pripravovaní dát pre BI a ako popri tom vytvoriť vlastnú dátovú architektúru/warehouse. Zákazníkom je britská zdravotná poisťovňa, ktorej organický rast spôsobil, že mali viacero menších data martov, ktorých údržba by v dlhšom horizonte bola neudržateľná. Z pohľadu IT by bol ideálny jeden spoločný centrálny dátový sklad, z ktorého by mohol SAS čerpať všetky potrebné dáta, najmä na využitie SAS BI servera. Avšak cena za vytvorenie takého skladu bola pre vedenie príliš vysoká.

Preto prišiel na rad Plán B, a teda pracovať na dátovom sklade postupne, počas prác na BI Serveri, čo znamenalo omnoho menší tlak na rozpočet. Začalo sa v januári 2008. Snaha bola o opakovateľnú integráciu dát – recyklovanú zdieľanú vrstvu (reusable shared content layer), v najhoršom prípade len taktickú integračnú vrstvu raz nahraditeľnú  plánovaným dátovým skladom. 

Základom bola podpora pre túto ideu u vedenia spoločnosti a databázových administrátorov transakčných dát. Bolo potrebné zákazníkovi zdôrazniť, že nešlo o snahu konkurovať plánovanému veľkému dátovému skladu. Samozrejme rizikovým prvkom bol nedostatok zdrojov na komplexné riešenie, ktoré by plne analyzovalo dátové a biznis vzťahy. Tím zložený zo SAS konzultantov musel z konkrétnych projektových zadaní odvodiť širší kontext dát, ktoré plánoval využiť neskôr. Pomohla aj existencia starších datamartov.

Technologicky išlo o samostatný Enterprise Data Integration Server a Enterprise Bussines Inteligence Server, oba na Windows 2003. Na desktopoch Dataflux dfpower Studio. Datamarty v kompresovaných datasetoch. Biznis používatelia pristupovali k dátam hlavne cez ID Portal a niekoľko expertov malo aj SAS Enterprise Guide.  Zdrojové databázové systémy Siebel nad Oracle a DB2 na Unixe, niekoľko legacy IBM Mainframes s DB2. Použitý bol CA AllFusion ERwin Data Modeler (integrovateľný so SASom).

1. krok: Vytvorenie tzv. Obláčikového diagramu - vecí ktoré by mohli postupom času zaujímať používateľov. (obrázok č. 1 v článku)

2. krok: Výstup z kroku 1 bol Subject data model (krabice - boxes) s ponechanými obláčikmi. (obrázok č. 2 v článku)

3. krok: Vytvorenie BI vrstiev – väčšina používateľov pristupuje cez OLAP kocky, niekoľko používateľov môže pristupovať aj priamo na tabuľky. (obrázok č. 3 v článku)

Výsledok bola prvá verzia Modelu. Počas projektu však došlo samozrejme k zmenám a rozširovaniu a nasledovalo viacero verzií modelov (viac v článku). Postupne bolo možné čerpať z predošlých krokov, ktoré tým, že mali širší záber, ušetrili prácu v neskorších fázach.  V januári 2010 bola hotová verzia 6 Modelu (obrázok 6) a zákazník označil postup projektov krok za krokom za vyhovujúcejší ako jednorazový veľký plán, z hľadiska implementácie aj financovania.

Čo fungovalo:

  • flexibilita pri používaniu dimenzionálneho a normalizovaného modelovania pri dizajne umožnila ľahšie rozširovanie. Akceptovali sme malú mieru redundancie, ako cenu za zníženie nutnosti prepracovávať veci,
  • efektivita nášho BI warehouse, denné updates,
  • pri nových požiadavkách je možné často použiť už predpripravené dátové zdroje,
  • subject model diagram (krabice a obláčiky) bol veľmi efektívny pri prezentácií postupu vedeniu a novým používateľom.

Čo sme sa naučili:

pozitívne:

  • postupný – inkrementálny dizajn funguje, ak je podporený skúsenosťami, prístupom k dobrým informáciám o zdrojových systémoch a dátach,
  • kombinácia skúsených ľudí, ktorí poznajú systémy s novými konzultantami,
  • je potrebné, aby databázoví administrátori zdrojových systémov pochopili, čo sa SAS snaží robiť. Vedie to k omnoho lepšej spolupráci.

varovné:

  • SAS team by mal byť  informovaný o zmenách v databázovom systéme aby sa mohol pripraviť,
  • zmena v zdrojových systémoch je problematická, ak sú involvovaný externý konzultanti a dochádza k časovému sklzu,
  • Databázové test dáta niesu vždy vhodné ako BI test dáta.  Je odporúčané mať prístup na databázu počas UAT testov BI.

Čo by sme robili inak:

  • získať čo najskôr biznis analytika, schopného analyzovať data subjects (krabice) nie len biznis požiadavky,
  • prvý BI projekt postavte nad stabilnými dátami, vyhnite sa zmenám zdrojových databáz pri prvom projekte,
  • zabezpečte si prístup k dostatočným UAT verziám hlavných databáz, ako test cases pre BI na prehĺbenie vašej znalosti dát.

Záver:  Postupný – inkrementálny dizajn BI data warehouse je praktické riešenie rozpočtových problémov, ak vedenie akceptuje určitú mieru uprav v neskorších fázach. Je možné minimalizovať riziko dobrým dizajnom. Riziko bude najnižšie ak bude použitý skutočne subjektovo orientovaný prístup, kde je možné každé nové dáta analyzovať a začleniť. Na toto je potrebná podpora biznis analytikov, administrátorov zdrojových systémov a manažérov vývoja.

Z anglického originálu preložil a skrátil, Jozef Kordík, Technical Support Consultant