Adatbányászat Blog

Az Adatbányász Blogon a dmlab szakértőinek írásait olvashatod a big data és data science területéről.

dmlab.hu - Big data és data science tanácsadás
"Ha örülsz, hogy fejedre nőttek az adatok."

Keress minket bátran:
- Nagy-Rácz István +36704595669
- Gáspár Csaba +36208234154
- info@dmlab.hu

2012.07.06. 12:32 István NagyRácz

Beszámoló az IBM Modeler 15 bemutatójáról

Címkék: ibm spss clementine ibm modeler

A Clemetine Consulting az IBM adatbányászati szoftvere legújabb verziójának megjelenése alkalmából bemutatót rendezett, ahol a frissen megjelent szoftver újdonságairól hallhattunk. Természetesen a Clementine-ról van szó, ahogy ez a név sokak fejében már így marad.

A bemutatón elsőként Szabó Gábor, az IBM Hungary üzleti elemzésért felelős brand managere szólt arról, hogy miért is volt fontos lépés az IBM és az SPSS életében az a három évvel ezelőtti felvásárlás, amiként az IBM bővíteni tudta az adatelemzési megoldásainak portfólióját az SPSS termékcsaládjával. Kihangsúlyozta, hogy az IBM-en belül fontos hívószó a prediktív analitika. A három éve történt felvásárlás óta sokakban felmerült az az érzés, hogy az IBM sokat akart - értsd nagyon gyorsan akarta bővíteni a BI területre pozicionált szoftvermegoldásait -, de nem integrálta ezeket a termékeket a portfóliójába, és igazán új fejlesztéseket nem akart ezen termékek mögé tenni. Ez volt az első beszédes dolog, ami megcáfolta ezt az érzést. És nem az utolsó...

A következő előadó Körmendi György volt, aki a Clementine Consulting vezetőjeként bemutatta nagyvonalakban azokat a fejlesztéseket, amik belekerültek a legújabb termékbe. Előadásának szórakoztató része volt a termék nevezéktana (Clementine-tól, a jelenlegi, "végleges" IBM Modelerig), valamint a termék felhasználói felületén történt fejlesztések: copy paste rendes megvalósítása, zoomolás stb. Azonban, hogy ne legyek igazságtalan, a felhasználói élmények javítását számos kicsi, de annál hasznosabb új feature is szolgálja: stream paraméterek használata SQL kifejezésekben (ez annak jelent sokat, aki a script lehetőségeit is kihasználta eddig a szoftvernek), térképes megjelenítés integrációja a Statisticsből.

A másik nagyobb csoport a fejlesztések területén az analitikai újdonságok: bekerült a szoftverbe a GLMM modell, ami engem legalábbis nem hozott nagyon lázba. Lenne egy-két olyan dolog, amit el lehetne lesni a konkurensektől ebben a témában az újabbnál újabb csodaalgoritmusok helyett (például a vezérlési szerkezetek grafikus támogatása).

A harmadik csoportba a teljesítménybeli fejlesztések kerültek. Az új tulajdonosnak köszönhetően erre a kérdésre komolyabb hangsúlyt fektettek, és itt újra felcsillant a hasznos integráció szikrája. Egyelőre csak Magyarországon egzotikusnak számító adatbáziskezelőkhöz (Netezza, DB2), de fejlesztésre került egy Scoring Adapter nevű megoldás, amely az in-database mining elvén haladva a modellek futtatását teszi lehetővé az adatbáziskezelőben közvetlenül. A megoldás lényege, hogy a modelleket az adatbázisok specialitásait figyelembe véve alakítja át az adapter, és nem csak a sima SQL átírás történik meg. Az így megvalósított modellek köre jelentősen bővebb is, mint a sima SQL átírás esetében. A megoldás akkor lesz igazán átütő, ha az adaptert Oracle-höz is lefejlesztik. 

Az utolsó csoport az IT rugalmasság volt, ahol persze sok-sok terméknév és kompatibilitási infó jelent meg, de ennél sokkal érdekesebb volt az az állítás, miszerint a 15-ös Modeler bár képes megnyitni elődei streamjeit, de ez fordítva nem lesz igaz. Bár nem az első ilyen húzás nagy szoftvergyártóktól, de ez mindig tud még fájni a felhasználóknak.

A bejegyzés elején utaltam arra, hogy az IBM-et elkezdte komolyan foglalkoztatni az integráció kérdése. Ennek legerősebb bizonyítéka az, hogy a Modelerbe integrálásra került a cég, egy duplikáció azonosítására létrehozott megoldása. A Pintér Gábor által tartott demo kis bepillantást engedett a megoldás használatába. Számomra kicsit furcsa, hogy miért a Source node-ok között kapott helyet a megoldás, de ez értelmezés kérdése. A megoldás két verzióban létezik: az egyszerűbb megoldás esetén 10 millió entitás kezelése a felső határ, és egy ilyen duplikáció repository kezelésére van lehetőség, míg unleashed verzióban a repositoryk megosztása is megoldott és nincs is mennyiségi korlátozás azok méretére. A megoldás üzleti értéke felől nincsenek kétségeim, az integráció elég jól sikerült, bár látszik, hogy a felhasználói felület kialakítása nem SPSS-esen egyszerű. A legjobb hír számomra mégis az, hogy a Clementine él és a jövőben is szeretné az IBM, hogy fejlődjön és bővüljön. 

Az újdonságok közül utolsónak a szoftver hálózatelemzési lehetőségeiről beszélt Windhager-Pokol Eszter. Véleményem szerint nem egy átgondolt fejlesztés végeredményét láthatjuk a jelenlegi verzióban. A megoldás bár képes csoportok keresésére, és azokon belüli statisztikák és egyéb mérőszámok számítására (lábjegyzetként megjegyzem, hogy itt sem értem a Source panelben való elhelyezést), valamint egyszerű fertőzési modellek használatára is, de semmilyen megjelenítési támogatást nem ad (ha nem vesszük számításba a Web megjelenítési opciót, ami igazán nyakatekerten használható ebben az esetben). Reméljük, hogy a jövőben ilyen megoldások is belekerülnek a szoftverbe.

Összegzésképpen nem ugrott nagyot előre a szoftver, nem egy jelentős mérföldkő a szoftver életciklusában, de számomra megjelent az ígéret, hogy lesz a szoftvernek még hasznosan bővített változata az elkövetkezendő években.

5 komment

A bejegyzés trackback címe:

https://adatbanyaszat.blog.hu/api/trackback/id/tr384631509

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

tnsnames.ora 2012.07.07. 08:04:32

Köszönöm a posztot, jó volt olvasni róla, ha már centikkel lemaradtam róla. :o)

Az integrálással kapcsolatban nekem felemás érzéseim vannak. Például az SPSS és Cognos mindkét irányba kezdett átjárható lenni. Clementine-ban Cognos BI node, míg Cognosban SPSS prediktív analitika megjelenése (amihez nem kellett SPSS-licence-t venni). De a Netezza, IBM Infosphere Warehouse támogatás megjelenése is régóta része a portfólióba integrálásnak.
Mondjuk a mezei adatbányász-felhasználó nem biztos, hogy ezektől könnyedén lázba tud jönni. ;)

Egy kis helyesbítés. A Scoring Adapter Netezzára és Teradatara jött ki egyelőre, szerintem. Én ugyan nem találtam bitekbe leképezett nyomát, de az IBM-es vonatkozó software-repository őskáoszban ezt bőven elnézhettem. Minden esetre a doksi szerint még DB2 for z/OS-re is van. A magyar felhasználóknak szerintem mindegyik egzotikus platform, szerintem is. ;)

Érdekes kitérő a régi streamekkel való kompatibilitás. A doksiban sem találtam erről infót first lookra, hogy mi változott, hogyan és főleg miért.
Igaz az én sejtésem, hogy
(1) A verzióujdonságok nem tudnak visszafele kompatibilis módban megjelenni a streamekben. Egy graphboard ujdonsággal mit kezdjen egy v14.x-es Clementine?
(2) Mi az a vállalati forgatókönyv, hogy egyszerre kelljen használni új és régi verziójú Clementine-t átjárhatóan?

Szerintem jobban védhető, hogy source node-ban kapott helyet a deduplikáció (meg a hálózatos node). Ha a vizuális streamet nézzük "balról-jobbra" eleve DeDuplikációval kell kezdeni a feldolgozást (már ahol ennek értelme van), a forrásoldalt kell tisztítani (DQM). De a Text Analytics-hez hasonló megjelenést is el tudom képzelni, részben a struktúrálatlanból strukturált adatok, részben a prediktív analitika felhasználása szempontjából.

Az Entity Analyticsnek az igazán nagy technikai nóvuma, hogy a Clementine eddig flat file-okon tökéletesen tudott dolgozni, de a deduphoz már szükség van adatbázis jelegű local repository-ra, ami most a v15-ben megjelent. Kissé felemásan szerethető módon szerintem: nem elég, hogy csak a premium opcióban érhető el a cucc, de további felhasználói fejés az unleashed elágaztatás.

Egyébként a rendezvénytől távol én is írtam az új főverzióról egy hosszabb blogposztot kicsit más megközelítésben. A GLMM-ről is, amit itt nem ismételnék meg külön.
liftinstinct.blogspot.hu/2012/07/ibm-spss-modeler-clementine-v150.html

Gáspár Csaba 2012.07.07. 18:19:47

@tnsnames.ora: Szerintem source node-ként való berakás szerintem nem logikus. Ha én mondjuk egy-egy él súlyát szeretném változtatgatni, kipróbálni több megoldást is mondjuk arra, hogy mi a definíciója a kapcsolatnak, akkor ki kell majd mindig iratnom mindnet file-ba, hogy onnan az új node feldolgozhassa. Miért nem lehetett egy olyan felületet csinálni, ahol megmondom melyik attributum az élek kiindulási élei, melyek a célcsomópontok, és mi az élsúlyt tartalmazó attribútum. Sokkal természetesebb lett volna ezt az egészet egy feldolgozó csomópontként definiálni (esetleg modellezőként).

tnsnames.ora 2012.07.07. 18:57:27

Nem teljesen fogom ám a problémát, de ez az én korlátaimból fakad, meg abból, hogy még keveset foglalkoztam a témával. :)

Úgy érzem amit felvetsz az már egy következő szint, amihez itt a v1.0-ban ugyan nem szép, de túlélhető a flat file-ba kiírás és beolvasás. Ilyet amúgy is szokott csinálni az ember, vagy legalábbis én. :o)

Az jó kompromisszumnak hangzik, hogy mennyivel jobb lenne feldolgozási node-nak, mint source node-nak. Én amikor írtam a hozzászólásomat, elsősorban arra fókuszáltam, hogy nem modellező node-ként gondolnám a saját logikám alapján.

Míg másik oldalról az lehet egy potenciális ellenvetés, és itt elsősorban az Entity Analyticsre gondolok, szükséges (1) előzetes, (2) Clementine-on kívüli feldolgozás /mert ott nem megoldható meg/: lásd az általam említett standardizálás, adatgazdagítás. A hálózatos eset is talán felfogható analóg módon úgy, hogy tessék jó inputot adni, és akkor "elég" a source node-ként felfogás.

Extrapolálva és általánosítva.

A hagyományos eddig v14.2-ig tartó megközelítésben durván szólva két lényegi fázisa volt az adatbányászatnak: (1) előkészítés (2) modellezés kiértékeléssel. A Clementine ad egy nagyon jó workbenchet az (1)-re is, noha az nem "kötelező", ha tökéletes inputot ad a felhasználó a modellezéshez (például SQL-technikákkal). Ami kötelező és nem "megúszható" az adatbányászatban az a modellezés és kiértékelés.

Na most számtalan modellezési+kiértékelési technika létezik, amihez hasonló és sok helyen használható előfeldolgozási lépések tartoznak, amiket tehát belepakoltak a remek Clementine Workbenchbe az évek során(!). A dedup és a hálózat viszont speciálisan egyedi cucc, speciális struktúrával és problematikával. Speciális talán annyira mint a szövegbányászat ha nem egyenesen speciálisabb. Az ő speciális előfeldogozásuk implementálása nem feltétlen volt reális cél a v1.0-ban.

Szerintem.

De bőven meggyőzhető vagyok az ellenkezőjéről. és érdekes kérdés tényleg.

Gáspár Csaba 2012.07.08. 11:40:22

Számomra mindkét elem logikailag inkább a PCA eljáráshoz hasonlít: komoly számítási feladatot végez el, és manipulálja, kiegészíti a bemenő adathalmazt.

Nyilván a file-kiirás, -beolvasás egy általános technika, de ha pont mondjuk a hálózateremzős részt szeretném optimalizálni azzal, hogy más-más bemenetet adok rá, akkor csak azért, mert a source node-ról van szó, kénytelen leszek még szkriptelni is.

Logikailag egy source node lényegében abban különbözik egy belső, adatfeldolgozó node-tól, hogy nincs értelme a bemenetére egy másik node-ot kötni. Hát itt éppenséggel mindkét esetben lenne értelme.

Persze hozzá kell tennem, hogy az én logikám már nem alapból Modeler logika - a RapidMiner sokat formált a megközelítésemen, és ott akár egy file-beolvasó elé is köthetsz más csomópontot, illetve ott egy-egy élen nemcsak adathalmazok, hanem sok más adattípus is közlekedhet (modell, performancia vektor, stb). Elképzelhető, hogy a kezdő felhasználók számára ez a source node megoldás fogyaszthatóbb - és be kell látnunk, őket kell egy ilyen szoftverfejlesztés középpontjába tenni, a profibbak majd megoldják máshogy. És valóban, lényegében funkcionalitásból nem vesztettünk semmit ezzel, ha a file-kiirás/olvasás módszerét használjuk.
süti beállítások módosítása