Agilis Talend

.
* Alapfeladat(-analógia):
Akarunk venni 1 vagy 2 kg/zsák lisztet. Pénztárnál a kifizetés után ott az öröm, hogy miénk a vásárolt cucc, de ott a feladat is, hogy haza kell vinni (ezt most én előre megfontolt szándékkal overheadként aposztrofálom). Nyilván több cukrot nehezebb hazavinni, pláne ha egy nyugdíjas rokonunk volt a vásárló.
De ott a lehetőség, hogy kérünk szállítást is extra-felárért. Vegyük észre, hogy az egyszerű hétköznapi példában az overhead (további) termék(vétel)be fordult/konvertálódott.

Propozició:
Minden szolgáltatásterméknek (informatikában legalábbis többnyire) van egy látványos "darabra számolható" termék-része és van egy implikált kevésbé látványos, hogy ne mondjam "láthatatlan" overhead-massza része (vö.: felosztott és felnemosztott költségek).
Informatikai szolgáltatás-termékben egy új szolgáltatás beizzítása (legrövidebb úton), azonnal szuboptimálissá tesz/tehet néhány régebbi megvalósítást és ezt a legacy-terhet aztán lehet továbbgörgetni.
Szép is lenne ha kódolt karakterszámra "skálázva" kéne fizetni, dupla kód dupla pénz. Én a magam részéről nem gondolnám, hogy a szoftver ipar skálázódása ott tartana, ahol a hardveré, a komplexitás-overhead nullához konvergálásával.
Az overhead egyfelöl tehát sosem nulla, másfelöl sokszor szeretünk elfeledkezni róla, ami problématengerek ősforrása (hogy egy "kis" képzavarral éljek).

Propozició:
Ha van overhead, akkor egyet tehetünk (ami kötelességünk is egyúttal), minimalizálni az overheadet (dinamikusan alkalmazkodva).
A lehető létező legrosszabb ám nem minden alap nélküli opció, hogy agilis megrendelő projektvezető szabadságakor "fű alatt" orvosoljuk az overheades problémákat, megyünk utána elmaradt dolgoknak, na pláne "ingyen".
Egy sokkal ígéretesebb út lehet viszont, ha korrekten, számonkérhetően, elszámolhatóan - bevezetőben említett látható(!) módon - termékké konvertáljuk.


* Axióma:
Az agilis fejlesztési módszertan (hadd hívjam innentől agilitásnak, mert sokkal rövidebb) az inkoherenssé válás - divergálós - melegágya: amennyiben minél rövidebb és benne minél hatékonyabban termékrefókuszált időre optimalizálunk (csak) amiáltal törvényszerű a rendszer-szétesés idővel lineárisan, rosszabb esetben progresszív haladvány szerint arányosan.

Miért is?
Mert a termék-leszállítás legjobb esetben is csak egy pillanatba fókuszált lokális optimum lehet, globális (teljességre nézvést tökéletességet hordozó) semmiképpen, merthogy hiszen bőven vannak egyéb optimalizációs szempontok.
A "látható" termékre fókuszálva a megrendelő csökkenteni véli a költségeit, a szállító meg "túlélésre" rendezkedik be. Én bizony azt konkludálom, hogy kizárólag a jóindulaton és a pillanatba zsúfolt szakmai képességeken múlik, az érintett rendszer jósága, szakmai kényszerítő erő a minőségi konzisztenciára egyáltalán nincs.
Azt gondolom rendszerszinten kell globális optimumra törekedni.

Analógia a lokális optimum kontextusára:
Meg lehet nyerni egy Tour de France-t doppinggal és aztán el lehet veszteni 7 db Tour-elsőséget is akár. A kulcsszó a dopping aka megengedett/korrekt eszközök. Nemcsak (korrekt) terméket kell szállítani, hanem korrekten is kell megtenni ezt: egy "doppinghoz" felemásan viszonyuló világban ("a leggyorsabb célbaérés követelménye felülírhat vagy nem írhat felül minden más szempontot").
Vagy egy másik példában 1-200 év alatt seggére lehet verni a könnyen kitermelhető kétszázmillió év alatt keletkezett fosszilis energiakincsnek, "piacgazdaság pörgetése" címszóval, aztán lehet szembesülni a nem végiggondolt overhead-következményekkel.


Axióma:
Ahogy az ETL-t, mint adatintegrációs módszertant megbukottnak tekintem, hogy ha business userek desktop-környezetben Access-szel enterprise data martot fejlesztenek, úgy az agilitást mint módszertant megbukottnak tekintem az adott projektben, ha időben haladva nő az overhead és romlik a minőség. Az első mérföldkő minőségét overhead-szintjét tartani kell tudni, csak akkor van miről érdemben beszélni.


* Overhead-tényezők vég nélkül folytatható listája, ízelítőnek (adatintegráció ETL/Talend útján)

- Rendszer-divergálás/-szétesés, inkosziztencia, névkonvenció-megbicsaklások, gányolás-szag erösődés, "esztétika-" majd minőségromlás, egyre gázabb belenyúlni korábban fejlesztett cuccokba.

- Idő lineáris múlásával progresszíven nő az overhead (kétszer annyi idő után pl.: négyszer annyi gond)

- Visszamérések többszörös üzemeltetési költségnövekedést láttatnak az agilis projektben.

- Szellemi munkát, extra költségnövelő erőforrást igényel az üzemeltetés. Ez durván hangzik, vélhetően olyan generálódott munkát takar, amit a fejlesztő nem végzett el és meglehet el kellett volna végeznie.

- Agilis fejlesztők egyre többször egyre hosszabb/komplexebb dolgokat mindig újra kitalálnak zöld kányhától, zöld mezősen (jobb híján). Nem tud a korábbi tapasztalat beépülni a fejlesztés kereteibe. allokált idő hiányában.

- Egyre több mellékhatás kódolódik a rendszerbe, okozhatja a legváratlanabb hibákat, vagy csak a hibalehetőségeket, ráadásul a teljes ETL-DB szoftverláncon.

- Az általános célú job-ok, egyre több (felesleges) specifikumot tartalmaznak

- A specifikus job-ok feleslegesen szaporodnak, generálják a (sokszor inkonzisztens) redundanciát.

PS: Érdekes lenne belegondolni, hogy egy VirtDB-nél hogy néz ki ez az overhead-lista. Így first lookra, egyfelöl a fentiek kvázi egyike sem jeletkezik, HURRÁ! Másfelöl data governance meg változás-management tudhat extra kihívásokat produkálni, ha túl sokan, túl könnyen jutnak adathoz, heterogén környezetben, a nagy adatdemokratizálódás útján. Az ETL, önmagában, önnön önminőségéből fakadóan definitive garantál bizonyos fékeket, amiknek vannak/lehetnek pozitív szempontjai is, nemcsak negatívak. Egy VirtDB vélhetően jóval kisebb kikényszerítő erővel hat egy vállalati MDM-re, mint egy ETL.


Megoldás-alternatíva:

+ Termék és termékarányos rendszerkonszolidációt kell értékesíteni, számonkérni objektív cost-benefit alapokon (nemcsak úgy l'art pour l'art).

+ Pontosan kell tudni mi legyen általános/generikus és mi specifikus egy ETL-projektben.
* Vagy mindent egy job csinál univerzális kalapácsként (túl általános)
* Vagy mindent spéci job-ok csinálnak (túl spéci)
* Kettő között van vélhetőleg az arany középút
* Egyfelöl: csak olyan legyen általános, amihez nem kell nyúlni (konfiguráláson túl). Vagy hozzányúlásnál teljes impact analizis és teszt, majd konzisztens állapotra hozás.
* Másfelöl a spéci job-okat objektumkönyvtárhoz hasonló "elemkönyvtár best practice"-szel lehet érdemes megtámogatni, hogy ha már spéci a job, csak integrálás legyen lehetőleg.

+ Agilisen NEM fejleszteni overhead-generáló és/vagy szabványkönyvtárból elérhető funkcionalitást.
* Komoly vesszőparipám idevágóan például, hogy custom-logolót semmiképpen nem szabad fejleszteni agilis projektben, ha egyszer létezik egy log4j.
* Nem gondolnám, hogy egy agilis projekt nem tud eltartani egy custom-logolót: meg lehet próbálni csak a kockázat nem tünik arányosnak várható eredménnyel.
* Nem hiszem el, hogy agilisen jobbat lehet adni egy log4j-nél, "majd mi megmutatjuk alapon".
* Egyik érv az szokott lenni, hogy kevesebb info kell, mint amit a log4j ad (ami túl sok és rapid módon nő), amire gyógyszer lehet az log-eszencia-képzés és policy-s szabályozás:
(1) kimazsolázás után minden adat szükségesen elégségesen álljon rendelkezésre
(2) majd szigorú törlés / kiarchiválás
* Másik érv szokott lenni, hogy szükséges infót meg nem tud mindig kiadni magából (pl.: table reccount forrás és céloldalon). Ugyanakkor nehezen emészthető, hogy ez miért implikáljon custom logolót.
* Én abban hiszek, hogy aggregálós eszenciaképzés után egy komplexebb view-val bármilyen ETL-operációs dashboard kiszolgálható.

+ Legyen jól felépített az agilis fejlesztés szervezetileg is
* Vagy minden fejlesztő egyenrangúan jól csinálja az overheadet érintő dolgokat (pl.: deploy, névkonvenció etc) és azért mert jó policy folytán ez egyszerű, bolondbiztosan hibamentesen elvégezhető.
* Vagy legyen a Java-ban megszokott deployer/release-maintenance-r aki a darabra elkészült termékeket, csomagokat, komponenseket, verziókat, (név)konvenciókat admin hatókörrel "kordában" tartja, mellékhatásokat feltérképez, menedzsel etc.
* Semmi sincs ingyen másképpen szólva szűznek maradva nehéz kurválkodni. Ha nincs jó fejlesztési policy ÉS nincs semmiféle agilis projektpusztulás-gátlás az egyértelműen a káoszba visz.

+ Continuos integration adaptálandó, release managementtel, megfelelően rendesen szétválasztott DEV-PROD környezetekkel.
* Egyik végletes megközelítésben, jó policy-k esetén ezt a bekezdést ki sem kell fejteni. ;)
* Másik végletes megközelítésben túl sok lokál-specifikum lehet a történetben, hogy általános célú poszt foglalkozzék vele.
Én mindenesetre most kihátrálok belőle azzal a jelszóval, hogy külön posztot érdemel. :DDDD Az igazság az egyébként, hogy egyelőre nem tudtam rendbetenni a témát magamban.

+ Technikai hibák magas szinten katalógusosan kategorizálandók legyenek ne nyers error-message legyen csak és legyen hozzá todo is.

 Örök memento hogyan ne... ;)

Pro: programozási nyelvek és adatbányászat kölcsönhatásai

.
Ugye nem kell hangsúlyoznom, hogy a téma rendes kifejtése PhD-szintű tézis-hegyeket igényel ;) Meg sem kísérlem a téma bemutatását még villantás erejéig sem, ebben a rövid ám annál szubjkektívebb posztban, így augusztus 20-dikai ünnepnapon (amikorra annyi mindent terveztem, csak éppen ezt a blogposztot nem).

Comming Out következik: magam részéről azt gondolnám, hogy Földi Tamás (Starschema, fejlesztési vezető) hatása alól nehéz kivonnia magát az embernek.

Elsőként 2010-ben tapasztalhattam meg ezt, igen fájdalmasan impresszív módon. Együtt dolgoztunk egy párhetes GE-s ETL/DB migrációs projekten ("gyenge" 1.400 migrálandó job-bal). Én mint PlSql-Developer fan meg kellett éljem egy minden optimalizációnak ellenálló végtelenül lassú Oracle-töltésnél (hiszen Tamáshoz már csak végstádiumban betegeskedő job-ok kerültek), hogy a szerintem bár Delphiben íródott ám "orákulumos fejlesztésre alkalmatlan lomha" TOAD for Oracle-ben 6.5 perc alatt kivitelezett tervszerűen és komplexen összefüggő egérklikk és billentyűleütés-interakció-sorozat nyomán kezesbáránnyá szelidült a jobtöltés. PlSql Developerben többet lehetett volna küszködni ezen, de legalább esélyesen eredménytelenül, a szükséges infók megfelelő kicsalogatásának hiányában.

Aztán annó láttam egy Starschemás-álláshirdetést (még a Profession.hu-n), ahol előny volt a jelentkezőknél, ha Clojure, Scala, Haskell, Erlang megvolt nekik. What the fuck? Mit szívtak Tamásék ott a BI-fellegvárban? [Mindegy, nekem dupla adag kell belőle :D]
Én az egyetemen küszködve abszolváltam a LISP funkcionális nyelves kurzust, ha valami távolállt tőlem az ez volt, meg is fogadtam, hogy bármi jöhet, de ezt soha többé ne lássam.
Erre egy magyar álláshirdetésben ezt látom. Halkan, bekezdést bezáróan megjegyezném, hogy hatalmas ütésekkel dörömböl a Starschema-kapun a Clojure-s állásinterjúk világa (az "előnyből" hovatovább elvárás lesz), azaz komoly a dolog, "mivel viccnek kicsit durva lenne" (vö.: a székely favágós vicc)

Aztán egyszercsak azt veszem észre, hogy elvégeztem egy internetes Clojure-s kurzust és imádtam, a szó legszorosabb értelmében (kikapcsolódásnak is, agyserkentésnek is kiváló volt). Terveztem erről írni, egy hosszabb, mélyebb blogposztott, de egyelőre az egyéb másirányú elfoglaltságok ezt elsodorták. Informatikus kollégák láthatóan/érzékelhetően determináló komoly rétege "esküszik" a funkcionális programozási nyelvekre (az évtizedek óta létező LISP napvilágra jöttétől: basszus kulcs egy Autocad internal script nyelve bír lenni.)

Aztán mit kell lássak a Clojure brutális (és jogos) térnyerésén felül? Hogy egyre-másra jelennek meg a Data Analysis/Science könyvek ezekkel a programozási nyelvekkel (Clojure kezdte, Scala folytatta, majd a Haskell és most futottam bele egy Erlangos neurális hálós könyvbe). Nem linkelem őket (az utóbbit leszámítva, hiszen miatta született ez a poszt), neten megtalálhatók. Én bizony azt látom, hogy ez a téma nagyon erős figyelemfókusz-/erőforrás-allokációt követel magának egyre inkább. Mondjon bárki-bármit, ez bizony nem hype-nak tűnik, hanem valós forró témának: az a bizonyos közmondásos csizma nagyon odakerült az asztal közepére.

Nyilván rohamléptekkel fejlődik a programozási nyelvek tudománya is, lassan a magyar nyelvre is lehet compilert írni (kis túlzással). Nagyon fontos az informatikában - adatbányásznak aztán különösen - hogyan fogalmazza meg az abszolválandó  feladatot, és aztán ezt milyen - plaszticitású - nyelven teszi meg, nagyon nem látszik mindegynek.Sosem téveszthetjük szem elöl egy jó kérdés, egy feladatmegfogalmazás / problémafelvetés, sokszor félsiker, azaz érdemes ezt megtámogatni, ha kell nyelv oldaláról is (tök logikusan egyébként, szvsz).

Adatbányászat nagy kihívásai című 2010-es számomra máig talán legkedvesebb blogposztomban 40 tételben szedtem össze a kihívásokat (amiből ugye a funkcionális nyelvek vagy a LISP említése, hogyhogynem kimaradt). Földi Tomi maximális és kizárólagos "bűne", hogy a funkcionális nyelvek számomra (is) elvitathatatlanul odakívánkoznak 41-diknek, a kihívások közé.

Pár idézet-mazsola az említett Erlangos NN-s könyvről, felcsigázásnak.

Handbook of Neuroevolution Through Erlang, 2013, 898 pages
http://www.springer.com/us/book/9781461444626
With 300/4MB example source codes:
https://github.com/CorticalComputer/Book_NeuroevolutionThroughErlang

Erlang-site:
http://www.erlang.org/

Dacker B (2000) Concurrent Functional Programming for Telecommunications: A Case Study of Technology - Introduction. Masters thesis KTH Royal Institute of Technology Stockholm.

A list of features that a neural network based computational intelligence system needs
01.The system must be able to handle very large numbers of concurrent activities.
02.Actions must be performed at a certain point in time or within a certain time.
03.Systems may be distributed over several computers.
04.The system is used to control hardware.
05.The software systems are very large.
06.The system exhibits complex functionality such as, feature interaction.
07.The systems should be in continuous operation for many years.
08.Software maintenance (reconfiguration, etc) should be performed without stopping the system.
09.There are stringent quality, and reliability requirements.
10.Fault tolerance

Erlang was created to 
* develop distributed
* process based
* message passing paradigm oriented
* high availability
* robust
* fault tolerant
* concurrent systems
* used to build massively scalable soft real-time systems.

Joe Armstrong (2003)
Making Reliable Distributed Systems in The Presence of Software Errors.
The Royal Institute of Technology Stockholm, Sweden, (PhD thesis).

Erlang-alkotótól, hogyan támogassa a fentieket az akkoriban új (Erlang) nyelv:

Encapsulation primitives — there must be a number of mechanisms for
limiting the consequences of an error. It should be possible to isolate processes
so that they cannot damage each other.

Concurrency — the language must support a lightweight mechanism to create
parallel process, and to send messages between the processes. Context
switching between process, and message passing, should be efficient.
Concurrent processes must also time-share the CPU in some reasonable
manner, so that CPU bound processes do not monopolize the CPU, and prevent
progress of other processes which are “ready to run.

Fault detection primitives — which allow one process to observe another
process, and to detect if the observed process has terminated for any reason.

Location transparency — If we know the PId of a process then we should be
able to send a message to the process.

Dynamic code upgrade — It should be possible to dynamically change code in
a running system. Note that since many processes will be running the same
code, we need a mechanism to allow existing processes to run “old” code, and
for “new” processes to run the modified code at the same time.

With a set of libraries to provide:

Stable storage — this is storage which survives a crash.

Device drivers — these must provide a mechanism for communication with the
outside world.

Code upgrade — this allows us to upgrade code in a running system.

Infrastructure — for starting, and stopping the system, logging errors, etc.

Itt van a lehető legegyszerűbb NN-program Erlangban, házi feladat C-ben reprodukálni :D

-module(simplest_nn).
-compile(export_all).

create() ->
    Weights = [random:uniform()-0.5,random:uniform()-0.5,random:uniform()-0.5],
    N_PId = spawn(?MODULE,neuron,[Weights,undefined,undefined]),
    S_PId = spawn(?MODULE,sensor,[N_PId]),
    A_PId = spawn(?MODULE,actuator,[N_PId]),
    N_PId ! {init,S_PId,A_PId},
    register(cortex,spawn(?MODULE,cortex,[S_PId,N_PId,A_PId])).

neuron(Weights,S_PId,A_PId) ->
    receive
        {S_PId,forward, Input} ->
            io:format("****Thinking****~n Input:~p~n with Weights:~p~n",[Input,Weights]),
            Dot_Product = dot(Input,Weights,0),
            Output = [math:tanh(Dot_Product)],
            A_PId ! {self(),forward,Output},
            neuron(Weights,S_PId,A_PId);
        {init,New_SPId,New_APId} ->
            neuron(Weights,New_SPId,New_APId);
        terminate ->
            ok
    end.

    dot([I|Input],[W|Weights],Acc) ->
        dot(Input,Weights,I*W+Acc);
    dot([],[],Acc)->
        Acc;
    dot([],[Bias],Acc)->
        Acc + Bias.

sensor(N_PId) ->
    receive
        sync ->
            Sensory_Signal = [random:uniform(),random:uniform()],
            io:format("****Sensing****:~n Signal from the environment ~p~n",[Sensory_Signal]),
            N_PId ! {self(),forward,Sensory_Signal},
            sensor(N_PId);
        terminate ->
            ok
    end.

actuator(N_PId) ->
    receive
        {N_PId,forward,Control_Signal}->
            pts(Control_Signal),
            actuator(N_PId);
        terminate ->
            ok
    end.

    pts(Control_Signal)->
        io:format("****Acting****:~n Using:~p to act on environment.~n",[Control_Signal]).

cortex(Sensor_PId,Neuron_PId,Actuator_PId)->
    receive
        sense_think_act ->
            Sensor_PId ! sync,
            cortex(Sensor_PId,Neuron_PId,Actuator_PId);
        terminate ->
            Sensor_PId ! terminate,
            Neuron_PId ! terminate,
            Actuator_PId ! terminate,
            ok
    end.

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.