Prekopcsák Zoltán [RapidMiner] trollkodása

Előljáróban, a tények kedvéért rögzítem: 
Prekopcsák Zolit 2007 óta ismerem a BME-ről. Gáspár(-Papanek) Csaba révén ismertük meg egymást több más kollégájával párhuzamosan. Azóta perdöntően szakmai konferenciákon futottunk össze. Fennálló jónak mondható kapcsolatunkat jelezhette például az is, hogy együtt ebédeltünk (konferencia-ebédszünetben), jóízűt beszélgetve (máig emlékszem rá).

SAS?

Fenti előzmények után derült égből villámcsapásként ért, hogy a fentebb linkelt blogposztom kommentrészlegében kvázi rámtörte az ajtót, szakmában általam nem igazán látott (és nem elfogadható) stílusban. Ha valaki elolvassa a teljes kommentfolyamot, észreveheti, hogy cca. kétszerannyi idősként én - értelmezésemben igazságtalanul, és otromba módon - megtámadottként, még én próbáltam úriemberként Zoli hevességét csillapítani. Az egészet el is felejtettem volna, ha hónapokal később, nem tanulva, észlelve semmit bírálható magatartásából, ugyanott folytatta, ahol abbahagyta: környezete sem tudott ráhatni.

Mi volt a linkelt rövid posztom negatív kontextusú üzenete? 2015-ben miért kell SAS-t tanítani,
* drága oktatói erőforrásokat erre pazarolva,
* SAS-nak több okból eredeztethető marginalitása okán
* itthon Magyarországon kevéssé hasznosítható várható eredményekért,
* árukapcsolás részeként (több más fontos topikkal együtt)?

Ami a linkelt blogposzt kommentfolyamában történt Prekopácsok Zoliék részéről, az értelmezésemben szintiszta offtopik trollkodás.

- Kötözködés a visual flow kapcsán, ami aztán csendben kimúlt a reagálásom nyomán.
- Terelés az R-rel.
- Irányomba való, minősítgető személyeskedés, minden tárgyszerűségtől, indoklástól mentesen ("ámokfutásom", "konstruktivitás nélkülözése" és társai)
- Kognitív disszonanciából eredő(?) további terelés. Mert van magyarországi SAS álláshirdetés, ezért már kéne SAS-t tanítani ilyen vesézett fókusszal?
- További érveléstechnikailag védhetetlen terelés: mi köze a SAS-nak tantervbe emeléséhez (annak vitatásához), hogy egyébként alulfizetett oktatók tanítják és világszinvonalon? Én is mondtam, hogy a tanterv SAS része is jó, a SAS-komplementeren felül is. A blogposzt által felvetett probléma ismétlem az volt, hogy miért kell SAS-t így pusholni. Lásd még értelmező olvasás! ;)
- Awk-kal való felesleges szúrkálódás.
- Tiszteletlenséggel való vádaskodás.
- Majd ezek után konklúzióként, a szakmai, stilisztikai, világnézeti közös talapzatról "letaszításom".

Az én konklúzióm a fentiek tükrében:
- Prekopácsok Zoli maga írta meg, hogy "kevés nála érdekeltebb ember van a SAS bukásában az országban".
- Nem érkezett egyetlen elemezhető, kontextusban maradó, diskurzust képezni tudó pozitív érv sem miért kéne SAS-t tanítani, a kommentfolyam hosszúsága ellenére sem.

- Minden offtopik ellenérv-kezdeményt, tévedést igyekeztem cáfolni, ami aztán elhalt (értelmezésemben nem miattam).

- Személyem konkrét megtámadása, teszem hozzá magas lóról. Csak tudnám mi predesztinálja erre Zolit?!
- Próbáltam a félresiklott kommunikációt helyrehozni, sehogysem jártam sikerrel (azt gondolom nem miattam, hanem Zoli akart mindenképpen, mindenáron ütni rajtam, amit még így is elviseltem volna, ha nincs folytatás több hónappal később).

Számomra ezek - pláne ismétlés okán - kimerítik a trollkodás fogalmát. Annyira hogy muszáj volt ezt a blogposztot szentelnem neki.


[Data Science] Top5 leginkább (érdemtelenül) túlárazott szoftver

Prekopcsák Zoltán, úgy is mint 2014 augusztus óta "VP Big Data, RapidMiner, Developing and executing the Big Data strategy of RapidMiner and managing the Hungarian subsidiary", a fenti blogposztom kommentrészlegét végiggtrollkodta a RapidMiner kapcsán.

Zoli ingerültsége, ha nem is védhető, pláne prezentált formájában, RapidMiner/Radoop-érintettként magyarázható. És ha már egy ilyen nagy ember vette a fáradságot, hogy beszóljon itt a végeken egy magyar blogosnak, gondoltam én is szánok egy posztot a tisztánlátás érdekében "sok bába közt ne vesszen el a gyerek" jeligével, mielött elkezdenénk könnyeket hullatni a RapidMinerért, az én "rosszindulatú", "hiányos" blogtevékenységem okán.


Előzmény:
- RapidMiner v5.3-ig open-source, community-edition-nel bíró verzió volt, aminek korrekten volt supportos commercial alternatívája. Ebben a minőségében komoly tekintélyig jutott teljesen megérdemelten. Aztán 2013 novembere környékén a v6.0-val egy értelmezésemben (1) elhibázott, (2) durva, (3) érintett szakmai közönség részére rendkívül káros történés történt.
(1) A v6.0-nak megszűnt a community edition-je (v5.3-é megmaradt)
(2) Született egy értelmezésemben értelmetlen és használhatatlan 1GB-os memórialimitítű "starter", ami freeként lett alternatívája a community edition-nek.
(3) A RapidMiner Studió (és hol vagyunk még a Servertől) négy fizetős verziójából kettő annyira durva lett, hogy ki sem merték írni. "Ask" lett.
(4) A két megjelölt árú kiadás beárazása "cserébe" nagyon durva lett, főleg a v5.3->v6.0 előrelépés minőségének arányában.
(5) Volt egy http://rapidminer.com/pricing/ link, ahol az árak megtekinthetők voltak

A linkelt posztomban fel "mertem" tenni azt a kérdést hogy mi van ha olyan progresszív a hiányzó árszabás,  hogy be sem merték vállalni? Miközben korábban megjegyeztem, hogy "félreértés ne essék lehetnek egyedi árajánlatok, egyedi hozzáadott értékekkel, megegyezésekkel, de azt vélelmezem "dobozos" terméknél elvárható valamiféle listaár. Annyira nem rocket science az árképzés, hogy ezt minden határon túl meg kéne úszni".


Jelen állás:
Ha a költségtranszparenciás problémám, igényem nem érthető, mondok más analóg példát, ugyanarról a "nyugat"-ról, ahonnan a RapidMiner érkezik. Álláshirdetések fizetésmegjelőlései. Ami itthon  álom, az kint valóság: szakmánkban pontosan lehet tudni fizetési referenciákat, kategóriákat, intervallumokat. Ez ugyanúgy nem azt jelenti, hogy nem lehetnek ettől eltérő egyedi megállapodások a dolgozók és cégeik között, skillek, hasznosság etc. mentén.

A korábbi "pricing" link az alábbi beszédes linkre dobja ma már az érkezőt: https://rapidminer.com/pricing-quotes/. Itt szó nincs konkrét formában "Rapidiner szerverről", mint azt Zoli oly hosszasan próbálta volna a RapidMinere védelmében felhozni,

"Get your tailor-made predictive analytics platform. Complete this form - we will be happy to find the best option for you."

Megjegyzés: Az Alteryxtől, Daton-n át, nagy konkurrens Knime, IBM SPSS meg SAS-ig mindenki tud serverárakat is közölni, csak a RapidMinernek okoz ez megoldhatatlan  nehézségeket. A blog olvasóira bízom annak eldöntését, hogy ezek a Zoli által felhozott "nehézségek" mennyiben indokoltak, mi a helyesebb hozzáállás a RapidMiner esetében.

Mivel 2013 novembere óta az volt érzékelhető (számomra mindenképpen), hogy a RapidMiner vérében van - egy új és nehezen védhető trendi jegyében - az árakról való, más termékeknél jelenleg perdöntően nem jellemző titkolózás, nekem ennyiből az jött le, hogy a maradék publikus, egy klikkre elérhető, nyilvános árak is eltüntek.

Zoli, említett trollkodásában, azt "elfelejtette" megemlíteni, amikor adott egy "hónapok óta létező" linket az új árakról (amiből eltünt az említett két "Ask"), hogy hány hónapról is beszélünk. Az én screenshotom 2015 május-júniusa körül készült. Azaz a screenshoot 18+ hónapot valid volt (v6.0 kezdete óta).

Zoli újkeletű információi a linkelt blogposztom óta, összegezve:
- v6-nál ismét van open source (github-on).
- Megszűnt a kárhoztatott 1GB memórialimit is evvel.
- Megszűnt a két "Ask" a RapidMiner Studio árazásánál.
- "Sikerült" a RapidMinernek a honlapján értelmezésemben ritka pocsék módon, ügyetlenül, félrevezetően, hiányosan tálalni. Én értem, hogy Zoli minderről könnyedén tudhat, az említett poziciójánál fogva, de a plebsnek, ahová én tartozom, hadd legyen már meg a tévedés joga a pontos helyzetről, a "rosszindulat" vádja nélkül.

Azaz az üzenet: a RapidMiner "hiányosságai" ne már az én blogolási tevékenységem nyakába legyenek varrva.Nyilván teret adok, meg örülök minden új információnak, de azt a felháborító hangot és módszert, amit Zoli képviselt trollkodásában, azt visszautasítom.

Rendkívüli módon sérelmezem Zolinál, hogy első hozzászólásának első konkrétumos fele teljesen hamis képet fest (amit egy külön hosszú blogposztban kell rendbetenni), második felében minden konkrétum és előbbiek miatt minden alap nélkül nélkül minősítget engem és tevékenységemet illetve a továbbiakban vádol engem, hogy utálom őt. Ennyire Zoli sem nagy ember, hogy ezt megtehesse (értelmezésemben).

Szó nincs róla, hogy utálnám Zolit, csak rámutatok trollkodására. Zolival szemben én embert magát sosem támadok, csak és kizárólag tevékenységet.

Hirtelenjében nem is tudom mi a jobb: ha Zoli ezt szándékosan, avagy szándék nélkül: értelmező olvasás képességének hiányában teszi.

Vegyük észre a fentiekből, hogy az általam kárhoztott RapidMiner dolgok mindegyike

(1) hosszú ideig létezett, amit Zolinak illett volna elismernie egy korrekt diskurzus esetén.

(2) pont azokban a dolgokban történt változás, amit én kifogásoltam a linkelt blogposztomban, Azaz valid volt a blogposztomban a RapidMiner "szégyenpadra" ültetése (egyébként csak 5-dikként. Jegyezzük meg ezen a ponton: ez a termék kiválóságáról, rosszasságáról egy szót sem mond, csak és kizárólag a Rapidminer vezetők attiüdjéről, hozzáállásáról jelez bármit is). Nyilván eljutott a Rapidminer vezetők fülébe, hogy az általam kifogásoltak nem voltak túl jó ötletek és/vagy az értékesítés sem hozta az elvárt szintet és léptek (szvsz).

(3) Ezek az örvendetes változások azonban nem teszi meg nem történtté a RapidMiner korábbi v6-ot övező súlyos félrelépését.

Zoli! Kérve-kérlek, tartsd meg ígéretedet, és ilyen attitüdöddel, viselkedéseddel tartsd magad távol ettől a blogtól.

DATO GraphLab Create - INSTALL

.
Ez egy rövid blogposzt lesz, hogyan rakom én fel Windows alá a tárgybeli cuccot.

Ugye létezik egy Dato Launcher nevű cucc, nálam aktuálisan v1.2.2.2 verzióban, 54MB terjedelemben.
- Na ez az amit nagy ívben el kell kerülni, akkora hulladék (egyetlen pozitívuma, hogy szépen gyorsan uninstallható)
- Ez az ami az aktív user profile alá, ahol a legkevesebb keresnivalója van, akar rakni egy 1.6 GB-os Anaconda install-t majd a GraphLab Create-t
- Ezen kívül semmi más értelmes funkciója nincsen a cuccnak (számomra nem látszik).
- Mindezt úgy, hogy a gépen ottfelejti a 350MB Anaconda-Install-kitet utána, csomó szeméttel együtt.
- Nem rábeszélhető sehogyse, hogy ne akarja deaktiválni a jelenlegi Anaconda-környezetet, úgy sem, hogy a sajátját installom külön szeparáltan.
- Azaz opcionálisan kérhető egy FAQ a böngészőbe, de vagy belevág az ember a felesleges és gusztustalan őrületbe vagy kilép a cuccból. Én kilépek és innentől uninstall, hogy soha többet ne lássam (kézzel kitörölgetve a maga után hagyott szemeteket).
- De persze gondosan lementem a 350 MB-os Anaconda-2.3.0-Windows-x86_64.exe-t, hiszen ezt szereti a GraphLab Create maga alatt tudni. Mellesleg érdekes verzió ez, mert a gyári Anaconda (Python v2.7-hez): Anaconda2-2.4.1-Windows-x86_64.exe, ami kisebb verziószámot takar.
- Én egyébként azt vélelmezem, hogy kell menjen a gyári Anacondával is (későbbi up-to-date-elések miatt mondom ezt), de nekem megfelelt a DATO-s Anaconda is.

Létezik egy command line install leírás.
- Mivel én egy szimpla Anacondát és DATO GraphLab-ot akartam, ezért kihagytam a virtuális környezetet.
- Aki Python v3.5-öt tolja már (azt gondolnám helyesen), annak kellhet plusz DATO GraphLab-os virtualis környezet.
- Ugye a DATA Graphlab Create-t lehet installni meglévő conda-környezetbe ami kétféleképpen is mehet
* szimpla lib-install add-on a meglévő környezetbe (envs-es környezet nélkül), amit én preferálnék ugye, meg
* plusz conda-s környezetként envs alá, ami nem azonos a virtuális környezettel ugye:
conda create -n dato-env python=2.7 anaconda
- Őszintén bevallom nekem feleslegesnek látszik (hacsak a peremfeltételek nem követelik meg) akár külön conda-s környezetbe, akár virtuális környezetbe installni a DATO GraphLab Create-t.
- Számomra biztos, hogy a linkelt command line-os leírás elbírna pár szót a témáról. Főleg, hogy "ajánlott" az opció.

1.lépés: default értékekkel és egyébként magától "silence" install c:\Anaconda alá
Anaconda-2.3.0-Windows-x86_64.exe
PS: Egyébként erre módosul utána a PATH: %PATH%;C:\Anaconda;C:\Anaconda\Scripts

2.lépés: az igényeim miatt ("szimpla lib-install"), kihagytam a környezetes utasításokat és az alábbi paranccsal folytattam.
conda update pip

3.lépés:
- Nyilván az email és product key behelyettesítendő
- Kötelező az internet kapcsolat, mert online serverről veszi a licence adatokat.
pip install --upgrade --no-cache-dir https://get.dato.com/GraphLab-Create/1.7.1/your registered email address here/your product key here/GraphLab-Create-License.tar.gz

4.lépés:
conda update ipython ipython-notebook

5.lépés:
ipython notebook

6.lépés: böngészőben (automatikusan a fenti hatására):
http://localhost:8888/tree#

7.lépés: böngészőben evvel már lehet Ipythonozni.
http://localhost:8888/notebooks/Untitled.ipynb?kernel_name=python2 

8.lépés: Ez mutatja, hogy .használható-e a GraphLab Create:
import grahlab + shift+enter

9.lépés: Például innen is lehet elindulni:
https://dato.com/learn/userguide/install.html
https://github.com/dato-code/userguide


Végül megúsztam az egészet: 1.6 GB-ból. Lehet, hogy én vagyok eltévedve de egy évi 4.000 USD-be kerülő szoftvertől, ennél intelligensebb install-eljárás és dokumentálás elvárható lenne.

[Data Science] Top5 leginkább (érdemtelenül) túlárazott szoftver

.
- Ez a rövid blogposzt már a DATO-nál elkezdett érlelődni, pedig a SAS vagy RapidMiner már önmagában adott volna elég gyújtóanyagot korábban is :)
- Az alábbiakban csak olyan szoftverek kerülnek elő, amik valamiképpen
(1) előfordultak a praxisomban ÉS
(2) helyet követelnek maguknak.
- Így például a KXEN/SAP vagy Insightful Miner/TIBCO - mivel sosem volt fókuszban nálam - így nem léphettek elő "trónkövetelőkké".

- Nem is olyan könnyű árakhoz hozzájutni, ami  még inkább "visszataszítóvá" tudja tenni a témát (számomra).
- Nekem ne jöjjön senki avval, hogy "ügyfélorientált" meg "személyreszabott" akar lenni a vendor, ezért nem közöl ára(ka)t. Számomra ez sokkal inkább jelent
(1) átláthatatlanságot,
(2) nem tiszta viszonyokat,
(3) sőt korrupciós melegágyat (hiszen annyiba kerül, amennyit "megér" az ügyfélnek).
Ha ez kint nyugatabbra is dívik, bele sem akarok gondolni nálunk itthon milyen lehet a helyzet.
- Az olyan aljasságokról nem beszélve, hogy a kis cégek fizethetik a jóval teljesebb árat publikusan, míg a nagy multik fű alatt
(1) akár kis csomag(!) esetén is
(2) ártárgyalás nélkül indulásként is(!), akár 80%(!) árengedményről indulnak (tapasztalatból mondom: pl.: IBM SPSS Modeler, vagy nálam ilyen az Anaconda vagy a DATO hozzáállása is)
- Félreértés ne essék lehetnek egyedi árajánlatok, egyedi hozzáadott értékekkel, megegyezésekkel, de azt vélelmezem "dobozos" terméknél elvárható valamiféle listaár. Annyira nem rocket science az árképzés, hogy ezt "minden határon túl meg kéne úszni".


1. ANACONDA
A kétes hírű verseny első helyezettje egyértelműen, az én értékelésemben (aminek része ugye az egyébként különállóan szépen könnyedén elérhető nagyon "trendi" okos remek scikit-learn is (függőségeivel együtt is).
A javukra legyen mondva:
+ Anaconda Subscriptions url, világos, egyértelmű, teljeskörű információt ad.
+ A free verzió nagyon elterjedt, nagyon hasznos eszköz.
+ "Numba" nem-CUDA része open source lett, ahogy az "MKL Optimization" is.
Viszont:
- Azért is "nyernek aranyérmet", mert rögtön három termékük is potenciális kandidáló.
- A 10.000 USD-s verzió semmi lényegi érdemi hozzáadott értéket nem ad. Ami érték az 30.000 USD-től indul (iopro, numbapro, cuda, accelarate, etc.)
- A 60.000 USD meg azért "viszi a pálmát", mert az Anaconda open source-csomagokat rámol egybe, amiért egyedül "felel" az az összerámolás, illetve saját proprietary csomagok.
- A 60.000 USD/év még USÁ-ban sem kevés, megkockáztatom még pörgös gazdasági években sem, nemhogy a költségcsökkentések korában. Fel nem fogom hogy állhat össze a termék pénzes ügyfélköre. Az itthoni helyzetről nem is beszélve: ~18 millió forint évente kb. a semmire.
- Mindezt úgy, hogy pár hete 400 USD körüli összegért az összes lényegi PRO* Anacondás proprietary csomag elérhető volt, úgyis hogy az "MKL Optimization" és "Numba" teljes egészében fizetős volt. "Kicsit" emelkedtek az árak ;)

2. DATO
Rögtön a másik nagy "cápa", Python-világban.
A javukra legyen mondva:
+ DATO Prices  szintén egyértelmű árlista
+ Létezik Amazonos EC2-verzió is, de sok közelebbit nem lehet róla tudni (és engem annyira nem is érdekelt a rossz tapasztalatok után, bevallom férfiasan)
Viszont
- 4.000 USD/gép/év olyan szinten túlárazott egy korábban open source termékre, hogy nálam második helyet ér ezen a "negatív listán".
- Nincs közbülső ár az akadémiai szféra és az üzleti szféra között. Az előbbi korlátlanul ingyen bármire használhatja (1 év után, megújíthatóan), az utóbbinak kőkeményen perkálnia kell a teljes összeget. A trial-ban emlegetett "personal licence" nem létezik, csak beetetésre van ott (utána jártam levelezésben a témával foglalkozó posztom óta).
- A cucc csak Python v2.7-re létezik
- Csak külön enviromentként installható nagyon zűrősen.
- A default path Windows-on a %user profiles%, oda csűr be egy közel 2 GB-os anaconda környezetet (megváltoztathatlanul). Ezen azért sokat kellett "agyalnia" valakinek. ;)
- Használhatatlanná teszi az alap grafikus installer a korábban települt Anacondá-t. Valahogy persze biztos lehet workaround-t találni hogy lehessen azt is használni: de talán ennyi is elég ahhoz, hogy egy ilyen szinten kiforratlan termék erős túlárazásáról beszéljünk.
- A cucc a scikit-learn-nel összemérhető, ővénél részben erősen kisebb algoritmus-választékkal. Míg performanciát illetően állítólag jobb, (nem teszteltem eddig). Gondolom a CUDA alkalmazásából eredhet a különbség.
- A Deep Learning-implementáció túlzott ígéretei is tudhatják szkeptikussá tenni az embert, majd meglátjuk igazolja az idő/élet a cég optimizmusát.

Az első két helyezett tehát avval tűnt ki, hogy kvázi a semmire kérnek horror összeget.
A következő cuccok ugyan adnak "valamit", de azt totálisan eltévedt árakon.


3. SAS
- Maximális "kiépítésben" egy szegényes és kvázi egyáltalán nem fejlődő algoritmusválasztékú cuccért közel félmillió dollárt (150 millió forint+ 50 millió évenként) elkérni azért arc kell. ;) Mit mondjak: a hülyének is megéri. Egy szimpla "halott" dobozos termékért, hiszen a munka és a további érdemi tőkeigény csak eztán jön.
- Az IBM SPSS Modeler árképzése sem a visszafogottságáról híres, meg ugye ott egyéb aljasságok is tettenérhetők, de a fasorban sincs ilyen méretű "ár-elszállás", az én meggyőzödésem szerint nagyságrendekkel jobb termékért cserébe.

4.Salford Predictive Modeler Suite
- Nagyon ígéretes, ám élesben, demó-szintről túllépve, rendesen kipróbálhatatlan termék.
- Pár - interpretálás oldalon is erős - algoritmust ad csak, bár azokkal nyertek már versenyeket, a hírek szerint. A Microsoft is csak kevés (szintén ígéretes algoritmust ad, töredék áron).
- Hivatalos "személyre szabott" pár hetes árajánlatból ollóztam az árakat:

5. RAPIDMINER
- Bár csak ötödikek lettek a "szégyenpadon", de inkorrektségben az első helyen vannak (nálam), a hiányzó árakkal.
- Korábban pár hete még RapidMiner Prices linken elérhetők voltak az árak. Ma már nem. És nemcsak a két utolsó hiányzó ár hiányzó mivolta.
- Ha csak a lineáris háromszorozást vesszük: 10.000 USD, 30.000 USD minimum lehet a 2 ASK helyén (sosem érdekelt és már nem is fog, szvsz, így nem jártam utána).
- De mi van ha olyan progresszív a hiányzó árszabás,  hogy be sem merték vállalni? ;)
- Az összes általam látott free-verzió között talán a RapidMineré a legértéktelenebb (pedig sok ipari hulladékot láttam már), ennél szerintem jobb az open source v5.3-as használata is, minden hibájával együtt is.

Ensemble Learning és Scikit-learn

.
Kedvenc PhD-szemináriumom legutolsó csütörtöki alkalmán, ifj.Benczúr András kiváló előadásában lehetett sok érdekességet hallani a fenti témákban és azok mentén.

Adatbányászatban nagyon sok szép érdekesség, kihívás van, az egyik legizgalmasabb, az összefoglaló néven Ensemble Learning. 
* Látványosan, jobb prediktív performancia figyelhető meg annak során, ha többféle tanítás erényei ennyire erősen tudnak összegeződni.
* Döbbenetes volt látni a Netflix-versenynél, hogy az élbolyban hogy nyert teret.


Bagging(=Bootstrap Aggregating)
* Olyan ensemble technika, ahol nem egyetlen tanító készlet, hanem visszatevéses véletlen rekord-mintavételezéssel több tanító készletet csinálunk és tanítunk.
* Sok tanítókészletnél nem is kell dokumentálni a visszatevéseket.
Majd szavazással eldöntjük a végsõ osztályozási cimkéket.
* Random Forest verziója változókból is vesz mintát (=bagging+random feature selection), még ma is nagyon erős módszernek számít.

Boosting
* Jó a bagging, de nem véletlenre kéne bízni a fenti visszatevéses véletlen rekord-mintavételezést.
* Azokat a pontokat akiket visszatérõen rosszul osztályozunk, azokat súlyozott mértékben gyakrabban tegyük vissza a tanítókészletekbe.

Adaboost (=ADAptive BOOSTting), legelsõ
* Adaptive abban az értelemben, hogy a következõ osztályozást, az elõzõ osztályozás hibái alapján csináljuk.
* Egy mélységû döntési fák az osztályozók
* Magyar nyelvû érdekesség lóverseny-fogadásos kerettörténettel
* A Tutorial on Boosting (Yoav Freund, Rob Schapire), nagyon jó (vizualizációkkal).
+ Cikk
+ Slides-version1
+ Slides-version2
+ Slides-version3

Logitboost

* Pillanatnyi log likelihood
* Döntési fából regressziós fát csinál
* Error rate (RMSE=Root Mean Square Error) tanítása
* Netflixes 5-ös rating helyett 4 a jó, akkor a különbséget kell csak tanítani.
* Tutorial

Gradient Boosting Trees


* Logitboost RMSE-re tanítása túl egyszerû brutalitása miatt
* Szofisztikáltabban a gradiensre/residual-ra kellene tanítani.
* Outlierek túlsúlyozása jobban kivédhetõ.
* Itt is regressziós fás tanítás van, többféle loss-függvény lehetséges (nem feltétlenül a default a jó).
* Tutorial


ÉRDEKESSÉGEK: 

Logisztikus regresszióról lassan érdemes lenne már lejönni.
* Adatelõkészítés, normalizálás, regularizálás praktikákkal is csak alulról közelít a jóhoz, kvázi minden esetben (sosem tud győzni).
* Bizonyos korrelálási anomáliák nagyon nehezen vagy sehogyse gyógyíthatók ki belőle. András hozott egy érdekes, egyszerű demó-példát, ilyen rendellenes működésre.
* Mindez abban kulminál, hogy ami jónak néz ki tanító oldalon, az a teszt-oldalon már gyenge lesz.


Döntési fáról is érdemes lenne lejönni.
* Minden elõnye mellett azért problémás lokális módon rossz cimkézõ döntéseket tud hozni
* Nem tud "visszanézni", vágásokon keresztül
* Ezen a konkrét problémán segít az Ensemble Learning.

Wekáról is érdemes lenne lejönni, még ha annyira nem is egyértelmű a dolog.
* Kiváltani Scikit-Learn & iPythonnal
* Weka gazdagabb ugyan algoritmusokban, pl.: logitboost például van benne, ami Scikit-Learn-ben nincs.
* A Sci-kit learn vagy jó csv-t/inputot kell kapjon (elõfeldolgozás után), vagy meg kell békélni típus-szegény NumPy-jal.
* De a Scikit-Learn tálalásban, felhasználóbarátságban összehasonlíthatatlanul jobb, mint bitang nagy Java-kódokat mutogatni (non-visual-flow esetben).

Plot helyett írtak egy pár soros kicsi Python-kódot, amivel a faépítések részleteikben is jól jeleníthetők meg.

Határozottan létező kutatási irány, hogy a modellparaméterek automatikusan jöjjenek, szoftverből. Már most verik a parameter-free Data Science Machine-ok a versenymezőnyök nagyságrendileg 2/3-dát.


Titanic-Kaggle Challenge (oktatási célzattal)
* Idén decemberben zárul.
* Prediktálni kell ki lesz áldozat a hajótörés után, a rendelkezésre álló alapadatokból (hány éves, milyen nemû, milyen típusú/drága jegyet vett, egyedül volt-e, stb.).
* Nagyon jó hatásfokkal lehet osztályozni
* Volt aki visszafejtette a dataset-et, neten található publikus infók alapján (áldozatnév szintjére), így az adatbányász-feladatot megkerülve 100% minõségben tudott osztályozni.

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