Adjuk-e historikus stage-et a felhasználóknak?


Most vagyunk túl egy kísérleten, ahol azt vizsgáltuk, hogy pusztán a forrásrendszer tábláinak szabványos interfészen történő átadása (historizált stage formájában) elegendő-e az üzleti felhasználóknak ahhoz, hogy abból önállóan, IT támogatás nélkül legyenek képesek önkiszolgáló BI rendszereket építeni.

Másképpen fogalmazva: Építettünk egy historizált adatbázist ahová összelapátoltuk a forrásrendszerek azon tábláit, amelyeket a felhasználók a riportjaikhoz használnak és azt vizsgáltuk, hogyan tudnak ebből önkiszolgáló BI eszközökkel dolgozni. Megj.: A historikus stage-et nem nekik építettük, de kíváncsiak voltunk arra, hogy meddig tudnak vele eljutni. Mire tudnák használni; a data lake + önkiszolgáló BI koncepció mennyire működne a vállalatnál, egy kétsebességes adattárház architekúra kialakítása során hol húzhatjuk majd meg a felelősségi határokat, stb.

A hipotézisünk az volt, hogy nagy segítség lesz ez azoknak a feketeöves felhasználóknak, akik ma is a forrásrendszerekből vagy azok extraktumaiból riportálnak, hiszen

  • így kapnak egy historikus forrást, ahonnan tetszőleges időpontra le tudják kérdezni a forrástáblák adatait (A forrásrendszerekből ma ezt nem tudják megcsinálni, mert a forrásrendszerek nem tárolják a históriát)
  • Így akkor kérdezhetik le az adatokat amikor csak akarják (nem a forrásrendszereket terhelik)
  • Így könnyebben össze tudják kapcsolni a különböző rendszerek tábláit. (Egy adatbázis kezelőben van minden adat, az önkiszolgáló BI eszközök tudnak szerveroldalon join-olni)
  • Így teljesítjük azt az álmukat, hogy mindenféle transzformációtól és módosítástól mentes, nyers adatokkal dolgozhatnak 😊.
  • és biztosítható legyen a forrásrendszeri adatok sor/oszlop szintű jogosultság kezelése

Jöjjenek a tapasztalatok

  • Nagyon örültek a felhasználók annak, hogy végre van egy forrás ahonnan le lehet kérdezni a forrástáblák tartalmát tetszőleges időpontra, de nem/nagyon nehezen tudtak ebből historizált forrásból dolgozni. Egész egyszerűen túl bonyolult volt nekik a két idősík (Ahogy történt, ahogy most láttam)
  • Nem tudtak belőle pillanatfelvételeket készíteni, nem tudtak belőle időben nem aggregálható mutatókat számolni. Addig remekül ment minden, amig csak tranzakciókat kellett összeadni, de egy adott időpont állapotát lekérdezni, állapotokat idősorosan összehasonlítani már nem tudták
  • 2 vagy több rendszer adatait addig tudták csak integrálni egymással, amíg az integráció egyszerű szótártáblákkal megvalósítható volt. Ennél magasabb szintre önerőből, a napi munka mellett nem tudtak lépni.
  • A válaszidők – köszönhetően a forrásrendszeri szerkezetnek – sokszor pocsékok voltak

Összeségében arra jutottunk, hogy bár szakterület BI fejlesztők, a data scientist-ek, az adattárházasok imádják, az adatrambók el-elboldogultak vele, de az SQL-ben alig-alig jártas elemzők/kontrollerek nagyon nehezen tudtak belőle dolgozni. Nincsenek csodák, az új technológiák és a közös adatbázis még nem oldja meg minden problémájukat...

Tudjon meg többet az itt elhangzottakról és jöjjön el a 2018. április 17.-i BI és adattárház projektvezető képzésre. Részletek >>

  

ÖNKISZOLGÁLÓ BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2018. február 27.-i Önkiszolgáló BI workshopra. Részletek >>

  

Elválasztó

Már készül a következő cikk. Kérjen értesítést a megjelenéséről itt.

|

Szóljon hozzá!

Szabály: Legyen kedves, segítõkész és vállalja a nevét.
A mező tartalma nem nyilvános.
  • A web és email címek automatikusan linkekké alakulnak.
  • Engedélyezett HTML elemek: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • A sorokat és bekezdéseket automatikusan felismeri a rendszer.
ANTI SPAM
A robot regisztrációk elkerülésére.
Image CAPTCHA
Figyeljen a kis és nagybetűk használatára

Tudjon meg többet az itt elhangzottakról és jöjjön el a 2018. április 17.-i BI és adattárház projektvezető képzésre. Részletek >>