DATO: (i)Pythonos Machine Learning Framework

.
Kedvenc PhD-szemináriumom csütörtöki alkalmán, ifj.Benczúr András kiváló előadásában hallottam erről a címbeli DATO-ról először, gondoltam írok róla pár szót. Ez egy olyan poszt lesz, ahol több lesz a link, mint saját betű, de sebaj: ilyen is kell legyen :) (Noha már telepítettem és vetettem rá első pillantást a délutáni órákban)

A Yahoo alapján a marketingesek rendesen belehúztak a névválasztásba, de annyira, hogy sikeresen megmenekültem a fordítás kötelezettsége alól ;)

DATO => Dining at the orifice.. Dining at the Y... Multiple shots on goal. First two refer to "eating out" the respective regions... the last refers to deeds done multiple times to one woman. Hope thats clear enough without getting inappropriate.

Történt vala pedig annó, hogy a Carnegie Mellon nevű nevezetesebb amerikai egyetemen elkezdtek fejleszteni C++-ban egy parallelizált machine learning library-t, unix és mac-támogatással (azaz Windows nincs közte), aminek Graphlab lett a neve a keresztségben. Aztán ez a codeset befagyasztódott.
Carnegie Mellon - Graphlab
PowerGraph (github, befagyasztva)

De persze maga a termék továbbfejlesztődött, pár napja jött ki a legfrissebb verzió PyPi-re, immáron Windowsra is:
Graphlab utolsó legfrissebb verziója PyPi-n, Windowsra is

Az eredeti fejlesztők közben megalapították a DATO-t. Innentől van egy github-ról szabadon letölthető Open Source ág, olyan finomságokkal mint a Pandas-NumPy alternatíva SFrame vagy plugin SDK a github-on (ráadásul Python API-val)
DATO: Open Source
DATO: SFrame
DATO: CORE
DATO: GraphLab Create SDK

És lett egy commercial termék(család). Az alap "desktop"-termék a Graphlab Create illetve ehhez kapcsolódik a server-oldali két termék (DATO Predictive Services és Distributed)
DATO Products

A számomra legizgalmasabb a "desktopos" (nemcsak desktop hanem pl.: cloud) Graphlab Create:
Ha valaki szereti a böngészőben futó iPython-t, az imádni fogja. :)
Immáron természetesen van Windows-os install is (egyre kevesebb hibával) érdemes szűzen telepíteni, hogy más Anaconda Python disztribúciós telepítéssel ne vesszen össze.
DATO Architecture and features
DATO Machine Learning Algorithms

A nagy versenytárshoz (sci-kit learn)-höz képest, ugyan olyan minőség mellett 5-6-szoros gyorsulás érhető el DATO-val.
DATO: Performance

Sajnos  a commercial termék nincs ingyen, 4.000 USD/gép/év, ami az Alteryx-szel (másik C++ -alapú framework) összevethetően nagyon drága.
Mivel Anacondás Python disztribúción alapul a DATO, megnéztem, hogy az Anaconda árazás hogyan alakul, és sajnos döbbenetesen elszállt az is. Az Add-On-ok párszáz dolllárja 10-60.000 USD/év-es előfizetésekbe torkolltak. És az Add-On-ok ráadásul a legolcsóbb előfizetésben nem is érhetők el, csak 30.000 USD felett. Még a végén visszasírom a RapidMinert az árszabásával....;) Ez bizony mellbeverő fejlemény volt számomra.
Ami idevág még, hogy egy évre lehet akadémiai licence-t igényelni, akinek van ilyen mailcíme, és ha jól értettem personal licence-t is, de utóbbinak egyelőre nem látom a feltételeit. Én egyelőre egyhónapos trial-t installtam.
DATO: Prices

A DATO két legizgalmasabb feature blogposztokban:
DATO: Gradient Boosted Trees
DATO: Deep Learning

A DATO szépen van dokumentálva.
DATO: 1.User's GuideDATO: 1.User's Guide - kódok github-on
DATO: 2.How-To
DATO: 2.How-To - kódok github-on
DATO: 3.Docs

Alteryx-hez hasonlóan itt is van nagyon jó és bővülő galéria, ipythonos notebook-okkal, videókkal, kategorizálva.
DATO: Gallery

És van az elmaradhatatlan fórum:
DATO: Forum

DATO-finomságok:

+ Az SFRame típusos oszlopokat éppúgy támogat, mint tabular és graph-adatokat, míg a scikit-learn közvetlenül eszi az adatait, szemben a Pandas-szal, amihez kell NumPy.

+ Legfontosabb algoritmusok benne vannak, jó performanciával, intenzíven fejlesztik (Gradient Boosting Trees, Deep Learning). 2015 nyarán jött ki az Adam-optimalizálás cikke (DeepLearning), és már bekerült a Graphlab-ba ;)

+ Nem visual-flow-os eszközöket tekintve messze legelegánsabb küllemre. Deszkamodell-építéshez akár megrendelő ügyfélhez is kivihető.

+ Cloud, Masszív párhuzamosítás, CUDA, Hadoop fókuszban

+ DeepLearning olyan verziójú, hogy a legtöbb terhet leveszi, le akarja venni az adatbányászról, paraméterezés, konvolúciós rétegek száma automatikus módon stb. Egy jól működő projekt van már (MINST), de az örömtüzekkel érdemes lehet várni (márminthogy univerzálisan is működik az automatizált Deep Learning. Volt egy érdekes megjegyzés: "Ha majd idõsorokra jól megy majd akkor esetleg jobban hihető lesz".

+ SZTAKI ennek az eszköznek a használatával 2-dik lett a 2014-es RecSys Challangen.
* Itt a cikk róla.
* Itt a dataset.
* Itt a leaderboard.
* Ez a verseny arról szólt IMDB filmadatbázis alapokon - hogy most már nem milyen ratinget kap a film a usertől, hanem API-n keresztül lekérhető adatok révén milyen twitter-interakciót generál egy film.
* Volt retweet / like engagement, ezt nem pontosan értettem.
* 350 és 150 euró volt a díja az I. és II.helyzettnek. Gondolom inkább dicsőségre ment.
* Gravity és a szervezõk között volt (Tikk Domonkos)
* Lássuk be nem mindennap olvasni, hogy egy felhasználóbarát magasszintű eszközzel ennyire jól lehet szerepelni egy data mining versenyen, igaz ez még akkor is, ha a logitboost-hoz wekázni kellett a csapatnak.

Deep Learning

.
Volt szerencsém résztvenni kedvenc adatbányászós phd-szeminárium legutóbbi poszt-címbeli tárgyat érintő, Daróczy Bálint -nak köszönhetően szenzációsan jó alkalmán/előadásán és megpróbálnám reprodukálni az ottani infókat és saját gondolatvilágomba ágyazni az ott elhangzottakat.

Előre szólok, csak "trécselés" szinten, kedvcsinálóként írok, ami alulról próbálja elérni a szakmai blogposzt műfaját.
- Disclaimer: ami jó és érdekes az alábbi írásban az alapvető módon az előadásból származik, ami rossz az az én öreg rossz szemem és fülem, félreértelmezésem, hibáim/tévedéseim eredménye: ezt az olvasónak kell sajnos szétválogatnia, bár igyekszem megtámogatni ebben.
- A neurális hálók(NN) külön nagy tudomány, aminek részleteire itt meg sem kísérelhetek kitérni és bár bőven tanultam róla, gyakorlati tapasztalataimból elég rendesen hiányzik az alkalmazása.
- Én felhasználói szinten kvázi kívülről érkeztem a témához, mondhatni ez az első benyomásom a címbeli cuccról. Perpillanat nemhogy nem értek hozzá egyelőre nemhogy részleteihez, de felhasználói szinthez sem, de csomó mindent még az előadáson elhangzottakból sem igazán értek, tudok érdemben feldolgozni.

A deep learning, a neural network-ös machine learning egy aktuálisan nagyon is hottopic-ja, konkréten tudható, hogy mostanság komoly versenyeket lehet vele nyerni. Ráadásul óriási potenciál van benne még, hiszen alig-alig tudunk bármit is, meg értünk a működéséből, illetve rengeteg irányba lehet továbbvinni a tuningolását, és egy-egy ötlet végigvitele egy csoport heteit-hónapjait is le tudhatja kötni.

Ha bárkit mélyebben érdekel a téma, például kipróbálási szinten, akkor valamelyik győztes publikációjából valamint datasetjéből érdemes kiindulni, de javaslom a Kaggle-t itt is mint oly sokszor máskor is, mert a győzteseknek itt vannak legszigorúbb publikálási kötelezettségei, továbbá a résztvevők fórumokon osztják meg tapasztalataikat. (Ugyanis köztudottan lehet akár 12 oldalas „elfogadható” cikket publikálni a semmiről és/vagy reprodukálhatatlan módon, amivel nem kerül beljebb senki).  Léteznek tutorialok is. Kiváncsi leszek könyvben és tantervben mikor látom majd.... ;)

Ami a számítási teljesítményigényt jelenti, egy jelentősebb CUDA-s 100.000 forintos NVIDIA-kártyával már csodákat lehet tenni, amik ráadásul skálázhatók: 2x annyi kártya kvázi 2x annyi teljesítményt jelent (mínusz overhead). Azaz otthon is lehet próbálkozni;  kvázi nulla tőkét, "csak" tudást igényel a tárgybeli erőlködés.

Már most kétszámjegyű egyre okosabb és általánosabb implementáció áll rendelkezésre, számomra meglepő módon java egy sincs és 9:1 arányban van Python/C++ wrapper valamint egy szem LUA (torch), amikkel szintén lehet játszani.  Ugye mondanom sem kell, hogy IBM SPSS-ben, SAS-ban, Alteryxben és hasonló csillagrombolós gigászokban ne keressünk ilyeneket (még ha elvi plugin-technika miatti akadályuk nem is lenne). Viszont az open source cuccokban Weka/Knime/Rapidminer/R könnyedébben/gyorsabban meg fog tudni jelenni, bár a java-centrikusságuk lassító tényező lehet.
A leghíresebb, legelső, legáltalánosabb célú implementáció a theano

Előzmény: régen volt sok(féle) adatunk például ügyfelekről, majd némi trükközés pl.: mezőszármaztatás után relatíve egyszerű dolgok (mint elvándorlás-hajlandóság leképzése) következtek, pl.: kőegyszerű logisztikus regresszióval. Persze adattisztítással, data mart építéssel, vizualizációval, prezentációval, decision makinggel, folyamatba-integrálással, de ezek ezután is kellenek, szóval offtopik itt. Ha az embernek volt egy csodajó osztályozó algoritmusa pl.: SVM, avval már versenyeket lehetett nyerni még pár éve is.

Na a manapság nagyon menő jollyjoker már a Deep Learning, és már felhasználói szinten is brutálisan nehéz: környezetet setupolni, brutális komplexitásig menően neuron-layereket programozni, ráadásul úgy, hogy 90% megy aztán a kukába sikertelen próbálkozásként (max. lehet belőle cikket írni és/vagy jobb esetben beépül a tapasztalatba valamilyen formában).

Volt 1-2 éve egy ImageNet-es képfelismerő verseny A feladat nem is olyan egyszerű, ha gépi algoritmussal kell felismerni (osztályokba sorolni), hogy a képen például egy házimacsek avagy hiúz van. ;). A győztes 1-2 százalékot tudott javítani a többiekhez képest deep learninggel és evvel meg is nyerték a versenyt a klasszikus Fisher-score-os módszerekkel szemben. Plusz paraméteres aktivációs függvényt alkalmaztak, ahol a paraméter további machine learningből illetve nem normál (Gauss-)eloszlásos modellinicializálást és vagy még 8 további trükköt, de most nem cél ebbe jobban belemenni.

A versenyen: 1.2 millió képet adtak trainingnek, feladat: ha jól emlékszem 500.000 kép, 1000 osztályba sorolandó, 5-6 óra alatt. TOP1 40%hiba, TOP5 16% hiba már csak. Vagyis a legvalószínűbb illetve öt legvalószínűbb osztály megjelölése és annak hibaszázaléka, mind az 500.000 képre.

Egy következő fordulóban a Microsoft/GoogleNet/IBM-es gigacégek rúgtak már csak labdába, az akadémiai szféra kompletten nem fért fel a listára. ;) (Emlékszünk még, hogy a Netflixnél tarolt az akadémiai szféra?) Úgymond semmi hozzáadott értéket nem adtak, ugyanis ugyanezzel a deep learninggel, csak felskálázva több gépen, több és jobb CUDA-val, több réteggel (azaz mélyebb tanulással), több számolással, szignifikánsan jobb eredményt értek el.

A győztes levitte 30% és 11%-ra a hibázásokat és az az érdekes eredmény jött ki, hogy lassan-lassan az emberi hibázáshoz konvergál már a dolog. Nem úgy kell érteni, hogy egy ember nem ismer fel egy képen egy kutyát, hanem a sokadik kép után megnő a humánosztályozós félreklikkelések száma.

Mi is ez a Deep Learning? Vannak input és output rétegek adatszinten (ahogy mindig is, eddig is megszokottan).

Feladat
* tegyünk közéjük - definitive nem-lineáris típusú - hidden neuron-layereket a célból, hogy minden layer mást tanuljon olyatén transzformációőrző módon (azaz divergálás kicsi legyen), hogy réteg(elemek) ne tegyenek keresztbe másnak (súlyozás mindvégig közös például).

* A távolabbi cél e rétegezéssel kideríteni az adatokból, hogy mit érdemes megtanulni az adatokból (ezt manapság még data scientistes humanoid ember csinálja, ugye).
* Ennek aztán rögtön következménye az is, hogy például egy (fix) feature extraction (ami szívemnek oly kedves tevékenység volt eddig az adatbányászatban), innentől erősen felejtőssé válik értelemszerűen.
Ezt póriasan úgy is el lehet elképzelni, hogy egy SQL-es lekérdezéshez képest az adatbányászati tevékenység sokkal szofisztikáltabb (magyarán egy SQL-es csak "elefánt"-ként tud fungálni az adatok "porcelánboltjá"-ban), addig a feature extractionhöz képest a hidden-layerek tanulása a sokkal-sokkal kifinomultabb eljárás. Az információ áramlás input->hidden layerek->output-on kétirányú, egyrészt előrefele tanulóak, visszafele hibakorrigálók lehetnek (de nem kötelezően).

Mi a cél? Hát az, hogy a jelszó innentől: jól kell generalizálni (számok nyelvére lefordítani az alapproblémát), utána az ígéret szerint pl.: egy osztályozás már gyerekjáték lesz. A gond az, hogy ez baromi nehéz feladat, nem mindig végezhető el, sok minden megy a kukába menetközben és nem értjük pontosan mi hogyan működik benne (jól), lásd még NN-világban triviális "blackbox"-problémát, fogalmunk sincs hány réteg kéne, hogyan kell aztán visszanyesni őket (egyébként a döntési fa visszanyeséséhez – „prune” - analóg módon) a jó működés érdekében. A jó hír viszont az, hogy tettenérhető, ha jól működik a generalizált modell, „csak” el kell kapni a fonalat hozzá.

A fenti rizsa más szavakkal: építünk egy akár végletekig szofisztikált generalizált „modellszobrot”, ez erős túltanuláshoz (overfitting) vezet (hiszen „megtanulódik” maga a teljes adathalmaz) és emiatt a gond miatt baltával nekiesünk a szobornak és ütjük-vágjuk-nyessük, hogy jó és stabil legyen a modellműködés. A generalizálás során végletekig habosítjuk a kiinduló adatkáoszt: ami után adatpont x dimenzió szorzat így sokkal kisebb lesz mint a felhabosítás utáni teljes paramétertér (azaz pont nem sok adatból képzünk le keveset, mint korábban, hanem fordítva sokból még többet)

A nagy nóvum, ami az phd-előadást is inspirálta Hinton (őt az előadó szerint nagyon érdemes olvasni, röviden, tömören, érthetően ír) 2012-es cikke: dropout, ahol nem neuronokat, pláne layereket dobálnak el visszanyesés során, hanem csak neuronkötéseket pl.: full connected-ből, nem a számítási igény korlátai miatt, hanem helyesség iránti igényből (vesd össze hálózatelemzés, NN-től függetlenül is) olyatén módon, hogy minden neuron(működés) állapotját javítják (nem rontják).
Ha jól értettem az előadó szkeptikus volt ("miért és miért így") én a sokkal "távolabb" elhelyezkedő intuiciómmal ezt nagyon erős ígéretes iránynak érzem.
És akkor még réteg-átlapolásról, szavazásos boostingról egy szó sem esett.

Személyes konklúzióm: abszolút nem látom, nem érzékelem, hogy ekkora témabeli erőfeszítés hogyan-miképp hat és térül meg.
* Nekem ez az egész blackbox a négyzeten, még ha főbb vonalakban értem is, hogy mi történik (neurális hálók révén, ami 1950+-től létezik, 1980-tól intenzívebben). Vaktában kell a sötétben tapogatózni, vajákolni, nem kérdezni csak csinálni intuicióból, és siker esetén aztán örülni. Nagyon távol van ez még nekem a felhasználói "algoritmizálhatóságtól".
* Viszont az elvitathatatlanul nagyon jó indikátor, ha (jellemzően domain-free) versenyeket lehet vele megnyerni.
* Képzeljük el, ha erre még domainfüggő üzleti tudást is ráépít valaki (ami a versenyeken definitive nem tudhat működni, hiszen ott csak számokkal küzdenek a versenyzők legtöbbször).
* Belegondolni is brutális élmény, hogy bambán ugyanaz a módszer több gépen több számolással ekkora megbízható szignifikáns javulást tud hozni, úgy is, hogy alig-alig értünk az egészből bármit is. Képzeljük el, mi lenne, ha értenénk pontosan melyik részletből mi következik?


Update-1: bi.hu

Milyen  kicsi a világ. :) Arató Bence bi.hu-s honlapja a minap ezt a "Egyre több a nyílt forráskódú adatbányászati szoftver" link -et osztja meg, ami rögtön két érdekességet is rejt:

 (1) Amiről több szálon is beszéltem (deep learning és implementációi, ImageNet verseny)
"A Google TensorFlow az úgynevezett mély tanulás (deep learning)  terültének fonton szereplője. A szoftver többek között a Google Photos képkeresőszolgáltatásba is beépül."

(2) Öt évvel az adatbányász kihívások blogposztom után végre nagy örömmel ábrán is látom a megvalósított update cache egy verzióját.  Korábban ugye csak annyi volt, hogy a processben manuális állítás után  a szükségtelen (impact nélküli) kalkulációkat ne végezzünk a gyorsabb futás érdekében.  A valódi cache persze ennél sokkal értékesebb és komplexebb: amikor a szotver maga tud dönteni a rekalkulációról, sőt támaszkodik a korábbi eredményekre is.


Update-2: DATO

Következő PhD-szemináriumon Benczúr András mutatott egy DATO-s (iPython+scikit-learn) Deep Learning-es notebookot a MINST-adatbázisra.
* 80% training
* layerek, (hány) konvolúció, flatten, aggregációk, maxpool és egyéb paraméterek meghatározása, dropout-konfig, etc. automatikusan program által meghatározva.
* 99% pontosság 1 konvolúcióval(!)
* Kétséges, hogy ez az automatizmus megy általánosan is. Beszélgetés során elhangzott megjegyzés: "Ha majd idõsorokra jól megy majd akkor esetleg".

Update-3:  Google Tensorflow

* Soft Max Regresszió, amiről most hallottam előszőr.
* Bár épp a napokban csalódottságos cikket is lehet olvasni vele kapcsolatban, a SZTAKI-s csapat lát benne potenciált, szemléletileg is, implemenetációilag is, szemben a DATO-nál említett automatikussággal kapcsolatos szkepticizmussal.
* DATO-val szemben három lényegi ponton a felhasználó paraméterez/legóz, kötött szabályok szerint.
(1) Modell
(2) Célfüggvény
(3) Algoritmus


Google: TensorFlow - Google’s latest machine learning system, open sourced for everyone
Google: Building a deeper understanding of images


KDNuggets: TensorFlow Disappoints – Google Deep Learning falls shallow
KDNuggets: Popular Deep Learning Tools – a review
KDNuggets: Top 5 arXiv Deep Learning Papers, Explained
KDNuggets: Decision Boundaries for Deep Learning and other Machine Learning classifiers (R)
KDNuggets: Where to Learn Deep Learning – Courses, Tutorials, Software



Update-4: Chainer

* Japán eredetű, jóhírű cucc, csak megemlítődött.
* Itt egy 36 slide-os prezi.

Indexes interjú a stanfordi Matthew O. Jacksonnal

.
Sokan szeretik, ha elhallgatják előlük a híreket Interjú Matthew O. Jacksonnal, a Stanford Egyetem professzorával

* Szenzációs interjú (blőd címet leszámítva), általános célú online újságírásban meglepően erős tartalommal. A professzornak van Coursera-s kurzusa is, ahogy az interjúból ki is derül.

* Csak ez az egy beszélgetés "zsebrevágja" (nálam) Albert-Barabási nemhogy interjúit, de legutóbbi Villanásos könyvét, annyi érdekesség, információ van benne, olyan éles témákban is, mint menekültkérdés. A kérdező is nagyon jó, nagyon felkészült, volt szakértő(?) segítője. Albert-Barabásit interjúvolni szokó indexes Stöckertet is bőven übereli nálam.

* Az interjú számomra gyönyörűszépen rávilágít arra, hogy mennyire áthatja életünket a hálózatok világa, a "hálózatos" gondolkodás. És, ha ez erős szakmai elemzős tartalommal van megfejelve, hihetetlen erős erővel tudhat hatni, adatbányászat egy speciális önálló ágaként is.

* A nekem legfontosabb mondatok, amiket persze tud az ember, de más, ha leírva is látja. Mennyire fontos a "beágyazottság", "a terjedési sebesség", "a tömegesség", "teljesség" (részletekbe-elmerüléssel szemben)

+ "Volt egy mikrohiteles kutatásuk is Indiában, ahol az egyik eredmény az volt, hogy hiába tájékoztatják a falvak vezető személyiségeit, csak ott terjednek el az új hírek, ahol ők egyben szociálisan is beágyazott figurák, sok barátjuk, ismerősük van."
AKA sokszor nem az igazság és/vagy jó számít, hanem ki és hogyan mondja.

+ "Vannak nagyon alap taktikai elemek, ahogy egyes terroristasejteket azonosítani lehet, vagy milyen pontokon lehet a legtöbb információt megtudni a működésükről. De sokkal fontosabb és alapvetőbb azt feltérképezni, hogy miért csatlakoznak emberek, hogy hogyan terjed az egész."
AKA nem a betegség tünetét kell kezelni, hanem a tünethez vezető úton kel legyen gyógyító fókusz.

+ "Az amerikai tapasztalatok alapján tehát kevésbé jó ötlet egy nagy tömbben tartani a bevándorlókat, úgy kell elhelyezni őket, hogy egyediek legyenek a környékben."
AKA egészen más figyelmet érdemel az egyedi jelenség, mint a tömeges.

+ "A bankok pedig ezen belül elkezdik akkor a legnagyobb haszonnal kecsegtető kötvényeket megvenni, azaz a görög kötvényeket. Ez utólag kiderült, hogy nem volt tökéletes ötlet. Ha nem az egész rendszert vizsgáljuk, hanem csak egyes szereplőket, akkor elég sok mindent el lehet rontani. Tehát igen fontos a tudatosság, a hálózaton belüli interakciók folyamatos ellenőrzése, és akkor meg lehet előzni a nagyobb bajokat. Ha már tudjuk, hogy mire kell figyelni, és van is elég információ, onnantól ez egyébként elég egyszerű feladat."
AKA jól kell dekomponálni meg súlyozni a vizsgálandó rendszerben.

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