|  | ||||||||
|  | ||||||||
| | ||||||||
| | ||||||||
 |
kategória |  |
||||||||
|
|
||||||||||
 |
 |
|
|
|
|
|
||
|
|
Diplomaterv
Viselkedés változás analízise
távközlési hívásadatokon
Tartalomjegyzék
1. Absztrakt ha kell angol is
2. Bevezetés
2. 1. A téma elhelyezése a világban; adatbányászatról pár szó
2. 2 Adatbányászati feladatok
2. 3. BME és a T-com közös projektjének leírása: miről szól, milyen adataink vannak
2. 4. A téma indoklása, a konkrét megoldandó feladat, a probléma megoldása mit tesz lehetővé a számunkra, Miért indokolt a probléma kezelése
2. 5. A CRISP-DM modell rövid bemutatása, mely alapján a téma kidolgozása történik.
3. 1. Business Understanding: a kitűzött feladat miért hasznos üzleti szempontból
3. 2 Data Understanding: adatok feltérképezése (piped-mine), begyűjtése (piped-mine), megértése
3. 3. Data Preparation: a tényleges adathalmaz elkészítése
3. 4. Modeling: konkrét adatbányászati műveletek: modellezési technika
3. 4. 1. technika kiválasztása: milyen modelleket próbáltunk, a sikeres (leghatékonyabb) modell ismertetése matematikai szempontból (elméleti háttér)
3. 4. 2. modell felépítése, futtatás
3. 4. 3. sikeresség vizsgálata, modell ellenőrzése
3. 5. Evaluation
3. 6. Deployment
4. Összefoglalás, következtetések
V. Irodalomjegyzék
VI. Rövidítések jegyzéke
VII. Ábrajegyzék
VIII. Köszönetnyilvánítás
IX. Mellékletek
Napjainkra a tároló kapacitások erőteljes növekedése valamint az árak nagymértékű csökkenése a hétköznapi életben is egyre több helyen elérhetővé tette adatbázisok és adattárházak használatát. Ezáltal manapság szinte minden közép- és nagyvállalat alkalmazza ezeket az informatikai eszközöket vásárlóik, ügyfeleik, illetve saját adataik tárolására. Ez a folyamat azt eredményezte, hogy egyre több információ halmozódott fel, melyeket eleinte csak ellenőrzésre illetve visszakeresésre használtak, így alakultak ki az úgynevezett "adattemetők" (data tombs) [1].
Azonban egyre több területen merült fel az igény arra, hogy a meglévő információkból valami új, hasznos információt nyerjünk ki, melyekre a régebbi adatbázis kezelő rendszerek még nem voltak felkészülve. Ez az igény keltette életre az adatbányászatot, az 1980-as éves végén, mely mostanra már közel húsz éves fejlődésen ment keresztül.
Az adatbázisból való tudásfeltárás[1] során adatbányászati algoritmusokat alkalmazunk. Az algoritmusok elvégzése után mintákat fedezünk fel az adatokban, végül számítógép segítségével a mintákból használható tudást kovácsolunk. Az adatbányászat definíciója tehát a következő: nagyméretű adatbázisokból új, nem triviális és egyben hasznos összefüggések feltárása.
Az adatbányászat egy új tudományterület, mely számos korábbi tudománnyal is szoros kapcsolatban áll, illetve ezeket ötvözi. Ilyenek például a teljesség igénye nélkül a matematika, statisztika, számítástudomány, mesterséges intelligencia és a marketing. A diplomatervem során az adatbányászat már meglévő eredményeit, módszereit használom föl, illetve feladatom megoldásához új módszert (modellt) alakítok ki, mellyel mindegy hozzájárulva az adatbányászat eddigi töretlen diadalmenetéhez.
A sikeres alkalmazások eredményeképpen az adatbányászat egyre elfogadottabb tudománnyá vált, így ma már az adatok tárolásán kívül, szinte mindenütt fontos azok feldolgozása és elemzése is. Az adatbányászat a kereskedelem, a pénzügy, valamint a biológia és orvostudomány területén már bizonyította hatékonyságát. Mégis van néhány tipikus feladat, mely több különböző környezetben is felmerül és általános megoldási módszereik hasonlóak a különböző felhasználási területeken. Ilyenek például a következő feladatok:
Gyakori minták kinyerése [2]: olyan elemcsoportok megkeresése, melyek gyakran együtt fordulnak elő, azaz asszociációs szabályok megkeresése. Tipikus példája a vásárlói kosár elemzése, ahol a gyakran együtt vásárolt termékek kerülnek feltárásra.
Attribútumok közötti kapcsolat: itt az elemek attribútumai közti kapcsolatokat tárjuk fel, így alakítunk ki korrelációs, illetve függőségi szabályokat.
Osztályozás [2]: az elemeket valamilyen tulajdonságuk alapján előre definiált csoportokba soroljuk, vagyis osztályozzuk őket.
Klaszterezés [2]: itt az elemeket egy-egy előre nem definiált csoportokba soroljuk be. Az adott klaszterező algoritmus feladata az egyes csoportok kialakítása. Az a fontos, hogy a csoporton belüli elemek egymáshoz valamilyen szempontból közeliek legyenek, a különböző csoportokban lévők pedig távoliak.
Sorozatelemzés: a hasonló sorozatokat vagy részsorozatokat keressük meg, illetve azokat, amelyek gyakran fordulnak elő. Megpróbáljuk meghatározni, hogy egy adott sorozat nagy valószínűséggel mivel fog folytatódni.
Eltéréselemzés: az előző feladatoknál általában nem vettük figyelembe az általános trendtől erősen eltérő néhány elemet. Itt viszont pont azokat kell megkeresnünk. Tipikus példája a hibadetektálás, vagy a csalások felderítése.
Viselkedés előrejelzés: feladat itt az, hogy a múltbéli események alapján megjósoljuk, hogy milyen fordulatok várhatók a vizsgálati alany viselkedésében. Ez használatos, ha például meg akarjuk tudni, melyik ügyfél hajlik arra, hogy szolgáltatót váltson (churn-analízis), vagy, hogy melyik ügyfél nagy valószínűséggel hogyan fog reagálni egy-egy új termék bevezetésére (affinitás elemzés). Diplomatervemben főként ez utóbbi kérdéskört vizsgálom meg.
Az előző félévek során bekapcsolódtunk a tanszék egyik adatbányászati projektjébe. A projekt a T-Com távközlési cég megbízásából indult, a MTA-SZTAKI[2], a TMIT tanszék és az AITIA Rt. részvételével. A cég vezetékes telefonhívások szolgáltatásával is foglalkozik, így nagy mennyiségű hívásadatok állnak rendelkezésükre. Az adatok tárolása itt létfontosságú, hiszen az előfizetők nyomon követéséhez és a számlázásához elengedhetetlen nagyméretű adattárházak használata. A tárolt adatok nagy segítséget nyújtanak akkor is, ha egy vállalat racionalizálni szeretné a működését, illetve mindezeken kívül az adatokból másfajta összefüggésekre is rá lehet jönni az adatbányászati tudomány segítségével. A tanszék hallgatóinak feladata pedig az, hogy az adatokon különböző adatbányászati projekteket hajtsunk végre. Természetesen a felhasználói viselkedések helyes modellezése a többi telekommunikációs területen, például mobil távközlés, vagy internet szolgáltatók esetén is alkalmazható, sajnos azonban ilyen adatbázis nem áll rendelkezésünkre. A tanszéken elemezzük a hívások különböző attribútumait, úgymint a hívások időpontját, időtartamát, irányultságát valamint a költségét, mely a tarifacsomagokhoz szorosan kapcsolódik. Természetesen a hasznos információ megszerzéséhez az előfizetők megfelelő modellezésére van szükség, mely tulajdonképpen ezen adatbányászati projektek célja.
Manapság a telekommunikációs piac telítődött, így a cégek számára a legfontosabb, hogy a már meglévő ügyfeleiket, megtartsák. Ezért, ha sikerül előre jelezni, hogy ki fog szolgáltatót váltani (ez a terület a churn-analízis), célzott reklámokkal, ajánlatokkal (Direct Marketing) van esély megtartani az ügyfelet. A cégek hajlandóak az ügyfelek részére egy kedvezőbb tarifacsomagot ajánlani, ezáltal kevesebb profithoz jutni, csak azért, hogy nehogy más szolgáltatót válasszanak. Ráadásul a helyzetet még az is bonyolítja, hogy a tarifacsomag váltása után a legtöbb ügyfélnek megváltoznak a telefonálási szokásai. Sokan jóval többet kezdenek telefonálni, mások pedig jobban odafigyelnek arra, hogy mikor telefonáljanak. Természetesen vannak olyanok is, akik érzéketlenek a tarifacsomag váltásukra vagy nincsenek pontosan tudatában annak, hogy a nap melyik szakában milyen irányban mekkora költséggel telefonál. A diplomatervemben ezt a feladatkört próbálom megoldani, vagyis olyan modelleket kívánok létrehozni, melyek hűen türközik egy átlagos előfizető viselkedését egy új tarifacsomag bevezetése esetén.
Az üzleti feladat részletesebb kifejtésére és az adatbányászati cél meghatározására . fejezetben kerül sor.
Az adatbányászati algoritmusok megszületését követően problémaként merült fel, hogy a konkrét adatbányászati projektek terén nincs olyan jól kidolgozott általános módszertan, mely mentes lenne a különböző szaksági specifikumoktól. Mivel az adatbányászati feladatokat széleskörűen alkalmazzák, ezért a tapasztaltabb szállítók kidolgoztak egy olyan módszertant, mely rendszerezi a nélkülözhetetlen lépéseket és lehetővé teszi, hogy egy adott területen megszerzett tudást egy másikban is felhasználják. Így jött létre a CRISP-DM (CRoss Industry Standard Process for Data Mining − Iparág független Szabványos Adatbányászati Módszertan) [3] .
A módszertan hat fő lépését az ábrán láthatjuk ( . ábra), vizsgáljuk meg ezeket a lépéseket sorjában!
. ábra ACRISP-DM módszertan
1. Üzleti célok meghatározása (Business Understanding ez a projekt első fázisa, itt fogalmazzuk meg a projekt célkitűzését, illetve a vele szemben támasztott elvárásokat üzleti szemszögből igyekszik meghatározni. Itt határozzuk meg az alkalmazási környezetet is.
2. Az adatok megismerése (Data Understanding Ebben a fázisban először begyűjtjük az elemzéshez szükséges adatokat, megértjük őket, majd megvizsgáljuk mely attribútumok fontosak számunkra az elemzés szempontjából és ezek milyen típusúak. Elemezzük az adatainkat adatminőség szempontjából is, hogy mennyire hiányosak vagy inkonzisztensek a rendelkezésre álló adatok. Ez utóbbi lépés nagyon fontos minden projekt során, mert ha nem tiszta adaton dolgozunk a konkrét adatbányászati algoritmusokkal, akkor vagy hibás eredményeket kapunk, vagy eredménytelen lesz a projekt.
3. Adatelőkészítés (Data Preparation ebben a fázisban a különböző forrásokból begyűjtött adatokat egységes formátumra hozzuk. Elvégezzük az adattisztítást, mely során az adat minőségének feltárása során megismert hiányosságokat pótoljuk: a hiányzó illetve hibás adatokat feltöltjük. Valamint elvégezzük az adatbeszúrás műveletét is, mely során akár új attribútumokat, vagy rekordokat fűzhetünk a már létező adatstruktúrákhoz. A fázis végére elkészül az a struktúra, mely az elemzés bementéül szolgál.
4. Modellek megalkotása (Modeling): Ebben a fázisban érkezünk el az adatbányászati műveletek végrehajtásához. Először a modellezési technikát választjuk ki, általában valamely erre a célra kifejlesztett szoftver (például Clementine) segítségével. A technika kiválasztása után, a modellt az aktuális adatokhoz hangoljuk, vagyis felparaméterezzük a modellünket. A modellezés elvégzése után meg kell vizsgálnunk a modell sikerességét. Nem kielégítő eredmények esetén új modellel, vagy új paraméterekkel kell újrakezdeni a modellezési lépést. Ezeket a lépéseket egy adatbányászati projekt keretében többször is végrehajtják. Egy ilyen projektre ugyanis sokkal inkább jellemző az, hogy elsőre nem sikerül a helyes modellt megtalálni.
5. Eredmények értékelése (Evaluation Ebben a szakaszban már a megfogalmazott üzleti céloknak megfelelően értékeljük ki a modell, illetve a modellezési lépések sikerességét, hogy teljesítettük-e az első fázisban megalkotott üzleti célokat. Amennyiben az eredményt megfelelőnek ítéljük, akkor modellünket éles bevetésben is használhatjuk és továbblépünk a megvalósítás fázisába. Ha a modellünk nem megfelelő, akkor vissza kell kanyarodnunk egy korábbi lépéshez, vagy egy új projekt keretén belül más irányvonalat kell keresnünk.
6. Az eredmények üzleti szintű alkalmazása (Deployment Ezen utolsó fázis célja, hogy a projekt során megszerzett ismereteket a megrendelő számára is érthető formába kell hoznunk. Ehhez egy alkalmazási és egy üzleti tervet kell készíteni. Ez utóbbi azért szükséges, hogy az adatbányász csoport kivonulása után is folytatódhasson a munka. Bizonyos esetekben célszerű gondosan kidolgozott fenntartási stratégiákat is kidolgozni. A projekt végén gyakran szükség lehet egy olyan összefoglaló dokumentumra, mely a projekt során nyert tapasztalatokat összegzi. Végül saját magunk számára is hasznos egy olyan dokumentum létrehozása, melyben a projekt pozitív és negatív tapasztalatait gyűjtjük össze és levonhassuk a megfelelő konzekvenciákat.
Mivel diplomatervem gyakorlatilag egy teljes adatbányászati projekt végrehajtását tartalmazza, ezért munkám során ezt a jól kidolgozott módszertant követem a továbbiakban.
Az 1. ábrán jól láthatjuk, hogy az egyes lépések között visszalépések is történhetnek, ez a CRISP-DM metodika egyik legfontosabb jellemzője, mely azért van, mert nem megfelelő eredmények esetén gyakran vissza kell lépni az előző fázisba és addig változtatni az adathalmazon, új ötleteket kipróbálni, ameddig kielégítő eredményeket nem kapunk. Diplomaterv feladatom megoldása során magam is többször alkalmaztam ezt a visszalépési eljárást, de ebbe a dokumentumba már csak a végleges, legjobb eredményt hozó módszert fejtem ki részletesen, az előfordult esetleges visszalépéseket és eredménytelen "vakvágányokat" csak megemlítem a dolgozatomban.
A fejezet címe egy adatbányászati projekt első lépése. Ebben a fázisban a projekt célkitűzéseit, illetve a vele szemben támasztott elvárásokat üzleti szemszögből igyekszünk meghatározni. Az "üzleti" kifejezés itt nem feltétlenül a hagyományos pénzpiaci értelmezését fedi, hanem az általános alkalmazási környezetet adja meg, ezért ebben a fejezetben térek ki a munkám során rendelkezésre álló technikai és alkalmazási eszközökre is.
A diplomatervemben olyan modelleket kívánok létrehozni, melyek hűen türközik egy átlagos előfizető hívási szokásait egy új tarifacsomag bevezetése esetén.
Nehezíti a modell megalkotását, hogy az előfizetők egyes csoportjai biztosan másképpen reagálnak egy-egy új tarifacsomag bevezetésére. A nagyobb cégeknél dolgozók munkahelyi hívási szokásait valószínűleg nem befolyásolja, hogy a cég milyen szolgáltatót választott, és épp az adott időpontban mekkora költséggel telefonál a dolgozó. Másrészt pedig a nagyobb cégek általában olyan kedvezményekre is jogosultak, melyek egyéni előfizetők számára nem elérhetők. Ezért a további vizsgálatokban csak az egyéni előfizetőket veszem nagyító alá. Tovább nehezíti a modellalkotást az, hogy egyéni előfizetőkön belül is több csoport létezik, hiszen biztosan más hívási szokásai vannak egy üzletembernek, akinek munkájához elengedhetetlen a telefon használata, illetve egy nyugdíjas idős hölgynek. Ezek az előfizetői csoportok azonban nem választhatók szét a rendelkezésre álló hívási információk alapján.
Határozzuk meg, hogy mit értünk egy előfizető hívási szokásai alatt, vagyis hogy mit kell mégis modelleznünk! A hívási adataink (mely részletesen a 3. 2. 1. fejezetben kerül majd részletes bemutatásra) lényegében azt tartalmazzák, hogy az egyes felhasználók, mikor, milyen irányban és milyen hosszan telefonáltak. Ezekből az adatokból többféle származtatott adatot készíthetünk, melyek modellezése a célom. Ilyen származtatott adatok a következők:
felhasználónként a legkorábbi és legkésőbbi hívás időpontja a vizsgált időszakban
hány hívást bonyolított a felhasználó egy adott hónapban
a felhasználó átlagos híváshossza
egy hónapban összesen hány percet telefonált
Természetesen ezeket az értékeket különböző bontásokban külön-külön is kiszámíthatjuk. Ilyen bontások lehetnek a következők:
Hívás időpontja szerinti bontásban
Ø hétköznap csúcsidőben
Ø hétköznap csúcsidőn kívül
Ø hétvégén
Hívás iránya szerinti bontásban
Ø helyi
Ø távolsági
Illetve ezek kombinációjaként például kiszámíthatjuk a hétköznap csúcsidőn kívüli, helyi hívások átlagos hosszát. Ezekből az adatokból és a különböző felbontásokból nagyszámú adatot tudunk származtatni az egyes felhasználókhoz, melyek jól leírják viselkedésüket.
Feladatom ezen értékek előrejelzése, abban az esetben, ha egy felhasználó tarifacsomagot váltott. Természetesen az egyes felhasználókról feltételezhetjük, hogy a hozzájuk tartozó hívási adatok (hívások száma, átlagos híváshossz, hívások időtartamának összege) a váltás után nem változik és így a váltás előtti hónap adataival becsülhetjük. Hasonlóan jó becslés lehet, ha a felhasználók tarifaváltás előtti összes hívási adata alapján számítjuk az értékeket és ezt vetítjük le egy hónapra majd feltételezzük, hogy a váltás után szintén ilyen paraméterekkel fog telefonálni.
Az adatbányászat eszközeivel viszont kihasználhatjuk, hogy már vannak olyan előfizetők az adatbázisban, akiknek tudjuk, hogy hogyan változtak meg a szokásaik váltásuk után. Ezen felhasználók segítségével egy modellt építve egy olyan felhasználóról is kiszámíthatjuk a hívási szokásainak peremétereit, akik még nem is váltottak át másik tarifacsomagra, vagy éppen most váltottak át. Ez üzleti szempontból nagyon fontos, melyről a következő fejezetben esik szó.
Diplomatervem célja, tehát hogy olyan modellt alkossak, mely pontosabb becslést tud adni annál, mintha az adott felhasználó szokásának változását csak egyszerűen az előző havi (váltás előtti), vagy váltás előtti életciklusának átlagával becsülnénk. Amennyiben ez sikerül, akkor tekinthetjük úgy, hogy az adatbányászati projekt elérte célját.
Az adatok elemzése során továbbá megtudhatjuk, hogy mennyire érzékenyek az emberek saját tarifacsomagjukra és így a saját pénztárcájukra, valóban megváltoznak-e a hívási szokásaik, ha új tarifacsomagba lépnek át. Megéri-e a szolgáltatónak olcsóbb tarifákat bevezetni és ezzel több előfizetőt megtartani, illetve hogy többet telefonálunk-e a szükségesnél, ha bizonyos időpontokban olcsóbban, vagy akár teljesen ingyen telefonálhatunk.
Elsősorban a szolgáltatók számára nagyon fontos az előző fejezet kérdéseinek megválaszolása. Napjaink üzleti világában elengedhetetlen, hogy egy-egy tarifacsomag bevezetése után kiszámítható legyen, hogy ez a szolgáltató számára milyen többlet költségekkel fog járni a jövőben, vagy mekkora többlet nyereség várható egy új számlázási rendszer megvalósítása esetén. Egy ilyen felhasználói modell segítségével elemezhető, hogy vajon egy rivális szolgáltató miért vezetett be egy adott új tarifacsomagot, esetleg nekünk is megérné-e hasonlót létrehozni.
Üzleti szempontból tehát nagyon fontos, hogy modellezzük egy előfizető viselkedését, hiszen ezzel megtudhatjuk, hogy egy felhasználó melyik tarifacsomagról melyikre áttérve milyen paraméterekkel fog telefonálni. Ebből aztán költséget számíthatunk a telefonszolgáltató számára, meghatározhatjuk a tarifacsomagok percdíjait, melyekből aztán kiszámíthatjuk a bevételt és kiadásokat, illetve ezáltal a távközlési szolgáltató nyereségét.
Azonban a telekommunikációs szolgáltatók számára nem pusztán az anyagi értékek előrejelzésére (prediktálására) használhatják ezt a modellt. Távközlési és informatikai szempontból is szükség van arra, hogy előre lássuk egy-egy vonal terheltségét, kihasználását, hiszen a tervezések és fejlesztések során ezek az információk nélkülözhetetlenek. Ugyanakkor ennek a problémakörnek a megoldására a távközlési szolgáltatók jelentősen túlméretezik saját kommunikációs hálózatukat, mert anyagi és üzleti okok miatt így gazdaságos számukra a jövőre nézve, és ezzel kerülik el a hálózat esetleges túlterheltségét.
Egy-egy új tarifacsomag bevezetése esetén létrejöhetnek kritikus időpontok, amikor a hálózat terheltsége nagyon megnő vagy lecsökken. Ezek kiszámításához szintén elengedhetetlen egy ilyen ügyfélmodell megalkotása.
A tanszéki projekt a T-Com távközlési cég megbízásából indult, a MTA-SZTAKI, a TMIT tanszék és az AITIA Rt. részvételével. A hívási információk tárolását és alapvető feldolgozását a SZTAKI tette lehetővé számunkra. A tanszék adatvédelmi okok miatt kisebb módosításokkal kapta meg az adatokat a SZTAKI-tól, azonban ezek a módosítások az elemzés szempontjából irrelevánsak, így lehetővé vált számunkra az adatbányászat ezeken hívási információkon.
A Távközlési és Médiainformatikai Tanszék a módosított adatokat tárolta és a SZTAKI a tanszéki szerveren is elérhetővé tette az adatok kitömörítéséhez és alapvető feldolgozásához szükséges piped-mine nevű programot, melyet a SZTAKI fejlesztett ki.
Ez egy komponens alapú rendszer, mely erősebb kapcsolatot jelent a komponensek között, mint az objektum orientáltság. Lényege, hogy adott egy komponens keretrendszer, melyet egyszer létrehoztak és ebbe a programozás során lehet behelyezni az egyes komponenseket. Ezen rendszer felépítését szemlélteti a . ábra.
. ábra A piped-mine keretrendszer
Mikor a komponenseket a rendszerbe helyezzük, a komponensek tudnak kommunikálni egymással, és a keretrendszerrel. Nekünk csak azt kell ismerni, hogy a "core" és közöttünk milyen interfész található. A rendszerben jelenleg hozzávetőlegesen 40-50 komponens található. Amennyiben valamelyiket használni szeretnénk, akkor ezeket bármilyen sorrendben egymás mögé rakhatjuk, szintaktikailag működni fognak, csak rossz esetben értelmetlen kimenetet kapunk. Illesztésekkel tehát nem szükséges foglalkozni. Ilyen módon a számunkra szükséges komponensek felhasználásával egy "csővezetéket" (innen ered a rendszer neve is) építhetünk melynek a kimenetén megjelenik a számunkra szükséges adathalmaz.
A feladatunk tehát egy olyan konfigurációs fájl elkészítése, mely tartalmazza, hogy milyen komponensekből tettük össze a rendszert és azok hogyan kapcsolódjanak egymáshoz (melyik melyikkel álljon kapcsolatba). Tehát a konfigurációs fájl megírásánál a következő információkat kell megadnunk:
melyik komponensből: pl. kitömörítő, szűrő (filter), aggregáló, hisztogram készítő, fájlba író komponensek
hányat: szükség esetén természetesen több ugyanolyan komponens is egymás mögé fűzhető pl. több szűrő komponens egymás után
kivel kommunikáljon: melyik másik komponenstől kapja az információt és melyiknek adja tovább a "csővezetékben"
A komponensek és a keretrendszer egy egységben vannak, melynek a mérete (csak az algoritmusokat tartalmazza) kb. 24 MB. A SZTAKI ezt a rendszert tette elérhetővé számunkra a tanszéki szerveren, mivel az adatok tömörített formában vannak tárolva és a piped-mine segítségével megoldható, hogy csak azok az adatok kerüljenek kitömörítésre, melyekre a további elemzések során szükségünk lesz.
A keretrendszerről egy általam készített részletesebb útmutató található az irodalomjegyzékben .
Ez a Java alapú adatbányászati szoftver-rendszer lehetővé teszi az üzleti tapasztalatokon alapuló előrejelző modellek gyors kifejlesztését, és azok üzleti és a döntési folyamatokba való beillesztését. Mivel az SPSS a nyílt, egymással összekapcsolható eszközök híve, így a Clementine az iparág független CRISP-DM módszertant követi, mely a diplomatervem során rendkívül előnyös. A Clementine nyitott architektúrája lehetővé teszi a meglévő IT befektetések megőrzését és felhasználását a rugalmas elemzési modell kialakításban és annak üzemelési folyamatokba történő beépítésében.
Az alapvető szükséges adatok kiválasztása és kitömörítése után (melyet az előző fejezetben ismertetett piped-mine rendszerrel végeztem el a tanszéki szerveren) az adatokat átmentettem a saját itthoni számítógépemre. Ezt követően az adatok további átalakítását, a modellek megalkotását és értékelését itthon végeztem el a Clementine 11. 1. -es verziójával.
Intel(R) Core(TM)2 Duo E6750 2,66 GHz
3071 MB RAM
Háttértárolók: Samsung SP1614C 160 GB valamint 2 db Seagate Barracuda 7200. 10 320 GB (Raid1)
Windows Vista x64 operációs rendszer
Sun Java(TM) 6 Update 5
Clementine 11. 1.
Dual Opteron processzor
4 GB memória
Debian Linux operációs rendszer
Piped-mine keretrendszer
Az adatbányászati projekt következő lépése az adatok megértése. Ekkor feltérképezzük, hogy milyen adatok állnak rendelkezésünkre, majd az elemzési célt figyelembe véve ezekből kiválogatjuk az elemzéshez szükséges adatokat. A kiválogatott adatokat részletesebben is megvizsgáljuk, hogy milyen típusúak, milyen értékkészletűek, grafikonokat készítünk az eloszlásukról. Elemezzük, hogy van-e hiányzó, vagy téves adat, illetve, hogy mennyire konzisztens az adatbázisunk. Ezek a lépések egy adatbányászati folyamat sarkalatos pontjai, hiszen itt dől el, hogy mely adatokon fogunk dolgozni. Hibás, vagy téves adatok elronthatják a modell építését és végül hibás eredményekhez jutunk és a projekt sikerességét is veszélyeztetjük.
A SZTAKI által rendelkezésünkre bocsátott adathalmaz 54 attribútumot tartalmaz. A feladatunk ezek közül a számunkra lényegesek meghatározása. Az összes mező rövid leírása megtalálható a [M1] mellékletben, azonban az attribútumok beszédes neve miatt részletes tárgyalásukra itt nem térek ki. Általánosan elmondható, hogy a "D _ SZAM" kifejezést tartalmazó információ a hívó félre vonatkozik, míg a "B _ SZAM" a hívott félre vonatkozó attribútum.
Mivel diplomatervem feladata az ügyfelek telefonálási szokásainak vizsgálata, ezért olyan mezőket kell kiválasztanunk az 54 közül, melyek egy előfizető szokásait jellemzi. Egy hívás legfőbb tulajdonságai ilyen szempontból, hogy milyen irányban telefonálunk, milyen időpontban és természetesen, hogy mennyi ideig. Ezek alapján a következő mezőket választottam ki az elemzéshez, melyeket az alábbiakban részletesen is bemutatok:
D _ SZAM: Ezen mező kiválasztása azért szükséges, hogy a hívó felet azonosítani tudjuk. Ez tulajdonképpen a hívó fél telefonszáma is lehetne, azonban adatvédelmi okok miatt ezek nem a tényleges hívó fél telefonszámai, hanem valamilyen módon azokból előállított azonosító. Ez egy string típusú változó az adatbázisban.
D _ SZAM _ KORZET: Ez a mező a hívó fél körzetszámát tartalmazza. Azért van rá szükségünk, hogy meg tudjuk állapítani, hogy vajon az adott hívás az helyi, vagy távolsági hívás. Ezen kívül pedig szükség esetén akár demográfiai információk is visszafejthetők ebből a mezőből. Ez a mező egész számokat tartalmaz, tehát integer[4] típusú.
D _ SZAM _ BIU: Ez tartalmazza azt az információt, hogy egy adott ügyfél milyen ügyfélcsoporthoz tartozik. Az adatbázisban több mint 182 ügyfélcsoport létezik, melyek az [M2] mellékletben hivatkozott helyen megtalálhatók. Azonban amennyiben ez a mező "1" értékű az minden esetben a lakossági, egyéni ügyfeleket tartalmazza. A diplomatervem . fejezetében részletezett okok miatt csak az egyéni előfizetőket vizsgálom, cégek hívásinformációját nem. Így a későbbiekben csak azokat a rekordokat tartottam meg, ahol ez a mező "1" értékű. A mezőben található adat integer típusú.
D _ SZAM _ UGYFEL _ VONALDARAB _ SZAMA: Az elemzések későbbi fázisaiban fény derült arra, hogy egy felhasználó (azaz egy D _ SZAM) 60-70-szer váltott tarifacsomagot. Ez természetesen hibás feltételezés, melynek oka, hogy egy D _ SZAM-hoz több vonal is tartozik melyek más-más tarifacsomag szerint számlázódnak. Így eddig a lépésig vissza kellett lépni a CRISP-DM (2. 5. fejezet) metodika alapján és ezt a mezőt is felvenni a szükséges, vizsgálandó mezők közé. Tehát ez a mező azt az információt tartalmazza, hogy a hívó fél számához hány tényleges vonal tartozik. A legtöbb rekord esetében ez tipikusan "1" értékű, de mint látjuk természetesen előfordulhat, hogy egy számhoz több vonal is tartozik.
B _ SZAM _ KORZET: Ez a mező a D _ SZAM _ KORZET-hez hasonlóan, a hívott fél körzetszámát tartalmazza. Ez a mező szintén integer típusú. Szükséges ezen mező felvétele is, hiszen a D _ SZAM _ KORZET és a B _ SZAM _ KORZET mezőkkel együttesen tudjuk megállapítani az adott hívás típusát (helyi, helyközi, távolsági).
TARTASIDO: Ez a mező tartalmazza az adott hívás hosszát. Értéke egy egész szám, vagyis interger, mely a hívás hosszának másodpercekben kifejezett értéke.
HIVAS _ IDEJE: Ez az attribútum tárolja azt az információt, hogy az adott hívás mikor történt. Értéke egy nagy egész szám, mely az 1970. január 1. -e óta eltelt másodpercek száma az adott hívás időpontjáig. A SZTAKI így tárolta a hívási időpontokat ezért számunkra is ilyen meglepő formátumban áll rendelkezésünkre.
TARIFACSOMAG _ KOD: Ez egy string típusú mező, mely a hívó fél tarifacsomagjának kódja. 48 féle lehetséges értéke van, melyek az [M3] mellékletben találhatók meg.
A hívási adatok a SZTAKI-tól a tanszéki szerverre kerültek, ahol a piped-mine keretrendszer szintén elérhető. A keretrendszerről részletesebb információ diplomatervem 3. 1. 3. 1. fejezetében található, valamint egy általam írt dokumentum is elérhető az irodalomjegyzék pontjánál.
Elkészítettem azt a konfigurációs fájlt, mely elvégezte a szükséges attribútumok kiválasztását. Mivel hatalmas méretű adathalmazról van szó (tömörítetten 28,5 GB) ezért az előző fejezetben említett D _ SZAM _ BIU mező alapján már itt szétválasztottam az egyéni ügyfeleket a vállalati ügyfelektől. Ehhez a művelethez a piped-mine-ban egy filtert definiáltam, mely kiválogatta azokat a rekordokat, melyekben D _ SZAM _ BIU "1" értékű. Ezzel hozzávetőlegesen a hívási adatok felét kiszűrtem az elemzés korai fázisában.
Ahogy az előző fejezetben említettem a későbbi elemzések szükségessé tették a D _ SZAM _ UGYFEL _ VONALDARAB _ SZAMA mező használatát is ezért erre is egy külön filtert írtam, mely csak azokat az ügyfeleket válogatta ki, melyeknek egy vonal tartozik a hívószámukhoz.
Elhagyva ezeket a számomra felesleges rekordokat egy sokkal kisebb méretű adathalmazt kellett csak a hálózaton átmásolnom az itthoni számítógépemre, melyen az elemzés további részét végeztem.
A piped-mine konfigurációs fájl, mely az adatok kitömörítését és a szükséges attribútumok kiválasztását végzi az [M4] mellékletben található.
A kitömörítés után célszerű az adatokat ismét összetömöríteni és így átmásolni a hálózaton, hiszen sok azonos karakter fordul elő bennük, ezért nagy méretcsökkenés érhető el az eljárással. A hálózaton ilyen tömörített formában másoltam át a számomra szükséges adathalmazt. Az így átmásolt majd kitömörített adathalmaz mérete: 34 GB mely 687 481 666 rekordot és az előző fejezetben megjelölt 8 attribútumot tartalmaz.
A SZTAKI 2005. október 3. -tól 2006. április 30. -ig tartó időintervallum hívásait bocsátotta rendelkezésünkre tömörített formában.
A kitömörítés és a szükséges adatok kiválasztása után Clementine segítségével végeztem el az átmásolt adatok elemzését. Az adatbázisban csak a vezetékes hívásokat találtam, mivel az adatokat megvizsgálva a B _ SZAM _ KORZET oszlopban nem találtam mobil irányba menő hívásokat, azaz 20-as, 30-as, 70-es körzetszámot.
A körzetszámokat tovább vizsgálva kiderült, hogy a leghosszabb hívási időtartamok általában az 51-es körzet felé irányulnak. Ami nem is véletlen, hiszen az 51-es körzet a modemes internetszolgáltató körzetszáma. Mivel az adatok 2005. és 2006. évből származnak, ezért ebben az időpontban még jelentősebb volt a modemes internet kapcsolattal webezők száma mint manapság, ezért ez jelentős összeget jelent. Mivel diplomatervem célja a hívási szokások elemzése, ezért a továbbiakban az ilyen irányú hívásokat kivettem a további vizsgálatokból.
Az adatok megismerése sokszor grafikonokkal a legegyszerűbb és legszemléletesebb, így a kiinduló adatokból is készítettem ábrákat. Az adatokat Clementine segítségével összegeztem, majd az adatokat Microsoft Excelbe vittem át és ott készítettem el az ábrákat, melyek közül az alábbiak voltak érdekesebbek. A 3. ábraán a vizsgált időszakban ábrázoltam az összes hívás összegét, minden előfizetőre nézve. A grafikon függőleges tengelyén az adott nap lebonyolított összes hívás időtartamának összegének percben kifejezett értéke látható. Kimagasló számot mutat a Karácsony és Szilveszter, ami érthető is, hiszen ekkor a legtöbben felhívjuk szeretteinket. A többi csúcsérték jellemzően vasárnapi időpontokat mutat, azonban ezek a csúcsértékek nem túlzottan magasak, így ezekből további szokási következmények nem vonhatók le.
. ábra A tartási idők összege a vizsgált időintervallumban
A következő ábrán (4. ábra) az adott napra eső összes hívás időtartamából egy átlagot számoltam. Ez látható a grafikon függőleges tengelyén másodpercekben kifejezve. Az ábrán jellegzetes "tüskék" láthatóak, melyek jellemzően vasárnapra esnek. Ez azzal magyarázható, hogy az előfizetők még vasárnap, a következő hét előtt aránylag hosszabb időtartamban beszélnek szeretteikkel. Mivel az adatbányászat korai fázisában már kiszűrtük csak az egyéni előfizetői hívásokat ( . fejezetben kifejtett okok miatt) ezért a grafikon a cégek hívásait nem tartalmazza, így valószínűleg nem a munka okok miatt indított hívások okozzák a kiugró vasárnapi értékeket.
. ábra A tartási idők átlaga a vizsgált időintervallumban
A következő ábrán ( . ábra) a vizsgált időintervallumban az egyes napokon megszámoltam, hogy hány darab hívás történt. A "tüskék" ezen a grafikonon is jelentkeztek, azonban itt pont a fordított negatív irányban. Azaz a vasárnapi hívások darabszáma mindig kevesebb, mint az egyéb napokon indított hívások.
. ábra A hívások darabszáma az adott időintervallumban
A 4. ábraés . ábra segítségével azonban egy fontos következtetést vonhatunk le a hívási szokásokról. Az ábrákon ugyanazt a két vasárnapi (2006. 01. 29. valamint 2006. 02. 05. ) és hétfői (2006. 01. 30. valamint 2006. 02. 06. ) napot jelöltem meg, mivel általában ez a két nap jelenti a maximumokat és minimumokat. Vasárnap jellemzően kb. 15%-al kevesebb hívást indítunk, mint hétfőn, viszont kb. 40%-al hosszabb (mely nagyjából 100 másodpercnek felel meg) időtartamban beszélgetünk a hívott féllel. Ezzel szemben hétfőn több hívást indítunk, kisebb átlagos híváshosszal. Ez a megállapítás egy fontos hívási szokást jelent.
Azonban a hívásokat nem csak az egyes napokra összegezhetjük, hanem megvizsgálhatjuk azt is, hogy egy nap adott percében hány hívást indítottak. Mindegyik hívásról megállapítottam, hogy a nap mely percében történt, tekintet nélkül arra, hogy a hívás napja hétköznapra vagy hétvégére esett, majd ezeket összegeztem a 6. ábra. Az ábrán két jellegzetes "púpot"fedezhetünk fel. Az első maximumát reggel 8:00 közelében éri el. Ezt követően a délelőtt folyamán kicsit csökken a hívások száma, majd 14:30 körül ismét emelkedni kezd. A második "púp" délután 17:30 körül éri el a maximumát, majd innen fokozatosan csökken az indított hívások mennyisége. Az ábrán nagyon szembetűnő még, hogy a második "púpon" belül tüskéket fedezhetünk fel, melyek szabályosan fél órás időintervallumokkal követik egymást. Valószínűsítjük, hogy ennek oka szoros összefüggésben van a televíziózási szokásokkal, valamint az éppen akkor sugárzott adással. A műsorok többsége általában egész órakor, vagy félkor kezdődnek, így reklámok alatt megnő a hívások mennyisége, majd a műsor alatt nagymértékben rövid idő alatt lezuhan. Végül egy érdekes momentum, hogy a nap végéhez közeledve 23:00-kor még egy utolsó ugrás van a hívások számában, melynek okát nem ismerjük biztosan.
. ábra A nap perceiben indított hívások darabszáma
Az adatok további módosítását már az itthoni számítógépen végeztem el a Clementine adatbányászati szoftver segítségével, mivel ezeket a feladatokat csak sokkal nehezebben, vagy egyáltalán nem is lehetett megoldani a piped-mine keretrendszerben.
Az adatok ellenőrzésekor fény derült arra, hogy egy-két heti hívás információban a szokásos [M3] mellékletbeli tarifacsomag kódok helyet egész számok szerepelnek, melyeknek nem tudtuk a jelentését. Szerencsére ezen adatok kijavítása még időben megtörtént, de szükségessé tette az összes eredmény újrafuttatását.
A 3. 2. 3. fejezetben említettem, hogy jelentős hívási időtartamot jelent az 51-es körzetbe irányuló hívás, vagyis a modemes internet. Ezeket a rekordokat Clementine segítségével eldobtam, mert a későbbi modellezés jobb eredményeket produkált ezen rekordok elhagyásával.
A következő fontos lépés a hívás idejének átalakítása volt, melyet a HIVAS _ IDEJE mező tartalmazott. Ez a mező a 3. 2. 1. fejezetben részletezett módon az 1970. január 1. -e óta eltelt másodperceket tartalmazza. Szerencsére a Clementine szoftverben előre definiált függvények vannak ezen szám átalakítására, így ezeket a másodperceket jelentő számokat könnyűszerrel átalakítottam. Megemlíteném, hogy mivel a tarifacsomagok általában egész órakor váltanak, ezért kezdetben elégségesnek láttam a hívás időpontját úgy átalakítani, hogy dátumot, napot (a hét melyik napja) és órát kapjak. Azonban később kiderült, hogy ez nem elegendő és szükséges lenne percre pontosan tudni a hívások időpontját. Ezért ismét vissza kellett lépni a CRISP-DM módszertan alapján és a perc attribútummal kibővíteni az elemzési adathalmazt.
Ezeket az adattisztítási és átalakítási lépéseket elvégezve előállt az az adathalmaz, melyben már csak egyéni előfizetők adatai vannak (akiknek egy vonaluk van), és nem tartalmaznak internetes hívásokat sem. Így már neki láthattam azon ügyfelek hívásainak kiválasztásához, akik váltottak tarifacsomagot. Ez az eredeti adathalmaz 2 026 352 egyéni ügyfélhez tartozó hívásokat tartalmazza.
Mivel diplomatervem feladata, hogy a tarifacsomagot váltott előfizetők szokását elemezzem, ezért a következő feladatom az volt, hogy a tarifacsomagot váltott ügyfelek hívásait szétválasszam azoktól a hívás rekordoktól, melyek olyan ügyfelekhez tartoztak, akik nem váltottak tarifát.
Ehhez előfizetők azonosítója (D _ SZAM) szerint, majd idő szerint sorba rendeztem a hívásokat, mivel a szerverről az adatok havi bontásban lettek átmásolva. Majd megállapítottam, hogy mely rekordpároknál fordul elő az, hogy két időben egymást követő hívás esetén azonos D _ SZAM-hoz különböző TARIFACSOMAG _ KOD tartozik, azaz mely ügyfeleknél történt váltás. Ezen ügyfelekből egy új adathalmazt készítettem, mely tartalmazta az ügyfelek azonosítóján kívül a tarifacsomag váltását (melyik tarifáról melyikre) illetve a váltás időpontját.
Persze fél éves időintervallumban megesik, hogy egy ügyfél akár 2-szer 3-szor is vált tarifacsomagot. Kétszer váltott tarifacsomagot, 50 186 ügyfél és háromszor 8 086 ügyfél. Azonban ez a szám túl nagy és csak nehezítik a későbbi modellezést, ezért kiválogattam azokat az ügyfeleket, akik csak egyszer tértek át másik számlázási rendszerbe. A futtatás végére 321 191 ilyen ügyfelet találtam, melyet a kiindulási ügyfélszámmal összevetve kiszámítható, hogy fél év alatt az ügyfelek 15,85%-a váltott egyszer számlázási csomagot.
Eloszlás a váltásokról az időintervallumban
Melyik tarifáról melyikre váltottak sokan
Melyik tarifacsomag párt választottam és miért, tarifacsomag információ a netről
Join, havonként és miért.
Az előbbi két adathalmazt az ügyfél azonosítója alapján összeillesztettem (join), így egy olyan hívási adathalmazt kaptam, amiben csak a tarifacsomagot váltott ügyfelek hívásrekordjai vannak. Ez az adathalmaz ????61 639 742???? rekordot tartalmaz és mérete ????3,6 GB????. Ez mekkora méretű, hány rekordja van.
A két tábla összeillesztése, azokhoz a userekhez tartozó rekordok kiválasztása akik váltottak. Problémák, így hány rekord, mekkora méretű.
Hány rekordból hány lett így, ezek mekkora méretűek
További bontás: azon hívásrekordok kiválasztása, akik egy bizonyos tarifáról egy másikba mentek át
Váltás előtti hívás-e, melyik hívási típusba esik. A vektor hogyan épül fel, melyik mezőből épül fel, hogy bontottuk fel a hetet.
Prediktálás - előrejelzés
CRISP-DM - CRoss Industry Standard Process for Data Mining, Iparágfüggetlen Szabványos Adatbányászati Módszertan
Business Understanding - Üzleti célok meghatározása
Data Understanding - Az adatok megismerése
Data Preparation - Adatelőkészítés
Modeling - Modellek alkotása
Evaluation - Eredmények kiértékelése
Deployment - Az eredmények üzleti szintű alkalmazása
Filter - szűrő
Piped-mine - A SZTAKI által fejlesztett komponens alapú keretrendszer
pipestartOrig. headerfields = D _ SZAM
pipestartOrig. headerfields = D _ SZAM _ KORZET
pipestartOrig. headerfields = D _ SZAM _ UGYFELCSOPORT
pipestartOrig. headerfields = D _ SZAM _ BIU
pipestartOrig. headerfields = D _ SZAM _ INSTALLATION _ LINE _ NR
pipestartOrig. headerfields = D _ SZAM _ VONAL _ KEZDO _ DATUM
pipestartOrig. headerfields = D _ SZAM _ LESZERELES _ DATUM
pipestartOrig. headerfields = D _ SZAM _ TELEPULESNEV
pipestartOrig. headerfields = D _ SZAM _ OSS _ TERMEK _ KOD
pipestartOrig. headerfields = D _ SZAM _ ADSL _ FLAG
pipestartOrig. headerfields = D _ SZAM _ MEGSZUNTETES _ TIPUS
pipestartOrig. headerfields = D _ SZAM _ UZEMSZUNET
pipestartOrig. headerfields = D _ SZAM _ HITELKEPESSEG
pipestartOrig. headerfields = D _ SZAM _ FIZETOKEPESSEG
pipestartOrig. headerfields = D _ SZAM _ UGYFEL _ VONALDARAB _ SZAMA
pipestartOrig. headerfields = D _ SZAM _ VONALALLAPOT
pipestartOrig. headerfields = D _ SZAM _ NATURE _ OF _ LINE
pipestartOrig. headerfields = D _ SZAM _ SERVICE _ CATEGORY
pipestartOrig. headerfields = D _ SZAM _ VONALTIPUS
pipestartOrig. headerfields = D _ SZAM _ FIZIKAI _ MEGVALOSITAS _ KOD
pipestartOrig. headerfields = D _ SZAM _ AHIER2 _ KOD
pipestartOrig. headerfields = D _ SZAM _ VALOS _ VONAL
pipestartOrig. headerfields = D _ SZAM _ KSH _ KOD
pipestartOrig. bodyfields = B _ SZAM
pipestartOrig. bodyfields = B _ SZAM _ KORZET
pipestartOrig. bodyfields = TARTASIDO
pipestartOrig. bodyfields = IMPULZUSSZAM
pipestartOrig. bodyfields = UJRADIJAZOTT _ OSSZEG
pipestartOrig. bodyfields = KORREKCIOS _ OSSZEG
pipestartOrig. bodyfields = OCP _ KEDV _ OSSZEG
pipestartOrig. bodyfields = HIVAS _ IDEJE
pipestartOrig. bodyfields = TARIFACSOMAG _ KOD
pipestartOrig. bodyfields = OSS _ TERMEK _ KOD
pipestartOrig. bodyfields = B _ SZAM _ UGYFELCSOPORT
pipestartOrig. bodyfields = B _ SZAM _ BIU
pipestartOrig. bodyfields = B _ SZAM _ INSTALLATION _ LINE _ NR
pipestartOrig. bodyfields = B _ SZAM _ VONAL _ KEZDO _ DATUM
pipestartOrig. bodyfields = B _ SZAM _ LESZERELES _ DATUM
pipestartOrig. bodyfields = B _ SZAM _ TELEPULESNEV
pipestartOrig. bodyfields = B _ SZAM _ OSS _ TERMEK _ KOD
pipestartOrig. bodyfields = B _ SZAM _ ADSL _ FLAG
pipestartOrig. bodyfields = B _ SZAM _ MEGSZUNTETES _ TIPUS
pipestartOrig. bodyfields = B _ SZAM _ UZEMSZUNET
pipestartOrig. bodyfields = B _ SZAM _ HITELKEPESSEG
pipestartOrig. bodyfields = B _ SZAM _ FIZETOKEPESSEG
pipestartOrig. bodyfields = B _ SZAM _ UGYFEL _ VONALDARAB _ SZAMA
pipestartOrig. bodyfields = B _ SZAM _ VONALALLAPOT
pipestartOrig. bodyfields = B _ SZAM _ NATURE _ OF _ LINE
pipestartOrig. bodyfields = B _ SZAM _ SERVICE _ CATEGORY
pipestartOrig. bodyfields = B _ SZAM _ VONALTIPUS
pipestartOrig. bodyfields = B _ SZAM _ FIZIKAI _ MEGVALOSITAS _ KOD
pipestartOrig. bodyfields = B _ SZAM _ AHIER2 _ KOD
pipestartOrig. bodyfields = B _ SZAM _ VALOS _ VONAL
pipestartOrig. bodyfields = B _ SZAM _ KSH _ KOD
Excel táblázat, mely az ügyfeleket tartalmazza:
https://www. hszk. bme. hu/~fg497/dm/doc/ugyfelcsoport _ biu. xls
Row # TARIFACSOMAG _ KOD TARIFACSOMAG _ NEV
1 U Ismeretlen
2 U Bázis csomag
3 BBB Barangoló
4 CBC CBC LTO-S tcs.
5 FAV Favorit usp.
6 HTC Bázis csomag
7 KKK Kontroll
8 OPE Optimist üzl.
9 RUE Ritmus üzl. egy.
10 SOK Új sokatm. tcs.
11 SOK Sokatmondó tcs.
12 TBO Turbo ISDN. tcs.
13 TST Teszt díjcsomag
14 V8V V8 vállalkozói
15 BELU Belföldi csomag
16 BIZU Minimál díjcsom
17 BPLU Csevegő díjcsom
18 FPLU Favorit Plusz
19 HETU Hétvégi csomag
20 KORM Kormányzati tcs
21 MINU Mindenkinek cs.
22 R100 Ritmus100
23 R200 Ritmus200
24 R300 Ritmus300
25 RITU Ritmus csomag
26 RUZL Ritmus üzleti
27 SPEC Speciális tcs.
28 UFEL Üzleti felező
29 UTBO Üzleti turbó
30 VOCA VoCATV díjcs.
31 BAZIS Bázis díjcsom.
32 TPCBC Teleperc CBC
33 TPERC Teleperc dcs.
34 TPPAR Teleperc Part.
35 WIMAX WIMAX USP.
36 FELEZO Felező tcs.
37 LTCSEV Csevegő LTO tcs
38 RCSUCS Ritmus csúcs
39 RHELYI Ritmus helyi
40 RMOBIL Ritmus mobil
41 RSTAND Ritmus standard
42 FEPLUSZ FelezőPlusz tcs
43 LTOCSEV Csevegő LTO tcs
44 LTOR100 R100 CBC tcs.
45 R1PLUSZ Ritmus100+
46 R2PLUSZ Ritmus200+
47 R3PLUSZ Ritmus300+
48 RBELFOLD Ritmus belföldi
###
Ez a komponens vegzi a fajlba irast
### letrehozzuk majd beallitjuk a parametereit
create. coord = textwriter
coord. filename = fg200510. txt
coord. writeheader = 1
coord. separator = |
#coord. link = pipestartOrig
#coord. link = dbg
coord. link = filterelementLakossag
###
Ez egy szuro, mely csak a lakossagi elofeizetoket valogatja ki
### azaz azokat a sorokat, ahol D _ SZAM _ BIU = 1
create. filterelementLakossag = filterelement
filterelementLakossag. link = filterelementVonaldarab
filterelementLakossag. create. int32filter1 = int32filter
filterelementLakossag. int32filter1. field _ name = D _ SZAM _ BIU
filterelementLakossag. int32filter1. op = ! =
filterelementLakossag. int32filter1. value = 1
filterelementLakossag. filterobject = int32filter1
###
Az 1 vonaldarabszamu ugyfelek kivalogatasa
### azaz ahol D _ SZAM _ UGYFEL _ VONALDARAB _ SZAMA = 1
create. filterelementVonaldarab = filterelement
#filterelementVonaldarab. link = dbg
filterelementVonaldarab. link = pipestartOrig
filterelementVonaldarab. create. int32filter2 = int32filter
filterelementVonaldarab. int32filter2. field _ name = D _ SZAM _ UGYFEL _ VONALDARAB _ SZAMA
filterelementVonaldarab. int32filter2. op = ! =
filterelementVonaldarab. int32filter2. value = 1
filterelementVonaldarab. filterobject = int32filter2
###
Ez egy hasznos debug eszkoz,
### ez csak maxnumbernyi embert porget vegig a rendszeren
create. dbg = sampling _ debug
dbg. link = pipestartOrig
dbg. maxnumber = 50000
###
Ez a kitomorito elem, itt adom meg hogy melyik filebol dolgozzon
### es hogy milyen mezoket csomagoljon ki.
### A kitomorito elem neve legyen: pipestartOrig
create. pipestartOrig = decoder
#### Ekkor a temp file-okat eltunteti maga utan
#pipestartOrig. file _ operation = -1
#### Ekkor meghagyja a temp file-okat
#pipestartOrig. file _ operation = 0
#### Ekkor kepes meglevo tempfileokbol dolgozni
#pipestartOrig. file _ operation = 1
### Bementi fajlok megadasa
pipestartOrig. sourcefilename = /export/1/compressed _ data/20051003-20051009. dat
pipestartOrig. sourcefilename = /export/1/compressed _ data/20051010-20051016. dat
pipestartOrig. sourcefilename = /export/1/compressed _ data/20051017-20051023. dat
pipestartOrig. sourcefilename = /export/1/compressed _ data/20051024-20051030. dat
### A kivant attributumok beallitasa
pipestartOrig. headerfields = D _ SZAM
pipestartOrig. headerfields = D _ SZAM _ KORZET
pipestartOrig. headerfields = D _ SZAM _ BIU
pipestartOrig. bodyfields = B _ SZAM _ KORZET
pipestartOrig. bodyfields = TARTASIDO
pipestartOrig. bodyfields = HIVAS _ IDEJE
pipestartOrig. bodyfields = TARIFACSOMAG _ KOD
Találat: 5287
