Tekninen määrittely. ETL-työkalu. ExtraTerrestriaLs / Aureolis Oy

Transkriptio

1 Tekninen määrittely ETL-työkalu ExtraTerrestriaLs / Aureolis Oy Versio Päivämäärä Tekijä Muutos Timo Sallinen Ensimmäinen versio Jani Honkanen ETL-moottori Teemu Nousiainen Kuvauskieli Mikko Ruokojoki Rakenteellisia muokkauksia dokumenttiin Jani Honkanen Arkkitehtuuri Jani Malmi Toimenpiteiden yleiskuvausta Jani Honkanen Katselmoinnissa sovittuja korjauksia Teemu Nousiainen Kuvauskielen esimerkki liitteisiin Timo Sallinen Lisätty dokumentaatiogeneraattori, korjauksia Mikko Ruokojoki Pieniä korjauksia tehty Timo Sallinen Ajantasaistettu, lisätty uusia toimenpiteitä Timo Sallinen Korjauksia Risto Kunnas Korjauksia, lisätty ImportSql Timo Sallinen Päivityksiä Timo Sallinen Ajantasaistus Timo Sallinen Parannettu toimenpiteiden kuvauksia Jani Honkanen Lisätty sekvenssikaaviot Timo Sallinen Varmistettu ajantasaisuus Sivu 1 / 31

2 Sisällysluettelo Tekninen määrittely Johdanto Dokumentin tarkoitus Sovelluksen yleiskuvaus Sanasto Arkkitehtuuri Johdanto Suunnitteluperiaatteet Toimenpiteet Toimenpiteiden parametrointi Toimenpiteiden käyttämä tietokantaluokka Java-pakettien nimeäminen Moduulit Kuvauskieli Rakenne Prosessikuvaus Konfiguraatio Projektimäärittely Kuvauskielen parserointi ETL-moottori Yleiskuvaus ETL-toimenpiteistä koostuvan prosessin esitysmuoto olioina Toimenpiteiden ajaminen ja ajojärjestyksen suunnittelu Rajapinta moottorin ja Javalla ohjelmoitujen toimenpidekomponenttien välillä ETL-prosessin aikana tapahtuvien virheiden hallinta (ei toteutettu) Tietovaraston hallinta, lookup-toiminnot, Slowly Changing Dimensions Tietokantojen ja väliaikaisvarastojen hallinta Rajapinta prosessikuvauksen lataamiseen Rajapinta prosessin suorittamiseen ja konfiguroimiseen Dokumentaatiogeneraattorin tarvitsemien tietojen kerääminen ETL-prosessista Toimenpiteet Yleiskuvaus Uusien toimenpiteiden ohjelmoiminen Copy Insert / append Pivot Delete Export Join Filter ImportCSV ImportSQL Aggregate Update Sivu 2 / 31

3 3.4 Dokumentaatiogeneraattori Yleiskuvaus Lähtöaineiston kerääminen Aineiston käsittely Viitteet Liitteet Esimerkki XML-konfiguraatiotiedostoista Projektimäärittely Prosessikuvaus Konfiguraatiotiedosto Johdanto 1.1 Dokumentin tarkoitus Dokumentti määrittelee teknisen toteutuksen ETL-työkalulle, riittävällä tarkkuudella implementoinnin mahdollistamiseksi. Sovelluskomponenttien väliset rajapinnat kuvataan UMLluokkakaavioilla. Kohderyhmänä ovat projektiryhmä, asiakas ja tulevat sovelluskehittäjät. Järjestelmää suunnitellaan jonkin verran pidemmälle kuin on tarkoitus tämän projektin aikana toteuttaa. Tarkempi kuvaus tämän projektin aikana toteutettavista toiminnoista löytyy vaatimusmäärittelystä ja projektisuunnitelmasta. Erillisessä kehitysohjeessa[1] on kuvattu käytännön tasolla järjestelmän käyttöönottoon ja jatkokehitykseen liittyviä asioita. Lukijalla oletetaan olevan hyvät yleistiedot ETL-prosesseista ja tietovarastoinnista. 1.2 Sovelluksen yleiskuvaus Sovelluksen tarkka yleiskuvaus löytyy vaatimusmäärittelystä [2]. 1.3 Sanasto Sanasto löytyy vaatimusmäärittelystä [2]. 2 Arkkitehtuuri 2.1 Johdanto ETL-työkalu koostuu seuraavista komponenteista: Kuvauskieli, jolla suunnitellaan ETL-prosessi ETL-moottori, joka koordinoi prosessin suoritusta ETL-toimenpiteet, joita käytetään työkaluina ETL-prosessissa Dokumentaatiogeneraattori, jolla tuotetaan rakennekuvaus suunnitellusta ETL-prosessista Lisäksi lähdedatan lukeminen ja tietovaraston hallinta kuuluvat järjestelmään, mutta ETLtyökaluissa ne mielletään yleensä mieluummin osaksi samaa kokonaisuutta kuin erillisiksi komponenteiksi, riippuvuuksien takia. Tuotantokäytössä ETL-työkalu pyörii loppuasiakkaan koneella Java-prosessina, joka suorittaa ETLprosessin määrätyllä tavalla ja määrättyinä aikoina. Työkalu lukee asiakkaan tietojärjestelmiä, pääasiassa operatiivisia tietokantoja ja tiedostoja, sekä tuottaa prosessin tuloksen tietovarastoon. Sivu 3 / 31

4 Kaikki prosessointi tapahtuu tavallisesti loppuasiakkaan tietokoneilla, käyttäen useampia tietokantoja ja mahdollisesti joitakin ulkoisia järjestelmiä (lähdedatan lukemiseen). Kuva 1: Deployment-kaavio tuotannossa olevasta ETL-työkalusta Sivu 4 / 31

5 Kunkin komponentin arkkitehtuuri on kuvattu tässä dokumentissa omassa luvussaan. 2.2 Suunnitteluperiaatteet Seuraavia yleisiä ohjenuoria pyritään noudattamaan koko suunnittelun ajan: Moduulijako pitää olla erittäin selkeä (tarkasti määritellyt rajapinnat), koska suunnittelussa on mukana monta ihmistä ja lisäksi kommunikointimahdollisuudet ovat heikot. Pitää keskittyä erityisen tarkasti järjestelmän runko-osiin, koska jatkokehitystä on tarkoitus tehdä paljon, myös räätälöidysti eri asiakkaille. Varotaan tekemästä työkalusta liian yleiskäyttöistä, koska markkinoilla on jo isojen firmojen suurella budjetilla tekemiä yleiskäyttöisiä ETL-työkaluja. Tehdään kevyt ( light-weight ) sovellus ja suunnataan se ainoastaan ohjelmointitaitoisten ihmisten käyttöön. 2.3 Toimenpiteet ETL-työkalu käyttää toimenpiteitä suorittamaan tietokantaoperaatioita. Toimenpiteet muodostavat prosessin, jota ETL-moottori ohjaa. ETL-moottorin ja toimenpiteiden välillä käytetään rajapintaa, jossa välitetään tietoa mm. kannoista ja lähde ja kohdetauluista. Toimenpiteiden tarkemmat kuvaukset löytyvät tämän dokumentin kohdasta moduulit, kappale Toimenpiteiden parametrointi Toimenpiteelle välitettävät argumentit voivat olla dynaamisia parametreja. Esimerkki käytöstä on vaikkapa ajonaikaisen päivämäärän lisääminen tulostaulun nimeen. Parametrit on toteutettu dynaamisesti ladattavina Java-luokkina, jotka toteuttavat com.aureolis.etltool.parameters.parameter -rajapinnan. Parametri-luokka palauttaa yhden merkkijonon, joka voidaan generoida mielivaltaisella logiikalla. Parametrit voivat olla myös staattisia, jolloin prosessikuvauksessa määritellään suoraan tämän arvo. Määrittely kuvauskielessä tapahtuu seuraavasti: <etlprocess> <parameters> <param name= pvm value= com.aureolis.etltool.parameters.dateparameter /> <param name= staticfoo value= bar isdynamic= false /> </parameters> <operations>.. <export targettable= tulos-{pvm} /> </operations> </etlprocess> Ylläolevassa esimerkissä {pvm} korvautuu DateParameter-luokan palauttamalla merkkijonolla, esim. tulos Toistaiseksi parametrien automaattisista korvausta ei ole toteutettu, vaan parametrien korvaus tapahtuu siten, että toimenpide pyytää moottoria korvaamaan mahdolliset parametrit attribuutissaan Sivu 5 / 31

6 (EngineServices.replaceParameters(attr : String) : String) Toimenpiteiden käyttämä tietokantaluokka Toimenpiteet käyttävät tietokantaluokkaa (com.aureolis.etltool.database.database), jonka kautta hoidetaan tietokantaan liittyvät toiminnot kuten tietokannan avaaminen ja SQL-lauseiden ajaminen. Luokka tarjoaa lisäksi yleisiä palveluita, kuten väliaikaistaulun luominen ja yhteyspoolin hallinta. 2.4 Java-pakettien nimeäminen Kaikki luokat ja paketit laitetaan com.aureolis.etltool-nimiavaruuden alle. Tämän alle luodaan funktionaalisesti jaettuja alipaketteja, joihin toiminnalliset luokat ja rajapinnat sijoitetaan. com.aureolis.etltool.database -tietokantojen käsittely com.aureolis.etltool.engine -etl-moottori com.aureolis.etltool.operation -toimenpiteet, jokainen omassa alipaketissaan com.aureolis.etltool.transfer -datan siirtäminen toimenpiteiden välillä com.aureolis.etltool.processlanguage -etl-prosessin kuvauskieli com.aureolis.etltool.docgen -dokumentaatiogeneraattorin pääpaketti com.aureolis.etltool.parameters -prosessiparametrit toteuttavat luokat com.aureolis.etltool.test -testausluokat ja testitapaukset 3 Moduulit 3.1 Kuvauskieli Kuvauskieli kuvaa ETL-prosessin, lähdeaineistot, kohdekannat ja toimenpiteet. Kuvauskielen toteutustavaksi valittiin projektin puitteista luotava XML-kieli. Syitä valintaan olivat: Helppo muokattavuus sekä käsin, että koneellisesti Voidaan käyttää olemassa olevia parseritoteutuksia (helppo validointi ja jäsennys) Helppo dokumentoinnin generointi Kuvauskieli on määritelty XML-Skeeman avulla, joka toimii lopullisena tarkkana kieliopillisena spesifikaationa. Tämän kappaleen tarkoitus on kielen esitteleminen yleisellä tasolla. Esimerkki kuvauskielestä löytyy liitteistä Rakenne Kuvauskieli jakautuu kolmeen osaan, moottorin konfiguraatioon, projektimäärittelyyn ja itse prosessin kuvaamiseen. Yhdessä tiedostossa ei tarvitse määritellä kaikkia näitä, vaan ne voidaan jakaa ylläpidollisesti loogisiksi kokonaisuuksiksi eri tiedostoihin. Lisäksi prosessikuvauksia voidaan hajauttaa eri tiedostoihin (aliprosessit) Prosessikuvaus Prosessikuvaus rakentuu joukosta toimenpiteitä, jotka käyttävät toistensa tuloksia syötteinään. On myös määritelty erikseen toimenpiteet, jotka hakevat dataolioita (tauluja) työskentelytilaan ja niitä, jotka vievät prosessin tuotteet tietovarastoon. Jokaisella prosessilla on oma id:nsä (yksilöivä nimi). Sivu 6 / 31

7 Yksi prosessi käyttää aina yhtä työskentelytietokantaa. Toimenpiteiden lisäksi prosessista voidaan kutsua aliprosesseja määritetyillä parametreilla. Aliprosessille voidaan määrittää oma työskentelytietokanta. Usein käytetyistä aliprosesseista voidaan täten laatia yleiskäyttöisiä kirjastoja. Aliprosessit Kuvauskielessä voidaan määritellä aliprosessi joko suoraan pääprosessikuvaustiedostoon vastaavasti kuten toimenpiteet: <etlprocess> <operations> <subprocess name=" " workingdatabaseid=" "> </subprocess> </operations> </etlprocess> <operations> </operations> Tai kutsumalla erillistä prossessikuvaustiedostoa seuraavasti: <call name="nimi" file="c:\test\aliprosessi.xml"> <argument source="korvaavatoimenpiteenoutputname" name="korvattavalähdetaulu"/> </call> Esimerkissä argumentin attribuutti name on viitatussa prosessitiedostossa määritelty lähdetaulu, joka korvataan source-attribuutilla. ETL-moottori ei konseptuaalisesti erota pää- ja aliprosesseja toisistaan, vaan parseri yhdistää prosessit siten, että aliprosessin Import-toimenpiteet korvataan Copy:lla. Jos importin syötekanta on eri kuin importin kohdekanta. Jos kannat ovat samat, poistetaan import-kokonaan. Toimenpiteiden suhteet määritellään siten, että jokaiselle toimenpiteelle määritellään prosessin sisäisesti yksikäsitteinen id-tunniste (name-attribuutti), joka määritellään seuraavan toimenpiteen syötteeksi (source). Jos toimenpiteelle ei ole määritelty lähdetoimenpidettä/taulua, asettaa parseri automaattisesti edellisen toimenpiteen tämän syötteeksi. Toimenpiteen syötteet voivat olla myös tuloksia Konfiguraatio Konfiguraatiossa määritellään käytettävät tietokannat ja prosessien ajastus. Jokaiselle käytettävälle tietokannalle määritellään yhteysasetusten (sis. URL, käyttäjätunnus, tyyppi ja salasana) lisäksi id, johon prosessikuvauksen toimenpiteet viittaavat. Ajastus toteutetaan UNIXin crontab:in tyyppisesti, eli prosessin käynnistämisajankohta määritellään viikonpäivien, kuukausien, päivien jne. perusteella. Jokainen ajastuselementti viittaa käynnistettävän prosessin nimeen. Uudemmassa DYNAMIC-haaran versiossa, konfiguraatiotiedostoon voidaan asettaa myös käytettävät toimenpideluokat. Sivu 7 / 31

8 3.1.4 Projektimäärittely Projektimäärittelyä käytetään koko ETL-moottorin konfiguroimiseen. Se sisältää viittaukset konfiguraatiotiedostoon ja prosessikuvaustiedostoihin Kuvauskielen parserointi Konfiguraatiotiedostojen parserointiin käytetään validoivaa Apache Xerces DOM-parseria. Tämän määrittelyt ja optiot validoinnin käyttöön ovat XMLProcessParser-luokassa. Validointi voidaan määritellä erikseen tapahtuvaksi joko pelkän syntaksin osalta tai skeemaa vasten. Skeemavalidointi auttaa löytämään virheitä prosessikuvauksessa jo parseroinnin aikana. Muuten virheet saattaisivat jäädä ajonaikaisiksi. Haittapuolena tietysti on se, että skeemaa joudutaan muokkaamaan uusia toimenpiteitä lisättäessä. Validoiva parseri ei siedä virheitä, vaan ajo keskeytyy välittömästi virhetilanteessa. Parseri on toteutettu siten, että kuvauskielen tekniikka voidaan tarvittaessa vaihtaa kokonaan, ilman, että muihin sovelluksen osiin tarvitsee tehdä muutoksia. Parseroinnin vaiheet 1. XmlProcessBuilder lukee projektikuvauksen (parseprocessfile()) ja muodostaa siitä DOMpuun (org.w3c.dom.document). DOM-puut validoidaan Xercesin toimesta automaattisesti. 2. XmlProcessBuilder kutsuu XmlConfigurationBuilderia, joka lukee konfiguraation ja alustaa DatabaseManager-instanssin tässä määritellyillä tietokantakonfiguraatioilla. 3. Prosessikuvaustiedostosta muodostetaan niinikään DOM-puu, joka välitetään XmlProcessBuilder-luokalle geneerisen ProcessBuilderin kanssa. 4. XmlProcessBuilder parseroi prosessikuvauksen, lataa toimenpidekomponentit ja lisää ne riippuvuuksineen prosessiin ProcessBuilder-luokan metodeilla. ProcessBuilder-sisältää tämän jälkeen OperationNode-verkon, joka kuvaa prosessin java-olioina Virhetilanteessa suoritus keskeytyy ProcessBuildException-poikkeukseen. ProcessBuilder-instanssilla on kolme käyttötarkoitusta: 1. Dokumentaation generointi prosessin parseroinnin jälkeen 2. ProcessRun-luokka, jolla prosessi voidaan ajaa on-demand 3. Scheduler-jolla prosessi voidaan ajaa ajastetusti Sivu 8 / 31

9 3.2 ETL-moottori Yleiskuvaus ETL-moottorin päätehtävänä on suorittaa annettu ETL-prosessi ja tuottaa prosessin lopputulos tietovarastoon. Oleellisia osia moottorissa ovat: ETL-toimenpiteistä koostuvan prosessin esitysmuoto olioina Toimenpiteiden ajaminen ja ajojärjestyksen suunnittelu Rajapinta moottorin ja Javalla ohjelmoitujen toimenpidekomponenttien välillä ETL-prosessin aikana tapahtuvien virheiden hallinta Tietovaraston hallinta, lookup-toiminnot, Slowly Changing Dimensions (ei toteutettu) Tietokantojen ja väliaikaisvarastojen hallinta Rajapinta prosessikuvauksen lataamiseen Rajapinta prosessin suorittamiseen ja konfiguroimiseen Dokumentaatiogeneraattorin tarvitsemien tietojen kerääminen ETL-prosessista ETL-toimenpiteistä koostuvan prosessin esitysmuoto olioina Prosessi kuvataan moottorin sisällä verkkona, jossa solmut vastaavat toimenpiteitä ja solmut on kytketty toisiinsa sen mukaan, minkä toimenpiteiden tuloksia kukin toimenpide käyttää syötteenään. Prosessin ajon aikana OperationNode-luokka vastaa yhtä tällaista solmua ja sisältää viittauksen EtlOperation-olioon, jossa on varsinainen toimenpiteen toteutus. OperationNode-oliossa on lista edeltävistä ja seuraavista solmuista, sekä InputArguments-rakenne, johon kerätään syötetaulut sitä mukaa kun edeltäviä toimenpiteitä saadaan suoritettua. Solmulla on myös nimi, jota käytetään dokumentaatiogeneraattorissa toimenpiteen identifiointiin. Tämä on sama, kuin kuvauskielessä määritelty name-attribuutti, tai sen puuttuessa moottorin generoima merkkijono. Sivu 9 / 31

10 Kuva 2: Prosessin rakenteen kuvaamiseen liittyvät luokat (moottorin sisäinen esitystapa) Prosessin suorittaminen useammin kuin kerran Prosessin voi suorittaa vain kerran, minkä jälkeen se on ladattava kuvaustiedostosta uudestaan (mm. OperationNode ja EtlOperation -oliot ovat kertakäyttöisiä). Mutta jos nähdään tulevaisuudessa tarvetta suorittaa prosessi useampaan kertaan ilman latausta, voidaan toteuttaa toinen vastaavanlainen toimenpideverkko, jossa jokainen solmu sisältää EtlOperationFactory-olion. Yksinkertainen tapa olisi ladata järjestelmän käynnistyksen yhteydessä (tai prosessin kuvaustiedoston muuttuessa) prosessiverkko kokonaan muistiin tällaiseksi verkoksi ja luoda sen perusteella EtlOperation-verkko erikseen jokaista ajoa varten. Toinen mahdollisuus on pitää muistissa vain lähdedataa kuuntelevat toimenpideoliot tai muut komponentit, jotka saattavat laukaista prosessin, ja ladata prosessi vasta kun se ajetaan. Toimenpidekomponentteja arveltiin olevan prosessissa korkeintaan muutamia satoja tai muutamia tuhansia, joten kaikkien factory-olioiden pitäminen muistissa ei liene ongelma, elleivät ne tarvitse jotain erityisiä resursseja. Aliprosessit Nykyisessä toteutuksessa on lähdetty siitä, että aliprosessit ovat kuvauskielikohtainen asia, eikä moottorissa ole erikseen tukea aliprosesseille. Parserin tehtävä on tulkita prosessikuvaustiedostossa määritellyt aliprosessikutsut ja antaa ladattu prosessi moottorille avattuna, eli siten, että Sivu 10 / 31

11 aliprosessien sisältämät toimenpiteet on sijoitettu ko. aliprosessikutsun tilalle ja moottori näkee prosessin yhtenä isona toimenpiteiden muodostamaa verkkona. Parseri voisi myös toteuttaa aliprosesseja varten oman aliprosessin kutsumistoimenpiteen, jolla olisi samankaltaiset syötteet ja tulokset kuin muillakin toimenpiteillä, mutta sen toteutus lähettäisi syötteet toiselle ETL-prosessille (aliprosessille) ja saisi siltä tulokset. Huonona puolena olisi kuitenkin, että pääprosessia ajava moottori ei olisi tietoinen aliprosessin sisäisestä toiminnasta, eikä pystyisi optimoimaan sen suoritusta, huomioimaan sitä dokumentaation generoinnissa, tuottamaan lokiviestejä kätevästi jne. Moottoriin voisi periaatteessa lisätä tuen tällaisille kutsumistoimenpiteille siten, että moottori osaisi suorittaa myös aliprosessin itse. Mutta toisaalta esimerkiksi prosessin esitysrakenteen selkeyden ja toimenpiteiden aikataulutuksen kannalta voisi olla parempi pitää koko prosessi yhtenä isona verkkona ja merkitä aliprosesseihin liittyvät ominaisuudet (nimeäminen, konfiguraatio, rajoitukset suoritusjärjestykseen yms) johonkin aliprosessihierarkiaan, jota moottori pitäisi osana prosessin sisäistä esitysmuotoa Toimenpiteiden ajaminen ja ajojärjestyksen suunnittelu ProcessRun-olio vastaa yhtä prosessin suorituskertaa ja sisältää ajojärjestyksen koordinointiin liittyvän koodin. ProcessRun aloittaa prosessin käynnistämällä joukon sellaisia toimenpiteitä, jotka eivät käytä syötteenä mitään toista toimenpidettä (yleensä nämä ovat asiakkaan lähdedataa lukevia toimenpiteitä). Toimenpiteen suoritusta varten luodaan OperationExecutor-olio, joka käynnistää toimenpiteen erillisessä säikeessä ja ilmoittaa lopulta tuloksen ProcessRun:lle. Kukin toimenpide voidaan suorittaa aikaisintaan silloin, kun kaikki sen syötteenä käyttämät toimenpiteet on saatu suoritettua. Ajojärjestyksen suunnittelu ja aikataulutus voidaan eriyttää myöhemmin toiseen luokkaan, jos tarvetta ilmenee. ProcessRun ei tee erityistä aikataulutusta tai toimenpiteiden priorisointia, mutta on suunniteltu siten, että näitä ominaisuuksia voidaan myöhemmin lisätä. Sivu 11 / 31

12 Kuva 3: Toimenpiteen ajaminen Taulujen sisältöä muokkaavat toimenpiteet kirjoitusoikeuksien hallinta Toisinaan on tarvetta muokata vain muutamaa riviä isosta taulusta. Useampi toimenpide saattaa kuitenkin tarvita samaa taulua syötteenä, joten on estettävä jotenkin konfliktien syntyminen, esimerkiksi ottamalla kopioita syötetauluista eri toimenpiteitä varten. Nykyinen moottorin toteutus tekee aina kopiot kaikista toimenpiteen syötetauluista varmuuden vuoksi, mutta tehokkaammin homman voisi hoitaa esimerkiksi näillä päättelysäännöillä: Jos toimenpide ei tule lähdetaulun muokkausta suoraan (ts. read-only-tyyppinen toimenpide), ei kannata koskaan ottaa kopiota lähdetaulusta. Muussa tapauksessa toimenpiteen annetaan tehdä muutokset aina suoraan lähdetauluun, jos mikään muu toimenpide ei tarvitse kyseistä taulua. Jos jotkut muut toimenpiteet tarvitsevat kyseistä taulua ensin lukemiseen, voidaan joko ottaa taulusta kopio muokkausta varten tai odottaa kunnes taulua lukevat toimenpiteet on suoritettu. Sivu 12 / 31

13 Toimenpiteiden riippuvuuksien hallinta Toimenpide voidaan suorittaa silloin, kun sen kaikki syötetaulut ovat valmiina. Muunkinlaisille riippuvuuksille voisi olla käyttöä, voitaisiin esimerkiksi määritellä prosessikuvaukseen korkeammalla prioriteetillä olevia toimenpiteitä, jotka tulee suorittaa ennen tiettyjen muiden toimenpiteiden suorittamista (eli optimoitaisiin käsin toimenpiteiden suoritusjärjestystä). Eli toimenpiteelle itselleen voitaisiin antaa mahdollisuus kertoa, onko se valmis suoritettavaksi. Ajojärjestyksen suunnittelu Nykyisessä toteutuksessa toimenpiteet suoritetaan heti, kun kaikki syötteet ovat saatavilla. Suoritusjärjestyksen voisi kuitenkin suunnitella paremminkin esim. seuraavien seikkojen perusteella: Maksimimäärä yhtaikaa suoritettaville toimenpiteille Prioriteettijärjestys, jos pitää valita mikä toimenpide suoritetaan seuraavaksi Sync barriers. ETL-prosessi suunnitellaan usein niin, että se koostuu muutamasta peräkkäisestä aliprosessista, jotka ajetaan yksi kerrallaan, tai ainakin priorisoidaan vanhaan aliprosessiin kuuluvia toimenpiteitä. Suoritusaika- ja muistinkulutusarvioita, joiden perusteella voitaisiin priorisoida kriittisellä polulla olevia toimenpiteitä. Arvioita voisi antaa käsin, laskea rivimäärien perusteella tai muistaa edellisestä prosessiajosta. Prosessin ajaminen yksi toimenpide kerrallaan debuggausta varten. Lähdedatan kopiointi työkantaan nopeasti prosessin alkuvaiheessa, jotta se on mahdollisimman samanaikaista Rajapinta moottorin ja Javalla ohjelmoitujen toimenpidekomponenttien välillä Kun moottori päättää suorittaa toimenpiteen, se kutsuu ko. toimenpiteen run()-metodia. Argumentteina annetaan syötetaulut (InputArguments) ja paluuarvona saadaan tulostaulut sekä tietoja tapahtuneista virheistä (OutputArguments). EngineServices-luokka sisältää moottorin tarjoamia palveluita, joilla toimenpidekomponentti pääsee käsiksi työtietokantoihin sekä muihin tarpeellisiin moduuleihin. Moduulit ovat nimettyjä olioita, jotka luodaan konfiguraatiotiedoston perusteella ja jotka auttavat toimenpidekomponentteja prosessin suorittamisessa. Moduuleihin voi kuulua esim. tietojen lukemista tietovarastossa olevista lookup-tauluista tai jostain ulkoisesta järjestelmästä. InputArguments ja OperationResult sisältävät yhden tai useamman viittauksen tietokantatauluihin, jotka toimivat toimenpiteen syötteenä/tuloksena. Näiden rakenteesta kerrotaan tarkemmin kohdassa Vikasietoisuus Moottorin ja toimenpidekomponenttien välinen rajapinta on tarkoitus pitää sellaisena, että toimenpidekomponenteissa mahdollisesti olevat ohjelmointivirheet haittaisivat mahdollisimman vähän järjestelmän toimintaa. Tämä siksi, että toimenpidekomponentteja voi lopullisessa työkalussa olla paljon (kymmeniä) ja uusia toimenpiteitä on lisäksi tarkoitus ohjelmoida räätälöidysti asiakasprojekteissa. Sivu 13 / 31

14 Kuva 4: Rajapinta moottorin ja toimenpidekomponenttien välillä Toimenpiteissä oleviin ohjelmointivirheisiin varaudutaan mm. seuraavasti (ei toteutettu): Työtaulut ja tietokantayhteydet vapautetaan automaattisesti moottorin toimesta, kun toimenpide päättyy. Jos toimenpide jää jumiin, sen suoritus katkaistaan, väliaikaistaulut vapautetaan ja prosessia mahdollisesti jatketaan. Toimenpidekomponentin ei anneta kutsua moottorin palveluita enää sen jälkeen, kun toimenpiteen suoritus on päättynyt. Syötetaulujen kopiointi tiettyyn työkantaan toimenpidettä varten. Toimenpiteet eivät kutsu toistensa Java-metodeita suoraan (synkronointiongelmien välttämiseksi). EtlOperation-olio poistetaan suorituksen jälkeen muistista (poistamalla olio Mapeista yms.), jotta muistiin ei jää vahingossa isoja olioita. Toimenpiteen etenemistä mitataan getprogress-metodilla, jolla saatetaan havaita toimenpiteen jumiutuminen tai tavallista pidempi suoritusaika. Sivu 14 / 31

15 3.2.5 ETL-prosessin aikana tapahtuvien virheiden hallinta (ei toteutettu) Yleisesti ETL-prosessin pitää pystyä jatkumaan lähdedatassa olevista virheistä huolimatta. Lähdedatassa olevia virheitä pyritään suodattamaan erityisillä puhdistustoimenpiteillä (projektikohtaisesti). Lisäksi toimenpidekomponentit saattavat tuottaa virheitä, jos toimenpidettä ei pystytä ajamaan johtuen lähdetauluissa tai niiden riveissä olevista virheistä. Toimenpidekomponenteille tarjotaan mahdollisuus kirjata tällaisia virheitä virhelokiin, joka on käytännössä tietovarastossa sijaitseva taulu. Lisäksi toimenpide voi tuottaa virhetaulun aivan samaan tapaan kuin tavallisen tulostaulun, ja tätä virhetaulua voidaan edelleen käsitellä ETLprosessissa. Toimenpidekomponentti palauttaa tuloksen mukana tietoja tapahtuneista virheistä ja niiden vakavuudesta, minkä perusteella moottori päättää, voidaanko prosessia jatkaa. On myös mahdollista, että tietokantayhteys katkeaa tai sattuu joku muu tilapäinen häiriö. Tähän varaudutaan tallentamalla prosessin välituloksia sopivin väliajoin (määritelty käsin prosessikuvauksessa) ja mahdollistamalla prosessin käynnistys jostain välituloksesta alkaen. Välituloksella tarkoitetaan sellaista taulujoukkoa, joka sisältää kaikki seuraavaksi ajettavien toimenpiteiden tarvitsemat syötetaulut Tietovaraston hallinta, lookup-toiminnot, Slowly Changing Dimensions Tietovaraston käsittelyä ei ole tarkasti suunniteltu, mutta varastoon kirjoittaminen tulee tapahtumaan etupäässä siihen tarkoitetuilla toimenpidekomponenteilla (rivien / taulujen lisääminen ja päivittäminen varastoon). Tietovarastossa olevan (vanhan) tiedon lukeminen prosessin aikana toteutetaan luultavasti myös toimenpidekomponenteilla ja/tai Javalla tehdyllä moduuleilla, joita voidaan kutsua mistä tahansa kohdasta ETL-prosessia Tietokantojen ja väliaikaisvarastojen hallinta ETL-prosessin aikana käytetään välitulosten tallentamiseen väliaikaisia tietokantatauluja, jotka moottori luo tarvittaessa. Moottori tarjoaa toimenpidekomponenteille seuraavia väliaikaistauluihin liittyviä palveluita: Halutunmuotoisten taulujen luonti Taulujen nimien valitseminen (törmäysten estämiseksi, myös jos useampi moottorin instanssi käyttää samaa tietokantaa) Toimenpiteen tulostaulujen automaattinen droppaaminen sitten, kun niitä ei enää käytetä Toimenpiteen sisäisten väliaikaistaulujen droppaaminen heti toimenpiteen päätyttyä Valmiita toimintoja taulujen kopiointiin, tuomiseen toisesta tietokannasta jne. Taulujen lukuoikeuksien hallinta ja taulujen monistaminen (jos samaa taulua käyttää syötteenä useampi toimenpide, joista osa haluaa tehdä muutoksia suoraan ko. tauluun) Moottorin väliaikaistaulujen hallinnointiin tarkoitetut WorkingDatabaseManager, WorkingDatabase ja WorkingTable käyttävät hyväkseen yleisempiä DatabaseManager ja Database -luokkia. SqlTable-olio taas on pelkkä viittaus jossakin kannassa olevaan tauluun, eikä Databaseluokka pidä erikseen kirjaa ko. tietokannassa olevista tauluista. Yhtä fyysistä taulua kohti voi siis olla olemassa useampia SqlTable-olioita. Toimenpidekomponentin ei ole tarkoitus käsitellä Working-luokkia suoraan missään tilanteessa, vaan niitä käytetään moottorissa sisäisesti. Toimenpidekomponentti käyttää EngineServicesluokassa olevia palvelumetodeja. Sivu 15 / 31

16 Kuva 5: Työtietokantojen hallintaan liittyvät luokat Tietokannassa olevaan tauluun viitataan SqlTable-luokalla, joka sisältää taulun nimen ja tietokannan lisäksi kuvauksen taulun muodosta (SqlTableFormat) sekä loogisen taulunimen, jota käytetään debug-viesteissä ja muissa vastaavissa tarkoituksissa (ei kuitenkaan taulun tunnistavana nimenä). SqlTableFormat sisältää luettelon taulun sarakkeiden nimistä ja tyypeistä, listan primary key -sarakkeista ja joukon indeksejä. Toimenpidekomponentin syötteiden ja tulosten rakenne Syöte ja tulos ovat kumpikin joukko nimettyjä tauluja, jotka sijaitsevat työtietokannassa. Tyypillisesti kuvauskielessä toimenpiteiden syötteet määrätään antamalla niiden toimenpiteiden nimet, joiden tuloksia käytetään syötteenä (ja lisäksi ko. toimenpiteen tulostaulun nimi, jos sillä on useita tulostauluja). Jokainen nimetty syöte ja tulos on yksi tietokantataulu ja käytännössä useimmat toimenpiteet tuottavat vain yhden tulostaulun, mutta käyttävät useampaa syötettä. Syötteiden ja tulosten nimet ovat vain kuvauskielessä esiintyviä nimiä, eivätkä vastaa suoraan työtietokannassa käytettäviä nimiä. Moottori generoi työtauluille yksilölliset nimet, tosin liittäen kuvauskielessä esiintyvän nimen osaksi fyysistä nimeä (debuggausta varten). Järjestelmään voisi myös lisätä tuen sille, että toimenpiteellä voisi olla ennalta tuntematon määrä tulostauluja, mutta käytännössä ei ole keksitty yhtäkään toimenpidekomponenttia, joka tarvitsisi tätä ominaisuutta. Datan välittäminen muualla kuin tietokannassa Nykyinen versio tukee datan välittämistä toimenpiteestä toiseen vain työtietokannassa olevissa tauluissa, mutta joissakin tilanteissa voisi olla edullisempaa välittää dataa esimerkiksi Java-olioina. Sivu 16 / 31

17 Kaikki tehdyt toimenpiteet on kuitenkin suunniteltu nimenomaan käsittelemään dataa tietokannassa ja Java-olioihin pohjautuva datanvälitysmuoto edellyttäisi, että niille toteutettaisiin mielekäs joukko toimenpidekomponentteja. Toisaalta datan välittäminen ilman varsinaista tietokantaa on mahdollista ottamalla käyttöön jokin kevyt muistinvarainen JDBC-tietokanta. Työtaulujen automaattinen droppaaminen Toimenpidekomponentti voi luoda uuden työtaulun kahdella tavalla: Kutsumalla moottorin palvelua, joka luo uuden taulun ja palauttaa sen fyysisen nimen Pyytämällä moottorilta yksilöllisen nimen uudelle työtaululle, luomalla taulun itse (esim. create table as select... ) ja rekisteröimällä taulun moottorille (ei toteutettu) Molemmissa tapauksissa moottorille jää tieto luodusta työtaulusta, jotta moottori voi tuhota taulun, kun sitä ei enää käytetä. Tämä mahdollistaa työtaulun tuhoamisen heti toimenpiteen ajon jälkeen, jos se ei ole osa toimenpiteen tulosteita. Jos taas on, taulu pidetään olemassa niin kauan kuin joku toimenpide sitä käyttää. Seuraavat toimenpiteet voivat myös käyttää ko. taulua omana tulostaulunaan, jolloin taulu pidetään edelleen tietokannassa, kunnes siihen ei ole enää yhtään viittausta käynnissä olevista toimenpiteistä tai tämänhetkisestä välituloksesta. Työtaulun luominen moottorin palvelun avulla Työtaulun luominen moottorin palvelun avulla Sivu 17 / 31

18 Työtaulun luominen suoraan tietokantaan ja rekisteröiminen moottoriin Pääprosessin välitulokset ETL-prosessi koostuu tyypillisesti muutamasta erillisestä vaiheesta, joiden välituloksiin saattaa kuulua tauluja, joita päivitetään prosessiajosta toiseen. Moottori ei käsittele näitä samalla tavalla kuin prosessin sisäisiä väliaikaistauluja, vaan niitä käsitellään importin ja exportin kaltaisilla toimenpiteillä, ikään kuin nämä välitulokset olisivat tietovarastoja. Näiden taulujen luonti ja päivitys tapahtuu samalla tavalla kuin tietovarastotaulujen muutenkin. Tietokantayhteydet Toimenpidekomponentit pyytävät tietokantayhteyden joko DatabaseManager-luokalta, tai jokaiseen syötteenä käytettävään SqlTable:n liittyvältä Database-luokalta. Tämä tarjoaa metodit yhteyden avaamiseen ja sulkemiseen, joka kätkee mm. Yhteyspooleihin liittyvät likaiset yksityiskohdat toimenpiteiltä. Toimenpidekomponentin on vapautettava kaikki avaamansa yhteydet, joita se voi avata useita. Tuki useammalle tietokannalle Järjestelmään voi konfiguroida useita tietokantoja ja toimenpidekomponentti voi luoda työtauluja mihin tahansa tietokantaan. Käytännössä päätettiin tehdä kuvauskielessä niin, että kukin prosessi (tai aliprosessi) käsittelee aina yhtä työtietokantaa. Toimenpiteen ominaisuuksissa voi määrätä, että moottorin tulee kopioida kaikki toimenpiteelle annetut syötetaulut ensin tiettyyn työkantaan, mikäli ne sattuvat sijaitsemaan toisessa kannassa. Muussa tapauksessa toimenpiteen syötteet saattavat sijaita useissa kannoissa, mikä voi olla tehokkaampaa kuin kopiointi, jos vaikka tarvitsee lukea vain muutama rivi isosta taulusta. Tietokantavirheiden hallinta Moottori ottaa kiinni kaikki toimenpiteen läpi päästämät poikkeukset, joten jos toimenpide itse ei käsittele esimerkiksi tietokantayhteyden katkeamistilannetta, niin moottori päättelee vain kyseisen Sivu 18 / 31

19 toimenpiteen suorituksen epäonnistuneen ja hylkää tuloksen. Kantayhteyksien uudelleenavaamista yms. ei ole toteutettu Rajapinta prosessikuvauksen lataamiseen Tarkoituksena on eriyttää moottori kuvauskielitiedoston lataajasta, jotta kuvauskieli ja sen esitysmuodon yksityiskohdat voivat vaihdella ilman että moottoria tarvitsee muuttaa. Kuvauskielen lataajakomponentti syöttää prosessin moottorille ProcessBuilder-olion kautta, joka sisältää metodit mm. toimenpidekomponenttien lisäämiseen ja niiden linkittämiseen. Lisäksi lataajakomponentin tehtävä on luoda EtlOperationFactory-oliot ja antaa niille konfiguraatioparametrit. Kuvauskielessä määritellyn prosessin ei tarvitse vastata rakenteeltaan kovin tarkasti moottorin sisäisesti käyttämää muotoa, vaan kuvauskielen lataajakomponentti voi esimerkiksi lisätä joitakin toimenpiteitä ilman, että prosessin suunnittelija on niitä erikseen kuvauksessa maininnut. Tällaisia toimenpiteitä voivat olla esimerkiksi taulujen automaattinen kopiointi työkantojen välillä tai indeksien poistaminen tilapäisesti raskaan lisäysoperaation ajaksi Rajapinta prosessin suorittamiseen ja konfiguroimiseen Prosessin ajamiseen liittyvät toiminnot löytyvät pääasiassa ProcessRun-luokasta ja konfiguroimiseen liittyvät toiminnot tämän lisäksi ProcessBuilder-luokasta. Prosessien ajastettuun ajoon ja konfiguraatioon liittyvät suunnitelmat löytyvät kuvauskielen schema:sta Dokumentaatiogeneraattorin tarvitsemien tietojen kerääminen ETLprosessista Moottoriin on toteutettu mm. seuraavien tietojen kerääminen prosessista: Toimenpideverkon rakenne Toimenpiteiden nimet, tyypit ja kuvaukset Kunkin toimenpiteen syöte/tulostaulujen rakenne (kaikissa tapauksissa rakennetta ei voi ennustaa tarkasti ennen prosessin ajoa, koska se riippuu lähdedatasta) Käytetyt väliaikaistietokannat Näistä kaksi ensimmäistä saadaan pelkällä kuvauksen parseroinnilla (ja täten OperationNodeverkon luomisella). Kaksi jälkimmäistä vaatii moottoria, ja prosessin ajoa ennen dokumentaation generaatiota. 3.3 Toimenpiteet Yleiskuvaus Toimenpiteet ovat yhtenäisen rajapinnan toteuttavia Java-komponentteja, jotka suorittavat datan käsittelyyn liittyviä tehtäviä ( transformations ). Toteutetut perustoimenpiteet ovat: ImportSQL, SQL-taulun tuonti prosessin käsiteltäväksi ImportCSV, CSV-tekstitiedoston muuntaminen SQL-tauluksi Copy, taulun kopiointi Insert / append Update Sivu 19 / 31

20 Aggregate (sum, count, min, max, average ja näitä käyttävät lausekkeet) Filter, rajaus Join (left & right) Pivot (samankaltaisten sarakkeiden yhdistäminen) Delete, taulun tai rivien poisto Export, taulun vienti tietovarastoon (load) Jokainen Javalla tehty toimenpidekomponentti toteuttaa EtlOperationFactory-luokan, jolle välitetään prosessin latausvaiheessa sellaiset parametrit, jotka pysyvät vakiona prosessin suorituskertojen yli. Joka kerta kun prosessi ajetaan, moottori luo factory-luokkien create()-metodia kutsumalla jokaisesta toimenpidekomponentista EtlOperation-rajapintaa toteuttavan olion, jonka tehtävä on suorittaa toimenpide juuri kyseisen prosessiajon aikana. Kun toimenpide on määrä suorittaa, moottori antaa sille joukon viittauksia edeltävien toimenpiteiden tuottamiin tauluihin (usein vain yhteen tauluun) InputArguments-luokassa. Toimenpidekomponentti voi kutsua moottorin palveluja luodakseen omaan käyttöön väliaikaisia tauluja sekä joukon tulostauluja, joihin se kirjoittaa lopullisen tuloksensa. Toimenpidekomponentin ei yleensä tarvitse murehtia taulujen nimien valinnoista (törmäysten välttämisestä) tai väliaikaisten taulujen poistamisesta. Toimenpidekomponentti palauttaa tuloksensa OperationResult-oliossa, joka sisältää tulostaulujen kuvauksen lisäksi tietoa toimenpiteen aikana tapahtuneista virheistä. Lähdedatassa olevat virheet tulee toimenpiteiden yleensä tunnistaa ja tuottaa niistä virheilmoitukset moottorin virheidenhallintajärjestelmää varten. Tietokantayhteyksien katketessa tai konfiguraatiovirheen sattuessa taas toimenpidekomponentti heittää poikkeuksen. Tämä mahdollistaa sen, että moottori voi yrittää suoritusta myöhemmin uudelleen, nykyiseen versioon tätä ei ole toteutettu. Alla on kuvaukset toteutetuista toimenpidekomponenteista ja niiden ominaisuuksista Uusien toimenpiteiden ohjelmoiminen Toimenpidekomponentteja luodaan sekä tämän projektin aikana että räätälöidysti eri asiakkaita varten. Toimenpidekomponentin luominen tehdään seuraavasti: Suunnittele komponentti (parametrit, syötteet, tulokset, toiminta, virhetilanteet jne.) ja kirjoita siitä samanlainen kuvaus kuin alla olevissa toimenpidekomponenttien kuvauksissa. Suunnittele samalla, miten toimenpidekomponentti kuvataan kuvauskielessä. Räätälöityjä komponentteja varten ei yleensä kannata tehdä muutoksia kuvauskieleen. Tee komponentille Java-pakkaus. Jos kyseessä on työkaluun liitettävä yleiskäyttöinen komponentti, pakkaus tulee luoda com.aureolis.etltool.operation-pakkauksen alle. Jos kyseessä on asiakasprojektiin tehty räätälöity komponentti, voidaan käyttää jotain projektikohtaista pakkausnimeä (tai laittaa samaan pakkaukseen muiden toimenpiteiden kanssa). Tee EtlOperationFactory:n toteuttava luokka. Tähän luokkaan ei yleensä pidä laittaa mitään muuttuvia attribuutteja, vaan ainoastaan konfiguraatiotietoa, joka pysyy vakiona olion olemassaolon ajan. Samaa EtlOperationFactory-oliota voidaan käyttää useiden prosessiajojen ajan. Tee EtlOperation:n toteuttava luokka, jonka instanssin EtlOperationFactory.create()-metodi luo. Tätä EtlOperation:n toteuttamaa oliota käytetään vain yhden prosessiajon ajan ja sen jälkeen se hylätään, eikä moottori käytä samaa oliota enää seuraavassa prosessiajossa (vaan luo uuden Sivu 20 / 31