ETL, mint mém

Általánosságban ETL alatt egy olyan folyamatot értünk, amely két rendszer között adatokat mozgat, közben feloldva a rendszerek közötti adatreprezentációs különbségeket. A közel 50 éves informatikai fogalom manapság népszerűsége csúcsán van. Ahogy az informatikai megoldások egyre komplexebbé váltak technológiában, térben és időben (is) egyre heterogénebbek lettek, úgy vált egyre erősebbé az integráció iránti igény. Ma az egyik legfontosabb kérdés az üzleti alkalmazások kapcsán is az, hogy hogyan lehet az adatokat a megfelelő formában a megfelelő helyre eljuttatni.

Az ETL betűszó (és annak hitvitákat is indukáló egyéb variációi) jelentése ugyanakkor elég tág és képlékeny. Hogy egy konkrét megoldás esetén az egyes betűk az adatfolyam melyik részére vonatkoznak, az sokkal összetettebb lehet.

Jelen blogban egy egyedi fejlesztésű ETL keretrendszer megoldásainak kapcsán azon rétegekre fókuszálok, amiknek megléte és szerepe jellemzően észrevétlen.

Maga az eszköz jelenleg több ügyfélnél több különböző feladatra is alkalmazott adattárházas feladatkörben. Ugyanakkor érdekesebb lehet egy olyan eset kapcsán bemutatni, ahol - egy vállalatirányítási rendszer váltás miatti migrációs feladathoz kapcsolódóan - csak egyszeri szerephez jutott.

Oracle – SAP Migráció, mint feladat

A migráció, azaz a forrásrendszer adatainak legyűjtésre, majd megfelelő formára hozása után a célrendszerbe való betöltése, egy „ETL” megoldás. Ugyanakkor a megoldás két dimenzió mentén tagolt. Az egyes adatkörökért külön-külön dedikált ETL-ek felelnek. Továbbá technológia korlátok és kockázatok miatt a két végpont nincs közvetlen kapcsoltban. Így megjelenik a másik dimenzió, amely mentén több, önmagukban is ETL megoldásnak tekinthető rétegek is megkülönböztethetők.

Az alábbi ábra szemlélteti, hogy ebben a történetben az ETL bélyeget mikre lehetne rásütni.

Madártávlatból a két rendszer viszonylatában a migráció, mint „ETL”,  a teljes folyamat az alábbi elemekből áll össze (fordított sorrendben):

  • „L”: a célrendszerbe való betöltést az SAP Migration Cockpit végezte, ami önmagában is egy teljesértékű „ETL” eszköz. Ez az eszköz Excel forrásból nyeri ki az adatokat, majd az SAP által megkívánt transzformációk után betölti. Belseje azonban „fekete doboznak” tekinthető, abba a kiajánlott képességeken túl nem lehet beavatkozni. 
  • „T”: az az egyeztetési, adattisztítási és konverziós munka, amit a folyamatban a projektben résztvevők manuálisan végeznének. Ezek az „etl”-ek jellemzően nem formalizált, esetenként ad-hoc jellegű beavatkozások. A jellemző eszköz ebben a rétegben az Excel és minden egyéb, amit a cél érdekébe be lehet vetni. A teljes folyamat robusztussága érdekében ezen „betű” szerepét a lehetőség szerint minimalizálni kell. Igazán „feszes” akkor lenne, ha a legfelső szinten csak „EL” lenne.
  • „E”: az a megoldás, ami a forrásrendszerből leválogatja az adatokat. Ebben az esetben az „etl” a Cockpithez képest az eszköz belseje hozzáférhető, a projektszereplős transzformációkhoz képest formalizált megoldásokat tartalmaz.

IXENIT ETL Tool szerepe

Elsősorban az Oracle oldali adatkinyeréshez készült az eszköz. Amennyiben csak annyi lett volna a feladat, hogy leválogasson és valamilyen feldolgozható formában (például CSV) a transzformációhoz átadjon, akkor a történet véget is érne.

Az eszköz madártávlatból nem különbözik a piacon elérhető „dobozos” eszközöktől. Ugyanakkor a „nyitottságának” köszönhetően további feladatok is felvállalhatók voltak. A tervezett migráció során a legnagyobb kockázatot a „T” szerepe és súlya jelenthette volna. Ezért az egyik legfontosabb célkitűzés lett, hogy ezt a transzformációs lépést úgymond kiürítsük és lehetőség szerint minden formálisan ki legyen fejezve valahol. Tekintve, hogy a SAP oldalán az eszköz „zárt”, csak az Oracle oldali eszközben volt erre lehetőség.

A transzformáció kiürítése három feladatot jelentett:

  • Hagyományos értelemben vett transzformációk, például érték megfeleltetések végrehajtása. Erre az eszköz önmagában is lehetőséget ad, saját „T” transzformációs szolgáltatásaival.
  • Oracle – SAP adatmodellezési különbözőségeinek feloldása. A leválogatott adatok nyers formában nem alkalmasak a betöltésre, azoknak a célrendszernek megfelelő struktúrában kell előállniuk. Például a partnertörzs teljesen más egyed fogalmakkal építkezik és ezzel majd konzisztensnek kell lennie a nyitott tranzakciós állományoknak.
  • Az adatok megfelelő formában való prezentálása. Ehhez a Cockpit által generált Excel vázak szabtak követelményt.

Mindhárom feladatot átvette az eszköz.

Transzformáció

A transzformációhoz kapcsolódó konverziós táblázatok az eszközön keresztül bekerültek a forrásrendszerbe. Azokra transzformációs szabályok hivatkozhatnak, azok újra felhasználhatóan minden érintett adatra konzisztensen végrehajthatók. Ugyanakkor a transzformációk elemezhetősége érdekében a lépés előrébb lett hozva ez eszközön belüli adatfolyamban.

Adatmodell

A két rendszer üzleti adatmodelljének különbözősége adatkörönként két rétegben készült el. Az első a forrásrendszer fogalmait megtartva lett felépítve. A második az elsőre támaszkodva, a célrendszernek megfelelő struktúrában és a transzformációs szabályokkal egybeszerkesztve lett kialakítva. A két réteg külön-külön és együtt is elemezhető adatbázis eszközökkel.

Az a képesség, hogy beletekinthessünk az adatfolyamba auditálási céllal, kiemelt fontosságú egy migrációs megoldásnál. Hogy a forrásrendszer legfrissebb korrekciói valós időben, a teljes ETL végrehajtása nélkül, „mi-lenne-ha” most futtatnánk formában, akár részadatokon, akár más adatokkal összefüggésben elemezhetők legyenek. Mivel ebben az esetben közel 100 adatkörről volt szó, a teljes folyamat futtatása egyben időigényes is, illetve a célrendszerbe való betöltés nem csinálható vissza. Egy adattárház esetén lényegesen egyszerűbb a hibás adatok eldobása és újra gyártása.

Prezentálás

A folyamat végén egy, további átalakítást nem igénylő, azonnali betöltésre alkalmas formájú Excel áll elő. Ehhez a Cockpit által legyártott minta Excelek struktúrája meta-adatként lett ábrázolva. Az eszköz eredeti Excel gyártó képessége ezen adatokra támaszkodva lett kibővítve.

Továbbá, hogy a felhasználóhoz által is kényelmesen elérhető szolgáltatás legyen, az eszköz integrálva lett a forrásrendszerhez. A végrehajtás párhuzamosított, betartva az adatok közötti összefüggéseknek megfelelő logika sorrendiséget. A migráció végső végrehajtása a legjobb esetben egyszeri lépés, legalábbis a célrendszer oldalán. Ugyanakkor a forrásrendszerből való kinyerése tetszőleges adatkörökre, adatkörcsoportokra többször is ismétlődhet.

Oracle – SAP Migráció, mint megoldás

Az alábbi ábra szemlélteti, hogy ebben a történetben az ETL végül milyen formában valósult meg.

  • Az „L” változatlan formában felel a célrendszerbe való betöltésért
  • Az „E” átvette a „T” minden feladatát.

A forrásrendszer oldali ETL megoldás az alábbi rétegekkel rendelkezik:

  • A „T” transzformáció két rétegben megfogalmazott kis „etl”-ekkel felel a forrásrendszer szerinti logika ábrázolásáért, a klasszikus transzformációkért, illetve a célrendszer modelljének leképezéséért.
    • „S” etl réteg az Oracle EBS adatinak előszűrésének formális leírásáért felel (például régi irreleváns adatok kizárása) megtartva annak struktúráját.
    • „T” etl réteg teszi lehetővé, hogy az egyszerű értékkonverziós transzformációk mellett sokkal komplexebb strukturális transzformációk is formalizáltak lehessenek (például szállító és vevő törzs összefésülése közös partner törzsbe).
  • Az „E” legyűjtés két rétegben felel az adatok visszakövethető kivonatolásért, illetve a közzététel megismételhetőségéért.
    • „Q” etl réteg a ténylegesen végrehajtott kivonatolások. Nemcsak az ellenőrizhetőséget biztosítja, hanem lehetővé teszi, hogy más etl-ek felhasználják egymás adatait (például a többször használt törzsadatok csak egyszer legyenek leképezve).
    • „X” etl réteg a ténylegesen végrehajtott publikálások. Biztosítja, hogy a kimenet újra gyártható lehessen. (Fontos, hogy a teljes folyamatot megismétlése nélkül erre lehetőség legyen, elkerülendő az adatinkonzisztenciákat)
  • Az „L” jelen megoldásban az Excelbe való töltést, illetve annak kiajánlását (Publish) végzi.

A forrásoldali megoldás nemcsak a teljes adatfolyam végrehajtását végzi, hanem az összes köztes szint kiajánlásával az elemezhetőséget is lehetővé teszi.

IXENIT ETL Tool hozzáadott értéke

Egy dobozos termék esetén az eszköz képességei szabta korlátok között lehet ETL megoldásokat szállítani. Az IXENIT eszköz esetén, annak meglévő képességei mellett, lehetséges az újabbakkal való bővítés. Ez teszi lehetővé, hogy a problémákat „meta” szinten oldjuk meg.

Jelen esetben az alábbi – részben az eredetileg meglévők bővített, részben újonnan kialakított – képességek voltak a legfontosabbak:

  • Amennyiben az üzleti rétegek kialakítását, tehát az egyes objektumok leválogatásának első köréhez szükséges adatbázis-táblák és mezők kijelölését, egy kellően hozzáértő EBS szakértő képes megvalósítja, az összes többi objektum karbantartása automatikusan történjen. Kvázi ne legyen szükség ETL fejlesztőre.
  • A SAP Migration Cockpit által elvárt Excelnek megfelelő publikálási képessége. Egyben felkészülve arra, hogy azok struktúrájában még az utolsó pillanatban is történhet változás. (A végső kimenet újragyárthatósága emiatt kiemelt követelmény lett és gyakorlat vissza is igazolta szükségességét).
  • Mivel várható volt, hogy az első két kis etl rétege (S,T) – ahol az üzleti logika megfogalmazott – a projekt alatt folyamatosan változni fog, szükséges volt, hogy annak változásait az arra épülő gyűjtési réteg automatikusan, fejlesztői munka nélkül le tudja követni. Az IXENIT ETL Tool ezt a két réteget dinamikusan újra tudja építeni. (A gyakorlat ennek létjogosultságát is visszaigazolta, mint várható volt, az utolsó pillanatban is történtek változások az üzleti logikákban).
  • Minden réteg önállóan is megszólítható (SQL lekérdezésekkel betámadható) lehessen. A motor az üzleti logikát egybeszerkesztve a kivonatolással és a publikálással generált nézeteken keresztül kiajánlja.

Összefoglalva az eszköz lehetővé tette, hogy az ETL fejlesztő az üzleti problémára tudjon fókuszálni. Az IXENIT ETL Tool nem fekete dobozként, hanem transzparens módon hajtja végre az ETL lépéseit. Biztosította az ellenőrizhetőséget, hogy bármelyik adatrétegbe bele lehet kérdezni az ETL folyamat bármely fázisában. Lehetővé tette az adatkinyerés auditálását, a mapping hiányosságok feltárását, valamint az elvárt struktúrához képest tapasztalt eltérések debuggolását. A transzformációk és az eredményfájlok előállítása az ETL Tool használatával szinte automatikusan történhet, az EBS konkurrens programjait használva felhasználóbarát módon vezérelhető.

  |

0.0