.jpg)
Ha életemben valaha is volt értelme annak a mondásnak, hogy "betévedtem, mint Pilátus a krédóba", az a minapokban esett meg velem. :)
A munkahelyem jelmondata, hogy "lehetetetlent is megcsináljuk, az elérhető legjobb piaci áron".
Na ez személyes életemben úgy csapódott le, hogy megnyertem egy angol nyelvű szövegbányászati (méretesebb) projekt projekttagságát (szerencsére immáron már múltidőben), amiről némi ügyféloldali agilis kapkodás után kiderült, hogy mindent kell csinálni, csak éppen szövegbányászatot nem, mert ahhoz tilos hozzányúlni, fekete dobozként funkcionál (hiába, rossz, többtíz gigabyte nagyságrendben helypazarló, brutális többnapos futási idejű, nem szabványos custom hackelés az egész).
Cserébe amit kellett csinálni, ott minden, de tényleg minden vadonatúj volt számomra, nulla felkészülés idővel, hatalmas időnyomással. Még az iroda is (bővülés miatti átépítés),meg a projektteam is.
- Git. Sose volt dolgom vele eddig. Eddig például egy Subversionbe könnyebb volt életet lehelni, meg könnyebb is volt a munka vele, kétség nem férhet hozzá. De el kell ismerni, a Gitnek is megvan a maga létjogosultsága, mégha a szívás most perpillanat több is volt vele, mint megérte. ;)
- Olyan statisztikai modellekről, amik arcus sinust
használnak, még csak hallani sem hallottam korábban. Bevallom lestem, mint Rozi a moziban, és a tátott szájam sehogy sem tudott becsukodni, mert a reverse engine-je a dolog értelmének túl nagy kihívás volt számomra. ;) Az biztos, hogy statisztika témában is látnivalóan van fejlődési potenciál, személyes perspektívámat illetően. ;)
- MsSql 2012. 6-700 MB vastag kliense kevéssel marad el az Oracle mögött, méretben legalábbis. ;) Elég jó a a kappott felület, de lenne még mit hegeszteni rajta. ;)
- Talend (opens source ETL), ráadásul v5.3 enterprise verzióval, aminek már van komolyabb MapReduce támogatása
- Datastax Cassandra (értelmezésemben egy ipari hulladék NoSql adatbáziskezelő). Félreértés ne essék, amire kitalálták jó, csak ne kelljen benne értelmes táblát létrehozni, mert összezagyválja a mezősorrendet, amit nem hagy sehogy se befolyásolni a user által. Nemkicsit hajmaresztő ez nekem a XXI.században.
- Teammunkás, Netbeans-es Java-fejlesztés. Nagyon kellemes eszköz ez a Netbeans, csak a legjobbakat tudom mondani róla. Egy élmény benne a Java-fejlesztés.
- Időnyomásos agilis módszertan (sose csináltam korábban,
abban látatlanban biztos voltam, ultrabrutál kegyetlen nagy marhaság tud lenni, ha rosszul csinálják). Ráadásul - ügyfél által megkövetelten - a vonatkozó manifesztum értelmében nulla projektdokumentálással, 100%-os szóbeli kommunikációval. Én értem, hogy mindent az ügyfélért, de, hogy ezt nem tudtam egészségesnek látni, az is biztos.
- Hive (fékezett habzású SQL-származék). Eléggé funkciógazdag, szépen dokumentált is, Java-ban könnyedén lehet UDF-et (=User-Defined Function) írni. De a performanciája az finoman szólva is hagy maga után kívánnivalót. Maradjunk abban nem Oracle-ekvivalens. ;) Nem véletlen, hogy a Pivotal One nekifeküdt a témának, és Hawq néven fejleszt egy jóval gyorsabb verziót.
Ennek a projektnek köszönhetem az SqlDbx-re való rácsodálkozásomat.
Ez egy pici, C-ben írt, single exe, SQL Front-Endre.
Imádnivalóan gyors, használható.
Pont mint a Tableau, aszimptótikusan nullához kovergáló overheadet rak az SQL-végrehajtásra.
Egy másik szimpi tool - AQT (=Advanced Query Tool) - nagyságrendileg 10x lassabb végrehajtási/megjelenítési időket produkál.
Döbbenetesen stabil a működése, például egy Squirel+Vectorwise kombóhoz képest.
Minden ODBC SQL-adatforrást meg tud hajtani, a standard adatbázisokon felül, így Hive-ot, Cassandrát, Vectorwise-t.
Personal Edition-je ingyenes, ráadásul.
Erősen ajánlott eszköz, nézetem szerint.
Az mindenesetre szimpatikus volt, hogy brute force Map Reduce mindig működőképes (0 MAP-fázis, 100% Reduce-fázis). Nyilván minél több minden tud MAP-be kerülni,annál jobb lesz a performancia.
A másik fontos észrevétel: nem szabad beeröltetni mindent egyetlen MapReduce-ba. Kellhet particionálni a problémateret.
- Kézműves módszerekkel optimalizált SQL2MapReduce "konverzió":
A Hive-os SQL-ek, mint említettem egyrészt lassúak voltak, másrészt üzleti igény volt, hogy csak prototípus-készítésre (kommunikációra) volt használható, éles production környezetben 100%-ban ignorálni kellett. Ez magával rántotta azt a feladatot, hogy sql2mapreduce konverziót kellett csinálni.
Na ettől a konverziótól eléggé megrémültem, amikor először szembesültem vele, de aztán nagyon megszerettem. De csak teoretikus alapon.
Na ezt megmagyarázom. :)
Van egy szenzációs, friss (2012-es) szakkönyv:
Ez a könyv egyrészt nagyszerűen érzékelteti, hogy micsoda erő van a Map Reduce-ban, nem véletlen a robbanásszerű terjedése, másrészt sokmindenre kiterjedően ad recepteket, mozaikockákat, amikből építkezni lehet (sajnos csak elvben). További adalék,hogy hihetetlen nagy optimalizálási tartalék van a témában.
Eddig a lelkesedésem. :(
A gond az, hogy a HDFS-olvasás, kegyetlen lassú, brutálisan erőforrásigényes művelet. Nem is értem miért, hiszen semmi nem indokolja. Hawq-nak lesz lehetősége megtalálni a piaci rést ;)
Ez a tény egészen egyszerűen kinyírja, hogy design patternek szerint építőkockákból építkezzünk, Mivel minimalizálni kell a HDFS-olvasást, így übtre vonódnak össze mapreduce kódok. Amik egyre áttekinthetetlenebbek, kevésbé módosíthatók lesznek, miközben bármikor jöhet üzleti igény, ami miatt át kell szabni a Map Reduce-olást.
A komplexitás exponenciálisan nő, egyetlen szempont/KPI (performancia) tragikusan alacsony értéke miatt. Tiszta deja vu érzés, mintha optimalizált befaragott assembly programot akarnnánk lépten-nyomon team-munkában módosítgatni, majd újraoptimalizálni.
Ne haragudjon meg rám a világ, de ez nekem nagyon nem tetszik. Amikor olyan programozási nyelvcsodák vannak, mint Ruby vagy Scala, ne menjünk már vissza 20+ évet, hogy ki tud olvashatatlanabb kódot írni versenyekbe. ne menjünk vissza már a programozás Proterozoikum korába. ;)
Bejegyzések
Nincsenek megjegyzések:
Megjegyzés küldése