ABC od podataka do informacije, dio prvi

Poslovna analitika

ABC od podataka do informacije, dio prvi

U zadnjih nekoliko godina Business Itelligence  područje u svijetu je jedno od najinteresantnijih područja implementacije informacijskih sustava u kojem se obrću goleme količine zelembaća… U Hrvatskoj je BI još uvijek (na žalost) za širi krug korisnika Terra incognita i u ovoj dvodjelnoj kolumni ćemo se orjentirati na tehničko-tehnološki framework – kroz case study zamišljenog BI projekta vidjeti što sve na putu od podatka do informacije treba napraviti.  Naravno, u cijeloj BI priči, najprije valja postaviti pitanje…

Zašto, Why, Warum, Per Que?

Pojam Business Intelligence postojao je i mnogo ranije – to smo nazivali “poslovnom špijunažom”. Sve je to počelo 1992. godine kad je “kum” skladištenja podataka Bill Innmon definirao skladište podataka kao skup subjektno orjentiranih, integriranih, vremenski ovisnih i  nepromjenjivih podataka za podršku poslovnom odlučivanju. Razlog zbog kojeg je cijeli koncept nastao je rasterećenje transakcijskih sustava (famoznih ERP-ova) od upita za koje oni nisu optimirani poput onih koji sumariziraju milione slogova iz više tablica s više uvjeta u nekoliko brojki zanimljivih rukovoditeljima. Zbog toga se podaci iz transakcijskih aplikacija u regularnim vremenskim intervalima prebacuju u drugi sustav optimiran za takve upite za potrebe izvještavanja i analize. I nakon toga je uslijedio pravi boom – ljudi su shvatili da se u tim podacima krije pravo blago za analizu različitih uzoraka u podacima (a i tehnologija je to mogla omogućiti), koji, ako se pravilno analiziraju i protumače, mogu donijeti kompaniji veliku kompetitivnu prednost na tržištu i financijsku korist. Nakon nekoliko godina, sve te tehnologije za analizu svih internih i eksternih informacija iz poslovnog okruženja su zajedničku kapu našle pod pojmom Busineness Intelligence, odnosno u zadnje vrijeme e-Intelligence pod utjecajem Internet revolucije…

Naš case study biti će izrada sustava za podršku poslovnom odlučivanju koji će pokriti sve potrebe kompanije za izvještavanjem, analizom, predviđanjima i planiranjem. Postoje tri stvari koje moraju biti postavljene na svoje mjesto prije početka – svaki BI projekt mora zadovoljiti barem tri osnovna uvjeta koji će mu osigurati uspješnost (naravno, ima toga još, ali ovo su ipak osnove):

  1. mora imati jasno definirane ciljeve – ako to nije slučaj, projekt će se jednostavno rasplinuti jer nitko neće shvaćati što i zašto se radi
  2. mora biti vođen od poslovne strane i imati podršku top rukovodstva – u suprotnom će biti smatran još jednim hirom IT-a
  3. mora imati osigurano odgovarajuće financiranje – takvi projekti i njima pripadajuće tehnologije su još uvijek vrlo skupe…

Projekt ima slijedeće ciljeve – omogućiti transparentno izvještavanje o prodaji u cijeloj organizaciji u skladu s ovlaštenjima, analizu podataka iz prodaje i o kupcima, predviđanje prodaje u slijedećem razdoblju i na temelju predviđanja planiranje, budžetiranje i praćenje izvršenja plana. Radi mira u kući analizu podataka s web-sitea ostavljamo za drugu fazu projekta i zanemariti ćemo dijelove projekta vezane uz definiciju izvještajnih potreba, te se koncentrirati na tehnologiju u pozadini…

Svako skladište svoju bazu ima…

Kao prvi korak, treba odabrati platformu na kojoj će se sve odvijati – to mora biti kvalitetan i pouzdan DBMS, budući da će u svakoj srednjoj ili većoj organizaciji skladište podataka koje služi kao podloga svemu što slijedi vrlo brzo narasti na desetke ili stotine Gigabajta… Najjednostavnije je da to bude DBMS koji već koristite, budući da ga već ionako imate licenciranog i ne trebate ga kupovati. Tu naravno ima iznimaka – mainframe platforme nisu baš pogodne za takve projekte jer zahtijevaju velike memorijske i diskovne resurse (skupo…), pa se skladišta uglavnom baziraju na DBMS-ovima na Unix i Windows platformama. Postoje DBMS-ovi napravljeni isključivo za skladištenje podataka – najpoznatiji su NCR-ov Teradata i Redbrick, sada u vlasništvu Informixa (odnosno IBM-a) – koji omogućavaju razne zgodne i funkcionalne stvari poput kreiranja agregacija prilikom učitavanja podataka, te razne načine indeksiranja podataka radi bržih operacija nad podacima u skladištu. U zadnjih nekoliko godina i vodeći RDBMS sustavi na tom polju daju izvrsne rezultate (OracleInformixDB2 i SQL server), a svaki ima svoje prednosti u odnosu na konkurente i čvrsto drži svoju tržišnu poziciju. U svakom slučaju, na rasprave o prednostima i vrlinama svake od solucija potrošeno je jako puno tinte, te ćemo se time detaljno pozabaviti drugom prilikom – za sada je dovoljno da znamo da je platforma odabrana i da možemo krenuti dalje.

Projektiranje i optimizacija skladišta podataka

Slijedeće pitanje je koje podatke uopće trebamo u skladištu? Nakratko uzmamo definicije izvještajnih potreba i definiramo podatke koje ćemo iz transakcijskih podataka učitati u skladište. Naravno, ti podaci su u trećoj normalnoj formi, kako svaka dobar ERP sustav nalaže – takvu formu na žalost skladište najčešće ne poznaje iz jednostavnog razloga što ne bi radilo brzo kad se postavi upit na nekoliko (stotina) milijuna slogova. Dakle, prilikom učitavanja podataka radi se denormalizacija i u podacima se pojavljuje određena količina redundancije, što ionako nije bitno ako se sjetimo nepromjenjivosti iz inicijalne definicije – podaci se kreiraju i  mijenjaju u ERP-u, a u skladište se samo pune… Dva osnovna oblika tablica koja se pojavljuju u skladištu su fact table ili činjenična tablica i dimension table ili dimenzijska tablica. U činjeničnoj tablici nalaze se podaci koje želimo analizirati (na primjer, tablica prodaje), dok se u dimenzijskim tablicama nalaze podaci po kojima analizirane podatke želimo grupirati (na primjer, tablica prodavaonica, tablica artikala i tablica vremenskih razdoblja). Ove dvije vrste tablica mogu se organizirati u dvije osnovne strukture – prva i jednostavnija je star schema ili zvjezdasta shema u kojoj su sve dimenzijske tablice primary key – foreign key vezom vezane na činjeničnu tablicu (puno redundancije), dok je druga i općenitija snowflake schema ili pahuljičasta shema u kojoj dimenzijske tablice imaju i međusobne veze i hijerarhije (manje redundancije).

Koliko god cijena računala padala, skladištenje podataka je strašno zahtjevan hobi – probajte zamisliti skladište od 200 GB podataka i fact table s 150 milona slogova s podacima iz maloprodaje i tri dimenzijske tablice – vrijeme, prodavaonice i artikli. Korisnik postavlja upit u kojem želi detaljne podatke za tekuću godinu za grupu artikala i za prodavaonice u Karlovcu – to je join četiri tablice s tri where filtera… Naravno, svaki rezultat koji stiže nakon više od 30 sekundi je ravan katastrofi, a to je tek jedan od 250 korisnika sustava… Postoji nekoliko načina da se takvi upiti izvode brzo – jedan je naravno moćni n-procesorski stroj s 16 GB RAM-a, a drugi je optimizacija. Mnogo je načina na koji se sustav može optimirati i fino tunirati, ali najbitnija rješenja nalaze se na početku – treba pažljivo definirati podatke koji ulaze u skladište (sve što je u skladištu a ne koristi se je bespotreban overhead koji samo troši resurse), zatim tablicama treba pažljivo odabrati i kreirati indekse, definirati i kreirati potrebne agregacije, te definirati odnose među tablicama i odabrati prikladnu shemu odnosa. Najsigurniji rezultat daje metoda pokušaja i mjerenja vremena odziva. Ako imate OLAP server i kažete da optimizacija skladišta nije ni toliko bitna – varate se, i kreiranje OLAP kocke često koristi brzinu indeksiranih tablica i znatno skraćuje noćne obrade, a vrlo često korisnici traže i mogućnost drill-trougha do granularnih podataka.

Kad je sustav u funkciji, vrlo je važno mjeriti korištenost pojedinih dijelova, kako bi se mogle dodati agregacije koje se često traže a nisu prethodno kreirane ili kako bi se podaci koji se rijetko traže mogli prebaciti na jeftiniji i sporiji medij. Morate voditi i evidenciju o tome tko koliko koristi sustav i da li postoje pokušaji neovlaštenog pristupa.

Nakon definiranja potrebnih podataka, agregacija i strukture skladišta treba napraviti inicijalno učitavanje.

A tko će sve to napuniti i počistiti?

Skladište zahtijeva initial load ili inicijalno punjenje s postojećim historijskim podacima – ono se naravno radi odmah nakon definicije strukture i traje relativno dugo. Podaci koji se učitavaju u skladište u pravilu dolaze iz nekoliko različitih sustava s različitih platformi, te se učitavaju preko različitih sučelja, bilo native drivera ili putem ODBC-a. Kad je skladište u funkciji, podaci u njemu se u redovnim vremenskim razmacima – dnevno, tjedno ili mjesečno – moraju nadopunjavati ili osvježavati, što se naiva incremental load. U tu svrhu pišu se procedure za učitavanje koje su praktično uvijek automatizirane i schedulirane u noćno doba, kako bi podaci uvijek bili svježi. Naravno, nakon svakog osvježavanja i agregacije u skladištu moraju se obnoviti, što može trajati i po nekoliko sati…

Koliko u ERP sustavu ima artikala koji nemaju definiranog dobavljača, koliko ima kupaca s upisamim krivim imenom ili adresom, koliko je krivih knjiženja? Takvi problemi rješavaju se također prilikom učitavanja na nekoliko načina – ili se ignoriraju (najlošije), ili se automatski korigiraju (bolje) ili se identificiraju, odvajaju, ispravljaju u ERP-u i ispravni učitavaju u slijedećoj iteraciji (najbolje). Međutim, s kontrolom kvalitete podataka procedure učitavanja postaju složene i međuzavisne i prijete da se otrgnu kontroli. Rješenje se zove Extraction, Transformation and Loading Tool (ETL) – specijalizirana grupa alata koji služe automatiziranju procedura za ekstrakciju, transformaciju i čiščenje podataka, te punjenje istih u skladište. Često su to vrlo skupe, moćne i sofisticirane platforme, od kojih su najpoznatije Ardent DataStage i Informatica, ali također postoje i jeftinije i jednostavnije solucije – no to je ponovo zasebna tema o kojoj se može dugo raspravljati.

Nakon što smo odabrali ETL tool, uspješno ga implemetirali i riješili problem brzog učitavanja i kvalitete podataka, problem na kojem su se mnogi prije njega spotakli i na kojem je mnogi BI projekt pokleknuo, te se sada našli pred slijedećim pitanjem – OK, podaci su u skladištu, a što sad? Moramo ih nekako iskoristiti… Tko će imati pristup kojim podacima? Što će tko s podacima raditi? Kako ćemo informacije distribuirati? Na sva ta pitanja ćemo pokušati odgovoriti u drugom dijelu kolumne za mjesec dana… (D.O.)