Tietovirtojen lataaminen tosiaikaiseen tietovarastoon

hyväksymispäivä arvosana arvostelija Tietovirtojen lataaminen tosiaikaiseen tietovarastoon Mika Kukkonen Helsinki 22.10.2009 Seminaarityö HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen tiedekunta Tekijä Författare Author Mika Kukkonen Työn nimi Arbetets titel Title Tietojenkäsittelytieteen laitos Tietovirtojen lataaminen tosiaikaiseen tietovarastoon Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages Seminaarityö 22.10.2009 15 sivua Tiivistelmä Referat Abstract Tosiaikainen tietovarasto on keskitetty tietokantajärjestelmä pehmeitä tosiaikaisia raportointisovelluksia varten. Näiden sovellusten perusvaatimuksena on tuoreen tiedon jatkuva saatavuus. ETLprosessissa muutokset lähdejärjestelmien tietosisällöissä päivitetään tietovaraston relaatiotietokantaan. Tosiaikaisen ETL-prosessin toteuttamisessa on kaksi perusarkkitehtuuria: muutostietojen noutaminen lähteistä tihennetyllä aikataululla sekä muutostietojen aktiivinen lähettäminen lähteistä tietovarastoon. Muutostietojen lähettäminen jatkuvana tietovirtana mahdollistaa lyhyimmät viiveet lähteiden ja tietovaraston välillä. Tietovirtojen kuunteluun perustuva ETL-järjestelmä voidaan mallintaa ETL-operaatioiden jonoverkkona [KVP05], johon saapuu monikkoja lähteistä satunnaisesti. Mallin avulla ETL-jonoverkon suorituskykyominaisuuksia kuten keskimääräisiä odotusaikoja ja jononpituuksia voidaan parhaassa tapauksessa ennustaa luotettavasti. ETL-jonoverkon keskeinen operaatio on liitos, jota tarvitaan mm. keinoavainten hakemisessa. MeshJoin on algoritmi liitoksen laskemiseksi nopean tietovirran ja hitaan perusrelaation välillä, joka on suunniteltu läpivirtauksen optimoimiseksi rajallisella muistimäärällä [PSV08, PSV + 07]. Kokeissa MeshJoin-algoritmi osoittautuu tehokkaaksi liitosalgoritmiksi tosiaikaisessa ETL-jonoverkossa, mutta muihin käyttötarkoituksiin perinteiset liitosalgoritmit soveltuvat paremmin. ACM Computing Classification System (CCS): H.2.7 [Database Administration], H.2.8 [Database Applications] Avainsanat Nyckelord Keywords tosiaikainen tietovarasto, ETL, tietovirrat Säilytyspaikka Förvaringsställe Where deposited Muita tietoja övriga uppgifter Additional information

Sisältö ii 1 Johdanto 1 2 ETL-prosessin jonoverkkomalli 3 3 MeshJoin-algoritmi 6 4 MeshJoin-algoritmin suorituskyky 10 5 Johtopäätökset 13 Lähteet 14

1 1 Johdanto Tietovarastot ja transaktionkäsittelytietokannat (OLTP) eroavat toisistaan ennen kaikkea työkuormitukseltaan. Tietovarastojen hyötykuorma on lukuintensiivistä ja OLTP-tietokantojen kirjoitusintensiivistä. Erilaisten työkuormien optimoinnista on seurannut erilaisia teknisiä valintoja tietomallinnuksessa, indeksoinnin suunnittelussa, välimuistiratkaisuissa ja fyysisessä tallennuksessa 1. Näistä eroavaisuusuuksista huolimatta tavallisesti sekä tietovarastojen että OLTP-tietokantojen moottorina on relationaalinen tietokannanhallintajärjestelmä (RDBMS). Tietovaraston relaatiotietokanta on myös tavallisin lähde multidimensionaalisille OLAP-tietokannoille. Radikaalein ero päätöksenteon tukijärjestelmien ytimenä olevien tietovarastojen ja operatiivisten OLTP-tietokantojen välillä ei ole tietokantatekniikassa, vaan ylläpitoprosessissa. Analyysijärjestelmänä oleva tietovarasto on voitu sulkea käyttäjiltä tietojen uutos, muunnos ja latausprosessin 2 ajaksi, kun taas operatiivisissa OLTPtietokannoissa ei voida sallia käyttökatkoja. Tietovarastoinnin palveluvaatimukset ovat kuitenkin tiukentuneet 2000-luvulla, mikä johtunee tietovarastoinnin yleistymisestä ja operatiivisten järjestelmien lukumäärän kasvamisesta. Tietovarastoinfrastruktuuria on olemassa ja sitä halutaan hyödyntää tiedonhallinnassa monipuolisemmin kuin alun alkaen suunniteltiin. Yksi uusi käyttökohde on hyödyntää tietovarastoja operatiivisessa raportoinnissa, etenkin jos raportteja varten pitää yhdistää tietoja useammasta kriittisestä OLTP-järjestelmästä. Operatiivinen raportointi ei kuitenkaan salli palvelukatkoksia ja tietojen pitää olla riittävän tuoreita, eli niillä on jokin tosiaikaraja. Tosiaikainen tietovarastointi ja liiketoimintatiedon hallinta (real-time DW/BI) on alue, joka käsittelee tietojen integrointia useammasta lähdejärjestelmästä ja raportointia pehmeiden tosiaikarajojen vallitessa. Aihepiiriin keskittynyt BIRTE-workshop on järjestetty nyt kolmesti vuodesta 2006 lähtien VLDB-konferenssin yhteydessä [Bir09]. Tosiaikaisen tietovarastoinnin perusongelmana on rakentaa ETL-prosessi niin, että tietovarasto pysyy riittävän tuoreena ilman, että tietovarastolta halutuista ominaisuuksista, kuten kyselytehokkuudesta ja eri lähdejärjestelmistä ladattujen tietojen yhdenmukaistamisesta pitäisi tinkiä liikaa. Tosiaikaisen ETL-prosessin toteuttamisessa on kaksi perusarkkitehtuuria: 1 esim. dimensio- vs. normalisoitu mallinnus, raskaat indeksit vs. kevyet indeksit, materiaalistetut näkymät/koosteet vs. pelkkä kyselysuunnitelmavälimuisti, ja sarake- vs. rivitallennus 2 extract, transform and load, ETL

2 Tihennetty ETL: perinteisen ETL-prosessin tihentäminen (micro-batching), joka perustuu tietojen vetämiseen (pull) lähteistä määräaikavälein Tietovirta-ETL: tietovirtojen jatkuva kuunteleminen ja prosessointi, joka perustuu tietojen työntämiseen (push) lähdejärjestelmistä tietovarastoon Perinteisen ETL-prosessin tihentäminen on yleisin tapa saavuttaa tavanomaisilta liiketoimintajärjestelmiltä vaadittavat aikarajat. Tekninen toteutus perustuu päätietovarastosta fyysisesti erilliseen, huomattavasti pienempään kirjoitusoptimoituun tosiaikaiseen osioon, johon päivänsisäinen tieto ladataan[kir02, Inm05, SB08]. Kyselyissä tehdään tarvittaessa liitoksia päivänsisäisen osion ja päätietovaraston välillä. Ylläpitoikkunan aikana tosiaikainen osio konsolidoidaan päätietovarastoon 3. Push-tyyppinen ETL on herättänyt paljon mielenkiintoa [Par09], sillä se mahdollistaa lyhyemmät viiveet lähdejärjestelmien ja tietovaraston välillä. Tietojen muutokset voidaan uuttaa lähdejärjestelmissä lähes välittömästi ja toimittaa muunnosja latausvaiheiden käsiteltäviksi. Push-tyyppinen ETL johtaa myös löyhempään sidokseen tietolähteiden ja tietovaraston välillä: muutostieto generoidaan lähdejärjestelmissä ja välitetään rajapinnan kautta tietovarastoon. Pull-tyyppisessä ETLprosessissa tietojen uuttaminen on konfiguroitu/ohjelmoitu ETL-järjestelmään, mistä seuraa että ETL-järjestelmä on herkkä muutoksille lähdejärjestelmissä. Yksinomaan tietovirtojen kuunteluun perustuva tosiaikainen ETL on toistaiseksi enemmän akateeminen tutkimuskohde kuin varteenotettava tekninen vaihtoehto. Saapuvien tietovirtojen tallentaminen tietokantoihin on kuitenkin aina ollut tavallista hajautettujen tietolähteiden kanssa. Esimerkiksi lokitus- ja lokianalyysijärjestelmä voitaisiin toteuttaa tosiaikaisena tietovarastona, joka kuuntelee tietovirtoja lokilähteistä. Tässä työssä käsitellään tietovirtojen lataamista tosiaikaiseen tietovarastoon. Ensimmäiseksi esitellään ETL-prosessin yleistä jonoverkkomallia ja ETL-operaatioiden keskeisiä suorituskykysuureita (luku 2). Tämän jälkeen tarkastellaan yksittäistä mutta tärkeää ETL-operaatiota, tietovirran ja tietovaraston relaation liitosta ja sen laskemista MeshJoin-algoritmin avulla (luku 3). MeshJoin-algoritmin suorituskykyä ja optimointia tutkitaan luvussa 4. Lopuksi arvioidaan tietovirta-etl:n sekä MeshJoin-algoritmin suorituskykyominaisuuksia. 3 Käytössä on myös termi operatiivinen tietovarasto, ODS, jolla tavallisesti tarkoitetaan ad hoc -luonteisempaa replikaattia raportointia varten tarvittavista tiedoista, eikä tätä voida helposti konsolidoida päätietovarastoon

3 2 ETL-prosessin jonoverkkomalli Tietovirran lataaminen tietovarastoon voidaan mallintaa ETL-operaatioiden jonoverkkona [KVP05]. Jonoverkkomallit (queueing network models) ovat tietokonejärjestelmien suorituskyvyn analysoinnin keskeisiä työvälineitä [DeB78]. Jonoverkkomallissa verkon solmuja kutsutaan palvelupisteiksi. Kuhunkin palvelupisteeseen saapuu asiakkaita jonossa. Jos palvelupiste on varattu, asiakas odottaa jonossa, kunnes palvelupiste vapautuu. Asiakas poistuu jonosta, kun sen palvelupyyntö on toteutettu. ETL-jonoverkkomallissa palvelupisteitä ovat ETL-operaatiot, jotka voidaan luokitella suodattimiin, muunnoksiin ja binäärioperaatioihin [KVP05]. Suodatin karsii pois osan jonoon tulevista monikoista (valintaehdot), muunnosoperaatio muuttaa tietosisältöä tai suorittaa muunnoksen tietomallien välillä (tietojen puhdistaminen ja yhdenmukaistaminen), ja binäärioperaatio tuottaa kahdesta lähteestä yhden tulosvirran (relaatioiden liitokset). ETL-palvelupisteiden kannalta asiakkaat ovat kuitenkin toisistaan erottamattomia tietovirtoja, jolloin kyseessä on ns. yhden luokan jonoverkkomalli [KVP05]. Jonoverkon palvelupisteisiin (kuva 1) liittyy kaksi parametria: 1. saapumisnopeus λ IN = palvelupisteeseen saapuvien asiakkaiden lukumäärä aikayksikköä kohden, ja 2. palvelunopeus µ = λ OUT + λ REF = palvelupisteeltä poistuvien asiakkaiden lukumäärä aikayksikköä kohden, jossa λ OUT on palvelupisteen hyväksymien ja prosessoimien asiakkaiden lkm/aikayksikkö ja λ REF on palvelupisteen hylkää- Kuva 1: Jonoverkon palvelupiste [KVP05].

4 mien asiakkaiden lkm/aikayksikkö. Jotta jono ei kasvaisi rajattomasti, on oltava voimassa ρ = λ/µ < 1, jossa ρ on palvelupisteen käyttöaste. Jonoverkon keskeiset suorituskykysuureet ovat keskimääräinen jonon pituus ja keskimääräisen odotusaika (jonotus + palveluaika). Jos jonossa on yksi palvelupiste, ja saapumisnopeus on Poisson-prosessi sekä palveluaika noudattaa eksponenttijakaumaa, niin jonoa kutsutaan Kendallin merkintätavassa M/M/1 -jonoksi. M/M/1-jonoille sekä näistä muodostetulle jonoverkolle voidaan johtaa ennuste keskimääräiselle jononpituudelle ja odotusajalle. ETL-järjestelmän suorituskykyyn vaikuttaa myös joukko jonoverkkomallista riippumattomia arkkitehtuurivalintoja. Kuvassa 2 on esitelty jonoverkkoon ja web service -rajapintoihin pohjautuvan ETL-järjestelmän 4 toteutusvaihtoehtoja. Kuva 2: ETL-järjestelmän arkkitehtuurivalintoja [KVP05]. Kokeissa[KVP05] testattiin jonoverkkomallia sekä mitattiin arkkitehtuurien vaikutusta suorituskykyyn. 4 kuvassa ETL-järjestelmä = Active Data Staging Area, ADSA

5 Koko järjestelmän suorituskyvystä havaittiin, että: ETL-järjestelmä kannattaa eristää sekä lähteistä että tietovarastosta. Kahden palvelimen mallissa ETL-järjestelmä kannattaa kuitenkin sijoittaa tietovarastopalvelimelle. Tietovirran säätely (regulation) lähteestä ETL-järjestelmään vaikuttaa läpivirtaukseen ja odotusaikoihin merkittävästi. Lähteiden ja ETL-järjestelmän välisessä tiedonsiirrossa lohkon koko ei saa olla liian pieni tai liian suuri (alle 25 tai yli 100 monikkoa). Liian pieni lohkon koko kuormittaa lähdejärjestelmää ja vähentää läpivirtausta. Liian suuri lohkon koko johtaa viiveisiin tiedonsiirrossa. Lähteiden ja ETL-järjestelmän välisessä tiedonsiirrossa UDP-protokollaa käytettäessa pakettien hävikki on liian suuri, jotta protokollasta olisi suorituskykyetua TCP-protokollaan nähden. Tietovarastoon tallentavan rajapinnan arkkitehtuuri ei vaikuttanut suorituskykyyn merkittävästi (tietovirran säätely, synkroniset vs. asynkroniset kutsut, web service -instanssien lukumäärä). Odotusaikojen minimoimiseksi jononpituudet ETL-jonoverkossa tulisivat olla mahdollisimman lyhyitä, eli saapumisnopeus lähteistä ei saa ylittää ETLjärjestelmän palvelunopeutta ETL-järjestelmän jonoverkkomallin koeasetelmissa jonoverkot muodostuivat 0-4 peräkkäisestä ETL-operaatiosta, joista jokainen mallinnetaan M/M/1-jonoina. Suuntaaantava tulos oli, että kokeessa, jossa palvelunopeus on 2000 monikkoa sekunnissa, havaitut keskimääräiset jononpituudet eri operaatioissa olivat 5-8 monikkoa ja mallin ennusteet 2-3 monikkoa. Malli aliarvoi keskimääräisen jonon pituuden kaikissa kokeissa ja ero havaittujen ja ennustettujen jononpituuksien välillä oli eri operaattoreilla noin 3-5 monikkoa. Näiden tulosten nojalla malli ei kuitenkaan epäonnistu keskimääräisen jononpituuden ennustamisessa. Koetulosten tilastollista analyysiä kirjoittajat eivät kuitenkaan esitä, mikä vähentää tulosten luotettavuutta. Koetulosten yleistäminen on vaikeaa, sillä koeasetelman ETL-järjestelmä on toteutettu pelkästään spesifiä tarkoitustaan varten. Tarkoituksena on ollut osoittaa jonoverkkomallin kelpoisuus tosiaikaisen ETL-prosessin suorituskykymallina ennemin kuin esittää tosiaikarajojen saavuttamiseen suunniteltuja optimointeja.

3 MeshJoin-algoritmi 6 ETL-prosessin yleisimpiä operaatioita on lähdemonikkojen liitos tietovarastossa tai valmistelualueella (staging area) sijaitseviin relaatioihin. Liitoksia tarvitaan mm. keinoavainten (surrogate key) hakemisessa sekä uusien monikkojen erottamisessa tietovarastoon jo tallennetuista monikoista. Keinoavaimet ovat tietovaraston avaimia, jotka korvaavat lähdejärjestelmien omat, ns. luonnolliset avaimet. Luonnollisia avaimia tai näiden johdoksia ei ole syytä käyttää tietovarastoissa, koska tästä seuraava tiivis riippuvuus lähteiden ja tietovaraston välillä rajoittaa tietovaraston loogista suunnittelua. Lisäksi avainkonfliktien riski haittaa tietovaraston ylläpitoa. Avainmuunnoksessa lähdeavainta vastaava keinoavain haetaan master-taulusta liitoksella (Kuva 3). Kuva 3: Keinoavaimen haku [NDW09]. Tavanomaisessa ETL-prosessissa suorituskykytavoitteena on minimoida prosessin kokonaiskesto. Liitoksissa tarvittavat lähdemonikot ladattaisiin tällöin muistipuskuriin ja liitoksen laskemisessa käytettäisiin soveltuvaa lohkoalgoritmia, kuten sortmerge tai hash join -algoritmeja [PSV08]. Tietovirtojen ja relaatioiden välisiin liitoksiin tosiaikaisessa tietovarastossa tämä ei kuitenkaan sovellu. Tavoitteena ei ole enää ETL-prosessin kokonaiskeston minimointi, vaan tosiaikarajan saavuttaminen. Puskuroinnista johtuvat odotusajat eivät palvele tätä tavoitetta, vaan tarvitaan jatkuva ennemmin kuin eräajoihin perustuva liitosalgoritmi [PSV08, NDW09]. Jos puskuroinnista luovutaan, niin jäljelle jää sisäkkäisten silmukoiden liitosalgoritmit (nested-loop join), erityisesti index-nested-loop (INL). Tällöin kuitenkin menetetään läpivirtauksen tehokkuutta, koska jokaista saapuvaa monikkoa kohden on tehtävä indeksihaku, joka pahimmillaan on kallis satunnainen levyhaku [PSV08]. Mahdollise-

7 na lisäkustannuksena on vielä indeksin ylläpito liitosattribuuteissa. Kompromissina voitaisiin yrittää optimoida puskurikokoa dynaamisesti tosiaikarajan tiedostavalla algoritmilla. Haasteena tässä on, että tietovirran nopeus suhteessa perusrelaation levyhakujen nopeuteen on tuntematon ja voi vaihdella suuresti [NDW09]. Lähtökohtaisesti hyvä liitosalgoritmi olisi sellainen, jossa läpivirtaus olisi mahdollisimman suuri, jonotusajat pieniä, ja joka kuluttaisi mahdollisimman vähän muistia. Muistinkäyttö on kriittistä ETL-prosessissa kahdesta syystä. Ensinnäkin perusrelaatiot voivat olla hyvinkin suuria eikä niitä voida tavallisesti ladata muistiin kokonaan. Toiseksi, tehokas ETL-prosessi hyödyntää rinnakkaisuutta mahdollisimman paljon, ja samanaikaisesti voi olla käynnissä useita muistia tarvitsevia operaatioita [NDW09]. MeshJoin on algoritmi liitoksen laskemiseksi nopean tietovirran ja hitaan perusrelaation välillä, joka on suunniteltu läpivirtauksen optimoimiseksi rajallisella muistimäärällä [PSV08, PSV + 07]. Tavoitteen saavuttamiseksi levyhakujen kustannus jaetaan usean saapuvan monikon kesken (amortization). Lisäksi levyä luetaan silmukassa sarjallisesti, eikä hitaita satunnaisia levyhakuja tarvita. Algoritmi ei oleta indeksejä relaatiossa, liitostyyppiä ei rajoiteta (equivalence, range, similarity etc.) ja liitoksen tulos on eksakti 5. MeshJoin (kuva 4) laskee liitoksen virtana saapuvan relaation S ja tietovarastossa levyllä säilytettävän, muuttumattoman relaation R välillä. Algoritmin toimintaa ei ole tarkoitus määritellä tässä toteutukseen vaadittavalla täsmällisyydellä, mutta suorituskykyominaisuuksien ymmärtämiseksi tarvitaan kuvaus algoritmin toimintaperiaatteesta ja kustannusmallista. Algoritmin yksittäisen iteraation syötteenä on b sivua perusrelaation monikkoja ja w syötevirran monikkoa. Tulosvirtaan tuotetaan liitosehdon täyttävät monikot. Yksittäisessä iteraatiossa: 1. Syötevirrasta talletetaan w monikon lohko tietovirtapuskuriin ja perusrelaatiosta ladataan b sivua kerrallaan levyltä levypuskuriin. 2. Tietovirtapuskurin w monikkoa tallennetaan liitosavaimen perusteella hajautustauluun H, ja monikoista ylläpidetään saapumisjärjestyksessä liikkuvaa ikkunaa, jonoa Q. Jonoon tallennetaan vain osoittimet hajautustaulun monikoihin. Jos jono on täynnä, poistetaan ensin vanhin w monikon lohko jonosta ja hajautustaulusta. 5 MeshJoin-algoritmista on myös ei-eksakti approksimaatioliitosversio, jota käsitellään lyhyesti luvun 4 lopussa.

8 Kuva 4: MeshJoin-algoritmin tietorakenteet ja arkkitehtuuri [PSV08]. 3. Lasketaan levypuskurin liitos hajautustaulun monikoihin ja palautetaan tulos. Sama voidaan esittää pseudokoodina (kuva 5). Oikeellisen toiminnan kannalta on tärkeintä, että liikkuvan ikkunan koko (w monikon lohkojen lukumäärä) on yhtä suuri kuin koko relaation lataamiseen tarvittavien iteraatioiden lukumäärä: jonon Q koko = (sivujen lukumäärä relaatiossa R)/b Tällöin perusrelaation b sivua ladataan levyltä vain kerran yhden ikkunan käsittelyä varten, ja levy-io:n kustannus jakautuu kaikkien liikkuvassa ikkunassa olevien monikkojen kesken. Kun levyä lukeva silmukka lukee seuraavan kerran samat b sivua, liikkuvassa ikkunassa ei enää ole yhtään samaa monikkoa kuin edellisellä kerralla. Algoritmin oikeellinen toiminta rajallisessa muistissa edellyttää myös, ettei yksittäisen iteraation aikana tietovirrasta saavu enempää monikkoja kuin kerralla luetaan (w kpl). Jos liitosoperaatio mallinnetaan jonoverkkona (luku 2), niin sen palvelunopeus µ = iteraation nopeus w. MeshJoin-algoritmin vaatima muistitila on rajattu, jos syötevirran nopeus λ ei ylitä algoritmin palvelunopeutta µ.

9 Kuva 5: MeshJoin-algoritmin pseudokoodi [PSV08]. Algoritmin sisäisiä parametreja b ja w muuttamalla algoritmia voidaan optimoida niin, että saadaan: 1. suurin palvelunopeus äärelliselle muistille M max tai 2. pienin tilantarve M annetulle palvelunopeudelle µ. Algoritmin kustannusmallissa [PSV08] esitetään palvelunopeuden µ, tilavaatimuksen M, puskurin koon b ja ikkunan kokoon w vaikutus toisiinsa. Kustannusmallissa analysoidaan tilavaatimus M ja iteraation aikavaatimus c loop komponenteittain. Yksinkertaistettuna: M = levypuskuri + tietovirtapuskuri + jono Q + hajautustaulu H c loop = b sivun lataamisen levy-i/o + jonon Q ylläpito + hajautustaulun H ylläpito + liitoksen laskeminen b sivun ja hajautustaulun välillä + tulosvirran generointi Palvelunopeuden µ, puskurin koon b ja ikkunan koon w välillä on yhteys: µ = w/c loop (1)

10 Kustannusmallin avulla voidaan kirjoittaa ikkunan koko funktiona w = f(m, b), ja eliminoida se palvelunopeuden yhtälöstä (1), jolloin saadaan µ = f(m, b)/c loop. Palvelunopeuden suurin arvo muuttujan b suhteen voidaan ratkaista nyt numeerisilla menetelmillä. Analyyttistä ratkaisua ei ole, koska b sivun lataamisen levy-i/o on riippuvainen muuttujasta b, mutta tätä riippuvuutta ei voida esittää kaavana, vaan levy-i/o voidaan ainoastaan mitata [NDW09]. MeshJoin-algoritmin kustannusmallia on testattu vertaamalla mallin mukaisia suorituskykyennusteita on mitattuun suorituskykyyn [PSV08, NDW09]. Kuvassa 6 vasemmalla on ennustettu ja mitattu palvelunopeus vakiomuistilla (20MB), levypuskurin kasvaessa lineaariseesti. Oikealla on ennustettu ja mitattu palvelunopeus eri muistimääärillä. Kuva 6: (a) Ennustettu ja mitattu palvelunopeus vakiomuistilla (20MB), levypuskurin kasvaessa lineaariseesti. (b) Ennustettu ja mitattu palvelunopeus eri muistimääärillä [NDW09]. 4 MeshJoin-algoritmin suorituskyky Kokeiden perusteella MeshJoin-algoritmin palvelunopeus on suurempi kuin INLalgoritmin sekä synteettisellä että reaalimaailmasta poimitulla aineistolla (kuva 7). Enimmillän maksimipalvelunopeudessa on satakertainen ero. Muistin määrän kasvaessa ero pienenee synteettisellä aineistolla. MeshJoin ja INL-algoritmit eivät myöskään ole erityisen herkkiä liitokseen osallistuvan relaation R jakauman vinoudelle.

Molempien palvelunopeus laskee tasaisesti liitosavainten jakauman keskittyessä yksittäisten arvojen ympärille [PSV08]. 11 Kuva 7: MeshJoin ja INL -algoritmien palvelunopeus eri muistimäärillä. (a) synteettinen aineisto. (b) reaalimaailmasta poimittu aineisto. [PSV08]. Suoraviivaisin, ja ehkä käytännöllisin tapa optimoida MeshJoin-algoritmin palvelunopeutta on lisätä muistin määrää, sillä palvelunopeus kasvaa M:n suhteen. Palvelunopeuden kasvu ei ole lineaarista, vaan hidastuu muistin lisääntyessä [PSV08] 6. Muisti on kuitenkin rajallinen resurssi ETL-prosessissa, minkä vuoksi on relevanttia maksimoida palvelunopeutta rajalliselle muistibudjetille M max. Tällöin kyseessä on rajoitettu optimointi-ongelma, jossa jokaiselle muistibudjetille M max etsitään optimaalinen levypuskurin koko b. Vastaavana optimointi-ongelmana voidaan minimoida muistinkäyttöä annetulle palvelunopeudelle µ min. Offline-optimoinnissa b ratkaistaan ennakoidulle syötevirralle ja online-optimoinnissa b mukautetaan ajonaikaiseen syötevirtaan. Optimoinnin haittapuolena on kompleksisuuden kasvaminen ja mahdolliset virhetulokset, ja jos järkevillä vakioparametreilla päästään lähelle optimiarvoja, niin optimointi ei välttämättä kannata [NDW09]. Optimointi-ongelma on yksikäsitteisesti ratkeava, eli palvelunopeudella on yksi maksimarvo muistibudjetilla M max (kuva 6a). Tämä johtuu siitä, että annetulla muistibudjetilla levypuskurin koko b ja tietovirtapuskurin koko w riippuvat käänteisesti toisistaan, mutta molempien kasvattaminen lisää palvelunopeutta. Jos b on pieni, niin koko relaation lukemiseen vaadittava levy-i/o kasvaa ja liitoksen laskeminen suuresta hajautustaulusta vie enemmän aikaa [PSV08]. Suurella b:n arvolla levypus- 6 kuvassa 6 x-akseli on logaritminen

12 kurin osuus muistista kasvaa liikkuvan ikkunan ja hajautustaulun kustannuksella. Tällöin palvelunopeus jossakin vaiheessa pienenee enemmän sisäänluettavan syötteen vähenemisen vuoksi kuin se kasvaa levy-i/o:n jakamisen seurauksena. Verrattaessa optimaalista levypuskurin kokoa vakioarvoon havaitaan kuitenkin, että optimoinnin hyöty on kovin vähäinen (kuva 8). Vakioarvona on käytetty optimiarvoa 20MB muistimäärällä, ja enimmillään palvelunopeuden ero optimiin jää alle kahteen prosenttiin. Kuva 8: Suorituskykyvertailu levypuskurin vakiokoolla ja optimikoolla eri muistimäärillä. [NDW09]. On mahdollista, että syötevirran nopeus λ ylittää MeshJoin-algoritmin palvelunopeuden µ. Tällöin paras toimintatapa voi olla pudottaa pois osa syötevirrasta, jolloin eksaktin liitoksen sijasta saadaan approksimaatioliitos. Pudotetut syötteet voidaan prosessoida myöhemmin eikä niitä menetetä pysyvästi. MeshJoin-algoritmilla suoritettavissa liitoksissa pudotettavien monikkojen valintaan on olemassa erilaisia menetelmiä. TopW -heuristiikassa [PSV08] säilytetään ne w monikkoa, jotka ovat suoritushetkellä esiintyneet useimmin liitoksissa. Monesta-moneen approksimaatioliitoksissa TopW-heuristiikan suorituskyky on lähellä optimia [PSV08].

5 Johtopäätökset 13 Tämän työn tarkoituksena on ollut selvittää tietovirta-etl:n ja MeshJoin-algoritmin suorituskykyominaisuuksia. Edellisten lukujen perusteella yritetään vastata seuraaviin kysymyksiin: Mitä suorituskykyetuja tietovirta-etl:stä on tosiaikaisessa tietovarastoinnissa? Entä haittoja? Verrattuna tihennettyyn ETL-prosessiin. Onko MeshJoin soveltuva algoritmi tietovirtojen ja relaatioiden välisen liitoksen laskemiseksi? Muutostietojen lähettämisellä tietovirtana ETL-jonoverkkoon pyritään minimoimaan viivettä operatiivisten järjestelmien ja tietovaraston välillä. Suorituskykyhaittana perinteiseen off-line ETL-prosessiin nähden on läpivirtauksen pieneneminen, koska saapuvia tietoja käsitellään pääsääntöisesti monikko kerrallaan eikä tietovarastoa voida sulkea pois käyttäjiltä. Myös tihennetyn on-line ETL-prosessin läpivirtaus on pienempi kuin mitä perinteisessä off-line -prosessissa on mahdollista. Tihennetyn ETL-prosessin ja tietovirta-etl:n suorituskykyeroa ei kuitenkaan voida arvioida, sillä mitään vertailuja ei ole saatavilla. Operatiivisten raporttien viiveen minimointi on kuitenkin kaikkein yksinkertaisinta, jos tietovarastoa ei käytetä lainkaan, vaan kyselyt ajetaan suoraan operatiivisissa tietokannoissa tai niiden päälle perustetuissa OLAP-tietokannoissa [MTK06]. Kaikenkaikkiaan parhaan ratkaisun löytäminen tosiaikaiseen raportointiin ei ole suoraviivaista, sillä eri tekijöitä kustannus/hyötyanalyyseissä on lukemattomia. Suorituskyky on näissä vain yksi ulottuvuus. Tosiaikaisen ETL-prosessin viitekehyksenä ja suorituskykymallina tietovirta-etl on edistynyt ja käyttökelpoinen. Tietovirtojen säätely (regulation) ja monikkojen pudottaminen (shedding) mahdollistavat palvelutason kontrollin (QoS) käyttäjille näkyvissä odotusajoissa. Tällaista kontrollia tihennetyssä ETL-prosessissa ei lähtökohtaisesti ole. MeshJoin on algoritmi liitoksen laskemiseksi nopean tietovirran ja hitaan perusrelaation välillä, joka on suunniteltu läpivirtauksen optimoimiseksi rajallisella muistimäärällä. Tähän tarkoitukseen se on tehokkaampi kuin vertailukohtana käytettu INL-algoritmi. Muissa olosuhteissa MeshJoin ei kuitenkaan ole INL-algoritmia parempi. Jos saapuva tietovirta on hitaampi kuin perusrelaation tai indeksin lukemisnopeus, niin

14 INL-algoritmin läpivirtaus on samaa luokkaa MeshJoin-algoritmin kanssa, ja myös odotusaika yksittäisen tietovirran monikon ja perusrelaation liitoksen laskemiselle on pienempi. Jos muistia on riittävästi, niin perusrelaatio kannattaa pitää muistissa eikä levynkäsittelyn optimoinnista ole hyötyä. Tällöin myös nopeusero saapuvan tietovirran ja perusrelaation käsittelyn välillä saattaa kääntyä. Jos liitosoperaatiolla ei ole tosiaikavaatimusta, niin perinteiset lohkoalgoritmit mahdollistavat suurimman läpivirtauksen. Lähteet Bir09 DeB78 BIRTE 2009, Workshop on Enabling Real-Time for Business Intelligence, August 24, 2009 - Lyon, France, 2009. URL http://www.cs. toronto.edu/db/birte09/index.html. [15.09.2009]. Denning, P. ja Buzen, J., The Operational Analysis of Queueing Network Models. ACM Computing Surveys (CSUR), 10,3(1978), sivut 225 261. Inm05 Inmon, B., Building the Data Warehouse. Wiley, neljäs painos, 2005. KiR02 KVP05 MTK06 NDW09 Par09 Kimball, R. ja Ross, M., The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. Wiley, toinen painos, April 2002. Karakasidis, A., Vassiliadis, P. ja Pitoura, E., ETL queues for active data warehousing. Proceedings of the 2nd International Workshop on Information Quality in Information Systems. ACM New York, NY, USA, 2005, sivut 28 39. Mundy, J., Thornthwaite, W. ja Kimball, R., The Microsoft Data Warehouse Toolkit: With SQL Server 2005 and the Microsoft Business Intelligence Toolset. Wiley, 2006. Naeem, M. A., Dobbie, G. ja Weber, G., Comparing global optimization and default settings of stream-based joins. BIRTE 2009, 2009. Pareek, A., Addressing BI transactional flows in the real-time enterprise using GoldenGate TDM. BIRTE 2009, 2009.

15 PSV + 07 PSV08 SB08 Polyzotis, N., Skiadopoulos, S., Vassiliadis, P., Simitsis, A. ja Frantzell, N.-E., Supporting streaming updates in an active data warehouse. IC- DE, 2007, sivut 476 485. Polytzotis, N., Skiadopoulos, S., Vassiliadis, P., Simitsis, A. ja Frantzell, N.-E., Meshing streaming updates with persistent data in an active data warehouse. IEEE Transactions On Knowledge And Data Engineering, 20,7(2008), sivut 976 991. Santos, R. J. ja Bernardino, J., Real-time data warehouse loading methodology. IDEAS, 2008, sivut 49 58.