Agilis BI-munkaerő skálázása

.
Sikerült egy olyan rövid címet találnom, ahol úgy van minden szón hangsúly, hogy mégis lefedi posztbeli mondandóm lényegét. Nem volt könnyű, sok cím-kandidálót el kellett dobni hozzá.

Megjegyzés: A továbbiakban "cég"-nek hívom azt a helyet, akinek fókuszban van a BI-munkaerő felskálázása. És "dolgozónak", akit aktuálisan felvettek munkaerőnek.

Alapállás:
Jelenleg inkább keresleti, mint kínálati a BI-munkaerő piac.
A miértek elemzése offtopik itt, valószínűleg súlyozottan szerepel az okok között, hogy nehéz meló meg az is, hogy sok cég nagy potenciált lát benne, évek óta, így jelentős éhség lehet jó szakemberek iránt. Nem véletlen, hogy hiányszakma mivolt ellenére is elég jó pénzeket lehet vele keresni publikus infók alapján is, még itthon is, nemhogy egy USÁ-ban.
Az egy spéci aspektus, hogy egyre többen egyre jobban értenek (BI-)informatikához is, meg próbálnának ebből megélni, immáron angol tudással is akár.
Mégis észrevehető két nagy "halmaz", aminek mintha nagyon kicsi lenne a metszete, ahol találkozna a kereslet a kínálattal.

Propozició:
Ha pedig ez a helyzet, esetleg belső feszültség is terheli az alkalmazó cégek kiválasztási folymatait, akkor érdemes lehet új szemléletben gondolkodni. Eddig klasszikusan az volt jellemző (tapasztalatom szerint), hogy nehézkes, lassú, költséges kiválasztási folyamatban próbáltak rendet vágni egy-egy állásra  jelöltek közül.
Mi ennek az ellentettje?
Töröljük el ezt a nehézkes folyamatot: pár "egyszerű"(értsd egyszerűbben biztosítható) szabállyal próbáljunk meg minden minimumot teljesítő jelentkezőt alkalmazni. Ne egy tévedős, hibázós kiválasztási folyamat, hanem a való élet rendezzen alkalmassági kérdéseket.

Propozició:
A kiválasztás során a cégek két hibát próbáltak ugye elkerülni, az elsőfajút [olyat nem alkalmazni, akit kellett volna] és a másodfajút [olyat alkalmazni, akit nem kellett volna].
A gond az, hogy míg például az angol tudás nagyon könnyen tesztelhető (csak egy angolul tudó ember kell a cégnél), addig a szakmai kvalitások nagyon nehezen.
A 30+ év alatt, amit a pályán eltöltöttem, volt 20 effektív munkahelyem, 30+ effektív projekttel, így rengeteg (szakmai) kiválasztási folyamatban vettem részt (mindkét oldalról). Azt gondolom mindegyik nagyon messze volt az általam ideálisnak tartottól. Jellemző hibák abban voltak, hogy
(1) nem fontosat és/vagy
(2) például módszertani hiányosságok miatt nem jól mértek és/vagy
(3) nem hozzáértően, szakszerűen.

Propozició:
Milyen szakmai skilleket értek BI-munkaerő alatt, e posztbeli kontextusban?
+ OS=Operating System
+ ERP=Enterprise Resource Planning
+ DB, (O)(R)DBMS=(Object-Oriented) (Relational) Database Management System, MPP=Massively Parallel Processing
+ NoSql=No Structured Query Language (SQL-komplementer világ).
+ Streaming and Graph Databases
+ In-Memory Data-Grid
+ Lambda-architecture
+ ETL, ELT=Extract &Transformation & Loading
+ CDC=Change Data Capture
+ State Machine Replications
+ Virtual Databases
+ Message Queuing
+ Client-Server Riporting & Dashboard adatpornó
+ Data Science
+ Hadoop, MapReduce
+ Parallel Programming
+ Reverese Engine
+ Programozási nyelvek (legyen itt egy bővebb felsorolás, de ez persze bővíthető tetszés szerint: SQL, 4GL-ek, C++, Java, JavaScript, Funkcionális nyelvek pl.: Clojure, Haskell, Elixir, Python, R, Julia. Én szeretnék köztük látni olyanokat, mint Go vagy D, és pl.: Javascriptet még tévedésből sem, de az élet nem hallgat rám :D).
Fontos ennél a pontnál megjegyezni, hogy a skilleknek nagyon széles spektruma van a juniortól a használható tudáson át az expert-szintig (ami magába foglal olyan eszközspecifikus pokolbugyrokat, ami felé földi halandó ritkán téved el)

Propozició:
Nagyon nehéz a posztbeli feladat, nagyon sok szempont mentén lehet optimalizálni, sokszor kellhet iterálni, dinamikusan javítani. Ez ekvivalens avval, hogy óriási vitákat is tudhat generálni  ;)

Szemünk elött napjainkban zajló potenciális PARADIGMA-VÁLTÁSOK:

(1) Korábban megszerzett tudás alacsonyabb értéke, tanulási ("felszippantási") hatékonyság magasabb értéke. Jóval értékesebbé válik az az ember, aki esetleg nulláról zöldmezősen kezd valamit, de nagyon rövid időn belül értéket tud termelni. A kiválasztási folyamatot ez perdöntően befolyásolhatja (nem tudás, hanem tudásszerzési képesség mérését követeli meg). Azért az egy kényelmesebb, stresszmentesebb jobb feladat annak eldöntése egy állásinterjún, hogy melyik jelöltbe fektetünk be szívesen (horribile dictu kisebb összeget) a kölcsönösen gyümölcsöző együttműködés érdekében. Ha nem jön össze, akkor a céges veszteség: fizetett tapasztalat a jobb kiválasztáshoz, ami korrekt visszacsatolásnál csökkenthető.

(2) Nem (generális) sémákban, hanem személyreszabottságban lehet érdemes gondolkodni. Hiszen a tehetség nem szereti a sémát, míg a személyreszabottság színesebb világát lehet értelmes mederbe terelni (nyilván nagyobb, komplexebb, nehezebb meló).

(3) Cost-benefit elemzés (visszaméréssel, folyamatba visszacsatolással) egyre inkább teret követelhet magának, józan észnek alaposan ellentmondva, hogy a mai napig nem jellemző céges-alapkészség ez. Mindig van mindennek értéke és költsége (overhead-e). Nem lehet kérdés, maximalizálni kell a (képzési) értéket, minimalizálni a céges és munkavállalói overheadet.

(4) Kisebb léptékű többféle/diverzifikált befektetést kell tenni a dolgozó munkaerő irányába. Régen egy csillagrombolós költségű SAS vagy SAP-tanfolyam vagy akárcsak egy rendesen végigvitt Oracle-tanfolyam horribilis költséget jelentett, ami értelemszerűen sokszor éves szintű röghözkötést jelentett. A cég fizetett, és elvárta a dolgozójától, hogy keresse meg az ellenértékét. Szerencsére a világ mára megváltozott. Jóval olcsóbban érhető el magas(abb)szintű tudás cserébe a röghözkötés is tudhat enyhülni, eliminálódni. Valamit valamiért.
És lássuk be ez a helyes irány. Egy munkaerő az emberi érző lény, többféle szükségletei vannak csak a munkahelyén is, azon felül is, hogy 1 hét alatt elvégez egy Oracle-kurzust. Támogatni kell őt értékkummuláló, értékőrzési folyamatában, megújulásában, ami sokkal komplexebb megközelítést kell megköveteljen a munkaadó cégtől.

Propozició:
Mi legyen a minimum, mire kelljen figyelni egy BI-munkaerő felvételénél, ha csak kizáró okot keresünk, minden potenciális jelölt jöhet?
+ Angol tudás. Ez ma már nélkülözhetetlen a versenyképességhez a globális piacon.Szokták mondani, hogy mi magyarok nagyon rosszak vagyunk idegennyelvtudás terén, ahol én dolgozom, oda lehet, hogy meg sem kísérlik a jelentkezést angol-tudás nélkül, mindenesetre, ahogy én tudom az angol miatt esik ki legkevesebb ember.
Én itt a blogon két szintet szoktam megkülönböztetni angol tudás kapcsán:
(A) Az "értés-centrikus"-at: olvasás, chat, írás, internetes kurzus érdemi értése, feladatok megoldása (hang alapján is).
(B) "Kommunikációra alkalmas"-at: meetingek, telefonkonferenciák, prezentálás, előadás, angolul rosszul beszélőkkel is.
+ Tanulási képesség felmérése
+ Azt kiszűrni, hogy valaki túl nagy befektetést igényel, túl kevés várható eredménnyel
+ Nem jól együttműködő. Lássuk be nem tud mindenki mindenkivel együttdolgozni. Az emberiség nem rokonlelkek halmaza. Sajnos elég széles lehet a nem-megfelelési spektrum.
+ Monotonitáshoz, egyedül dolgozáshoz való viszony felmérése.

Propozició:
- Fontos mérőszám lehet az oktatási modulok elvégzése a kollégák értékének pl.: ROI-t is kalkuláló számszerűsítéséhez (bérére vetítve). Hiszen két amúgy ugyanúgy teljesítő kolléga közül az a jobb, aki több területen is bevethető.

Propozició:
- Az agilis módszertan a tanulásban is bizony nagyon hasznos lehet, ad absurdum még az angol tanulásban is érvényesíthető az ereje.
- Igyekezni kellhet a jövőben jobb tanulási görbéket elérni céges szinten, Kétszer annyi idő, erőforrás, kétszer annyi (részben potenciális) értéket hozzon (és ne egységnyi ám hosszú idő és/vagy nagy pénzbefektetés után derüljön ki a nagy bukta egy rossz folyamat keretein belül.). Minden nagy monolitikus egységnél törekedni kellhet dekomponálni.

Propozició:
- Cél-e mindenkinek mindenhez értenie (pláne nem kellő mélységben):
- Az én felfogásomban szigorúan NEM a válasz. Sőt én az ellenkezőjét vallom, ha választanom kellene "igen" és "nem" között.
- Nevezetes vicc: egyre többet tudunk egyre kevesebbről, végül mindent fogunk tudni a semmiről.
- Kialakítható cégen belül egy olyan dolgozói struktúra, hogy mindenki csak avval foglalkozzon amire predesztinálva van, de mégis sose legyen kompetenciahiány, projekt-erőforrás allokálás során (egy adott létszám felett csak, persze).
- Van aki abban lubickol ha sok mindenhez ért "good enough" és élvezettel "switch"-elget köztük, meg tanul újabb vad dolgokat is akár.
És van aki abban lubickol, hogy annyira expert legyen, hogy ad absurdum a szoftvergyártó céggel is képes tud lenni érdemi kapcsolatot kiépíteni és/vagy képes megválaszolni minden nyitott kérdést a stackoverflow-n :). Persze kockáztatva az avulás kori nagyobb veszteséget is.
A munkaerő boldogságához ennek helyes kezelése létfontosságú, a nézetem szerint.

Propozició:
- Minden ujonnan felvett kollégáról tudható mégpedig az állásinterjú(-sorozat) alapján, hogy
(A) milyen előzetes tudásra lehet építeni (erősségek)
(B) kinek mire van affinitása érdeklődése. A fokozatosság elvét szem elött tartva lehet oktatási modult választani személyreszabottan (aki a vizualizálós csilivili világban érzi jól magát, azt elsőként nem például Talenddel kéne nyakonvágni. De persze ez fordítva is igaz lehet.)
(C) milyen skillre van égetőbb szükség a cégnél, azaz mi a management-érdek.
- Ebből következően minden kollégára lehet egy optimalizált csökkenő fontossági sorrendű szakmaközpontú prioritáslistát csinálni személyreszabottan mi(ke)t lenne legjobb leghamarabb elvégeznie (oktatási modulok közül, amit jóvá tud hagyni a dolgozó is, meg a management is.

Propozició:
Ezen a ponton vannak felvett embereink (pool-ba), akik ugyan bírnak (potenciális) értékekkel, de szabadon még nem allokálhatók munkára.
Feladat integrálni őket a cég-be mindenki számára minél hasznosabb 3 hónap próbaidőkitöltéssel.
A nézetem szerint ez az integrálás kétféle - máshol is ismert - megközelítéssel történhet:

(A) TopDown
- Ez a kurzus-centrikus, elmélettől-gyakorlatig menő integrálási mód.
- Én itt azt szoktam mondani, hogy nem kell feltalálni a vízet, számtalan jobbnál-jobb profi cég van, aki megfelelő erőforrásokkal, gazdaságosan tudnak online trainingeket nyújtani.
- Mint mondottam volt, én jobban kedvelem a külső kurzusokat, mint a cégen belül adhoc összehozottakat, de elképzelhető, hogy a cég adott szempontok alapján akarja eröltetni a belső kurzusokat is. Ebben az esetben is az Internal & External kurzusok arányának jó kikeverése fontos szempont lehet.
- Előny, hogy egy-egy ilyen - sokszor funny - external kurzus a feladatokkal elvégezhető önállóan.
- Persze kérdéseket is lehet feltenni meg válaszokat nyerni cégen belül különböző csatornákon, nagyban segítve az integrációt, egymás jobb megismerését.
- Egy ilyen skill-t építő modulban tehát a cég márcsak kérdés-válaszolás, ellenőrzés, házifeladatok, vizsgák és kiértékelések szintjén lép csak be, ami töredék költség, ahhoz képest. mintha magát a tanfolyamot is neki kéne biztosítani.
- Akkor tekintem sikeresnek a scenáriót, ha a modul végén a modul-skillben hadrafogható lett az a dolgozó (nem expert, de juniornál több).
- Hogy ennek mi az átfutási ideje? Sok paraméter miatt nehéz biztosan jót mondani, de azt gondolom alsó korlát (aminél rosszabb nem lehet) a próbaidős 3 hónap alatti legalább 1 modul elvégzése. Ha ez nem jön össze ott valami alapvető probléma kell legyen. És ha van ilyen adalék, akkor a 3 hónap próbaidőt lezáró one2one megbeszélés tudhat miről szólni.
- Motiváció lehet, akár még a Courserá-n is, certifikáció fizetése, költségtől függően mondjuk legalább az első certifikáció. Ami segíti a win-win szituáció kialakulását cég és dolgozói között.

(B) BottomUp
- Ez az az eset, amikor valakit valós projekt során agilisen képezünk ki, akár úgy hogy könnyebbtől nehezebbig terjedő feladatokkal integráljuk őt. Akár mentoron keresztül képezzük a dolgozót, segítve, hogy felszippantsa a szükséges dolgokat.
- E módinak óriási előnye:
(A) céges oldalról, hogy pénztermelésben segít az új ember
(B) dolgozó oldalról, olyan plusz infókhoz jutha, ami nincs benne az online kurzusokban, meg végtelen számú amazon.com-ról rendelhető könyvekben. Mindezt az expertté válás következő szintjén.
- Menete lehet az, hogy a projektvezető úgy érzi ki tudna valakit venni a poolból, olyan az aktuális terhelés minősége, amit már csak le kell egyeztetni managementtel, dolgozóval.
- Ennél az iránynál az erősen kerülendő, ha
+ nagyon sokat kell indulásként magyarázni (nagy overheaddel),
+ folyamatosan túl sok kérdés merül fel
+ akadozik és/vagy kevés az önálló munka
+ majd hirtelen máshová kell átcsoportosítani a dolgozót, cég-szinten.
Ilyenkor két ember munkája is mehet a levesbe (mentoré és junioré egyaránt). Uramatyám mennyi erőforráspocsékolást láttam már az évek során, ilyenkor a szomorúság jeges marokkal facsarja a szívemet.
- Azaz mentori erőforrásokat e bottom-up projektcentrikus oktatásnál lehet inkább érdemes felhasználni (ilyen nem beszerezhető a netről), az én tárgyalt nézetem szerint. E mentori erőforrás lehet sőt kell legyen cég-specifikus (hf/vizsga/projekt).

Propozició: kiégés management, elvándorlás-minimalizálás kontextusában is.
Na ez komoly vesszőparipám, az egész posztbeli gondolatmenet legkritikusabb pontja, amin állhat vagy bukhat az egész.
- Nagyon kell figyelni az emberi oldalra, kiégés és/vagy elhasználódás kapcsán. Ha el is megy a dolgozó, cél legyen az, hogy azonos vagy pláne jobb állapotban menjen el a dolgozó, nem leamortizálva, feltéve, hogy a cég ilyen szempontú image-e fontos.
- Jó legyen a projekt, aminek ismérvei:
(A) Jó ha zöldmezősen a cégünk kezdi és viszi éveken át mindig optimumközeli állapotban tartva, amiben implicit pozitiv visszacsatolás éppúgy van, mint komoly tapasztalat, no persze a megkeresett pénzen felül (hiszen éhen halva ezt nem lehet csinálni).
(B) A következő legjobb, ha mások "szemetét" tartjuk karban, pisztergáljuk, brute force. Hiszen a megrendelő lavírozta magát rossz helyzetbe, nem mi a szállító. Felelősség-stressz minimalizálása miatt.
(C) Saját "szemet"-ünket tartjuk karban, egyre nagyobb agilis divergálás mentén. Felelősség is nagy, a káros stressz is nagy. A divergálás miatt, az idő múlásával akár progresszíven is lassulunk, egyre többet hibázunk, hosszú távon elégedetlenek leszünk a világgal majd magunkkal hiszen ugyanazért a pénzért egyre többet és/vagy rosszabb minőségű dolgot kell tenni.
- Konklúzió: egy karbantartott jólmenedzselt horribile dictu optimumon tartott  jó rendszeren jobb dolgozni. Jó ha minél kisebb az ideálistól való eltérés.
- Agilisen elszámolható tevékenység nagyobb aránya, értelemszerűen az elszámolhatatlanok rovására.
- Túl sok ilyen agilisen elszámolható tevékenység ne legyen, mert káros stresszhez vezet.
- Minél kevesebb (rossz) energiaégetéssel minél nagyobb üzleti érték. Ugye például egy tanulást én jóféle energiaégetésnek gondolok.
- Ne legyen a dolgozó szűk keresztmetszet (hosszabb távon)
- Ne legyen a dolgozó töltelék ember se (önbecsülés).
- Értékes legyen a tevékenység ne monoton csicskameló (hasznos stressz értékei fontossá válnak).
- Értékes tanulás legyen (ne a káros s*ggberúgás tapasztalata).
- Magáénak érezze az elégedettség érzésével az ember az elvégzett tevékenységet. Ne szalagszerű robotmunka legyen.
- Legyen jó "levegő" a (nagyobb) tevékenységek, mérföldek között, örülni az elvégzett munka felett, derüsnek lenni. Jó levegő alatt nem lébecolást értek, hanem értékképző relaxot.
- Relax lehetőség tehát végtelenül fontos, aminek jónak/sikeresnek kell lennie, természetesen személyreszabottan (ha nekem rapre vagy fifára kéne relaxálnom, bajban lennék).
- Tudás-elavulás lassítása. A cég olyan technológiákat alkalmazzon, amiben van fantázia és nem kukázódik rövid időn belül. 1-2 kukázás belefér, de a folyamatos és gyorsuló kukázás nagyon lelombozó és amortizáló tud lenni. Mondom ezt szakmából lassan kikopóként is.

Konklúzió: programozási nyelvek és adatbányászat kölcsönhatásai

.
Két korábbi blogposztomban pozitív és negatív megközelítéssel egyaránt próbáltam a témához közelíteni.
- Ez egyfelöl mutatta erős vívódásaimat meg hiányosságaimat (mennyire kevés vagyok a mérlegeléshez még magam számára is).
- Másfelöl kódoltan tartalmazza, hogy valami tévedésnek kell lennie, így muszáj valamiféle konklúziót vonni. Eredetileg tézis-antitézis-szintézis hármas jutott eszembe, de jó hogy elvetettem :)

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

Jelentem teljesen megtaláltam a lelkibékémet a témában, de nagyon meg kellett küzdeni, sokat kellett agyalni  hozzá. Ez az érzés annyira erős, hogy tudom vállalni az esetleges hibáit is a gondolatmenetemnek.

Az eszenciális főgondolat:
Ami az ETL-nek/Data Managementnek az SQL, az a Data Science-nek a funkcionális nyelvek.

Nyilván hibádzik ez a gondolat, hiszen
- nincs szó kizárólagosságról (vagyis hogy csak SQL-t vagy csak funkcionális nyelvet lehet használni nyilván nem igaz, bár az SQL nyilván meghatározóbb a saját területén belül)
- bár nagyságrendileg többtíz éve léteznek, a nagyobb és megalapozottabb karriert kétségtelenül az SQL futotta be, míg a funkcionális nyelveket csak mostanság kezdik data science-re is szeretni.
- életstabilitásuk is különbözik, hiszen az SQL minden nyűgje ellenére nehezen ignorálható (lásd hive), míg a funkcionális nyelveket egy új nyelv sokkal könnyebben elsöpörheti releváns ujdonságával.
- Agilis módszertanhoz való viszonyuk is más, sőt ellentétes. SQL-nél, ETL-nél sokkal problémásabb, míg data science-ben sokkal kívánatosabb lehet.
- Eltérő a felhasználótábor mérete, SQL-t használók tábora nagyságrendileg nagyobb, mint az összes funkcionális nyelv összes felhasználójának tábora, ez aztán semmiképpen nem könnyíti meg a konklúziót ;)

Amiért nekem mégis tetszik a párhuzam, hogy
- mindkettő magasszintű, általános, és problémára-fókuszáló
- MIT-et erősíti a HOGYAN helyett a feladatoknál
- "célszerszámok", abban erősek, amiért vannak.
- kívülesnek a szokásos 3GL paradigmán. Más megközelítésben: van releváns hozzáadott értékük a 3GL nyelvekhez képest.
- "nyelvi overhead"-minimalizálóak
- kódtömörség jó barátságban van a kódérthetőséggel, kódolvashatósággal
- mindkettőnek van erős open-source kötődése

Érdekes megnézni az alábbi programozási nyelves vizualizációt.
* Awk: inkább interakcióznak, mint publikálnak („nincs mit megosztani, csak megérteni való van?”).
* Elixir, Julia inkább megosztanak, mint interakcióznak, („minden triviális?”).
* R-ben inkább kérdeznek, mint megosztanak, ami a CRAN repository brutalitásan durva mérete miatt érdekes.
* Clojure, Haskell, Scala hiába nehéz programozási nyelvek, tartják az egyensúlyt, ráadásul R szintjén.
* Python, Java - magasabb szinten - egyre közelebb van egymáshoz, ami Java versenyelőnyének elvesztését vetíti előre (számomra).
      

FUNKCIONÁLIS NYELVEK KÖZVETLEN ÉRTÉKEI DATA SCIENCE-BEN

(1) Ember fontossága a zajjal bőségesen szennyezett információáradattal szemben.

- A data science-t végső soron emberek csinálják, még mindig ők a legfontosabbak az ilyen feladatok megoldásában. Az ő erényeik maximalizálása és gyengeségeik, korlátaik minimalizálása a cél.

- A humán kreatív agilis fejlesztőt ki kell tudni választani a sokaságból, könnyedén, gyorsan, megbízhatóan, jelenlétet nem megkövetelően.

- Kell tudni tesztelni a szakmai frissességet. Ehhez egy lehetséges út tetszőleges feladat tetszőleges funkcionális nyelvre portolása, még akár otthon is. Nyilván nem triviális egy ilyen feladatkiírás, de eleganciája azért bőven lehet érték.


(2) Nagy nóvum (számomra): prototípuskészítés korszerűsége, gyorsasága, eleganciája.

- Két eset van: valaki
(A) vagy ismeri az összes data science algoritmust high level, tudja hová kell nyúlni találat esetén, és tudja megmondani, hogy errre és erre jelenleg nincs jó algoritmus fejleszteni kell.
(B) vagy "brute force" elkezd dolgozni az adataival. Beolvassa, azonnal (biztonságosan) párhuzamosan manipulál rajtuk magas szinten, keresi, elhatárolja az univerzális és speciális feature-eit.

- Nem kell, hogy optimális legyen a prototípus, csak könnyedén verifikálható legyen a adatbányász-gondolat helyessége az aktuális dataset-re. Persze eljöhet a pont, hogy annyira jó a cucc, hogy megéri C-ben performanciára optmalizáltan is lefejleszteni, de ez itt offtopik.

- Legyen bármilyen morbid, de kössük össze egy példában a régi jól bevált SQL-t a data science prototípus orientált funkcionális nyelvekkel. Vegyük hozzá az alábbi triviális Oracle Data Mining példát.
http://oracledmt.blogspot.hu/2006/05/sql-of-analytics-1-data-mining.html

SELECT A.cust_name, A.contact_info FROM   customers A
WHERE  PREDICTION_PROBABILITY(tree_model, ‘attrite’ USING A.*) > 0.8

* Ami jó ebben nyelvileg, hogy rövid, tömör, párhuzamos amennyire az Oracle leprogramozta.
* Szeretjük-szeretjük, de érezzük, hogy nem az igazi, ennyi elég egy ETL-s embernek, de nem elég a data scientistnek.
* Nem tudunk új paraméterrel tuningolni az algoritmuson.
* Blackbox az egész.
* Nagy az overhead, ha hozzá akarunk adni Oracle-hez saját algoritmus-ujdonságot.
* A data scientist hozzá akar(hat) nyúlni a modellépítéshez, saját következtetést akar(hat) a valószínűségekből.
* Ehhez meg nem monolit monstrumokon, hanem rugalmas kis prototípusokon vezethet egyfajta agilis út.
* Versenyelőnyhöz biztos nem ez az "előregyártott" Oracle út vezet.


(3) Agilitás sosem látott magasságokban tündökölhet data science-t illetően

- Pl.. prediktálásos célhoz vezető út rendkívül komplex, elágazásos, sok buktatóval, tévedési lehetőséggel, felesleges overhead generálással. Észre kell venni, rugalmasan és gyorsan el kell tudni szakadni olyantól is, ami ígéretesnek nézett ki A topdown feladatlebontás és bottomup agilitás konvergál leggyorsabban a legjobb eredményhez talán.

-  Egyik legnagyob pozitívuma, hogy minél kisebb overhead mellett minél jobban párhuzamosodjon az emberi fejlesztési élőmunka is, ne csak a gépi számolás. Ha a data science projekt megköveteli a gyorsaság érdekében a munka párhuzamosítását (lesznek tehát kidobandó branchek, amik csak tapasztalat szintjén épülnek be). Akkor keresve sem lehet jobbat találni a testre sőt személyreszabható agilis fejlesztesi módszertannál.

- Projekten belüli versenyhelyzet, kiválasztás a "dolgozók" között ("passzát szelet fújókra" illetve végrehajtókra). A Kaggle-t símán lehet háziversennyé szelídíteni, adaptálni.


(4) Megbízható, gyors, elegáns párhuzamos programozás.

Ezt - értelmezésemben - a Python sem tudja, mint "zöld kályha". Ha valamit akkor ennek fontosságát nem kell bővebben kifejtenem, betűkímélés céljából :)


(5) Nem igaz, hogy gyakoribb használatú nyelv jobb, szvsz.

- Konstruktivitás több, mint meglévő eszközök konstruktív csoportosítása, használata.

- Egy data science feladatban az univerzálist kell a speciálistól elkülöníteni és a speciálisra saját út lehet az üdvőzítő, amire kézenfekvő válasz a prototípus-építés. A saját útban meg benne foglaltathatik egy célraorientáltabb programozási nyelv, és ebben a saját útban kellhet maximálisan konstruktívnak lenni.

Akkora már a felhalmozott data science tudás, hogy nem lehet pusztán csak leírt betűkből dolgozni (információt aggregálni). Én ebbe a hibába bizony többször estem bele korábban: csak olvastam és olvastam, fejben építgettem, miközben elfogyott az idő.
Azonnal ki kell nyerni a speciálisat az adatokból, minél jobban, gyorsabban Ehhez út lehet a saját út versenyelőny-kovácsolással.


Végezetül elképzeltem egy agilis-centrikus forgatókönyvet, sci-fi faktor szerinti növekvő sorrendben: a valósággal való bármilyen múlt-jelen-jöbőbeli kapcsolata kizárólag a véletlen műve :DDDD

- Kaggle-versenyzés még működik, jellemzően domainfree alapokon. Értsd "értékesen" detektálható a "jobb" eredmény.

- Aztán ez a domainfree adhoc teljesítményfokozás összteljesítményben egyre kevesebbet jelent majd. Azaz amit érdemes javítani az "algoritmikusá válik" (ennek gyökerei ma is megvannak, hiszen a nyertesek publikálnak eredményeikről). Minden más meg kevésbé lesz érdekes, illetve előtérbe kerülnek egyéb szempontok, mint modell időben való állandósága.

- Aztán egyfajta decentralizálódás után fontosabb lesz a domainfüggő és enterprise-szintű megközelítés (és erre képesség meg út is lesz: ma még ez nincs az én értelmezésemben). Amikor nem csak a számok koherens tartalma lesz perdöntő, hanem az üzleti tudás témához való hozzáadott értéke viheti már a prímet.

- Később esetleg nem lesznek kétdimenziós táblázatok magyarázó és célváltozókkal, mert az előállításuk végtelenül költséges, meg végtelenül javítható.

- Később modell-paraméterezések is halványulnak.

- Hatalmas káoszban kellhet villámgyorsan rendet vágni, adatot gazdagítani.
Itt egy friss példa már a magyar nyelvű sajtóból. Ha volt ötlet, ami már nagyon várt arra, hogy valaki megcsinálja (első körben nyilván tisztességtelenül /bennfentes információk miatt/) az ez a "fantáziasport" cucc. Ennek még a policyjét sem lehetett semmi kitalálni, meg a mögötte lévő komplex informatikát, a nyerőstratégia megalkotásáról már nem is beszélve. Ehhez képest a Szerencsejáték RT totója, góltotója, tippmixe mára szóviccnek is gyenge, informatikásul, mindenestül (pedig így is szállítja rendesen a lóvét a költségvetésnek). Ugye nem kell hangsúlyozni a "káosz" és "gyorsaság" jelentőségét a példában.

- Lesz dolgozó szinten is elérhető sok-sok olcsó párhuzamosan dolgozó gép, elsőként gondolom a felhőkben.

- Lesznek priorizálandó és versengő taskok párhuzamosan.

- Ad absurdum a legkevesebb begépelt betűvel kell elérni legtöbbet minél biztonságosabb környezetben. A kevesebb hiba jótékonyan hat.

- Brute force és villámgyorsan meg kell zabálni a szerteágazóan heterogén inputot.

- Pl.: jelenleg mainstreamnek számító Python libhívások csak egy részét adják a teljes folyamatnak, de akár ignorálandók lesznek explicit ciklusok, változók, míg lambda-kalkulus vagy automatikus rekurzió vagy ki tudja még mi esetleg annál többször kerülhet előtérbe.

- (Nálam R-t is bőven verő) Python is veszít mainstream-erősségéből.

- Lesznek agentek akik - tetszik nem tetszik nekik, de - agilisen kipréselik magasabb cél érdekében a taskból amit tudnak.

- Lesznek irányítók, akiknek jól működnek a priorizáló ösztönei és ezt Kagglénál kisebb volumenű házi verseny keretében választódhat ki.

- Manipulálás kivédése, bekalkulálása/folyamatba integrálása gondolhatunk például a tőzsdei alkalmazásra.

- Egyediség felé minél nagyobb elmozdulás, univerzalitás keresésével szemben, hiszen az egyediből lehet a nagyobb versenyelőnyt kovácsolni jó eséllyel..

- Végsős soron egyfajta gyilkos versenyben, pilótajáték effekttel,  aki picivel hamarabb ér el ugyanolyan jó eredményt az nagyságrendileg többet kaszálhat az információs sztrádán.

SAS?

.
BME Választható tárgyak a big data világából

Végtelen szomorúsággal és értetlenkedéssel olvastam a fenti blogposztot. Annak is főleg az első felét: Alkalmazott adatelemzés-Applied Data Analysis. A második kurzus - 'Big Data' elemzési eszközök nyílt forráskódú platformokon - tanterve is tudhat kérdéseket generálni, de az legalább koncepcionálisan betonbiztos alapokon nyugszik.

Nagy csalódottságomban - humoros formában - feltettem céges belső slack-en, hogy mi a kakukktojás az alábbiak közül:

shell script, sed, awk, r, SAS, python, hive, pig

Az első azonnali reakció az volt, hogy az awk, mondván, hogy annak semmi értelme, míg a többinek van.

Egy következő reakció: SAS, mert az cégnév. :)

Nekem magamnak semmi bajom az AWK-kal, egy olyan legfrissebb  kdnuggets-es data sciences-felmérés után, ami a negyedik helyen hozza ki. Mondom ezt úgy is, hogy én sose fogom használni nyilván (bár sose mondd, hogy sose, mint tudjuk).

Analytics, Data Mining, Data Science software/tools used in the past 12 months
* Python, 30.3% share (837 votes)
* Java, 14.2% (392)
* C/C++, 260 (9.4%)
* Unix shell/awk/gawk, 8.0% (221)
* Other programming languages, 5.1% (140)
* Scala, 3.5% (96)
* Perl, 2.9% (79)
* Ruby, 1.2% (33)
* Julia, 1.1% (31)
* F#, 0.7% (18)
* Clojure, 0.5% (13)
* Lisp, 0.4% (10)

Azonban a SAS az egy teljesen másik sztori, többszörösen is. Ugye nem kell külön hangsúlyoznom, hogy nálam ez volt a kakukktojás.

1.
Az én világnézetemben, még ebben a felpörgött mai világban sem fér el a sed és a sas egy féléven belül, maximum filozófia-oktatás keretén belül (nem konkrétumok szintjén, hanem magasabb szinteken). Ahogy nem férne el a közgázon a mikróökonomia és makróökonómia, a műegyetemen a newtoni mechanika az atomfizikával. vagy matematikusoknál a funkcionálanalizis a szimplex-módszerrel.

Mondom ezt úgy, hogy SAS-on kívül a többi megfér egymás mellett elvi síkon (arányokon lehet vitatkozni persze).Egészen egyszerűen nem látom azt a közöst, amire felfűzhető a sed és a SAS, néhány előadáson belül.

2.
A következő problémám a visual flow tanítását én minden másban jobban el tudom képzelni, mint a SAS-ban (tematika szövege mondjuk nem említi explicit, de nem tudom elképzelni az elkerülését), még RapidMinerben is ezerszer inkább, pedig a SAS után ők vannak leginkább bögyömben, ideértve a legfrissebb licence-húzásukat (két free edition választásának lehetősége). Számomra a SAS semmi extrát különöset nem nyújt visual flow szinten, cserébe ott van viszont a SAS végtelen arrogáns, inkorrekt, extraprofit hajhászós túlárazós céges hozzáállása, ami oly sokat ártott és árt a data science világnak. Egészen egyszerűen a SAS rossz üzenet régóta és egyre inkább (az én felfogásomban). Bármilyen többi nem kakukktojáshoz hasonló visual flow-s open source cucc jobban megdobogtatná az olyan öreg szíveket, amilyen az enyém.

3.
A harmadik problémám,hogy mi a nemzetgazdasági haszna a GNI-ből (szándékosan nem GDP-t írok) finanszírozott SAS tanításának, preferálásának? Ki fog itthon SAS-t használni, hol, mekkora itthoni GNI nemzeti jövedelmet termelve (más kérdés, hogy a nemzeti jövedelem elköltése is bőven megérne egy misét, de ez itt most offtopik)?!

Számomra a SAS maximum az agyelszívás folyamatát tudja támogatni konstruktív értelemben.

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

.
Pár napja írtam egy pozitív-konstruktív megközelítést a témában. Ma olyanom van, hogy egy negatív destruktívat fogok írni  ;)

Azonnal felmerülő triviális kérdések:
- Lehet-e mérni egy programozási nyelv megválasztásának hozzáadott értékét a feladathoz (hogy miben oldjuk meg a feladatot)?
- Lehet-e összehasonlítani a programozási nyelveket értelmesen? Az biztos, hogy jó lenne, az is biztos, hogy nehéz feladat a megfelelő mutatók korrekt összevetése.
- Van-e valós tartalom új programozási nyelvek kreálása mögött, ha már 8.000+ programozási nyelv és ~dialektus van? Mekkora a hype-faktor a történetben? Nem kicsi, szvsz.
- Hogy néz ki az egész történet a data science kontextusában.Azt gondolom az adaton, az algoritmuson, hozzáálláson jóval több múlik.

1.Axióma:
Nem vagyok hajlandó aszerint minősíteni egy programozási nyelvet, hogy van-e utasítások mögött pontosvessző vagy nincs, vagy honnan indítja a tömb-indexelést 0-tól vagy 1-től. Ezek olyan finom felbontású dolgok, hogyha ezen a szinten dőlne el érdemben bármi is statisztikai relevanciával, akkor ezt egy másik blogposztban kell tárgyalni. ;)

2.Axióma:
Kizárólag profitcentrikus aspektusból vagyok hajlandó tárgyalni a kérdést, minden nem megoldott problémát ennek rendelek alá. Durván fogalmazva, érzelmek nem játszanak, ha Cobol a jó választás, akkor Cobol-t kell választani, rühelljem bármennyire is.

3.Axióma:
Nem vagyok hajlandó száműzni az embert a feladatmegoldásból, azaz feltételezem, hogy szükség van emberre, szakemberre, a kreativitásra, a gép önmagában nem elég 100%-os mértékben, jelen állás szerint.

4.Axióma:
Legfontosabb támadási pont, hogy miben alapítok a felhalmozott közösségi tapasztalatra, és miben alapítok a saját (vélt) remélhetőleg minél tartósabb lokálspecifikus lépéselőnyőmre. Minél jobb a szétválasztás, minél jobban/gyorsabban azonosítom őket, annál kisebb a költségem, annál nagyobb a profitom.

1.állításom:
Önmagában a programozási nyelv megválasztásával a legnehezebb valós tartós gazdasági előnyt kovácsolni, a teljes projektet nézve.
* kvázi minden programozási nyelvben kvázi minden megoldható, kvázi összevethetően.
* programozási nyelv mögötti közösség tömeg brutálisan jó indikátornak néz ki (inkább a közösségi tapasztalat előnyét hangsúlyozza az individuum zsenialitásával, lokálspecifikumával szemben).
* programozási könyvtárak legacy-hátrányai folyamatosan csökkenek, eliminálódnak
* nehéz tartósítani az esetleg megszerzett versenyelőnyt a kérdéses ismeretlen programozási nyelv használatával.
* nehéz felfelé skálázni az esetleg megszerzett versenyelőnyt
* az új programozási nyelv használatával implementált gazdasági előny feszültsége nagyon instabil, külső tényezők hatóereje miatt.
* sok kompromisszumot kell kötni minden egyes programozási nyelv használatával
* előbbit megfordítva nehéz azt mondani meglévő két programozási nyelvre, hogy "jobb" az egyik, mint a másik.
* nincs nagy léptéke a fejlődésnek, ugyanazt a*/@&#-t paszírozzuk 1950-es évek végétől, még a funkcionális nyelvek esetén is.
* lehet, hogy létezik nagy kiugrásra lehetőség, de ez nagyon nem látszik 60-70 év tapasztalata alapján.

2.állításom:
Egy (új) programozási nyelv kiváló eszköz lehet az agilis fejlesztő gyors pontos megméréséhez, minél könnyebb hadrendbe állításához. Mondom ezt akkor is, ha én elvéreznék egy ilyen teszten.
Tesztelhető, mérhető:
* Szövegértés gyorsasága, pontossága
* Kreativitás
* (Tapasztalat)integrálás készsége
* Prototípus-készítés minősége.

3.állításom:
Egy projekt áll ugye adatokból és algoritmusokból. Mindkettőnél komoly lokálspecifikus versenyelőny kovácsolható, miközben a közösségi tapasztalat jóval kisebb mértékben integrálható. Algoritmusoknál jóság, optimumközelség, overhead éppúgy, mint az adatoknál a zajtalanság, korrektség, teljeskörűség, minimalitás, konzisztensség, pontosság, dqm, tartósság terén.
Az egész pénzben számszerűsíthető (idő, költség, overhead, hiba tényezőkkel együtt is).
Analógia: Egy Oracle DBA max 10%-ot tud tekerni a rendszeren, azt is csak akkor, ha el van rontva előzetesen, míg egy alkalmazásfejlesztő nagyságrendekkel többet. Ugyanígy egy megfelelő programnyelvválasztás hozhat összességében a konyhára, de várhatóan nem az extraprofit kategóriában.

Tényezők, amik alapján összehasonlítanám a programozási nyelveket:
* Funkcionalitás, ökoszisztéma gazdagsága; hiszen az 50.000 Python-Library jobban hangzik, mint a 8.000 R Library, közösségi tapasztalat perspektívájának szempontjából.
* Integrálhatóság, Library, Kód, tapasztalat szintjén
* Script interpreting és Native compiling egyidejű megléte
* Általánoscélú, univerzalitás: SQL-ben nem megcsinálható feladat nem létezik, ugye ;), de azért általános célú nyelvnek nem mondanám.
* Programozási nyelv terjedésének rapiditása, kiterjedtsége, új további programozási nyelvek generálódásának fékeződése,
* Szakirodalom megjelenés gyorsasága, kiterjedtsége
* Releváns előny megléte a többi programozási nyelvvel szemben és/vagy kevés lehetőleg jelentéktelenebb kompromisszum.
* Prototípus-készítés könnyedsége
* Csoportmunka támogatása
* Párhuzamosítás/skálázás támogatása, könnyedsége, "hibataszítása"
* Set-at-home típusú lokális projektkezelés lehetősége.
* Continuos Integration minősége
* Szükséges processzor-erőforrás igénye a feladatvégrehajtáskor (mennyire kevés az overhead)
* Gépi kód minősége fordítás után (legyen minél kisebb, jobb)
* Mekkora távolság a magas szintű nyelv magasszintűsége és a gépi kód között. Minél nagyobb annál jobb, hiszen annál többet lehet elvégezni a géppel, annál több erőforrás jut az emberi kreativitásra
* Overhead magában a programozási nyelvben: egy Cobolban sokkal több a felesleges körítés. For ciklus hegyeknél egy lambda-kalkulus jóval elegánsabb.
* Mennyire örömteli más kódjának módosítása, hiszen nemcsak zöldmezősen kell fejleszteni. Gondoljunk bele, hogy ez még az SQL-nél is mennyire tragikus.
* Anyagi haszon, összevethetőség miatt, adott konstans projektnél, wing-to-wing számolva.

PS: Az "én" programozási nyelveim, amiket szeretek a sokezerből (Pascal és Python után, SQL-t nem számítva), erősen performancia-centrikus világnézettel:
- D (javított C) és ezerszer inkább, mint egy C++.
- Go
- Julia
- Clojure vagy Elixir

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.