.jpg)
Budapest BI Fórum - első nap ("Open Analytics")
A blogoszféra ezen eldugott sarkában, mindig különleges érzés (érdemi) hozzászólással találkozni, köszönet érte. :)
A téma meg annyira nagy és fontos, hogy azt gondolom megérdemel külön blogposztot. Nehezítő körülmény számomra, hogy mostanság teljesen más témákban mozgom, így extra kihívás összeszedettnek lennem, de megpróbálom.
Szerinted jó volt a Sidló előadása a Sztakiból? Persze, rosszak a kereskedelmi ETL tool-ok, majd ők megmutatják. Több év alatt írtak egy egygépes(!), "jól skálázódó" eszközt, (többek között a mi adóforintjainkból). 2013-mat írunk, nem baj. Open source-á tették, mert manapság az a trendi..csak minek...
Jó volt-e Sidló Csaba előadása?
Mielőtt az érdemi, lényegi mondandóra térünk, álljunk meg itt is egy percre. Mitől jó egy előadás (számomra)? A Budapest BI Fórum második napjáról szóló - sötét tónusú - blogposztomban bőségesen kitértem erre is (igaz nem fókuszáltan). De ha már explicit felmerült most, akkor szedjük pontokba is:
- A legfontosabb ismérv, hogy az előadás végén szomorúan konstatálljam, hogy vége, illetve fogalmazódjék meg bennem, hogy egy szinttel mélyebbre menve, tartson mégegyszer annyi ideig. :)
- Foglalkoztassa a téma a szakmai közvéleményt, ha lehet már az előadás elött.
- Ezzel szemben az előadás konkrét mondandója meg legyen minél újszerűbb, akár csak kontextusában.
- Állítson valamit az előadás, de olyat, hogy lehessen róla vélemény - horribile dictu ellenvélemény - a közönség soraiban. Ez nekem kardinális kérdés, itt a blogon is. Óriási (parallel létező) információtömeg vesz körül minket, elolvasni, feldolgozni sincs időnk rá. Viszont élni, valamilyen ösvényen haladni azt mindannyiunknak kell. Ha új információ érkezik azt meg kell vizsgálni, azt be kell építeni vagy éppenséggel el kell vetni, azaz valamit csinálni kell vele. Ezért a vélemények számomra nem l'art pour l'art párhuzamosan léteznek bele a világba, hanem kőkemény versenyt vívnak egymással, ahol a jobb vélemény előkelőbb helyezést ér el. Ez maga után vonja, hogy a véleményt vállalni kell, még ha egy későbbi ellenvélemény felül is írja. Ha nincs vélemény, akkor nincs ugyan "bukás" se, de nézetem szerint, némi extrapolációval, kár volt a témával foglalkozni.
- Legyen nagyon nagy személyes varázsa az előadónak. Mivel kevés kiemelkedően jó előadót ismerek, hajlamos vagyok azt feltételezni, hogy ez valami istenadta - tanulhatatlan - adottságból fakadhat. A konferencián az én fogalmaim szerint Arató Bence és Földi Tamás ilyen kvalitású előadó. Vagy éppen Sidló Csaba munkatársa ifj.Benczúr András, aki sajnos nem volt itt.
- Végül legyen szellemes, humorral fűszerezett. Ez olyan mint a só a bográcsgúlyáshoz. El lehet hagyni, de érdemes? ;)
Számomra Csaba előadása:
- Fontos "hottopic" témát vesézett, fogalmazódtak meg kérdések is a közönség soraiban. ;)
- Újszerű mondandója volt az előadásnak
- Sajnáltam az előadás végén, hogy vége volt, mentem volna tovább a mélyebb részletek felé.
- Őszinte véleményt formált, meg indokolt is (amennyire ideje engedte), kevés ilyen előadó volt a konferencián.
- Emlékeim szerint némi poén is volt. :)
Rosszak a kereskedelmi tool-ok
Ez bizony az én általánosító megállapításom is. Több összetevője van ennek:
- Maga a műfaj kelt egy kvázi kivédhetetlen hátrányt, nevezetesen, hogy úgy generál komoly overheadet egy cég életében (licence, fejlesztés, üzemeltetés), hogy ezenközben a hozzáadott érték roppant kicsi.
- Sokszor rossz elvek mentén fejlesztették őket (például adatbázis repository alapokra)
- Az ETL-eszközöknek sok-sok évük volt, hogy fejlődjenek, de valamiért megrekedtek egy nagyon alacsony szinten. Tudomásom szerint szakmai konszenzus van abban, hogy minden ETL eszköznek van (védhetetlen) hülyesége.
- Az ETL-eszközökhöz órási - számomra visszataszító - marketing tartozott mindig is, ami horibilissé tette alkalmazásuk költségeit.
- Az ember nehezen tudja elképzelni, hogy ne lehessen szerethető ETL-eszközt írni. Az hogy jó adatmodellező szoftvert nagyon nehéz írni, azt el tudom fogadni a magam részéről, de egy ETL-eszköz fejlesztése azért mégse egy "rocket science".
- És akkor egy szót sem szóltam a konkrétumokról. ;)
* OWB-vel 2.1-es korában találkoztm először. A generált kódja hibás volt (le sem fordult). Milyen "élmény" volt utána kézzel ráhackelni. Arról az inkorrekt Oracle-s hozzáállásról nem beszélve, hogy a vásárlóival fizetette meg az OWB fejlesztési költségeit az Oracle. Kiadott egy használhatatlan ipari hulladékot pre alpha állapotban és a fizető vásárlók idegrendszerén zongorázva javította éveken át. Majd az ODI-akvizició után halálra is ítéli.
* ODI. Nem lenne őszinte/hiteles véleményt formálnom róla, mert éles projektben nem találkoztam vele (hiába tűnt első ránézésre szimpinek). Aki OWB-zett kollégám, az mind utálta (teljesen más logikája miatt). A horribilis árképzése miatt viszont nálam végérvényesen leírta magát.
* Business Objects Data Services, a híres nevezetes BODS. Egy komplett ipari hulladék, nullához közeli fórumos élettel, horribilis áron. Életem egyik legrettenetesebb fejezete a vele való éles projekt.
* IBM Datastage. Első ránézésre egy szimpi ezsköznek tűnik. Csak ne kelljen vele éles projektet csinálni. Zavaros, hiányos, logikátlan.
* A témában a legígéretesebbek még az open source eszközök. Igen pont az open source eszközök. pl.: Talend. Na nem mintha annak memóriaigényén, bugmentesítésén ne lenne például faragnivaló.
Majd ők megmutatják
Csaba elmondása szerint ők csak dolgozni akartak eredendően, eszükben nem volt újat írni. Meg is vizsgáltak (kimértek) néhány eszközt, megpróbáltak többükkel eredményt elérni, de számukra fontos dolgokban korlátokba ütköztek. Ennyi rálátásom még nekem is van a Sztaki-tevékenységekre (korábbi évekből), hogy ezt kívülről érkezve validáljam magam is.
Mindazonáltal a "majd ők megmutatják"-ban sem látok kivetnivalót. Hiszen a végtermék hitelesít úgyis.
Több év alatt írtak egy egygépes(!), "jól skálázódó" eszközt
Ezt sajnos nem tudom tárgyilagosan elemezni, érdemi információk hiányában.
Nem tudom miért írod az "egygépes"-t. Legalább csak a mérések párhuzamos környezetet igényeltek. Vagy te résztvettél benne, és konkrét infóid vannak?
A mi adóforintjainkból
Nem szeretnék politizálni pláne ezen a blogon nem. De ezzel a felütéssel ugyanúgy nem értek egyet, mint a "lélegeztetőgép-valutával".
Aztán én biztos nem érzem magamat hivatott személynek arra, hogy eldöntsem, hogy mely témákkal érdemes vagy nem érdemes mennyire foglalkozni, Még a magam számára sem tudom eldönteni, hogy például egy SVM-paraméterezésbe, mennyi időt lenne ildomos feccölni. :)
Sztaki meg ráadásul nemcsak adóforintokból él, hanem kőkemény piaci versenyző, ráadásul tudtommal meglehetősen "vastag ceruzával". Magyarán e nélkül éhen halnának.
Ha meg csak a szakmát nézzük, ifj. Benczúr András meg Lukács András személye számomra igazi garancia a minőségi munkára, megújulásra. Tudnék ellenpéldát mondani, az egyetemi szférából.
2013-mat írunk, nem baj
Én egy jó ETL-eszköznek 2015-ben is tudnék örülni. ;)
Open source-á tették, mert manapság az a trendi..csak minek...
Ezt az ellenérzést viszont sehová nem tudom tenni. Kicsit olyan nekem (extrapolációval), mint "adakozott az árváknak a szemét".
Mi baj van avval, hogy open source-szá tették. Örüljünk neki, ez semmit nem von le az élvezeti értékéből, sőt. Ha nem lenne Knime/RapidMiner/Weka, most is tízmilliókért lehetne csak adatbányászkodni.
Külön érdemes összevetni a "mi adóforintjaink"-ellenérzéssel. Pont hogy visszaosztottak valamit a közösség felé általa. Nem pedig "sales"-osztályt hoztak létre, gigantikus overheadet generálva. Lásd még idevágóan, hogy a tudósok által írt cikkek csak nagy nehezen lassan férhetők hozzá szabadon az őket támogató közösség számára.
Bejegyzések
Nézd, a sok marketingszagú külföldi előadás mellett vártam ezt az előadást, a Sztaki számomra (is) a minőségi megoldásairól ismert (szótár..stb)
VálaszTörlésAmit nem értettem viszont, (és ennek a csalódottságnak adtam hangot!) hogy miért nem gondolkoztak rögtön elosztott, többgépes feldolgozásban?
Hidd el, product managerként én sem vagyok oda a kereskedelmi eszközökért, szükségünk is lenne egy jó tool-ra, de ami tényleg többgépen skálázható, ha már adatfeldolgozásról
beszélünk. Az említett Storm integrációt szívesen megnéznénk, kipróbálnánk.
Egyetértünk: túl sok volt a túl marketingszagú előadás a konferencián.
TörlésNem tudom mennyire gondolkoztak, gondolkoznak a Sztakiban a többgépes feldolgozásban, milyen ehhez a felszereltségük, mit bírtak el gazdaságilag (mekkora overheadűek lettek volna) azon pénzes projektek, amiknek a kérdéses open source eszköz lett a gyümölcse.
Azt sem tartom lehetetlen meg helytelen küldetésnek, hogy egy következő evolúciós fázisban implementálódjék a párhuzamos feldolgozás full támogatása.
Azt elhiszem, hogy szükség lenne egy jó ETL-toolra, és ez az igény nem speciális. :)
A Storm-integráció óriási gondolat szerintem is, remélem sikerrel jártok a megnézését illetően.
Az előadás minőségére nyilván nem, de néhány témára reagálok részletesebben, érdekes dolgok kerültek elő.
VálaszTörlésMiért. Amit a Longneck megold (ami inkább data quality eszköz, mint ETL), az tudományosan nem túl izgalmas probléma (az entity resolution feladatot kivéve, de arra külön megoldásunk van), viszont sok gyakorlati adatbányászati és más analitikai projektünkben felmerült. Ezekre fejlesztett ipari alkalmazások mentén jutottunk a mostani Longneckhez. Kezdetben költséghatékonyabbnak tűnt egy saját eszköz fejlesztése; ha most kezdenénk ez már biztosan nem lenne így, de menet közben mindig érdemesebb volt a saját eszközt továbbvinni, mint áttérni másikra. Ezzel még csak egyedül sem vagyunk, az utóbbi években csak itthon láttam két hasonló eszközt (az egyikre emlékszem, nemrég volt egy big data meetupon, mETL). Nem hiszem hogy bárki "jól megmutatom" indokkal fejlesztene, egyszerűen racionális ez a döntés bizonyos esetekben.
Nyílt forráskód. Mint szoftvermérnökök igyekszünk minél jobb eszközt fejleszteni, és büszkék vagyunk a szép megoldásokra ("a programozás célja jó minőségű szoftvertermék előállítása"), de folyton látunk olyan pontokat, ami nem ideális, amin lehet és kell javítani. A nyílt forráskódúság ezt a javulási folyamatot nagy mértékben képes felgyorsítani. Jó sok más előnye is lehet a nyílt forráskódnak, de én most egy másik tényezőt emelnék még ki: azt, hogy az ETL és data quality eszközök piaca elég zárt. Részben emiatt mint kutatócsoport nem akarunk itt versenyezni - nincs hozzá kellő marketing és sales gépezetünk, a vezető eszközök pedig sokszor pont ebben jók. Ráadásul a Longnecknél sem önmagában a keretrendszer érékes, kell hozzá a benne leképzett üzleti tudás, ami pedig leginkább akkor fejlődhet, ha a keret könnyen elérhető és egyszerűen használható - aztán úgyis húzza magával a keretrendszert. Nekünk pedig mindkettő érdekünk, ezért kerekítettük le mint önálló egység, és ezért tettük nyílt forráskódúvá és ingyenessé; nem divatból, hanem mert ezt látjuk a Longneck leginkább ígéretes jövőjének.
(Mellékszál, de a piac zártságából következik részben az is, hogy alapvető szoftverminőségi elvárásokat a nagy eszközök képesek nem teljesíteni. Miklós szerint a hozzáadott érték a befektetetthez képest elég kevés tud lenni, ezt én is osztom sokszor; de tényleg, ha rábökök a magic quadrant vezető szegmenséből valamire, közben fellapozom a wikipedia software quality bejegyzését, elég jó eséllyel gyorsan eljutok egy olyan pontig, amin elbukik, és ez még csak nem is egyéni ízlés kérdése lesz.)
És végre, a skálázódás. A kezdetektől fogva elsődleges cél - jó ideje sok big data jellegű témával foglalkozunk. Ehhez elég sok minden adott nálunk, az elméleti háttértől kezdve feladatokon át a gépparkig. A Longneck egyszerű feldolgozási és adatmodelljét nagy részben motiválta az, hogy lehessen osztott módon és adatfolyam környezetben is használni. A longneck-storm futtató mégis csak kísérleti egyelőre; miért? Mert a gyakorlati feladataink egyelőre nem igényelték a több gépre szétosztást. Egyszerűen hamarabb ütközünk input olvasási korlátba, mint számításiba. Egyébként ez sem egyedi megfigyelés; a GraphLab például szép osztott adatbányászati eszközkészlet, mégis nagyon pörög a GraphChi, az egygépes változata. Miért? Mert a felhasználók feladatai többnyire nem igényelnek többgépes környezetet. Itthon hol van olyan adatmennyiség, hol kell olyan feldolgozási sebesség, ami indokolná a többgépre osztást? Tudok persze példákat mondani, de a jellemző feladatok, a data quality eszközök elsődleges alkalmazási területei nem ilyenek (már ha nem valamelyik nagyon rosszul választott eszköz sebességét vesszük alapul). A Longneck tényleg egyszerű feladatot old meg: egymástól független rekordokat olvas, transzformál, ír; ez a rész ritkán bonyolódik túl. A streaming környezet az, például szenzor vagy logadatokkal, ahol ez leghamarabb meg fog dőlni, mivel ott jellemzően nem diszken tárolt adatból dolgozunk, ezért is a Storm mint környezet.
Örülünk viszont minden új felhasználónak, sőt fejlesztőknek is akár! Tehát, ha valóban érdekel a longneck-storm, Peter.Zende, szívesen segítünk kipróbálni,akár azzal, hogy előbbre hozzuk a publikálását, elérhetővé tesszük. Ez igényel némi munkát, open source-ként sem (sem helyett lehetne nem is) érdemes félkész, dokumentálatlan vagy egyébként használhatatlan eszközt kiadni, de ha van motiváció, könnyebb rá megtalálni a hiányzó néhány napot.
VálaszTörlés