Edellinen blogini käsitteli esityskerrosta (infokerrosta). Nyt käymme läpi laajemmin arkkitehtuuria.
Millainen olisi modernin teknologian tietovarastoympäristö, joka on mahdollisimman helppokäyttöinen, nopeasti käyttöönotettavissa ja periaatteiltaan selkeä ja ymmärrettävä.
Miksi monimutkaisuus on kasvanut
Kuten viime blogissani totesin, tietovarastointi on käynyt läpi monia kehitysvaiheita. Bill Inmon määritteli tietovarastoinnin perusideat korostaen yritystason ratkaisua ja tietojen integrointia. Sitten tuli Kimballin jalostama tähtimallisuunnittelu sekä Dan Linstedtin Data Vault -arkkitehtuuri. Nykyisin Bill Inmonkin kouluttaa ja kirjoittaa Data Lakehouse -arkkitehtuurista.
Tietovarastointitekniikoiden alati muuttuessa ja näennäisesti kehittyessä välillä tuntuu, että alasta on alkanut kehittyä jonkinlainen salatiede, jonka syvälliseen ymmärtämiseen vain harvat pääsevät.
Meidän pitää pystyä parempaan
Joskus jonkin asian kehittäminen alkaa kääntyä itseään vastaan, panokset menevät sisäiseen kehitykseen ja unohtuu, mikä olikaan koko tekemisen tarkoitus. Tavoitteenahan on saada aikaan huomattavaa lisäarvoa liiketoiminnalle tuomalla organisaation omat, tietojärjestelmiin hautautuneet ja hajautuneet tiedot helposti saataville analyyseja ja tutkimista varten.
Tämä pitäisi tehdä mahdollisimman yksinkertaiseksi ja ymmärrettäväksi. Jos toimittajan esittelemä arkkitehtuuri ja ratkaisu menevät hilseen, kannattaa miettiä miten edetä.
Lähtökohtia uudelle tietovarastoinnille
Tässä muutamia tavoitteita ja ratkaisuja tavoitteisiin pääsemiseksi.
Ensinnäkin tavoitteena on kompleksisuuden vähentäminen. Tähän liittyy se, että tietojen siirtämistä ja latausajoja pyritään minimoimaan – ne usein aiheuttavat viiveitä ja vievät aikaa.
Kolmanneksi pyritään vähentämään lähtöjärjestelmien tietorakenteiden tutkimiseen kuluvaa aikaa – analyytikot haluaisivat tehdä työtään, eivät arvuutella, mitä tiedot tarkoittavat.
Tavoitteena on ymmärtää kokonaisuus ja tärkeimmät tietorakenteet. Tätä varten tarvitaan tietoja kuvaavia karttoja, eli käsitemalleja.
Tarvitaan kasvupolku vanhasta tietovarastosta uuuteen, saumattomasti. Nykymaaailmassa tarvitaan mukaan myös strukturoimatonta tietoa, kuten tekstiä.
Lopuksi vielä: tietovaraston tulee tukea sekä erillisiä liiketoiminta-alueita (yksittäisen osaston tiedot) että yhdistettyjä tietoja koko organisaation läpi – eli integroituja tietoja.
Tietovaraston pääosat
Tietovarasto jaetaan kolmeen osaan. Tietoallas-osa on paikka, johon tiedot alunperin lähtöjärjestelmistä tuodaan ja jota nyt myös käytetään tietovaraston kyselyissä. Infoaltaalla säilytetään mastertiedot ja mastertietojen relaatiot organisaation eri liiketoiminta-alueiden tietoihin. Kutsumme näitä relaatioita integraatiopisteiksi. Eri liiketoiminta-alueiden tietojen integrointi eli yhdistäminen toisiinsa tehdään infoaltaalla.
Yhden liiketoiminta-alueen näkökulmasta suurin osa tiedoista on tietoaltaalla ja integrointiin liittyvät tiedot ja mastertiedot ovat infoaltaalla.
Kolmas osa on viime blogini aihe, eli infokerros (esityskerros), jonka päälle rakennetaan SQL:llä, Business Intelligence -työkaluilla ja muilla välineillä kyselyjä, raportteja ja analyysejä.
Mainittakoon vielä, että arkkitehtuurimme perustuu Data Lakehouse-arkkitehtuuriin, joita on toteutettu esimerkiksi Databricks, Snowflake ja Microsoftin Fabric alustoilla.
Integrointi – mitä se oikein tarkoittaa
Integrointi-sanaa käytetään usein kuvaamaan sitä, että tiedot on vain viety tietovarastoon. Englannin sana ”ingest” olisi parempi. Oikeasti integrointi tarkoittaa eri lähteistä tulevien tietojen yhdistämistä jonkin yhteisen avaimen avulla. Esimerkiksi asiakkaseen liittyviä tietoja löytyy myynnistä, markkinoinnista, tilauksista ja niin edelleen. Nämä tiedot tulee yhdistää, eli integroida, asiakastunnuksen avulla kokonaiskuvan muodostamiseksi asiakkaasta.
Edellyttääkö tietovaraston rakentaminen kuitenkaan kaikkien tietojen viemistä samaan purkkiin lähelle toisiaan? Ei, sillä tyypillisesti vain pieni osa eri järjestelmistä tulevista tauluista liittyy toisiinsa. Suurin osa taulujen välisistä relaatioista on tietyn järjestelmän sisällä. Yli järjestelmien liitettävät taulut muodostavat integraatiopisteet.
Voimme jättää suurimman osan tiedoista tietoaltaalle ja yhdistää tietovaraston infoaltaalla vain osan tiedoista, eli juuri ne osat, jotka eli liiketoiminta-alueiden välillä todella liittyvät toisiinsa. Näitä ovat mastertiedot, kuten asiakas, tuote, organisaatioyksikkö, kustannuspaikka ja työntekijä; ne kiinnostavat laajasti eri liiketoiminta-alueita ja niiden avulla saadaan uutta kokonaisnäkemystä.
Infoallas, tietoallas ja esityskerros
Master-tietojen lisäksi toinen infoaltaalla toteutettava asia ovat niiden suhteet muihin tietoihin, eli integraatiopisteet. Esimerkkijä ovat sopimukset (esim. asiakkaaseen liittyvät vakuutukset, liittymäsopimukset, pankkitilit tai hoitojaksot) ja joskus osa tapahtumista (kuten maksu, korvaus).
Masterdatat kannattaa tuoda kokonaisuudessaan i2nfoaltaalle tarkalla tasolla, koska niiden volyymi on yleensä pieni. Sopimuksista sen sijaan tuodaan vain avaimet (vrt. Data Vaultin hubin käsite). Loput tiedot voidaan jättää tietoaltaalle.
Näin voidaan päästä tilanteeseen, jossa tiedot tuodaan lähtöjärjestelmistä tietoaltaalle ja pääosin jätetään sinne. Minimoidaan siis latausajoja, jotka vievät aikaa, ovat virheherkkiä ja vaativat seurantaa. Poikkeuksen muodostavat mastertiedot, jotka tuodaan kokonaisuudessaan infoaltaalle.
Esityskerrosta, eli collection-tasoa, jota kuvasin edellisessä blogissa, rakennetaan yhdistämällä infoaltaan ja tietoaltaan tietoja. Tässä kohtaa siis nähdään vaivaa, jotta collection-taso olisi mahdollisimman helppokäyttöinen.
Järjestelmä on sikäli joustava ja skaalautuva, että tarvittaessa lisää tietoja voidaan nostaa infoaltaalle. Syy tähän voi olla esim. suorituskyky.
Tietojen siirtojen vähentäminen
Nykyaikaisessa data lakehouse -ajattelussa datat tuodaan sellaisenaan tietoaltaalle, siis samassa muodossa kuin ne ovat lähtöjärjestelmissä. Joskus tiedot ovat selkeässä muodossa, tällöin siis lähtöjärjestelmän tietokanta on ollut hyvin suunniteltu, toisinaan taas hyvin vaikeasti ymmärrettävässä muodossa.
Uudessa arkkitehtuurissa tietoaltaalle tuotuja tietoja pyritään käyttämään sellaisenaan osana kokonaisuutta. Jos tietojen hyväksikäyttö edellyttää jalostusta, tuodaan infoaltaalle mallinnettua, tarkempaa tietoa.
Iso päänsärky – lähtöjärjestelmien tietorakenteet
Jos on se tilanne, että lähtöjärjestelmien tietorakenteet ja datasisältö ovat vaikeaselkoista, ollaan ongelmissa. Analyytikot tuskailevat, kun heidän pitää yrittää selvittää ja mallintaa, mitä dataa tietoaltaalle oikein saatiin. He eivät ole kyseisen tietokannan ja liiketoiminta-alueen asiantuntijoita ja oikeita asiantuntijoita voi olla vaikea saada kiinni. Aikaa kuluu ja tulee vääriä tulkintoja.
Sitten data on muokattava analyyseihin ja raportointiin sopivaksi, eli on tehtävä tietojen muokkaus- ja latausajot. (ETL/ELT). Aikaa kuluu, aikataulut uhkaavat ylittyä eikä itse analyysityöhon vielä päästä.
Kaksi menetelmää asian korjaamiseksi
Tee ensin käsite- ja tietomallinnus ihanteellisesta rakenteesta, eli rakenteesta, josta parhaiten saa liiketoiminnan tarvitsemat tiedot. Sitten tilaa lähtöjärjestelmien toimittajilta tiedostot, joihin tiedot on muokattu valmiiksi juuri tuon tietomallin mukaiksi.
Näin vaikeaselkoisen datan jalostustyö meille sopivaksi ulkoistetaan juuri sille taholle, joka sen parhaiten osaa tehdä. Tämä tietysti maksaa, mutta ajan ja oman työn säästö on merkittävä. Päästään todella nopeasti itse analyysi- ja raporttityöhön, kun selvitys- ja muokkaustyö vähenee.
Järjestelmien toimittajia ei yleensä kiinnosta se, että asiakkaat vievät heidän sovellustensa tietoja tietovarastoon. Nyt, toimittajien kautta tehtävien sopimusten myötä, heidät sitoutetaan jalostamaan tietoja meille sopivaksi.
On tilanteita, joissa edellä kuvattu menetelmä ei ole mahdollinen. Toinen menetelmä on käyttää tekoälyä päättelemään datan sisällöstä mitä se voisi sisältää. Tällaisia ominaisuuksia alkaa olla joissakin mallinnustyökaluissa. Ne laativat automaattisesti käsite- ja tietomalleja tulkitsemalla tietoaltaalle ladattuja lähdejärjestelmien tietoja tai jopa lukemalla suoraan lähdejärjestelmän rakenteista.
Miten edetä olemassa olevan tietovaraston kanssa
Yhä yleisempää on tilanne, jossa nykyinen tietovarasto alkaa olla elinkaarensa päässä, ehkä tekniikkansa puolesta tai muista syistä.
Edellä kuvattua arkkitehtuuria voidaan soveltaa tähän tilanteeseen alkamalla rakentaa rinnalle uutta tietovarastoa saumattomasti. Kannattaa valita moderni, mielellään pilvipohjainen ja skaalautuva alusta sekä data lakehouse -teknologia.
Tässä ratkaisussa nykyinen tietovarasto voi toimia aluksi ikään kuin tietoaltaana. Infoaltaaseen viedään integraatiopisteitä, eli mastertiedot, sekä vähitellen sopimusdataa, kuten yllä kuvattiin. Näiden relaatiot viittaavat takaisin päin nykyiseen tietovarastoon, jota siis edelleen käytetään tietolähteenä.
Etuna on, että nykyiseen tietovarastoon ei tarvitse koskea, koska sieltäpäin ei ole viittauksia uuteen tietovarastoon. Viittaukset ovat toisin päin. Uusi tietovarasto on ainakin aluksi suhteellisen kevyt, kun siellä on vain masterdataa ja sopimusdatasta avaimet ja relaatiot vanhaan tietovarastoon päin.
Jos tulee uusia operatiivisia järjestelmiä tietolähteiksi tai olemassa olevia järjestelmiä vaihtuu, niiden tietoja voidaan ruveta tuomaan suoraan integroitavaksi infoaltaalle, entisten rinnalle saumattomasti.
Vähitellen aletaan siirtää vanhan tietovaraston latauksia uuden tietovaraston tietoaltaalle. Ratkaisu ei siis edellytä suurta revoluutiota vaan tapahtuu evoluutiona ja siirtymänä. Suurella vaivalla rakennettua vanhaa tietovarastoa ei noin vain hylätä.
Kokemuksia
Näiden ajatusten taustalla on monia kokemuksia erilaisista tietovarastoratkaisuista.
Erässä konsultointi-casessa yrityksellä oli menossa kaksiosainen tietovarastohanke. Osa lähtöjärjestelmistä tuotiin Data Vault -arkkitehtuurilla ”by-the-book” rakennettuun tietovarastoon. Yrityksessä ei ratkaisusta tiedetty paljoakaan. Siitä tuli laaja, kallis ja monimutkainen. Toimittaja oli hyvissä asemissa.
Toinen osa tietovarastohankkeesta toteutettiin niin, että yrityksen oma asiantuntija latasi parin operatiivisen järjestelmän tietokannat tietoaltaalle. Niiden tietokannat olivat varsin hyvin suunniteltuja ja selkeitä. Asiantuntija pystyi varsin nopeasti rakentamaan joukon Power BI -raportteja. Käyttäjät olivat tyytyväisiä, ja kustannukset pienet. Osaaminen jäi omaan taloon.
Nuo kaksi ratkaisua ovat ikäänkuin ääripäitä. Kuvaamani arkkitehtuuri tarjoaa parhaat edut kummastakin ratkaisusta. Infoallas toimii integraattorina ja pääosa tiedosta voidaan jättää tietoaltaalle.
Ari Hovi
