Adatbányászat Blog

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

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

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

Hírlevél

Iratkozz fel hírlevelünkre, hogy mindig naprakészen tudjunk tájékoztatni.
Feliratkozás
Leiratkozás

Címkék

10éves (1) 2007 (1) 2010 (23) 2011 (27) 2012 (13) 2013 (23) 2014 (5) 2015 (6) 2016 (10) 2017 (3) adaptív (1) adat- és médiainformatika (1) adatárusítás (1) adatbányászat (10) adatbányászati algoritmusok (1) adatbányászati alkalmazások (2) adatbányászati meetup (1) adatbányászati oktatás (1) adatbányászati technológiák (4) adatelemzés (1) adatelemzési platformok (1) adattárház (5) adattárház fórum (6) adattárolás (1) adattisztítás (1) adatvédelem (2) advise (2) aegon (1) aglitás (1) agy (2) ajánló (11) ajánlórendszerek (1) aktivitás felismerés (1) algoritmus (1) alkalmazás (3) állásajánlat (1) amazon ec2 (1) ambiens (1) ami (1) analitika (1) analytics (1) andego (3) apache (1) api (2) Arató Bence (3) bank (1) barabási (2) Barabási (2) beharangazó (1) beharangozó (18) bejelentés (2) belami (1) best practice (9) beszámoló (14) bi (13) BI (3) Bi (1) bi-trek (1) biconsulting (7) bigdata (21) Big Data (2) big data (5) biopen (1) biztosító (1) BI Akadémia (1) bi consulting (1) bi start (1) blog (5) BME (14) bme (1) bootcamp (1) brainstorming (1) bsp (1) budapest (1) business analytics (1) business analytics szakirány (1) churn (2) ci (1) címkefelhő (2) CIO (1) clementine (1) Clementine Consulting (1) cloud computing (2) cognos (1) credit scoring (1) crisp-dm (1) crm (2) csalásdetektálás (1) DataExpert (1) dataexplorer (1) datapest (1) data mining (1) data science (5) diplomamunka (1) dmla1o (1) dmlab (12) döntési fák (1) drill (1) e-commerce (1) előadás (21) előrejelzés (1) élő közvetítés (1) Enbrite.ly (1) energetika (1) esemény (2) esettanulmány (3) etikus (1) etl (2) évforduló (2) fejlesztés (2) felmérés (5) felsőoktatás (1) felület (1) felvásárlás (3) film (1) fizetés (1) forecasting (1) forgalomelőrejelzés (2) foursquare (1) fraud detection (1) freebase (1) gartner (2) gazdasagi informatikus (2) gépi tanulás (4) google (8) google analytics (1) graphlab (1) gravity (3) greenplum (1) gyakorlat (1) hadoop (10) hallgatók (2) hálózatelemzés (3) hálózatkutatás (2) hálózatok (3) hazai (2) hiba (4) hírlevél (2) hive (1) honlap (1) HR (1) HVG (1) i5 (1) ibm (6) ibm modeler (1) ibm spss (3) icdm (1) idc (2) idősor (1) idősorok (1) ieee (1) iir (1) infobright (1) információbróker (1) innováció (5) innovatívBI (1) innovativ bi (4) inspiráció (1) intelligencia (2) Internet Hungary (1) iqsymposium (19) iqsys (16) iroda (4) jelentkezés (1) jmp (2) kaggle (2) kampánymenedzsment (1) kapcsolati hálók (1) karrier (1) kdd (3) kdnuggets (2) képzés (4) kérdés (1) kérdőív (1) kerekasztal (1) keresés (1) kereső (1) keresztvalidáció (4) klaszterezés (2) knime (1) kockázati tőke (1) kollaboratív munka (1) kompetencia (1) konferencia (70) könyv (6) környezet (1) közlekedés (1) közösség (2) közösségi hálózatok (4) közvetítés (6) kritika (1) küldetés (1) kürt akadémia (1) kutatás (2) lemorzsolódás (1) licensz (1) live (1) logisztika (1) magyar telekom (2) mahout (1) mapreduce (1) marketplace (1) média (2) meetup (11) mellékspecializáció (1) mém (3) memóriacentrikus (1) menedzsment (3) metaadat (1) metodika (1) microsoft (1) mobil (5) mobil bi (4) modeler (2) modell (3) morgan stanley (1) motion chart (1) munkaerő (1) mysql (1) mytraffic (4) nemzetközi (5) nemzetközi összehasonlítás (1) netflix prize (1) networking (1) next big thing (1) nips (1) nosql (1) nyílt forráskód (4) nyomkövetés (1) offline áruházak (1) okostelefon (1) oktatás (22) olvasók (1) online áruházak (1) online kutatás (1) open source (19) open source bi (3) operatorfa (1) osbi (12) összehasonlítás (1) ötletek (2) pandas (2) paradoxon (1) pascal (1) pentaho (1) personal data mining (1) phd (2) philips (1) piac (3) pikk (1) pilot (1) PISA-felmérés (1) pmml (1) politika (2) powerpivot (1) prága (1) praktiker (1) prediktív analitika (2) prediktív analitka (1) prediktiv modellezés (5) prediktív modellezés (1) prezi (15) privacy (1) privacy preserving data mining (1) projekt (1) projektmenedzsment (4) publikáció (1) python (9) radoop (12) random forest (1) rapid-i (2) rapidanalytics (7) rapidminer (40) RapidMiner (2) rcomm (7) refine (1) Rexer Analytics (1) rsctc (1) R nyelv (7) saas (1) sap (1) SAS (20) sas enterprise miner (2) sas enterpris guide (1) sas entprise miner (1) sas fórum (1) sas forum (3) siker (3) simptech (1) sixtep (2) smarthabits (1) spike sorting (1) sportanalitika (1) SPSS (3) spss (13) spss clementine (3) spss hungary (5) spss modeler (6) ssd (1) starschema (2) startup (9) statisztika (1) survey (1) svm (1) szabad szoftver (1) szakmai (1) szavazó eljárások (2) szélenergia (1) szélerőmű (1) szervezetfejlesztés (1) szociális hálók (1) szoftver (5) szöveg (1) szövegbányászat (2) sztaki (2) tableau (1) talend (2) támogatás (1) tanulmány (1) tanulság (1) távolság (1) technológia (1) tedx (1) telekommunikáció (2) teradata (2) teszt (1) text mining (1) tmit (5) toborzás (1) tőzsdei előrejelzés (1) tracking (1) trendek (8) tudományos (1) tunedit (1) twitter (17) ügyfél (1) üzleti intelligencia (3) üzleti modell (3) üzleti reggeli (3) validáció (4) válogatás (1) válság (1) változás (1) vélemény (1) véleméy (1) verseny (20) vezetői képzés (1) videó (3) vizualizáció (5) web (4) web2 (2) webanalitika (3) webshop (1) weka (2) wikipedia (2) workshop (1) yahoo (2) Címkefelhő

TWitter a csapat tagjaitól

2015.03.18. 10:00 Ragány Csaba

RapidMiner tippek - Adatbázis-rendszer monitorozása

Címkék: best practice rapidminer


Nagyjából egy hónapja jelent meg az adatbányászati és prediktív analitikai eszközök idei, Gartner által készített szokásos kiértékelése, mely a RapidMiner esetén sok újdonságot illetve változást nem hozott: a cég idén is a vezetők között szerepel, picit több vízióval. Őszintén szólva számomra kisebb meglepetés, hogy a Radoop felvásárlásával nem ugrottak valamelyest az előző évi értékelésükhöz képest, bár az igaz, hogy a Big Data képesség ma már alapvető tulajdonsággá vált egy adatelemző szoftver esetében. A csupán minimális változás egyik okaként többek között az általunk is többször említett “lack of documentation” is feltüntetésre került, amin ez a blogbejegyzés aligha változtat, mindenesetre az alábbiakban egy igen érdekes use-caseről olvashattok, aminek egyik apropója a szintén kb. egy hónapja megjelent Gartner adattárházakra vonatkozó elemzése, amin jószerével nagyvállalati adattárház cégek szerepelnek. De mi köze a RapidMiner-nek az adattárházakhoz?

illustration_tnm


Tegyük fel, hogy egy projekt során szükségünk van egy adattárházra, amibe eddig CSV fájlokban meglévő adatokat szeretnénk eltárolni, de ilyen-olyan okok miatt nem valamely kész megoldást nyújtó klasszikus IT cég csúcsterméket választjuk, hanem mi magunk építünk egy számunkra megfelelő adattárházat pl. PostgreSQL alapokon. Miután létrehoztuk a dimenzió- és ténytáblákat illetve kialakítottuk a teljes rendszert (ügyelve többek között a karakterkódolásra és az időzóna beállításra), következhet az adatok betöltése, aminek az egyik legegyszerűbb és nagyon jól automatizálható módja SQL nyelven speciális betöltőfüggvények írása. Ezeket egyszer lefuttatva vagy akár beütemezve tölthetők be az egyszeri vagy az időszakosan előálló adatok.

Itt most teszek egy kis kitérőt, hiszen érdemes megjegyezni, hogy az adatok betöltése RapidMiner folyamatokkal is megoldható, és bizonyos esetekben akár előnyösebb választás is lehet a fenti módszernél. Nyilván szakembere válogatja, hogy ki melyik technológiát preferálja jobban, de aki nagyjából egyformán otthon van mindkét nyelvet/eszközt illetően, hamar észreveszi, hogy az egyszerűbb struktúrájú adatokat sokkal könnyebb és gyorsabb betölteni SQL függvényekkel. Ha például csak néhány dimenziótáblába és egy ténytáblába kell betöltenünk adatokat viszonylag kevés feltétel ellenőrzésével, akkor semmiképp nem javasolt RapidMiner processzt készíteni SQL függvény helyett. Viszont ha jóval összetettebb feltételrendszer mellett kell adatokat betöltenünk, kezelve számos hibalehetőséget (például hiányzó értékeket), elvégezve néhány adattranszformációt, adatszármaztatást és aggregálást, naplózva bizonyos tevékenységeket és mindezt akár bemeneti paraméterekkel vezérelve, akkor a betöltő folyamatot - már csak az átláthatósága és karbantarthatósága miatt is - célszerűbb lehet pl. RapidMiner-ben létrehozni, ahol az RM processz fájl szintén ütemezhető egy szerveren a rendszeres adatbetöltés végett. Persze egy ilyen RapidMiner folyamat korántsem lesz egyszerű, egy-egy processz XML fájljának mérete simán elérheti az 1500-3000 kódsort is (ami egyáltalán nem kevés, sőt!), viszont jóval átláthatóbb, és ha egy év múlva módosítani kell valamit, valószínűleg nemigen kell fölötte napokat ücsörögni még akkor sem, ha esetleg már hosszabb ideje nem dolgoztunk RapidMiner-rel. A fentiek miatt, és mert konkrét feladatot sem definiáltam, így egy ilyen processz részletezésétől most eltekintek. Nem célom a két módszer hatékonyságának összevetése sem (nincs is most a tarsolyomban egy adattárház), és bár elsőre a legtöbben talán azt mondanák, hogy nyilván egy SQL script rég betölti az adatokat, mire a RapidMiner futtatókörnyezete feláll, de mondjuk 70 GB adatnál ez nem biztos, hogy így van. Ehhez természetesen szükséges az adatok előzetes feldarabolása, mert a RapidMiner bemenetére pár 100 MB-os CSV-nél nagyobbat aligha ajánlott engedni, viszont ezekkel meglepően gyorsan képes végezni. És a lényeg, hogy a RapidMiner ismertebb operátorai mellett a különböző exception, makró, log és adatbázis operátorokkal a fenti speciális adatbetöltés “könnyedén” megoldható.

Az adatbetöltés mellett felmerülhet igényként az adattárház "monitorozása" is, ami alatt most a klasszikus felügyelet helyett azt értjük, hogy szeretnénk valamilyen értesítést és leírást kapni arról, ha történt adatbetöltés a rendszerbe, illetve arról is, hogy az új adatok milyen változást eredményeztek az adattáblákban, mennyire térnek el az új adatok a korábbiaktól. Ez így persze egy elég általános megfogalmazás, úgyhogy százféle megoldása lehet. A feladat részletesebb specifikálása érdekében járjuk picit körül az adatbetöltés hibadetektálásának problémáját: adott egy adattárház, tele adattáblákkal, melyek között az idő elteltével akár új is felbukkanhat. Minden adattábla tekinthető egyedinek, mivel (kezdetben legalábbis) nem tudunk róluk semmilyen információt, így azt sem, hogy hány mezővel és rekorddal rendelkeznek, illetve milyen típusú értékeket tartalmazhatnak. Tegyük fel, hogy szeretnénk a betöltött adatokra vonatkozóan outlier detektálást, amihez egy bemeneti segédtáblában rendelkezésre áll, hogy mely adattábla mely oszlopain milyen intervallumok engedélyezettek. Ha nincs ilyen információ, akkor az abban az oszlopban lévő minden érték érvényes, vagyis nem kívülálló. A végeredményben pl. táblázatos formában az adattábla azonosító és az aktuális adatbetöltéshez tartozó minimális és maximális kulcs mellett tehát szeretnénk látni az egy-egy adattábla esetén meglévő intervallumhibák darabszámát, valamint, hogy hány darab “különbség” jelentkezett az előző ellenőrzés óta, illetve egy ebből a számból számított arányszámot is az adattábla mezőinek függvényében. Ezen arányszám és az intervallumhibák számának ismeretében állapíthatjuk meg, hogy vajon az újonnan betöltött adatok “lényegesen” eltérnek-e a korábban betöltött adatoktól, vagy sem. Az eredménytáblának célszerű tartalmaznia a korábbi ellenőrzések eredményeit is minden adattáblára, hogy összevethetők legyenek az aktuális elemzésnél kapott értékek a korábban kapott értékekkel.

“Különbség” pedig adattábla mezőnként akkor keletkezik, ha egy adott oszlopra a figyelembe vett egy-egy mérőszám egy paraméterben meghatározott mérték felett eltér a korábbi (vagy eddigi vagy első) adatbetöltés során számított azonos mérőszám értékétől. Egy oszlopnál maximálisan annyi különbség keletkezhet, ahány mérőszámot definiálunk, adattábla szinten pedig ez szummázódik a mezők darabszámára. Ezután már csak azt kell definiálni, hogy milyen mérőszámokat vegyünk figyelembe a “különbségek” összeszámolásához. Minden oszlopra vizsgálhatjuk az egyedi illetve a hiányzó értékek arányát az összes betöltött rekord függvényében, szöveges mezőkre kiszámíthatunk egy rakás változót a karakterhossz mellett, például hány olyan érték van a mezőben, amely csak decimális, kisbetűs, nagybetűs vagy speciális karaktert (illetve ezek kombinációit) tartalmaz, és ezen darabszámokból képezünk egy-egy arányszámot. A speciális karakterek vizsgálatához célszerű egy makróban megadni a magyar abc (vagy egyéb előforduló nyelv) ékezetes karaktereit (külön a kis és nagybetűket) unicode formában (pl. ‘á’ = \u00e1). Dátum értékeknél vizsgálhatjuk a minimum és maximum dátum között eltelt időt. Hasonlót számíthatunk numerikus értékekre is, valamint nézhetünk különböző statisztikai próbákat (pl. w-próba az átlagra, f-próba az eloszlásra). Valós értékeknél megvizsgálhatjuk a törtrész pontosságát is (vagyis a tizedesjegyek darabszámát). Ha ezeket az attribútumokat legeneráltuk, már csak meg kell nézni, hogy a belőlük származtatott arányszámok a paraméterben megadott értéktől nagyobb mértékben különböznek-e az adattáblába korábban betöltött adatok esetén jelentkező arányszámoktól, és ha igen, akkor keletkezett egy “különbség” arányszámonként (és mezőnként). Persze akár súlyozhatjuk is az eltéréseket, pl. a hiányzó értékekben való eltérés duplán számít.

Nos, ez a feladatleírás “picit” hosszúra és talán bonyolultra sikeredett így elsőre, de a jó hír, hogy mindez RapidMiner-ben megvalósítható, kezdve onnan, hogy az adattárházból beolvassuk a benne lévő adattáblák neveit, amikből eltávolítjuk a rendszertáblákat, mert azokat nem akarjuk elemezni. Nyilván szükségünk van a jogosultságok beolvasására is, hiszen csak olyan adattáblát tudunk elemezni, melyhez van olvasási jogunk. Ezután beolvashatók az elsődleges kulcsok nevei és maximális értékei, melyek alapján csak azokat az adattáblákat elemezzük, ahol ezen értékekben történt változás. Ehhez egy, a RapidMiner Repository-ban eltárolt segédtáblát használhatunk, melyet adatbetöltés esetén minden elemzés alkalmával frissíteni szükséges az elemzett adattábla kulcsának új értékével illetve új adattáblával is, ha került ilyen az adattárházba. Az elemzéseket adattáblánként végezzük egy Loop Values operátor segítségével, amiben beolvassuk az adott adattábla újonnan betöltött rekordjait, illetve a mezők adattípusát is. Ha az idegen kulcsokat nem szeretnénk elemezni, akkor azokat kiszűrjük (az elsődleges kulcsot értelemszerűen nem elemezzük). Az idegen kulcsokra azok elnevezéséből vagy a leírásából következtethetünk (legalábbis jól definiált adattárház esetén). Adattárházról lévén szó, jó eséllyel a dátum értékeket ki kell nyernünk a megfelelő dimenziótáblákból, majd adattípustól függően legeneráljuk a fent definiált arányszámokat külön a szöveges, numerikus és dátum típusú mezőkre. Az arányszámokat össze kell vetni a korábbi adatbetöltéshez tartozó arányszámokkal, és megnézni, hogy a különbség nagyobb-e, mint a paraméterben megadott érték. Ha ezekkel megvagyunk, jöhet az intervallum vizsgálat, ami numerikus és dátum típusú mezőknél egy egyszerű min-max feltétel ellenőrzés, majd következhet a kiszámított értékek egy táblázatba ágyazása és elmentése, ami a fentiek után már gyerekjáték. A létrehozott folyamatot célszerű az adatbetöltőkkel szinkronban beütemezni, így minden adatbetöltés után azonnal lefut az elemzés, ami többek között a performancia miatt nagyon nem elhanyagolható szempont, illetve így triviálisan megállapítható minden adatbetöltésre (bemeneti CSV fájlra), hogy a benne lévő adatok mennyire “jók”.

A létrehozott folyamat egyik előnye, hogy gyakorlatilag semmilyen előzetes információt nem követel meg az elemzéshez, különösen ha nem szeretnénk outlier detektálást (ha nem definiálunk intervallumokat, az elemzés akkor is lefut, ahol minden adattáblában pontosan 0 darab outlier érték lesz). A kívül eső értékek egy része egyébként jól definiált mérőszámok esetén is detektálható: pl. ha a bemeneti adatokban az adatbevitel során történt elgépelés miatt szerepel egy 2206-os évszám 2006 helyett, akkor a minimum és maximum dátum között eltelt idő nagymértékben különbözni fog a korábbi adatbetöltés ugyanezen értékétől. Természetesen a processz számos PostgreSQL specifikus elemet és lekérdezést tartalmaz, de ezek könnyen adaptálhatók más rendszerekre.

Egy ilyen processz megépítése nyilván nem egy fél napos munka, az eredmény itt is bőven 2-3000 kódsor közé tehető, így itt sem látom értelmét kódrészletek bemutatásának. Azonban remélhetőleg a fenti leírás jó illusztrációt ad arra vonatkozóan, hogy a “The RapidMiner platform supports an extensive breadth and depth of functionality” Gartner véleményezés mennyire helytálló, illetve arra vonatkozóan is, hogy adatbányászati feladatok mellett a tágabb data science világban is bátran használható a RapidMiner. Ezzel természetesen nem azt akarom mondani, hogy ez a legjobb megoldás erre a feladatra, de abban szinte biztos vagyok, hogy kevesen gondolták volna, hogy ilyen szintű problémák is egészen jól kezelhetők RapidMiner-rel.

Még egy jó tanács a végére: ilyen bonyolultságú processzek építésénél célszerű egyedi elnevezésekkel és kommentekkel ellátni a RapidMiner operátorokat, mert egy idő után már nem lesz annyira egyértelmű, hogy annak idején pontosan mit és miért is csináltunk. Kommentek a ‘Comment’ panelben írhatók minden operátorhoz külön-külön. (Ha nem találnád ezt a panelt: a View / Show View menüpont alatt kiválasztható.)

A kép forrása.

Szólj hozzá!

A bejegyzés trackback címe:

http://adatbanyaszat.blog.hu/api/trackback/id/tr327275995

Kommentek:

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

Nincsenek hozzászólások.