Olvasási idő: 4 perc
Az elmúlt 1-2 évben megszaporodtak azok az ügyfél-megkeresések, amelyekben valamilyen módon “valós idejű adattárházról” volt szó. Előfordult ez szakmai kávézástól, ajánlatkérésen át, lezárult projektig sokféle formában. Ezek alapján azt tapasztalom, hogy kevesen értik, hogy mit is jelent ez, mire való és milyen következményei vannak.
Real-time vagy online?
Gyakori, hogy a “real time” és az “online” kifejezéseket szinonimaként használjuk. Pedig nem azok, és ez nemritkán félreértésekhez vezet. Az “online” (ebben a kontextusban) azt jelenti, hogy a rendszer számítógépes hálózaton, praktikusan az interneten keresztül, lényegében folyamatosan elérhető. A real-time meg azt, hogy a rendszer a rá hatással levő külső változást lényegében azonnal lereagálja. Ez a két dolog független egymástól.
A postai csekk se nem online, se nem real-time. Az internet-es felületekről indított banki átutalások Magyarországon hosszú ideje végrehajthatók online; de valós idejűvé csak nemrég váltak: előtte órák, esetleg napok múlva történt meg a pénz átvezetése. A repülőgépek “fekete doboza” maximálisan real-time, de legkevésbé sem online.
Az adattárházak, illetve azok felhasználói felületei általában online-ok – az idő jelentős részében (de pl. sok helyen a betöltés idejére a rendszert off-line-ba teszik), azonban ma nagyon ritka a real-time adattárház.
Valós idő az adattárházakban
A legtöbb esetben, amikor az adattárházakkal kapcsolatban a “valós idejű” kifejezés elhangzik, akkor ezt üzleti értelemben értjük, és kb. azt jelenti, hogy “a jelenlegi napi adatfrissítési ciklus helyett ennél jóval rövidebb (órás vagy perces) ciklust szeretnénk (legalább) bizonyos adatkörökre”. Ez – informatikailag – távolról sem real-time; ezért szerencsére ennek a követelménynek a teljesítése jóval egyszerűbb, és olcsóbb, mint az informatikai valósidejűségé.
A hagyományos, napi adattárház frissítés ún. batch alapú. Ilyenkor egy nekifutásra dolgozzuk fel az összes adott napi adatot. Betöltésre kerülnek a napi tranzakciók, és – rendszerint adattárház oldali különbségképzéssel – rögzítjük a törzsadatok változásait, majd az új állapot alapján kiegészítjük vagy újra számoljuk az adatpiaci táblákat. Egy-egy nagyobb adattárháznál ez órákat vesz igénybe. (Extrém eset, de olyat is láttunk, ahol ez akár 24 óráig(!) is tarthatott; ott két példány adattárház volt: az egyik töltődött, a másikat használták…)
Napinál rövidebb betöltési ciklusokat rendszerint ún. micro-batch feldolgozással lehet megvalósítani. Ilyenkor az elv szinte ugyanaz, mint a napi betöltéseknél, csak jóval gyakrabban és kisebb adatmennyiségre futtatjuk a betöltőket. Van azért néhány szempont, amire oda kell figyelni.
Hogyan kezeljük az átmeneti inkonzisztenciát?
A normalizált alapréteg betöltésénél a sebességgel nem szokott gond lenni, hiszen egy-egy micro-batch általában kevés rekordot tartalmaz. Azonban két olyan specialitás van, amit mindenképpen kezelni kell.
Az egyik, hogy micro-batch módban általában csak változásokat szokott kapni és feldolgozni az adattárház, nem teljes állományokat. Itt arra kell odafigyelni, hogy az ilyen, “inkrementális” vagy “delta” töltések hajlamosak hosszabb idő során “elcsúszni”: bár a részek “összege” elvileg kiadja a teljes állományt, valójában eltérések lesznek. Ezt úgy lehet kezelni, ha a delta töltést kiegészíti egy (időnként futtatott) teljes állomány betöltés is; ami lehet akár a napi betöltési folyamat része.
A másik specialitás, hogy a micro-batch-ek néha – technikai, folyamatszervezési vagy egyéb okból – nem kapnak meg minden adatot: pl. megkapják a tranzakciókat, de nem kapják meg a módosult törzseket, vagy ezek egy részét. Itt tehát azt kell tudni kezelni, hogy a micro-batch töltés után az adatok nem minden tekintetben lesznek konzisztensek (abban az értelemben, hogy pl. nem minden rekordhoz lesz a törzsadat). Bár a tradicionális adattárház szemlélet számára ez riasztó gondolat lehet, többnyire nincs reális alternatívája. Az adatokat a napi betöltési ciklusnak kell helyretennie, addig bizony lehetnek benne kisebb-nagyobb átmeneti ellentmondások.
Tudunk-e elég gyorsan újraszámolni?
Az adatpiaci rétegben egy más jellegű kihívás szokott megjelenni: a számított értékek (pl. KPI-k), és a bonyolultabb adatpiaci kimenetek számolása erőforrásigényes dolog. Ráadásul vannak néha elvi problémák is, pl. hogyan kell napi változást számolni, ha a mai napnak csak egy része van betöltve?
Hiába kevés a változás az alaprétegben egy-egy micro-batch futtatása során, bizony leggyakrabban – az összefüggések miatt – szükséges, hogy ne csak a változásokkal egészítsük ki az adatpiacot, hanem teljesen újraszámoljuk. Hiszen legtöbbször nem elég az “új” adatokkal számolni, sok “régi” adat is kell. Ez a gyakorlatban korlátozhatja, hogy egyes felhasználási területeken mennyire „real-time” tud lenni a megoldás, vagy jelentősen megnövelheti az infrastruktúra igényeket.
Az adatfrissítéssel kapcsolatban van még egy jelenség, ami szokatlan a hagyományos adattárházakhoz képest: az adatok “folyamatosan” (napon belül) változnak. Általában ez csak az adattárház bizonyos sarkaiban hasznos; a legtöbb területen a felhasználókat ez vagy nem érdekli, vagy kifejezetten zavarja. Tapasztalatunk szerint ez olyan technikai visszalépéshez is vezethet, hogy míg korábban egy vezetői beszámolóba az élő riport linkjét tették be az elemzők, ezután csak a képernyőképét merik, mert félnek tőle hogy az olvasó már nem ugyanazokat az összefüggéseket látja.
Megoldások
Elsősorban is fontos, hogy a “valós idejű” és a “normál” felhasználási területet üzletileg és informatikailag – magunk és az adattárházi felhasználók számára is – jól külön tudjuk választani.
Ennek alapján – az adott helyzet, adatkör, igények figyelembevételével – lehet a valós idejű és a napi adatokat együtt kezelni, de olyan architektúrát is ki lehet alakítani, amiben a “gyors” adatok (általában a tranzakciók) külön vannak a “lassú” adatoktól, és külön is kerülnek feldolgozásra és felhasználásra.
Ezen felül a betöltési szemlélet is módosul: micro-batch-ek esetén általában az inkrementális, “real-time” betöltésen felül van egy napi betöltési ciklus is. Így könnyen előfordulhat, hogy ugyanazt az adatot kétszer is betöltjük! Ezért a két töltési ciklus összehangolása nagyon fontos: a napi betöltés korrigálja a napon belüli töltések tranzienseit, és kiszolgálja a stabilabb adatokra építő felhasználási igényeket. Az is általános, hogy a napi betöltés olyan adatpiaci számításokat is elvégez, amit a micro-batch töltések sorén nem teszünk meg.
Az adatok minél kisebb késleltetéssel történő feldolgozása egyre fontosabb a korszerű adatmenedzsmentben. Ez az adattárházakban is lehetséges, ha megfelelően menedzseljük az elvárásokat, és olyan megoldásokat használunk, amik a gyorsabb adatfrissítés előnyeit tudják biztosítani, miközben körültekintően elkerülik a buktatókat.
Zimmer András – CTO