.jpg)
.
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.
2015. szeptember 6., vasárnap
2015. szeptember 4., péntek
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
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
2015. augusztus 22., szombat
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... ;)
* 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... ;)
2015. augusztus 20., csütörtök
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.
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.
2015. augusztus 1., szombat
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.
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.
2015. július 8., szerda
"Policy Analysis" és vonzatainak egy olvasata
.
Kezdem a végével. Nem vagyok a kérdés szakértője. Azonban azt gondolom, hogy "politics analysis" maximálisan félrérthető fogalom. Számomra ez azt jelenti, hogy politológusok elemeznek történéseket objektív/szubjektív alapokon, nulla konszenzus felé konvergálva. Biztos jellemzőjük azonban, hogy az adatbányászathoz semmi közük, hiszen kevés adat miatt intuicióval pótolva az információhiányokat próbálnak elemezni, következtetéseket levonni, data scientist eszköztár nélkül.
A policy analysis viszont komoly tudománynak tűnik, az adatbányászat egy domain-specifikus területeként.
Másik oldalról a policy-nek többféle értelme van/lehet, míg az Obamacare egy valós konkrét policy-dolog, a policy-analysis egy sokkal generálisabb policy-fogalmat takarhat, többféle homonima-konfúzióval.
Azt gondolom abszolút valid felvetés az egyéni kontra listás képviselők elemzése "társadalmi jóság" szempontjából. Ha csak józan ész szerint gondolkozunk, akkor is érzékelhető, hogy különféleképpen jutnak pozicióhoz, más stratégia mentén kell nyerniük, mások a motivációs háttereik.
Egy listás képviselőnek egyedül a párthoz kell "igazodnia", ott kell tűzközelbe kerülnie, hogy még bejutó helyre tudjon kerülni a listán.
Egy egyéni képviselő jó esetben (tehát nem Magyarországon) független tudhat lenni a pártoktól, kvázi csak a körzetétől függhet (kisebb önkormányzatoknál ez még itthon is meg tud valósulni). De ha függ is párttól meg annak jóindulatától, mint mondjuk egy Tarlós István, olyan könnyen nem dobható ki, ha egyébként jól /jobban be van ágyazva a társadalomba, mondjuk egy összekoccanás után (lásd Lázár Jánossal való cicaharcokat).
Ha elfogadjuk tehát, hogy az egyéni és listás képviselő különböző "állatfaj", akkor következő lépésként azt kell meggondolni, hogy a társadalmi jóság célja lehet-e számukra azonos ("célváltozó"), azt gondolom igen: jó eszközökkel kell jó törvényeket hozni, kerülni kell az osbaságot, szemétséget, korrupciót, etc (kb. én ezt várom el társadalmi jóságként). Nyilván ezt egy boolean változóként megfogalmazni finoman szólva is kihívás. ;)
Az én konklúzióm: valid tehát a listás és egyéni képviselők data science szempontú "szembeállítása".
Az interpelláció a következő nagyon nehéz topik valóban. Azt nem mondanám, hogy egyetlen vagy legfontosabb indikátor, de az vezethet konszenzusra, ha azt mondjuk fontos indikátor.
Abban egyetértek, hogy interpelláció úgy lehet látható tevékenység, hogy közben kevéssé hatékony és vagy alkalmas komoly magyarázóerőre. Míg megfordítva, a háttérben machiavellista kavarógép lehet nagyon hatékony, miközben a felszínen semmi nem látszik tevékenységéből. Jó példa erre például Habony Árpád. Tegye fel a kezét, aki ismerte a nevét 2002-2006 között és/vagy most is ismeretlen a neve elötte. ;) Ráadásul még csak nem is képviselő. ;)
A harmadik topikhoz én annyit tennék hozzá, hogy a politikusokról rengeteg betű lát napvilágot. Valódi text majd data mining kincsesbánya :) Nehezen lehet azt mondani, hogy nincs adat. Még magyarországi léptékben is tudhat "big data" lenni, pláne, ha figyelembevesszük az EU-s vonatkozásokat is. Az, hogy a sok információ alapján milyen magyarázó- vagy célváltozókat veszünk modellképzés során, az egyrészt nagyon nehéz feladat, másrészt távolról sem lehetetlen küldetés, szakmailag jót csinálni.
Mostanság, ami nagyon forró topik lehet, korrupció-analízis publikus adatok alapján. Azt gondolom nagyon nehéz alábecsülni a téma jelentőségét.
Komment-1: "A közpolitika elemzés nem csak a vállalt és tényleges politikai tevékenység közti különbséget nézi, hanem az alapvető politikai tevékenység tulajdonságát, meg pl. a policy making folyamatot (milyen jelenségre milyen válasz, külso környezeti változók, stb). Nemzetközi tanulmányok mestert végeztem. Nem mintha sok értelme lett volna..."
Komment-2: " http://www.budapestinstitute.eu/index.php/hu "
Data Scientist állásinterjú.
A srác CV-jében skill: „policy analysis”
Gondoltam rákérdezek, ha már fogalmam sincs mit takar ez.
Tegye fel a kezét, aki továbbolvasás nélkül tudja mi fán terem a „policy analysis”? ;)
Na akkor megosztom: (Köz)politika elemzése
Ilyen kérdésekre próbál többek között választ keresni, parlamenti azonnali kérdések, interpellációk stb. alapján, hogy mennyire (másképp) aktív az egyéni listán bejutott képviselő a listás képviselővel szemben.
**********************************************
"Üzleti" szempontból van-e ilyen kutatásnak értelme, egyéni képviselőt szembeállítani a listással? hiszenAz alábbi diskurzus történt a minap. És ugyan értelemszerűen nincs nálam a bölcsek köve, hogy egyértelműen tisztázhassak minden felmerülő kérdést (hiszen biztos vitatható lesz amit mondok), de olyan érdekesek a felvetett kérdések, hogy blogposztért kiáltanak. :)
1) nem az aktivitás függvénye az egyéni kontra listások aránya, ezért nem látom az eredmény-magyarázóváltozó közötti összefüggést ebben a vizsgálatban
2) nem tudom, hogy az interpelláció az egyetlen és megbízható indikátor a teljesítménymérésben (lehet olyan, hogy háttérmunka, vagyis a képviselő nem szólal fel de ettől még dolgozik, pl. fogadóórákat tart stb)
3) arra lehet jó egy ilyen, hogy kiértékeljük a számokat. de akkor ez egyszerű leíró statisztika, nem?
+1 kötözködés: policy helyett inkább a politics lenne a helyénvaló mert a policy alatt olyat kell érteni mint pl. Obamacare. szerintem.
Kezdem a végével. Nem vagyok a kérdés szakértője. Azonban azt gondolom, hogy "politics analysis" maximálisan félrérthető fogalom. Számomra ez azt jelenti, hogy politológusok elemeznek történéseket objektív/szubjektív alapokon, nulla konszenzus felé konvergálva. Biztos jellemzőjük azonban, hogy az adatbányászathoz semmi közük, hiszen kevés adat miatt intuicióval pótolva az információhiányokat próbálnak elemezni, következtetéseket levonni, data scientist eszköztár nélkül.
A policy analysis viszont komoly tudománynak tűnik, az adatbányászat egy domain-specifikus területeként.
Másik oldalról a policy-nek többféle értelme van/lehet, míg az Obamacare egy valós konkrét policy-dolog, a policy-analysis egy sokkal generálisabb policy-fogalmat takarhat, többféle homonima-konfúzióval.
Azt gondolom abszolút valid felvetés az egyéni kontra listás képviselők elemzése "társadalmi jóság" szempontjából. Ha csak józan ész szerint gondolkozunk, akkor is érzékelhető, hogy különféleképpen jutnak pozicióhoz, más stratégia mentén kell nyerniük, mások a motivációs háttereik.
Egy listás képviselőnek egyedül a párthoz kell "igazodnia", ott kell tűzközelbe kerülnie, hogy még bejutó helyre tudjon kerülni a listán.
Egy egyéni képviselő jó esetben (tehát nem Magyarországon) független tudhat lenni a pártoktól, kvázi csak a körzetétől függhet (kisebb önkormányzatoknál ez még itthon is meg tud valósulni). De ha függ is párttól meg annak jóindulatától, mint mondjuk egy Tarlós István, olyan könnyen nem dobható ki, ha egyébként jól /jobban be van ágyazva a társadalomba, mondjuk egy összekoccanás után (lásd Lázár Jánossal való cicaharcokat).
Ha elfogadjuk tehát, hogy az egyéni és listás képviselő különböző "állatfaj", akkor következő lépésként azt kell meggondolni, hogy a társadalmi jóság célja lehet-e számukra azonos ("célváltozó"), azt gondolom igen: jó eszközökkel kell jó törvényeket hozni, kerülni kell az osbaságot, szemétséget, korrupciót, etc (kb. én ezt várom el társadalmi jóságként). Nyilván ezt egy boolean változóként megfogalmazni finoman szólva is kihívás. ;)
Az én konklúzióm: valid tehát a listás és egyéni képviselők data science szempontú "szembeállítása".
Az interpelláció a következő nagyon nehéz topik valóban. Azt nem mondanám, hogy egyetlen vagy legfontosabb indikátor, de az vezethet konszenzusra, ha azt mondjuk fontos indikátor.
Abban egyetértek, hogy interpelláció úgy lehet látható tevékenység, hogy közben kevéssé hatékony és vagy alkalmas komoly magyarázóerőre. Míg megfordítva, a háttérben machiavellista kavarógép lehet nagyon hatékony, miközben a felszínen semmi nem látszik tevékenységéből. Jó példa erre például Habony Árpád. Tegye fel a kezét, aki ismerte a nevét 2002-2006 között és/vagy most is ismeretlen a neve elötte. ;) Ráadásul még csak nem is képviselő. ;)
A harmadik topikhoz én annyit tennék hozzá, hogy a politikusokról rengeteg betű lát napvilágot. Valódi text majd data mining kincsesbánya :) Nehezen lehet azt mondani, hogy nincs adat. Még magyarországi léptékben is tudhat "big data" lenni, pláne, ha figyelembevesszük az EU-s vonatkozásokat is. Az, hogy a sok információ alapján milyen magyarázó- vagy célváltozókat veszünk modellképzés során, az egyrészt nagyon nehéz feladat, másrészt távolról sem lehetetlen küldetés, szakmailag jót csinálni.
Mostanság, ami nagyon forró topik lehet, korrupció-analízis publikus adatok alapján. Azt gondolom nagyon nehéz alábecsülni a téma jelentőségét.
Komment-1: "A közpolitika elemzés nem csak a vállalt és tényleges politikai tevékenység közti különbséget nézi, hanem az alapvető politikai tevékenység tulajdonságát, meg pl. a policy making folyamatot (milyen jelenségre milyen válasz, külso környezeti változók, stb). Nemzetközi tanulmányok mestert végeztem. Nem mintha sok értelme lett volna..."
Komment-2: " http://www.budapestinstitute.eu/index.php/hu "
2015. június 7., vasárnap
Budapest Analytics Rockstars, The Day of Data, 2015.06.04
.
Nagyszabásúnak hirdetett szakmai (és nem sales) meetupot rendezett a Starschema Kft., részint megünnepelve új elegáns helyre való költözését is (Váci út 99, erkélyes/teraszos naplemente-nézős 9.emeleten)
Az eseményre 100+ kolléga jelentkezett és végül 89-en (Starschémás kollégákat nem számítva) jöttek el. Ami azért nem hangzik rosszul külső szemlélő számára sem.
De nemcsak a naplemente volt izgalmas, mert hogy érdekes előadások hangoztak el a Starschema termékvonalát érintően. Én az érintett VirtDB, Alteryx, Tableau termékvonal mindegyik komponensének szenteltem egy hangsúlyosan szubjektív személyes blogposztot, természetesen a szokásos objektivitásra való maximális törekedés jegyében.
A Földi Tamás "databoss" által elővezetett Apache Kafka "ultimate solution"-nek is szántam egy blogposztot, hogy teljes átfogó kép legyen az egész meetupról.
A magyar gyökerű VirtDB laudációja
Alteryx - új Self-BI versenyző
Alteryx+Tableau kombó nagyszerűsége
Na és mi a helyzet a CQRS-szerverekkel
Az előadások udvariasságból angol nyelven zajlottak, úgy is, hogy a prezentációk angol nyelvűek voltak és csak egyetlen olyan angol nyelvterületről való kolléga volt, aki nem értette (volna) a magyart.
A prezentációkról való írás is megérne - rosszalással is olykor tarkított - misét, de akkora az anyag, hogy muszáj volt szelektálnom.
Az esemény nem egyszeri alkalom volt, reménység szerint máskor más előadókkal folytatódni fog a meetup-sorozat.
Bonus poszt a hardcore fanatikusoknak
KDnuggets data science tool szavazás 2015
Nagyszabásúnak hirdetett szakmai (és nem sales) meetupot rendezett a Starschema Kft., részint megünnepelve új elegáns helyre való költözését is (Váci út 99, erkélyes/teraszos naplemente-nézős 9.emeleten)
Az eseményre 100+ kolléga jelentkezett és végül 89-en (Starschémás kollégákat nem számítva) jöttek el. Ami azért nem hangzik rosszul külső szemlélő számára sem.
De nemcsak a naplemente volt izgalmas, mert hogy érdekes előadások hangoztak el a Starschema termékvonalát érintően. Én az érintett VirtDB, Alteryx, Tableau termékvonal mindegyik komponensének szenteltem egy hangsúlyosan szubjektív személyes blogposztot, természetesen a szokásos objektivitásra való maximális törekedés jegyében.
A Földi Tamás "databoss" által elővezetett Apache Kafka "ultimate solution"-nek is szántam egy blogposztot, hogy teljes átfogó kép legyen az egész meetupról.
A magyar gyökerű VirtDB laudációja
Alteryx - új Self-BI versenyző
Alteryx+Tableau kombó nagyszerűsége
Na és mi a helyzet a CQRS-szerverekkel
Az előadások udvariasságból angol nyelven zajlottak, úgy is, hogy a prezentációk angol nyelvűek voltak és csak egyetlen olyan angol nyelvterületről való kolléga volt, aki nem értette (volna) a magyart.
A prezentációkról való írás is megérne - rosszalással is olykor tarkított - misét, de akkora az anyag, hogy muszáj volt szelektálnom.
Az esemény nem egyszeri alkalom volt, reménység szerint máskor más előadókkal folytatódni fog a meetup-sorozat.
Bonus poszt a hardcore fanatikusoknak
KDnuggets data science tool szavazás 2015
Feliratkozás:
Bejegyzések (Atom)
Bejegyzések
