Üzleti Intelligencia Hírek, újdonságok és tesztek az üzleti intelligencia és az adattárházak világából

A BO, a QV és a poligámia

Egy új, izgalmas, aktuális problémába botlottam az elmúlt napokban, amit reményeim szerint még élvezetesebb lesz megoldani, mint egy zsák fehéregeret elengedni egy női fehérnemű boltban.
Van egy nagy cég, ahol már jó pár éve használnak BusinessObjects-et. Persze nem elég jól, mert senki nem úszhatja meg, hogy le ne szóljam, de vannak bejáratott felhasználási módok, univerzumok, az univerzumok alá fejlesztett - tervezett céltáblák, esetenként még adatpiacocskák is. A DWH adatbázis platformja persze a jó öreg Oracle, valami nagy, közös szerveren hostolt instance, talán még virtualizálva is van, közepesen vacak paraméterezéssel és olyan IO-val mint ahogy egy csípőprotézises tengeri sün futja a Cooper tesztet. Természetesen a hosting csapat / DBA-k a jó globális munkamegosztásnak megfelelően másik team, másik lokáció, kicsit sem érdekli őket, hogy DWH igények szerint optimalizálják az adott instance-okat, mert az csak több munkát, macerát és heterogén installációs bázist eredményezne, szóval az adattárházas fejlesztőktől jövő levelekre kreálnak is egy "whothef#ckcares" nevű új filtert, aztán mehet az Angrybird ebédszünetig.
Ha BI fejlesztő létedre normális válaszidőket akarsz, akkor meg jöhet a céltáblába töltés, kalkulált, aggregált metrikák és tábláik, töltéseik faragása dögivel. Emiatt vagy a fejlesztési ciklusokat, vagy a riport frissítési időket érzik a felhasználók kínosan hosszúnak, mint hasmenéses vőlegény az örömódát.
Bánatosak is mind a BI fejlesztők, reggelente morózusan ébrednek és utálkozva néznek a tükörbe: még egy nap amikor nézegethetem a homokórát rogyásig / csapágyasra izélgetnek a felhasználók, anyukám hetek óta csuklik, stb... A tehetetlenség frusztrációt, probléma tagadást, felelősség hárítást, workaround keresést szül, és a végén jön a sommás megállapítás: a BO lassú (egyébként most éppen nem lenne az, de a tradíció szerint a rossz hír hozóját kell fölkötni, tehát a homokórát megjelenítő BI eszköz lesz a bűnbak). És innen már csak egy lépés, hogy kipróbálják a neten valamelyik híresen gyors, menő, szexi új generációs BI eszközt, lenyomnak egy sikeres POC-ot QlikView-val, és jöhet a bevezetés, illetve...

Mert az jó, hogy pár dashboard-ot QV-vel valósítunk meg, mert azok szebbek, gyorsabbak lesznek, de a több száz, esetleg több ezer meglévő, operatív, vagy elemző riportunkat nem dobjuk ki úgy, mint egy emésztési fázisa végén járó házicicát.
OK, maradjon a BO az operatív riportolás eszköze, legyen az analyst-eknek WebIntelligence-ük, hogy szórakozzanak, és legyen a felsővezetőknek meg az egységsugarú felhasználóknak pár QV dashboardjuk, deal?
Hm, ez jó, de miből fog táplálkozni a szerencsétlen QV? A BO-s világ öröksége, hogy van sok előre kalkulált, aggregált metrikánk az adattárházban, sőt, jópár kódforgatást, szűrő feltételt, case-when logikát is belekódoltunk az adattárház rétegbe. Ettől még ugyan be tudja szipkázni a QV az elemi szintű adatokat,  de mi biztosítja, hogy a QV-s aggregációk, transzformációk nem csúsznak el a BO / Oracle transzformációkhoz képest? Ezentúl kétszer kell lefejleszteni, karbantartani a metrikákat, ha mind a BO-ban, mind QV-ben használni akarjuk azokat? Vagy erőszakoljuk meg a QV-t, hogy használja a már létező aggregált tábláinkat és lemondunk a QV-ben lévő jó gyors inMemory engine-ről és a flexibilitásról?
Nem is beszélve a QV asszociatív technológiájáról, ami egyező mező-név alapján összekapcsol nekünk mindent, ami a jelenlegi névkonvenciók alapján nem biztos, hogy jó lesz. Átnevezünk, load scriptekben átmeppelünk mezőket, vagy mi legyen?

A probléma filozofikusabb megfogalmazása: működik-e az európai kultúrkörben a poligámia? Értjük, hogy vannak előnyei a nagymellű szőkének, a sportos barnának és az okos vörösnek is, de hogyan tudnak úgy együtt élni, hogy mindegyiktől azt kapjuk, amiben ő a legjobb és az együtt lakás ne járjon tányér-röptetéses diplomáciai konfliktusok végeláthatatlan sorával?
Érdekes, feladat, nem?

A bejegyzés trackback címe:

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.