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.