ETL és az "agilityssment"

.
Disclaimer: Érzékenyebb lelkületű olvasók MOST hagyják abba az olvasást, mert igen őszintén, erősen kijelentő módban, nem teljeskörű bizonyítással, minden finomkodástól mentesen, keresetlen szavakkal fogok írni kínzó fájdalmakról, ön- és ügyfélbecsapásokról. Ahogy azokat én éltem meg az elmúlt 15+ évben.

Számomra érzékelhetően 2000-ben látható volt egyik legelső/legnagyobb magyar adattárház-implementációnál (fura érzés az 'ott voltam' tudata), hogy rossz irányt vesz az ETL-ipar. Gyakorlatilag egyedül maradtam az összes rossz érzésemmel. Körülöttem lévők mondhatni mindegyike feltartózhatatlanul ezerrel rohant a messiási csoda reményében a végzetbe.

Szívesen mondanám, hogy tévedtem (aki ismer az tudja, hogy komolyan így gondolom/hiszem), de úgy érzem az élet engem igazolt, így visszatekintve erre a 15+ évre (sokra megyek vele). Nyilván vannak/lesznek, akiknek lesz idevágó ellenvetésük.

Mit lehetett érzékelni 2000-ben, OWB(=Oracle Warehouse Builder) v2.1 korában?

- Óriási léptékben túlzó  és teszem hozzá kevéssé megalapozott üzleti elvárásokat.
- Koncepcionálisan elhibázott irányvonalat (hardver erőforrások nem becsülése, gigantikus overhead, minden határon túl, szemrongálóan elburjánzó nyilakat visual streameken, csillogás túlhajtása a használhatóság rovására, etc.)
- Végtelenségig túlárazott, aranyárban nyújtott kevéske és gyatra termék-szolgáltatást, akárcsak a heterogenitást nézve is.
- Minden kódgenerálás után kézzel kellett javítani az egyébként hányadék generált kódon.
- És a legszörnyűbb adalék: az Oracle Corp. végtelenül ocsmány eljárása (félkésznek sem mondható, nimbuszrombolóan iszonyú bugos drága cuccot adtak drága pénzen ügyfeleiknek, amit a support révén befolyt bevételekből szándékoztak/terveztek bugmentesíteni).
Szóval a piaci szereplők mindegyike hozzáadta a maga "kis" részét a végső soron totális kudarchoz.

Az elmúlt 15+ évben, annyi túlárazott, gigantikus overheadet generáló iparági hulladékkal volt dolgom, hogy több életre is sok belőle: OWB, ODI, Goldengate, BODI, BODS, SSIS, IBM DataStage, Informatica, SAS ETL-Studio, Talend Enterprise.  Ami a gyanutlan felületes személőnek olybá tűnhetett, hogy teljességgel reménytelen a korrekt ETL-ezés. Persze a szoftvergyártók megtollasodtak, hiszen égető kereslet volt a jó eszközök irányába.

Agilis módszertan villámgyors és brutális térnyerése aztán szépen rámutatott a felhalmozódó fájó problémákra, majd a saját módszertani hiányosságaival ráerősítve elhozta a mélypontot.

Az én olvasatomban az látszott:
- Az ETL-ezés szakmai alapproblémáit nem oldották meg
- Helyette generáltak sok más egyéb addig nem létező problémát
- Amikre rossz válaszokat/üzeneteket adtak jellemzően. 
- Drága és/vagy karbantarthatatlan és/vagy üzemeltethetetlen szutykok jelentek meg folyamatosan a végeredmény oldalon.
- Nem győzöm ismételni, hogy aranyárban (hwsw-beszerzés, support, konzultáció, fejlesztés üzemeltetés összességében).
- Menekülési útként, sokszor egy "ingyen" tákolt helyi custom-kódolt rendszer célraorientáltabb és megbízhatóbb volt, ami az informatika örök gigantikus szégyenbélyege marad.
- Ami "menekülés út" sokszor vett irányt az MS-Access felé, ami a non-plus ultrája a szégyennek, gyásznak.
Prominens, Kanadát megjárt, banki IT-vezető céges irányvonalat akart építeni  MS-Access-re, adattárház-építés címén. Konkréten a szemem előtt játszódtak a történések. Céges összefogással tudták csak erről az eltökélt szándékáról lebeszélni.

Persze a 15+ év második felében már jöttek negatív felhangok is az ETL-ipar szörnyű elmaradott állapotáról, De vígaszt ez nem nagyon jelentett értelemszerűen, amikor az ember látta elfolyni a pénzmilliók tömegét értelmetlenül.

Ahogy az sem jelentett már sok hozzáadott értéket, hogy az OWB-t egyre többen szerették, mert egyre jobb eszközzé kupálódott ki (szerintem egyébként nem). Nem validálhatta a korábbi kudarcokat, vendori rosszindulatot.

Szóval nálam nagyobb ellensége az ETL látható választott útjának nem igen akadt a rossz koncepcióknak és gyalázatos implementációknak köszönhetően.

„Érdekes” módon a VirtDB-koncepció engem azonnal kilóra megvett (és azóta is tart a markában, látszólagosan kicsi piaci súlya ellenére is: hiszen az érdem és piac nem mindig jár kéz a kézben, pláne nem az ETL-kontextusában, elfogultságmentesen beláthatóan, ugyibár).

Nyilván a VirtDB-nek is megvannak a maga problémái (nagy adatdemokratizálódás útján a hozzáférés-etika és jogosultságkezelés terén például), de látnivaló milyen fénysebességgel körözi le az ETL-ipart, hogy már csak ilyen problémákon kell agyalni, technikai téren szinte minden adott a legoptimálisabban, azáltal, hogy a legrövidebbre szabja az adatutat a forrástól a célig.

Na pláne főleg slack-kel, wunderlisttel, logentries-zel és hasonló szörnyen használt cuccokkal súlyosbított „agilityssment” korában [most kreáltam a szót, 'harrassment' mentén (is). Nincs még rá Google-találat :)], amikor már az  „agilis nap” is túl durva felbontás és percről percre kell fejlesztő embereknek, párhuzamosan jelentkező – nyilván sokszor antagonisztikus - igényeket kiszolgálniuk, egy durva túlélési folyamat keretében.

Leáldoz-e akkor a napja az ETL-nek?

A magam részéről tuti nem mernék jóslásokba bocsátkozni.

Egyfelöl
* érzek egy akkora iparági tehetetlenségi erőt (mint annó az Oracle RDBMS nyomasztó túlsúlyakor), hogy jó darabig még ignorálhatatlan lesz az ETL-ezősdi (rosszul) megszokott eddigi útja.
* Analógia: ha van gátlástalanul parasztvakító szoftverterméktípus amit világ életemben rühelltem, az a "query-builder", ami nagyot álmodni tudó embereknél, hivatott volt/lett volna az SQL-t „kiváltani”. A talán leggyászosabb „állatorvosi lova” az Oracle Discovererben valósult meg. Per a mai napig virágzik a technológia, minden égbekiáltó „bűne” ellenére is.
* Ezt a fentebb kritizált, sok helyen látható, eszköz-determinált ETL-módit túl sokan használják rosszul, túl sok pénzt beleölve. Sem kidobására, sem jobbra cserélésére nem látszik kellően erős, nagy tömegű alternatíva és/vagy jólirányzott motiváció.

Másfelöl viszont az open source világnak (Talend, Kettle) nagyban köszönhetően talán megmenthető valami az ETL-ezés becsületéből még az „agilityssment” korában is. Akkor is, ha hihetetlen mértékben bugos például egy Talend, vagy például (Talend) Enterprise verzióban szintén durván túlárazott ócskaság. Kettle-ről sajnos nincsenek behatóbb, mélyebb tapasztalataim (sajnos elkerült engem): amit láttam belőle az tetszett, de pudingról nem lehet véleményt mondani pusztán csak a látvány alapján.

* A VirtDB eleganciáját, egyszerűségét, hatékonyságát ugyan esélye nincs elérni,
* A Talenddel bejárt 100 különböző útból várhatóan kb. 98 rossz (lesz) az én értékelésemben, érzékelésemben, mivel nagyon könnyű vele is, továbbra is eltévedni.

DE

* Jó architektúrával (pl.: lambda architektúra megfelelő alkalmazása)
* Jó architecttel (én jó ÉS főállású, architecttel még nem bírtam találkozni életem során, külön-külön azért lehet teljesíteni a feltételeket)
* Jó ETL-fejlesztőkkel (ilyen azért bőven akad)

* Jó elvek mentén (pl.: a nodehasználat és kódolás arányának megfelelő kikeverése).

* Jó szellemi/vezetői hozzáállással (pl.: ami nem merül ki a (túl)hajtásban, és hajlandó folyamatosan(!) egy napnál messzebbre is előrenézni)

NEM ESÉLYTELEN - ügyfélként nézve, még számomra is elfogadható -, azaz
* Maximálisan ügyfélcentrikus (szakmailag megalapozott ügyféligények maximális kielégítésével)
* Üzleti logika méretével és komplexitásával, erőforrás-igényt tekintve, lehetőség szerint, felülről minél jobban közelítve a lineáris skálázódódást
* Jó ETL-ezést implementálni,
* Akár „agilityssment”-tel is súlyosbítva, ha ez kikerülhetetlen,
* Hangsúlyozom kizárólag az említett open source alapokon (hiszen a commercial része az iparágnak minden becsületét eljátszotta, olvasatomban, úgy hogy az önkritikus szembenézés is elmaradt).

Talend Studiónak is rengeteg problémája van:
* nagyon bugos,
* külön lélektana van a benne való hibakeresésnek, -megkerülésnek (és egyáltalán nem az előnyősebbik végéről)
* nem normális a 10.000-es nagyságrendű jar-tömeg, akár 4 GB-on is elterülve (azt gondolom: lenne ott mit optimalizálni, illetve lehetséges magyarázat a bugtengerre)

De koncepcionálisan annyi kört ver a létező commercial eszközökre, hogy egy ennyire szomorú hangvételű blogposztban megérdemli a maximálisan pozitív kiemelést.

PS: Nálam, analógiában, a Talend Studió az ETL-ezés PlSql Developere (ami PlSql Developer kicsi, ergonomikus, tán még butának is mondható eszköz egy TOAD-hoz képest), de ár-érték arányban verhetetlen, többek közt, mert érzékelhetően szívvel-lélekkel ügyfélorientáltan fejlesztették, az évek hosszú sora alatt a használhatóság irányába. Például azáltal is,hogy sokkal kevesebb okádék sql/plsql-kód esik ki belőle, mint a nagy testvér TOAD-ból. Miközben a nagy TOAD a Dell égisze alatt vegetál.