Az adatintegráció ETL-útjáról unorthodox megközelítéssel

.
Hogy jelezzem mennyire távolinak érzem a témát érintő saját gondolkodásomat a mértékadó ipari véleményektől, úgy gondoltam ezt a címbeli - a napi hazai politikából némileg áthallásos, feltétlenül mindenképpen - bombasztikus jelzőt  is bedobom az ügy érdekében. Annyira durvákat tervezek írni ebben a posztban, hogy az érzékenyebbeknek lehet, hogy most kéne más blogra lapozniuk ;)

Apropó:

(1)  a három napja publikált Gartner-report (lásd lenti linken). Ami jelentést én nagy szakmai traumaként érzékeltem, ha finom és arisztokratikus akarok lenni önkifejezési stílusomban, akkor annyit mondanék, hogy ez így ebben a formában egy ipari hulladék, de talán elhihető, hogy tudnám jóval erősebben is kifejezni magamat. ;)

Nincs rajta a Pentaho/Kettle, Talend durván alul van értékelve, míg az IBM+Informatica az egekbe van emelve tök érdemtelenül, indokolatlanul (vagy csak jó pénzt fizettek a Gartnereseknek). Mindössze ennyi is jelzi a cucc által képviselt értéket (számomra).

Gartner: Magic Quadrant for Data Integration Tools

(2) Személyes levelezésemben is előkerült a téma, Talend kapcsán, így legalább ez utóbbi dícséretére is tudok pár szót szánni (belső késztetésből, nem fizetett hirdetésként).

(3) Illetve a napokban foglalkoztatott az open source BI "hol tart" jellegű mérlegelése.
Nagyon röviden idevágóan: én azt gondolom, hogy vannak feladatok, amikben az open source világ produktumai ugyanolyan jók, vagy egyenesen jobbak, mint a commercial-é.
- Riportingban közel olyan jók/ekvivalensek
- Data Mining-ban például mára már jobbak az open source cuccok, ahogy adatintegrációs eszközöknél is.
- És persze van olyan terület, ahol valamiért esélytelen az open source világ jelen állás szerint: ilyen az adatmodellezés például (open source vonalon maximum részsikerek láthatók számomra). Vagy az RDBMS-ek világa; azért egy Oracle marha magasra tette a lécet, lássuk be. OLAP-ot illetően is inkább szkeptikus vagyok, mint optimista.


Problématér: Az ETL eszközöket személy szerint – környezetemben tudhatóan – mindig is nagyon rühelltem koncepcionálisan is, konkrét megvalósításaikban is (uramatyám mi szoftver-szeméthegyeket sodort az élet elém a témában az elmúlt 15+ évben). Ez csak napjainkra változott meg, mióta Talendben dolgozhatom, az egyetlen olyan eszközben, amiben perspektíva van, illetve ami által értelmet tud nyerni az adatintegráció ETL-válfaja. Horribile dictu még a fejlesztés is funny benne.

Az volt ugyanis a durván vaskos tapasztalatom, hogy az ETL koncepcionálisan ostoba megközelítésével elfedi a lényeget, úgy hogy más technikai - informatikai problémá(ka)t generál (senki nem kérte ezeket) majd erre a kihívásra ráadásul kifejezetten rossz választ ad.


Hangsúly: az adatintegráció témájában az üzleten, hogy világos legyek Ü-Z-L-E-T-en van, annak kiszolgáló eszköze kellene legyen bármilyen ETL-tool, és nem pedig egy öncélú, pénzpazarló, monolit, maszturbációs informatikai státuszszimbólumnak kéne lennie, az én felfogásomban.

Azaz (heterogén) forrásoldalról, gyorsan, olcsón, jól értelmezetten, üzleti fogalmakra helyesen leképzett adatok kerüljenek céloldalra, megfelelő minőségű és időben jól változó/bővülő adatpiacok formájában, üzleti igények elérhető legteljesebb körű kiszolgálására.
Megfordítva, ha
- nincs alkalmazott forrásrendszer-ismeret
- nincs üzleti fogalomtár (metaadattár, data governence, adatgazda-hierarchia)
- ha az ETL-tool csak újabb nyügők, overheadek generálását tudja hozzáadott értékként beadni a közösbe, szétforgácsolva és pusztítva a szűkös erőforrásokat, nem pedig észrevétlenül plusz támogatást ad az üzleti célok megvalósulásához
- MS-Accessben hegesztenek adatpiacokat üzleti emberek (pláne from scratch),
akkor az adatintegráció ETL-koncepciója látványosan megbukottnak tekinthető számomra, tök felesleges volt egy buzzword oltárán pénzhegyeket költeni.


Nehézség: azt szoktam mondani, hogy az ETL-es üzleti logikák komplexitása olyan, mint az információ- tömörítés. Az utóbbinál tudjuk Shannon információ-entrópiás munkásságából, hogy van egy mérethatár, ami alá nem lehet menni alkalmazás oldalán mondjuk az említett tömörítésben: ahogy egy videót senki nem fog pár bitre tömöríteni, éppúgy, ahogy a 100 méteres síkfutó sem fog 5 másodperces világcsúcsot futni.

És bizony az üzleti logikák komplexitása sem "tömöríthető" egy határon túl. Rossz felfogás esetén az ETL csak értelmetlen pótcselekvéses menekülési utat ad. Az üzleti kommplexitással való valós szembenézés elkerülhetetlen, nem megúszható. Nemhogy semmilyen csilivi grafikus tool-lal, hanem egyáltalán nem megúszható. (Pont amiről beszéltem a "problématérben".)


Előzmény: a RÉMÁLOM, amiért máig haragszom az ORACLE-re, az az, hogy mit adott az iparnak az OWB-vel, az én értelmezésemben:

- Ahelyett, hogy vettek volna egy értelmes eszközt, mint addig mindig sőt OWB-korszak után is (lásd ODI, Goldengate), és ami perdöntően jól sikerült vásárlások/akviziciók voltak mindig is, saját erőből hegesztettek-tákoltak egy rettenetes OWB-t, amit félkész-bugos verzióban piacra dobtak, mondván, hogy, ha kell a piacnak, akkor a befolyó licence-költségekből fejlesztik, hibamentesítik.

- Mindezt brutális milliós áron (per licence).

- Vázoltak egy rettenetes alvilági pokolba vezető utat a fizető ügyfeleknek, amiknek mérföldkövei: (1) licence, (2) support, (3) oktatás, (4) konzultáció, (5) brutálisan és mellesleg feleslegesen nagy overheadből következő jelentős túlméretezések miatti hardver-oldali költséghegyek előre kifizetve az Oracle-nek és iparnak, miközben a fizető ügyfélnek még semmije nincs, ezen a ponton.

- Lassú hozzáadott érték képzés, gyorsuló elavulással kombinálva.

- Join-oknál elszaporodó felesleges leképzési élek, valós felhasználás során áttekinthetetlenné váló workflow-ok

- Gusztustalan (plsql)-kódgenerálás, v2.1-ben rossz kód generálódott, kézzel kellett belehegeszteni  minden fordulóban.


Pár szó a visual streamekről

Szét kell választani a megközelítést: a visual streamnek általam elismerten is komoly elönye van/lehet, például adatbányászatban vagy self-bi-ban. A node-kat könnyedén tudja pakolgatni, cserélgetni az ember magának egy átlátható folyamat keretében, a produktivitás jegyében. De enterprise-ready ETL-ben két sok ezer oszlopos tábla joinjánál/mappingjénél ahol az élek úgy szaporodnak feleslegesen a monitoron, mint a hangyák, én ezt marhaságnak gondolom. Ennél akkor már sokkal jobb módszertanilag az SQL (csomó más előnnyel).

Szokták mondani, fentebb is volt szó róla, hogy ETL-re azért van szükség, hogy ha kétszer annyi fejlesztő kell, akkor tudjon a csapatba jönni könnyedén új fejlesztő és tudjon elkezdeni azonnal dolgozni. Míg egy szanaszét hackelt custom code-ot azért nem szívesen ad az ember egy ujoncnak. Igen ám, de gusztustalanul kusza szuboptimális ETL-processt ilyen visual streames ETL-eszközökben is könnyen össze lehet hozni, ahol nem egy hálás feladat reverse engine-elni az üzleti logikát node-okra való klikkelgetés révén.

Szokták mondani, hogy az ilyen grafikus ETL-tool azért is jó, mert könnyebb vele adminisztrálni, monitorozni, üzemeltetni. Az Oracle például nagyon sokáig nem tudta azt az alapvető dolgot, hogy egy lehalt ETL-töltést lehessen folytatni klikkelésre, csomó manualitás kellett hozzá pluszba és/vagy patch-hackelés, mindezt brutális árszabás mellett.

Örök vita tárgya, hogy hol kell fusson az ETL: drága adatbázis szerverben gyorsan, avagy kiszervezve például Java-s applikációs szerverbe (utóbbit kb.10-szer olcsóbb skálázni). Hát ha (homogén) adatbázis szerverben fut, akkor a vizuál streames ETL-t eléggé feleslegesnek gondolom a magam részéről. Nem vállalkozom a saját kérdésem megválaszolására :DD, én csak annyit várok el, hogy teljeskörű mérlegelés előzze meg a döntést (követő visszaméréssel), és ne lokális és/vagy korrupciós szempontok.

Azt akarom csak mondani, hogy már az elvárások terén is komoly problémák vannak, és az implementációkról még nem is beszéltünk egy szót sem.Mindehhez az ETL-ek aranyárban vannak (visual streamek bűvölete révén), és én csak azt nem értem mire fel.



Az én fogalmaim szerint értelmes ETL-ezés feature-setje valami ilyesmi:

* Kis overhead, olcsó elindulás, (jól skálázható, értsd degresszív vagy legalább lineáris költségnövekedésü) fejlesztés verziókezeléses team-munkába, értelmes üzemeltetéssel, új szoftververzióra való könnyű átállás lehetőségével.

* Enterprise-ready legyen, ne hackszagtól bűzlő implementációs szemétdomb jellemezze.

* VALÓDI ETL-funkcionalitás legyen:
+ Rendkívül erős heterogenitási support. Webservice, Exchange-mail, MQ-rendszerek, Kerberos-authenticated sql/nosql külső és/vagy egzotikus adatbázisok (amikre akár odbc+jdbc sincs) integrálhatósága, transzparens oprendszerek, stb.
+ Ne csak pár SQL batchéről beszéljünk (valós ETL-funkcióimplementálás)
+ Tényleg legyen valós adatintegráció, ne két Oracle-instance közötti adatcseréről beszélgessünk már.
+ Plugineléses funkcionalitás-kiterjesztés
+ Minőségi feladat/munka dekomponálás, horribile dictu agilitásos módszertannal is.

* Világos elhatárolás legyen a központosítás pl.: ügyféltörzs, interfacelés-szabályozás, változásmanagement valamint nem-központosítás között pl.: az adhoc elemzői data blending, tervezéssel, prediktálással. Mindkét válfaj fontos, mindkettő nélkülözhetetlen.

* Megszakíthatóság, újraindíthatóság, monitorozhatóság, continuos integration megfelelő policyje, mindez értelmes jogosultságkezeléssel megtámogatva, az értelmes üzemeltetés jegyében.

* Jó fejlesztési policy, hogy ne szabaduljanak el az egyéni fantáziák noch dazu az agilitás jegyében. Megtalálni a kódolás és visual stream helyes arányát, ha lehet OO-paradigma keretein belül.

* Mixed kézi és automatikus doksi-generálás, a naprakészség jegyében.

* DB-repo (OWB) helyett filerepo jól kereshetően, programozhatóan feldolgozhatóan

* Szimpatikus SCD-zés (=Slowly Changing Dimension) lehetősége.


Talendről

A Talend legálisan ingyenes cucca (Open Studio) nagy tudású, nagyon kellemes eszköz. A fejlesztési folyamat állomásán/végén produkál egy Java-s .jar-t, amit tetszés szerint akárhol lehet futtatni szépen. A benne lévő kód nagyon szép és ergonómikus (az Oracle OWB-je ugye ritka hányadék kódot generál). Mondom ezt úgy is, hogy Talend Custom Componentet írását, csak távolról láttam, de hozzáértő kezek csodákra képesek. . ;) Gyönyörűszép kapcsolat van a visual stream designer és code-window között (utoljára ilyet Delphinél láttam, és ez hatalmas szó, aki ismer engem). Mondjuk a visual stream komponensei/node-jai közötti turkálásban el tudnék képzelni felhasználóbarátabb megközelítéseket, mint amikkel nap mint nap kell dolgozni.

A Talend pénzes verziója viszont nagyon durván túl van árazva, azt gondolom.A legdrágább aranyárban vesztegettt Informaticának negyede kb, szerintem a huszadát sem éri meg. Az Open Source Talendre mindenkit bátorítanék, a pénzes Talendről mindenkit lebeszélnék a magam részéről.

A Talendben többszáz komponens/node van, nagyon jól kitalált architektúrában, nagyon jó teljesítménnyel, remek logolással ötvözve (maga a Talend Studió mondjuk erőforrás-igényes kétségtelenül), de amikor többtízmilliókról beszélünk (dolgozók bérköltségén felül is) ne legyen már probléma egy erős fejlesztői munkaeszköz beszerzése (+8 vagy horribile dictu +16 GB RAM-mal vagy pláne 13"-nál nagyobb képernyővel).

Ha sikerül az agilitási nyomulásokat is visszaverve, jó policy mentén fejleszteni az ETL-folyamatokat, akkor - azt gondolom - a Talendnek nincs párja funkcionalitásban, komponensekben, teljesítményben, adminisztrálásban, heterogenitás supportjában,olyan környezetszennyező ipari hulladékok fémjelezte vesenyben, mint OWB, IBM, Datastage, Informatica vagy a nagy "kedvenc" BODS(=Business Objects Data Services).

Talendből egy dolog hiányzik fájdalmasan egy CDC(=Change Data Capture). Más kérdés, hogy ez mennyire kell része legyen az ETL-nek. Ha arra gondolok, hogy mennyire fájdalmasan nem tud a világ jó CDC-szoftvert csinálni, akkor része kéne legyen, de egyébként alapjáraton nálam nemkicsit más műfajok a CDC és az ETL.