Jelen cikksorozatunk elsődleges célja, hogy napjaink adattárházkörnyéki, főbb szakmai, vezetési, szervezési nehézségeit taglalja, ill. mankót nyújtson azon adattárházas vezetők számára, akik szeretnék a napi munkájuk hatását, döntésük következményeit stratégiai távlatból szemlélni. 

Fontos, hogy a menedzsmentszintű döntések hatását szervezői, fejlesztői szempontból is átlássuk és fordítva: a fejlesztők kódolási konvencióinak, a fejlesztői szabályzat hiányosságainak, be nem tartásának későbbi-, menedzsmentdöntéseken érezhető hatását is szükséges vizsgálni.

Jelen cikkünket azon adattárházas szakmai vezetőknek szánjuk elsősorban, akik 

◼︎ utat keresnek valahol a fejlesztők és magas szintű IT vezetők közötti szakmai-, szakpolitikai erőtérben,

◼︎ valós tartalommal szeretnék feltölteni a sokszor unalomig ismételgetett Data Governance kifejezést,

◼︎ szakmai eszköztárukat szeretnék bővíteni egyfajta adattárházakat is érintő stratégiai szemléletmóddal

azzal a céllal, hogy az adattárházba betöltött adat hosszú távon is fenntartható üzleti érték legyen.

 

Fejlesztési sztenderdek

Amikor egy nagyvállalat adattárház bevezetése mellett dönt, az jellemzően valamilyen stratégiai döntés következménye. Egy adattárház központi bevezetése 10-20 éves távlatban képes jelentősen befolyásolni egy szervezet Data Governance stratégiáját, belső IT környezetet, tehát fontos, hogy az adattárházunk hosszú távon is stabil lábakon nyugodjon, megőrizve a menedzsment stratégiai elköteleződését. Ennek egyik eleme, hogy olyan fejlesztési sztenderdeket alakítunk ki szakmai vezetési, architekti és vezető fejlesztői körben, melyek alapjaiban keretezik a fejlesztők és szervezők technológiai és szervezési feltételeit. 

Új adattárház bevezetésekor könnyen lehet olyan érzésünk, hogy ezen szabályzatok, fejlesztési irányelvek részletes kidolgozása, a fejlesztési folyamat kontrollja aránytalanul sok idővel és látszólag kevés eredménnyel járnak. Gondoljunk arra, hogy ezt a munkát kizárólag zöldmezősen érdemes végezni, „kétszer mérj, egyszer vágj” szemléletmóddal. Ne feledjük: döntésünk akár 10-20 éves távra is kihathat meghatározva az adattárházas szakemberek munkáját, ezáltal jelentős hatást gyakorolva adattárházunk megítélésében a társrendszerek irányából. 

Jelen cikkben nem térünk ki a szállítók részéről gyakran dobozos termékként pozícionált adattárházakra (pl.: SAP BW), mivel ezek piaci penetrációja Magyarországon alacsony.

Nézzünk néhány példát:

 

Standardizált betöltők

Ezek olyan jól specifikált és verziókövetett eljárások, melyek alapvető szerepet tölthetnek be adattárházas ETL folyamatainkban. Standardizált betöltő eljárásaink használata kötelező érvényű minden fejlesztő számára, ettől eltérni adattárházunk maximum korai életciklusában indokolt. Ezek működési alapelvei minden pénzintézetnél nagyjából ugyanazok. Azon szervezeteknél, ahol a fejlesztők előre megírt és letesztelt, univerzálisan hívható táblatöltési eljárásokat használnak, ott jelentősen csökken a hiba bekövetkezési valószínűsége, illetve a technikai mezők töltési logikája és ezek neve is előre definiált. Természetesen valamilyen szintű sztenderdizálás a fejlesztői, vagy integrációs keretrendszerekben (ODI) fejlesztett/paraméterezett ETL folyamatokban is lehetséges és szükséges.

Ezen eljárásokat célszerű lehet külön a Stage, DW, DM szinten létrehozni, hiszen így séma szinten, fizikailag is kikényszeríthető, hogy adott eljárás csak az adott adattárházas szegmenst érje el. Ezzel a fejlesztők ésszerűtlen innovációs ötletei, esetleg más szakterületi vezetők nyomásgyakorlása is csökkenthető a belső szabályzatunkra való hivatkozással. Rövid távon ez egy olyan vállalható rugalmatlansággal jár, mely hosszú távon élét veszi a „kivétel erősíti a szabályt” tévképzetnek. 

Milyen táblákat töltő eljárások lehetnek ezek? A teljesség igénye nélkül:

◼︎ Üzleti érvényesség eleje és vége mezőkkel töltött, állományi adatokat (pl.: egyenleg) tartalmazó táblák;

◼︎ Technikai érvényességi eleje és vége mezőkkel töltött táblák*

*Az adattárház mikor szerzett tudomást az üzleti érvényességről és annak változásáról. Ennek akkor lehet szerepe, amikor egy adott rendszer T+n naposan küld T+n-1 napos érvényű adatokat.

◼︎ Tranzakciós táblák töltésénél időbélyeg alapú leltárolás;

◼︎ Dinamikus táblákat* (akár állományi, akár tranzakciós) létrehozó eljárások.

*Dinamikus táblák alatt azon táblákat értjük, ahol DW szinten egy táblában keletkező új értékkészlet elem alapján DM szinten fizikailag is megképződik egy új mező, egy előre definiált töltési logikával, pótlólagos fejlesztés nélkül. Ilyen lehet egy új termékkód bevezetése és tárolása DW szinten, majd pótlólagos fejlesztés nélkül, automatikusan keletkező termékhasználati mező(k) képzése adatpiac szinten.

◼︎ stb.

 

Standardizált interfészek

Technikailag nagyon sokféleképpen kialakítható a kommunikáció egy adattárház és a társrendszerek között. A teljesség igénye nélkül kommunikálhatunk DB linken, filetranszfer alapokon fizikai fájlokkal, kaphatunk adatot push/pull módon, hozhatunk el adatot társrendszerek adatbázisaiból, használhatunk újabb technológiákat, Apache Kafka-t, Nifit a saját szájízünk szerint. Működhetünk tradicionális T+n napos batch alapú feldolgozással, vagy akár közel valós időben. Fontos azonban, hogy ne keverjük ide a real-time adattárházak fogalmát, ami az adattárházakra jellemző architektúra okán valójában sosem lehet valós idejű (maximum elfogadhatóan gyors, pl: T + 2 min).

Egy dolgot nem felejthetünk el: bármit is vezetünk be, az hosszú távon fogja meghatározni fejlesztőink, üzemeltetőink kompetenciaigényét és a környezeteink újraépítési költségét, átfutási idejét, sőt még az adatbázislicenc költségét is. 

Pár alapelvet fontos betartanunk:

◼︎ A DW-vel való kommunikáció tervezése során érdemes figyelembe venni a belső IT által ajánlott szakmai sztenderdeket, már használt technológiákat. Ugyanakkor a társrendszerekkel való kommunikációban érdemes a társrendszereknek alkalmazkodniuk, hiszen valószínűleg egyik társrendszer sem fog olyan sok forrásból adatot kapni, mint az adattárházunk. Elvonatkoztatva a speciális céllal (pl. IFRS) létrehozott adattárházaktól.

◼︎ Akármennyire is szorít a határidő, ha szakmai felelősséget érzünk adattárházunkért, nem érdemes kommunikálnunk más rendszerekkel DB-linken, illetve rendszerenként kiajánlott interfész sémákon. Persze ezek könnyű, gyors megoldásnak tűnnek egy kezdeti adattárház bevezetésénél főleg, ahol az adatbázis-fejlesztők nem adattárházas közegből jönnek. A gond az, hogy egy rövid távon bevezetett rossz megoldás precedenst teremt, illetve rossz irányba vihet későbbi fejlesztéseket. A fentiek okán akármennyire is jó megoldásnak tűnik:

◼︎ Kerüljük az adattárház forrásrendszer oldalán létrehozott, interfész sémába betöltött adatokkal való kiszolgálását, hiszen ez biztosan egy olyan, más rendszerekkel való kommunikációban nem alkalmazható egyedi megoldást jelent, ahol DW oldali monitorozó eljárást szükséges fejleszteni, írási jogosultsággal szükséges rendelkezni a társrendszer adatbázisába. A környezetek újraépítése, másolása a fizikailag elkülönülő adatbázisok okán időigényes, nehézkes és költséges, adattárházunk társrendszeri kitettsége architektúrálisan nagy. 

◼︎ Hasonló szempontok miatt érdemes elkerülni, hogy más rendszerek adattárházunk tábláiba írjanak, ezzel megvalósítva a push adatküldést. Persze, ahol egy adattárházas PM az üzleti igény gyors és olcsó megvalósítását szem előtt tartva igyekszik a technológiai megoldásokban is állást foglalni egy megengedő sztenderdekkel rendelkező környezetben, ott bizony a fenti kockázatot kénytelenek vagyunk kezelni. 

◼︎ A fentiek alapján láthatjuk tehát, hogy interfészeinket oly módon szükséges megterveznünk, hogy az adattárházas környezeteink ne igényeljenek lényegi társrendszeri integrációt, illetve éles hibáknál egy állományi táblát teljesen újra tudjunk építeni. Üzleti érvényességkezelés okán szélsőséges esetben akár több hónapnyi állomány ismételt betöltésére is szükségünk lehet.

 

Standardizált DW architektúra

Hatalmas segítséget jelenthet, ha az integrációra vonatkozó szakmai sztenderdek betartásának/betartatásának felelősségét szerepkörhöz rendeljük. Kisebb szervezeteknél azonban aligha számíthatunk dedikáltan adattárházas architektre, sokkal inkább általános rendszerintegrációs (solution-)architektekkel dolgozhatunk együtt. Ekkor kockázatot jelent, ha ezen kollégák online adatkapcsolatokhoz, vagy (micro)service-s architektúrában szocializálódtak, ahol alapvetően elemi szintű adat küldése és fogadása a cél. A klasszikus (batch) adattárházak világa nem ilyen. 

Ezeknél a rendszereknél előfeltételek figyelembevételével futtatható batch folyamatok vannak, ahol nagy adattömegek, sokszor hatalmas méretű állományi táblák több szálon való bedolgozása a célunk. A kettő fogalmilag is eltér; eszköztáruk annyira hasonló, mint egy autószerelő és egy ács eszköztára. Persze egy szakember lehet sikeres autószerelő és ács egyszerre, de érdemesebb lehet házunkat olyanra bízni, aki kizárólag ács, autónkat pedig olyanra, aki kizárólag autószerelő. 

Architektúránk védelme alapvetően olyan szabályok lefektetésével is jár, amelyek a lehető legnagyobb mértékben gátolják adataink utólagos korrekcióját. Sok esetben persze elkerülhetetlen, hogy utólag módosítsunk adatainkon. Bár az adatkorrekciós igények kiszolgálása rövid távon jelenthet a megrendelő területnél plusz pontot, hosszú távon a menedzsment adattárházunkba vetett hitét áshatja alá. Fontos tehát, hogy ne igyekezzünk minden forrásrendszerbeli adatminőségi problémát adattárház oldalon javítani, még ha ez rövid távon ügyfél elégedettséget is jelenthet. 

Törekedjünk inkább olyan adatminőségi KPI-k felállítására, amik megsértése társrendszer oldali kényelmetlenséget, akár finanszírozási-, büdzsé allokálási feladatokat is eredményez. 

A fejlesztési szabványok hiányosságai szélsőséges esetben oda is vezethetnek, hogy az adattárház csökkenő hatékonysággal kezdi használni a hardvererőforrásokat: akár a kulcsok és megszorítások nem megfelelő használata, akár az indexek nem megfelelő állapota, akár elavult fejlesztői konvenciók miatt. Ezek nagy része viszont a release folyamatba integrálható Dexter alkalmazás használatával kiszűrhető.

 

Standardizált egyebek

Nagyon sok DWH-s folyamat standardizálható, a fentiekben a leglényegesebbeket soroltuk fel. Természetesen a séma-, tábla-, mezőelnevezések, szkriptek elnevezése, működése, DB linkek neve, üzleti-, IT- és rendszerspecifikációk, üzemeltetési dokumentációk és még ezer dolog standardizálható. 

A fejlesztői standardok mellett, azzal összhangban szintén elengedhetetlen a szervezői standardok lefektetése. Képzeljük el, mekkora overhead-et jelent, ha nem foglaljuk belső szabályzatba a rendszerek közötti kommunikációs metódusokat, illetve közvetítő keretrendszereket. Ezzel egyrészt a szervezők kezébe adunk olyan, a fejlesztői kompetencia határterületeit érintő döntéseket, amelyekre nincs igazán rálátásuk. Fontos, hogy a rendszerek közötti kommunikációt ne az egyedi fejlesztések nyomán ad-hoc találjuk ki, hanem az adattárházunk első tábláinak létrehozásakor már szabályzatban, vagy architekturális irányelvekben definiáljuk.

Problémát jelenthet a specifikációk karbantartása, illetve azok minősége is. Gyakran találkozhatunk azzal, hogy az adattárházas szegmensek táblatöltési logikái nincsenek, vagy hiányosan vannak definiálva. Ez azt jelenti, hogy a fejlesztési igényekben mindig csak a módosítás kerül definiálásra, de ez az AS IS állapot hiányában csak rossz minőségben tud megtörténni. Ha kellően sok ideig marad így, úgy idővel elkerülhetetlen lesz egyfajta refaktorálás. A megoldást ilyenkor specifikációs/igénykezelési folyamataink újraszervezésében és/vagy a Dalia használatában is kereshetjük, amit több helyütt használnak már banki és biztosítói területeken. A Dalia alkalmazásával lehetőség nyílik Oracle adatkapcsolatok vizualizációjára, illetve bizonyos metrikák mentén elemezhetők az adatkapcsolatok, programozott összefüggések, megkönnyítve ezzel a módosítás, áttervezés feladatait. A hatásbecslő modulnak köszönhetően a tervezett módosítások potenciális következményeiről is képet kaphatunk.

A lényeg, hogy a lehető legkisebb mértékben kelljen támaszkodni egyedi megoldásokra. Ez természetesen a fejlesztők szakmai kihívás iránti igényének nem tesz jót, cserébe viszont rendszerünk hosszú távon is élhető technológiai környezetet teremthet, ahol az alacsony belépési küszöb mellett van lehetőségünk junior kollégákkal is együtt dolgozni.

A cikk szerzője: Fábián Tamás