Magamról

Saját fotó
Főiskolai, majd egyetemi diplomamunkáimtól kezdve világ életemben, adatok, adatbázisok, adattárházak (leginkább Oracle) környékén mozogtam. Mostanság adattárházasként, adatbányászként élem napjaimat.

2013. június 29., szombat

Coursera: Introduction to Data Science



v3.0, 2013-07-02, Oracle kiegészítés az "IGEN-érvek" szekcióban és peer-to-peer dolgozatjavítási adalék.

Coursera: Introduction to Data Science (Bill Howe-University Washington)

Épp ma gondoltam bele, hogy annyira öreg vagyok már, hogy egy olyan felsőoktatási intézményben tanítottam évtizedekkel(!) ezelött és éveken át - 99,99%-ban lányokat :) -, amely intézmény a több évtizede létező nevét ("Könnyűipari Műszaki Főiskola=KMF"), illetve státuszát azóta legalább 3-4-szer változtatta, a rendszerváltási hevület nagy kavarásaiban. A www.kmf.hu url már nem is él. ;)

A másik érdekes dolog idevágóan, hogy olyan témában végeztem a minap online kurzust, aminek a tárgya (data science), még úgy volt ismeretlen az én egyetemi éveim alatt, hogy még az "előzménye" vagyis az adatbányászat is ismeretlen volt, megnevezésében is, tananyagában is (egy hang sem volt róla, noha akkor már létező dolog volt angol nyelvterületen)

Mindezt csak azért említem, mert végigcsinálva a címbeli és link mögötti online kurzust, a fentiek miatt hallgatói és oktatói szemmel egyaránt érdekes számomra, egy pillanatra megállni a nagy pörgésben, és némi konklúziót vonnom. A videó-leckéken, a neméppen triviális kvízeken, a kitűzött feladatokon, megoldásukon, értékelésükön teljeséggel túl vagyok, a certificate-t még ugyan nem kaptam meg (ha megkapom egyáltalán), de ez már nem oszt és szoroz a kialakult véleményemben.

Több - tárgyba vágó nemcsak Coursera-s - kurzusba néztem bele: és úgy ítélem meg, hogy 2013 tavaszán két kurzus emelkedett ki toronymagasan a mezőnyből. A címbeli valamint Coursera: Machine Learning (Andrew Ng-Stanford University). Az utóbbi előadóról sokat elárul, hogy az egyik nagytömegű Kaggle-versenyt az ő - társszerzőként jegyzett - cikkének algoritmusával nyerte meg a győztes (szememben ez nagyon nagy dolog), úgy hogy az élboly többi versenyzője teljesen más algoritmusokkal kísérletezett. Valamint Kaggle-versenyzők sokasága emlékszik meg róla nagy szeretettel.

Mindazonáltal Bill Howe kurzusa még az ővénél is kellemesebb emlékeket jelent majd számomra.
- Eredeti módon gondolkodó, szellemes figura volt az előadó, nagyon élveztem a mondandóját (azt is amit tudtam, azt is, ami új volt nekem).
- Jól választotta meg a tematikát.
- Remekül alakította ki a feladatokat(ráadásul volt opcionális és kötelező, ami szintén piros pont nálam). => kvízek, programozási feladatok, tankörtársas kiértékelésű feladatok, projekt, verseny.
- Fontos volt neki, hogy a hatékonyság érdekében "funny" legyen a munka, és én ebben maximálisan igazat adok neki (én is ilyen voltam oktatóként, jóval szerényebb kiadásban). Más kurzusnál az izzadságszag sokkal inkább dominált.
- Messze a legkönnyebb(nek érzett) kurzus volt teljesíthetőség szempontjából.
- Mégis komoly(abb) hozzáadott értéket tudott nyújtani.Vesd össze "nem dolgozni kell, hanem produkálni!"
- Sokat - sőt szerintem rengeteget - tanultam, fejlődtem, formálódtam magam is a kurzus által. Ami perdöntően Bill Howe érdeme, olvasatomban.
- Sok ötletet generált bennem az egész kurzus.
- Naggggyon jó volt angolozni általa. Erről szólok később is.
- Voltak letölthető prezentációk
- Voltak angol nyelvű feliratok is a videkhoz.
- Sőt még blogposztokat is generált :)
- Egyetlen negatívumot tudok csak mondani: a vendégelőadók nyomába sem értek Bill Howe-nak, prezentációik is, mondandójuk is nagyságrendekkel gyengébb volt.Semmi kifogásom a vendégelőadók ellen, lehetnek jó választások is, itt nem azok voltak. ;)

Hogy negatív példát is mondjak (röviden), ez a kurzus viszont borzalmas volt (az én értelmezésemben): Coursera: Statistics-Making Sense of Data (Alison Gibbs, Jeffrey Rosenthal -University of Toronto). Statisztika témában ez sokkal ígéretesebbnek és életszerűbbnek tűnik:Coursera: Statistics One (Andrew Conway-Princeton University), ami szeptember 22-én indul majd.

Magam részéről mindenkinek javaslom egy ilyen kurzus végig csinálását, meghatározó és döbbenetes élményeket lehet szerezni általa. Két kiegészítéssel.

- Érdemesebb inkább két hónapot rászánni 1-2-3 db párhuzamos kurzusra, mint munka mellett csinálni, akárcsak egyet is. Természetesen a "papír" megszerezhető munka mellett is, de a megszerzett tudás mélysége, "beégetettsége" - ismerve a "bolond", és tapasztalat szerint napi több mint nyolcórás, informatikai melót, projekteket - jobb tud lenni az előző esetben. Hosszú távon nem hiszem el, hogy mindkettőre lehet 100%-ban fókuszálni. Az én kurzusos koncentrációm is exponenciálisan csökkent, amikor beesett egy németországi nagy-projekt a munkahelyemen. "Egy s*ggel nehéz két lovat ülni"

- Ha valaki csak a papírért csinálja, készüljön fel, hogy a technika ördöge miatt nemfeltétlen kapja meg sikeres elvégzés eseténe sem. Konkrét infóm van ilyesmiről is, szerencsére nem velem történt meg, bár még megtörténhet. ;)


Na és akkor lényegről: :)


(1) Coursera típusú (ingyenes?) kurzusok valamilyen sorozata kiválthassa-e a jövőben az egyetemi diplomát?

NEM-melleti érvek:

Engem olyan tanár-óriások tanítottak többekközt, mint Bánhegyi György, Zentai Károly, Benyák Ferenc, Scharnitzky Viktor, Kiss László, Babai László, stb. A tőlük kapott életreszóló élmények reprodukálhatatlanok egy személytelen online kurzus kereti között.

Nagyon nehéz elérni, hogy csalók kívülrekedjenek. Nulla tecőleges részvétellel is lehet papírhoz hozzájutni jelenleg. Nyilván vannak visszaélések a jelenlegi felsőoktatásban is, "puskán" túl is, mégis nagyságrendbelinek érzem a különbséget.

Nagyon nehéz a tudást gépekkel megbízhatóan tudást mérni és minősíteni, mégha vannak is újabb lehetőségként ("peer assigmentek") tankörtársi dolgozatjavítás is. Csak ez az egy téma is óriási perspektívákat, kihívásokat, eredményeket fog szerintem támasztani a következő években.


IGEN-melleti érvek:

Tömegeket lehetne valós módon magasabb szinten oktatni (visszaélési lehetőségek kiszűrése után), objektív értékeléssel, állandó továbbképzés/aktualizálás perspektivájával.

A legjobb módon segíti a szegény tehetségest.

Államvizsga nélkül nem dobódik ki öt "felesleges" egyetemi év, viszonyt nyugdíjasként is csatlakozhat az ember, korlátlanul. Időpillanat helyett időtávban fejti ki jótékony hatását.

Komolyabb szakmai kapcsolatok jöhetnek létre, tudnak karbantartódni a diákok között. Kézzelfogható tapasztalat volt.

Nincsenek feleslegeskörös "szivatások", mint a valóvilágos felsőoktatásban. Az én véleményem megoszlik a szükségességről, akkor is, ha "szivatástengerben" elég jól tudtam lavírozni

Óriási potenciált látok az online kurzusok mellett az Oracle Corp. típusú lerabló, inkorrekt OCA, OCP típusú vizsgák elleni konkurálásban. Egy tisztességes munkáltatónak mindegy kell legyen, hogy Oracle vagy más elismert cég ad papírt Oracle tudásról.. Más szóval amit az Oracle tud tanítani, azt más is tudja tanítani, tisztességtelen extraprofit nélkül is.


KONKLÚZIÓ:
(A) fogalmam sincs, perpillanat, - fogjuk rá, hogy túl friss még az élmény... ;)
(B) nagyon - értsd: naggggggggggyon - drukkolok neki.


(2) Lehet-e tömegeket gépi segítséggel számonkérni, vizsgáztatni, korrekten, objektíven, arányosan, csalásmentesen? 

Ez szerintem óriási és szenzációs topik. Ennek kedvéért vágtam bele ebbe a blogposztba. :)

A téma nyilván gyerekcipőben jár még. Az igazán izgalmas kérdés, hogy meddig juthat el teoretice illetve gyakorlatilag? Mit lehet és mit irreális elvárni tőle?

Nyilván vannak különbségek. Data Science nyilván könnyebben számonkérhető tudomány, mint mondjuk egy szociológia, vagy zongorázás-tudás.

Torrent analógiára a peer-to-peer dolgozatjavításban óriási fantáziát és lehetőséget látok a magam részéről (perspektivikus értelemben). Akkor is, ha magam is idegenül fogadtam kezdetben, akkor is ha van hiba, meg gyerekbetegség a témában. Egyébként egy ilyen javítási feladatsort abszolváltam a háromból, és nálam a javítás 100%-os minőségű volt és én is szívesen javítottam a többiek megoldásait, a kötelezőkön felül is (300%-ban).

Rájöttem ma munkábajövet arra a trivialitásra, hogy ez a peer-to-peer dolgoztajavítás tökéletesen tud működni az idő horizontján.
Egyrészt didaktikailag helyes ha a tanulók dolgozatot javítanak, mert mélyül vele a tudásuk.
Másrészt díjazni kell pontokkal azokat, akik az átlaghoz minél közelebb esően javítanak.
Annak esélye ugyanis progresszíven csökken, hogy sokan egyformán rosszul javítanak és egy valaki jól javít, illetve valaki mindig átlag közelébe javít.
Azaz határértékben az javítók átlaga közelíti a jó értékelést és az átlagtól való minél nagyobb eltérés közelíti a rossz javítást.
Fontos megállapítani, hogy a (névtelen) jó dolgozatjavítás honorálása motiválóan hat a tanulókra.

Akármilyen korlátjai is vannak az online kurzusos gépi számonkérésnek, csak a jelenlegi metódusai is pregnánsan és impresszíven világitanak rá valós való életbeli poblémákra.

Ott van például a Rigó utcai angol nyelvvizsga. Kell-e ember az angol tudás konkrét méréséhez (nyelvtanteszthez már ma sem kell, ugye), merül fel az emberben a triviális kérdés?! Persze a tesztösszeállításhoz már igen, de nem ez itt a lényeg ugyibár.

Világosan kell kell megkülönböztetőleg látni, hogy az ember  nyelvtudásmérésnél...
(1) saját maga is tudni akarja, hogy hol tart pontosan a nyelvtudásban.
(2) de a "karrier-szempontú" nyelvvizsgapapírnak is megvan a maga funkciója.
Nekem mindazonáltal szimpatikusabb a való élet kihívásainak való megfelelés, mert egzaktabb, megbízhatóbb, ösztönzőbb.

 Aki egy angol nyelvű Coursera-s kurzust megcsinál, az nyilván jobbnak tekinthető angolból, mint aki nem. Aki megbízhatóan tud angolul chat-elni, az még nem biztos, hogy átmegy a Rigó utca szóbelijén, de már értékelhető az idegennyelvű kommunikációja, az írásbelin túl is. Ugyanígy aki szakadozó mobiltelefon-vonalon, érdemben tud választékosan vitatkozni filozófiai témáról, ez a dolog nyilván erősebb nyelvtudást feltételez a Rigó utcai vizsgához képest.

A Rigó utca nyelvvizsga az egyén szempontjából egyszerre lehet
(1) felüllövés
(2) alullövés.
(3) mellétrafálás

A Rigó utca nyelvvizsga az én témábavágó megközelítésem szerint:
(1) mesterséges képződmény (nem tud más lenni),  ami egyszerre akar minden igénynek megfelelni.
(2) nem képződik le jó a való életre, illetve
(3) időpillanatra szól, nem időtávra.

Mindez csak az online kurzusuk melleti lehetséges pozitív érvek végiggondolásához lehet adalék.

Szóval hajrá online kurzusok! :)

2013. június 28., péntek

Oracle Database 12c (v12.1)


Szép csendben kijött a tárgybeli szoftver újabb főverziója, szokás szerint első körben (Linuxra, Solarisra).

10/11g grid "g"-je után a 12c verziószámban lévő "c" utal a 'cloud' ("felhős informatika") egyre nagyobb jelentőségére, irányába való elkötelezettségre.

Szemezgetve a friss meleg pár napos 128 oldalas New Feature Guide-ból:

Oracle Database 12c Documentation

* PlSql függvény definiálható az SQL parancsok WITH clause-ában, ami különösen csak olvasható (read only) adatbázisokban nagyon finom lehet. Létezhet-e olyan feladat a világban, ami nem oldható meg SQL-lel, pláne ezek után....  :)

* Temporal Validity megjelenésével több idődimenzió is adható, létező táblaoszlopok, vagy éppen az RDBMS generálta oszlopok felhasználásával. Eddig, ha az ember ha csak azt meg akarta különböztetni alkalmazásában, hogy üzleti vagy technikai validitás, akkor vagy workaroundot programozhatott, vagy vehette meg az Oracle Total Recall-hoz az Advanced Compress Option-t, ami egy bő 25%-os felárat jelentett. Természetesen ennek az ujdonságnak a Flashback-lekérdezésekre is ösztönző hatása volt. :)

* Oszlop-alapérték (default value) most már lehet Oracle-szekvencia is.Default value explicit NULL-beszúrásánál is tud élni már. Ezek migrálást is könnyítő lehetőségek.

* Identity SQL-szabvány alkalmazása, átvétele, ezzel a PK-t adó egyedi sorszámozás garantálható, szekvencia-húzás, vagy egyéb módszerek nélkül is.

* MATCH_RECOGNIZE clause natív SQL-ben, rekord-mintázatok megtalálásához. Adattárház építésénél hasznos eszköz lehet.

* Parciális index kreálható particionált táblák esetén.

* Adaptive Query Optimization: azaz, ha rossz az induló SQL-plan, akkor az a mondás,hogy képes lesz az SQL-engine kijavítani saját magát. Annyira azért nem váratlan az ötlet megjelenése, a folyamatos intenzív adatgyűjtés (aka statisztika) már most is meglévő lehetősége mellé.

* Oszlop-csoport detektálása szintén a bővített statisztika révén, SQL-plan optimalizáláshoz.

* Párhuzamosított statisztika-gyűjtés.Ez az az erőforrás-igényes művelet, amin jó minél előbb túllenni bármikor, bármilyen körülmények között :)

* Speciális statisztikagyűjtés Bulk Load-okhoz.

* SQL*Loader-nél mostantól nem feltétlen kell kínlódni control-file-lal (EXPRESS MODE révén), az eszköz megpróbálja kitalálni magának, az adatokból.

* Többszörös index-et lehet mostantól kreálni ugyanarra az oszlop-csoportra (b* és bitmap, uniq és non-uniq => ezt egyelőre nem látom át, mikor igazán hasznos ;), etc.)

* Közvetlen redefiniciós lehetőség táblára particióra (DBMS_REDEFINITION-nal)

* Oracle Scheduler támogatás Data Guard Rolling Update-re.


Adatbányászatot érintően:
* Döntési fa adatbányászkdási funkcionalitás szöveges adatokra. Hiába jó az SVM, a felhasználók egyszerűen imádják a döntési fát, többekközt gyönyörű modell-magyarázhatósága, vagy például sebessége miatt.

* Expectation Maximization (EM) valószínűség-alapú klaszterezés, az eddigi két klaszterezés mellé.A döntő szempont az volt, hogy az eddigi klaszterezések nem nagyon támogatták, ha az input-adatok keverten jöttek például struktúrált és nem-strukturált formákban.

* Feature Extraction SVD-vel (Singular Decomposition Value). A szövegbányászok régóta szeretik és használják ezt az algoritmust, elegáns, nagy adatokra is megy, elméletileg mindig megtehető a kérdéses felbontás. Ráadásul úgy csökkent dimenziót az eljárás, hogy sokszor jobb eredményeket kapunk a folyamat legvégén, mint dimenziócsökkentés nélküli brure force-t (nyers erőt) alkalmazó esetekben.

* Feature Selection GLM-hez (General Linearized Model). A GLM napjaink egyik legfontosabb algoritmus családja, speciális esete kiváltja a közkedvelt logisztikus regressziót is.Feature Selection-je sose volt triviális feladvány, csak akkor ad sokszor megbízható eredményt, ha magát az időigényes algoritmust futtatjuk, ami nem éppen örömteli dolog. Viszont a dolog nehézsége miatt én egyelőre szkeptikus vagyok a sikerességet illetően.

* On the fly keletkező adatbányászati-model használatának lehetősége SQL-lekérdezésekben. Napjaink egyik hot topikja a "data stream"-ek adatbányászata, ahol úgy dőlnek ránk adatok csőstül, hogy egyre kevesebb idő van modellezni meg modelleket letárolni. Ehhez vezető út egyik lépcsője az on the fly modellek kezelése (értelmezésemben).

2013. június 24., hétfő

Lehet-e köze a focinak az adatbányászathoz?


Nem véletlenül így tettem fel a címbeli kérdést. ;)

Nyilván az adatbányászatnak van köze a focihoz, ezt legkésőbben a Moneyball című film óta a nagy közönség is tudhatja. Drága csodaszoftverek gyűjtenek elképesztő részletességű adatokat, játékosokról, meccsekről, ellenfelekről. És persze nemcsak adattonnák zúdulnak a felhasználó fejére, hanem lényegi hatalmas pénzeket mozgató információkristályok is.

A másik irány (foci hatása adatbányászatra) analógiája ma reggel munkábajövet jutott eszembe. A fent említett jólhasználható csodaszoftverek semmit nem érnek Heynckes, Guardiola, etc. tudása, egyénisége, munkája, csapatuk nélkül.Nem elég, ha "trendi" az adatbányászat, meg "sok pénzt mozgathat meg": aki használja annak az ötletei, meglátásai, tudása, egyénisége, munkája éppen úgy kell ahhoz, hogy Bayern München típusú sikereket lehessen elérni.

Az eszköz és a beszállítója párosa önmagában definitive nem lehet a siker garanciája. A legtöbb amit fel tudhatnak mutatni, ha a siker érdemi katalizátorai.

2013. június 22., szombat

Tableau: Egy vizualizációs stratégia lehetséges szubjektív sarokpontjai


Ahogy így - eddigi életutamból és pályámból nem igazán levezethetően :) - egyre többet Tableau-zok - nagyon addiktív a cucc :) -, egyre inkább érett bennem, hogy a vizualizációhoz való - feszültségekkel teli,  problematikus - viszonyomat végiggondoljam/tisztázzam egy blogposzt keretében. .
Az előző Tableau-blogposztom:  Data Science: Tableau8-feladatok

Az utolsó szöget a téma felöli hallgatás koporsójába az általam - szellemes eredetisége, komoly respektálandó gondolkodása révén - nagyon kedvelt és tisztelt Bill Howe(University Washington) hölgykollégájának egy bizonyos Cecilia R. Aragon értelmezésemben, rettenetes színvonalú, hevenyészett - módon összetákolt (összeollózott) semmitmondó témabeli kurzus-fóliasorozata jelentette. Pedig amúgy láthatóan csinos lenne a hölgy. :)

Amit én komolyan vehető, tudományosan is megalapozott, üzleti életben is használható infókat adó, frissnek mondható - 2010/2011-es - kurzusnak tartok az a (jelenleg) stanfordi Dr. Mike Sips kurzusai. A fickó értelmezésemben hasonlóan nagy kaliber, mint Bill Howe. Sajnos nagyon terjedelmes az anyag (féléves), ráadásul a videókon németül beszél, de a prezentációi angol nyelvűek szerencsére, és nagyon profik
Mike Sips féléves vizualizációs kurzusa

Minimum kétféleképpen lehet közeledni a témához:

(1) Esettanulmánnyal, konkrét vizualizációkkal, hogy ne csak levegőbe lógjon az egész. Kerülve az "aki tudja csinálja, aki nem tudja tanítja" paradoxont :)
Szeretnék majd esettanulmány(oka)t is csinálni - már ott kiváncsi vagyok idevágóan, hogy kimerek-e állni ilyesmivel a nyilvánosság elé :), amihez legelébb is egy
(a) publikus,
(b) közérdeklődésre számottartó, érdekes
(c) jó minőségű dataset
...kell. De ez nem ma-holnap lesz, ha lesz egyáltalán. ;)

(2) Sarokpontok(elvek) világossá tételével, én most ezt az utat fogom követni, erre volt legalábbi ihletem az elmúlt órákban. ;)

Ha magamnak adatbányászkodtam, sose volt szükségem vizualizációs eszközökre, tökéletesen jól megvoltam nélküle, sosem éreztem hiányát. Bőven elég teret az informatika és benne a 3GL & SQL illetve a túlzásba sosem vitt Statisztika.

Aztán az sem lehet véletlen, hogy létezik olyan (durva) nézet, hogy a vizualizálás csak a gyengelméjüek gyógyszere, a komoly információ-potenciál úgy is az adatok legbelsejében van, ami (adhoc) manuális kattingatással nehezen megközelíthetőnek tűnt mindig is.

És ha még ez sem lenne elég, akkor az Acces/Excel meg Visual Basic "ingyen" triviális lehetőségéhez analóg módon egyre hozzáférhetőbb, korszerűbb és okosabb kattingatós szoftvercsodák (amilyen ugye a Tableau is), valósággal csábítják a boldog-boldogtalan dolgozókat, "proaktív", zöldmezős, mindennel inkompatibilis, kis monolitikus szigetrendszerecskékben való hogy ne mondjam gányolásra, bemosva jó nagyot, sokszor, a drága, véres verejtékkel megszült vállalati adatbázisoknak.

Kedvenc példám: jó dolog, ha valaki mobiltelefonról tud fényképezni "kattingatással", de lássuk be a komoly fotóművészet az mégis csak másutt van. ;) A komoly szoftverfejlesztés sem titokban fejlesztett, egyszemélyes, sosem mentődő, kliens-oldali, Visual Basic kódolásnál kezdődik. ;)

És bizony a vizualizáció témájában is komoly alapok vannak, törvényszerűségekkel, kritériumokkal, korlátokkal, hibázási lehetőségekkel, objektív mérhetőséggel ("van jobb vizualizáció még ugyanabban a topikban is"). Érteni kell ehhez is, a vizualizálásnál van értelme a vizualizáló hitelességéről beszélni (értelmezésemben).

SAROKPONT: a fentiekből implicite az is következik értelmezésemben, hogy a a vizualizálásnak nem szabad "túlélés"/"létharc"/"odacseszés" jellege, csak azért csinálni ábrát mert tudunk kattingatni. A jó vizualizálásnak (domain-)tudás, háttérinfók, intenzív gondolkodás, optimumkeresés adja az aranyfedezetét, magyarán minőségi módon  dolgozni kell vele, ahogy a fotós is szívét-lelkét beleadja a képébe, nincs "ingyen ebéd". ;)

Mindezen negatívumok, csapdalehetőségek ellenére sem osztom a fenti álláspontot, azaz hogy felesleges kolonc lenne a vizualizálás.
* Van aki egyenesen azt mondja, hogy vizualizáció révén kerül legjobban és leggyorsabban (párhuzamosítottan!) az információ az emberi agyba.
* Az élet tele van redundanciával, ami redundancia hasznos is lehet. Ha az információ vizualizáció útján jut el legjobban a megfelelő helyre, ha hozzáadott értéket tud termelni, akkor a magam részéről csak azt tudom mondani, hogy "hajrá!" :)


Kicsit messzebbről (női divat) kezdve vannak dolgok, ahol a praktikum és a nem kézzelfogható eszenciális kulturfaktorok (divat, esztétikum, művészet, speciális vonzódás egy ruhatári kellékhez, stb) élesen el tud válni egymástól, mint a képen látható "holdjáró cipő". Férfi szemmel sosem tudtam elképzelni, hogy vékony olykor egyenesen magas lányok, hogy voltak képesek ilyen cipőkért akár sok pénzt is kiadni, amit viselni sem egyszerű/praktikus és minimum megosztó (az én szememnben kifejezetten ronda). Továbbá úgy magasít, hogy párkapcsolatnál a hölgyeknél sokszor jobban kizáró ok, ha a nő magasabb.

Hogy hogy kerül a csizma, akarom mondani "holdjáró" az asztalra?

SAROKPONT: Hát úgy, hogy a vizualizáció, bár
(1) alkalmazott művészet,
(2) esztétikai értelemben is tárgyalható,
(3) az alkotó üzenetet akar itt is megfogalmazni/közvetíteni,
mégis alapvetően a
(A) célraorintált praktikumról, pragmatikus hatékonyságról szól,
(B) masszivan konkrét "materialista" célja van, ~elvárásokat támaszt,
(C) jellemzően egy szűkebb célközönség felé.

Ha úgy tetszik, célját tekintve közelebb van a tudományhoz és üzlethez, mint a művészethez.
(A) Lehet objektíven tárgyalni,
(B) Anyagi alapja semmmiképpen nem mecénatúra-bázisú

SAROKPONT: ALAPFOGALMAK:

Értelmezésemben, definiciós behatárolás kontextusában:
- a vizualizáció egy speciális kódolási-dekódolási folyamat az adat és ember között.
- a vizualizációnak célja van
- a vizualizációval üzenetet kell megfogalmazni - kvázi külön "dimenzió" a vizualizációban :))
- a vizualizáció célja "1000 szó" kiváltása
- a vizualizáció célja az el-/továbbgondolkodtatás.
- minden vizualizáció feladatból indul ki, feladat mentén kell felfejteni az eszközöket,  lehetőségeket, korlátokat a vizualizáció céljának teljesítéséhez. Persze nagy ritkán olyan is lehet, hogy annyira megtetszik nekünk egy ábra, grafikus megoldás, ~technika, hogy át akarjuk venni alkalmazás-jelleggel saját témánkba is.
- adatvezérelt, adat(bázis) van mögötte, annak specifikumaival, előnyeivel és hátrányaival.

Vizualizáció célja:
- Expand Working Memory (aktuális munkamemória kiterjesztése)
- Reduce Search Time (keresési idők csökkentése)
- Pattern Detection and Recognition (mintázat észlelése és keresése)
- Perceptual Inference (észlelés alapú következtetés)
- Perceptual Monitoring (észlelés alapú monitorozás)
- Perceptual Controlling Attention (észlelés alapú figyelem-kontroll)
- Cognition with Iterative Interaction (megismerés, iteratív interakciós folyamatokban)
- Supporting Decision Making Process in Time Crisis (döntéstámogatás időstresszben)

Egyetlen valóság négyféle megjelenése:

Adatféleség-lehetőségek


Az adatmodellek lehetnek Mike Sips után:
(1) Diszkrét
(a) Reláció
(b) Topológia
(2) Folytonos
(a) Fields (mezők)
(b) Manifolds (sokaságok)

Vizuális attrtibútumok:
I. Bertin-félék:
* pozició(position)
* méret(size)
* érték(value)
* szövetszerkezet(texture)
* szín(color)
* irány(orientation)
* alak(shape)

II. Továbbiak - többek között - Jock D. Mackinlay révén (a prefuse-t eredendően neki köszönhetjük):
* torzítás(distortion)
* pásztázás(panning)
* zooming(geometriai és szemantikus)
* interakítv szűrés(interactive filter)
* gráf/fa/térkép(Graph/Tree/Map)
* idő(time)
* animáció
* 3d

Vizuális attribútumok "hierarchiája":

Adatféleség-típusok kölcsönhatásai a vizuális attribútumokkal, Bertin szerint.



Analitikus interakciók:
- Comparing (hasonlítás)
- Sorting (rendezés)
- Adding variables (mezőszármaztatás)
- Filtering (szűrés)
- Highlighting (kiemelés)
- Aggregating (aggregálás)
- Re-Expressing (üzenet-ujrafogalmazás)
- Re-Visualiziling (ujravizualizálás)
- Zooming and Panning (zoomolás és pásztázás)
- Re-Scaling (új skálára áttérés)
- Details on Demand (igény szerinti részletek, magyarul lefúrás)
- Annotating (megjegyzéskészítés)
- Bookmarking (hierarchiába-illesztés)

Vizualizálás-modell (Mike Sips)


SAROKPONT: Mi a reláció az adabányászat és vizualizáció között?

Alapértelmezésben, a vizualizációt az adatbányászati folyamat részének tekintjük, abban a tekintetben, hogy segít eladni az adatbányászati végterméket, meg segít újabb megbízáshoz hozzájutni.

Én most speciális egyedi szemszögből szeretném tárgyalni ezt a viszonyt.

Azt gondolom ugyanis, hogy a "számokkal küzdő" adatbányászati folyamat és a vizualizáció úgy két párhuzamosan és önmagában is létező/életképes minőség, hogy rendkívül sok és mély közös vonás van köztük - ezért sem vagyok a témával szemben ellenséges, ugye :) -, minden módszertani eltérésük ellenére is.

* Mindkét esetben a kiindulás nagyon sokszor kétdimenziós sor-oszlop tábla. Persze nyilván van multidimenzionális adatbányászat, meg vizualizáció, de ez most offtopik itt.

* A tábla mindkét esetben tartalmaz alap és származtatott adatokat. Mind az adatbányásznak, mind a vizualizálónak fontos eszköze a származtatott mezők képzése, sőt mondhatni az egyik legfunnybb része az egésznek :)

* A tábla adatprofilozása (típus, alapstatisztika, kardinalitás, szelektivitás, változékonyság, azonosítóság, rendelkezésreállás etc.)  mindkét esetben nagyon fontos. Tudni kell pontosan, milyen adat van benne, mennyire pontos, mennyire megbízható, mi a hatóköre. Persze kattingatni ugye enélkül is lehet, csak eredményt elérni és/vagy üzenetet megfogalmazni nem igazán.

* Mindkét esetben kiemelt jelentősséggel bír a missing values(hiányzó értékek)hez valamint az outlierek(kiugró értékek)hez való viszony.

* Mindkét eljárásban domináns filozófia a tömörítés. Lásd: feature selection, dimension-reduction, segmentation, etc. illetve vizuális ábrába való információtömörítés.

* Mindkét esetben komoly küzdelmet kell folytatni a kombinatorikus robbanás ellen. Minél szélesebb és/vagy nagyobb egy tábla, annál kevésbé esélyes a brute force algotimusok célbaérése, annál kifinomultabb technikák iránt mutatkozik igény a méret, a komplexitás valamint a nemlineáris műveletigények kontextusában.
Ugyanígy vizualizálásnál 15.000 oszlopot (Orange-verseny) nem lehet egy ábrában megmutatni. Illetve, minél több előfordulás van egy-egy kategóriamezőben, akkor szorzatbalépésével egyre valószínűbb lesz, hogy lesznek többihez képest sokkal érdekesebb kombinációk, a kombinációk számosságának növekedése mellett. Ami előbb utóbb zavarni fogja a vizualizációnkat - legalábbis brute force megközelítésnél. :)

* Mindkettőnél alapvető fontossággal bír a legjobb kérdés feltevése (majd lehetőség szerinti megválaszolása)

* Mindkettőnél van (1) adatelőkészítési (2) "modellezési" fázis. Az utóbbi a vizualizációnál a "vizuális formázás", az adatok vizuális attribútumokkal való ellátása, a "csicsázás", ami sosm lehet öncélú, mert az adatokat/információkat/üzeneteket kell hogy szolgálja.

* Mindkettőnél létfontosságú az adatféleségekre vonatkozó (domain-specifikus) humán-tudás. Ezt lehet támogatni - speciális és iteratív rabló-pandúr folyamat keretében - különféle gépi algoritmusokkal, de kiváltani sosem lehet talán.

* Mindkettőt alááshatja DQM-probléma (Data Quality Management).

* Mindkettőnél heurisztikus (értsd nemdeterminisztikus, dinamikus) kutatási módszertan szokott perdöntő lenni. "Befejezni sosem lehet, csak abbahagyni" ;)

* Mindkettő szeret mintázatot keresni ("pattern recognition")

* Mindkettő mélyében ott van a statisztika, például a korrelációval. Mindkettő célja szokott lenni (érdekes) összefüggések vagy éppen össze nem függések feltárása.

* Mindkettőnél működőképes a confirmatory analysis (megerősítő analízis), hipotézisek felvetésével és menedzselésével.

* Mindkettőnél értelmes az exploratory analysis (feltáró analízis), hipotézisek hiányában is.

* Mindkettőnél vannak eredmények, amiket lehet prezentációban megmutatni.

SAROKPONT: Az általam szerethető - üzenettől induló és effektív vizuális konkrétumokban manifesztálódó - vizualizációs folyamat lépései:

A legelső az üzenet (legfontosabb Top-N darab üzenet) kitalálása.

"Entitás" nézés az adattáblában! Lehet választani mire koncentráljon az ember, az üzenethez, ráadásul csökkenti és/vagy irányítja a gondolkodási teret. Ezért szeretem oly nagyon...  :)
Mivel az adatbányász és vizualizáló szeret kétdimenziós táblákra szorítkozni ugye,ezért joinok, mezőszármaztatások miatt több entitás is tud keveredni bennük, de releváns módon kevesebb, mint az attribútumok számossága (ezért szeretjük, ezért emelem ki első helyre). Az előző blogposzt madárvándorlásos példájánál ilyen entitás (madárfaj, repülőtér helye, idő, replőgépek típusa, károkozás, utas, időjárás, kockázat etc.). Azért használtam idézőjelet, mert ez nem egészen fedi a relációs modellezés entitás-fogalmát.

Érdekes/releváns összefüggés keresése. Összefüggések kilószám vannak, orrvérzésig le lehet velük fárasztani a hallgatóságot, "algoritmikus"(generatív) úton. :DDDD

Élvezetes formájú érthető legyen az üzenet. Ötórai teánál sem idegen szavakkal ködösítünk.

Memorizálható legyen az üzenet. Ami a memóriában vagy, az később könnyebben elő is jön, az üzenettel bombázott emberben.

Lényeges és csak lényeges elem(kombináció) legyen az ábrában. Minden legyen benne, de semmi se terheljen feleslegesen. Attribútumkombinációk esetén az a finom, ha a vizuális elemek önmagukban is megállnak, meg a többivel is összefüggésben vannak.

Nem egyformán fontosak az attribútumok, kategorizálni kell őket (id-k,stringek például nem is igazán használhatók fel közvetlenül, kivéve, ha az ID például beszédes ugye, mint az egyik adatbányászversenyen). Más a jelentősége a kvantitatív mérőszámnak és más a jelentősége a kategóriáknak (amikkel egyébként több mindent lehet kezdeni kategórizálásnál, lásd a vonatkozó ábrát. A kis kétértékű természetes kategória éppúgy lehet nagyon hasznos, mint binnelés utáni kategóriák.

Mit tornásszak az adatokon (adatképzés, mezőszármaztatás címén)? Hogy az üzenet ábrázolható legyen (minél jobban), azaz legyen ábrázolható adat az üzenet mögött. Ez a legnagyobb, legnehezebb, legörömtelibb topik. Teljes kifejtése nem lehet célja ennek a blogposztnak.

Van-e az üzenetnek alert-része, kellőképpen ki van-e domborítva?

Null, N/A, Undefined, Outlier, etc jó vizuális attribútumokat kaptak-e. Nem kell túlspilázni a dolgot, de gondolkodásunk egy kis sarkában ott figyelhet a topik.

Milyen hibákat ne kövessek el vizualizálásnál (ebből is van egy rakatnyi)....
Lehetséges vizualizálási hibák, van belőlük egy rakat, most illusztrációnak kettőt beteszek. A szakirodalom több helyen is mondja, én nehezen tudom elképzelni, hogy ezeket el lehet követni. :)




Eddigi TABLEAU-blogposztjaim:
2013.06.17 - Data Science: Tableau-feladatok
2013.06.22 - Tableau: Egy vizualizációs stratégia lehetséges szubjektív sarokpontjai
2013-07-05 - Tableau: Mindennapi örömök
2013.07.09 - Tableau: Eset a NEM-létező egzotikus nagygépes adatpiaccal
2013.11.16 - Tableau: Aktuális Pros/Cons egyenleg
2013.11.17 - Tableau: Text Table

Ha valakinek még nincs meg a Tableau-szoftver, miközben szeretne engedni a birtoklási csábításnak, az alábbi mail-címen egy kedves, fiatal, aranyos kolléganő igyekszik hatékony és konkrét eszközök segítségével ápolni minden Tableau-vonzatú kapcsolatot. Illetve biztos segít optimális árat találni a termékhez vezető rögös úton. :)
hello@tableausoftware.hu

2013. június 17., hétfő

Data Science: Tableau-feladatok

v3.0 2013-06-21 (Kiegészítettem a feladatokat)

Ez a vizualizálásos topik az, ami állandóan kétségekkel áraszt el engem, amivel kapcsolatban a legtöbb ambivalens, skizofrén érzés áraszt el, még mielött installálnék egy tárgybeli szoftvert vagy elkezdenék írni róla.

Skizofréniám oka, hogy míg egyfelöl műszaki végzettségem óta véremmé vált, hogy "egy jó "ütős" ábra sok oldalnyi szöveget tud helyettesíteni" (Tableau-s információ szerint egy jó ábra akár 1.000 érdemi [angol] szót is ki tud váltani), addig a vizualizációk meg riportok kombinatorikus robbanás mentén szaporodnak és túlnyomó többségük szemét/zaj vagy akként végzi, amint a mobiltelefonokkal hobbifényképeszkedők képei is a facebookon.

Egyfelől van az ember természetes és védhető igénye a vizualizálására, másfelöl ipar van arra, hogy evvel visszaélések történjenek.

Kínzó kérdések rögtön a blogposzt címe után.

(1) Ha eddig Linuxon is működőképes SqLite, Python, Apache, Pig (és csak gyarlóság miatt zárójelezve az R-t, Octave-ot) hozom fel, akkor mit keres "Data Science-feladatok" blogposzt-sorozatban egy proprietary termék, amilyen a Windows-os Tableau?

Elég indok-e, hogy létezik "Tableau Public Free", ahol, ha jól emlékszem, 1 GB-nyi adatig lehet szabadon vizualizálni. Egy újságírónak tuti nagy lehetőség ezt, mert, ha valaki akkor ő könnyedén bele tud férni az 1 GB limitbe, és soha nem látott könnyedséggel tud szép ábrákat csinálni cikkéhez. (Nem elég indok tehát: ettől még a Tableau egy proprietary termék)

Elég indok-e, hogy "funny" használni. Tényleg az. De a ggplot2-t is funny használni, ráadásul egy Data Scientist, aki GB-os állományokkal dolgozik, nap mint nap, lehet jobban szeret programozni (még ha nem is triviális), mint drag and drop-polni meg kattingatni.
By the way én soha ki nem állhattam a drag and drop-ot, mert amikor véletlenül került elő, akkor galibát okozott mindig: meg el is lehet rontani és nem mindig triviális az "undo"-funkcionalitás.
(Nem elég indok tehát: van más "funny" eszköz is, lásd ggplot2, lattice, d3.js, csak a "forróbb" mainstream-vonalról is, hogy az ígéretes hadoop-os Platforát már ne is említsem).

Valahogy tehát az az érzésem, hogy egy fenékkel nem lehet két lovat megülni, vagy durvábban szólva szűznek is maradni, meg jólérezni is magunkat. Mert azonnal jön a kérdés, hogy akkor az SPSS vagy Matlab miért nem "funny"?

(2) Miért nem Javá-ban íródott a Tableau, bevállalva a plaform-függetlenség elvesztését is. Ez manapság se nem trendi, se nem "cool" dolog. Nem lett volna Java-programozó? - Ugye csak viccelődünk?

Az én sejtésem:
- Valahogy hatékonyabbnak érezték a natív gépi kódra fordítást, és tény, hogy a Tableau száguld, mint atom, a használat során. Pedig a Java-s virtuális gépek is csodaszámban fejlődtek az elmúlt években.
- A natív Windows vizualizálásnál sokkal szebb, mint a Java.-s Windows. Ez nekem régről fixa ideám, hogy még egy Java-s Swing GUI-felület sem soha nem tud kellően szép és ugyanolyan használható lenni: meg lehet szokni, de a különbség nem tünthető el.
De most ráadásul vizualizálásról beszélünk.

(3) Mi a helyzet az árral? A Windows-os Tableau Desktop 2.000 USD-s listaárú, de biztos van akinek sikerül ebből alkudnia, még akár 1.600 USD környékére (nemcsak oktatás vagy egyéb "beetetés" révén), míg a böngészős verzió emlékeim szerint ennek fele.
Nem azért mondom, de tökéletes árszabás:
- Ezt még talán itthon is meg lehet fizetni, nem az elérhetetlen kategória.
- Nem fog elkezdeni senki bohóckodni, hogy Trial-ek használatával váltsa ki a fizetést. Vagy Amazon AWS-sel küszködni - merthogy EC2-n keresztül is lehet kérni Tableau-telepítést, igaz a guide hozzá vagy 30 lépéses, neméppen triviális mutatvány. De müxik :)
- Abszolút értékarányos ("kapunk anyagot a pénzünkért", "nem az image-t kell megfizetni"), pláne ha az SPSS Clementine 25.000 USD-jét nézzük, vagy még inkább pláne a SAS Enterprise Minerét (ami csak éves szinten is ennyi).
- Versenytárs nélküli jelenleg az ennyire könnyű és hatékony használat, ilyen vizuális orgiával párosítva, "enterprise scalability"-vel támogatva.
- Még én is - meglehet - megvenném, pláne, ha a kereskedõi jutalékot sem kéne kifizetnem... ;) :DDDDDDDDDD

(4) Ha én profivá képzem ki magamat, milyen olyan use case van, ami NEM Tableau-sales tevékenység?

A jó hír egyfelöl, hogy aki rászán egy kis időt a témára, akkor közepes képességekkel is csodákra lehet képes, azaz a profizmus nem elérhetetlen vágyálom a témában. Az egész Tableau-információs birodalom nem elérhetetlen, nem átláthatatlan. Van egy 1000 oldalas manual, ~70 db Advanced Techniques Guide, ~50 db Webinar, fórum, community.

A jó hír másfelöl, hogy az újságíró is tud self-servioce módon nagyobb eszközkészletet alárendelni a munkájához, úgy az üzleti életben is megvan a lehetőség, hogy ráfordítási idő arányosan is nézve, gazdagíthatjuk eszközkészletünket a munkabeli céljainkat támogatva. Ahogy az említett újságíró is.

És, hogy egy igazi data scientist-es use case-t is mondjak: ha az adatbányászat fejlesztési folyamat során előáll egy GB-os text-es tesztállomány, amit az üzletnek meg kéne nézni, bitre pontosan tudja, hogy mit tartalmaz, de se SQL-ezni, se Clementine-ozni nem (az ár, licence, knowhow-hiány miatt), csak Excelezni: na akkor a Tableau az lehet az ő (valós érdemi alteranatívát jelentő, költséghatékony) eszköze.

(5) Nem takarja-e a csicsa a lényeget? Nem szemét-e a sok végtermék, tud-e összeadódni az (üzleti) intelligencia, az információs/tudás betagozódni a vállalati folyamatokba?

Na ebbe a topikba koncentrálódik tulajdonképpen az összes ellenérzésem. És be kell valljam töredékére sem tudom a választ a felvetett kérdéseknek.

* Amennyire érezzük az igényt egy "ütős" ábrára, vagyis ahol a (1) sok adat vizuális értelemben beletömöríthető egy-egy (2) gondolkodást serkentő ábrába, annyira nehéz objektív egzakt alapokon közelíteni a témához.

A gond ugye az, hogy mondhatni megmérhetetlen módon, de érezzük sokkal több rossz ábra van zaj jelleggel, mint jó ábra. Így attól is elvehetjük a kedvet az ábra-böngészéstől, aki egyébként képes lenne másképp is gondolkodni, mint például szövegek balról jobbra olvasásában

Az én konklúzióm tehát, hogy kevés "ütõs" ábra van, zajos környezetben.

* Bármennyire és fontos egy ütős ábra, lássuk be az igazi érték az adatforrásban, a költségesen felépített adattárházunkban, adatpiacunkban van. Nem Tableau-val kell elkezdeni hegeszteni adatokat, még ha erre van is (korlátozott) lehetőség, még ha olykor ez csábító is.

* Elemző szoftver-e a Tableau? Itt is inkább szkeptikus vagyok, mint amikor a kdnuggets-en annó statisztikai elemző szoftverek közé vették az adatbányász eszközöket (közvélemény-kutatásnál).

Taxonómiát nem mindig tud jól felállítani az ember, legyen bármilyen intelligens, mint egyébként például a zenében sem (értelmezésemben).



Igen! Lehet elemezni a Tableau-val, lehet következtetésekre jutni általa. Nemcsak prezikben tálalni lehet vele, hanem ismeretlen adatforrás (amiből egyre több példa van, egyre nagyobb igények közepette) megértésében is tud segíteni.

Nem! Nem elemző szoftver, ha 15.000 attribútumos datasetre gondolunk. Ember nincs, aki kattingatással állna neki ilyen feladatnak.

Különben is értelmezésemben az elsőrendű prioritása mindig a jó kérdés feltevésének majd jó megválaszolásának van: nem pedig vadul kattingatni bele a világba. Koherens kérdések szülnek csak  koherens válaszokat.


Analógia: "feature selection"-nél pl.: kattingatós SPSS Statistics-szel áll le küzdeni az ember, például két oszlop korrelációjának felderítéséhez, avagy non-visual szoftveres eszközt választ-e a feladat abszolválásához?

Analógia: "Alert"-et szintén a gép tudja jobban folyamatszinten, szintén non-visual alapon (persze tervezéshez ember kell)

Analógia: "Mintázat-keresés"-t szintén a gép tudja jobban. Ahogy adatbányászakodni sem select * from relációs SQL-kkel adatbányászkodunk (maximum, ha SQL-függvényekbe, operátorokba van belekódolva az adatbányász-fukcionalitás, mint az Oracle Data Miner szerver-opció esetén is).

* Hogyan adódik hozzá a domain-tudás? Hogyan lesz idõkímélõ hatékony csoportmunka? Itt vagyok a legszkeptikusabb, a legrosszabb tapasztalataim okán.

A leggyakoribb és leghorrorisztikusabb forgatókönyv, amikor a dolgozó Visual Basic affinitással "felvértezve", Excel-alapokon szigetrendszert épít magának, "nélkülözhetetlenné" téve magát a cégen belül, párhuzamos folyamatokat generálva a céges adattárház/adatpiac mellé. A "rugalmasság" jegyében. És mellesleg mérhetetlen károkat okozva egyéb frontokon.

Na a Tableau-val és egyéb Self-Service BI-eszközökkel mindez "négyzetre tud emelődni". Mindenki inkább individuum, saját ügyféltörzset akar, saját monolitikus szigetrendszert, és persze kész budgetjéért harcolni is, amit a cégek biztosítanak is sokszor, saját érdekeik ellenében is. Az egyéni létharc sokszor felülírja a közösség építésétnek vágyát, igényét.

A "dashboard" meg "riporting" 'bűntények' ilyetén módon nagyon sok kárt tud okozni:
* Párhuzamos, DQM-problémákat is generáló (pl.: migrálhatatlan adatforrások formájában is), működési költséget igénylő hagyományos cuccok az olvasatomban, sokszor jó sok overheaddel, adott esetben "fingreszelés" feelinggel, párhuzamosan a lényeg rejtve maradásával,  látszattevékenységekkel.
* tapasztalat szerint felesleges vagy éppen ki nem kényszerített körökkel,
* nehezen pénzzé konvertálható outputokkal
* mennyiségi szemlélettel (minöségi szemlélet ellenében), kominatorikus robbanás jelleggel, zajjal erősen spékelten: túl sok adat, túl kevés információ.
* mivel van rá motiváció (egyéni és vállalati), így a riportálós visszaélésipar tud pörögni
* a riport-szaporodás kiváló táptalaja a bürokráciának, egyre nehezebb, komplexebb, költségesebb, szerteágazóbb folyamatoknak.
* sokkal hosszabb költséges utak konktrollálatlan lehetősége a várható haszon szempontjából sokkal kérdésesebb versenyelőnyökhöz.
* sokszor egy deklarált probléma megoldása (riport formájában), 10 másik problémát generál, olykor köztudott pontalanságok kíséretében ("ügyféldarabszám"). Rekurzív probléma-generálás.
* totálisan elhanyagolt változásmanagement. Egy riport addig fontos, amíg elkészül és/vagy pisztergálni lehet vele az IT-t. Majd sokszor ott rohad a szerveren napi kigenerálódási célzattal. A riport életciklusa: mintha csak szaporodni tudna az Exabyte-ok világa felé.
* A forintosítás csak a riporting folyamat elején látható/mérhető, hogy mibe fog kerülni. De a visszamérés, hogy mi hasznot, hogyan hozott, szinte sose vizsgálja senki.
* jópofa lehet a dashboard egy mobiltelefonon: színházi elõadás szünetében, valentin napi vacsora közben WC-re is rá lehet nézni a napi eladási adatokra. Pfúj.... Azonban ne tagadjuk, hogy "üzleti igény" van rá! ;)


Ami az említett négyzetre emelést ilelti.a Tableau ráadásul jó(l meg is írt) szoftver, pláne egy árban vele összemérhető hulladék Excelhez képest. Vele aztán lehet termelni, lényegbevágó módon is. Tud nagytömegű adatot, érdemben kezelni, ráadásul "Enterprise" szinvonalon.

Kérdés tehát, hogy Tableau egyik oldalról paradigmaszerű és egyébként örömteli változást hozó filozófiája képes lesz-e másik oldalról a (közel)-jövőben  a szigetrendszerek ellenében, valóban "hozzáadott értéket" produkálni, vagyis az domain-specifikus (üzleti) intelligenciát összeadhatóvá tenni?
- Valós érdemi alternatívát nyújtani, ha már valaki nem tudja/akarja az egyébként cool "felülről kompatibilis" SQL-t megtanulni.
- Hogy még a 2.000 USD se tünjön pénzkidobásnak
- Hogy jó adatforrásból táplálkozik és vállalati folyamatba tagozódik a Tableau-output, vállalati döntéshozatalt is érdemileg támogatva.

Az ambivalenciát meg skizofréniát okozó kínzó kérdések konklúziója: 
- ha a szoftver-használat motivációja/környzete (mi a hatáköre, létjogosultsága) "rendben" van, mert hogy az nem érv, hogy "használják", meg "üzleti igény van rá", hiszen köztudomásúlag "egymilliárd légy sem tévedhet"...
- akkor viszont már jelenleg szerintem nincs jobb termék a műfajban, (ennyire könnyű és hatékony kattingatós darg&drop-os használat, ilyen vizuális orgiával párosítva, "enterprise scalability"-vel támogatva)



Na és akkor kezdjünk el beszélni magáról a TABLEAU-ról a sok "marketing rizsa" után. 

(1) Hatalmas piros pont az installálási folyamatért. Nekem annyira tetszik, hogy két képet is berakok illustrációnak.

A legkultúráltabb mód a licence-feltételek tálalásának: button rá, illetve checkbox arra, hogy a felhasználó tényleg tudomásul veszi.

A custom-telepítés van, csak nem alapértelemzett opció, hiszen nem sok minden lehet szükséges pluszba (második képernyő).

Villámgyorsan felugrik a gépre 350 MB formájában a teljes szoftver.

Ami még érdekes a html-es helpet külön kell installni: mondván használja mindenki a mindig aktuálisabb, frissebb, teljesebb netes infókat.

De magát az 1000-oldalas PDF-es Tableau Desktop manualt természetesen le lehet tölteni:
http://www.tableausoftware.com/support/help
http://onlinehelp.tableausoftware.com/v8.0/pro/offline/en-us/tableau_desktop8.0.zip


Magyarán: kicsi kompakt gazdaságos, belátható ám mégis finom az egész Tableau-cucc.








(2) Hatalmas piros pont a saját fileformátumért

- TWBX=Packaged Tableau Workbook (amiből eXtractolni lehet infókat)
Ez egy síma zip, ami tartalmazhatja többek közt a
(1) TDE-formátumú adatokat,
(2) XML-formátumú "vezérlést", valamint opcionálisan
(3) segédállományokat, például képeket.

- TDE=Tableau Data Extract. Ez egy  proprietary bináris fileformátum, ami a legtömörebben tárol (COLUMNAR DATABASE koncepciónak köszönhetően), hiszen manapság háttértárról olvasni a legköltségesebb művelet (netes fel-letöltögetésekről már nem is beszélve), szemben a processzor és memóriaműveletekkel (lásd RDBMS-ekben is a tömörített táblatereket vagy egyenesen a columnar-oriented DBMS-eket). A később vesézendő Bird Strikes Access-ben 105 MB, CSV-ben 71 MB, Excel-ben 56 MB, TDE-ben 20 MB. Azért érezzük át egy pillanatra ennek kiemelt piros pontos jelentőségét.

Van hozzá kultúrált programozói API is. Mivel proprietary bináris a fileformátum, így a lényegi funkcionalitást DLL-ekben kapjuk.

Azért érezzük, hogy kezd végtelenné növelődni lehetőségeink tárháza, csak ezen a fronton:
- Web-es adatok TABLEAU-sítása
- SQL-es adatgazdagítás, pl.: SqLite révén és/vagy Text/Excel/MsAccess ODBC révén, ha végképp nincs érdemi RDBMS-hozzáférésünk.
stb.



(3) Hatalmas piros pont a "connect to data"-hoz

Imádnivaló használni. 
Széles választékú, felixibilis, teljeskörű.

Az Excel-t már itt el lehet felejteni.
A Custom SQL-el gyönyörűséges benne.

(4) Hatalmas piros pont a performanciáért.

Az én gépemen pikk-pakk, másodpercek alatt korrekten olvasott GB-os állományokat, dolgozott velük (nem úgy mint a Microsoft PowerPivotja, vagy az IBM "új" pár hónapja bejelentett Cognos-csodája).

Külön említésre méltó, hogy van benne működő "progress bar"-funkcinalitás, meg mutatja az eltelő másodperceket. A szoftverkészítők tényleg mindenre igyekeztek gondolni, mindenre igyekeztek odafigyelni, a legapróbb részletekre is. Látnivalóan a felhasználó volt a középpontban, minden szempontból.

Lehet, hogy ez csak Windows és/vagy Proprietary/Commercial-termékvonal alatt lehetséges? :DDDDDDDDDDDD

(5) Hatalmas piros pont ezért a lehetőségért, (default útvonalú) Tableau-állományért:
"c:\Program Files (x86)\Tableau\Tableau 8.0\Performance\PerformanceRecording.twb"
Azért az milyen, hogy Tableau-val tudjuk Tableau-s tevékenységünket monitorozni, majd általa javítani.

(6) Hatalmas piros pont a szépségért, könnyen használhatóságért, világos értelmes működésért. de erről többet beszélni már nem lehet most egyetlen blogposztban. Aki többre vágyik, annak ott a rendkívül szinvonalas, tartalmas, addiktív Tableau-honlap.

Ha egy hátrányt mindenképpen kellene mondani, akkor megjegyezném, hogy a platformfüggetlenség elvesztésével  a 64-bites verzió könnyed triviális lehetősége is elveszett. A Tableau bizony 32-bites szoftver jelenleg, a 32-bites rendszerekre jellemző címzési korlátokkal.

Mondjuk a Tableau és TDE képességeinek érzékeltetésére megpróbáltak egy idei konferenciára összerakni egy real-scenariót egy képzeletbeli bank "Big Data" datasetje alapján. 102 millió sor 1.8 GB-on elfért. Kell tehát küzdeni,hogy Tableau-szempontból értelmes feladattal kinőjük magát a Tableau-t. ;)

Akit meg ennyi sem hatott meg, az meg nem célközönség. :)

FELADATOK. Szokás szerint Bill Howe(University Washington)-től.

Adva van egy Bird Strikes dataset:

Eredeti, 165.000 rekordos, hízó adatbázis:
http://www.faa.gov/airports/airport_safety/wildlife/database/
http://wildlife.faa.gov/downloads/wildlife.zip (165.000 rekord)

100.000 rekordos változat:

http://www.tableausoftware.com/public/community/sample-data-sets
http://www.tableausoftware.com/public/sites/default/files/Bird%20Strikes.xlsx

Reprodukáljuk az alábbi riportokat/dashboardot belőle:

1. Meg kell határozni, hogy az adatforrásunkban hány rekord van:
A Tableau-generált "Number of records" measure (baloldali zöld), felvonszolása "Rows"-ba

2. Mutassuk meg térképes színezéssel a madárrepülések és a repülés induló állama(hol szállt fel a repülőgép) közötti korrelációt
A Tableau generál térképes megjelenítéshez longitude és latitude adatokat.
A Tableau-generált "Number of records" measure (baloldali zöld), felvonszolása a "Color"-hoz
Az Edit Colornál lehet színeket állítani, felcserélni (reverse).

3. Bontsuk meg a költségeket "Origin state" szerint, rekordszám szerinti csökkenő sorrendben
A Tableau-generált "Number of records" measure (baloldali zöld), felvonszolása a "Columns"-hoz
Origin state felvonszolása "Rows"-hoz
Cost Total $ felvonszolása a "Color"-hoz
"Barchart"-ot válasszuk jobboldalon
Ábra alján lehet hossz szerint rendezni, egyébként fenn a "Rows","Columns"-oknál

4. Meg kell határoznia Repülési Dátumok idősorát, heti bontásban.
"Flight Date" felvonszolása, "Columns"-hoz. Vigyázat van folytonos és Discrete Dátum-kezelés!
A Tableau-generált "Number of records" measure (baloldali zöld), felvonszolása a "Rows"-hoz


5. Meg kell határozni ugyanezt éves bontás-ban, "Effect: Impact flight" mező vonatkozásában, de a Null és None-okat vonjuk össze
Kell egy mezőszármaztatás, jobb gomb "Effect: Impact flight" Create Group-pal


6. Kellene egy ehhez hasonló másik "Custom Dashboard", ahol egy általunk kitalált lényeges kérdést teszünk fel, amit az ábra szépen tudhat magyarázni.
A lenti dashboard: http://www.tableausoftware.com/public/gallery/bird-strikes
http://www.tableausoftware.com/public/gallery - Érdemes itt körülnézni, ki hogyan vizualizál.



Két féle irányból lehet támadni a feladatot:
(1)  A meglévő "Bird Strikes" dataset oszlopainak értelmét megvizsgáljuk, miből/melyekből lehet a legizgalmasabb kérdés(eke)t feltenni. Ha ez nem elég, akkor származtathatunk új oszlopo(ka)t is.
(2) A "csicsa" érdekében tobzódunk a vizuális orgiában, ahol az ábrába egy-két-három-etc oszlopot vonunk be "vizuális megformázással".
Például havonkénti bontásban hogyan alakulnak/korrelálnak a károsodási számok, a madárrajok repülésével
Ehhez származtatni kell egy text-mezőt:s
CASE [Effect: Indicated Damage] WHEN 'Caused damage' THEN 1 WHEN 'No damage' THEN 0 ELSE NULL END
Ezután a sheete-ket össze lehet pakolni könnyedén egy "New Dashboard"-ra.



7. Publikáljuk oda az előbbi "Custom Dashboard"-unkat,ahol az alábbi is van
A lenti dashboard: http://www.tableausoftware.com/public/gallery/when-birds-and-planes-collide
A dashboardban a nagy kaland a jobboldali sárgás-kék trend-ábrázolás.

Server/Tableau Public menüponton keresztül megtehető a publikálás.
Kell egy free és egyszerű Community Account regisztrálása hozzá (akár fake mail-címmel).
A publikálás után lementhető a link is, hogy megoszthassuk mással munkánkat.


Eddigi TABLEAU-blogposztjaim:
2013.06.17 - Data Science: Tableau-feladatok
2013.06.22 - Tableau: Egy vizualizációs stratégia lehetséges szubjektív sarokpontjai
2013-07-05 - Tableau: Mindennapi örömök
2013.07.09 - Tableau: Eset a NEM-létező egzotikus nagygépes adatpiaccal
2013.11.16 - Tableau: Aktuális Pros/Cons egyenleg
2013.11.17 - Tableau: Text Table

Ha valakinek még nincs meg a Tableau-szoftver, miközben szeretne engedni a birtoklási csábításnak, az alábbi mail-címen egy kedves, fiatal, aranyos kolléganő igyekszik hatékony és konkrét eszközök segítségével ápolni minden Tableau-vonzatú kapcsolatot. Illetve biztos segít optimális árat találni a termékhez vezető rögös úton. :)
hello@tableausoftware.hu

2013. június 16., vasárnap

Miért útálom oly nagyon a TOAD-ot?

v2.0 2013-06-21

2012 Szeptember 28-án a DELL megvette szőrüstől-bőrüstől a Quest céget, ami (mint a SAS is) független gyártóként kétszámjegyű éves múltra tekint vissza. Az ember azt hinné, hogy a független gyártókat jobban szereti az ember a mammutoknál,  vagy szakmaibban szólva megavendoroknál,  (amilyen az Oracle is), de nem: én a Questet is, a SAS-t is útálom, mind a céget magát is, mind a termékvonalatukat és árképzésüket is.

Árlistája szerint a TOAD for Oracle egyes kiadásai 1.000-8.700 euró (300.000-2.600.000 forint) közé esnek licencenként. Most az útálatomtól függetlenül is, 2008-as válság után nem tűnik életszerűnek az ilyetén árképzéses üzleti modell, logikusan várható volt ez a Dell-es akvizició. Ellenpontként a PlSql Developer jelenleg 216 USD, ~40.000 forint.

Öröktől fogva, amióta a világ világ, vagy legalábbis napvilágra került a két termék (Quest TOAD for Oracle és PlSql Developer) felhasználói kvázi kibékíthetetlen ellentétben állnak egymással. Mindegyik az általa használt termékre esküszik. Egyébként én is. ;)
Olyan a szembenállás, mint a Windows kontra Linux. Vagy még annál is durvább. Merthogy én Windows-ban dolgozóként abszolút értelmes és életképes alternatívaként élem meg a Linuxot, de a TOAD-ra például már fújok.  ;)

Ráadásul ami külön szép, hogy abban a Delphiben írták mindkettőt, ami számomra annó a legkedvesebb fejlesztőkörnyezetem volt, és mára széles körben teljesen lenézetté vált, egyébként teljesen jogosan, köszönhetően a Borland "okostojásainak", akik évek szívós és felhasználóellenes munkájával tönkretették a terméket (el is kellett adniuk, hogy ne termeljen további veszteséget, és azóta már ki tudja hanyadik tulajdonosnál vegetál az egyébként jobb sorsra érdemes cucc)

Legyünk rendesek kezdjük a TOAD előnyeivel. ;)

(1) Séma-exportja ritka flexibilis, ez mondjuk tud nehézkes is lenni, ha valaki gyorsan akarna egyet exportálni, annyi - olykor nem is trivális - dialógusablakon kell keresztül verekednie magát az embernek. De az biztos, hogy ennél többet még én sem nagyon tudnék beleképzelni a funkcióba. Persze csak alapértelmezésben... ;)

(2) SQL/DB-tuningolásra abszolút és verhetetlenül ideális. Saját szememmel láttam, hogy egy kollégám milyen hatékonyan támogatta meg egy 8 órába mindenképpen beleférő (SLA) 1400 job-os adattárháztöltést.

(3) DBA-Admin feladatokat remekül támogat. Egy Oracle Enterprise Manager úgy marad el felületében, használhatóságában, teljeskörűségében, hogy árban talán összemérhetőek egymással.

(4) SQL-monitorja egyenesen szenzációs. Gyönyörűen és használhatóan tudtam nézni, hogy a Business Objects Data Services (világ egyik legnagyobb ipari hulladéka, egyébként ETL-eszköz), milyen SQL-ekkel támadja meg az Oracle adatbázist. Segített felderíteni a "természetesen" nem dokumentált repositoryjának kulcsfontosságú részleteit, amiből aztán értékes üzleti funkcinalitást lehetett elérni.

(5) Table-rebuild. Megkreálódik a script, átnevezéssel, constraint-es ki-bekapcsolásokkal, particionálással, indexeléssel, jogosultságokkal, stc. De egyébként is pikk-pakk könnyű a legkülönfélébb reverse engine-s scriptekhez hozzájutni.

(7) Nagyon tetszik a gombra varrt Sql*Plus hívás lehetősége

(6) Session-browser. Fájó elismerni, de sokkal jobb, mint a PlSql Developeré. De tetszik az is, ahogy egyáltalán elválik a Session-, Schema-, Database-browser.

(8) Scheduler-funkcionalitás kidolgozottabb, mint a PlSql Developeré.


Na és akkor miért útálom a TOAD-ot:

(1) A béka-hang. Az első, amit az options-ben kikapcsolok, ha TOAD-oznom kell. ;)

(2) A világ legocsmányabbul formázott SQL-kódját adja ki magából alapértelmezésben, az én értelmezésem szerint.Ha kapok mailben egy SQL-t, rögtön tudom, hogy ha TOAD-dal lett összerakva - a hányingeremből;)

Ebben a témában én egyébként is "perben-haragban" vagyok a világgal.

Valamelyik "vicces" kedvű IT-s figura annó kitalálta (a világ meg bamba módon átvette), hogy az SQL-eket középre kell zárni, mert milyen "jópofa" középen a függöleges space-oszlop. Én meg ha ilyet meglátok, sírhatnékom támad, annyira szörnyűnek, visszataszítónak, problémákat gernerálónak találom.

A másik ilyen hülyeség, hogy az oszlopokat (másodiktól kezdve) vesszővel kell kezdeni a select-listában (illetve and/or-ral az elemi feltételeket a where-clause-ban). Mondván, hogy a vesszőt hajlamos a fejlesztő lehagyni a végéről így könnyebb a fejlesztőnek bővíteni a select-listát. Igen ám, de ez a fejlesztőnek pillanatnyi időre érdekes csak, szemben az SQL teljes életciklusával, mert az SQL-eket majd olvasók igényeivel. A szem fókuszt a vessző prioritása fogja vezérelni, nem pedig a mögötte lévő lényeg. A vessző vagy az AND az csak overhead az SQL-ben kis túlzással, legjobb lenne, ha nem is látszódna, mert hiszen nincs neki semmiféle üzleti tartalma.

Én ezzel szemben azt mondom hogy
- balra kell zárni,
- törekedni kell a minél kevesebb sorra, soronbelüli karakterszámra,
- az inline view-s struktúráknak első pillantásra jól kell látszódniuk,
- normális épelméjű legyen a zárójelezés az olvasó/visszafejtő számára,
- az SQL-formázásnak az átláthatóságot, a biztonságos módosítást kellene támogatnia, nem ilyen vizuális hülyeségeket mint a függőleges space-oszlopot.
Az ész megáll. ....

Nem értelemes fegyelmezett formázással lehetetlen biztonságosan és kultúráltan komplexebb, többszörösen beágyazott SQL-eket írni, amilyet nekem is kellett írni nem is olyan régen (132 KB, 3050 soros SQL)

(3) PlSql Developeresként  számomra rendkívül taszító volt a TOAD-ban mindig is, hogy egy lekérdezés COUNT(*) /rekordszám/-infójáért külön kell klikkelgetnem, amit én mindig azonnal kézhez kaptam azonnal.

(4) A TOAD számomra feleslegesen nagy monstrum (már az indulásánál is látszik, és utána is csak a szívás van vele), mindent összehányva tartalmaz, ami funkciókból - Pareto szabály szerint - 80%-ban használom a 20%-át, amivel szemben mindent ki is kell fizetnem, olvasatomban erősen túlárazott kalkulálás alapján (érdekes módon mint a SAS-nál is).
A PlSql Developer csak a 20%-ot tudja, de azt könnyedén, lightosan, barátságosan, és töredékáron.

(5) Ki merem jelenteni, hogy a TOAD nem fejlesztő eszköz. Csak van neki fejlesztői modulja is. Olyan is az egyébként. ;) TOAD-hívők is mindig csodálkoznak a PlSql Developer elegáns debuggerén, ami valóban támogatja a tárolt eljárások, hogy ne mondjam VIEW-k fejlesztését. (Nem mintha ő sem tudna befagyni, de ez más tészta)

(6) A TOAD-nak lehetne egy nagyszerű, világon egyedülálló feature-e, a lockolásos, csoportos szoftverfejlesztés, verziókontrollal. Ez lenne ugye a Team Coding. Ha nem lenne olyan használhatatlanul lassú és/vagy bug-os, hogy 2 percig(!) tartson (egyébként i5 procis, 8GB RAM-os desktopon) egy checkout-checkin session, olyan hibákkal, hogy a VIEW-k ablakai konkréten semmilyen módon nem bezárthatók utána (TOAD-reboot szükségessége). Az látszik, hogy küszködnek a témával a fejlesztők is,mert az UPDATE-k nagyrészt szólnak Team Coding BugFix-ekről.

Egyrészt én ezt a Team Codingot így használhatatlannak tartom a (jelenlegi formájában), ráadásul semmi mással nem is együttműködésképes csak a Quest termékek szintjén

Másrészt a funkciónak ezt a formáját sem tartom létkérdésnek. Azt gondolom biztonságosan lehet még Subversion-nel vagy SVCO-val is megoldani a problémát/funkciót, ha már az Oracle van olyan "szíves" és 40+ év után sem képes ilyesmit érdemben támogatni RDBMS-ében. ;) Persze jobban szeretem a Microsoft Visual SourceSafe lockolásos módszertanát.

A "2 perc" némi magyarázatra szorul. Életemben sok év után újra egy újabb projekt keretében ismét kellett használnom a General Eletric(=GE) VPN-hálózatát. Sok VPN-t láttam már, dolgoztam bennük, mindközül toronymagasan a legsz*rabb a GE-é.

Régen olyan lassú volt, hogy távolról mailben való karakter-leütés megoldhatatlan problémát jelentett neki (timeout).

A mostani friss élményem, hogy 2013-ban is továbbra is csak az ActiveX-s Internet Explorer-t támogatják. De olyan szinten, hogy a látszatra böngészőfüggetlen Juniper NetWork Connect mélyében is ez a szutyok IE van. Na de hogyan? Az IE 10-es verziót ismeretlen böngészőként ismerik fel (nemdeterminisztikus módon egyébként, van akinek sikerült ezt elkerülnie, de nem tudja, hogyan, miért), ami azonnal "restricted"-használatot von maga után. És persze a Microsoft megteszi azt a "szívességet", hogy a Windows8-ba beégeti az IE10-et, onnan kivakarhatatlan módon. Magyarán mind a Microsoft, mind a GE "jelszava" olvasatomban az, hogy a Windows8-as felhasználók rohadjanak meg, miközben az IE a kötelező standard.

Képezheti-e csoda tárgyát, hogy a TOAD Team Codingja ebben a GE-VPN-ben nem képes felülmúlni saját magát? ;)

2013. június 5., szerda

Adattárház Fórum 2013 - Első (DW-)nap


v2.0 update (2013.06.11 10:00)

Adattárház Fórum egy fizetős konferencia, és mint ilyenen, hosszú évek után először volt alkalmam résztvenni a mai napon (még ha a holnapin már nem is leszek ott). Idén már kétnaposra szervezte a rendezvény házigazdája Arató Bence Bi Consultingja, aki gazdája a nagyszerű BI.hu szakmai blognak is.

Így "vezetői összefoglalóként" :) azt kell mondjam, hogy meglehetősen ambivalens érzéseim voltak a mai nap végére.

Egyfelöl bozasztóan sajnáltam, hogy reggel 9:00-kor a nap első, kvázi legfontosabb, plenáris, "keynote" előadásán, amikor a legjobban tud még koncentrálni a hallgatóság, a legnagyobb számban, akkor olyanokról kellett hallgatnom, hogy "column store" (ma már "hibryd store"-ra is lehet ráizgulni), meg "in memoy database" meg "hybrid data storage", amik már évekkel ezelött is a könyökömön jöttek ki, ráadásul mindezt egy órán keresztül. Sokat elárul egyébként szerintem, hogy senki nem kérdezett az előadótól az előadás után, ami azért szokatlan, szvsz.

Másfelöl olyan kincsvadászok legmerészebb álmát is felülmúló kincset érő előadások, mint Földi Tamás Pivotal One vagy dr.Bodon Ferenc Q/Kdb+  nap végi előadásokra alig maradt ember, meg nézőtéri figyelési energia. Arról már nem is beszélve, hogy én két-két órás terjedelemben is tudtam volna őket hallgatni, meg arról, hogy vagy hat kérdést kellett magamba fojtani - mások is kérdeztek volna persze, ha lett volna lehetőség. Miután párat azért feltettem nekik, némileg meglepetést is okozóan. ;)

És akkor picit részletesebben, részben az események hatása alatt, frissiben. ;) Sajnos nem várhat senki igazán érdemi infókat ettől a beszámolótól/blogposzttól. Az előadás-prezentációk nincsenek a kezemben, hangfelvétel sem áll rendelkezésemre. Gyér és lyukas memóriám az egyetlen forrásom a felelevenítéshez. No meg persze a saját véleményem, amire általában és mindig jobban emlékszem :DDDDDDDDDD

Érdekes módon állnak "inverz/komplementer" kapcsolatban egymással a fizetős és Open konferenciák, amelyek mindegyike Bence égisze alatt kerülnek megrendezésre.
- Azon túl is, hogy az egyiknél kell fizetni, a másiknál meg nem. :)
- Például az Open konferenciáknál 200+ emberből volt, hogy csak párat nem ismertem legalább látásból, a mai nap ez pont fordítva volt, mindössze pár embert ismertem csak.
- De említhetném azt is, hogy ma úgy éreztem a közönséget teljesen más hozza lázba, mint engem, míg az Open konferenciáknál ez mindig korrelálni szokott egymással :) Ez a Pivotal One kapcsán élesen szembeütközött, számomra.
- Vagy említhetném, hogy  a fizetősön sokkal több az angol nyelvű előadó, míg az Open konferenciákon ez eddig pont fordítva volt..

Itt jegyezném meg zárójelben (amely véleményemmel lehet, hogy egyedül vagyok a világban), hogy bár értem a motivációt az angol nyelvre, meg örömteli, hogy így is angolozik az emberfia, sok szempontból védhető is a dolog. Mégis azt mondom, hogy egyfelöl rengeteg angol nyelvű értékes anyag érhető el - sokszor ingyen is - a minket körülvevő globalizált világban, másfelöl a magyar piac lokális problémákkal szokott küzdeni, amire egy angol vagy amerikai szakértő sokszor ab ovo nem tudhat autentikusan reagálni. Azt is nehéz elképzelni, hogy magyarhonban dolgozó angolos külföldieket érdemes ilyen úton is kiszolgálni.

Különösen igaz mindez, ha sales/marketing vs. szakma áll szemben egymással. A nemzet- és vendor-független szakmát külföldi gazdagabb országbeli angolul előadó szakértők a tudásukat jobban tudhatják elhozni Magyarországra, míg sales esetében több lehet a lokális specifikum.
Órákat lehetne erről vitatkozni, de ennek a blogposztnak most nem célja ennek a kérdésnek a további boncolgatása.


Előadások:

Innovations in Data Warehousing Technology
Stephen Brobst, CTO of Teradata

Rokonszenves volt az előadó, aki szeret Magyarországra jönni igét hirdetni :) Bencének talán első komoly "zsákmánya", még évekkel ezelöttről, ami ma már egészen odáig ment, ahogy említettem is, hogy egyre több az angol nyelvű előadó a konferenciákon. Az előadó gyönyörűen, szépen, érthetően beszélt angolul élmény volt hallgatni, ráadásul át meg átszőtte mondandóját humorral, ami kifejezetten jót tett az egésznek.

A már említett "könyökön jön ki" meg "ezen már rég túlvagyunk" effektuson felül (klasszikus vicc az egyszer Pista bácsival, aki a kuplerájban kéri a sarokból a vöröskét, mire a madam megjegyzi, hogy "Pista bácsi; maga már rég túl van ezen". Mire Pista bácsi. "Igen?! Akkor mennyivel tartozom?"...
Szóval ezen felül ami még kifogásom, hogy mélyen hallgatott arról, hogy a Teradata cég az egyik leghorrorisztikusabb árszabást alkalmazó vendor, nem véletlen, hogy nem éppen elterjedt a Teradata-platform Magyarországon.
Én elvárom egy előadótól, hogy ne csak szépeket mondjon a cég képviseletében (még ha az sok technikai részletet is érint a szakmából, oktató célzattal), hanem az árnyoldalt is mutassa meg, jelen esetben, hogy mit fog tartalmazni a számla. Az egész Teradata (az én tapasztalatom szerint) inkorrekten és titkokkal övezetten kezeli a "piszkos" anyagiakat.
Az én szintemen egész egyszerűen úgy néz ki a perspektíva, hogy hiába van egy csilivili csoda technikai megoldás, ha minden várható profitomat előre felemészti az, hogy előre kell kifizetnem ezeket az eszközöket.

Mémek:
- Érdekes volt látni, hogy az IMDB itteni kontextusban: "in memory database management", és nem filmes adatbázis :)
- "Want more data, want it faster" -> Több adat gyorsabban, ahogy egy telhetetlen habzsoló világban ez már csak természetes, teszem hozzá ;)
- "Data temperature" -> adathőmérséklet, aszerint, hogy mennyire azonnal kell elérni adatot, CPU-RAM-SDD-HDD kontextusban. Természetes folyománya a Mutitemperature Data Management.
- "R" mindenütt. Hihetetlen a programozási nyelv és runtime environment népszerűsége. Mindenki, aki él és mozog támogatja. Még a nap végi Q nyelv is, amitől nem számítana ilyesmire az ember, legmerészebb álmában sem. A végén előbb-utóbb a Prolog nyelv is fogja támogatni. :)


Adattárházak Magyarországon
Arató Bence ügyvezető, BI Consulting

- 55 ember részvételével zajlot a DW-Trek kutatás, "adattárházak Magyarországon" jeligével. Figyelembevéve, hogy egy-egy vélemény több vélemény aggregálása is lehet, hogy nem is olyan kicsi ez a szám, pláne magyar viszonylatban.
-Pentaho érzékelhetően előrébb tart ismertségben, mint a Talend, ETL-eszközök témában.
- Jellemzően a Kimball-féle önálló vagy összehangolt adatpiacos DW-architektúra a támogatottabb itthon Magyarországon, mint az Immon-.féle 1-2 rétegű normalizált adatpiac. De megjelent már a Data Vault módszertan alkalmazása is.
- Kedvenc DW-feature-k sorrendben: preaggregáció, particionálás, molap, compression, in memory, column store. Bence szerint az utóbbi kettő azért marad csak le, mert a két legnépszerűbb vendor (Oracle és Microsoft) elég későn kezdte el támogatni őket.
- Kedvenc adatforrásbiztosítás: file-transzfer, közvetlen dblink, middleware, replikáció. Itteni sorrend alakulására az ár/költség is jelentősen hathat.
- Van már 100+ TB adattárház is, csak a CIB bankké 30 TB.
- Jó hír, hogy jelentős fejlesztéseket terveznek a cégek. Elsősorban DQM fókusszal (=Data Quality Management), utolsósorban felhasználószám növelési vagy addiginál még sokkal sűrűbb adattöltés fókuszokkal.
- 2011-es felméréshez képest nem volt jellemző változás, talán 5 év múlva érdemes ezt először firtatni?
- Ami változik: (A) a méret nő folyamatosan, (B) szemléletben történt változás: DW-t és ETL-t nem feltétlen kell egy vendortól vásárolni..


The Evolving Data Warehouse
Dirk DeRoos, Big Data Specialist, IBM

- Nagyszerű angol nyelvű előadás volt.Az előző angol előadáshoz képest ráadásul sokkal jobban felépített, remek diákat tartalmazó előadás volt, ahol a diák egymással sokkal szervesebb kapcsolati láncot alkottak.
- Sokak szerint nagyon pörgősen beszélt a srác, de szerintem így is nagyon érthető volt, pedig én a süketebb emberek közül való vagyok, az angolomat már nem is vesézve külön.
- Fiatal kora ellenére már két könyvet is publikált:
Harness the Power of Big Data (2012, McGraw-Hill Press)
Understanding Big Data (2011, McGraw-Hill Press)
- Én az első slide-jánál szívembe zártam az előadót. A folyamatos vesszőparipámat rakta rá, három dimenziós koordinátarendszerben: "budagetary constraints", "technical change", "regulatory press" határozódik meg a gondolkodásunk a fejlesztéseket illetően.
-Structured+repeatable-linear vs. unstructured+exploratory+iterative
-Analógia: alaszkai aranyásó kontra arany-kitermelés.
- SPARQL
- "Szent grál":  Natíve SQL -> NoSQL-re. :) Ez már leírva is szép, még laikusnak is talán.
- Data Governence, amire elhangzott egy nemkicsit meglepő magyar fordítás is: "adatvagyon-biztosítás"
(A) Policy, (B) Value creation, (C) Risk management, (D) Architecture, (E) DQM, (F) Metadata / Business glossary, (G) Lifecycle, (H) Audit / reporting



Adattárház menedzsment és metaadat kezelés
Gollnhofer Gábor, Jet-Sol Kft.

- Gábor régi kedves ismerős, az ebédet is társaságában volt lehetőségem elfogyasztani. Nagyon szeretem az előadásait, akár ismétlés jelleggel is. Például mert igyekszik mindig feltenni azokat a kérdéseket, amik fontosak (nekem és szerintem is).
- Build or Buy klasszikus kérdése DW-re.
- Csak egy adattárházunk legyen?
* Ha igen, akkor mi legyen a többivel?
* Ha nem, miért nem?
- DW akkor teremt értéket, ha (A) folyamatosan épül, (B) megbízható minőségű, (C) adhoc igényeket is kielégít, (D) extra nem tervezett de kiaknázódó értéket is rejt magában.
- Metadata van technikai és üzleti


Metavezérelt banki adattárház bevezetése és működtetése
Rekenei Zoltán, CIB Bank Zrt.

- Rokonszenves előadó, őszintén/hitelesen, ráadásul érdekesen beszélt. Tudtam volna továbbhallgatni őt is.
- Sajnos mondandójának középpontjával maximálisan nem tudtam azonosulni. Ha nekem lenne cégem, a legutolsó utáni gondolatom lenne aranyárban mért amerika adatmodell vásárlása, valamint SAS technológia stack (DW, ETL Studió és társai) vásárlása. Képtelen vagyok elhinni, hogy ez rentábilis, jó performanciájú,  rugalmas és kellően konszolidált megoldás legyen. De legalább az informatikának még mindig van kenyérkereseti forrása. ;)
- Nem hiszek a diagram ("krumpli") vezérelt egymásba ágyazott vizuális drag'n'drop huzigálásban sem. Sosem hittem. Az a vicc jut rá mindig eszembe, amikor egy pucér mexikói férfi az első emeletről a kaktuszosba ugrott. Kérdezték tőle miért tette: "elsőre jó ötletnek tűnt". ;)
- Nem a CIB-banknak címzem, csak itt jut eszembe, ami minap is felmerült már itt a blogon: számomra riasztó az az ellentét,hogy egyfelöl két kézzel, számolatlanul képesek egyes vállalatok pénzt kidobálni technológiákra/alaptermékekre, másfelöl a sokszor fillérekért dolgozó és/vagy kizsigerelt magyar vállalkozók teljesítéseit képesek nem kifizetni.
- Azzal a dologgal viszont nagyon egyetértek, hogy metaadat(-vezéreltség) az nagyon fontos (ezt "irigylem" is a SAS-tól ;), sőt nekem régről vesszőparipám az egész topik. Mondjuk én jobban el tudom ezt képzelni a Halassy-féle eredeti DBA analógiájára (nem a lebutított Oracle-DBA cuccról beszélek), semmint a disztributív "adatgazdák" vonatkozásában. Én amit az utóbbiból láttam szervezeti működést, az vagy nem működött, vagy hajmeresztően borzasztó volt.


Metavizualizáció – a metaadatok kiaknázásának kulcsa
Kósa Dávid, Metvizins Kft.

- Rokonszenves előadó, fontos problémát feszgetett, de nekem túl távolinak tűnt a mondandója, számomra sem kézzelfogható nem volt, sem témát illető szkepszist legyőző. De ez lehet ám az én hibám is. ;)
- Én már ott meglőve érzem magam, ha valaki vizualizálni akar egy ilyen durván nagy cuccot.


Data Warehouse ETL offloading with MapR
Zeljko Dodlek, MapR

- Rokonszenves  angol nyelvű előadás.
- Ha valaki, akkor én mellette vagyok a MapReduce-nak és Hadoopnak, de, hogy ETL-re mennyire jó ötlet, az minimum kérdéses. Maradjunk annyiban, hogy meglátjuk mit hoz a jövő!
- Az mindenesetre mellette szóló pozitívum, hogy nem pilinckázik, mint egy aranyárú Informatica GUI (amit én sose tudtam becsülni igazán nem értékarányos árszabása és felhasználóbarátságtalansága okán), hanem mert egyenesen paradigmaszerű gondolkodásváltást tűz ki célul :)


Pivotal One – Az agilis nagyvállalati platform
Földi Tamás, Starschema

- Távolálljon tőlem, hogy hazabeszéljek,de páratlanul nagyszerű volt hallgatni Földi Tamás lényegretörő és Greenplum-viszonteladóként is kendőzetlenül őszinte előadását.
- Pivotal cég Pivotal One termékéről van szó, a Hawk - Hadoop-os SQL-t leszámítva - már most kész, bevezethető vállalatoknak. Magyarországon most készül az első referencia-megvalósítás.
- A GE(=General Electric), iparágban szokatlan módon,10%-ban, 105 millió dollár értékben azonnal bevásárolta magát a projektbe.
- Van a klasszikus Waterfall (=vízesés) fejlesztési modell, ahol a cél kőbevésett. És van az Agile (=agilis) fejlesztés, ahol a cél is változhat menetközben, a revizíók során lehet felmérni, hogy a változás hol tart, milyen hatása van a célra, úgy általában az egészre. Ez a változás a "pivotal" az agilis fejlesztési módszertanban. Világéletemben vesszőparipám volt a változás-management fontossága, illetve mikéntje és hogyanja. Öröm volt nekem ezért ezt a levezetést hallanom.
- Célkitűzés: a már létező IaaS (=Infrastructure as a Service) után Paas(=Platform as a Service) megteremtése. Olcsón - még akár home-célra is? - értékesített wing-to-wing skálázott sandbox, amibe adott esetben Data Scientist embernap is bele tud majd tartozni.Nézzük meg X nap alatt mire jut a Pivotalos data scientist a datasetünkkel, hogyan tudja "megköpködni", ha valami rossz benne.
- Pivotal szereti támogatni a halados fejlesztői eszközöket: Ruby on Rails, GRails, Scala, etc.
- Tamás szerint az Oracle parallel query ma már szépen monitorozható szintén. Az én érzésem az, hogy a MapReduce-szal, eddig sosem látott korrektségű progressbar húzható majd lekérdezéseknél (de persze tévedhetek ennek megítélésében). ;)
- MPP-knél 40 gép felett nem lineáris a skálázás, hanem degresszív. Hadoopnál ilyen gond elvben nincs.
- Hadoop gyengeségei: (A) file-on belüli változás nehézsége, (B) adhoc lekérdezés: nem erre van kitalálva (C) elemzői interface-ek problématikusságai,  (D) adatbiztonság (autentikáció,autorizáció) hiánya.
- Döbbenetes adat: 60% Spring-használat a teljes Java-container technológiából.
- Egy másik 60%: Apache Tomcat fejlesztők 60%-a Pivotal-alkalmazott lett. Bennem ez felvet olyan kérdéseket egyébként, hogy nem lesz olyan, mint a (Sun) OpenOffice-nál, amikor az Oracle megvette: az eredeti csapat kilépett és folytatta a régi vonalat.
 - Poén: fabrik az kulcsszó, buzzword, érdemes vele barátkozni.
- Poén: Amerikában mindenki ismer data scientistet, de senki nem látott még egyet sem (olyan ritka állatfaj néha)
- Poén: Social Media/Twitter strukturálatlan állományai kicsit túl vannak hypeolva Tamás szerint. :) Azért lássuk be robbanásszerűen szaporodnak a srtukturálatlan adatok is.

Én kiegészítései a Pivotal (One)-hoz.
- Én nem rajongok a Pivotal One tulajdonos EMC-ért, pedig szellemes nevük van (Einstein képletéből származik).Világéletemben szabályszerűen rühelltem a SAN-okat, csak a szívás volt velük, viszont cserébe értékükön felül jóval túlárazva; rohadt drágák voltak mindig is (horrosztukus extraporofitos árképzéssel). Az üzleti szféra rugalmatlanságára jellemző, hogy az EMC-nek a bőre alatt is pénz van. Vásároltak is belőle vagy tizeniksz technológiát és/vagy céget a nagy előadáscímbeli vízió érdekében.
- Viszont tárgyilagosan kell ítélni. Úgy tűnik nagyon erősen komolyan gondolják a víziójukat (nem viccelnek) és körültekintően,  redundanciát kerülve (nem úgy mint az Oracle akvizicióknál volt sokszor látható), vásárolták egymás mellé a komponenseket, meg dolgoztatnak hozzá 1400 fejlesztőt. Az Oracle analógia Tamás elmondása alapján ott is érdekes, mert konkurens lesz várhatóan a témában, eddigi lépéseiből leszűrhetően.
- A Pivotal spin-off jellege érdekes: a Greenplum önmagában is fejlődőképes, de így egy nagy egész része lesz. Azért ez pestiesen szólva nem semmi.
- Vita tárgya, hogy Hadoop/MapReduce avagy a Greenplum MPP-je(=Massive Parallel Processing) adja-e majd a Hawq ("elírt" sólyóm) erényét.Tamás szerint csak termékátnevezésről van szó, mert Hadoop hívószó nélkül már nincs is élet :)
- Bottom up agilitás
- Cél: egyszerre rendkívüli performancia, magasfokú kompatibilitás, rendlkezésreállás, operatiív interakítv valamint batch SQL.

És akkor ez egy 30 perces előadás nyomán képződött, napvégére leharcolt szellemi állapotom párlata. Mi lett volna, ha lett volna rendesen idő a témára (előadás + kérdések) ???? ;)


Q/Kdb+ alapú adattárház fejlesztés a Morgan Stanley-nél
Dr. Bodon Ferenc, Morgan Stanley

- Az előadót eddig csak referenciaértékű, linkelt, szenzációsan nagyszerű "Adatbányászati algoritmusok" könyve révén ismertem.Alig vártam ezt az előadását egész nap, hogy végre erről az oldaláról is megismerhessem. Nem is csalódtam. Nagyszerű, élvezetes, egyúttal precíz előadást tartott.
- A Q nyelvet nagyon könnyű megszeretni az ő bevezetése alapján, noha a "http szervert indít" engem elsőre egy kicsit megijesztett, bevallom.
- A Q nyelv ráerősít arra, amit Földi Tamás mindig is mondott,hogy a funkcionális programnyelvekben komoly fantázia van.
- Feri idézett egy érdekeset is: azt a (programozási) nyelvet, ami nem szabja át a gondolkodásodat, lehet, hogy nem is volt érdemes létrehozni. :)
- Napi 850 milliárd dolláros kötvénypiac mögötti adattárházról beszélünk. Álljunk meg kicsit és izlelgessük a számot. ;)
- Nem szabad hibázni. Egyik, éves szinten 100 millió dolláros profitú kereskedőcég egy picit hibázott 1-2 éve, vezetőhír lett belőle: 400 millió dollárt bukott, 15 év építkezése ment a levesbe.
- Cserébe sokszor másodpercek törtrésze alatt kell dönteni, iszonyatos méretű - idősoros-összefüggésű - adathalmazok alapján.

Update

Ma munkábajövet gondolkoztam el azon, hogy milyen célja/funkciója van/lehet egy ilyen adattárházfórumnak (ahol technológia köré gyűlnek megrendelők és beszállítók).

Az én olvasatomban/értelmezésemben:

(1) Legyen egy technológiai ujdonságok vonulat: ennek tökéletesen megfelelt ezúttal is, a MapR, PivotalOne, Q/Kdb+. Lássuk be nem mindegy Google-n keresztül találkozni egy újdonsággal. A www.bi.hu-n, már jobb ;) De az igazi, ha valaki átéli és megosztja a tapasztalatait. Ez mind előadókat, mind hallgatókat vonzó vonulat.

(2) Legyenek "best practice"-k: rendszervázolással, költséghatékonyság-elemzéssel, hátrányok nem elhallgatásával..Ennek nem tudom a formáját, az viszont tény, hogy én egyszerre éreztem/érzem a dolog fontosságát és jelentős hiányát is.
Az egyedi esettanulmányok sokszor gyengék, megvitatni sincs rá keret.
Másfelöl akadémiai szférából is nagyon nehéz kompatibilis hiteles embert elképzelni idevágóan, és zavaró hátrány, hogy a szakmai egészre kevés embernek van megfelelő rálátása, az ilyet nehéz is kiemelni a tömegből.
Az látszik azért, hogy a best practice-ért meg kell küzdeni, és nem igazán várható "felülről".

(3) Elősegíteni a kommunikációt megrendelők és beszálíltók között. Ahogy én tapasztalatom, elképesztő tévképzetek, arányok vannak folyamatosan a fejekben. Ez is inkább hiányérzetként manifesztálódik bennem, semmint konkrét javaslatként.

Egyben vagyok csak biztos, hogy a leghangsúlyosabb Brobst-os előadás felelt meg ennek a szempontrendszernek a legkevésbé.