Barabási Albert-László friss interjúja az index.hu-n

.

Az NSA primitíven használta a begyűjtött adatokat

Akik ismernek tudják rólam, hogy imádom a témát, épp ezért esett nekem nagyon rosszul a tárgybeli interjú, a rendkívül rossz üzeneteivel. Pedig jók voltak a felmerült a témák, a kérdező is készült, de az interjúalany mélyen alulteljesített számomra. Nézzük sorban a szakmai vonatkozású témákat!

NSA
- Számomra itt keveredik a szakma és etika, az interjúalany szövegében. Világos, hogy röviden, tömören, velősen kell fogalmazni, meg túl hosszú szöveget nem visel el az interjú, de itt a mondandó értelmének minden csíráját sikerült kigyomlálni.
- Nem tudjuk meg miért lenne rossz az NSA szakmailag, mármint a kijelentésen felül.
- Az meg, hogy nincs az NSA-felé szakember-mozgás, az meg inkább etikai gyökerű lehet, pláne, ha felkészült diákok keresnek szakmai kiteljesedéshez potenciálisan jó helyet.
- Értem azt is, hogy abbahagyták a mozgásos kutatást, de ez is megmaradt a kijelentés szintjén.
- A "pofozkodás"-t sem érzem jól kifejtettnek. Én szívesebben olvastam volna valamiféle protokollról, azon vonatkozásban, hogy hogyan lehet minimalizálni a kockázatokat, maximalizálni a hatékonyságot. Az adok-kapok régóta létező triviális probléma, ehhez nem kell tudós embert interjúvolni.

Network Medicine
- Itt én örültem volna Csermely Péter említésének, ha már elhangzik az "első komoly lépés", aki nagyon régóta kutatja a témát, még magyarul is publikált könyvet idevágóan (2005-ben). Én magam is tőle szereztem először infót a témáról. Tudván tudom azt is, hogy Barabási-Albert ismeri is Csermely Péter munkásságát.
- Maga a bekezdés a jobbak közül való az interjúban, bár bőven van azért hiányérzetem is.

Hálózat-kontroll kutatás
- Ez egy új fogalom volt számomra most, de én csak egy átcimkézést látok benne, hiszen az interjúalany sosem megnevezett telcós nagy hívási datasetes kutatása óta érdekli a téma.
- Ezt a "matematikailag intenzív" dolgot nem tudtam hová rakni. El tudok képzelni, nehéz, mély, komplex, több területet árfogó, intenzíven kutatott, stb matematikát, de intenzívet így önmagában nem.
- Szakma és etika megint furán keveredett.

Networking
- Ez nagyon jó topik. :) Csak ezért az egyért vágtam bele ebbe a blogposztba.
- (1) Jó munkahelyet/csapatot és (2) hosszútávra találni körülbelül hasonlóan nehéz, mint párt találni. Talán még nehezebb is, ha nem egyenesen lehetetlen. Életkoromnál meg egyebeknél fogva 30-hoz közelít a munkahelyek száma, ahol volt alkalmam dolgozni, például a CIB kivételével az összes nagy bankban is megfordultam, volt, ahol többször is. Rám igazán nem lehet mondani tehát, hogy nem tapasztaltam és remélem azt sem, hogy elfogult vagyok. Minden munkahelyen volt ami jó volt, és mindenhol volt valami komolyabb probléma (amikkel kompromisszum árán persze együtt lehetett valahogy élni). Hogy mit tekinte(né)k - talán elvileg is lehetetlen - jó munkahelynek? Ahol a felek (1) beletesznek a közösbe, (2) jól (3) hozzáadott értéket képeznek a szereplőknél (nem pedig amortizálják egymást). Ez nagyjából igaz talán a párkapcsolatokra is, amikor a felek tesznek azért, hogy többek legyenek együtt.
- És ha már eddig eljutottunk az analógiában, meg kapcsolódni akarunk az interjúhoz is, akkor bizony adekvát módon merül fel a team-építés adatbányászati támogatása, a már korábban e blogon is sokszor tárgyalt társkeresés adatbányászati támogatásához hasonlatosan.
- Azért szakmailag a társkeresős probléma nagyságrendekkel könnyebb, hiszen rengeteg ember keres egyetlen társat, és persze egyenrangúan. Míg a csapatépítés mindig sokkal szűkebb kört érint a legtrendibb szakmákban is, illetve a kandidálónak sokkal kisebbek az objektív mérlegelési/aktivitási lehetőségei.

Hat lépés
- Számomra ez egy kifejtés nélküli vagdalkozás volt megint, Karinthy érdemének negligálásával, ami külön keserű mellékízt az egésznek, főleg egy plebsnek szóló interjúban. Mellesleg én inkább azon szoktam kiakadni, ha akadémiai/egyetemi előadáson kezdi valaki a Königsbergi hidakkal.

Adatbányászat hollywoodi filmeken.

.
Csak egy rövid pár soros poszt erejéig jöttem ide.

Már eddig is voltak ilyen témába vágó filmek, speciel mindkettő igen jól sikerült.
Szakmai szempontból az első izgalmasabb és kidolgozottabb volt, pláne, hogy igaz sztorin alapult.
Mindkettő (számomra) azt feszegette, meddig tart az adatelemzés, honnan kezdődik az ember intuicója, döntéshozatal esetén.
De ezért a két filmért nem kezdtem volna bele a blogposztba. :)
Pénzcsináló / Moneyball
Újoncok napja / Draft Day

Amiért jöttem az ez a (4.évadánál járó) sorozat.
A felszínen ez egy klasszikus akciókrimi (talán a jobbak közül), egy rakat geggel egyébként.
Nyilván akárhány évadot meg lehet tölteni, annyira jók a sorozat keretei.
Célszemély / Person of Interest

De ha valaki elolvassa a szinopszist, akkor rögtön megérti miért a felhajtás. ;)

A titokzatos milliárdos Mr. Finch (Michael Emerson) kifejlesztett a kormány számára egy különleges számítógépet, amelynek a segítségével meg lehet akadályozni különféle bűncselekményeket, terrorfenyegetéseket. Később munkát ajánl a halottnak hitt, speciális katonai alakulatoknál szolgáló, korábbi kormányügynöknek, John Reese-nek (Jim Caviezel), hogy dolgozzanak össze, tisztítsák meg New York utcáit a bűnözőktől és védjék meg az ártatlanokat. Azonban a találmány egyelőre nem képes meghatározni, hogy kivel fog jó vagy rossz dolog történni, így a célszemélyről nem lehet előre tudni, hogy épp áldozat vagy maga az elkövető.

1.ÉRDEKESSÉG: Van-e értelme olyan előrejelzésnek (lehet-e ilyen egyáltalán), hogy nem tudjuk az "előjelet", jön-e lóvé, vagy viszik a lóvét? Áldozat lesz valaki, avagy gyilkos? Csak a személy neve esik ki az outputon, semmi más konkrétabb.
- Hát bizony ez egy nagyon valószerű probléma, bizony, hogy nagyon is lehet. Én ezt "change point detection" problémacsaládba sorolom. Amikor csak annyi jelződik előre az "ügyfél"-ról, hogy valami más/szokatlan rendkívüli fog vele történni: valami "törés" van kódolva a magyarázó adatok tengerében.
- Egyébként azt gondolom, hogy a film nagyon igyekszik elkerülni a "sci-fi"-t, meg a "túlgondolás"-t, azaz a sorozatkészítők (szvsz) konzultáltak szakértőkkel, mit "lehet" és mit nem a forgatókönyvben.
- Jonathan Nolan forgatókönyvíróról azt lehetett egyébként olvasni mostanság, hogy filmfeldolgozásban talán legnagyobb kihívást jelentő Alapítvány-feldolgozást forgatja a fejében.

2.ÉRDEKESSÉG: Logisztikus legyen-e a regresszió avagy nem?
- A film "természetesen" nem a logisztikus regressziót választja (vagyis, hogy valaki legyen-e vagy ne legyen főszereplő az adott sorozatrészben). Hanem numerikus célváltozójával priorizál.

3.ÉRDEKESSÉG: Mennyire életszerű a konkrétumaiban a feladatfelvetés, most 2015-ben?
- Azt gondolom ennek még nincs itt az ideje.
- Az nem kérdés, hogy van rengeteg adat (digitális lábnyom).
- Azt is el tudom képzelni, hogy magyarázó erőt tekintve elég erős is tudhat lenni ez az adatrengeteg. A sorozat persze lazán túl lép azon, hogy adott esetben vakriasztás is lehet, mint, ahogy valakire meg nem történik semmiféle alert (nyilván az ilyen esetek a sorozatrészek között történnek :)
- Amit viszont nem tudok elképzelni, hogy egy ilyen feladatot automatikus és iteratív (személyre szabott) feature-engineering nélkül is lehetne érdemben kezelni. Ilyen pedig még nincs a világon (az én legjobb tudomásom szerint). Azt nem mondom, hogy nem tanultam, mivel maga az "adatbányászat", mint fogalom sem létezett (itthon), amikor én jártam egyetemre. :)

4.ÉRDEKESSÉG: Mennyire életszerű a konkrétumaiban a feladatfelvetés, a jövőben?
- Én bizony egy kicsit szkeptikus vagyok, abban mindenképpen, hogy én megélem-e.
- Viszont semmiképpen nem tartom lehetetlennek a feladatot.
- Azt is símán el tudom képzelni, hogy előbb-utóbb (feltéve, hogy nem történik semmiféle kataklizma) valamilyen formája fel fog bukanni valamelyik adatbányász versenyen, amikről köztudomású, hogy szeretik a domain-független problémákat (csak számokkal melózás, számok mögötti előzetes humán tudás nélkül).

PS: Természetesen az egész sztorinak nagyon komoly etikai aspektusa van. Szabad-e, akarja-e az ember, hogy így védjék. Vagy éppenséggel megfordítva lehet-e ártásra használni az egészet (nyilván lehet adatok és algoritmusok/tudás birtokában) De ez most offtopik ebben a pársoros blogposztban.

Legjobb "ODBC-s" generikus SQL Tool (Windows-ra)

.
Én erre az eszközre esküszöm: SqlDbx

Értékelésem:
+ Van free personal edition belőle (igaz erősen butított)
+ Egyetlen pici 2+ MB-os exe (C-ben írva), azaz maximálisan portable alapból.
+ Létezik x86 és x64-re egyaránt
+ Leggyorsabb, legnatívabb adatelérés és adatmegjelenítés
+ Letisztult puritán felület, "mindent a gyorsaságért" jegyében.
+ A legspécibb Cassandrát, Hive-ot, egzotikumokat támogatja
+ Amire nincs ODBC, az kávzi nem is létezik. :)
+ A drága pl.: DataDirectes eszközöket is jól támogatja.
+ Scriptelhető, parancssorból vezérelhető
+ Excel és egyéb exportok
+ Visual Diff
+ SQL-formatter
+ ResultGrid kereshető
+ Intelligens Editor
+ Tökéletes script-generálások
+ A másik szimpi tool (Advanced Query Tool) azért vesztett evvel az SqlDbx-szel szemben, mert (sokkal) lassabb volt.

- A fizetős licence: 300 USD (commercial kategóriában nem kibírhatatlan)
- Egy dolgot nem tud ODBC2JDBC gateway-t

Greenplum-client for Windows

.
Falak omlanak le, mítoszok dőlnek meg, paradigmaváltás szemtanui lehetünk. :)

Régen "kikezdhetetlen" igazság volt, hogy valós enterprise környezetbe Oracle kell, aminek meg is lett az eredménye, hogy az RDBMS-tortából az Oracle mindig is valami hihetetlen nagy szeletet volt képes kihasítani.

2001-ben:
Oracle: 46%
IBM: 23.6%
Microsoft:: 6.7%

2008-ban, Gartner mérés szerint (több is lehetett, ezért nem 100% az összeg):
Oracle Database: 70%
Microsoft SQL Server: 68%
MySQL (Oracle Corporation): 50%
IBM DB2: 39%
IBM Informix: 18%
SAP Sybase Adaptive Server Enterprise: 15%
SAP Sybase IQ: 14%
Teradata: 11%

2011-ben, Gartner mérés szerint 

2014-ben:
"13% run Hadoop, either in pilot (8%) or production (5%). An additional 21% are considering"

Ami korábban elképzelhetetlen volt (számomra legalábbis): egy amerikai multi cég komplett iparága most akarja áttenni háromféle(!), 10+(!) ERP-jének analitikus platformját (100%-ban vegytiszta Oracle-ről) egyrészt olcsó tömegtárolású Apache Hadoop-ra, másrészt kritikus tárolású adatait Greenplumra. Egy Hawq-ra még nem "értek meg", de ez is csak idő kérdése. :). Mindezt a költségoptimalizálás jegyében..

És, ha mindez még nem lenne elég, akkor a következő még nagyobb "mélyütés" a témában:
- Ugyanez a cég úgy tervezi kidobni meglévő Informatica folyamatait, hogy még csak nem is egy Talendet helyez fókuszba (ami mára enterprise verzióban nagyon drága lett, ha jól tudom kb. negyede egy Informaticának, ami azért nem semmi)
- Hanem egyenesen vissza akar térni a régi SQL-es vagy a modern trendi open source SQOOP-ra. Ezt a nagy-nagy örömhírt (számomra visszaigazolást) napok óta sikertelenül próbálom megemészteni. Én világéletemben nagy ellensége voltam ugyanis az indokolatlanul brutáldárga ETL-GUI-knak, azóta, hogy Oracle Warehouse Builder 2.1-gyel beléptem ebbe a világba (is). (Azon az alapon, hogy én szakmai alapon vitatom, hogy elvileg lehetséges lenne jó eszközt fejleszteni, nemhogy gyakorlatilag).

Nagyon drukkolok, hogy az ilyen dolgokból trend legyen. ;)

Na de vissza a blogposzt címében felvetett problémához. Szokásos "játék", új rdbms-nél, mi a legjobb eszköz című versenyben.:) A kérdés azért merül fel, mert a Greenplum egy PostgreSQL-származék, elvben kell szeressen egy free open source PgAdmin-t, de a helyzet az, hogy eleve warninggal indul csak el, de az igazán nagy baj vele, hogy fagyogat, miközben éterbe küldi a benne lévő SQL-eket (Greenplum v4.2-nél).

És sikerült rátalálni egy nagyon jó eszközre, egy élmény vele dolgozni.

Aginity Workbench
http://www.aginity.com/workbench/greenplum/
http://www.aginity.com/documentation/wb/gp/

Értékelésem:
+ Free Community Edition(licence file-lal aktiválandó)

+ x86 + x64 platformokra is létezik.
+ Greenplum-specifikus

+ DBA+SQL-fejlesztés támogatása
+ Natív adatelérés
+ Nem JAVA-s a GUI, hanem ez is natív C/C++-os(?), hálistennek.
+ Nagyon szép, gyors és egészséges használni.
+ Baromi gyors.

- gmail-es cím nem elég a hozzájutáshoz, kell egy valódi munkahelyi.

- nem minden script-generálás megy jól (de javíthatók).

Ami toolokat én találtam még:
- Aqua Data Studio (fizetős)
- EMS (fizetős)
- Navicat (fizetős)
- RazorSQL (fizetős, jdbc-s)

 -SqlWorkbenchJ (free, jdbc-s, egyszerűbb SQL-re jó, stabilitási "kihívásai" vannak neki)

Oracle Reports RDF-file migrálása

.
Az alábbiakban egy gyors, rövid, habkönnyű morgolódás fog következni, aminek tárgya vélhetőleg és szerencsére kevés BI-ban mozgó embert érint, viszont annál bosszantóbb.

Létezik az Oracle Corporation termék-portfóliójában egy cucc: Forms and Reports.

Jellemzők:
- tejútrendszer-méretű ipari hulladék maga a szoftver, éremesélyesként indul a "világ legrosszabb szoftvere" versenyben. Úgy volt elképesztően drága, hogy architektúrálisan, használhatóságilag teljesen félretervezett volt (szvsz).
- Oracle saját fejlesztése volt, nem akvirálta (nem néztem utána, csak így emlékszem), az OWB-hez hasonlóan egyébként, az is nevezetes saját fejlesztés volt, ott is nagyon komoly visszás történésekkel.
- Ehibázott mivolta ellenére rengetegen használták, és ami külön érdekes Magyarországon is.
- Nagyon nem mindegy az RDF verziószáma (nem átjárhatók).

Feladat: 
Oracle Riports-os RDF file-t migráljunk valamely "korszerű" - jah pardon rossz szót használtam, mondjuk úgy inkább, hogy aktuálisan fejlesztett ;) - BI-eszközbe.

RDF file jellemzői
- Bináris hulladék, de érdekes módon a közepén van olvasható, ezáltal kimásolható SQL
- Sokféle (pl.: szerializált) RDF file van (Google-ben önmagában nem érdemes keresni tehát). A mi esetünkben egy spéci Oracle Riports Definition File-ról beszélünk.
- Van benne SQL, kliens/szerver-oldali PlSql, prezentációs réteg infói.

RDF-migrálás alternatívái:

(1) További tool igénybevétele nélkül, egyszerűbb SQL-es  (értsd egyébként helyes elv alapján perdöntően szerver-oldali SQL-re támaszkodó üzleti logikájú) riportok RDF alapján is migrálható, amennyiben van screenshot, meg egy Excel-kimenet, reprezentatív adatmintával.

(2) Ha valaki precízen akar hozzáférni az RDF-hez, akkor innentől kettéágazik az út.Oracle-felé akarja venni a migrációs utat, avagy más frissebb, jobb, használhatóbb alternatívák felé (pl.: Tableau)

(2a) Az Oracle út minden finomkodás nélkül bátran minősíthető botrányosnak.

Egyfelöl az Oracle BI Enterprise (talán a Siebeltől vették meg) már megvásárlásakor, egy ultradrága, barátságtalan, nehezen adminsiztrálható, gigantikus overhead-es, elavult eszköz volt. Ezt választani korszerű BI-platformnak monumentális pénzkidobás, fékezett habzású élménnyel. (szvsz).

Másfelöl botrányos azért, mert az elterjedt Oracle Reports RDF támogatását gyalázatosan oldották meg. Noha egy egyszerű feladatról lenne szó, egy bitre ismert internal file-t kiexportálni valami olvasható formátumra.

- Oracle BI Publisher gyári prezi alapján például 11g-be meg sem írták a konverziót.

- Rengeteg terméknév/verzió van közkézen, ember legyen a talpán, aki követni tudja miből, mikor mi lett a nagy akviziciók utáni termékintegrálás után.Melyiknek milyen install-követelményei / előfeltételei, meg lehetőségei vannak. Noha - ismétlem - csak egy egyszerű RDF-file infóihoz szeretnénk hozzáférni.

- Oracle BI Publisher tehát kiesik, 11g alapból, 10g azért, mert nem installható korszerű Win7/Win8 alá korrekten.

 - Oracle BI Enterprise 11g-vel azért nem érdemes kísérletezni, mert alapból 3-4 GB az installkit, de kell neki Fusion Middleware, meg Bealogic Webserver maga alá. E nélkül el sem indul az install.

- Vannak olyan verziók, amik megkövetelik a szerver-oprendszert

- Ami megy mondjuk Win XP alatt, de hivatalosan nem támogatta még a Win7-et például, az jellemzően nem is megy Win7 alatt: már az install sem.

Összefoglalva, lehet küzdeni, meg jó sok munkaórát beleölni az RDF-migrálásba, csak kérdés érdemes-e. Az én véleményem az, hogy a legegyszerűbb és legolcsóbb megoldás, úgy tekinteni az RDF-re, mint ha nem Oracle-eredetű lenne, lásd (2b)-t, XML-t kell belőle csinálni és aztán intenzíven elfelejteni az egész Oracle BI-vonalat.

(2b) Amennyiben nem Oracle a migrálási célplatform, akkor a legegyszerübb megoldás XP-s virtuális gép, 10-es 11-es Oracle Dev Suite install (complete-t, amiben benne van a Forms and Reports), ezek még baráti méretű 1 GB-os install anyagok, ráadásul gond nélkül felmennek. Aztán rwconverter-rel vagy Reports IDE-ből lementeni a szükséges infókat, aztán lehet koncentrálni a jövőbeli BI-fejlesztésekre.
Két hasznos link:
RDF-to-BI Publisher Conversion Utility (2012-01)
Steps to convert RDF into BI (2012-05)

Szoktuk mondani beszállítóként, hogy "az ügyfél minden elött". Egy Oracle megavendor képes volt minden szakmailag és emberileg elvárható minimum-követelménnyel szembemenve kiszolgáltatni (1)hűséges, (2) sok pénzt fizetű (3) nagyméretű ügyfélbázisát ilyen léptékben, a nagy akviziciók és integrációk nyomán.
Lássuk be: nem kicsit szomorú.

Gyorsjegyzet az Alteryx-ről (ETL+Prediktív analitika)

.
* Nicsak!
Kihívója lett az IBM SPSS Modeler-nek. :)
No meg persze immáron sok tárgybavágó open source cuccnak. ;)
Egy újabb (adatbányászatban kellemes, hatékony, jó támogatású, szemben az ETL-lel, ahol szerintem közel nem ennyire egészséges már, a stream-méretek miatt) visual stream-es eszköz.
Kb. 700MB-ban előadva.

És az mind semmi, úgy pénzes (meg töredékárú) a termék, hogy mintha időben visszautaztunk volna egy "kissé". És ami (szerintem nem kívánatosan) trendszerűen megjelenik mindkettőben: GUI-s felületen ETL + Adatbányászat. (Én ugyanis két külön "szakmának" tartom az ETL-t illetve az adatbányászatot, még ha indokolt is köztük iteráció, például adatgazdagítás célzattal is.

*  A BI.hu-n is csak egy Gartneres Magic Quadrantban szerepel eddig, ráadásul abban szerintem eléggé vitatható módon. A viziónárius tengelyen jóval előrébb sorolva, mint megérdemelné szvsz, viszont a kiforrottsági tengelyen meg hátrébb van sorolva, ami tekintve a platform érettségét, nyitottságát, hatékonyságát legalábbbis fura, főleg hogy még egy RapidMinerhez képest is ekkora a távolság.

* Kezdjük az árral, főleg, hogy "követi" valamennyire az egyébként számára is fontos Tableau-t. 4.000 USD (desktop, 1 user), a Tableau 1.600-2.000 USD-jéhez képest nem lenne sok, még mondanám is, hogy nagyon megéri, főleg az IBM-es 25.000 USD-hez képest. A ciki csak az, hogy ezt évenként kell kicsengetni, és így már rögtön más a leányzó fekvése. De legalább publikus az ár, lehet vele tervezni, szemben az IBM erősen vitatható árképzési gyakorlatával.

* Miért az időutazás feeling (időben visszafele)? Hát mert C/C++ban íródott, nem Javá-ban, vagy legalább Pythonban, mint a Tableau is, bővíteni is így lehet elsősorban.

* Mi jogos a viziónáriusságban? Hát az önkiszolgáló BI (amúgy általam mindig vitatott) erőteljes támogatása, Cloud-technológiák támogatásával is megspékelve. Én értem, hogy egyre okosabbak az analitikusok, egyre inkább nagyobb szabadságot akar a világ a kezükbe adni, egyfajta demokratizálódás jegyében is (mindenki egyformán gyorsan jusson a neki kellő adathoz). Egyre komplexebb infókra van szükség, egyre rövidebb idő alatt.
De ha közben szétesik a vállalati adatmodell, ha ugyanarról az üzleti fogalomról nem egyforma, sőt akár nagyságrendi tévedést is hordozó számok keringenek, akkor logikusan merül fel a kérdés az emberben, hogy hová a nagy kapkodás?

* Érdemes megnézni a technikai specifikációt.  Kellemes benne az
- SPSS/SAS fileformátumok támogatása
- Térinformatika támogatása
- SQLite-tól teradatáig való támogatás, modernkori egzotikumokkal, vadhajtásokkal együtt.
- Külön kiemelném a Pivotal Greenplum-ot, amint a jövő nagy ígéretét.
- Integrált API-k (pl.: Google Analytics)
- Ami leginkább szembetűnik a Data Blending és Cloud feltétlen támogatása

* Érdemes nézegetni a jól megírt prezentációkat.

* Érdemes a folyamatosan bővülő gallériát is nézegetni.

* Hihetetlenül erős a GUI-s felhasználói interface a szoftverben. Végre nem kell egérkilométereket tenni, ha adatot akarunk látni, sőt az egér korrekten használható, szemben az AWT rettenetes örökségét hordozó IBM SPSS Modelerrel.

* Öröm látni a terjedő ZIP-es, XML-es internal file-formátumot.

* Poén volt érzékelni a prediktív analitikának olyan túlhajtását, mint "predictive grouping/csoportosítás". :DDDD Ugye a prediktálás az klasszikusan az osztályozás egy speciális fajtája, míg a csoportosítás egy tök más dolog. Noha én egyébként (szakmával nem igazán egyetérve) nem érzem oly távol egymástól a két "technológiát". Lásd hozzá például a Semi Supervise Learninget, ahol,csak nagyon kevés cimke szokott lenni, nagyon sok csoportosítatlan adathoz.

* Érdemes a 14 napos demót letölteni, kipróbálni (ebben is követi az IBM SPSS-Modellert, trial-módban azt is eddig lehet csak használni teljesértékűen).

* Mindenképpen érdemes szólni a napjainkban már kötelező R-integrációról, no meg a szívünknek oly kedves Tableau-hoz való símulást. :)

* A több, mint 200 node, így csoportosul.

Milyen napjaink menő adattárházas szakembere?

.
Na evvel a blogposzttal tuti biztos kivágom a biztositékot.
De egy életem, egy halálom én bizony megírom, mit gondolok a témáról aktuálisan. :)
Természetesen az alábbiak nemzetközi környezetre  vonatkoznak. A magyar piaccal annak nagyságrendje és speciális visszásságai miatt nem kívánnék foglalkozni (most sem).

A téma (nálam) rögtön kettéágazik
- menedzserre
- fejlesztőre

A menedzserről kevesebbet szeretnék most beszélni.
Részint triviálisabb, részint emiatt kevésbé izgalmas.


Nálam a követelmények egy jó adattárház-menedzser felé 

- Perfekt angol tudás, nem szimplán "tárgyalóképes", hanem bizalmat keltően jó, használója képes megfelelő árnyaltsággal érvelni, vitatkozni. Amit én megfelelően perfekt angol tudásnak képzelek, ha valaki bármilyen pénzes angol szakmábavágó tanfolyamot, kurzust képes megtartani (úgy, hogy felkérik rá).

- Képes érdemben megszólítani (egy személyben) mind az üzleti területet (akik biztosítják általában a projekthez a budgetet), és persze mind a szakmai területet is. Az üzleti terület megszólítása külön nagy kihívás, hiszen az adattárház-építés a legelső és legnagyobb falat a vállalati üzleti intelligencia megalapozásában, ami a legtöbb pénzt szokta vinni, legkevésbé látványos és közvetlenül használható eredmények nélkül.

- Van fedezet a mondandója mögött, azaz le tud vezényelni sikeresen egy adattárház-építési projektet.

Én hosszú ~30 éves pályámon, 2, azaz kettő ilyen emberrel találkoztam csak (és sajnos én nem tartozom közéjük). Természetesen nem mondok neveket. ;)


Nálam (én fogalmaim szerint) a következő követelményeknek kell megfelelnie egy jó adattárházas szakembernek:

- A legminimálisabban értenie kell angol szakszövegeket (minél kevesebb szótározással), és minimálisan chatelnie kell tudnia angolul.

- Tetszőleges SQL, tárolt eljárások (4GL) olvasása, írása. Nálam ez második helyen van. ;) Megfordítva: nem tudok elképzelni jó adattárházast, jó SQL-tudás nélkül.Sőt én igazándiból ezt üzleti emberektől is szeretem megkövetelni az egzakt kommunikáció jegyében (más jó alternatíva hiányában). Az olvasás egyre inkább tért követel egyébként magának, hiszen ma már éppen annyit kell hegeszteni meglévő adattárházakat, mint újat építeni, ha nem éppen egyenesen jóval többet.

- Bármilyen SQL-t 90% ban egy napon belül meg kell tudnia írnia. Kb. 10% maradhat csak az igazán durva, napon túlnyúló SQL-eknek.

- Mainstream RDBMS-ektől nem szabad "megijednie", de jó, ha az egzotikumok irányába is nyitott (Hive, NoSql, XML etc). Szerethet különféle adatbázisokat elérő toolokat, de a fontosabbakat jó, ha már párszor aktívan használta.

- Tetszik nem tetszik, a világ abba az irányba halad (szvsz), hogy valaki ne egy valamihez értsen nagyon jól (bár van ma is akinek ez kell és meg is fizeti), hanem mielőbb, minél kisebb overheaddel be tudjon kapcsolódni, minél több típusú projektbe. Azaz nem OWB, ODI, Datastage van/számít, hanem GUI-s ETL-workbench ;) Ráadásul, ahogy én érzékelem, örvendetes módon már hódítanak az open source cuccok.

- Komoly reverse engine képességek birtoklása, gyakran tapasztalható hányadék (módon megírt és/vagy formázott) SQL-ekre is, vagy például tetszőleges riportoló eszközben adatforráshoz jutás. Sőt Data Lineage visszakövetése riportból forrásrendszerig. Sőt! Ennek vége, hogy valaki üzleti logikát is fel tudjon deríteni, aluldokumentáltság esetén is.

- ETL-jobot kell tudni módosítani, írni ugyanabban a "stílusban", ahogy a projektben szokás (verziókövetéssel, csoportmunkatámogatással), QA-ra PROD-ra menedzseléssel.

- Meg kell tudja mondani szabványos eszközök használatával, hogy maradt-e ki valamilyen futásra előírt töltés. (Adathiány, adatminőségi problémák felderítésének támogatása)

- Ismételhető futás felismerése tetszőleges ETL-job esetén (pl.: inkrementálissal szemben). Ennek vége, hogy a konzisztens jó állapothoz való teendők azonosításra kerülnek.

- Adatreplikálás minél több módjának ismerete.

- Operációs rendszer ügyben én csak egyet állítanék/követelnék: unix/linux esetén vi/vim-mel tudjon valaki file-t szerkeszteni, ne valamiféle Windowsos workarounddal.

- A durván Custom ETL-es követelményekkel szemben én megengedőbb vagyok. Ugyanis nem szeretem őket támogatni. Mindenféle további munkák erőforrásigényét, sikerességét exponenciálisan rongálják. Ezért is maradt ez a szempont a legvégére. ;)