Informatika | Tanulmányok, esszék » ClickS, weblog elemző adatpiac

ClickS – weblog elemző adatpiac fejlesztői dokumentáció Tartalomjegyzék: 1. Bevezetés, problémafelvetés . 3 1.1 Adattárház, adatpiac (data mart) . 3 1.2 OLAP elemzések . 3 1.21 Multidimenzionális adatabsztrakció . 4 1.22 OLAP műveletek . 4 1.3 Webszerver, weblog, weblog-elemzések . 5 1.31 A webszerver kliens – szerver architektúrája . 5 1.32 A webszerver logfile-jai . 5 1.33 A weblog rögzítés és elemzés terminológiája . 6 1.4 ClickStream adattárházak . 7 1.5 A ClickS csomag feladata, a dolgozat célja . 7 2. Az elemzendő weblogok szerkezete 8 2.1 Common Log Format (CLF) . 8 2.2 Extended Common Log Format (ECLF) (combined log format) . 9 2.3 Egyéb lehetséges leíró adatok . 9 3. Az adatpiac komponensei 10 3.1 Adattárház komponensek általában . 10 3.2 Komponensek a ClickS esetében . 10 3.21 ETL (Extraction, Transformation and Load) komponensek . 11 3.22 Adatbázison belüli adminisztrációs eszközök, adatszolgáltató eszközök . 11 3.23

Riportozó felület . 11 3.24 A fejlesztéshez és megvalósításhoz használt szoftverelemek . 11 3.3 Az alkalmazáscsomag szerkezete. 12 4. Az adatbázis szerkezete, kialakítása 12 4.1 Az adatbázis előkészítése . 12 4.2 A relációs adattárház sémák, tervezésük folyamata . 13 4.21 A csillag / hópehely séma. 13 4.22 A tervezés folyamata . 14 4.3 Felbontás meghatározása. 14 4.4 Dimenziótáblák . 14 4.41 Dátum dimenzió . 15 4.42 Idő dimenzió . 15 4.43 Host dimenzió – domain hierarchia . 16 4.44 Oldal dimenzió – oldal hierarchia . 16 4.45 Referrer dimenzió . 17 4.46 Remote user, auth user dimenzió . 17 4.47 Satus code dimenzió . 18 4.48 HTTP protocol dimenzió . 18 4.49 HTTP request dimenzió . 18 4.410 Agent dimenzió 19 4.411 Operációs rendszer dimenzió 19 4.412 Esemény-típus dimenzió 19 4.5 Ténytábla . 20 4.6 A teljes adatbázisséma . 21 4.7 Staging terület . 22 5. Előfeldolgozási, adattöltési lépesek 22 5.1 Az előfeldolgozó

szerkezete. 22 5.2 Modulok . 22 5.21 module ECLFParser.pl 22 5.22 module filter.pl 23 5.23 module host.pl 23 5.24 module pages.pl 23 5.25 module opsystem.pl, module agentpl 23 5.26 module referrer.pl 23 5.27 module session event.pl 23 5.3 Adattöltés az SQL*Loader Oracle eszközzel . 24 5.4 Adatbázison belüli feldolgozás PL/SQL programjai . 24 5.41 DW MAINTAIN DIMENSIONS csomag . 24 5.42 DW QUERY DIMENSIONS . 25 5.43 DW MAINTAIN IMPRESSION FACT csomag . 25 5.5 Statikus dimenziók inicializáló programjai . 25 6. Beszámolók, riportozó felület – hab a tortán 25 6.1 A riportozó felület architektúrája . 26 6.2 A riportok megvalósítása . 26 7. Teszt 27 7.1 A teszt hardver-környezete. 27 7.2 A teszthez használt logadatok . 27 7.3 ETL eszközök tesztje . 27 7.4 Adatbázis eszközök tesztje . 27 7.5 Riportozó eszközök tesztje . 27 8. Ismert hibák, hiányosságok 28 9. Lehetséges fejlesztési irányok 28 9.1 Aggregátumok kezelése . 28 9.2 Bővített

logfile formátumok kezelése . 29 9.3 Session központú ténytábla kialakítása . 29 9.4 Adminisztrációs felület, metaadat-kezelés kialakítása . 29 9.5 Riportozó felület fejlesztése . 29 9.6 Agent string megfelelő feldolgozása . 29 2 1. Bevezetés, problémafelvetés A dolgozat célja egy általános OLAP jellegű elemzéseket támogató weblog adatokat tároló adatbázis, valamint a megfelelő kapcsolódó eszközök kialakítása. Ehhez röviden tekintsük át a következőkben fogalmakat, használandó technológiákat, módszereket! 1.1 Adattárház, adatpiac (data mart) Tekintsük át néhány mondatban az adattárház fogalmának megértéséhez szükséges hátteret. Mára a különböző, alapvetően profitorientált gazdálkodó szervezetek, vállalatok többnyire rengeteg működési adatot halmoztak fel. Ezek az adatok (gondoljunk a logisztika, a számlázás, a vevőnyilvántartás vagy épp a tartalomszolgáltatás naplózásának feladatkörére)

többnyire szükségesek a szervezet megfelelő napi működéséhez. Emellett azonban megfelelő kezelésükkel, feldolgozásukkal hatékony eszközt jelenthetnek a vállalatirányítás kezében, a megfelelően támogatott döntések, hatékony irányítás pedig szerencsés esetben piaci előnyben, profitnövelésben realizálódhat. Ehhez az adatfeldolgozó, tudáskinyerő folyamathoz fejlődött ki az adattárházak elmélete, gyakorlata az elmúlt tíz évben. Gyakran idézett, és általánostan elfogadott Bill Inmon adattárház definíciója: „Az adattárház tárgyorientált, integrált, tartós és időfüggő adatgyűjtemény a vezetői döntéstámogatás szolgálatában.” (1996) A fogalom további részletezése most nem célunk, de mindenképp érdemes átböngészni az irodalomjegyzéket. (Többek közt a diplomamunkám is tartalmaz adattárház-elméleti összefoglalót, ami megtalálható a http://people.infeltehu/zorro/Work/DW/ url-en) Az adatpiac, „data

mart” fogalma szorosan kapcsolódik az adattárház fogalomhoz. Legegyszerűbben azt mondhatjuk, hogy az adatpiac egy viszonylag kisebb méretű, speciális feladatot ellátó adattárház-megoldás. A mi esetünkben a dolgozat céljaként kitűzött alkalmazáscsomag leginkább ezért az adatpiac kategóriába eshet, célja a webszerver-logok hatékony, integrált, időfüggő elemzése. 1.2 OLAP elemzések A (valamilyen adatbázison) online elemző rendszerek egyre széleskörűbb elterjedésével együtt nőtt az igény egy általános követelményrendszer felállítására ezen rendszerekkel szemben. Erre jelentett megoldást az OLAP fogalmának bevezetése OLAP: On Line Analitical Processing, az online analitikai feldolgozás. 1992-ben E.FCodd publikált egy cikket, melyben bevezeti az OLAP fogalmát, és 12 pontban definiál egy általa felállított követelményrendszert. Ez a definíció az online analitikai rendszerekre az idők során általánosan elfogadottá vált. A

12 pont szerint az OLAP rendszerek kliens-szerver modellűek, multidimenzionális adatabsztrakciót nyújtanak (az adatok tárolásának technikai részletei elrejtve) az elemző felhasználó felé, válaszadási sebességük megfelel az online elemzések követelményeinek, biztosítja a konkurens felhasználást, a rugalmas beszámolókészítést. 3 Jelen esetben az alkalmazás fejlesztésénél megpróbáltam minél inkább igazodni ezekhez az irányelvekhez, elvárásokhoz. 1.21 Multidimenzionális adatabsztrakció Multidimenzionális adatabsztrakció alatt értjük az adatok egy speciális, könnyen elemezhető és képszerű kezelési módszerét. E szerint az adatainkat úgy kezeljük, mintha egy n-dimenziós kocka pontjai lennének. Az adatok mindig valamilyen mérhető, mennyiségi jellegű adatok, melyeket többféle módon tudunk jellemezni. Ezeket a jellemzőket nevezzük dimenzióknak, melyek többnyire valamilyen diszkrét értékkészlettel rendelkeznek, valamit,

az értékeket gyakran rendezzük valamilyen hierarchikus szerkezetbe. Az így (általában is gyakran csak intuitív módon) intufelvázolt szerkezetet nevezzük adatkockának. Példaként nézzünk meg egy adatkockát, ami egy nemzetközi kereskedelmi vállalat eladási adatait tartalmazza termék, idő és eladási hely szerint felosztva: 1. ábra: eladási adatok adatkockája 1.22 OLAP műveletek Az adatkockába foglalt adatok elemzése, speciális eseteket kivéve, felveti az igényt a kockák közti műveletekre. Itt kimondottan fontosak azok a műveletek, melyek az adatkocka valamilyen végfelhasználó számára mejeleníthető nézetét biztosítják, ugyanis a megjelenítésre legyakrabban komoly korlátot jelent a beszámolóként megjeleníthető két dimenziós táblázatok, és ezekből származtatott egyéb táblázatok, grafikonok osztálya. Tekintsük át a szokványos műveleteket, melyek az elemzés rugalmasságát, megjeleníthetőségét biztosítják. (Ezek

adatkockáról adatkockára képző műveletekként foghatóak fel.) 4 • • • • • Aggregáció (roll up) Egy adott dimenziót kihagyunk a felbontásból, azaz a dimenzió elemein végighaladva az adatokat felösszegezzük. Előfordulhat az is, hogy a dimenzió felbontását nem teljesen hagyjuk ki, hanem áttérünk egy kisebb elemszámú hierarchia alkalmazására az adott dimenzióra. (Pl városok helyett országok szerint nézzük adatainkat) Lefúrás (drill down, roll down) Ennek ellentéte, mikor egyre részletezettebben nézzük az adatokat. Pl felbontjuk az összesített eladási adatokat termékekre, vagy a havi összesített adatokat lebontjuk napi adatokra. Pivoting Az adatkocka elforgatását értjük alatta. A kocka felbontása marad, csak a dimenziókat cseréljük fel, ezáltal más nézetét kapva az adatoknak. Szelekció (selection, filtering) Ebben az esetben egy adott dimenzió egy adott elemét kiválasztjuk, és a hozzá tartozó adatokat

nézzük, a többi adatot pedig figyelmen kívül hagyjuk. Ilyen pl., ha kíváncsiak vagyunk egy konkrét fióküzlet bevételeinek alakulására Szeletelés (slicing and dicing) Slicing alatt a szelekcióhoz hasonlóan azt értjük, mikor adott dimenziót fix értékkel lekötünk, és így nézzük a kocka nézetét, szeletét. Dicing alatt a kocka egy részkockájának kivágását értjük. 1.3 Webszerver, weblog, weblog-elemzések Vessünk néhány pillantást az adatpiac tárgyterületeként választott web-kiszólgálók működésére, az alapvető fogalmakra. 1.31 A webszerver kliens – szerver architektúrája A webet böngésző, adott weboldalt lekérő felhasználó számítógépe, valamint a weboldalt kiszolgáló szerver gép klasszikus kiliens-szerver viszonyban állnak. A felhasználó kliense valamilyen böngésző, a szerver valamilyen webszerver, a köztük lévő csatorna szerepét az internet látja el, a kommunikáció protokkolja pedig a Hypertext Transfer

Protocol (http) valamelyik változata. 1.32 A webszerver logfile-jai A webszerver működése során a különböző, működésével kapcsolatos eseményeket napló file-okba rögzíti. Ezek a naplófile-ok az események típusától függően, általánosan elfogadott és használt módon a következő típusú logfile-okba kerülnek: • AccessLog Számunkra a leglényegesebb naplófile típus. Ezek a file-ok tartalmazzák a webszerverhez befutott kérések adatait, valamint adatokat a kérés kiszolgálásáról. (A későbbiekben ezt még részletezzük) 5 • • ProxyAccessLog Adott esetben előfordulhat, hogy a webszerver a proxy kiszólgálók által küldött kéréseket külön naplózza. Ebben az esetben a lekéréseket és a kiszolgálás információit ez a file-típus tartalmazza. ErrorLog A webszerver a normális működésétől eltérő eseményeket ilyen típusú fileokban rögzíti. Ennek elemzése a dolgozatnak nem célja 1.33 A weblog rögzítés és

elemzés terminológiája A következőkben áttekintjük azon fogalmakat, tevékenységének méréséhez használni fogunk. • • • • • melyeket a webszerver Hit (találat): A hit fogalma vonatkozik bármilyen kérésre, melyet a webszerver kapott, majd erről a log file-ban bejegyzést is készített. Ez a kérés vonatkozhat szinte bármire: html oldalakra, képekre, videókra, CGI szkriptekre, stb. A weblog minden egyes sora megfelel egy-egy hit-nek Adott hit jelenléte nem jelenti feltétlenül a kérés kiszolgálását is, előfordulhat például, hogy a szerver valamilyen hibaüzenetet küld vissza. Files: A file hit alatt értjük a kiszolgált, visszadott file-ok találatait. A file mutatóval jelzett érték takarja tehát adott időperiódusban a webszerver által eredményesen kiszolgált, visszaadott (kép, html oldal, stb.) file-ok számát Page hit (oldal találat): Az oldal („page”, esetleg „page-view”) fogalma viszonylag körülményesen

definiálható. Alapvetően cél egy olyan mutatószám bevezetése, amely a letöltött oldalak számát mutatja. Ennek meghatározásához feltétlenül ismernünk kell azonban a weboldalaink szerkezetét, a kiszolgálás technológiáját. Alapesetben az oldalszintű találatok lehetnek azok a hitek, melyek valamely .html, vagy htm file kérésére irányulnak Előfordulhat azonban, hogy az oldal dinamikusan generálódik, ekkor más találatok is jelenthetnek oldal találatot, pl. phtml, php3, pl, stb Fontos azonban, hogy a page-hit nem foglalja magában az oldalt felépítő részegységeket, képeket, hangelemeket, stb, melyek mind külön hit-ként jelentkeznek a weblogban. Sites: Ez alatt értjük az oldalak egy adott halmazát, melyek tematikailag, és esetlegesen technikailag is külön egységet alkotnak. Például, képzeljünk el egy internetszolgáltató céget, aki hasonló körülmények között üzemeltet hírportált, webes levelező rendszert, valamint

szolgáltatás jelleggel más cégek weboldalainak is otthont nyújt. Ekkor az oldalak ilyen kategorizálása válasz lehet arra az igényre, hogy a weboldal-csoportok adatait külön szeretnénk kezelni, elemezni. Sessions: A „session” fogalma takarja adott felhasználó egy látogatása során bejárt, lekért oldalak találatait. A session meghatározását, a lekérések sessionbe sorolását gyakran elvégzi a webszerver, és ennek esetleg nyoma is marad a weblogokban. (A mi esetünkben a weblog formátum nem tartalmaz session jellegű információkat.) A session meghatározásakor általában a kliens azonosítása után megnézzük az (adott site-ra vonatkozó) utolsó lekérésének időpontját, majd pedig ha az új lekérés adott időlimiten (általában fél óra) következett be, az új találatot a session folytatásának tekintjük, ellenkező esetben új session nyitásának. 6 1.4 ClickStream adattárházak A weblog adatok elemzése viszonylag új igény,

kutatása, megvalósítása csak az utóbbi években vált aktív területté. Ennek következménye, hogy referenciaként használható megoldások, tapasztalatok, kutatási eredmények viszonylag kis számban állnak rendelkezésre, főleg igaz ez akkor, ha a weblogelemzések számunkra fontos, adattárházadatbázisos megoldásaira koncentrálunk. Viszonylag általánossá vált már viszont a terület elnevezése. Eszerint „clickstream” alatt értjük a webet böngésző felhasználók szolgáltatóknál hátrahagyott nyomait, képszerűen a kattintgatásainak sorozatát. Ezt az adathalmazt hívják „clickstream”-nek, az ebből készített adattárház megoldást pedig következésképp gyakran „Clickstream Data Warehouse”-nak. Ilyen (többé-kevésbé használható) terméket, szolgáltatást nyújt az Oracle „Oracle Clickstream Intelligence” néven, valamint a SAS is rendelkezik ilyen célú megoldással, ezek érdemesek tanulmányozásra. Gyakran az ilyen

termékek hátrányát az általánosságukból következően a feldolgozható adatmennyiségre vonatkozó viszonylag alacsony tűréshatáruk jelenti. Ez azonban komoly problémákhoz is vezethet, mert a webes szolgáltatók logadatai hatalmas adatmennyiséget jelenthetnek. (Magyar viszonylatban például a vezető hírportálunk forgalma hozzávetőleg napi két millió sornyi logadatban realizálódik, ami havi szinten kb.170 GB-nyi nyers, feldolgozandó adatot jelent) 1.5 A ClickS csomag feladata, a dolgozat célja Jelen esetben a dolgozatnak nem célja az előző alfejezetben említett kihívásokra választ adni. Célja azonban, hogy egy olyan adatbázis alkalmazáscsomag készüljön, ami kisebb site-ok forgalmának elemzésére elegendő, adott esetben pedig használható tapasztalatszerzésre, mérésekre, megoldási alternatívák kipróbálására, és struktúrájából következően alkalmasan bővíthető, skálázható. A következőkben látni fogjuk az architektúra

építőköveit. Előljáróban leszögezném azonban, hogy a hangsúlyt a weblog elemző adatbázis kialakításán, a weblogok előfeldolgozására és adatbázisba töltésére helyeztem. Ennek következménye, hogy a végfelhasználó számára látható riportozó felület (részben persze a részfeladat komplexitásából adódóan is) az alapfunkciók bemutatására korlátozódik, korántsem meríti ki az adatbázis nyújtotta lehetőségek tárházát. 7 2. Az elemzendő weblogok szerkezete A következőkben a webszerver által készített, a lekérések naplózására használt logfile-lal foglalkozunk (pl. accesslog, Apache webszerver esetén) Részletesen ismertetem azt az általánosan elfogadott weblog formátumot, amelyet az alkalmazás képes feldolgozni. Természetesen az elemzések kiterjedhetnének más formátumú, esetleg több, vagy akár kevesebb leíró adatot magába foglaló log-formátumokra is, azonban ezt a lehetőségek nagy száma miatt nem tűztem

ki célul. Törekedtem viszont arra, hogy a még nyers weblogok feldolgozását végző komponensek olyan modulként illeszkedjenek betöltést végző alkalmazásba, melyek adott esetben cserélhetőek, bővíthetőek az éppen adott igényekhez, adott webszerver specialitásokhoz igazítva. Általánosan igaz, hogy a webszerver log bejegyzései egy szöveges file-ba kerülnek. A fileokat a webszerver adott periodicitással cseréli, rotálja, erre bevett módszer a naponkénti új file nyitás webszerverenként. Ekkor az adott nap dátumát gyakran a file neve magában foglalja A file sorai egy, és csak egy a webszerver által kiszolgált kéréshez tartoznak. 2.1 Common Log Format (CLF) A Common Log Format eredetileg az NCSA Server (www.ncsauiucedu) webszerver által lekérések naplózásához használt formátum, ami azonban mára általánosan elfogadottá és használttá vált. ld: http://www.w3org/TR/WD-logfile A következő táblázat egy kiragadott, példa sort tartalmaz

egy CLF formátumú logból. host remote user authuser [date] "request" status bytes 151.9919027 - - "GET /~zorro/index.html http/1.0" 200 [01/Jan/1999:13:07:21 0600] 13276 A weblog sorok egy-egy hitnek felelnek meg. Minden sor mezőkből áll, melyek space szeparátor karakterrel vannak egymástól elválasztva. Amennyiben egy mező nem rendelkezik értékkel, helyére a ’-’ karakter kerül. A megfelelő mezők jelentése a következő: • • • • host: A lekérést kezdeményező gép IP címe vagy a teljes domain neve. Domain név abban az esetben szerepel, ha a webszerver támogatja az IP cím visszafejtését, és az IP cím valóban rendelkezik adott pillanatban érvényes, elérhető domain névvel. remote user: A távoli, lekérést kezdeményező gép által küldött, az RFC931 szabványnak megfelelő user azonosító. Nagyon ritkán használt mező authuser: Amennyiben a kérés kiszolgálása a felhasználó authentikációját

igényli, ebben a mezőben a felhasználót azonosító karaktersorozatot kapjuk vissza, leggyakrabban a felhasználói azonosítót. date: A lekérés pontos dátuma és időpontja. Formátuma a következő sémát követi: 8 • • • [day/month/year:hh:mm:ss zone] ahol mezők jelentése: day: adott hónap napja két számjegyen ábrázolva, pl. „04” month: adott év hónapja két számjegyen, pl. „11” year: teljes négy számjegyű évszám, pl. „1978” hh:mm:ss: óra:perc:másodperc, mindegyik két számjeggyel ábrázolva, pl.:”23:59:59” zone: időzóna információk, négy számjegyen, előjellel ábrázolva (hhmm formátumban), pl. „+0100” request: Akliens által elüldött kérés leírása. „method url protocol/version” formában, ahol: method: a HTTP szabvány metódusainak megfelelő, pl. GET vagy POST url: a kliens által lekért URL protocol/version: a protocol mindig a HTTP protokoll, azt követi annak verziószáma. status: Három

számjegyű azonosító a lekérés eredményességéről. Pl, 200 – OK, 406 – File not found bytes: A szerver által elküldött adatmennyiség byte-okban. 2.2 Extended Common Log Format (ECLF) (combined log format) Az ECLF formátum mindössze annyiban különbözik az előző CLF formátumól, hogy minden sor tartalmaz még két mezőt (ezért az „extended” jelző). host remote auth- [date] "request" status bytes "referer" user user bacuslab. prmcsnet scs [01/Jan/ 1999:12: 57:45 0600] "GET /~zorro/ index.html HTTP/1.0" 304 0 "user agent" "http:// "Mozilla/2.0GoldB1 www.cseltehu/" (Win95; I)" Ezek a mezők pedig: • • referer: A referer mező azt az URL-t tartalmazza, amit a felhasználó böngészője a lekérés előtt látogatott meg („ahonnan érkezett”). Formátuma megfelel a szabvány URL (vagy URI) formátumnak. user agent: Információt nyújt a kliens oldali böngészőről, operációs

rendszerről és ezek verzióiról. Ez az információ egy karaktersorozatként érkezik Léteznek ajánlások ennek formátumára, de sajnos általános szabályt nem tudunk mondani a user agent sztringre. Értékkészlete ezért, a sok különböző típusjelölés, verziószámjelölés, sőt, a böngészőnként kézzel felüldefiniálható érték miatt meglepően nagy lehet. 2.3 Egyéb lehetséges leíró adatok Más logformátumokban találkozhatunk a felhasználói session-t jellemző azonosítóval, esetleg session-cookie-val. 9 3. Az adatpiac komponensei Tekintsük át az adattárház megoldások komponenseit, majd nézzük meg, milyen eszközökben realizálódik ez a ClickS esetében! 3.1 Adattárház komponensek általában Először is fontos kitérni az adat útjára az adatforrástól az elemző végfelhasználóig. Általában az adattárház működése három fontos kulcsmozzanat köré szerveződik, ezek: 1. Adatkinyerés a tranzakciós (vagy más

vállalat-működtetési) rendszerekből 2. A kinyert adatok átformálása riport (beszámoló) készítés számára 3. A riportok, beszámolók elérhetővé tétele a döntéshozók számára A következő ábra ennek megfelelően kicsit részletesebben tartalmazza az adattárház komponenseket: 2. ábra: szokványos adattárház komponensek 3.2 Komponensek a ClickS esetében A megvalósítás során igyekeztem arra törekedni, hogy minél inkább elfogadott, elterjedt technológiákat alkalmazzak. Emellett azonban igaz az is, hogy nincs olyan technológia, amellyel az összes részfeladat megoldható lenne. 10 3.21 ETL (Extraction, Transformation and Load) komponensek Ez a csoport tartalmazza mindazokat az eszközöket, amelyek a weblog file-ok olvasását, feldolgozását és adatbázisba való töltését végzik. Rugalmassága, elterjedtsége és szövegfeldolgozó képességei miatt ezeket az egységeket Perl nyelven megírt modulok képviselik. Az előfeldolgozás

bizonyos lépéseit már adatbázison belül kell megoldani. Adatbázisnak az Oracle 8i-t választottam, mint elterjedt és megbízható adatbázis, valamint az adattárházak irányába való nyitottsága miatt, ebből részben következő módon az előfeldolgozás adatbázison belüli részei a hatékonynak mondott PL/SQL –ben készültek. 3.22 Adatbázison belüli adminisztrációs eszközök, adatszolgáltató eszközök Ez a csoport a metaadatok (adathalmazt leíró adatok) hatékony kezelését, adatbázison belüli adatmozgásokhoz kapcsolódó, valamint az adatszolgáltatást biztosító eszközöket foglalja magába. Erre eszközként szintén a PL/SQL programozási nyelvet használtam. 3.23 Riportozó felület Ide sorolhatók az adatok elemzési célú megjelenítését szolgáló eszközök. Most én egy webes alapú beszámoló felületet céloztam meg, ennek függvényében választottam technológiát. A riportok böngészőben html oldalakként jelennek meg, a

kiszolgálást Apache webszerver végzi, az adatbázis-lekérdezések és beszámoló generálások PHP nyelven lettek implementálva. Ezzel a riportozás folyamata gyakorlatilag semmiféle speciális felhasználó-oldali alkalmazás használatát nem igényli, lévén a böngészők általánosan elfogadott eszközök. 3.24 A fejlesztéshez és megvalósításhoz használt szoftverelemek Felsorolás jelleggel tekintsük át a felhasznált szoftverelemeket (a hardverelemek leírását ld. a tesztelés fejezetben): • • • • • • operációs rendszer: Windows XP – az alkalmazást futtató szerver gépen, valamint Debian Linux a perl előfeldolgozó eszközök fejlesztéséhez adatbázisszerver: Oracle8i Enterprise Edition Release 8.1700 – Production, PL/SQL Release 8.1700 – Production perl interpreter: Perl 5.80 webszerver: Apache/1.312 (Win32) PHP interpreter: Apache-hoz integrált php-4.23-Win32, Oracle8 adatbáziskapcsolati modullal (OCI) adatbázis tervezés,

fejlesztés: tervezés néhol Microsoft Visio eszközzel, implementálás részben PL/SQL Developer 5.12-vel 11 3.3 Az alkalmazáscsomag szerkezete Tekintsük át a ClickS alkalmazáshoz kapcsolódó eszközök struktúráját, követve a filerendszerbeli helyüket! • • • • • • • • [CLICKS HOME/] db-init: Itt találhatók az adatbázis táblák, felhasználók, szekvenciák, csomagok és más objektumok létrehozásához szükséges SQL és PL/SQL scriptek. [CLICKS HOME/] etc: mindenféle egyéb dolog, tesztprogramok, TODO lista kerültek ebbe a könyvtárba. [CLICKS HOME/] etl-bin: Az ETL eszközök könyvtára, főleg perl előfeldolgozó programokkal, valamint PL/SQL töltő programokkal. A feldolgozás egészének végrehajtásáért a main loader.pl script felelős [CLICKS HOME/] etl-config: .tpl kiterjesztésű SQL*Loader definíciós file-ok könyvtára, esetlegesen ide kerülhetnének más beállítás jellegű file-ok. A definíciós file-ok

specifikálják a staging file-ok és a staging táblák szerkezetét. [CLICKS HOME/] etl-log: Ide a betöltés során keletkező logfile-ok kerülnek, segítségével felderíthetők az esetleges hibák, hibás rekordok. [CLICKS HOME/] log-files: Ebben a könytárban találhatók a nyers, feldolgozatlan logfile-ok, amiket fel kell dolgoznunk. [CLICKS HOME/] stage-files: Az előfeldolgozott logfile-okból keletkező staging file-ok helye. [CLICKS PUBLIC HTML/] : A riportozó felület PHP scriptjeinek helye, tulajdonképp ide került a riportozó PHP alkalmazás. Az indexphp file-ból elérhetőek böngészővel a beszámolók 4. Az adatbázis szerkezete, kialakítása Ez a fejezet ismerteti a kialakítandó adatbázis szerkezetét, némi bevezető után. Ez szükséges ahhoz is, hogy áttekinthessük a betöltés folyamatát, valamint a riportozó eszközt. 4.1 Az adatbázis előkészítése Az adatbázis használatához feltétlenül szükséges annak telepítése, megfelelő

beállítása. Ezek után a fejlesztéshez létrehoztam egy specifikus tablespace-t, ami a clickstream adatok tárolását szolgálja, neve ezért CLICKS. Adott esetben létrehozható a jobb kezelhetőség érdekében külön tablespace az indexek számára, sőt, különválaszthatóak lennének (a későbbiekben vizsgált) staging-, fact-, valamint dimenzió-adattáblák is. Egyelőre azonban minden kapcsolódó adatbázistábla ebbe a táblatérbe került. Szintén szükség volt még megfelelő felhasználók létrehozására is. Készült egy fejlesztő és adatfeltöltő felhasználó mindenre kiterjedő jogokkal az adott táblespace-re, valamint egy 12 lekérdező felhasználó, csak lekérdezésre kapva jogot, a riportozó felület számára. (A tablespace és user létrehozó sql-ek megtalálhatóak a mellékletben.) 4.2 A relációs adattárház sémák, tervezésük folyamata Az adattárház elmélet relációs adatbázison alapuló adattárházakra vonatkozó része

egyöntetűen a csillag-hópehely adatbázis séma kialakítását tekinti célravezetőnek. Esetünkben tehát egy ilyen séma alkalmazáshoz szabott megvalósítását tűztem ki célul. Fontos megjegyzés, hogy az elemző alkalmazások igényei miatt elsődleges szempont a válaszidő komplex lekérdezések esetében is elfogadható (gyakran 3-4 másodperces felső határral) szinten tartása. Ennek egyik eszköze a redundáns adattárolás, ún denormalizáció, ami az általános adattárház elmélet normalizációs törekvéseivel épp ellentétes. Ennek eredményei viszont jelentkezhetnek már az adatbázis séma szintjén is 4.21 A csillag / hópehely séma Az előzőekben tárgyalt multidimenzionális adatfogalom kiszolgálásához alkalmazott relációs módszer a csillagséma kialakítása (nevét a táblák és kapcsolataik árbrázoása után kapta). Ekkor az adatokat egy központ, ún tény-tábla tartalmazza, ebben szerepelnek az adott mutatók, amik jellemzően

valamilyen számértékek, valamilyen mérőszámok, valamint túlnyomórészt értelmezve van rajtuk az összegzés művelete. A hozzá idegen kulcsokkal kapcsolódó ún. dimenzió-táblák tartalmazzák a ténytábla elemeinek jellemzőit. A dimenziótáblák jellemzően nagyságrendekkel kisebb méretűek a ténytáblánál, viszont sok, esetleg fölöslegesnek vélt adatot is tartalmazhatnak, melyek mind az elemzések rugalmasságát növelik. Példaként képzeljük el a dátum dimenziót, ahol szerepel egy adott napról pl. hogy a hét hanyadik napja, sőt, annak neve is, melyek elméletben (bár nagyobb időráfordítással és kevésbé konzisztens módon) utólag, frontend oldalon is meghatározhatók lehetnének. A dimenziótáblák között lehetnek statikusak, melyek tartalma nem változik, lehetnek viszont lassan változó tartalmú dimenziótáblák is, pl. vevő dimenzió A következő ábra egy példa csillag-sémára. 3. ábra: az eladási adatkocka megvalósítása

13 Hópehely sémáról akkor beszélhetünk, ha a dimenziótáblákhoz még kapcsolódnak a dimenziót leíró egyéb táblák, pl. termék dimenzió egy kulcsa mutat a termékhierarchiákat tartalmazó külön táblára. 4.22 A tervezés folyamata Nézzük meg a Kimball által [] javasolt négylépcsős relációs adattárház-tervezési metódust! 1. modellezendő üzleti folyamat kiválasztása pl: raktárkészlet nyilvántartások 2. felbontás (granularity) meghatározása pl: raktárkészlet termékenként, naponként, raktárhelyiségként, szállítóként,stb. 3. dimenziók meghatározása, kidolgozása pl: termék: név, súly, szín, beszerzési ár, stb. 4. tényadatok meghatározása pl: raktári mennyiség, súly, érték, minőségi mutatók, stb. A tervezés során igyekeztem ezt a modellt követni. Fontos, hogy a tervezés folyamatában iteratív jellegű, tehát a lépésekre vissza lehet és kell is térni, minél jobban megismerjük az adott terület

specialitásait, tulajdonságait. A ClickS esetében az adott üzleti folyamat a webkiszolgálás, a weblogok tárolásának folyamata, erre a következőkben nem térünk ki. 4.3 Felbontás meghatározása A felbontás meghatározásakor felső korlátot értelemszerűen a weblog file-ok felbontása jelent, vagyis, nem tárolhatjuk adatainkat a hitek szintjénél részletesebben. Ezt figyelembe véve választhatunk azonban nagyobb granunaliráts is. Lehetőségként felmerül a pagehitek szintjén való tárolás, a session-önkénti tárolás valamint akár nagyobb gyűjtőkategóriák is, mint visit-enkénti, vagy host-onkénti tárolás. Elsődlegesen ezek közül igazán használhatónak a page-hit szerinti, valamint a session-szerinti felbontások bizonyultak, ezek közül most a page-hit szerinti tárolást céloztam meg, bár a kidolgozott megoldásba esetlegesen jól illeszkedik egy későbbi session-jellegű felbontással készült ténytábla is, amennyiben session adatokat

tartalmazó logfile-okkal rendelkezünk. 4.4 Dimenziótáblák Nézzük át ezek után a kidolgozott hópehely-jellegű struktúrát! A táblák nevei DW prefixűek, a később tárgyalt staging táblák STG -vel kezdődnek. Fontos különválasztani a dimenziótáblákat abból a szempontból, hogy a dimenzió elemei változnak-e, és ha változnak, milyen gyorsan. A statikus, nem változó dimenziók csak kezdeti, iniciális feltöltést igényelnek, a változó dimenziók viszont valamilyen állandó frissítést. Szintén fontos még megjegyezni azt is, hogy célszerű a dimenziótáblák kulcsait minél kisebbre választani, valamint jelentéssel nem felruházni. Ezzel csökkenhet a központi ténytábla mérete, valamint nem lesz kikerülhető a dimenziótáblák használata, ami most 14 részemről szándékolt koncepcionálisan tervezett kényszerként fogható fel. Jellemzően a dimenziótáblák rendelkeznek egy ID mezővel, amihez tartozik egy-egy sequence objektum,

ami új dimenzióelemek felvételekor az ID-k konzekvens generálását szolgálja. A dimenziótáblákhoz tartalmazó ábrák csak áttekintés jelleggel tartalmazzák a tábla attribútumait, a táblák pontos specifikációja megtalálható a mellékletben. A dimenziótáblák elemeire jellemző, hogy legtöbb tartalmaz egy elemet arra az esetre, ha valahol az adott jellemzőt nem ismernénk, ennek értéke áltatlában a „Nem ismert.” érték Ennek célja, hogy az elemzések során a nem ismert értékeket ne mint nullértékek kelljen kezelni, hanem azokat felismerve az elemzések szerves részét alkothassák. 4.41 Dátum dimenzió Az Oracle biztosít számunkra egy date, dátum adattípust. Ez a típus alkalmas arra, hogy attribútumként tároljunk egy időbélyeget, ami magában foglal egy dátumot valamint egy napon belüli időpontot másodperces felbontással. Annak az oka, hogy az oldaltalálatok tárolásához mi mégis külön dátum és idő dimenziótáblákat

használunk, abban rejlik, hogy a dátum adattípus elemzési szempontból kevéssé használható, viszonylag kevés információt tartalmaz, és kezelése is nehézkes a jellemző OLAPszerű lekérdezések használatakor. Ezzel szemben, ha egy külön dimenziótábla tartalmazza a dátum és a napi idő jellegű adatokat, sok attribútummal, lehetségessé válik A dátum dimenzió statikus, új elemek jellemzően nem kerülnek bele használat során. Elemszáma viszonylag kicsi, 100 évnyi adat esetén is csak 36500 sor lenne, de most én megelégedtem két évnyi dátumadat feltöltésével. DW CALENDAR DAY PK DATE KEY DAY COMMENT START DATE END DATE YEAR QUARTER OF YEAR QUARTER NAME MONTH OF YEAR MONTH NAME MONTH LASTDAY NUMBER WEEK OF YEAR DAY OF YEAR DAY OF MONTH DAY OF WEEK WEEKDAY NAME DAY TYPE NAME 4. ábra: dátum dimenzió 4.42 Idő dimenzió Az idő dimenzió adott napon belüli időpontok tárolását szolgálja, másodpercnyi pontossággal. Elemszáma ebből

következően 86400, ami nem változik 15 DW TIME OF DAY PK TIME KEY HOUR OF DAY MINUTE OF HOUR MINUTE OF DAY SEC OF MINUTE TIME CATEGORY 5. ábra: idő dimenzió 4.43 Host dimenzió – domain hierarchia A host dimenzió tartalmazza a kliensek IP számából meghatározott kliens hostokat. A dimenzió elemei IP cím szerint egyértelműek, az IP-hostnév hozzárendelés többértelműségével most nem foglalkozunk, a nyilvántartás alapja az IP cím, ennek csak egy attribútuma a host-név. DW HOSTS PK HOST KEY FK1 HOST IP HOST NAME HOST DESCRIPTION DOMAIN KEY VALID FROM VALID TO DOMAIN ID DW DOMAINS PK DOMAIN ID PARENT DOMAIN ID DOMAIN NAME DOMAIN DESCRIPTION DOMAIN LEVEL NUMBER VALID FROM VALID TO 6. ábra: host dimenzió és domain hierarchia Az IP alapú host nyilvántartáshoz kapcsolódik egy hostnév alapú domain nyilvántartás, ami egy hierarchikus lekérdezéseket lehetővé tévő táblázat. Az előfeldolgozás során a visszafejtett hostnevekről

levágjuk azok domain-tartomány részét, majd azt feldolgozva bekerülnek a DW DOMAINS táblába. Pl, a „pandora.infeltehu” a domain táblában jelentkezik mint 1szintű „hu”, 2szintű „elte.hu” és 3szintű „infeltehu” domain, ezek megfelelő szülő kapcsolatával 4.44 Oldal dimenzió – oldal hierarchia Az oldal dimenzió tartalmazza azokat az oldalakat, melyekre érkezett lekérés a webszerverhez. Megfontolás tárgyát képezheti, hogy az elhibázott, kiszolgálhatatlan lekérések oldal-hivatkozásai bekerüljenek-e az oldal táblába, ez ugyanis annak (esetleg viszonylag gyors) konstans növekedésével járhat. Az oldal hierarchia szintén dinamikusan változó dimenzió. 16 DW PAGES PK DW PAGES FK1 HOST URL DESCRIPTION PAGE TYPE LANGUAGE VALID FROM VALID TO CREATOR OWNER PAGE HIERARCHY HIERARCHY KEY DW PAGE HIERARCHY PK HIERARCHY KEY PARENT KEY DESCRIPTION LEVEL NUMBER VALID FROM VALID TO 7. ábra: oldal dimenzió és oldalhierarchia Az

oldalhierarchia tábla biztosítja gyakorlatilag bármiféle oldal-hierarchikus szerkezet kialakítását, definiálását. Ez akár egybeeshet az URL-ben lévő könyvtárhierarchiával, de valószinűleg más logikai struktúrára van igény, mint a konkrét fizikai oldal-tárolás hierarchia. 4.45 Referrer dimenzió A referrer dimenzió tartalmazza a hitekhez tartozó hivatkozó host-adatokat, a hivatkozó url-ből feldolgozott hostnévvel (és ahhoz kapcsolódva a domain hierarchia adataival), a hoston lévő oldallal valamint url paraméterekkel (ami kereső referreroldalak esetén lehet érdekes például). DW REFERRER PK DW REFERRER URL HOST PAGE ID URL PAGE URL PARAMETERS TYPE DESCRIPTION LOCAL DOMAIN ID 8. ábra: referrer dimenzió 4.46 Remote user, auth user dimenzió A remote user (távoli felhasználó) és auth user (azonosított felhasználó) dimenziók külön dimenziótáblával nem rendelkeznek, ún. degenerált dimenziók Ennek oka, hogy az elemzendő

logadatokban csak ritkán fordul elő ilyen jellegű információ, és az sem túl sok információval bír. Így a remote user és auth user adatok közvetlenül a tényadattáblába kerülnek mint adat 17 4.47 Satus code dimenzió A status code dimenzió a http protokoll megfelelő verziója által használt status codokat tartalmazza. Például, az ismertebbek : 200 – OK, 404 – Not Found Minden kód első számjegye meghatározza, hogy milyen kategóriájú az üzenet, a dimenzió ezeket a kategóriákat is tartalmazza, denormalizált, a táblába integrált (és ezért redundáns, de válaszidő-kímélő) módon. Mivel a status code-ok előre definiáltak, ezért ez a dimenzió statikus, csak kezdeti feltöltést igényel. DW STATUS CODE PK DW STATUS CODE STATUS CODE NAME STATUS CODE DESCRIPTION STATUS TYPE DESCRIPTION STATUS TYPE 9. ábra: Status code dimenzió 4.48 HTTP protocol dimenzió A protokoll dimenzió a gyakoribb http változatokat tartalmazza névvel,

rövid leírással. A dimenzió statikus, elemei változatlanok. DW HTTP PROTOCOL PK ID NAME DESCTIPTION 10. ábra: HTTP protocol dimenzió 4.49 HTTP request dimenzió Tartalmazza a http által definiált kérés típusokat. A legelterjedtebbek ezek közül a GET, POST, HEAD, de a dimenzió tartalmazza az összes specifikált metódust. Elemei nem változnak, statikus. DW HTTP REQUEST PK ID NAME DESCRIPTION HTTP PROTOCOL 11. ábra: Request code dimenzió 18 4.410 Agent dimenzió A logfile „agent string” mezője a böngésző (vagy letöltő, esetleg valamilyen robot) kliens által definiált és elküldött karaktersorozatot tartalmazza. Ebben normál esetben szerepel információ a kliens oldali operációs rendszerről valamint a kliens programról. Az agent dimenzió ebből a kliens program típusait tartalmazza. Fontos azonban tudni, hogy az „agent string” a kliensek nagy száma miatt rendkívül sokféle formátumú és információtartalmú lehet, annak

megfelelő feldolgozása komoly feladat. Én most megelégedtem az ismertebb operációs rendszer platformok, változatok valamint ismertebb böngészők és letöltőprogramok detektálásával. Az agent dimenzió folyamatosan bővül, annak függvényében, hogy előfeldolgozás során milyen új kliens típusokat találunk, azok bekerülnek új elemként a dimenziótáblába. DW AGENT PK ID CLIENT TYPE CLIENT MAJOR VERSION MINOR VERSION 12. ábra: Agent típus dimenzió 4.411 Operációs rendszer dimenzió Az előzőekben leírt információ másik oldala a kliens oldali operációs rendszer típusa, ezt tartalmazza ez a dimenziótábla. Értelemszerűen szintén dinamikusan változik DW OPSYSTEM PK ID PLATFORM PRODUCT MAJOR VERSION MINOR VERSION 13. ábra: Kliens operációs rendszer dimenzió 4.412 Esemény-típus dimenzió Az eseménytípus dimenzió biztosít számunkra lehetőséget az oldal-találatok saját szempont szerinti csoportosítására. Ez a csoportosítás

kerül ebbe a dimenziótáblára A ClickS esetében a tábla session jellegű információkat tartalmaz, melyeket az előfeldolgozás során tárunk fel. Ez az információ konkrétan adott page-hit és session viszonyára utal. Értékei: session kezdő hit, session záró hit, session köztes hit, session kezdő és egyben záró hit. 19 DW EVENT TYPE PK ID TYPE NAME TYPE DESCRIPTION 14. ábra: Esemény-típus dimenzió 4.5 Ténytábla A dimenziótáblákat ismerve határozzunk most meg a ténytábla szerkezetét. A ténytábla kialakítása megfelel a célként kitűzött felbontás eléréséhez, tartalma soronként egy-egy oldal-találat, idegen kulcsokként pedig tartalmazza a dimenziók kulcsait. Érdekes adalék, hogy a hagyományos ténytábláktól eltérően a miénk most nem tartalmaz mennyiségi elemeket, hiszen az minden sorban az „1 page hit” érték lenne (ún. „factless fact table”) DW PAGE IMPRESSIONS FACTS FK4 FK5 FK8 FK10 FK6 FK2 FK9 FK1 FK11 FK7

FK3 JOB ID ENTRY DATE HOST REMOTE USER AUTH USER CALENDAR DAY TIME OF DAY HTTP REQUEST HTTP PROTOCOL PAGE STATUS CODE REFERRER CLIENT OPSYSTEM CLIENT AGENT EVENT TYPE REQUEST PARAMETER STRING 15. ábra: Oldal-találat ténytábla 20 4.6 A teljes adatbázisséma DW DOMAINS PK DW PAGE HIERARCHY PK DOMAIN ID PARENT DOMAIN ID DOMAIN NAME DOMAIN DESCRIPTION DOMAIN LEVEL NUMBER VALID FROM VALID TO HIERARCHY KEY PARENT KEY DESCRIPTION LEVEL NUMBER VALID FROM VALID TO DW REFERRER ID FK1 FK2 URL HOST PAGE ID URL PAGE URL PARAMETERS TYPE DESCRIPTION LOCAL DOMAIN ID DW PAGES DW PAGES PK ID FK1 HOST URL DESCRIPTION PAGE TYPE LANGUAGE VALID FROM VALID TO CREATOR OWNER PAGE HIERARCHY HIERARCHY KEY DW HOSTS PK PK HOST KEY FK1 HOST IP HOST NAME HOST DESCRIPTION DOMAIN KEY VALID FROM VALID TO DOMAIN ID DW TIME OF DAY PK HOUR OF DAY MINUTE OF HOUR MINUTE OF DAY SEC OF MINUTE TIME CATEGORY DW CALENDAR DAY DW PAGE IMPRESSIONS FACTS PK FK4 DW EVENT TYPE PK ID TYPE NAME TYPE

DESCRIPTION DW AGENT PK FK5 FK8 FK10 FK6 FK2 FK9 FK1 FK11 FK7 FK3 ID TIME KEY DATE KEY DAY COMMENT START DATE END DATE YEAR QUARTER OF YEAR QUARTER NAME MONTH OF YEAR MONTH NAME MONTH LASTDAY NUMBER WEEK OF YEAR DAY OF YEAR DAY OF MONTH DAY OF WEEK WEEKDAY NAME DAY TYPE NAME JOB ID ENTRY DATE HOST REMOTE USER AUTH USER CALENDAR DAY TIME OF DAY HTTP REQUEST HTTP PROTOCOL PAGE STATUS CODE REFERRER CLIENT OPSYSTEM CLIENT AGENT EVENT TYPE REQUEST PARAMETER STRING CLIENT TYPE CLIENT MAJOR VERSION MINOR VERSION DW HTTP PROTOCOL PK ID NAME DESCTIPTION DW OPSYSTEM PK DW HTTP REQUEST ID PLATFORM PRODUCT MAJOR VERSION MINOR VERSION DW STATUS CODE PK STATUS CODE STATUS CODE NAME STATUS CODE DESCRIPTION STATUS TYPE DESCRIPTION STATUS TYPE 21 PK ID NAME DESCRIPTION HTTP PROTOCOL 4.7 Staging terület A staging terület táblái jelentik az összekötő kapcsot az előfeldolgozott dimenziófrissítő, valamint tényadat-fileok és az előzőekben felvázolt csillagstruktúrás

adatbázisszerkezet között. Frissítést, új adatok bevitelét igénylig a nem statikus dimenziótáblák, valamint a központi ténytábla. A megvalósítás során a staging területet tulajdonképp két különálló egységre bontottam: egyrészt az adatbázison kívüli staging file-ok halmazára, valamint az adatbázison belüli staging táblákra, melyek egyenként megfelelnek egy-egy file-nak. Az adattöltés folyamata során először a file-ok állnak elő, majd SQL*Loader eszköz segítségével ezek adatai átkerülnek a staging táblákba, ahonnan PL/SQL függvények segítségével frissítjük a dimenziókat valamint a ténytáblát. A frissítéshez szükséges ellenőrző műveletek, kulcsmeghatározások, lekérdezések így csak az adatbázison belüli adatmozgások során kell megvalósítani, ami egyrészt gyorsabban implementálható, másrészt az eszköz (PL/SQL) miatt hatékonyabb is. A staging táblák tartalma azok feldolgozása után törlődik. A

táblák részletes specifikációja megtalálható a mellékletben 5. Előfeldolgozási, adattöltési lépesek A következőkben átnézzük az előfeldogozó Perl alkalmazás felépítését, működését. 5.1 Az előfeldolgozó szerkezete Az előfeldolgozó program felépítésénél igyekeztem arra törekedni, hogy az minél kevésbé függjön a konkrét log-file formátumtól. Ilyen megfontolásból, amennyire a perl nyelv ezt megengedi, moduláris szerkezetűre készítettem a feldolgozót. Alapvetően a feldolgozás a logfile soronkénti feldolgozását jelenti, most pedig attól függően, hogy milyen mezők szerepelnek az adott logfile-ban, a mezők megfelelő feldolgozásáról egy-egy modulban megvalósított függvény gondoskodik. Minden modul külön file-ba kerül A fő program neve main loader.php, különböző definíciókat pedig (plsession-hossz, útvonalak) a defs.pl file tartalmaz A modulok mindegyike module prefixel kezdődik, tartalmaz egy inicializáló,

egy sorfeldolgozó, egy befejező függvényt, valamint tartalmazhat globális változó deklarációkat. Az elnevezésekre korlátként szabtam, hogy minden függvény és változó a modul nevével kell kezdődjön. 5.2 Modulok 5.21 module ECLFParserpl Ebben a modulban valósítottam meg a logfile-sorok mezőinek szétválasztását. Először ez a modul kapja meg az adott sort, majd a többi modul már a feldolgozott, mezőkre bontott sorral dolgozik. 22 5.22 module filterpl A szűrés modulja felelős annak eldöntéséért, hogy egy adott log-sor page-hitet tartalmaz-e vagy sem. Amennyiben a szűrő modul egy adott sorra hamis értéket ad vissza, a main loader az adott sorral a továbbiakban nem foglalkozik. 5.23 module hostpl Feladata egy sorból a host információt kinyerni (IP szám), majd azt a host dimenzió frissítésére alkalmas formára hozni, a staging file-t létrehozni. Az host név visszafejtéséhez a modul a getHostByAddr rendszerhívást használja. Sajnos

a tapasztalatok a válaszra várni jelenti a futásidő legnagyobb részét, későbbiekben ez felgyorsítható lenne egy helyi cach file bevezetésével, vagy a lekérdezések párhuzamosításával. 5.24 module pagespl Az oldalinformációk feldolgozása, alkalmassá tétele az oldal dimenzió frissítésére. 5.25 module opsystempl, module agentpl Ez a két modul felelős az agent string megfelelő feldolgozásáért. Egyelőre az operációs rendszer és a kliens szoftver meghatározása egyszerűen adott minták keresésén és kiértékelésén alapszik. 5.26 module referrerpl Feladata a referrer információk feldolgozása, a referrer dimenziótábla karbantartó staging file-jának előállítása. 5.27 module session eventpl A ClickS mostani változatában a session event fogalma a találat azon tulajdonságát takarja, hogy session kezdeti, session belső vagy session záró hit volt-e. Ennek eldöntése sajnos – mivel a logfile nem tartalmaz session jellegű

információkat – csak közelítő módszerekkel lehetséges. Mindenképp szükséges a session nyomonkövetéséhez, hogy fel tudjunk ismerni adott klienseket. Ennek általános (de nem tökéletes) megoldásaként a cookie kezelés kínálkozik, azonban a logfile-unkban nem szerepelnek az esetleg kiosztott cookie-k. Ezért, kényszermegoldásként, a felhasználók azonosítására az IP címük és az agent-stringjük összekapcsolásából nyert karaktersorozatot alkalmazom, ami az agent-stringek viszonylagos változatossága miatt nem túl rossz közelítést adhat, de a proxy szerverek és adott helyeken nagy tömegben azonosan telepített gépek miatt több felhasználót néha azonosnak ismer fel. Annak eldöntése, hogy egy találat adott session záró találata volt-e, csak a logfile minta többszöri végigolvasásával lehetséges. Erre biztosítottam azonban lehetőséget 23 egy [modul neve] post process() függvény implementálásával, melyet a main loader

program hív meg a már előállított ténytábla-staging-file feldolgozására. 5.3 Adattöltés az SQL*Loader Oracle eszközzel Az előállított staging file-ok tartalmának adatbázisbeli staging táblákba töltését a main loader program végén rendszerhívással meghívott, megfelelően paraméterezett sqlldr eszköz végzi. Az SQL*Loader egy rugalmas, standard eszköz szövegfile-ok adatbázisba töltésére. Parancssori paraméterként megkapja az adatbázis azonosítóját, a megfelelő adatbázis felhasználó nevét és jelszavát, valamint a feldolgozandó file nevét. A file és a feltöltendő adattábla szerkezete egy megfelelő, viszonylag egyszerű formátumú leíró file-ban található. Az adattöltés során készít log feljegyzéseket a betöltés folyamatáról, valamint az esetleg előforduló hibás rekordokról. 5.4 Adatbázison belüli feldolgozás PL/SQL programjai Az adatbázison belüli adatfeldolgozó műveletek funkcióik szerint csoportosítva

külön csomagokba kerültek. 5.41 DW MAINTAIN DIMENSIONS csomag A csomag feladata a változó dimenziók dimenziótábláinak karbantarása. Feladatuk általánosan a staging táblák sorainak olvasása, annak ellenőrzése, hogy adott elem szerepel-e már a dimenziótáblában, ha nem, annak megfelelő beszúrása, esetleg módosítás esetén a bejegyzés duplikálása, érvényességi időbélyegekkel ellátva. Az eljárások: • • • • • LoadAgentData LoadOpsystemData LoadHostData LoadReferrerData LoadPageData Kicsit különböző feladatot lát el a következő függvény: • InserLineIntoDomains A domain hierarchia tábla nem rendelkezik saját staging táblával, feltöltése a host és a referrer táblákban előforduló host-ok függvénye. A megfelelő eljárások ezért egyszerűen meghívják a domain-feldolgozó függvényt a domain-információval, az karbantartja a domain-hierarchia táblát, majd visszatér egy kulccsal, ami a kérdéses domaint

azonosítja. 24 5.42 DW QUERY DIMENSIONS A csomagban található függvények feladata, hogy meghatározzák adott dimenzió adott tulajdonságú elemének kulcsát. Abban az esetben, ha adott tulajdonságú elem nem létezik, a 0 kulccsal térnek vissza, ami a ClickS esetében mindig a nem ismert dimenzió-elem kulcsa. 5.43 DW MAINTAIN IMPRESSION FACT csomag A csomag egy eljárást tartalmaz, neve LoadFactTableData. Feladata, hogy a staging ténytábla sorait feldolgozza, azokat beírja a ténytáblába, ehhez meghatározza a megfelelő kulcsokat a DW QUERY DIMENSIONS függvényei segítségével. 5.5 Statikus dimenziók inicializáló programjai A statikus, állandó elemekkel rendelkező dimenziók feltöltése egyszeri. Kisebb elemszám esetében a feltöltést egy-egy PL/SQL script végzi (pl. http-request), ezen túlmutató elemszám esetében a feltöltés egy staging file-ból történik a dinamikusan változó dimenziókhoz hasonlóan (pl. dátum) Az inicializáló

eljárások dinamikus dimenziók esetében az extremális, 0 kulcsú, „nem ismert” elem beszúrását végzik. A DW INIT csomag eljárásai: • • • • • • • • Init Time of Day Init Event Type Init HTTP Request Init HTTP Protocol Init Domains Init Hosts Init Page Hierarchy Init Opsystem 6. Beszámolók, riportozó felület – hab a tortán A beszámoló, riportozó felület megfelelő kialakítása már túlmutat a dolgozat kitűzött céljain. Ugyanakkor igaz azonban, hogy a többi komponens használhatósága, működése csak egy valamilyen riportozó felületen keresztül válik megbecsülhetővé, látványossá. Ezért a riportozó felület kialakításakor igyekeztem lehetőségekhez mérten olyan beszámolókat kialakítani, melyek az adatbázis-tárolás, adatbázis-szerkezet egy-egy előnyös tulajdonságát használják ki, valamint demonstrálják, hogy a felépítés megfelel az OLAP adatszolgáltatás követelményeinek. 25 6.1 A riportozó

felület architektúrája A felület kialakításakor követtem azt a ma trendnek számító irányvonalat, amely szerint a beszámolók legyenek webes alapúak, szabvány böngészővel és internetkapcsolattal elérhetőek. Nem alakítottam ki viszont megfelelő session-kezelő, bejelentkeztető felületet Ennek hiánya annak fényében nem veszélyes ebben az esetben, hogy a lekérdezések egy csak lekérdezési jogokkal felruházott adatbázis-felhasználón keresztül történnek. A riportozó kliens tehát egy tetszőleges böngésző. A böngésző lekérdezésekkel fordul a szerver oldali Apache webszerverhez. Az Apach webszerver modulként beépítve tartalmaz egy PHP interpretert, ami fel van ruházva Oracle8 adatbázis kapcsolat kezdési, adatbázis művelet végrahajtási képességekkel. Bizonyos szemszögből így az architektúra egy háromrétegű modellnek felel meg, ahol a webszerver az alkalmazásszerver szerepét játssza. 6.2 A riportok megvalósítása A ClickS

megoldás tartalmaz a beszámolás folyamatához egy kezdőlapot, ahonnan a meglévő beszámolók elérhetőek. A beszámolók lehetnek statikus, aktív elemekkel nem rendelkező riportok, vagy aktív, OLAP vagy más műveletet támogató beszámolók. A második típus beszámolói paraméterezhetőek, paraméterként átadva nekik egy-egy szűrés, lefúrás adatait, az annak megfelelő adatokat jelenítik meg. Az aktív elemek (formok vagy hivatkozások) mindig a megfelelően paraméterezett beszámolót hívják meg, adott esetben ez lehet önmaga is, új paraméterekkel. A következő ábra egy egyszerű aktív, időtartam-oldaltalálat beszámolót ábrázol: 16. ábra: Időtartam - oldaltalálat riport A beszámolók egységes kinézetét egy StyleSheet file biztosítja, amiben a használt html elemek tulajdonságait definiálhatom. Így az eredmény tábla kinézete pl minden beszámolóban hasonló. 26 7. Teszt 7.1 A teszt hardver-környezete A program fejlesztését,

tesztelését alapvetően a saját gépemen végeztem. A gép viszonylag szerény képességei ellenére azonban a feldolgozás és lekérdezés elég hatékonynak, gyorsnak bizonyult. • • • • AMD K6 3D processzor, 450MHz 320 MB RAM (Microsoft Windows XP operációs rendszer) WDC WD8000BB 80Gb merevlemez 7.2 A teszthez használt logadatok Eredeti terveim szerint a ClickS alkalmazást a www.infeltehu logadatain szerettem volna tesztelni, de sajnos a főoldalon feltüntetett „webmaster”-t nem sikerült elérni. A teszteléshez és a fejlesztéshez így aztán egy nem túl nagy forgalmú, de használható adatmennyiséget produkáló site logadatait használtam, ami megfelel a standard ECLF log formátumnak, látogatottsága kb. napi 500-600 oldaltalálat jellemző átlagban (ennek szórása viszonylag nagy). 7.3 ETL eszközök tesztje Az ETL eszközöket teszteltem egyrészt adathelyességi szempontok szerint, folyamatosan kiküszöbölve az extremális adatok okozta

hibákat, valamint a futásidőt figyelve. Kiderült, hogy az előfeldolgozás a vártnál jóval magasabb értékeket produkál. Ennek oka, hogy a feldolgozás futásidejének jelentős hányada az IP címek visszafejtésére fordul, igy az nagyban függ a számítógép internetkapcsolatának sebességétől. Hozzávetőleges eredmények: 2000 page hit 15000 page hit 3-4 perc között 70 perc körül 7.4 Adatbázis eszközök tesztje Az adatbázis oldali eszközök az előfeldolgozáshoz képest gyorsan, futnak, a szélsőséges esetek folyamatos megoldásával, kezelésével az adattöltés folyamata megbízhatónak mondható. 7.5 Riportozó eszközök tesztje A riportozó eszközök tesztje során általános elvárásként fogalmazható meg, hogy a válaszidők semmilyen lekérdezés esetében nem haladhatják meg a 3-4 másodperces felső 27 határt. A meglévő beszámolóim esetében ez nem is fordult elő, viszonylag nagyobb adatmennyiségek esetében sem. A riportok

tesztjét könnyítendő, azok tartalmaznak egy futásidő-mérés funkciót, ami a lekérdezés futásidejét másodperc pontossággal megjeleníti a beszámolón. 8. Ismert hibák, hiányosságok A hibák felderítésével, megfelelő dokumentálásával azok átminősülhetnek a program kiszámítható tulajdonságaivá, ezért igyekeztem azokat a fejlesztés során mindinkább figyelemmel követni. A főbb hiányosságok: • • • • A már említett IP-cím visszafejtési probléma miatt az előfeldolgozó futási ideje esetleg elfogadhatatlanul nagyra nőhet. Követleményként megfogalmazhatjuk, hogy egy napi logfile betöltése érjen véget egy éjszaka alatt. Ebben a formában nagyobb logmennyiség esetében ezt nem látom biztosítottnak. A változások nyomonkövetése a dimenziótáblákban még nem megfelelően kidolgozott és stabil abban az esetben, ha már meglévő elemet szeretnénk újra betölteni, különböző érvényességi időintervallummal. Az

előfeldolgozás session event modula nincs felkészítve arra, hogy eltárolja a legutolsó logfile-ban elkezdett, de be nem fejezett session-öket, majd időrendi sorban ezt felhasználva nyissa meg az újabb logfilet, a session-öket a félbehagyott állapotból folytatva. A ténytábla kimondottan méretérzékeny. Ezért érdemes lenne még átnézni az idegen kulcsokat, és csak akkora méretű attribútumokat használni kulcsként, amekkorára ténylegesen szükség is van. 9. Lehetséges fejlesztési irányok Ebben a pontban kitérek néhány olyan lehetőségre, amely benne rejlik a ClickS alkalmazásban, de még jelentős fejlesztést igényelne kidolgozásuk. 9.1 Aggregátumok kezelése Nagyobb adatmennyiség esetén a komplexebb lekérdezések válaszideje várhatóan az elfogadható határérték fölé nő. Ekkor válhat szükségessé megfelelő adataggregátumok, összegzett nézetek kialakítása a hagyományos adattárház elméletnek megfelelően, melyekben a

ténytábla adatai megfelelő módon felösszegezve, adott gyakran használt tulajdonságra szűrve vagy kevésbé használt dimenziót kihagyva találhatók. Az aggregátumok kialakítását, adatainak automatikus frissítését az Oracle adatbázis nagyban támogatja az ún. „Materialised View” nézet-típussal 28 9.2 Bővített logfile formátumok kezelése Az alkalmazás funkcionalitását nagyban növelheti, ha képes feldolgozni kevésbé elterjedt, de azért gyakran használt, több leíró adatot tartalmazó logfile formátumot. Erre elvileg alkalmas lehet a kifejlesztett ETL eszköz, a moduláris felépítése miatt. 9.3 Session központú ténytábla kialakítása Az adatpiac adatfelbontásának („granularity”) mostanitól eltérő megválasztásával a lehetséges beszámolók köre, a beszámolás folyamatának hatékonysága nagyban növelhető. Hasznos lehet egy olyan ténytábla kialakítása, amely a logadatokból kiszűrt session-ökről tartalmaz egy-egy

sort, megfelelően megválasztott attribútumokkal, mint pl. a session page-hit-jeinek száma, időtartama, a bejárt útvonal valamilyen jellemzője, stb. Ehhez a már meglévő dimenziók nagy része szintén felhasználható, egy új dimenzó (session) és egy új ténytábla kialakítása, valamint azok töltésének megoldása lenne szükséges. 9.4 Adminisztrációs felület, metaadat-kezelés kialakítása A ClickS alkalmazásból hiányzik az adminisztráció valamilyen szinten automatizált eszközeinek megvalósítása. Ezek lehetőséget adhatnának az adattöltések monitorozására, indítására, leállítására, esetleges aggregátumok kialakítására, más adminisztrációs lépések automatizálására. Ennek ha nem is feltétele, de mindenképp hasznos támasza lehet egy megfelelő metaadat-adatszótár készítése. A metaadat általában adatot leíró adatokat jelent, itt én most ez alatt értem a dimenziók leírását, a dimenzióelemek, a ténytábla tartalom

leírását, az aggregátumok leírását. (Ezek egy része valamilyen formában automatikusan elő is áll az Oracle repository-jában.) 9.5 Riportozó felület fejlesztése Az eszköz használhatósága, erőssége igazán akkor mutatkozna meg, ha a riportozó felület megfelelően fel lenne készítve OLAP lekérdezések kezelésére, ami azonban magában is legalább egy nagyprogram méretű fejlesztést igényelne. Érdekes és nagy jövő előtt álló terület ezen kívül adabányászati módszerek integrálása, a weblog adatok ennek jó táptalajt biztosítanak (pl. tipikus böngészési útvonalak felderítése, felhasználók klaszterezése, stb) 9.6 Agent string megfelelő feldolgozása Az agent string adatai nagyon sokféle formátumot követhetnek, gyakran hiányosak vagy egyediek, számossága folyamatosan nő. A kliens operációs renszer és a kliens eszköz minél pontosabb meghatározása ezért nagy kihívást jelent. 29