.jpg)
2013. február 14., csütörtök
Enterprise-level Form & DB architektúra
Feladat:
- Képernyő-formokon keresztül kell Oracle - később esetleg MSSQL vagy más? - adatbázisokba adatokat rögzíteni (+valamiféle menürendszer)
- Open-Source/Free alapok, elsődleges követelmény. Ettől még egy másik blogposztban át lehet tekinteni a commercial vonalat is. ;)
- Általános - enterprise-szintű - legyen a megoldás, ahogy a blogposzt címe is hangsúlyozza.
- Vendor-független technológia előnyben. Egy Oracle-Apex ebből a szempontból nem egy jó biznisz.
- Jellemzően CRUD(=Create Read Update Delete) a feladat, de azért jó, ha van perspektíva bonyolultabb üzleti logikára, szebb és/vagy jobb felhasználói képernyő-megjelenítésre, customizálásra.
- 100%-ban (erős) Windows7 munkaállomásokból áll a vállalati környezet, miközben a szerverek már nem annyira (kliens-szerver architektúra előnyben?)
- 100%-ban intranetes megoldás kell, bármiféle internetes megspékelési követelmény nélkül
- Ami specialitás (viszonyítási alapként): Legacy-rendszereknél a drága (alapból és rendes doksi+oktatás nélkül 8 millás) illetve kiváltandó kliens-szerveres Uniface helyére kell más.
- Riportálni nem kell tudni (csak képernyő-formot és menüt kezelni), mert a riportálás Oracle BI-alapú.URL-lel persze egy APEX-ből is ki lehet vezetni egy OBIEE-t, de kérdés, hogy ez mennyire elegáns, vet-e fel szakmai kétségeket.
Emiatt a bulettpoint miatt elmondhatom, hogy nem vagyok annyira offtopik - saját blogomban :)) [Zárójelesen megjegyzendő az nem igazán várható el, hogy ne is tudjon riportálni az eszköz/technológia, csak az maximum, hogy ne legyen égbekiáltó a különbség]
Kiegészítő (jellemzően saját) szempontok:
- Legkisebb „lábnyomú” (footprint), pehelysúlyú (lightweight) legyen: gyors indulású futtató-alkalmazás, kis méretű natív exe előnyben.
- Üzleti logika text-alapon kereshetően, átláthatóan legyen 100%-ban. Egy Oracle Forms .fmb-i kerülendők tehát. ;)
- Atomgyors (hogy növelje a felhasználói élményt)
- Flexibilis legyen a végtelenségig
- 3rdparty library-k integrálása teoretice is, valós gyakorlati életben is.
- Minél könnyebb legyen benne fejleszteni: Java Swing és/vagy SWT-nél és/vagy QT-nél egyszerűbben.
- Minél teljesebb felhasználói élményt adjon rögzítői oldalon.Nálam maximális alázattal - saját egoista szempontjaimról lemondva - az elsődleges fókusz a felhasználón van, aki használná az általam fejlesztett formokat. Inkább én mint fejlesztő és/vagy üzemeltető dolgozzak kicsit többet, mert az én munkám sokkal kevesebb lenne így is összességében.
- Szép legyen a form. Nálam a „szép form” legszebben a régi Delphis 3rdparty bővítményes eszkökészlettel volt implementálható.
- Billentyűzet-támogatás elegáns legyen (ne egerészni kelljen a rögzítőnek).
- Könnyű legyen módosítani a formokat, bővíteni formokkal/alkalmazásokkal a vállat informatikai eszköztárát.
- Könnyű legyen fejleszteni. Egy Java horizontálisan(API-k) és vertikálisan(mélység) a legkomplexebb nyelv. Kérdés, hogy egy .NET és C# mennyivel egyszerűbb. Illetve ahogy a programozási nyelveknél van 3GL/4GL (magasabb szintű programozás nyelvi struktúrák), úgy a formoknál is van magasabb szintű form-használat (kódírási minimalizálással).
- Meglévő vállalati készségek minél jobb újrahasznosítása, minél kevesebb "új" tanulásával.
- Minél kevesebb és/vagy kisebb hibázási lehetőség,
- Minél jobb és gyorsabb debug- meg hibajavítási lehetőségek.
- Könnyű legyen üzemeltetni. Nálam a könnyű egy régi exe lecserélése egy újra például ;) És nem alkalmazás-szerver leállítása, újraindítása, hibák kezelése stb.
- Ad absurdum, a fejlesztő környezet installja is legyen egyszerű: kicsi cuccként, még akár .zip-ből is valamilyen alkönyvtárba kicsomagolhatóan.
- 64-bites natív támogatás (esetleg), kliens-szerver architektúra esetén.
- A fejlesztő környezet minél kevésbé legyen „egzotikus”, abbahagyott fejlesztésű, kevéssé dokumentált stb (esetleg).
- Minél tömegesebben legyen oktatva, elterjedtség szempontjából. Ha már egyszer nem Uniface.
- Legyen magyar szakirodalom. Nem azért, mert a fejlesztők nem tudnak angol szakirodalmat olvasni, hanem, mert magyar szakirodalom megjelenése, kritikus tömegű magyar felhasználói tömeget érint, amelyre a szakkönyvkiadó érdemesnek lát szakkönyvet megjelentetni cost-benefit alapokon.
- Legyen "mainstream" a megoldás. ha már egy drága egyedi Uniface kerül lecserélésre. Az nem jó trend, ha csak egy valaki ért hozzá a vállalatnál, majd ő is elmegy a nagy fluktuáció közepette. De ez csak egy elv: a megoldás szakmaisága, elvszerűsége előrébbvaló ebben a blogposztban.
- "Faltól-falig" számolt költségek minimalitása. Hiába ingyenes egy APEX akár egy Oracle XE-vel is. Ez csak licence költség. Gondoljunk bele MSSQL-nél külön fenn kell tartani egy Oracle adatbázist vassal (ad absurdum négy hardver réteggel: MSSQL,Oracle,Web,Kliens-böngésző). Meg üzemeltetéssel, karbantartással, mainstreamből kilógó szaktudásigénnyel (nem triviális CRUD esetén), munkaidővel, stb.. Amit nem ellensúlyoz eléggé másik oldalon a felhasználói élmény. Nem véletlen, hogy ingyen adja az Oracle annak aki beugrik neki. ;)
- Repository-használat üldözendő technológia, amitől még az APEX sem tudott szabadulni, pedig az Oracle Forms, Reports, Designer is belebukott korábban (illetve némileg párhuzamosan). Egy Oracle BI Suite már nem is Oracle adatbázist használ repository információk alá. ;)
- Bármilyen ActiveX üldözendő technológia
- Opcionálisan érintőképernyő-lehetőség
- Opcionálisan Android-lehetőség
A blogposzt célja:
- a tárgybeli intellektuális szakmai kihívást,
- minél szélesebb körűen és tárgyilagosan, 100%-ban szakmai alapokon végiggondolni a témát,
- perdöntően a magam számára illetve nem "igehirdetés" céllal,
- előnyök-hátrányok vonatkozásában,
- a meglévő információk alapján,
- a tévedés jogát fenntartva,
- a minél maximálisabb tisztánlátás érdekében.
Azaz egész egyszerűen magamnak tartozom avval, hogy leírom a konklúziómat és megosztom.
Elöljáróban:
- Gondolatmenetemben a mi „NEM” irányából közelítek a mi „IGEN” irányába, vagyis ami legkevesebb kompromisszum mellett a legtöbb értéket tudhatja nyújtani az én értelmezésemben.
- Az informatikában – az én tapasztalatom szerint nem nagyon szokott lenni „fekete-fehér” szituáció. Minden előny mellé vaskos hátrányok szoktak párosodni.
- Nagyon ritkán van olyan, mint kivételesen szerencsésen ebben az esetben, hogy ultimate megoldást tudok találni (minden szempontból legjobbat), jelentősebb hátrány nélkül, úgy hogy még súlymátrixot csinálni is feleslegesnek tűnik.
1. LEGKEVÉSBÉ AJÁNLOTT ARCHITEKTÚRA: háromréteges architektúrába ágyazott: Webserver / J2EE-alkalmazásszerver / Portál-motor
Előny:
* Szakmai mainstream ajánlja
* Magyarországon is van rá tapasztalat
* Van magyar nyelvű szakirodalom: ami ott fontos szempont, hogy magyar felhasználói igények kritikus tömegét jelezheti.
* Free/Open Source
* Enterprise-szintű megoldás
Hátrány:
* Szakmai filozófiám szerint; alapvetően téves koncepció esetünkben. A tágabb internetes világban működő architektúrát egy szűkebb másképpen is viselkedő intranetes világba besuvasztani, annak specialitásainak figyelmenkívül hagyásával nem igazán szerencsés.
* Ráadásul intranetes világban erős túllövés/felüllövés ilyet használni.
* Csípőből kell egy alkalmazásszerver a középső rétegbe (költség), vagy egy meglévőt tovább terhelni.
* Szerver-oldali a terhelés, nem pedig kliens-oldali.
* Fenti miatt: nem a legoptimálisabban skálázható fefelé a megoldás.
* Alkalmazás-frissítés a legnehézkesebb, legköltségesebb: időigénye, potenciális problémái miatt. Ne feledjük külön szakma a deployment, nagyobb cégeknél csak evvel foglalkozó kollégával.
* Javánál szerintem nincs is nehezebb cucc (nyelv+API). Olyan kiterjedtségű és komplexitású.
* Minden szinten óriási overhead tehát
* Windows-specifikus végfelhasználói élmény (vizuális elemek, billentyűzethasználat könnyedsége, stb) itt a leginkább fékezett habzású
* Ha újat kell tanulni, nem érdemes a legnagyobbat markolni, ha gyorsaságon és sikerességen van a fő fókusz. Arról már nem is beszélve, hogy a profi Java-tudáshoz évek és/vagy felsőoktatási tapasztalatok kellenek.
* Nem tud előny lenni, hogy Linux-ra is működőképes
* Úgy a legdrágább (beruházás+fejlesztés+üzemeltetés), hogy gyakorlatilag semmi kézzelfogható előnye nincs, hátránya viszont nemkevés.
2. MINIMUM EGY FOKKAL JOBB ARCHITEKTÚRA: .NET és C#, Free Visual Studio Express Edition-nel vagy C++ és QT
Azt az egy specialitást külön kiemelve, hogy QT-nál van QML az üzleti logikának, ami szimpatikusan vonzó feature lehet.
Pythonnal kombinálva a QT-t már meg lehet gondolni.A kombinációnak van valós hozzáadott értéke esetünkben. Nekem legalábbis tetszik. :)
* Mainstreambe illeszkedik még akár Magyarországom is.
* Gyors-egyszerű
* 3rdparty libek és következményei.
* Jellemző hátrány nélkül.
* STB.
A tárgybeli két cucc érzékelésemben egyformán jó vagy nem jó, azt leszámítva, hogy az előbbi
* elterjedtebb
* egybe összerakott (nem összevadászandó)
* könnyebben tanulható/használható.
* mindez releváns hátrány nélkül a másikhoz képest.
Így a továbbiakban csak NET és C#-t tárgyalom.
Előny:
* Szakmai mainstream másik „best” ajánlata
* Magyarországon is van rá tapasztalat, hogy aktuálisan ezt választják.
* Free és részlegesen Open Source
* Enterprise-szintű megoldás
* 32&64 bit architektúra egyaránt szépen támogatott régóta.
* Van benne data-aware komponenes, más szóval data binding (vizuális kontroll és adat könnyű összerendelhetősége)
* Kliens-oldali terhelést ad, szimpatikusan kétrétegű kliens-szerver architektúrában.
* Tökéletes a skálázás: új felhasználó egyszerűen csak egy új desktop.
* Egyszerű alkalmazásfrissítés: exe-csere
* Elérhető Windows-specifikus végfelhasználói élmény (vizuális elemek, billentyűzethasználat könnyedsége, stb) teljesnek mondható
* Ami a tárgyhoz kell, azt messzemenőkig tudja szépen és jól.
* Van magyar nyelvű szakirodalom: ami ott fontos szempont, hogy magyar felhasználói igények kritikus tömegét jelezheti.
Hátrány:
* Túl általános célú, túl nagy overheaddel, túl kevés kézzelfogható előnnyel
* Ha van könnyebb, pehelysúlyúbb,célnak jobban megfelelő eszköz, akkor érdemesebb azt használni.
* Gigantikus (tehát nagyrészt felesleges) cucc, mind install-anyagában (teljes verzióban 4GB-os DVD-t tölt meg), mind erőforrás-használatában.
* Isten összes erőforrása kevés neki. 2GB RAM nem éppen baráti neki.
* ActiveX-szel bővíthető leginkább, ami szerintem üldözendő technológia
* A P/Invoke tudhat problémát okozni, ha nem csak hivogatni kell benne, hanem oda-vissza adatcserélgetni is, adott esetben intenzíven.
* A szükséges API sokkal általánosabb célú és ezért sokkal komplexebb és nehézkesebb, sok kódolási overheaddel.
* Az üzleti logika jó ha textes állományokban van (két irányból is módosíthatóan, kereshetően). Ha ez el is érhető, biztos nem triviális ebben az esetben.
* Tanulás szempontjából majdnem(?) olyan nehéz, sok és komplex, mint a Java
* A legvastagabb magyar könyvek is ebben a témában jelennek meg perdöntően, 1000+ oldalas nagyságrendben és hol van még akkor a referencia.
* Ha el is érhető egyetlen exe az nem triviális, nagy méretű és semmiképpen nem natív.
* Ha újat kell tanulni, nem érdemes a legnagyobbat markolni, ha gyorsaság és sikeresség a fő fókusz. Arról nem is beszélve, hogy az itteni profi tudáshoz évek kellenek.
3. EGY POTENCIÁLIS ÁM OLVASATOMBAN NEM AJÁNLOTT LEHETŐSÉG: Oracle-APEX
Előny:
* Magyarországon is van rá tapasztalat
* Van korábbi tapasztalat a vállalatban, házon belül van már: nincs is ellenállás irányába (?)
* Free/Ingyenes, ha már van Oracle (de azért nem nulla költségű)
* Korrekt data binding
* Nagyon egyszerű elkezdeni használni: és ha a default-használat elég, az lehet előny.
* Ha újat kell tanulni egy csapatnak, akkor az eddigiekhez képest ez a legkönnyebb, legtöbb sikerélményt adó (kezdetben legalábbis)
* Kétrétegű architektúra (aminek azért van hátránya is), jól illeszkedik vállalatunk architektúrájába.
Hátrány:
* Szakmai közvélemény kifejezetten nem ajánlja, legtöbbször üldözi vagy megtűri: részben jogosan, részben nem.
* Magyarországi multiknál is megfigyelhető az üldözése: igaz konkréten esetünkben ez kevéssé érdekes szempont.
* Nem vendor-független technológia, ha már nem általános, enterprise-szintűt keresünk.
* Én elképzelésemben egy Oracle-alkalmazáshoz egy kis APEX form-kezelés lehet jó, míg általános célú, sok felhasználós "enterprise" form-kezeléshez már nem jó architektúra, szerintem.
* Elején említett "faltól-falig számolt" összköltségek meglehetősen magasak.
* Mintha tendencia lenne az MSSQL térnyerése, Oracle mellé (vállalatnál is, másutt is). Az APEX viszont csak Oracle mellett tekinthető értelmes alternatívának (mégha FreeTDS-sel, még akár *nix alól is elérhető, még akár egy MSSQL is, még akár szabványos ODBC-vel is) Lásd hozzá az elején taglalt szempontokban részletesebb kifejtett problémákat.
* Adatbázis-oldalon keletkezik a terhelés, miközben az Oracle-szervereknek éppen elég feladatuk van anélkül is a konkrét esetünkben/vállalatunkban.
* Sok felhasználó mellett előjöhetnek szerver-performanciális gondok, miközben kvázi parlagon maradnak a jó kis Win7-es desktopok.
* Rettenetes a skálázása: nemvéletlen, hogy ingyen beetet vele az Oracle. Nem elég gépet bővíteni/venni pluszba, hanem az Oracle licence és support költségek is ugranak, a processzor alapú licencelés miatt. Azért az igaz, hogy egy Oracle XE-t azért nem olyan könnyű kinőni egy adott szint alatt.
* Még alkalmazás-szerverben is sokkal jobb a skálázás 1:8-hoz, mint Oracle-adatbázisban.
* APEX-ben alkalmazott repository technológia olvasatomban üldözendő.Az OBIEE sokkal kultúráltabb. Nem véletlenül: az APEX Oracle-fejlesztés, míg az OBIEE akvirált cucc.
* Elkezdeni az APEX-ben fejleszteni látványosan triviálisan könnyű. A customizálás nagyon nehéz már, már könyvhegyek vannak hozzá. Meglehet nehezebb, mint a .NET és C#, és akkor már ugye.... ;)
* Windows-specifikus végfelhasználói élmény teljessége itt is erősen kérdéses számomra (vizuális elemek, billentyűzethasználat könnyedsége, stb), akárcsak egy Uniface-hez képest is.
* Van egy előnye, ami konkrétan hátrány esetünkben: látványosan tud riportálni, viszont riportoló eszköz már van ugye (OBIEE), amihez ugyan tud link vezetni, de kérdés mennyire elegánsan. Két helyen semjmiképpen nem kéne riportolni. Illetve elég lenne csak a 100% pure form-kezelés megoldása
* Alkalmazás-frissítésben is el tudok képzelni egyszerűbbet.
* Digitalis footprintben is van kisebb.
* Nem tud előny lenni, hogy Linux-ra is működőképes
* Nincs magyar nyelvű szakirodalom, azaz itthon kevéssé használják talán, hogy érdemes lenne magyarítani valamilyen könyvet hozzá.
* Jó szakember elég drága hozzá.
4. SZERINTEM LEGJOBB ARCHITEKTÚRA: Lazarus-FreePascal kombó
Előny:
* Free/OpenSource, folyamatosan fejlesztett: ez szerintem nagyon fontos, hogy megvan itt is.
* 32&64 bit architektúra egyaránt szépen támogatott régóta.
* Kliens-oldali terhelést ad, szimpatikusan kétrétegű kliens-szerver architektúrában.
* Tökéletes a skálázás: új felhasználó egyszerűen csak egy új desktop.
* Enterprise-szintű megoldás
* Ami legszélesebb értelemben szükséges a feladathoz azt messzemenőkig és a legelegánsabban adja.
* Elérhető Windows-specifikus végfelhasználói élmény (vizuális elemek, billentyűzethasználat könnyedsége, stb) teljesnek mondható, és ami fő ActiveX nélkül.
* Vele elérhető felhasználói élmény, a kereskedelmi Delphi szintjét is meg tudja akár ütni.
* Data Binding alapból adott benne és korrekten.
* Legkisebb digitális lábnyom, pici natív exe stb.
* Egyszerű alkalmazásfrissítés: exe-csere
* Az üzleti logika is tömören, text-ekben, minimális overheaddel reprezentálódik: nagyon könnyű módosítás, beletanulás.
* Customizálás úgy általános, hogy egyszerűségét és eleganciáját koherensen megtartja.
* Azaz APEX-hez kvázi hasonlóan egyszerű az indulás, de a továbblépés már sokkal könnyebb
* Van magyar nyelvű szakirodalom: ami ott fontos szempont, hogy magyar felhasználói igények kritikus tömegét jelezheti.
* A Pascal a legegyszerűbb, legmagasabb szintű, tömegeknek még mindig (legrégebb óta) legtanítottabb nyelv az átlalános célú programozási nyelvek között.
* Könnyebb benne kevésbé hibás programot írni, a nagy átlagnak.
* Case-elágazások szépen magas szinten programozhatók
case x of
'a'..'z','A'..'Z':
writeln('betu');
'0'..'9':
writeln('szam');
'[',']','(',')':
writeln('zarojel');
else
writeln('egyeb jel');
end;
* Hasonlóan magas szintű IF is, például IN-használattal.
* Nincs feleslegesnek tűnő typecast-követelmény.
Hátrány:
* Én egyet tudok felhozni: szakmai mainstream még nem igazn ajánlja, legalábbis az első kettőhöz képest. Mondjuk azt gyanítom, hogy nem szakmai megfontolásból, hanem információhiányból eredően és/vagy marketing-érdekek mentén inkább elsősorban.
Záróbekezdés:
Szakmai Java-levlistán is megfürdettem a témát, nagy szerencsémre és örömömre 86 levelet generálva a közösségben. :o):
Ott az alábbi alternatívák hangzottak legalább egyszer, perdöntően kronológiai sorrendben..
Amiről a fentebbiekben nem beszéltem azokról egy-egy jellemző mondatot is írtam.
(1) APEX (MSSQL-hez Unix ulatt FreeTDS)
(2) Lazarus+FreePascal
(3) .NET (Visual Studio Express-es) és C#
(4) Web/J2EE-alkalmazás
(5) PHP (ma hallottam mástól)
(6) központi helyen egy jar-ban egy swinges app + webstart vagy bat
(7a) "Ha tényleg nem kell üzleti logika, akkor node.js szerveroldalon az adatbáziskapcsolathoz és ezt REST eleressel ext.js megjelenítés megteszi. Kevés Javascript tudással egy jó programozó indulásnak elég... "Nem mellesleg Ext 4-től MVC alapon tudsz fejleszteni vele (sokkal átláthatóbb lesz az
egész")
(7b) "Egyébként nem lesz megkerülhető a jövőben és egyre több próbálkozás van az OO JS verziók kifejlesztésére, többek közt az általam ma már említett Anders Hejlsberg (programozási nyelv fejlesztő zseni) is nekiállt egynek TypeScript (open source): http://www.typescriptlang.org/"
(7c) "ExtJs ->teljesen független a háttértől, tehát kiszolgálhatja jersey, vagy spring, vagy akar .net is, bármi ami json-t tud előállítani" Ez a megoldás óriási vitát váltott ki a levlistán.
(8) GWT vagy IceFace (vagy PrimeFaces az előbbi lassulása miatt)
(9) "Python és QT - tud exe-be fordulni, tanulhatóságot/használhatóságot, elterjedtséget, sebességet illetően a pályán lehet."
(10) "Groovy és Grails: gyors prototipizálással. Paper prototype: JPA-Spring-Vaadin"
(11) "Én is javasolnék egyet ami még nem volt: Vaadin. (http://www.vaadin.com). Érintőképernyős pluszok, Android-kapcsolat"
(12) "Ha csak a CRUD a feladat, szerintem a Spring ROO jó alternativa lehet. https://vaadin.com/springroo"
(13) "Mi nemrég KendoUI-jal raktunk össze egy alkalmazást, de most lehet, hogy twitter bootstrap-et valasztanánk es jQuery. One page app, szerver oldalom meg amit akarsz. Közötte json rest."
+1 Kódgenerálás topik. Csak azért említem így külön, mert ez is vihart kavart a levlistán. ;)
Utóirat:
A topik nem konstruáló agymenés eredményterméke, hanem való élet konkrétan valós problémájából merített.
Egyébként az Oracle-APEX (+ Oracle XE) nyert, alapvetően rövid átfutású improvizatív alapokon, indoklás nélkül, hatalmi szóval eldöntve.
De ez semmit nem von le abból, hogy élvezettel foglalkoztam a témával. :)
2013. február 13., szerda
Egy Oracle-SQL demó-feladat
Imádom a tárgybeli műfajt, egy időben, még évekkel ezelött gyűjtöttem is őket, sőt még SQL szakmai-levlistára is igyekeztem megirogatni őket. És bizony jó régen volt már, hogy sikerült beleszaladnom ilyen demó-feladatba. Amiről csak beszélgetni sem triviális, hát még megcsinálni.
Eredetileg nem terveztem blogposztot írni róla, főleg, hogy a blogot alapvetően és elsősorban adatbányász-témáknak tartom fenn. De a 2001(?) óta létező SQL levlista-accountom rakoncátlankodik és nem enged be levelet róla, így mérgemben csak blogposztba írom meg az egészet. :)
Az alábbi feladat a "való világ"-ból vevődött, azaz nem szimpla konstruáló agymenés végterméke :o) -> egy durva reverse engine projekt indukálta.
A feladat lépésenként végrehajtva nyilván triviális, a kérdés az, hogy egyetlen SQL-ben megy-e? ;)
Táblák és mezők:
PARTNER(partner_id,partner_nev)
TRANZAKCIO_TIPUS(tranzakcio_tipus_id, tranzakcio_tipus_megnev) –41 rekord van benne
TRANZAKCIO(tranzakcio_id,partner_id,tranzakcio_tipus_id,tranzakcio_datum) –vannak további mezők is persze,csak első körben nem érdekesek.
Kapcsolatok:
PARTNER -< TRANZAKCIO – 1:N
TRANZAKCIO_TIPUS -< TRANZAKCIO – 1:N
1.Feladat:
Kell a TRANZAKCIO táblából olyan 41 rekord(~tranzakcio_id), hogy minden tranzakciótípust le kéne fedni egy tranzakció-rekorddal olymódon, hogy ->
(1) Legkevesebb partnerrel. A konkrét esetben a maximum, hogy egy partner 18 különböző tranzakciótípust tud lefedni. (Igazándiból ez a fontos kritérium.)
(2) Ha a maximumnál (18) két vagy több partner is lenne, akkor azt a partnert kell választani, akinek a legutolsó lefedésre kandidáló tranzakciója a legfrissebb/legkésőbbi dátumú.
(Ha úgy egyszerűbb lehet tetszőlegesen "ahogy esik úgy puffan" jeligével is választani közöttük)
2.Feladat(-nehezítés):
Kell a TRANZAKCIO táblából 41 rekord, azaz minden tranzakciótípust le kéne fedni egy tranzakció-rekorddal (tranzakcio_id) olymódon, hogy -> Azt a legfrissebb tranzakció-rekordot kell kiválasztani adott tranzakciotípushoz, ahol
(1) A legtöbb mező van kitöltve
(2) Különböző értékekkel (azaz rekordon belül például nem lehet két egyforma dátum).
Utóirat1: azt gondolom ezutóbbi már lépésenként sem triviális.
Utóirat2:
Jövő évben lesz, hogy 20 éve SQL-ezem, de olyanra nem emlékszem, hogy 8 napig írtam volna egyetlen SQL-t.:o))
A minap ez is megesett: többszáz tábla több ezer mezőjéből kellett reverse engine-lnem 526 db (legértékesebb) mező üzleti töltési logikáját, úgy, hogy perdöntően se primary key, se foreign key nem volt (csak elvétve és véletlenszerűen), az egyedüli indulásnál megkapott segítségem egy bonyolult form-hierarchiával bíró képernyős alkalmazás volt, ahol egyetlen módosítás is nagyon hosszú idő volt (csak általa soha napján sem végeztem volna a feladattal, ha nem találok gyorsabb megoldás-megközelítést).
A végeredmény egy 132 KB-os 3.050 soros SQL lett, ami még gyenge tesztrendszeren is, sőt order by -jal visszaadta 39 sec alatt az összes adatot többszázezer rekordnál. Jó érzés volt látni munkám gyümölcsét, illetve látni az Oracle rdbms robosztusságát. :)
2013. február 5., kedd
Big Data csak hype lenne?
Ezt a posztot az Andego blog alábbi nagyszerű poszt-sorozata indukálta.
Mém neve - Big Data I.rész
Mém neve - Big Data II.rész
Mém neve - Big Data III.rész
Sajnálom, hogy lemaradtam a szerző gyors körkérdéseiről, így amit most leírok, arról nem tudható, hogy mennyire jött volna csípőből, egyáltalán mennyire visszás egy blogposztban előhozni, így felmelegítve, másodkézből. Viszont érdekes a topik, nekem szívügyem is, úgyhogy félre a kétségekkel. :o)
I.
1. kérdés: Szerinted mit jelent a “Big Data” kifejezés? (ha fogalmad sincs, akkor azt írd ide!)
Nekem erre három definicióm van, egyiket a szerző is említette, de úttörő-becsszó, hogy nekem is eszembejutott. :o) Fontossági sorrendben:
(A) Az a méretű és/vagy komplexitású dataset, ahol a ráépülő alkalmazás-tervezés elmozdul a párhuzamos adatfeldolgozás irányába. Azt gondolom, ez egyszerre komoly és éles vízválasztó: "párhuzamos"-an gondolkodni egészen másképp kell. Ez a "párhuzamosság" mára mondhatni paradigma(-váltás), ahogy a big data is az - a kvázi nulla másodperces, null költséget igénylő eredmény-elérési követelményekkel.
(B) Komoly - értsd például IBM SPSS Modelerben triviálisan nem abszolválható - előfeldolgozást igényel a dataset, a további érdemi feldolgozáshoz. Értelmezésemben ilyen például a multmédiás adatbányászat kis és nagy léptékben egyaránt.
(C) Az IBM SPSS Modeler nem bír megbírkózni mondjuk 24 órán belül a datasettel. Ez képlékeny dolog, mert az eszköz is, a hardver is, az algoritmusok is fejlődhetnek. Ami ma nem fut le, holnap lefuthat. (Ezt a megközelítést említette a szerző a poszt-sorozatában)
2. kérdés: Hány MB/GB/TB felett beszélünk Big Data-ról?
Erre a kérdésre nem szívesen válaszolok, ugyanis nem minden a méret. ;)
Nem mindegy ugyanis, hogy sok milliárd rekordunk van pár mezővel, mezők mindegyike kitöltve.
Avagy van 15.000 mezőnk, asszimmetrikusan tele null-okkal, adott esetben lényegesen kevesebb rekord mellett (és persze ugyanakkora tárigénnyel) - lásd Orange-versenyt. Ezt a feladatot ugyanis például Oracle alatt nem igazán lehet praktikusan kezelni. ;)
Van egy másik érdekes aspektus is. Magyarországi adatbányászként más dataset-méretekkel szembesülök, mint egy Google vagy eBay.A Cloud és Big Data iránti érdeklődés-lankadást én szeretem ilyesmi okokra visszavezetni.
Én azt szeretem hangsúlyozni,hogy ha a méret és a komplexitás szorzata egy küszöbérték felett van, akkor beszélhetünk Big Data-ról. És akkor itt utalnék vissza az 1.kérdéshez illetve szempontjaihoz.
3. kérdés: Mennyire vagy biztos a 2.-es kérdésre adott válaszod helyességében? (0% ->100%-ig bármit írhatsz)
100%-ig biztos vagyok. ;) Ebben a kései pillanatban. Azonban akár már holnap is el lehet bizonytalanítani ;)
4. kérdés: Ha látsz egy Big Data cikket, akkor erre hogyan reagálsz? (“biztosan elolvasom” -> … -> “undorodva elfordulok”, de bármit írhatsz, akár azt is, hogy még nem találkoztál ilyen cikkel!)
Nagyon jó kérdés! Ami kevés cikkel találkoztam az borzasztó volt; mindennel foglalkoztak csak érdemi problémákkal nem. A jó cikket azonnal felhabzsolnám, persze a habzsolásig kell némi munka/energia-befektetés is a dologhoz.
II.
A poszt-sorozat 3.része rendkívül inspiráló volt.
A. Kompetencia
Például egy adatbányász-projekt aspektusai
- közgazdász
- informatikus
- statisztikus/matematikus
- CRM szakértő (én ide "businessman"-t írnék, a CRM túl specifikusnak tűnik)
- projektvezető
Én azonnal megemlíteném az aspektusok közötti kommunikáció problémáját.
- Miképpen döntsön egy projektvezető, hogy érdemes-e újabb iterációt tenni, vagy egy újabb algoritmust kipróbálni? Belefér-e? Miképpen tudja a kérdés megválaszolását a matematikus korrekt alapokon megtámogatni? Netán még akkor is probléma ez, ha az aspektusok egy emberen belül ütköznek? ;)
- Hogy viselkedjen az üzleti ember? Pláne, ha mondjuk a másik odalon van (megrendelőként)? Mi alapján mit mondjon?
Én egyébként idevágóan nem kompetenciahiányt írnék, hanem "kompetencia-krízist". Egyszerre kell egyre több mindenhez érteni egyre mélyebben, egyre rövidebb idő alatt, egyre olcsóbban.
B. Frusztráció
"A Big Data egyik nagy ígérete, hogy a rengeteg adaton szükségszerűen jobb modellek készíthetők. Ez látszólag így is van. Ha megkérdezünk egy adatbányászt, hogy még plusz adatokat kér vagy egy jobb modellező algoritmust, akkor 10-ből 9 biztosan több adatot fog kérni."Na ezt bizony én másképp látom, még ha egyedül is maradok vele világban.
1.ellenvetésem: szerintem szó nincs arról, hogy a több adat jobb eredményt hoz. Van amikor igen és van amikor nem. Bizonyítani is lehet, hogy egyes dimenzióredukciós eszközök (még akár a PCA is) adott eseetben úgy csökkentik a méretet, hogy jobb eredményt indukálnak: lásd waveletek, idősorok, szövegbányászat stb.
2.ellenvetésem. nem elég adott pillanatban a legjobbat produkálni. Ugyanilyen, ha nem sokkal fontosabb, az időben való állandó minőség, vagy ha nem állandó, akkor legalább - folyamatvezérelten - menedzselhető minőség szállítása. És akkor arról a trivilitásról már nem is beszélve, hogy a KPI-ok (specificity, recall, accuracy, precision) perdöntően egymás rovására javíthatók csak sokszor.
3.ellenvetésem: szó se róla volt olyan mellrák-diagnosztikai-verseny, ahol egy-két rekord volt csak a (true) tanítóminta, ott tényleg vágyott az ember egy kicsivel több adatra, de nem gondolnám, hogy a napi gyakorlatunkban ez lenne a fő probléma. Engem bizony a jobb modellező algoritmus sokszor jobban felvillanyoz. ;)
Ettől még a szerzőnek maximálisan igaza van. A frusztráció napi gyakorlat ebben a vonatkozásban is. Főleg Magyarországon... ;)
III.
Végül, hogy a poszt címének kérdésére is válaszoljak. Ahogy zajlanak a témában a történések, az bizony sokszor kelti az emberben a rosszízű hype érzését. Azonban lássuk be valós exponenciálisan robbanó problémáról van szó. egyre többől kell egyre kevesebb erőforrással egyre jobb minőséget kicsiholni. És ezt még a válság sem tudja átírni.
2012. december 3., hétfő
Adatbányász-felelősség egyes aspektusai....
...egy Andengo blog-on megjelent poszt végiggondolása kapcsán.
I.TÉMA
Ne szólj szám, nem fáj fejem?
Hát én bizony vitatkoznék a blogposzt szerzőjével ;) És sajnos muszáj itt, és nem a posztnál, mert ott nem tudok kommentet írni.
Azóta, hogy hír lett a torinói földrengés-szerencsétlenség előrejelzés bírósági perbe való torkollása, igyekszem követni az eseményeket. Még az index.hu is igyekezett folyamatosan tudósítani a történésekről. Aztán amikor megszületett az elmarasztaló ítélet, akkor összegeztem is a témával kapcsolatos gondolataimat, itt.
A biztonság kedvéért itt is megismételve, kicsit átfogalmazva, meg kicsit kiegészítve/aktualizálva:
Időrendileg csökkenő sorrendbe rakva, az alábbi indexes cikkek jelentek meg a témában (magyar nyelven érdeklődök számára)
http://index.hu/tudomany/2012/10/24/tenyleg_hibaztak_az_olasz_tudosok/
http://index.hu/kulfold/2012/10/22/hat_evet_kaptak_a_tevedo_olasz_tudosok/
http://index.hu/tudomany/2009/05/09/idoben_nem_josolhatok_a_foldrengesek/
Nekem két állításom van a témában:
I. Perirat ismerete nélkül nem lehet korrekten mérlegelni, hogy felelősségre vonhatók-e az előrejelző tudósok avagy nem és mennyiben. Nagy véleménnyel ugyan nem vagyok a jogászokról ;), de azért egy EU-államban csak nincs boszorkányüldözés a XXI.században, csak volt valamilyen jogi megalapozottsága a pernek.
II. Szerintem a dolog minimum kettéágazik:
(1) Vészhelyzet-protokoll topik
(2) Földrengés-előrejelzés topik
(1) Vészhelyzet-protokoll topik
A Nature szerint emiatt hibáztak a tudósok.
"A tudósok a tudományos részt rendesen el is végezték, azonban a kommunikációt a polgári védelem egy tisztviselőjére hagyták, akinek nem voltak megfelelő tudományos ismeretei"
(a) Nem tudni még azt sem, hogy mennyiben játszottak börtönnel a tudosók, amikor ezt a pályát választották.
(b) Nehéz elképzelni, hogy kockáztattak és/vagy játszottak emberéletekkel. Persze kizárni sem tudjuk jelenleg, hiszen nem ismerjük a periratot.
(c) Óriási rés látszik az indexes tudosításban: mintha hiányozna a részletes egyzakt Nature-indoklás, mi volt a börtönnel büntetendő hiba, amit a tudósok elkövettek.
Nekem erről eszembejut a pár évvel ezelötti itthoni - halálos balesetekkel járó - aug 20-i tüzijáték. Akkor is az előrejelző meteorológusra akarták ráhúzni a vizes lepedőt, egyébként alapvetően politikusok. És akkor is "el volt végezve az előrejelző munka", ahogy én emlékszem. Csak az a fránya kommunikáció, ugye.
Én azt gondolom - nem kell velem egyetérteni -,hogy az előrejelzés és a polgárvédelmi protokoll (mikor riasszanak) az két különböző dolog. Ezt a protokollt szerintem az előrejelző-csapat és a polgári védelem közösen kell kialakítsa. És szerintem ez a kialakított protokoll nem működött vagy jól vagy sehogyse. Ahogy egyébként kis hazánkban sem az említett esetben.
Én felelőtlenséget érzek ennél a földrengés-előrejelzéses topiknál a mindenkori tervezésben, felelősségvállalásban, illetve az utólagos maszatolásban.
Illetve kiváncsi lennék, hogy legalább a sztori kapcsán eszébe jut-e az illetékeseknek szerte a világon,hogy rendezzék az adósságaikat a témában a jövőre nézvést (nemcsak földrengéseknél).
(2) Földrengés-előrejelzés topik
Sajnos kevés vagyok a földrengés-témához, meg kevés az infó is ebben az olasz történetben.
Ami nekem eszembejut idevágóan: nem nagyon tudok olyan hírről, hogy 1-2 napon belül itt és itt nagy erejű foldrengés LESZ. Azaz nem tűnik túl egzaktnak a földrengés-előrejelzés. De persze ettől még lehet (valamennyire) az. Ennek eldöntéséhez ismerni kéne a földrengés-, illetve a lokális (itt olasz) specifikumokat, a rendelkezésre álló adatokat.
Az én konklúzióm: tudomásul kell venni, nem mindegy, hogy
(a) az adatbányász szimplán projekt-beszállító, aki a projekt végén felveszi a megállapodott tiszteletdíjat, pláne úgy, hogy mivel általában értelemszerűen nincs predikciós SLA, az előzőleg megkötött szerződésben, így garanciális kötelezettségei sincsenek előrejelzéseinek időbeli stabilitását illetően.
(b) avagy az adatbányász az üzleti folyamat permanens részét képezi, folyamatosan kapva a fizetését. Ilyenkor az adatbányász minimum azért felelős, hogy a korábbi tapasztalatok helyesen legyenek aggregálva, "korrektesedjenek" az előrejelzései.
És akkor következzék a "vitatkozás", vagyis hogy mit látok másképpen:
(1) Nem értek egyet a KD-Nuggets cikk felvetésével: szerintem nem jó kérdésről történt a szavazás. A kérdés számomra az, hogy az ilyen-olyan pontatlanságú előrejelzések ismeretében ki vállalja az adott esetben téves riasztás ódiumát, költségét (netán akkor történt haláleset felelősségét), milyen információ(k) alapján, milyen teher alatt. A döntéshozónak kell-e "adatbányászul" tudnia: tévedés esetén mentség-e, hogy ő nem adatbányász, "csak" döntéshozó.
(2) Megfordítva: nem lehet az adatbányászatot leválasztva leválasztva a teljes egészről, laboratoriumi körülmények közé véve vizsgálni, mert tévútra vezethet. Nem látom, hogy lehetne particionálni ("modularizálni") a problémát, a teljes folyamatot kell górcső alá venni, adott esetben más fókusszal. Mondhatja-e az adatbányász, hogy az ő munkája pusztán csak a predikció elkészítéséig terjed.
A helyzet szakmai szemmel nagyon rossz/nehéz (az én értékelésemben).
Adott az "üzlet" (polgárvédelem) és adott az előrejelző adatbányász/tudós. Tökéletes harmoniában, 100%-os biztonsággal (első és másodfajú hiba nélkül) kéne együttműködniük, úgy, hogy előzetesen nem tudnak, mert nem tudhatnak szerződésben, minden látható és potenciálisan bekövetkező aspektusra kiterjedően megállapodni. (Én erre szoktam azt mondani, hogy egy adatpiac-építés egzakt tudomány - persze nem Magyarországon ;) -, míg az adatbányászat definitive ritkán lehet az: max.: egy Netflix-verseny)
És ha ezt még lehet tovább fokozni, akkor Magyarországon még a fentinél is rosszabb/nehezebb a helyzet.
Ugyanis attól még, hogy nem lehet felkészülni mindenre előzetesen egy szerződés(tervezet)ben, attól még a felek viselkedhetnek korrekten. Na Magyarországon még ez sem bír összejönni az én újabbkori tapasztalatom szerint.
Az én álláspontom, hogy adatbányász-projektet csak olyan feleknek lenne szabad vállalni, akik feltétlen megbíznak egymásban - kvázi mint egy házasságban ;), ahol szintén nem tudni előre mi minden fog történni a felekkel -, kellően intellingesek, felelősségvállalók, határokat pontosan látók, és korrektek, ahhoz, hogy ne egymás rovására érvényesüljenek, hanem közösen valami minőségit alkossanak.
II.TÉMA, szintén egy Andego-blogposzt nyomán, de most már csak röviden.
Miért nem szeretem a BI-t?
De jó volt olvasni ezt a fenti linkelt blogposztot! :o))
Abszolút egybevág az én véleményemmel is. Mondjuk nekem kicsit más (friss), hogy ne mondjam "ortogonális" ellenérzésem van a témában.
Konferenciákon már kétszer is hallottam, hogy a Microsoft PowerPivotja milyen baromi jó eszköz. Nemrég egy (adatbányász-)projektben kellett kétmillió rekordos táblázatot tesztelni (nekem is, meg az SQL-ül nem tudó üzletnek is). Mivel adatbányász.-projektről beszélünk nem elég kiválasztani az első mondjuk 1000 rekordot, sajnos teljes egészében szükség van a táblázatra, a megfelelő következtetések, számok megadásához.
Na PowerPivot. A kétmillió rekord bemegy az Excel-be (v2010) 1-2 perc után. A PowerPivot viszont úgy áll fejre tőle, úgy belereccsen, hogy csak les az ember. Na ennyit az (önkiszolgáló) BI-ról ;) De nehogy bárki ebből Microsoft-ellenességet olvasson ki. Az új csoda Cognos-eszköz is ugyanúgy hanyattvágja magát. Egy Clementine-nal persze nem lenne gond (bár nagyon lassú, de legalább elvégezhető a feladat, leszámítva a csúnya elszállásait), csak nála meg cost-benefit problémák vannak, ugye.
Ilyenkor azért örülök annak, hogy az SQL-tudásom nem egyik pillanatról a másikra lesz ad acta. ;)
2012. július 25., szerda
És akkor pár szó a LIFT-ről...
.
...ha már benne van ennek a blognak a nevében. :o)
Kerestem egy elemi és egyúttal minél teljesebb összefoglalót a tárgybeli - adatbányászatilag - kulcsfontosságú témában, ha már ez a blog is ezt helyezi fókuszba a blognév választásával, ugye. :o) Nemhogy magyarul, de még angolul sem találtam. Persze lehet ám, hogy ez az én saram ;)
Mivel hosszú és fárasztó a téma, én meg nem a rövid blogposztokról vagyok híres ;), kezdjük távolról és lazábban a témát:
Az angol nyelvterületen 15.század óta létezik a LIFT szó, vélhetőleg onnan került át változatlan formában magyar nyelvterületre is.
Ahelyett, hogy (erölködve) magyaráznám köznapi jelentését, vagy netről linket keresnék az értelmezésére; a ma használatos (és nekünk tárgyunk szempontjából izgalmas) értelmére mutatnék inkább pár viccet:
Az elképzelhetetlenül részeg és borzalmasan mocskosszájú Józsi bácsi megy hazafelé.
Belép a lépcsőházba, beszáll a liftbe, azonban a lift leszakad.
Az öreg össze-vissza töri magát, felugrik és elkezdi rugdosni a liftet, közben üvölt:
- B*zmeg! Azt mondtam, hogy a harmadikra!!!
- Te Józsi, van egy jó meg egy rossz hírem. Melyiket mondjam előbb?
- Na, mondd a jót!
- Már a kilencediken vagyunk.
- És mi a rossz?
- Az, hogy a másik házba kellett volna felvinni a zongorát.
- Milyen az arab lift?
- Megnyomsz egy gombot....és jön az emelet.
Azaz a LIFT köznapi jelentése alapján: energia befektésével, valamilyen téren akarunk "feltornászni" valamit ("nyerészkedés" jelleggel).
Adatbányászatban két fontos területen/módszerben is használják (minimum: lehet hogy több helyen is, de most éppen elég lesz a két legfontosabbra fókuszálni).
(1) Asszociációs szabályok
(2) Osztályozás, azon belül előrejelzés.
A gyakorlatban az utóbbi a hangsúlyosabb, izgalmasabb, viszont ABC-rend illetve könnyebbség szerint ez a helyes rendezettség, szvsz, ezért tehát ebben a sorrendben is tárgyalnám a következőkben :o)
Mindkét területen fel kell "tornászni", emelni valamit. (1)-nél érdekességet, (2)-nél hatékonyságot, minőséget.
I. Asszociációs szabályok:
A klasszikus példa szerint adott 5 db TESCÓ-s vásárlás(i kosár/tranzakció).
(1) tej, kenyér, sör, tojás
(2) kenyér, pelenka, tojás sör
(3) tej, kenyér
(4) tej, pelenka, szalonna, sör
(5) tej, kenyér, pelenka, sör
1.fogalom: frequency(~gyakoriság):
Hasonlóan a valószínűségszámításban tanultakhoz, adott elem gyakorisága, előfordulásának száma osztva az összes (tranzakció) számmal. Ez a hányados egyúttal az adott elem előfordulási valószínűsége is tehát.
Gyakoriság(X) = előfordulás_db / összes_db
Ami nóvum, hogy a különböző gyakoriságok közül minket a nagyobb gyakoriság jobban érdekel, következésképpen húzunk egy határt, küszöbértéket (=treshold), aminél kisebb gyakoriság már nem érdekel minket. Legyen ez min_gyak!
Példánkban tej, kenyér, pelenka, tojás, szalonna, sör elemek vannak. A pelenka-sör kombináció 3-szor fordul elő az összes 5 db tranzakcióból. Gyakorisága tehát: 0.6
2.fogalom: support(~bizonyosság)
A gyakoriság nem képes az elemek közti kapcsolat értelmesebb ábrázolására, ezért van szükségünk erre az új fogalomra. Asszociációs szabálynak (két elem esetén) az X=>Y implikációt nevezzük. Asszociációs szabályok adatbázisból való kinyerésekor arra keressük a választ, hogy a tranazkciók hány százaléka tartalmazza Y-t, ha X-et is tartalmazza.
Bizonyosság(X=>Y) = gyakoriság(X+Y) / gyakoriság (X)
Ennek valószínűségszámítási analógiája a P(Y|X) feltételes valószínűség.
Példánkban: bizonyosság(pelenka=>sör)=gyakoriság(pelenka+sör)/gyakoriság(pelenka)=0.75
A gyakorisághoz hasonlóan a bizonyosságnál is a minél nagyobb bizonyosság az érdekes számunkra, következésképpen itt is húzunk egy alsó küszöbértéket, aminél kisebb bizonyosság nem érdekel már minket. Legyen ez min_biz!
Egy asszociációs szabályt akkor tekintünk érvényesnek, ha min_gyak feletti a gyajkorisága és min_biz feletti a bizonyossága.
3.fogalom: lift(~érdekesség).
Az érvényes asszociációs szabályok egyrészt nagyon sokan lehetnek az elemek számának növekedésével, másrészt nem egyformán érdekesek.
Klasszikus példa szerint 500 ember kávé- és teafogyasztását vizsgálták meg, azt keresve, hogy a tea fogyasztása mennyire befolyásolja a kávé fogyasztását.
Legyen min_gyak=0.1, min_biz=0.7!
Teát az emberek 20%-a ivott, kávét 80%-uk, mindkettőt 15%-uk.
A gyakoriság(tea): 20%, azaz 0.2
A bizonyosság(tea=>kávé): 15/20=0.75
Mivel teát 20% iszik (=0.2 gyakoriság), ami nagyobb a min_gyak-nál (0.1)
Mivel a bizonyosság(tea=>kávé)=0.75, ami nagyobb a min_biz-nél (0.7).
Tehát az asszociációs szabály(tea=>kávé) érvényes szabály.
A nagy kérdés az az, hogy ez az érvényes asszociációs szabály érdekes is-e egyúttal?
Az emberek 80%-a iszik kávét, vagyis a tea fogyasztása valójában csökkenti a kávé fogyasztását nem növeli, ami nekünk ugye jó lenne. A kávéfogyasztás növelését nem tudjuk elérni teafogyasztás növelésével. Következésképpen a tea=>kávé asszociációs szabály félrevezető.
Ha a min_gyak, min_biz küszöböket
- alacsonyra állítjuk, akkor sok érvényes, de kevés érdekes asszociációs szabályhoz jutunk.
- magasra álíltjuk, akkor viszont érdekes asszociációs szabályokat dobálhatunk ki.
Az érdekességnek, mint mutatónak, létezik megközelítésileg
(1) szubjektív
(2) tárgyilagos
verziói. A szubjektívvel értelemszerűen most nem foglalkozunk.
A tárgyilagos érdekességmutatók legegyszerűbbike és legérdekesebbje az inkriminált LIFT.
Lift(X=>Y) = bizonyosság(X=>Y) / gyakoriság (Y)
Példánkban: Lift(tea=>kávé) = bizonyosság(tea=>kávé) / gyakoriság (kávé) = 0.75/0.8.
Azonnal látszik, hogy 1 alá csökkent a hányados, ami nekünk nem jó ("üldözendő).
Zárásként ami még érdekes, egy asszociációs szabály feltételét és következményét egymástól függetlennek tekintjük, ha a LIFT=1.
Ekkor: gyakoriság(X+Y) = gyakoriság(X) * gyakoriság(Y)
Végül ekkor: P(X,Y) = P(X) * P(Y)
Ami két esemény függetlensége, amit jól megtanultunk annó valószínűségszámítás órán.
:o)
II. Osztályozás (azon belül előrejelzés):
Minden előrejelzés osztályozási feladat is egyúttal (halmazelméleti értelemben). Az hogy valami bekövetkezik vagy nem, az bináris osztályozás távolabbról szemlélve. (Most nem ideértve az idősorok előrejelzését, mert az tök más dolog: az angol terminológia élesen megkülönbözteti a kettőt, az előbbi a prediction, az utóbbi a forecasting)
Klasszikus üzleti életben gyakran előforduló előrejelzési feladat:
- Churn(~elvándorlás), egy adott ügyfél otthagyja-e vagy sem például az internetszolgáltatóját, biztosítóját, bankját, stb.
- Response rate (~válaszolási arány)) például direkt marketing termékajánlati levél nyomán érdeklődik-e vagy sem az ügyfél a vállalatunknál a termékajánlat témájában.
Egy ilyen feladatban tudjuk az összes rekord számot (N)
Tudjuk, hogy eddig hányan vándoroltak el (churnöltek) például: (K)
Random mintavételezésnél: K/N relatív gyakorisággal találunk churnölőt.
Praktikusan nézve az összes N db ügyfelet "megdolgozva" tudunk foglalkozni összes K darab churnölővel.
A cél az lenne, hogy nagyságrendileg kevesebb (<<N) rekorddal dolgozva (valószínűség szerint csökkenősorrendbe rakva őket, a legvalószínűbbekkel "TOP N" foglalkozva), tudjunk foglalkozni minél több churnölővel. Az elérhetetlen ideális lenne persze, hogy K darab ügyfelet kiválasztva, a halmaz lefedné az összes K darab churnölő ügyfelet.:o)
Másképp fogalmazva a cél az lenne, hogy a random relatív gyakoriságot mindenféle okos (adatbányászati módszerekkel) meg tudjuk növelni.
Például, ha van 10 db ügyfelünk, akikből 2 churnöl, akkor mondjuk 10% (=1 db ügyfél) "kézbevétele" után lehetőleg azonnal találjunk/tántorítsuk el churnölő szándékától legalább 1 db churnölőt. Azaz 2/10=0.2 relatív gyakoriság helyett dolgozzunk mondjuk 100%-os (ötszörözött) hatékonysággal.
Na erről szól az osztályozásban/előrejelzésben a LIFT.
Csináltam egy végtelenül leegyszerűsített (túlbutított?) demót a szemléletéshez, Clementine-nal
Van a S(=source=magyarázó, prediktor) mező és van a T(=target, cél) mező.
10 rekordot vettem fel. Akikből ketten churnölnek.
Logisztikus regresszióval modelleztem
Az egyszerűsítés jegyében saját magára mértem vissza az adathalmazt (ilyet ugye tudjuk, hogy nem szabad csinálni a való életben).
A két churnölőt 1-es valószínűséggel egy churnölőt tévesen, de csak 0.875-ös valószínűséggel találtam meg a modellezés során.
Összefoglalva:
True Positive: 2 db
True Negatíve: 7 db
False Positive: 1 db
False Negatíve: 0 db
Mindösszesen: 10 db.
Képlet:
Ahol
p a valószínűség szerint csökkenőbe rendezett felső (=TOP) mondjuk k=5-10-20-30% rekordban talált valószínűség
h(=hit, azaz találat), adott előfordulásra volt-e találat (1) vagy nem (0)
LIFT-kiértékelés (churnarány görbe)
20%-nál
Számlálóban: tehát kettő jó találat van (1-es valószínűséggel) a háromból(=0.6666)
Nevezőben: 2 churnölő van a 10 ügyfél közül (=0.2)
0.6666/0.2=0.3333=3.3-as LIFT
Feltéve, hogy jól számoltam. ;)
GAINS-kiértékelés, True Positive Rate (koncentrációs görbe)
Mivel 2 jó találat van (1-es valószínűséggel) 3-ból, ezért 66% a "csúcs-ugrás", már úgy értve, hogy a legkevesebből.
RESPONSE-kiértékelés
TOP 20%-ban a 100%-nyi churnölőt találtunk.
PROFIT-kiértékelés
TOP 20%-ban a 100%-nyi churnölőt találtunk, TOP10%-ban csak fele annyit.
ROI-kiértékelés (Return of Investment)
100% kiértékelése után az 1 révedés miatt 33%-nyi veszteségünk volt.
Ott tartunk tehát, hogy 20%-nyi churnölőnél:
- az "elérhetetlen" elméleti maximum LIFT az 5(=1/5 reciproka)
- mi nem kis csalással elértünk 3.3-as LIFT-et, 20%-nál.
Összefoglalva, ami fontos az osztályozós/predikciós LIFT-nél:
-A LIFT egy metrika, másképp szólva - esetünkben osztályozás/prediktálós típusú - adatbányászati modellezés minőség(biztosítás)i mutatója.
-Bináris célváltozó kell, azaz churn, response, etc. (elvándorol, nem vándorol – válaszol, nem válaszol – stb.). A multinomiális osztályozás könnyedén visszavezethető bináris esetre (adott osztálynak tagja-e vagy sem).
-A nevezőben a véletlen kiválasztás relatív gyakorisága k/n, vagyis k db churn osztva n db összes rekorddal.
-A számlálóban van a top x darab rekord, ahol jóval többet kell találni mint véletlen mintavételezésnél.
-Így jön ki hogy hányszoros a lift a véletlenes mintavételezéshez képest.
LIFT FAQ/GYÍK
Miért preferálja az üzleti élet a LIFT-mutatót, szemben a matematikusok, adatbányász verseny kiírók - például - AUC-ával szemben (=Area Under Curve, görbe alatti terület)?
Nekem erre két észrevételem van. Egy rosszmájú ;) és egy jóindulatú.
(1) Egy marketinges mindig jobban szereti azt mondani, hogy mondjuk kétszer akkora a hatékonyságnövelés, mint azt, hogy 10%-kal több. Egész egyszerűen jobban hangzik. ;)
(2) A matematikusban fel sem merül, hogy az összes vizsgált (akár milliós darabszámú) rekordot "kézbevegye", hacsak nem mazoista. Az üzleti életben meg pont azon van a fókusz, hogy például az ügyfelekkel foglalkozni kell. Na most, ha mindenkivel nem is lehet a gigantikus mennyiség okán, akkor legalább fontossági sorrendet érdemes felállítani köztük (minél kevesebből minél nagyobb eredményt elérni).
Hányszoros LIFT-et szeret az üzleti megrendelő, aminél elégedett? Minimálisan mennyi az elfogadható LIFT, amiért már ki is fizetik a beszállítót?
Az elméleti LIFT elérése a vágyak kategóriája. 2-szeres LIFT elérését már ki szokták fizetni tapasztalat szerint Magyarországon. Ha ennél (jóval) kisebb a LIFT, akkor az a mondás, hogy nincs elég magyarázó erő az elvégzett adatbányászati modellezésben. Aminek oka lehet az adatok belső összefüggéseiben (például DQM=adatminőségi), de lehet ok az elégtelen modellezés is. Mindez vezethet "érdekes" beszélgetésekhez üzleti megrendelő és adatbányászos beszállító között. ;)
Kérdés: van-e erről a 2-szeres elfogadható minimum LIFT-ről érdemi referencia a neten, hogy ne "bemondásra" kelljen elfogadni?! Próbáltam keresni ilyen hivatalos referenciát is a minimálisan elfogadható LIFT-re, de nem igazán jártam sikerrel. Még ez a legelfogadhatóbb, ahol a példában 1.875-ös LIFT-et adnak meg, ami még az általam említett 2-nél is kevesebb, azaz én "szigorúbb" voltam. ;)
Triviális (elméleti) LIFT-növelés?!
Üzleti életben egy "churn" távolról sem triviális fogalom. Nem mindegy, hogy kit tekintünk pontosan, egzaktan, teljeskörű konszenzus mentén, churnölő ügyfélnek. Egyáltalán hogyan képződik le pontosan az üzleti fogalom a churn-mező mappelése során.
Az fixálható felső határként, hogy a teljes halmaz maximum fele lehet churnölő. Ha több, akkor azt érdemes előrejelezni, hogy ki marad. :o) Alsó határként meg az lenne az ideális, hogy akkora legyen a beazonosított churnölő ügyfélkör amekkorával van kapacitás foglalkozni vállalaton belül.
Emiatt aztán előfordulhat egy érdekes mellékhatás, nevezetesen az adatbányászati modellezés során kisebb lesz a teljes részhalmazon belül a churnölők részhalmaza. Ez aztán automatikusan megnöveli tehát az elérhető elméleti LIFT-maximumot, és gyakorlati értelemben is könnyebb lehet magasabb (és látványosabb) LIFT-et elérni.
Magam részéről hangsúlyozni szoktam, hogy a fenti mellékhatás az tényleg csak mellékhatás, nem pedig klasszikus optimalizálási cél, churn-rekordszám csökkentése vonatkozásában. A mellékhatás eröltetett fókuszba helyezése nem lehet kívánatos cél, bármennyire csábító. Modell-jóságra kell törekedni, nem pedig adott esetben hamis látványra.
Lehet-e a modellezés tényleges elvégzése elött valahogy "előreszámolni" a LIFT-et?
Sajnos jelen tudásom/tudásunk szerint (?), előre megrendelési, tendereztetési fázisban még csak közelítőleg sem lehet érdemi véleményt arról mondani, hogy mennyi idő- és energiaráfordítással, mennyi az elérhető LIFT.
Ha tehát például 10-szeres az elméleti maximum LIFT és a 2-szeres LIFT-et már elfogadottnak tekintjük, akkor mondhatjuk, hogy 2-10-szeres LIFT-pálya, sikeres adatbányászati modellezésnél. Ilyet azonban eléggé veszélyes mondani, mert az üzleti megrendelő lelki szemei elött megjelenik,hogy akkor majd 9-9.5-szeres LIFT-et megcélozzuk. Holott a gyakorlat szerint nagyon sokszor örülni kell a 2-3-szoros LIFT-nek is, abban is lehet óriási pénzügyi profit-potenciál.
Mi van a "kedvenc" NULL-unkkal?
A prediktálás során a célváltozó felveheti ugye a köztudott 0,1 értékeket, de lehet NULL is. RDBMS-világban a NULL nem érték, hanem - undefinit - állapot. Hogyan befolyásolja ez a NULL-ozás túlózás a LIFT-számolást? Ennek kifejtését meghagynám másoknak. Én beérem ebben a pillanatban egy kardinális állítással, aminek bizonyítását mindenkinek magának kell megejtenie:
Jó modellezés nem vezethet NULL célváltozóhoz, egyetlen rekordnál sem.
Tessék jól adatbányászkodni és akkor nincs probléma NULL-ok miatti LIFT-számolással!
Mindezt azért mondom, mert nekem például sikerült már beleszaladnom a problematikába, nem kis fejfájást okozva. ;)
...ha már benne van ennek a blognak a nevében. :o)
Kerestem egy elemi és egyúttal minél teljesebb összefoglalót a tárgybeli - adatbányászatilag - kulcsfontosságú témában, ha már ez a blog is ezt helyezi fókuszba a blognév választásával, ugye. :o) Nemhogy magyarul, de még angolul sem találtam. Persze lehet ám, hogy ez az én saram ;)
Mivel hosszú és fárasztó a téma, én meg nem a rövid blogposztokról vagyok híres ;), kezdjük távolról és lazábban a témát:
Az angol nyelvterületen 15.század óta létezik a LIFT szó, vélhetőleg onnan került át változatlan formában magyar nyelvterületre is.
Ahelyett, hogy (erölködve) magyaráznám köznapi jelentését, vagy netről linket keresnék az értelmezésére; a ma használatos (és nekünk tárgyunk szempontjából izgalmas) értelmére mutatnék inkább pár viccet:
Az elképzelhetetlenül részeg és borzalmasan mocskosszájú Józsi bácsi megy hazafelé.
Belép a lépcsőházba, beszáll a liftbe, azonban a lift leszakad.
Az öreg össze-vissza töri magát, felugrik és elkezdi rugdosni a liftet, közben üvölt:
- B*zmeg! Azt mondtam, hogy a harmadikra!!!
- Te Józsi, van egy jó meg egy rossz hírem. Melyiket mondjam előbb?
- Na, mondd a jót!
- Már a kilencediken vagyunk.
- És mi a rossz?
- Az, hogy a másik házba kellett volna felvinni a zongorát.
- Milyen az arab lift?
- Megnyomsz egy gombot....és jön az emelet.
Azaz a LIFT köznapi jelentése alapján: energia befektésével, valamilyen téren akarunk "feltornászni" valamit ("nyerészkedés" jelleggel).
Adatbányászatban két fontos területen/módszerben is használják (minimum: lehet hogy több helyen is, de most éppen elég lesz a két legfontosabbra fókuszálni).
(1) Asszociációs szabályok
(2) Osztályozás, azon belül előrejelzés.
A gyakorlatban az utóbbi a hangsúlyosabb, izgalmasabb, viszont ABC-rend illetve könnyebbség szerint ez a helyes rendezettség, szvsz, ezért tehát ebben a sorrendben is tárgyalnám a következőkben :o)
Mindkét területen fel kell "tornászni", emelni valamit. (1)-nél érdekességet, (2)-nél hatékonyságot, minőséget.
I. Asszociációs szabályok:
A klasszikus példa szerint adott 5 db TESCÓ-s vásárlás(i kosár/tranzakció).
(1) tej, kenyér, sör, tojás
(2) kenyér, pelenka, tojás sör
(3) tej, kenyér
(4) tej, pelenka, szalonna, sör
(5) tej, kenyér, pelenka, sör
1.fogalom: frequency(~gyakoriság):
Hasonlóan a valószínűségszámításban tanultakhoz, adott elem gyakorisága, előfordulásának száma osztva az összes (tranzakció) számmal. Ez a hányados egyúttal az adott elem előfordulási valószínűsége is tehát.
Gyakoriság(X) = előfordulás_db / összes_db
Ami nóvum, hogy a különböző gyakoriságok közül minket a nagyobb gyakoriság jobban érdekel, következésképpen húzunk egy határt, küszöbértéket (=treshold), aminél kisebb gyakoriság már nem érdekel minket. Legyen ez min_gyak!
Példánkban tej, kenyér, pelenka, tojás, szalonna, sör elemek vannak. A pelenka-sör kombináció 3-szor fordul elő az összes 5 db tranzakcióból. Gyakorisága tehát: 0.6
2.fogalom: support(~bizonyosság)
A gyakoriság nem képes az elemek közti kapcsolat értelmesebb ábrázolására, ezért van szükségünk erre az új fogalomra. Asszociációs szabálynak (két elem esetén) az X=>Y implikációt nevezzük. Asszociációs szabályok adatbázisból való kinyerésekor arra keressük a választ, hogy a tranazkciók hány százaléka tartalmazza Y-t, ha X-et is tartalmazza.
Bizonyosság(X=>Y) = gyakoriság(X+Y) / gyakoriság (X)
Ennek valószínűségszámítási analógiája a P(Y|X) feltételes valószínűség.
Példánkban: bizonyosság(pelenka=>sör)=gyakoriság(pelenka+sör)/gyakoriság(pelenka)=0.75
A gyakorisághoz hasonlóan a bizonyosságnál is a minél nagyobb bizonyosság az érdekes számunkra, következésképpen itt is húzunk egy alsó küszöbértéket, aminél kisebb bizonyosság nem érdekel már minket. Legyen ez min_biz!
Egy asszociációs szabályt akkor tekintünk érvényesnek, ha min_gyak feletti a gyajkorisága és min_biz feletti a bizonyossága.
3.fogalom: lift(~érdekesség).
Az érvényes asszociációs szabályok egyrészt nagyon sokan lehetnek az elemek számának növekedésével, másrészt nem egyformán érdekesek.
Klasszikus példa szerint 500 ember kávé- és teafogyasztását vizsgálták meg, azt keresve, hogy a tea fogyasztása mennyire befolyásolja a kávé fogyasztását.
Legyen min_gyak=0.1, min_biz=0.7!
Teát az emberek 20%-a ivott, kávét 80%-uk, mindkettőt 15%-uk.
A gyakoriság(tea): 20%, azaz 0.2
A bizonyosság(tea=>kávé): 15/20=0.75
Mivel teát 20% iszik (=0.2 gyakoriság), ami nagyobb a min_gyak-nál (0.1)
Mivel a bizonyosság(tea=>kávé)=0.75, ami nagyobb a min_biz-nél (0.7).
Tehát az asszociációs szabály(tea=>kávé) érvényes szabály.
A nagy kérdés az az, hogy ez az érvényes asszociációs szabály érdekes is-e egyúttal?
Az emberek 80%-a iszik kávét, vagyis a tea fogyasztása valójában csökkenti a kávé fogyasztását nem növeli, ami nekünk ugye jó lenne. A kávéfogyasztás növelését nem tudjuk elérni teafogyasztás növelésével. Következésképpen a tea=>kávé asszociációs szabály félrevezető.
Ha a min_gyak, min_biz küszöböket
- alacsonyra állítjuk, akkor sok érvényes, de kevés érdekes asszociációs szabályhoz jutunk.
- magasra álíltjuk, akkor viszont érdekes asszociációs szabályokat dobálhatunk ki.
Az érdekességnek, mint mutatónak, létezik megközelítésileg
(1) szubjektív
(2) tárgyilagos
verziói. A szubjektívvel értelemszerűen most nem foglalkozunk.
A tárgyilagos érdekességmutatók legegyszerűbbike és legérdekesebbje az inkriminált LIFT.
Lift(X=>Y) = bizonyosság(X=>Y) / gyakoriság (Y)
Példánkban: Lift(tea=>kávé) = bizonyosság(tea=>kávé) / gyakoriság (kávé) = 0.75/0.8.
Azonnal látszik, hogy 1 alá csökkent a hányados, ami nekünk nem jó ("üldözendő).
Zárásként ami még érdekes, egy asszociációs szabály feltételét és következményét egymástól függetlennek tekintjük, ha a LIFT=1.
Ekkor: gyakoriság(X+Y) = gyakoriság(X) * gyakoriság(Y)
Végül ekkor: P(X,Y) = P(X) * P(Y)
Ami két esemény függetlensége, amit jól megtanultunk annó valószínűségszámítás órán.
:o)
II. Osztályozás (azon belül előrejelzés):
Minden előrejelzés osztályozási feladat is egyúttal (halmazelméleti értelemben). Az hogy valami bekövetkezik vagy nem, az bináris osztályozás távolabbról szemlélve. (Most nem ideértve az idősorok előrejelzését, mert az tök más dolog: az angol terminológia élesen megkülönbözteti a kettőt, az előbbi a prediction, az utóbbi a forecasting)
Klasszikus üzleti életben gyakran előforduló előrejelzési feladat:
- Churn(~elvándorlás), egy adott ügyfél otthagyja-e vagy sem például az internetszolgáltatóját, biztosítóját, bankját, stb.
- Response rate (~válaszolási arány)) például direkt marketing termékajánlati levél nyomán érdeklődik-e vagy sem az ügyfél a vállalatunknál a termékajánlat témájában.
Egy ilyen feladatban tudjuk az összes rekord számot (N)
Tudjuk, hogy eddig hányan vándoroltak el (churnöltek) például: (K)
Random mintavételezésnél: K/N relatív gyakorisággal találunk churnölőt.
Praktikusan nézve az összes N db ügyfelet "megdolgozva" tudunk foglalkozni összes K darab churnölővel.
A cél az lenne, hogy nagyságrendileg kevesebb (<<N) rekorddal dolgozva (valószínűség szerint csökkenősorrendbe rakva őket, a legvalószínűbbekkel "TOP N" foglalkozva), tudjunk foglalkozni minél több churnölővel. Az elérhetetlen ideális lenne persze, hogy K darab ügyfelet kiválasztva, a halmaz lefedné az összes K darab churnölő ügyfelet.:o)
Másképp fogalmazva a cél az lenne, hogy a random relatív gyakoriságot mindenféle okos (adatbányászati módszerekkel) meg tudjuk növelni.
Például, ha van 10 db ügyfelünk, akikből 2 churnöl, akkor mondjuk 10% (=1 db ügyfél) "kézbevétele" után lehetőleg azonnal találjunk/tántorítsuk el churnölő szándékától legalább 1 db churnölőt. Azaz 2/10=0.2 relatív gyakoriság helyett dolgozzunk mondjuk 100%-os (ötszörözött) hatékonysággal.
Na erről szól az osztályozásban/előrejelzésben a LIFT.
Csináltam egy végtelenül leegyszerűsített (túlbutított?) demót a szemléletéshez, Clementine-nal
Van a S(=source=magyarázó, prediktor) mező és van a T(=target, cél) mező.
10 rekordot vettem fel. Akikből ketten churnölnek.
Logisztikus regresszióval modelleztem
Az egyszerűsítés jegyében saját magára mértem vissza az adathalmazt (ilyet ugye tudjuk, hogy nem szabad csinálni a való életben).
A két churnölőt 1-es valószínűséggel egy churnölőt tévesen, de csak 0.875-ös valószínűséggel találtam meg a modellezés során.
Összefoglalva:
True Positive: 2 db
True Negatíve: 7 db
False Positive: 1 db
False Negatíve: 0 db
Mindösszesen: 10 db.
Képlet:
Ahol
p a valószínűség szerint csökkenőbe rendezett felső (=TOP) mondjuk k=5-10-20-30% rekordban talált valószínűség
h(=hit, azaz találat), adott előfordulásra volt-e találat (1) vagy nem (0)
LIFT-kiértékelés (churnarány görbe)
20%-nál
Számlálóban: tehát kettő jó találat van (1-es valószínűséggel) a háromból(=0.6666)
Nevezőben: 2 churnölő van a 10 ügyfél közül (=0.2)
0.6666/0.2=0.3333=3.3-as LIFT
Feltéve, hogy jól számoltam. ;)
Mivel 2 jó találat van (1-es valószínűséggel) 3-ból, ezért 66% a "csúcs-ugrás", már úgy értve, hogy a legkevesebből.
RESPONSE-kiértékelés
TOP 20%-ban a 100%-nyi churnölőt találtunk.
PROFIT-kiértékelés
TOP 20%-ban a 100%-nyi churnölőt találtunk, TOP10%-ban csak fele annyit.
ROI-kiértékelés (Return of Investment)
100% kiértékelése után az 1 révedés miatt 33%-nyi veszteségünk volt.
Ott tartunk tehát, hogy 20%-nyi churnölőnél:
- az "elérhetetlen" elméleti maximum LIFT az 5(=1/5 reciproka)
- mi nem kis csalással elértünk 3.3-as LIFT-et, 20%-nál.
Összefoglalva, ami fontos az osztályozós/predikciós LIFT-nél:
-A LIFT egy metrika, másképp szólva - esetünkben osztályozás/prediktálós típusú - adatbányászati modellezés minőség(biztosítás)i mutatója.
-Bináris célváltozó kell, azaz churn, response, etc. (elvándorol, nem vándorol – válaszol, nem válaszol – stb.). A multinomiális osztályozás könnyedén visszavezethető bináris esetre (adott osztálynak tagja-e vagy sem).
-A nevezőben a véletlen kiválasztás relatív gyakorisága k/n, vagyis k db churn osztva n db összes rekorddal.
-A számlálóban van a top x darab rekord, ahol jóval többet kell találni mint véletlen mintavételezésnél.
-Így jön ki hogy hányszoros a lift a véletlenes mintavételezéshez képest.
LIFT FAQ/GYÍK
Miért preferálja az üzleti élet a LIFT-mutatót, szemben a matematikusok, adatbányász verseny kiírók - például - AUC-ával szemben (=Area Under Curve, görbe alatti terület)?
Nekem erre két észrevételem van. Egy rosszmájú ;) és egy jóindulatú.
(1) Egy marketinges mindig jobban szereti azt mondani, hogy mondjuk kétszer akkora a hatékonyságnövelés, mint azt, hogy 10%-kal több. Egész egyszerűen jobban hangzik. ;)
(2) A matematikusban fel sem merül, hogy az összes vizsgált (akár milliós darabszámú) rekordot "kézbevegye", hacsak nem mazoista. Az üzleti életben meg pont azon van a fókusz, hogy például az ügyfelekkel foglalkozni kell. Na most, ha mindenkivel nem is lehet a gigantikus mennyiség okán, akkor legalább fontossági sorrendet érdemes felállítani köztük (minél kevesebből minél nagyobb eredményt elérni).
Hányszoros LIFT-et szeret az üzleti megrendelő, aminél elégedett? Minimálisan mennyi az elfogadható LIFT, amiért már ki is fizetik a beszállítót?
Az elméleti LIFT elérése a vágyak kategóriája. 2-szeres LIFT elérését már ki szokták fizetni tapasztalat szerint Magyarországon. Ha ennél (jóval) kisebb a LIFT, akkor az a mondás, hogy nincs elég magyarázó erő az elvégzett adatbányászati modellezésben. Aminek oka lehet az adatok belső összefüggéseiben (például DQM=adatminőségi), de lehet ok az elégtelen modellezés is. Mindez vezethet "érdekes" beszélgetésekhez üzleti megrendelő és adatbányászos beszállító között. ;)
Kérdés: van-e erről a 2-szeres elfogadható minimum LIFT-ről érdemi referencia a neten, hogy ne "bemondásra" kelljen elfogadni?! Próbáltam keresni ilyen hivatalos referenciát is a minimálisan elfogadható LIFT-re, de nem igazán jártam sikerrel. Még ez a legelfogadhatóbb, ahol a példában 1.875-ös LIFT-et adnak meg, ami még az általam említett 2-nél is kevesebb, azaz én "szigorúbb" voltam. ;)
Triviális (elméleti) LIFT-növelés?!
Üzleti életben egy "churn" távolról sem triviális fogalom. Nem mindegy, hogy kit tekintünk pontosan, egzaktan, teljeskörű konszenzus mentén, churnölő ügyfélnek. Egyáltalán hogyan képződik le pontosan az üzleti fogalom a churn-mező mappelése során.
Az fixálható felső határként, hogy a teljes halmaz maximum fele lehet churnölő. Ha több, akkor azt érdemes előrejelezni, hogy ki marad. :o) Alsó határként meg az lenne az ideális, hogy akkora legyen a beazonosított churnölő ügyfélkör amekkorával van kapacitás foglalkozni vállalaton belül.
Emiatt aztán előfordulhat egy érdekes mellékhatás, nevezetesen az adatbányászati modellezés során kisebb lesz a teljes részhalmazon belül a churnölők részhalmaza. Ez aztán automatikusan megnöveli tehát az elérhető elméleti LIFT-maximumot, és gyakorlati értelemben is könnyebb lehet magasabb (és látványosabb) LIFT-et elérni.
Magam részéről hangsúlyozni szoktam, hogy a fenti mellékhatás az tényleg csak mellékhatás, nem pedig klasszikus optimalizálási cél, churn-rekordszám csökkentése vonatkozásában. A mellékhatás eröltetett fókuszba helyezése nem lehet kívánatos cél, bármennyire csábító. Modell-jóságra kell törekedni, nem pedig adott esetben hamis látványra.
Lehet-e a modellezés tényleges elvégzése elött valahogy "előreszámolni" a LIFT-et?
Sajnos jelen tudásom/tudásunk szerint (?), előre megrendelési, tendereztetési fázisban még csak közelítőleg sem lehet érdemi véleményt arról mondani, hogy mennyi idő- és energiaráfordítással, mennyi az elérhető LIFT.
Ha tehát például 10-szeres az elméleti maximum LIFT és a 2-szeres LIFT-et már elfogadottnak tekintjük, akkor mondhatjuk, hogy 2-10-szeres LIFT-pálya, sikeres adatbányászati modellezésnél. Ilyet azonban eléggé veszélyes mondani, mert az üzleti megrendelő lelki szemei elött megjelenik,hogy akkor majd 9-9.5-szeres LIFT-et megcélozzuk. Holott a gyakorlat szerint nagyon sokszor örülni kell a 2-3-szoros LIFT-nek is, abban is lehet óriási pénzügyi profit-potenciál.
Mi van a "kedvenc" NULL-unkkal?
A prediktálás során a célváltozó felveheti ugye a köztudott 0,1 értékeket, de lehet NULL is. RDBMS-világban a NULL nem érték, hanem - undefinit - állapot. Hogyan befolyásolja ez a NULL-ozás túlózás a LIFT-számolást? Ennek kifejtését meghagynám másoknak. Én beérem ebben a pillanatban egy kardinális állítással, aminek bizonyítását mindenkinek magának kell megejtenie:
Jó modellezés nem vezethet NULL célváltozóhoz, egyetlen rekordnál sem.
Tessék jól adatbányászkodni és akkor nincs probléma NULL-ok miatti LIFT-számolással!
Mindezt azért mondom, mert nekem például sikerült már beleszaladnom a problematikába, nem kis fejfájást okozva. ;)
2012. július 14., szombat
Társkeresés adatbányászati támogatással
.
Dr.Helen Fisher antropológust érintő posztjaimban már adtam tanubizonyságát, hogy mennyire izgatnak a társkeresés módszertani kérdései. Annál is inkább, mert érző emberi lényként is, adatbányászként is izgalmasnak találom a témát.
Itt az alábbiakban egy v0.0.0.1ß initial draft verzióban megpróbálom körbejárni a témát "domain-centrikusan", úgy ahogy első nekifutásra eszembe jutott, amit egy blogposzt keretei megengednek. Kéretik elnézni az esetleges hibákat, pontatlanságokat. Esetleg konstruktív hozzászólásokkal javítani a minőségén. ;)
NÉMI ELMÉLETI HÁTTÉR:
A párválasztás elsősorban szellemi-lelki-testi/fizikai, tehát „emberi” és nem „tudományos” téma, amit roppant nehéz mérni, egzaktan „materialistán” megközelíteni. Nem véletlen, hiszen a perdöntő első benyomás az „első szerelem”-hez kötődik gondolkodásunkban, nem pedig a hideg racionális számításhoz, ahol úgy érezzük a művészetnek van maximum érvényessége leginkább megszólalnia, semmint a tudománynak. Ebből azonnal következik, hogy a tudománynak nem lehet célja például a szerelem hőfokának valós számra való leképezése, ami metódust egyébként az adatbányászok oly nagyon szeretnek. :o) Mégis lehet ígéretes terep a témában még a tudomány (azon belül adatbányászat) számára is: például a hasonlóságok elemzése.
Ha absztrahálunk, akkor a problématérben egy társkereső
(1) rendelkezik preferenciákkal (potenciális társat illetően), illetve
(2) rendelkezik lehetőségekkel (adottság, környezet).
Az angol terminológia hangzásilag éredekes módon egybecsengő „meeting” és „mating”-gel jelzi a megkülönböztetésüket.
A társválasztási preferenciák két nagy csoportba sorolhatók, két elmélet mentén:
(1) Hasonlóság keresése a másikban (kulturális megközelítésnél).
Vonzalomelmélet. Kulcsmomentumok: „suba a subával, guba a gubával”, homogámia és homofília.
Az idevágó hasonlósági törekvéseket érdemes firtatnia egy adatbányászati (társ-)ajánlórendszernek
(2) A legjobb tulajdonságok keresése a másikban (társadalmi-gazdasági megközelítésnél).
Csereelmélet. Kulcsmomentumok:, „tulajdonság-, faktorpiac”.
A preferenciális csereelmélet (pl.: jövedelem) érvényesítési terepe továbbra is a hagyományos "egzakt" keresés.
Csak erős idegzetűeknek egy kifejtés: az elmélet szerint az emberek hasznok és költségek alapján alakítják ki, illetve szakítják meg kapcsolataikat: azokkal alakítanak ki kapcsolatot, akik a legnagyobb hasznot biztosítják, és a legkisebb költséget okozzák. Ha nincs megfelelő kapcsolat, egy szükséges különbség-küszöbre, akkor marad egyedül az ember. Minél magasabb a jutalmak és költségek különbsége az egyén referencia szintjéhez képest, annál kielégítõbb a kapcsolat. Ha egy potenciális alternatív kapcsolatban nagyobb a különbség, mint az aktuális kapcsolatban, akkor az egyén az aktuális kapcsolatból átlép az alternatívba. Az egyének a legmagasabb értékû társat keresik, annak alapján, hogy minden embernek van egy hozzávetõleges piaci értéke, annak arányában, hogy milyen mértékben rendelkezik elõnyös tulajdonságokkal (szépség, az intelligencia, a báj, a vagyon, és a társadalmi státusz). A rendszer úgy nyeri el stabilitását, hogy a közelítõleg egyenlõ értéket birtokló egyének egymásra találnak.
A reménység szerint nem „brittudós” kutatók számtalan vizsgálat után azt vélik, hogy társkeresésnél:
(1) Az emberek hosszú távú kapcsolataik során elsősorban
(a) „magukhoz hasonló megjelenés”-t keresik a másikban (homogámia) – például a fenotípusos illesztés specifikus idegrendszeri mechanizmusával - illetve
(b) „miben hasonlítanak” (homofília) jegyében választanak
(2) A homogám párválasztási preferenciák kialakulásában tanulási folyamatok is részt vesznek, nevezetesen imprinting jellegű mechanizmusok. A gyerekkori tapasztalatok hatására például a fiúk internalizálják anyjuk fenotípusát, és ezt, mint egyfajta mentális modellt, használják fel későbbi párválasztásuk során. Hasonlóság figyelhető meg ellentétes nemű szülő és partner között, sőt a hasonlóság erőssége korrelál a gyerekkori szülővel való érzelmi kapcsolat szorosságával, a pozitív tapasztalokkal.
(3) De az említett korreláció megfigyelhető még a személyiség jegyek Big Five skáláin is mérve.
(a) Extroverzió (kifelé fordulás: társaságkereső, aktívkodó, önérvényesítő, szeretetközpontú, élménykereső, pozitív érzelmeket hajtó formákban)
(b) Neuroticitás (emocionális stabilitás/labilitás)
(c) Együttműködés
(d) Lelkiismeretesség
(e) Nyitottság
(4) Arcmetrikai mérések - azaz az arc egyes méreteinek, arányainak vizsgálatai - közvetlen adatokat szolgáltatnak arról, hogy a partner – ellentétes nemű szülő közötti hasonlóságok ténylegesen fennállnak az arc bizonyos területein. Úgy látszik, hogy a nők elsősorban apjuk középső arcterületeit modellezik, a férfiak pedig az anyjuk arcának alsó részéről származó jellegzetességeket használják fel a mintavételre.
Minél igazabbak a fentiek, annál inkább kincsesbánya a terep az adatbányásznak. :o)
Szociálpszichológusok vizsgálatai ha valakivel gyakrabban találkozunk, azt jobban kedveljük, azaz a közelség vonzalom kialakulásához vezet. Van olyan konkrét megfigyelés is, hogy egy egyetemi kollégiumban a barátságok kialakulásának legjobb magyarázó tényezõje az volt, hogy milyen távol helyezkedtek el a szobák az épületben. Sőt a helyzet sokkal durvább. Az a sejtés, hogy ha több kapcsolatot alakítunk ki azokkal, akikkel gyakrabban találkozunk („közelség szindróma”), akkor, ha gyakrabban találkozunk olyanokkal, akik tõlünk valamilyen tekintetben különböznek, gyakoribbak lesznek a tõlünk különbözõekkel kialakított (heterogén) kapcsolataink. Azaz a „közelség” felülírja a „homogenitást”. Azaz érdemes lehet törekedni a „közelség” implementálására, ha a homogenitásra törekvés már túl nagy korlátokat emel.
A társkeresés algoritmusokkal való támogatása interdiszciplináris tudomány:
(1) Szociológia
(2) Pszichológia
(3) Kvalitatív („piac”)kutatás
(4) Adatbányászat (mesterséges intelligencia).
...határmezsgyéin.
GYAKORLAT
Külföldi minták számítógéppel támogatott társkeresésre:
* Parship
* Chemistry.com
* Match Affinity
* eHarmony
etc.
Kiindulás (az elméleti összfoglalás konklúziója nyomán)
(1) Hasonlóság(arc-, vélemény-, stb.) keresésére redukálódik a fókusz (mind köznapi, mind adatbányász értelmezésben), a piaci csereelmélet teljes ignorálásával.
(2) Invariáns, hogy egy társkereső mennyire népszerű az ellenkező nem körében. A lényeg, hogy ne a gyors/azonnali/kézreeső társkereső-választ keresse, hanem a fókusza a leghozzáillőbb megtalálásán legyen. Az a lényeg, hogy ha minél több a (hozzáillő társat komolyan kereső) felhasználó, annál reálisabb énképet tud adni a lehetőségekről és korlátokról az egyénnek, felesleges évek elvesztegetése nélkül.
(3) Az absztrakt értelemben vett "közelséget" (annak érzetének kialakulását) meg kell próbálni támogatni, valóságot minél jobban közelitő módon. Vö.: otthonosság komfortérzete.
(4) Mélyebben kell megérteni a vonzalmat és szabályait ("rules of attraction") a gyakorlati alkalmazhatósághoz.
(5) Az igazmondó és a hazudós jelöltekből is ki kell tudni préselni az igazságot. Inkább kevesebb, de megbízható legyen az információ. Rossz alapadatok, rossz következtetésre vezetnek.
Cél nem az, hogy az társ-ajánlórendszer minél többet ajánljon és az előfizető ezáltal minél többet perkáljon, hanem pont ellenkezőleg:
(1) minél kevesebbet ajánlani (rögtön elsőre a legmegfelelőbbet)
(2) minél inkább a társkeresők álmait megközelítően
(3) mindenki sikeresen találja meg az élete párját (már aki keres a rendszerben, mert még nincs neki), hogy éljen boldog párkapcsolatban, és ne maradjon társ nélküli előfizető a rendszerben
Scope:
Az algoritmusok által ajánlott párjelöltek kontaktus-felvétele pl.: e-mail cím cseréjével. A többit (randevú megszervezésével kezdve) oldja meg az élet vagy más.
Párválasztás sikeressége:
(1) A pár tagjai ugyanabban az időintervallumban gondolkozzanak (egyéjszakás,alkalmi,ásó-kapa-nagyharang)
(2) A pár ugyanazt keresse (levelezőpartner,barát,lelkitárs,tartós-együttjárás,élettárs,házasság)
(3) A felek pozitívan ítéljék meg.
Adatbányászati támogatás előnyei:
(01) Mindenki elvben 3.5 milliárd párjelöltből válogat, ami nagyon sok. Ha valaki komolyan veszi a nagy szerelem, az igazi társ keresését, annak minden lehetőség effektív kipróbálása, óriási szellemi-, lelki-, mentális próbatétel lehet, míg másik oldalról minden egyes kudarc meg károsan torzító. A tehermentesítés tehát potenciális előnnyel kecsegtet.
(02) Azoknak előnyös, akik mélyebb azonosságra („rokonlélekre”) vágynak. Társválasztás önmagában óriási kihívás, rengeteg buktatóval. Érdemes lehet fókuszálni nem (csak) triviális random lehetőségre, hanem a hatékonyságot növelve eleve már az indulásnál az ígéretesebb párjelölti halmazokban is keresni. Ezek a halmazok viszont semennyire nem behatárolhatók a hagyományos társkeresésnél.
(03) A nagy szerelem („álompár”), vonzalom alapján jöhet könnyebben, amit viszont a preferenciális keresés támogat kevésbé.
(04) A több információ nagyobb pontossághoz konvergál. Minél több minden tudható egy jelöltről, annál tévedhetetlenebbül lehet róla nyilatkozni (őszinteség,koherencia aspektusokban): Pár darab - pláne önbevalláson alapulú és/vagy közhelyes - preferencia/motivációból ezt nem igazán lehet megbízhatóan felderítenie senkinek. Köznapain szólva minél többet kell beszéltetni a másikat. A jelöltről az objektíven megtudható információk, az aktivitásai, véleményei beszélnek legpontosabban (mennyiséggel arányosan pontosabban).
(05) Elemi ésszel is beláthatóan a hasonlóság-elemzés hatalmas és kiaknázatlan terep a hagyományos keresési metódusokban, méretei, nehézségei, komplexitása miatt.
(06) Heterogénebb környezet potenciálisan „kalandosabb” kihívásai, „kísértései”, például akár a homogámia kontextusában is.
(07) Önbeteljesítés (párválasztás sikerességének) potenciális lehetősége
(08) Potenciálisan felesleges előítéletek jobb ignorálhatósága: „tudatlanság” -> „kedvező kép”-pé kiegészítés irányába való elmozdulása
(09) Az első lépések potenciális sutaságainak csökkentése
(10) Azonnal adódik párjelölteknek az első randevú potenciális témája :o)
Alapvető adatbányászati metódusuk ehhez:
(1) Látens szemantikus indexelés, rejtett, akár nem is magyarázható, faktorok általi összerendeléssel
(2) Más (pl.:Netflix) ajánlórendszerrek mintájára, azok a párkeresők akik hasonlóan ítélnek meg párjelölteket, potenciális párjelöltjeik az ő általuk legjobban kedveltek köréből kerüljenek ki.
(3) Társjelöltek távolság/közelség mérték minél használhatóbb definiálása, lehetőség szerint a priorizálást legjobban támogatva. (megfelelési-százalékkal, kizáró feltételek sértésének mérésével)
(4) Statikus preferenciák mérlegelését felváltó viselkedés/aktivitás megközelítésű dinamikus hálózatelemzés. Érdekes idevágó szakmai eredmény: Barabási és Albert [1999] kimutatta, hogy a perferenciális kapcsolódás (preferential attachment) mechanizmusa skálafüggetlen hálózatok kialakulásához vezet.
Adatbányászati támogatást implementáló társajánló honlap fontosabb ismérvei:
(01) Extenzíven sokan, minél többen legyenek rajta. Az algoritmusok nagyobb halmazokon pontosabban tudnak működni.
(02) Ne csak azok legyenek fenn rajta akik keresnek, hanem akik már megtalálták életük párját. Fontos mintát tudnak adni
(03) Intenzíven: minél részletesebb (nem pedig minél gyorsabb) legyen a párjelöltekről való információmegadás. Az algoritmusok nagyobb halmazokon pontosabban tudnak működni. Minél több az infó valakiről, annál könnyebb a koherencia/mellébeszélés kiderítése.
(04) Minél kevésbé támadható legyen, mindenfajta „megkerülések” által. Azaz a résztvevők minél jobban, minél automatikusabban tudjanak benne megbízni.Ehhez kell, hogy az igazmondóktól és a hazudósoktól is az igazságot lehessen megtudni a kérdezések, firtatások, tesztek során.
(05) Ösztönözzön az őszinteségre, szemben az okoskodó „hackeléssel”.
(06) Ösztönözzön a minél nagyobb részletezettségű információadásra (hiszen a "több" "pontosabb " eredményre vezethet hosszabb távon). Aki magáról/több sok infóval segíti a rendszert, annak nagyobb rálátása lehetne például a többi jelöltre (mindenkire aki ugyanannyit vagy kevesebbet adott meg magáról)
(07) Optimális mennyiségben se túl sokat, se túl keveset ne ajánljon, lehetőleg priorizálva, ahol a priorizálás a valóságot minél jobban közelíti, kezelve, hogy az álompárok kezdetben nem feltétlen kommutatív-jellegűek. Ha nem jön össze egy ajánlás, akkor a következő kört, lehet, hogy meg kell előzze egy finomhangolás (dinamikus iteráció keretében).
(08) Népszerűek ne legyenek túlterhelve ajálatokkal, kiegyensúlyozott ajánlásokkal. A „nincs”-et is vállalni kell hozzá.
(09) Humor és játék(osság) kísérje az egész folyamatot, mindenféle stresszet ignorálva.
(10) A társkereső felek - például képcsere - protokolljainak megfelelő idejű és jóminőségű kitalálása.
(11) Kevés induló felhasználónál is lehessen már a párosítás.
Szóbajöhető társkeresési (explicit) faktorok, elsőkörös gyűjtése
Egzakt faktorok
* Nemi irányultság (hetero-, bi-)
* Milyen távú kapcsolat kapcsolat keresése (alkalmitól, életreszóló egyetlenig)
* Városi-vidéki származási kategória
* Hely/távolság-tolerancia (azonos megye elég-e például)
* Életkor-intervallum
* Magasságlimit
* Súly, molett-sovány
* Végzettség
* Jövedelem
* Csillagjegy
* IQ (Raven-pontszám)
* Érzelmi intelligencia
* Szociális intelligencia (Guilford-féle SIT-teszt)
* Kreativitás (Torrance és Klein-Barkóczy)
* Dr. Helen Fisher kategorizálás (Fisher-Rich-Island Neurochemical Questionnaire (FRI-NQ) 56 kérdése)
* Mi a fontosabb a hasonló érdeklõdés vagy az egymást kiegészítõ szükségletek.
* Előbb a másik belső értékeinek felderítése avagy előbb a másik külsejét kell látni ismerkedésnél
* Hol lakik szívesen: nagyváros, külváros, hegy teteje
* Mi az első ösztönös kérdés egy ismerkedésnél: mivel foglalkozol, mire gondolsz, kit ismersz, mit érzel
* Mi dobbantja meg inkább a szívét, ha a másik: laza-energikus, lágy, hivatalos, magas-vékony
* Milyen földi élvezeteket szeret
* Inkább beszélni vagy inkább hallgatni szeret
* Politikai irányultság: magyar viszonyok között nagyon mérgező tud lenni a témabeli alapvetően különböző mentalitás
* Vallás beágyazodás iránya és mélysége, ~szokások
* Házassághoz való viszony (társkapcsolat kellékeként)
* Szabad idő együtt vs. magánélet a társkapcsolatban
Inegzakt, képlékeny faktorok
Faktorok, amiket közel lehetetlen összevethetően mérni:
* Fizikai vonzerő; első körben fényképre redukálva, legyen egész alakos, pontos készítési dátummal (aznapi újsággal?), hozzátartozóan, pontos születési dátum.
* Társadalmi státusz
* Tudás (esetleg párkereső által preferált témában fokozatosan nehezedő tesztek kitöltése)
* Humorérrzék mérése: esetleg szövegek, viccek, képek, filmrészletek alapján
* Hűség
* Családközpontúság, gyerekekhez hozzáálllás
* Kellemesség (agreeableness)
* Érdekesség
* Megbízhatóság
* Pontosság
* Dolgosság, munkamánia
* Romantika
* Extroverzió (kifelé fordulás: társaságkereső, aktívkodó, önérvényesítő, szeretetközpontú, élménykereső, pozitív érzelmeket hajtó formákban)
* Kifelé nyitottság, barátságosság
* Neuroticitás (emocionális stabilitás/labilitás)
* Együttműködés
* Tisztesség
* Lelkiismeretesség
* Társasági természet
Faktorok, amikre könnyebb direktben rákérdezni, könnyebben jön őszinte válasz, mert nincs "jó" válasz.
* Váratlanhoz, ismeretlenhez, ujdonság kereséséhez való viszony
* Óvatosság, kockázatvállalási hajlandóság
* Optimizmus
* Lelkesedés
* Nyugodtság
* Barátságosság
* Szabálykövetés
* Társaság-összetartás
* Határozottság
* Logikusság
* Versengés
* Bátorság
* Hálózatos gondolkodás
* Képzelőerő
* Altruista önzetlenség, nagylelkűség
* Érzelmi gazdagság
* Utazási affinitás
* Szélesebb általánosabb mélyebb specifikusabb érdeklődés
* Analitikus és szintetizáló gondolkodáshoz való viszony.
* Alkalmazkodás, öntörvényűség
* Hagyomány- , tekintélytisztelet
* Rendszeretet
* Energikusság
* Aprólékos tervezés
* Hideg fejjel gondolkodás
* Rugalmasság változtatásnál
* Empátia
* Ábrándozás
* Bohémség
* Dominancia, kalaphordási affinitás
* Konkliktuskezelésben mérlegszerep
* Vitatkozási affinitás, vita élvezete
* Művészetek iránti affinitás
* Mi kötelező elvárás
* Milyen az ideális másik
* Milyen áldozatra kész a nagy szerelem érdekében
* Milyen tehetségeket ad be a közösbe
* Gyakorlatiasság (főzés, barkácsolás)
* Szerelem első látásra létezik?
* Mennyire sok együttjárás egymás megismerésére, "kiértékeléséhez"?
* Létezik-e nagy szerelem, vagy másik végletként lényegében bárhol bármikor csak el kell kezdeni egymáshoz csiszolódni?
* Vélemények adott témában (zaj nélkül) és értékelése mi áll közel hozzá
Eddigi társkeresési blogposztjaim:
Társkeresés és adatbányászat témát érintő blogpostjaim:
Társkeresés adatbányász alapokon
Társkeresés - Numerátorok
Dr. Helen Fisher mint a szerelem "brittudósa"?
Dr. Helen Fisher kérdőíve társkereséshez
Dr. Helen Fisher - Zárszó
Társkeresés adatbányászati támogatással
Beszéd, mint a sikeres párkapcsolat prediktora?
COMMENT:COM: "Házasság első látásra"
Dr.Helen Fisher antropológust érintő posztjaimban már adtam tanubizonyságát, hogy mennyire izgatnak a társkeresés módszertani kérdései. Annál is inkább, mert érző emberi lényként is, adatbányászként is izgalmasnak találom a témát.
Itt az alábbiakban egy v0.0.0.1ß initial draft verzióban megpróbálom körbejárni a témát "domain-centrikusan", úgy ahogy első nekifutásra eszembe jutott, amit egy blogposzt keretei megengednek. Kéretik elnézni az esetleges hibákat, pontatlanságokat. Esetleg konstruktív hozzászólásokkal javítani a minőségén. ;)
NÉMI ELMÉLETI HÁTTÉR:
A párválasztás elsősorban szellemi-lelki-testi/fizikai, tehát „emberi” és nem „tudományos” téma, amit roppant nehéz mérni, egzaktan „materialistán” megközelíteni. Nem véletlen, hiszen a perdöntő első benyomás az „első szerelem”-hez kötődik gondolkodásunkban, nem pedig a hideg racionális számításhoz, ahol úgy érezzük a művészetnek van maximum érvényessége leginkább megszólalnia, semmint a tudománynak. Ebből azonnal következik, hogy a tudománynak nem lehet célja például a szerelem hőfokának valós számra való leképezése, ami metódust egyébként az adatbányászok oly nagyon szeretnek. :o) Mégis lehet ígéretes terep a témában még a tudomány (azon belül adatbányászat) számára is: például a hasonlóságok elemzése.
Ha absztrahálunk, akkor a problématérben egy társkereső
(1) rendelkezik preferenciákkal (potenciális társat illetően), illetve
(2) rendelkezik lehetőségekkel (adottság, környezet).
Az angol terminológia hangzásilag éredekes módon egybecsengő „meeting” és „mating”-gel jelzi a megkülönböztetésüket.
A társválasztási preferenciák két nagy csoportba sorolhatók, két elmélet mentén:
(1) Hasonlóság keresése a másikban (kulturális megközelítésnél).
Vonzalomelmélet. Kulcsmomentumok: „suba a subával, guba a gubával”, homogámia és homofília.
Az idevágó hasonlósági törekvéseket érdemes firtatnia egy adatbányászati (társ-)ajánlórendszernek
(2) A legjobb tulajdonságok keresése a másikban (társadalmi-gazdasági megközelítésnél).
Csereelmélet. Kulcsmomentumok:, „tulajdonság-, faktorpiac”.
A preferenciális csereelmélet (pl.: jövedelem) érvényesítési terepe továbbra is a hagyományos "egzakt" keresés.
Csak erős idegzetűeknek egy kifejtés: az elmélet szerint az emberek hasznok és költségek alapján alakítják ki, illetve szakítják meg kapcsolataikat: azokkal alakítanak ki kapcsolatot, akik a legnagyobb hasznot biztosítják, és a legkisebb költséget okozzák. Ha nincs megfelelő kapcsolat, egy szükséges különbség-küszöbre, akkor marad egyedül az ember. Minél magasabb a jutalmak és költségek különbsége az egyén referencia szintjéhez képest, annál kielégítõbb a kapcsolat. Ha egy potenciális alternatív kapcsolatban nagyobb a különbség, mint az aktuális kapcsolatban, akkor az egyén az aktuális kapcsolatból átlép az alternatívba. Az egyének a legmagasabb értékû társat keresik, annak alapján, hogy minden embernek van egy hozzávetõleges piaci értéke, annak arányában, hogy milyen mértékben rendelkezik elõnyös tulajdonságokkal (szépség, az intelligencia, a báj, a vagyon, és a társadalmi státusz). A rendszer úgy nyeri el stabilitását, hogy a közelítõleg egyenlõ értéket birtokló egyének egymásra találnak.
A reménység szerint nem „brittudós” kutatók számtalan vizsgálat után azt vélik, hogy társkeresésnél:
(1) Az emberek hosszú távú kapcsolataik során elsősorban
(a) „magukhoz hasonló megjelenés”-t keresik a másikban (homogámia) – például a fenotípusos illesztés specifikus idegrendszeri mechanizmusával - illetve
(b) „miben hasonlítanak” (homofília) jegyében választanak
(2) A homogám párválasztási preferenciák kialakulásában tanulási folyamatok is részt vesznek, nevezetesen imprinting jellegű mechanizmusok. A gyerekkori tapasztalatok hatására például a fiúk internalizálják anyjuk fenotípusát, és ezt, mint egyfajta mentális modellt, használják fel későbbi párválasztásuk során. Hasonlóság figyelhető meg ellentétes nemű szülő és partner között, sőt a hasonlóság erőssége korrelál a gyerekkori szülővel való érzelmi kapcsolat szorosságával, a pozitív tapasztalokkal.
(3) De az említett korreláció megfigyelhető még a személyiség jegyek Big Five skáláin is mérve.
(a) Extroverzió (kifelé fordulás: társaságkereső, aktívkodó, önérvényesítő, szeretetközpontú, élménykereső, pozitív érzelmeket hajtó formákban)
(b) Neuroticitás (emocionális stabilitás/labilitás)
(c) Együttműködés
(d) Lelkiismeretesség
(e) Nyitottság
(4) Arcmetrikai mérések - azaz az arc egyes méreteinek, arányainak vizsgálatai - közvetlen adatokat szolgáltatnak arról, hogy a partner – ellentétes nemű szülő közötti hasonlóságok ténylegesen fennállnak az arc bizonyos területein. Úgy látszik, hogy a nők elsősorban apjuk középső arcterületeit modellezik, a férfiak pedig az anyjuk arcának alsó részéről származó jellegzetességeket használják fel a mintavételre.
Minél igazabbak a fentiek, annál inkább kincsesbánya a terep az adatbányásznak. :o)
Szociálpszichológusok vizsgálatai ha valakivel gyakrabban találkozunk, azt jobban kedveljük, azaz a közelség vonzalom kialakulásához vezet. Van olyan konkrét megfigyelés is, hogy egy egyetemi kollégiumban a barátságok kialakulásának legjobb magyarázó tényezõje az volt, hogy milyen távol helyezkedtek el a szobák az épületben. Sőt a helyzet sokkal durvább. Az a sejtés, hogy ha több kapcsolatot alakítunk ki azokkal, akikkel gyakrabban találkozunk („közelség szindróma”), akkor, ha gyakrabban találkozunk olyanokkal, akik tõlünk valamilyen tekintetben különböznek, gyakoribbak lesznek a tõlünk különbözõekkel kialakított (heterogén) kapcsolataink. Azaz a „közelség” felülírja a „homogenitást”. Azaz érdemes lehet törekedni a „közelség” implementálására, ha a homogenitásra törekvés már túl nagy korlátokat emel.
A társkeresés algoritmusokkal való támogatása interdiszciplináris tudomány:
(1) Szociológia
(2) Pszichológia
(3) Kvalitatív („piac”)kutatás
(4) Adatbányászat (mesterséges intelligencia).
...határmezsgyéin.
GYAKORLAT
Külföldi minták számítógéppel támogatott társkeresésre:
* Parship
* Chemistry.com
* Match Affinity
* eHarmony
etc.
Kiindulás (az elméleti összfoglalás konklúziója nyomán)
(1) Hasonlóság(arc-, vélemény-, stb.) keresésére redukálódik a fókusz (mind köznapi, mind adatbányász értelmezésben), a piaci csereelmélet teljes ignorálásával.
(2) Invariáns, hogy egy társkereső mennyire népszerű az ellenkező nem körében. A lényeg, hogy ne a gyors/azonnali/kézreeső társkereső-választ keresse, hanem a fókusza a leghozzáillőbb megtalálásán legyen. Az a lényeg, hogy ha minél több a (hozzáillő társat komolyan kereső) felhasználó, annál reálisabb énképet tud adni a lehetőségekről és korlátokról az egyénnek, felesleges évek elvesztegetése nélkül.
(3) Az absztrakt értelemben vett "közelséget" (annak érzetének kialakulását) meg kell próbálni támogatni, valóságot minél jobban közelitő módon. Vö.: otthonosság komfortérzete.
(4) Mélyebben kell megérteni a vonzalmat és szabályait ("rules of attraction") a gyakorlati alkalmazhatósághoz.
(5) Az igazmondó és a hazudós jelöltekből is ki kell tudni préselni az igazságot. Inkább kevesebb, de megbízható legyen az információ. Rossz alapadatok, rossz következtetésre vezetnek.
Cél nem az, hogy az társ-ajánlórendszer minél többet ajánljon és az előfizető ezáltal minél többet perkáljon, hanem pont ellenkezőleg:
(1) minél kevesebbet ajánlani (rögtön elsőre a legmegfelelőbbet)
(2) minél inkább a társkeresők álmait megközelítően
(3) mindenki sikeresen találja meg az élete párját (már aki keres a rendszerben, mert még nincs neki), hogy éljen boldog párkapcsolatban, és ne maradjon társ nélküli előfizető a rendszerben
Scope:
Az algoritmusok által ajánlott párjelöltek kontaktus-felvétele pl.: e-mail cím cseréjével. A többit (randevú megszervezésével kezdve) oldja meg az élet vagy más.
Párválasztás sikeressége:
(1) A pár tagjai ugyanabban az időintervallumban gondolkozzanak (egyéjszakás,alkalmi,ásó-kapa-nagyharang)
(2) A pár ugyanazt keresse (levelezőpartner,barát,lelkitárs,tartós-együttjárás,élettárs,házasság)
(3) A felek pozitívan ítéljék meg.
Adatbányászati támogatás előnyei:
(01) Mindenki elvben 3.5 milliárd párjelöltből válogat, ami nagyon sok. Ha valaki komolyan veszi a nagy szerelem, az igazi társ keresését, annak minden lehetőség effektív kipróbálása, óriási szellemi-, lelki-, mentális próbatétel lehet, míg másik oldalról minden egyes kudarc meg károsan torzító. A tehermentesítés tehát potenciális előnnyel kecsegtet.
(02) Azoknak előnyös, akik mélyebb azonosságra („rokonlélekre”) vágynak. Társválasztás önmagában óriási kihívás, rengeteg buktatóval. Érdemes lehet fókuszálni nem (csak) triviális random lehetőségre, hanem a hatékonyságot növelve eleve már az indulásnál az ígéretesebb párjelölti halmazokban is keresni. Ezek a halmazok viszont semennyire nem behatárolhatók a hagyományos társkeresésnél.
(03) A nagy szerelem („álompár”), vonzalom alapján jöhet könnyebben, amit viszont a preferenciális keresés támogat kevésbé.
(04) A több információ nagyobb pontossághoz konvergál. Minél több minden tudható egy jelöltről, annál tévedhetetlenebbül lehet róla nyilatkozni (őszinteség,koherencia aspektusokban): Pár darab - pláne önbevalláson alapulú és/vagy közhelyes - preferencia/motivációból ezt nem igazán lehet megbízhatóan felderítenie senkinek. Köznapain szólva minél többet kell beszéltetni a másikat. A jelöltről az objektíven megtudható információk, az aktivitásai, véleményei beszélnek legpontosabban (mennyiséggel arányosan pontosabban).
(05) Elemi ésszel is beláthatóan a hasonlóság-elemzés hatalmas és kiaknázatlan terep a hagyományos keresési metódusokban, méretei, nehézségei, komplexitása miatt.
(06) Heterogénebb környezet potenciálisan „kalandosabb” kihívásai, „kísértései”, például akár a homogámia kontextusában is.
(07) Önbeteljesítés (párválasztás sikerességének) potenciális lehetősége
(08) Potenciálisan felesleges előítéletek jobb ignorálhatósága: „tudatlanság” -> „kedvező kép”-pé kiegészítés irányába való elmozdulása
(09) Az első lépések potenciális sutaságainak csökkentése
(10) Azonnal adódik párjelölteknek az első randevú potenciális témája :o)
Alapvető adatbányászati metódusuk ehhez:
(1) Látens szemantikus indexelés, rejtett, akár nem is magyarázható, faktorok általi összerendeléssel
(2) Más (pl.:Netflix) ajánlórendszerrek mintájára, azok a párkeresők akik hasonlóan ítélnek meg párjelölteket, potenciális párjelöltjeik az ő általuk legjobban kedveltek köréből kerüljenek ki.
(3) Társjelöltek távolság/közelség mérték minél használhatóbb definiálása, lehetőség szerint a priorizálást legjobban támogatva. (megfelelési-százalékkal, kizáró feltételek sértésének mérésével)
(4) Statikus preferenciák mérlegelését felváltó viselkedés/aktivitás megközelítésű dinamikus hálózatelemzés. Érdekes idevágó szakmai eredmény: Barabási és Albert [1999] kimutatta, hogy a perferenciális kapcsolódás (preferential attachment) mechanizmusa skálafüggetlen hálózatok kialakulásához vezet.
Adatbányászati támogatást implementáló társajánló honlap fontosabb ismérvei:
(01) Extenzíven sokan, minél többen legyenek rajta. Az algoritmusok nagyobb halmazokon pontosabban tudnak működni.
(02) Ne csak azok legyenek fenn rajta akik keresnek, hanem akik már megtalálták életük párját. Fontos mintát tudnak adni
(03) Intenzíven: minél részletesebb (nem pedig minél gyorsabb) legyen a párjelöltekről való információmegadás. Az algoritmusok nagyobb halmazokon pontosabban tudnak működni. Minél több az infó valakiről, annál könnyebb a koherencia/mellébeszélés kiderítése.
(04) Minél kevésbé támadható legyen, mindenfajta „megkerülések” által. Azaz a résztvevők minél jobban, minél automatikusabban tudjanak benne megbízni.Ehhez kell, hogy az igazmondóktól és a hazudósoktól is az igazságot lehessen megtudni a kérdezések, firtatások, tesztek során.
(05) Ösztönözzön az őszinteségre, szemben az okoskodó „hackeléssel”.
(06) Ösztönözzön a minél nagyobb részletezettségű információadásra (hiszen a "több" "pontosabb " eredményre vezethet hosszabb távon). Aki magáról/több sok infóval segíti a rendszert, annak nagyobb rálátása lehetne például a többi jelöltre (mindenkire aki ugyanannyit vagy kevesebbet adott meg magáról)
(07) Optimális mennyiségben se túl sokat, se túl keveset ne ajánljon, lehetőleg priorizálva, ahol a priorizálás a valóságot minél jobban közelíti, kezelve, hogy az álompárok kezdetben nem feltétlen kommutatív-jellegűek. Ha nem jön össze egy ajánlás, akkor a következő kört, lehet, hogy meg kell előzze egy finomhangolás (dinamikus iteráció keretében).
(08) Népszerűek ne legyenek túlterhelve ajálatokkal, kiegyensúlyozott ajánlásokkal. A „nincs”-et is vállalni kell hozzá.
(09) Humor és játék(osság) kísérje az egész folyamatot, mindenféle stresszet ignorálva.
(10) A társkereső felek - például képcsere - protokolljainak megfelelő idejű és jóminőségű kitalálása.
(11) Kevés induló felhasználónál is lehessen már a párosítás.
Szóbajöhető társkeresési (explicit) faktorok, elsőkörös gyűjtése
Egzakt faktorok
* Nemi irányultság (hetero-, bi-)
* Milyen távú kapcsolat kapcsolat keresése (alkalmitól, életreszóló egyetlenig)
* Városi-vidéki származási kategória
* Hely/távolság-tolerancia (azonos megye elég-e például)
* Életkor-intervallum
* Magasságlimit
* Súly, molett-sovány
* Végzettség
* Jövedelem
* Csillagjegy
* IQ (Raven-pontszám)
* Érzelmi intelligencia
* Szociális intelligencia (Guilford-féle SIT-teszt)
* Kreativitás (Torrance és Klein-Barkóczy)
* Dr. Helen Fisher kategorizálás (Fisher-Rich-Island Neurochemical Questionnaire (FRI-NQ) 56 kérdése)
* Mi a fontosabb a hasonló érdeklõdés vagy az egymást kiegészítõ szükségletek.
* Előbb a másik belső értékeinek felderítése avagy előbb a másik külsejét kell látni ismerkedésnél
* Hol lakik szívesen: nagyváros, külváros, hegy teteje
* Mi az első ösztönös kérdés egy ismerkedésnél: mivel foglalkozol, mire gondolsz, kit ismersz, mit érzel
* Mi dobbantja meg inkább a szívét, ha a másik: laza-energikus, lágy, hivatalos, magas-vékony
* Milyen földi élvezeteket szeret
* Inkább beszélni vagy inkább hallgatni szeret
* Politikai irányultság: magyar viszonyok között nagyon mérgező tud lenni a témabeli alapvetően különböző mentalitás
* Vallás beágyazodás iránya és mélysége, ~szokások
* Házassághoz való viszony (társkapcsolat kellékeként)
* Szabad idő együtt vs. magánélet a társkapcsolatban
Inegzakt, képlékeny faktorok
Faktorok, amiket közel lehetetlen összevethetően mérni:
* Fizikai vonzerő; első körben fényképre redukálva, legyen egész alakos, pontos készítési dátummal (aznapi újsággal?), hozzátartozóan, pontos születési dátum.
* Társadalmi státusz
* Tudás (esetleg párkereső által preferált témában fokozatosan nehezedő tesztek kitöltése)
* Humorérrzék mérése: esetleg szövegek, viccek, képek, filmrészletek alapján
* Hűség
* Családközpontúság, gyerekekhez hozzáálllás
* Kellemesség (agreeableness)
* Érdekesség
* Megbízhatóság
* Pontosság
* Dolgosság, munkamánia
* Romantika
* Extroverzió (kifelé fordulás: társaságkereső, aktívkodó, önérvényesítő, szeretetközpontú, élménykereső, pozitív érzelmeket hajtó formákban)
* Kifelé nyitottság, barátságosság
* Neuroticitás (emocionális stabilitás/labilitás)
* Együttműködés
* Tisztesség
* Lelkiismeretesség
* Társasági természet
Faktorok, amikre könnyebb direktben rákérdezni, könnyebben jön őszinte válasz, mert nincs "jó" válasz.
* Váratlanhoz, ismeretlenhez, ujdonság kereséséhez való viszony
* Óvatosság, kockázatvállalási hajlandóság
* Optimizmus
* Lelkesedés
* Nyugodtság
* Barátságosság
* Szabálykövetés
* Társaság-összetartás
* Határozottság
* Logikusság
* Versengés
* Bátorság
* Hálózatos gondolkodás
* Képzelőerő
* Altruista önzetlenség, nagylelkűség
* Érzelmi gazdagság
* Utazási affinitás
* Szélesebb általánosabb mélyebb specifikusabb érdeklődés
* Analitikus és szintetizáló gondolkodáshoz való viszony.
* Alkalmazkodás, öntörvényűség
* Hagyomány- , tekintélytisztelet
* Rendszeretet
* Energikusság
* Aprólékos tervezés
* Hideg fejjel gondolkodás
* Rugalmasság változtatásnál
* Empátia
* Ábrándozás
* Bohémség
* Dominancia, kalaphordási affinitás
* Konkliktuskezelésben mérlegszerep
* Vitatkozási affinitás, vita élvezete
* Művészetek iránti affinitás
* Mi kötelező elvárás
* Milyen az ideális másik
* Milyen áldozatra kész a nagy szerelem érdekében
* Milyen tehetségeket ad be a közösbe
* Gyakorlatiasság (főzés, barkácsolás)
* Szerelem első látásra létezik?
* Mennyire sok együttjárás egymás megismerésére, "kiértékeléséhez"?
* Létezik-e nagy szerelem, vagy másik végletként lényegében bárhol bármikor csak el kell kezdeni egymáshoz csiszolódni?
* Vélemények adott témában (zaj nélkül) és értékelése mi áll közel hozzá
Eddigi társkeresési blogposztjaim:
Társkeresés és adatbányászat témát érintő blogpostjaim:
Társkeresés adatbányász alapokon
Társkeresés - Numerátorok
Dr. Helen Fisher mint a szerelem "brittudósa"?
Dr. Helen Fisher kérdőíve társkereséshez
Dr. Helen Fisher - Zárszó
Társkeresés adatbányászati támogatással
Beszéd, mint a sikeres párkapcsolat prediktora?
COMMENT:COM: "Házasság első látásra"
2012. július 6., péntek
IBM SPSS Modeler (Clementine) v15.0
.
Sajnos csak ma délelött vettem észre, hogy a tárgybeli nevezetes termék főverziószám-ugrásának rendezvényt szervezett a Clementine Consulting, így nem tudtam ott lenni, pedig nagyon szívesen elmentem volna a téma fontossága és érdekessége miatt. Így viszont, no meg kárpótlásul saját erőből mentem utána az ujdonságok "horderejének", a mai napot így is a témának szentelve.
Egy érdekes 22 oldalas bevezető:
IBM hivatalos sajtóanyag (angolul)
INSTALL-anyagok, kódokkal, méretekkel:
Csak Windows 32-bitre így néz ki a "byte-tömeg", ami ráadásul még a 64-bitre sem "szimmetrikus" (van ami 64-bites környezetben is csak 32 bites).
Dátum: 2011,június 17.
IBM SPSS Modeler Client 32-bit 14.2 Windows Multilingual (CI1C0ML) Size 1,055mb
IBM SPSS Text Analytics Client 32-bit 14.2 Windows Multilingual (CZZZ5ML) 503mb
Dátum: 2012,június 12.
IBM SPSS Modeler Client 32-bit 15.0 Microsoft Windows Multilingual (CI8Y7ML) Size 1,091mb
IBM SPSS Modeler Client Entity Analytics 32-bit 15.0 Microsoft Windows Multilingual (CI8Y5ML) Size 110mb
IBM SPSS Modeler Client Entity Analytics Unleashed 32-bit 15.0 Microsoft Windows Multilingual (CI8X7ML) Size 172mb
IBM SPSS Modeler Client Social Network Analysis 32-bit 15.0 Microsoft Windows Multilingual (CI8YAML) Size 107mb
IBM SPSS Text Analytics Client 32-bit 15.0 Microsoft Windows Multilingual (CI8Y8ML) Size 127mb
IBM SPSS Modeler Administration Console 32-bit 15.0 Microsoft Windows Multilingual (CI8YLML) Size 128mb
IBM SPSS Modeler Batch 32-bit 15.0 Microsoft Windows Multilingual (CI8YQML) Size 132mb
IBM SPSS Modeler Premium Batch 32-bit 15.0 Microsoft Windows Multilingual (CI8Z4ML) Size 92mb
IBM SPSS Modeler Server 32-bit 15.0 Microsoft Windows Multilingual (CI8YNML) Size 300mb
IBM SPSS Modeler Server Entity Analytics 32-bit 15.0 Microsoft Windows Multilingual (CI8ZZML) Size 104mb
IBM SPSS Modeler Server Entity Analytics Unleashed 32-bit 15.0 Microsoft Windows Multilingual (CI8YCML) Size 171mb
IBM SPSS Modeler Server Social Network Analysis 32-bit 15.0 Microsoft Windows Multilingual (CI8ZDML) Size 192mb
IBM SPSS Text Analytics Administration Console 32-bit 15.0 Microsoft Windows Multilingual (CI8ZQML) Size 113mb
IBM SPSS Text Analytics Server 32-bit 15.0 Microsoft Windows Multilingual (CI8ZFML) Size 69mb
IBM SPSS Modeler 15.0 Collaboration and Deployment Services Adapter 32-bit 4.2 (CI8WLML) Size 430mb
IBM SPSS Modeler 15.0 Collaboration and Deployment Services Adapter 32-bit 5 (CI8WNML) Size 444mb
IBM SPSS Modeler Premium 15.0 Collaboration and Deployment Services Adapter 32-bit (CI8ZNML) Size 241mb
IBM SPSS Data Access Pack 6.1 sp3 Multiplatform English (CI8X6EN) Size 878mb
IBM SPSS Data Access Pack for Salesforce.com 6.0 Windows English (CI07REN) Size 43mb
IBM SPSS Modeler Desktop Quick Start Guide 15.0 Multilingual (CI660ML) Size 0.5mb
IBM SPSS Modeler Client Documentation 15.0 Multilingual (CI8Y1ML) Size 348mb
IBM SPSS Modeler Client Premium Documentation 15.0 Multilingual (CI8Y6ML) Size 51mb
IBM SPSS Modeler Server Quick Start Guide 15.0 Multilingual (CI661ML) Size 0.5mb
IBM SPSS Modeler Server Premium Documentation 15.0 Multilingual (CI8Z3ML) Size 28mb
IBM SPSS Modeler Server Scoring Adapter 15.0 for Netezza Multiplatform Multilingual (CI8X4ML) Size 130mb
IBM SPSS Modeler Server Scoring Adapter 15.0 for Teradata Multiplatform Multilingual (CI8X5ML) Size 112mb
IBM SPSS Data Collection, Licensing Tool
32 & 64-bit
AIX, HP-UX, Linux, Linux for System z, Oracle Solaris, IBMi
Academic, Academic Campus, Faculty Author Pack
Japán nyelv külön.
Észrevételek:
Szinte napra pontosan egy év elteltével jött ki a 15.0 a 14.2-höz képest. Illetve az SPSS továbbra is tartja, hogy főverzión belül két alverzió van.
36MB, 3.4%-nyi az ujdonság a setup-anyagban. :DDDD. Ez fedi le a GLMM-et (General Linear Mixed Model) és a Graphboard fejlesztéseket az alap Clementine-ban.
- Az egyik friss ujdonság Entity Analytics-nek két verziója van egy normál 110 MB és egy "Unleashed" (póráz és korlátok nélküli) 172 MB.
- Az Unleashed ráépül a normálra, feltételezi annak meglétét és szerintem valami förtelmesen hulladék az install-anyaga. Van egy install exe-je jó mélyen elásva egy könyvtárstruktúrában és egy nála jóval nagyobb Resouce1 zip-anyag (felsőbb szinten) nem felhasználóbarát elnevezésű java-csomaggal, amit nem tudni hogy ki és hogyan használ fel. És akkor még nem beszéltem arról, hogy az ujdonságok installja mennyire teleszemeteli a kristálytisztán világos eddigi install-struktúrát.
- A normál verzió egyetlen repositoryt engedélyez, így ezt cégek maguknak tudják használni. Az "Unleashed" verzió meg korlátlan repository használatot enged meg, ami deduplikálásra szakosodott cégeknek jöhet jól (brute force első megközelítésben)
- És természetesen mindennek van szerver-kiegészítése is. ;)
- Az Entity Analytics pasw-s fejlesztés maradt az ext-könytár tanusága szerint. ;)
- Az Entity Analytics csak ext/bin-ben jelenik meg, ext/lib-ben nem. Már ha jól láttam. Furcsálltam is rendesen... ;)
- Az Entity Analytics install anyaga el van rontva, minden file ugyanazon a néven kétszer van benne. Kicsomagolásnál jön a menetrendszerű kérdés: felülírás kell-e.
- Szerencsére a másik friss ujdonság Social Network anyagnál már nincsenek ilyen hókamókák.
A Text Analytics install-anyaga rendesen lecsökkent 503 MB.ról 127 MB-ra. Okát nem láttam, igaz nagy erőfeszítést nem is tettem az ügyben.Azt feltételezem, hogy (angol) szótárak, adatbázisok okozzák a méretkülönbséget.
- Érdekes, hogy a Batch 132 MB, addig a Premium Batch csak 92 MB (hasonlatosan a Collaboration and Deployment Services-hez).
- Attól lenne "Premium", hogy ugyanazt a funkcionalitást kevesebb kódsorból hozták ki? :DDDD Persze valószínűleg arról van szó, hogy a "Premium" ráépül a "Professional"-re.
- Egyébként ezt a szoftvergyári termék-elágaztatást már nagyon nehezen tudja az ember értelmezni. ;)
Kétféle adatelérés van:
(1) Amikor a .sav Statistics belső állományformátumot akarjuk külső programból,például SQL-ből elérni.
(2) Amikor a Clementine heterogén módon különféle adatbázisokhoz akar csatlakozni. A jó hír, hogy ez jóminőségű (amúgy brutális árszabású) ODBC-drivereken keresztül szokott történni. A rossz hír, hogy ezek az ODBC-driverek csak SPSS-termékeken belül használhatók.
Download, sajnos link nélkül ;)
Documentation
- A dokumentációk önmagukért beszélnek. Azért az egy érdekes dolog szembesülni, hogy a "Premium" doksinak nem része az alap Clementine doksija. ;)
- Algorithms Guide 367 oldalról 404 oldalra hízott, GLMM-nek köszönhetően. Viszont sajnálatos módon sem az Entity Analytics, sem a Social Network algoritmusok leírását nem tartalmazza. Mire fel ez a nagy titokzatosság? A felhasználók fekete dobozra bízzák rá a feldolgozásaikat, korunk nagy "kifehérítési" követelménye közepette? ;)
- Modeling Nodes Guide 479-ről 508 oldalra hízott, szintén a GLMM-nek köszönhetően
- Applications Guide viszont sajnos maradt 404 oldalnak. Ami annak fényében visszás, hogy a GLMM egyáltalán nem önjáróan és kitalálhatóan triviális játék. Demo-stream sincs hozzá. :o((
- Született egy új 53 oldalas könyv a 15.0-ra: Deployment Guide
- Entity Analytics User Guide mindösszesen 75 oldal
- Social Network User Guide mindösszesen 37 oldal.
- Nem tűnnek tehát "rocket science"-nek a használatuk. ;) És hozzájuk legalább már van demó stream, még ha a dokumentálásuk kicsit zavaros is.
- CRISP-DM, a hivatalos fenti linkes helyről le sem tölthető, de 5 oldallal azért bővült. :o)
- A többi doksik vagy nem változtak vagy pár oldalt híztak csak.
Azért az milyen "kemény", hogy Scoring Adapter is létezik olyan egzotikus platformokon, mint Netezza és Teradata. Feltételezem olyan helyeken lesz érdeklődés irányukba, ahol a pénz nem számít. ;)
És akkor a kombinatórikus robbanás jegyében, jönnek a pluszok és duplázódások:
- IBM SPSS Data Collection, Licensing Tool
- 32 & 64-bit
- AIX, HP-UX, Linux, Linux for System z, Oracle Solaris, IBMi oprendszerek
- Academic, Academic Campus, Faculty Author Pack
- Japán nyelv. Külön.a nyelvnél speciális érdekesség, hogy a két ujdonság (Entity Analytics, Social Network) installja két nyelv között enged választást: angol és lengyel(!).
Szóval ember legyen a talpán, aki ebben a install-dzsugelben kiigazodik.
ÁRAK:
Clementine árak I - IBM Passport Advantage Express
Clementine árak II - IBM-től letölthető 119 oldalas pdf-ben
Clementine-árak III - Gemini eStore IBM SPSS Modeler Client Professional
Clementine-árak III - Gemini eStore IBM SPSS Modeler Client Premium
Clementine-árak III - Gemini eStore IBM SPSS Modeler Server Professional
Clementine-árak III - Gemini eStore IBM SPSS Modeler Server Premium
Clementine-árak III - Gemini eStore IBM SPSS Collaboration and Deployment Services
Örök kérdés, hogy az egyes az opciók...
(1) diszjunkt módon egymásra épülnek-e, azaz a "magasabb rendű" feltételezi maga alatt az "alacsonyabb rendü" meglétét, avagy
(2) minden termék zárt, kerek, önmagában megálló egész-e. Mindkét megközelítésnek megvan az előnye (modularitás vs egységesség).
Jelen esetben az (1) esettel van dolgunk telepítés szempontjából (ár szerint nyilván nem, pontosabban felemásan, lásd alább). A Client Professional-ra kell telepíteni a Premium illetve Server komponenseket.
Pár érdekesebb ár:
IBM SPSS Modeler Client Professional Authorized User Initial Fixed Term License $10,961.00
IBM SPSS Modeler Client Professional Authorized User License $25,026.00
IBM SPSS Modeler Client Professional Concurrent User Initial Fixed Term License $27,451.00
IBM SPSS Modeler Client Professional Concurrent User License $62,468.00
IBM SPSS Modeler Client Premium Authorized User License $39,964.00
IBM SPSS Modeler Server Professional Processor Value Unit (PVU) License $537.38
IBM SPSS Modeler Server Premium Processor Value Unit (PVU) License $661.54
Az IBM öntudatlanul is beismerve, milyen "szégyenletesen" sokat kér (hivatalos listaáron mindenképpen), ezért nem nagyon terjeszti boldog-boldogtalannak az árait. A Clementine Consulting is csak a Statisticsre közölt mindig is árakat, a Clementine-ra sose (az én tudomásom szerint).
Árazást tekintve a "Premium" önálló termék, magában foglalja a "Professional"-t. Míg a Server látnivalóan opció csak, hogy teljesen kusza legyen a kép. ;)
A "fixed term"időkorlátos, gondolom egy évig lehet használni, mert 12 hónap support jár azért hozzá. A korlátlan ideig használható verzió majdnem háromszor annyiba kerül.
Az "authorised user" licence-verziót dedikált ember használhatja, mint egy "könyvet" (azaz akár napközben a munkahelyén és este az otthonában is)
A "concurrent user" licence-verziót meg csak munkahelyen akárhányan, de egyidőben egyszerre csak a licence-ben engedélyezett mennyiségű felhasználó, feltételezem három(?).
A PVU-alapu licencelésről meg pikirten elmondható, hogy a "legfelhasználóbarátabb" licencelési és árazási stratégia. Élből 10-zel kell szorozni az árat. ;)
Érdekes még a Non-Production Enviroment korlátozás. Neten sem találtam róla semmi idevágó infót. Ha egy biztosító üzemeltet ilyet az minek számít? Production? Non-Production?
És akkor a lényegről. :o)
Régebben az volt a szokás, hogy főverzió váltásánál sok kis finom apróság (hibajavítások mellett) szereztek örömet a felhasználóknak a verzióváltás nyügének legyőzésére. Most meg pusztán négy nagyobb ujdonság van a "What's news"-ban
- GLMM node megjelenése
- Térképek megjelenítésének támogatása a Graphboard node-ban
- Entity Analytics és Social Network Analytics megjelenése de csak a "Premium" verzóban, hogy a szövegbányászat ne csak önmagában árválkodjon ott.
Lehet, hogy tévesen látom, de az SPSS nem akar versenybe a Wekával, RapidMinerrel, Knimével, Orange-dzsal, R-rel, funkcionalitás oldalról, úgy mint régebben a SAS-sal tette számomra oly szimpatikus módon. A Clementine Workbench mára már (ha nem egyenesen régóta) nagykorú lett, már most is nagyon jó dolgozni vele. Egy-két finomság nem éri meg a fejlesztést, nem fog felhasználói tömegeket vásárlásra, upgrade-re csábítani.
Érdekesebb apróbb ujdonságok:
- Stream zoomolás lehetősége, ikonméret állítással összhangban.
- Node-végrehajtási idő megjelenítése
- Stream paraméter megjelenése SQL-lekérdezéseknél.
- Expression Builder hívni tud "In-Database" függvényeket.
- Aggregate Node bővült aggregálási módokkal, SQL-funkcionalitással
- Merge Node bővült feltételfüggő merge-léssel
- Táblatömörítés Database Exportban.
- Bulk Loading Database Exportnál
"Futottak még" apróságok.
- Netezza-fejlesztések.
- Teradata-ban is Score Adapter, "Big Data" supportként eladva.
- IBM Warehause megjelenése az "In Database"-ben
- IBM Cognos BI node fukcionális bővülése
- In Database Model Scoring
- Default Database beállítások
- Stream Properties beállítások, optimalizálások újratervezése
- Batch módban új forma megjelenése Database Connectionnél
- SPSS Statistics intergráció bővülése
- Nem root-jogú user is installhat Unixon
- Deployálási funkcionalitás bővülése, három vonatkozásban is.
Látnivalóan kölcsönösen konvergál egymáshoz a Statistics valamint a Clementine, a funkcionalitás odalaláról.Mondjuk nem épp felhasználóbarát módon, egyetlen termékbe olvadóan, hanem a felhasználókat jobban megfejelő (párhuzamos) módon.
Ahogy én tudom az upgrade is nagyon drága szokott lenni SPSS-éknél (akár a kritikus három éven belül, akár három év után nézzük): sajnos ennek most nem volt módom utánamenni. Ennek tükrében a Statisticsben már létező (valamilyen) GLMM nem épp vonzó ajánlat az alap Clementine megjelenésében, míg a Graphboard (térképes megjelenítés), ugyan látványos, de kevés haszonnal kecsegtet hosszú távon azoknak akik pénzt akarnak kisajtolni a Clementine-ból.
- DeDuplikálásról pár éve még csak suttogtuk, hogy lényegében adatbányász feladat (full refreshnél csoportosítási, partial refreshnél osztályozási feladat). Mostanra bekerült a Clementine-ba, az Entity Analytics révén. :o)
- Érdekes a demója: arra mutat példát, hogy ügyfélkockázat számszerűsítésénél nem mindegy, hogy sikerül-e minden ügyfél-rekordverziót megtalálni. :o)
- Totális "black box" nem tudni mekkora méretre működik, milyen gyorsan, milyen találati eredményességi aránnyal, milyen nyelvi lokalizációs mehézségekkel küzd. Egy ausztrál dedup a nagyobb méretek mellett is könnyebb feladat, mint egy magyar (normál esetben). Ahogy a szövegbányászat is magyar kiegészítéssel együtt használható csak igazán jól.
- Totális "black box" azt is el tudja fedni, hogy a standaridizálás, adatgazdagítás nem úszható meg normális körülmények között.
- Érdekesség még, hogy a repository IBM SolidDB típusú.
Hálózatanalízis két analizismódot támogat.
(1) Hálózaton belül milyen csoportok képződnek. - G[roup] A[nalysis]
(2) Hogyan terjed hálózaton belül az információ (milyen utakat kell erősíteni avagy elszigetelni feladattól függően). - D[iffusion] A[nalysis]
Mindkét kapcsolódó demó Churn-témájú szintén ;)
- Térképes demó nem fut alapértelmezésben Windows7 alatt.
MSPROFILE\AppData\Roaming\SPSSInc\graphboard\maps alól a Documents and Settings djones usere alá kell másolni a *.SMZ file-okat.
- A GLMM első "m"-je (mixed) attól "kevert", hogy a regresszióanalizis van társítva benne a szórásanalízissel, mindkettő előnyeit kihasználhatóan. (Továbbá kvázi idősorokkal megspékelten, hiszen korrelált "repeated measure" mélyén ilyesmi van).
- Olyan (klasszikus) feladatokra kiváló, hogy diákokat három féle módszerrel tanítanak például lineáris egyenletrendeszerek megoldására, majd tesztelik őket azonos nehézségű feladatok révén, váltogatva a módszereket, hogy melyik módszerrel milyen gyorsan és jól oldják meg azokat. Kérdés lehet az is, hogy vajon a nem vagy a matematika szakkörbe-járás releváns faktorok-e.
- Az igazán döbbenetes és teszem hozzá nehéz az benne, hogy a független és függő változók között nemcsak eddig megszokott direkt kapcsolat lehet, hanem linkfüggvényen keresztüli is (amiből van egy pár), például a klasszikus logit (logisztikus regresszió).
- Mindenképpen érdemes a figyelemre a metódus, szvsz
Sajnos csak ma délelött vettem észre, hogy a tárgybeli nevezetes termék főverziószám-ugrásának rendezvényt szervezett a Clementine Consulting, így nem tudtam ott lenni, pedig nagyon szívesen elmentem volna a téma fontossága és érdekessége miatt. Így viszont, no meg kárpótlásul saját erőből mentem utána az ujdonságok "horderejének", a mai napot így is a témának szentelve.
Egy érdekes 22 oldalas bevezető:
IBM hivatalos sajtóanyag (angolul)
INSTALL-anyagok, kódokkal, méretekkel:
Csak Windows 32-bitre így néz ki a "byte-tömeg", ami ráadásul még a 64-bitre sem "szimmetrikus" (van ami 64-bites környezetben is csak 32 bites).
Dátum: 2011,június 17.
IBM SPSS Modeler Client 32-bit 14.2 Windows Multilingual (CI1C0ML) Size 1,055mb
IBM SPSS Text Analytics Client 32-bit 14.2 Windows Multilingual (CZZZ5ML) 503mb
Dátum: 2012,június 12.
IBM SPSS Modeler Client 32-bit 15.0 Microsoft Windows Multilingual (CI8Y7ML) Size 1,091mb
IBM SPSS Modeler Client Entity Analytics 32-bit 15.0 Microsoft Windows Multilingual (CI8Y5ML) Size 110mb
IBM SPSS Modeler Client Entity Analytics Unleashed 32-bit 15.0 Microsoft Windows Multilingual (CI8X7ML) Size 172mb
IBM SPSS Modeler Client Social Network Analysis 32-bit 15.0 Microsoft Windows Multilingual (CI8YAML) Size 107mb
IBM SPSS Text Analytics Client 32-bit 15.0 Microsoft Windows Multilingual (CI8Y8ML) Size 127mb
IBM SPSS Modeler Administration Console 32-bit 15.0 Microsoft Windows Multilingual (CI8YLML) Size 128mb
IBM SPSS Modeler Batch 32-bit 15.0 Microsoft Windows Multilingual (CI8YQML) Size 132mb
IBM SPSS Modeler Premium Batch 32-bit 15.0 Microsoft Windows Multilingual (CI8Z4ML) Size 92mb
IBM SPSS Modeler Server 32-bit 15.0 Microsoft Windows Multilingual (CI8YNML) Size 300mb
IBM SPSS Modeler Server Entity Analytics 32-bit 15.0 Microsoft Windows Multilingual (CI8ZZML) Size 104mb
IBM SPSS Modeler Server Entity Analytics Unleashed 32-bit 15.0 Microsoft Windows Multilingual (CI8YCML) Size 171mb
IBM SPSS Modeler Server Social Network Analysis 32-bit 15.0 Microsoft Windows Multilingual (CI8ZDML) Size 192mb
IBM SPSS Text Analytics Administration Console 32-bit 15.0 Microsoft Windows Multilingual (CI8ZQML) Size 113mb
IBM SPSS Text Analytics Server 32-bit 15.0 Microsoft Windows Multilingual (CI8ZFML) Size 69mb
IBM SPSS Modeler 15.0 Collaboration and Deployment Services Adapter 32-bit 4.2 (CI8WLML) Size 430mb
IBM SPSS Modeler 15.0 Collaboration and Deployment Services Adapter 32-bit 5 (CI8WNML) Size 444mb
IBM SPSS Modeler Premium 15.0 Collaboration and Deployment Services Adapter 32-bit (CI8ZNML) Size 241mb
IBM SPSS Data Access Pack 6.1 sp3 Multiplatform English (CI8X6EN) Size 878mb
IBM SPSS Data Access Pack for Salesforce.com 6.0 Windows English (CI07REN) Size 43mb
IBM SPSS Modeler Desktop Quick Start Guide 15.0 Multilingual (CI660ML) Size 0.5mb
IBM SPSS Modeler Client Documentation 15.0 Multilingual (CI8Y1ML) Size 348mb
IBM SPSS Modeler Client Premium Documentation 15.0 Multilingual (CI8Y6ML) Size 51mb
IBM SPSS Modeler Server Quick Start Guide 15.0 Multilingual (CI661ML) Size 0.5mb
IBM SPSS Modeler Server Premium Documentation 15.0 Multilingual (CI8Z3ML) Size 28mb
IBM SPSS Modeler Server Scoring Adapter 15.0 for Netezza Multiplatform Multilingual (CI8X4ML) Size 130mb
IBM SPSS Modeler Server Scoring Adapter 15.0 for Teradata Multiplatform Multilingual (CI8X5ML) Size 112mb
IBM SPSS Data Collection, Licensing Tool
32 & 64-bit
AIX, HP-UX, Linux, Linux for System z, Oracle Solaris, IBMi
Academic, Academic Campus, Faculty Author Pack
Japán nyelv külön.
Észrevételek:
Szinte napra pontosan egy év elteltével jött ki a 15.0 a 14.2-höz képest. Illetve az SPSS továbbra is tartja, hogy főverzión belül két alverzió van.
36MB, 3.4%-nyi az ujdonság a setup-anyagban. :DDDD. Ez fedi le a GLMM-et (General Linear Mixed Model) és a Graphboard fejlesztéseket az alap Clementine-ban.
- Az egyik friss ujdonság Entity Analytics-nek két verziója van egy normál 110 MB és egy "Unleashed" (póráz és korlátok nélküli) 172 MB.
- Az Unleashed ráépül a normálra, feltételezi annak meglétét és szerintem valami förtelmesen hulladék az install-anyaga. Van egy install exe-je jó mélyen elásva egy könyvtárstruktúrában és egy nála jóval nagyobb Resouce1 zip-anyag (felsőbb szinten) nem felhasználóbarát elnevezésű java-csomaggal, amit nem tudni hogy ki és hogyan használ fel. És akkor még nem beszéltem arról, hogy az ujdonságok installja mennyire teleszemeteli a kristálytisztán világos eddigi install-struktúrát.
- A normál verzió egyetlen repositoryt engedélyez, így ezt cégek maguknak tudják használni. Az "Unleashed" verzió meg korlátlan repository használatot enged meg, ami deduplikálásra szakosodott cégeknek jöhet jól (brute force első megközelítésben)
- És természetesen mindennek van szerver-kiegészítése is. ;)
- Az Entity Analytics pasw-s fejlesztés maradt az ext-könytár tanusága szerint. ;)
- Az Entity Analytics csak ext/bin-ben jelenik meg, ext/lib-ben nem. Már ha jól láttam. Furcsálltam is rendesen... ;)
- Az Entity Analytics install anyaga el van rontva, minden file ugyanazon a néven kétszer van benne. Kicsomagolásnál jön a menetrendszerű kérdés: felülírás kell-e.
- Szerencsére a másik friss ujdonság Social Network anyagnál már nincsenek ilyen hókamókák.
A Text Analytics install-anyaga rendesen lecsökkent 503 MB.ról 127 MB-ra. Okát nem láttam, igaz nagy erőfeszítést nem is tettem az ügyben.Azt feltételezem, hogy (angol) szótárak, adatbázisok okozzák a méretkülönbséget.
- Érdekes, hogy a Batch 132 MB, addig a Premium Batch csak 92 MB (hasonlatosan a Collaboration and Deployment Services-hez).
- Attól lenne "Premium", hogy ugyanazt a funkcionalitást kevesebb kódsorból hozták ki? :DDDD Persze valószínűleg arról van szó, hogy a "Premium" ráépül a "Professional"-re.
- Egyébként ezt a szoftvergyári termék-elágaztatást már nagyon nehezen tudja az ember értelmezni. ;)
Kétféle adatelérés van:
(1) Amikor a .sav Statistics belső állományformátumot akarjuk külső programból,például SQL-ből elérni.
(2) Amikor a Clementine heterogén módon különféle adatbázisokhoz akar csatlakozni. A jó hír, hogy ez jóminőségű (amúgy brutális árszabású) ODBC-drivereken keresztül szokott történni. A rossz hír, hogy ezek az ODBC-driverek csak SPSS-termékeken belül használhatók.
Download, sajnos link nélkül ;)
Documentation
- A dokumentációk önmagukért beszélnek. Azért az egy érdekes dolog szembesülni, hogy a "Premium" doksinak nem része az alap Clementine doksija. ;)
- Algorithms Guide 367 oldalról 404 oldalra hízott, GLMM-nek köszönhetően. Viszont sajnálatos módon sem az Entity Analytics, sem a Social Network algoritmusok leírását nem tartalmazza. Mire fel ez a nagy titokzatosság? A felhasználók fekete dobozra bízzák rá a feldolgozásaikat, korunk nagy "kifehérítési" követelménye közepette? ;)
- Modeling Nodes Guide 479-ről 508 oldalra hízott, szintén a GLMM-nek köszönhetően
- Applications Guide viszont sajnos maradt 404 oldalnak. Ami annak fényében visszás, hogy a GLMM egyáltalán nem önjáróan és kitalálhatóan triviális játék. Demo-stream sincs hozzá. :o((
- Született egy új 53 oldalas könyv a 15.0-ra: Deployment Guide
- Entity Analytics User Guide mindösszesen 75 oldal
- Social Network User Guide mindösszesen 37 oldal.
- Nem tűnnek tehát "rocket science"-nek a használatuk. ;) És hozzájuk legalább már van demó stream, még ha a dokumentálásuk kicsit zavaros is.
- CRISP-DM, a hivatalos fenti linkes helyről le sem tölthető, de 5 oldallal azért bővült. :o)
- A többi doksik vagy nem változtak vagy pár oldalt híztak csak.
Azért az milyen "kemény", hogy Scoring Adapter is létezik olyan egzotikus platformokon, mint Netezza és Teradata. Feltételezem olyan helyeken lesz érdeklődés irányukba, ahol a pénz nem számít. ;)
És akkor a kombinatórikus robbanás jegyében, jönnek a pluszok és duplázódások:
- IBM SPSS Data Collection, Licensing Tool
- 32 & 64-bit
- AIX, HP-UX, Linux, Linux for System z, Oracle Solaris, IBMi oprendszerek
- Academic, Academic Campus, Faculty Author Pack
- Japán nyelv. Külön.a nyelvnél speciális érdekesség, hogy a két ujdonság (Entity Analytics, Social Network) installja két nyelv között enged választást: angol és lengyel(!).
Szóval ember legyen a talpán, aki ebben a install-dzsugelben kiigazodik.
ÁRAK:
Clementine árak I - IBM Passport Advantage Express
Clementine árak II - IBM-től letölthető 119 oldalas pdf-ben
Clementine-árak III - Gemini eStore IBM SPSS Modeler Client Professional
Clementine-árak III - Gemini eStore IBM SPSS Modeler Client Premium
Clementine-árak III - Gemini eStore IBM SPSS Modeler Server Professional
Clementine-árak III - Gemini eStore IBM SPSS Modeler Server Premium
Clementine-árak III - Gemini eStore IBM SPSS Collaboration and Deployment Services
Örök kérdés, hogy az egyes az opciók...
(1) diszjunkt módon egymásra épülnek-e, azaz a "magasabb rendű" feltételezi maga alatt az "alacsonyabb rendü" meglétét, avagy
(2) minden termék zárt, kerek, önmagában megálló egész-e. Mindkét megközelítésnek megvan az előnye (modularitás vs egységesség).
Jelen esetben az (1) esettel van dolgunk telepítés szempontjából (ár szerint nyilván nem, pontosabban felemásan, lásd alább). A Client Professional-ra kell telepíteni a Premium illetve Server komponenseket.
Pár érdekesebb ár:
IBM SPSS Modeler Client Professional Authorized User Initial Fixed Term License $10,961.00
IBM SPSS Modeler Client Professional Authorized User License $25,026.00
IBM SPSS Modeler Client Professional Concurrent User Initial Fixed Term License $27,451.00
IBM SPSS Modeler Client Professional Concurrent User License $62,468.00
IBM SPSS Modeler Client Premium Authorized User License $39,964.00
IBM SPSS Modeler Server Professional Processor Value Unit (PVU) License $537.38
IBM SPSS Modeler Server Premium Processor Value Unit (PVU) License $661.54
Az IBM öntudatlanul is beismerve, milyen "szégyenletesen" sokat kér (hivatalos listaáron mindenképpen), ezért nem nagyon terjeszti boldog-boldogtalannak az árait. A Clementine Consulting is csak a Statisticsre közölt mindig is árakat, a Clementine-ra sose (az én tudomásom szerint).
Árazást tekintve a "Premium" önálló termék, magában foglalja a "Professional"-t. Míg a Server látnivalóan opció csak, hogy teljesen kusza legyen a kép. ;)
A "fixed term"időkorlátos, gondolom egy évig lehet használni, mert 12 hónap support jár azért hozzá. A korlátlan ideig használható verzió majdnem háromszor annyiba kerül.
Az "authorised user" licence-verziót dedikált ember használhatja, mint egy "könyvet" (azaz akár napközben a munkahelyén és este az otthonában is)
A "concurrent user" licence-verziót meg csak munkahelyen akárhányan, de egyidőben egyszerre csak a licence-ben engedélyezett mennyiségű felhasználó, feltételezem három(?).
A PVU-alapu licencelésről meg pikirten elmondható, hogy a "legfelhasználóbarátabb" licencelési és árazási stratégia. Élből 10-zel kell szorozni az árat. ;)
Érdekes még a Non-Production Enviroment korlátozás. Neten sem találtam róla semmi idevágó infót. Ha egy biztosító üzemeltet ilyet az minek számít? Production? Non-Production?
És akkor a lényegről. :o)
Régebben az volt a szokás, hogy főverzió váltásánál sok kis finom apróság (hibajavítások mellett) szereztek örömet a felhasználóknak a verzióváltás nyügének legyőzésére. Most meg pusztán négy nagyobb ujdonság van a "What's news"-ban
- GLMM node megjelenése
- Térképek megjelenítésének támogatása a Graphboard node-ban
- Entity Analytics és Social Network Analytics megjelenése de csak a "Premium" verzóban, hogy a szövegbányászat ne csak önmagában árválkodjon ott.
Lehet, hogy tévesen látom, de az SPSS nem akar versenybe a Wekával, RapidMinerrel, Knimével, Orange-dzsal, R-rel, funkcionalitás oldalról, úgy mint régebben a SAS-sal tette számomra oly szimpatikus módon. A Clementine Workbench mára már (ha nem egyenesen régóta) nagykorú lett, már most is nagyon jó dolgozni vele. Egy-két finomság nem éri meg a fejlesztést, nem fog felhasználói tömegeket vásárlásra, upgrade-re csábítani.
Érdekesebb apróbb ujdonságok:
- Stream zoomolás lehetősége, ikonméret állítással összhangban.
- Node-végrehajtási idő megjelenítése
- Stream paraméter megjelenése SQL-lekérdezéseknél.
- Expression Builder hívni tud "In-Database" függvényeket.
- Aggregate Node bővült aggregálási módokkal, SQL-funkcionalitással
- Merge Node bővült feltételfüggő merge-léssel
- Táblatömörítés Database Exportban.
- Bulk Loading Database Exportnál
"Futottak még" apróságok.
- Netezza-fejlesztések.
- Teradata-ban is Score Adapter, "Big Data" supportként eladva.
- IBM Warehause megjelenése az "In Database"-ben
- IBM Cognos BI node fukcionális bővülése
- In Database Model Scoring
- Default Database beállítások
- Stream Properties beállítások, optimalizálások újratervezése
- Batch módban új forma megjelenése Database Connectionnél
- SPSS Statistics intergráció bővülése
- Nem root-jogú user is installhat Unixon
- Deployálási funkcionalitás bővülése, három vonatkozásban is.
Látnivalóan kölcsönösen konvergál egymáshoz a Statistics valamint a Clementine, a funkcionalitás odalaláról.Mondjuk nem épp felhasználóbarát módon, egyetlen termékbe olvadóan, hanem a felhasználókat jobban megfejelő (párhuzamos) módon.
Ahogy én tudom az upgrade is nagyon drága szokott lenni SPSS-éknél (akár a kritikus három éven belül, akár három év után nézzük): sajnos ennek most nem volt módom utánamenni. Ennek tükrében a Statisticsben már létező (valamilyen) GLMM nem épp vonzó ajánlat az alap Clementine megjelenésében, míg a Graphboard (térképes megjelenítés), ugyan látványos, de kevés haszonnal kecsegtet hosszú távon azoknak akik pénzt akarnak kisajtolni a Clementine-ból.
- DeDuplikálásról pár éve még csak suttogtuk, hogy lényegében adatbányász feladat (full refreshnél csoportosítási, partial refreshnél osztályozási feladat). Mostanra bekerült a Clementine-ba, az Entity Analytics révén. :o)
- Érdekes a demója: arra mutat példát, hogy ügyfélkockázat számszerűsítésénél nem mindegy, hogy sikerül-e minden ügyfél-rekordverziót megtalálni. :o)
- Totális "black box" nem tudni mekkora méretre működik, milyen gyorsan, milyen találati eredményességi aránnyal, milyen nyelvi lokalizációs mehézségekkel küzd. Egy ausztrál dedup a nagyobb méretek mellett is könnyebb feladat, mint egy magyar (normál esetben). Ahogy a szövegbányászat is magyar kiegészítéssel együtt használható csak igazán jól.
- Totális "black box" azt is el tudja fedni, hogy a standaridizálás, adatgazdagítás nem úszható meg normális körülmények között.
- Érdekesség még, hogy a repository IBM SolidDB típusú.
Hálózatanalízis két analizismódot támogat.
(1) Hálózaton belül milyen csoportok képződnek. - G[roup] A[nalysis]
(2) Hogyan terjed hálózaton belül az információ (milyen utakat kell erősíteni avagy elszigetelni feladattól függően). - D[iffusion] A[nalysis]
Mindkét kapcsolódó demó Churn-témájú szintén ;)
- Térképes demó nem fut alapértelmezésben Windows7 alatt.
MSPROFILE\AppData\Roaming\SPSSInc\graphboard\maps alól a Documents and Settings djones usere alá kell másolni a *.SMZ file-okat.
- A GLMM első "m"-je (mixed) attól "kevert", hogy a regresszióanalizis van társítva benne a szórásanalízissel, mindkettő előnyeit kihasználhatóan. (Továbbá kvázi idősorokkal megspékelten, hiszen korrelált "repeated measure" mélyén ilyesmi van).
- Olyan (klasszikus) feladatokra kiváló, hogy diákokat három féle módszerrel tanítanak például lineáris egyenletrendeszerek megoldására, majd tesztelik őket azonos nehézségű feladatok révén, váltogatva a módszereket, hogy melyik módszerrel milyen gyorsan és jól oldják meg azokat. Kérdés lehet az is, hogy vajon a nem vagy a matematika szakkörbe-járás releváns faktorok-e.
- Az igazán döbbenetes és teszem hozzá nehéz az benne, hogy a független és függő változók között nemcsak eddig megszokott direkt kapcsolat lehet, hanem linkfüggvényen keresztüli is (amiből van egy pár), például a klasszikus logit (logisztikus regresszió).
- Mindenképpen érdemes a figyelemre a metódus, szvsz
Feliratkozás:
Bejegyzések (Atom)
Bejegyzések
