Tämä on ensimmäinen blogi kaksiosaisesta sarjasta, jossa esittelen ajatuksia uudistetusta evolutiivisesta tietovarastoarkkitehtuurista. Ensimmäinen blogi käsittää periaatteita sekä infokerrosta (esityskerros). Toinen blogi kuvaa arkkitehtuuria laajemmin.
Useimmillahan on jo jonkinlainen tietovarasto. Miten edetä siitä? Idea on tuulettaa ajatuksia ja hahmottaa millainen olisi modernin teknologian tietovarastoympäristö, joka on mahdollisimman helppokäyttöinen, nopeasti käyttöönotettavissa ja periaatteiltaan selkeä ja ymmärrettävä.
Tähän on tultu
Urani aikana olen ehtinyt käydä läpi monia kehitysvaiheita. 90-luvun alussa olivat Bill Inmonin perustavaa laatua olevat ajatukset ja käsitteet Information Factory, integrointi ja normalisointi. Kimball 90-luvun puolivälissä julkaisi dimensionaalisen suunnittelumenetelmän eli tähtimallisuunnittelun painopisteenä raportoinnin tuki. 2010-luvulla Dan Linstedtin kehittämä Data Vault -arkkitehtuuri alkoi saada suosiota. Nyt on kuumaa aluetta Data Lakehouse – siitä Inmonkin nyt puhuu.
Meillä IT-ammattilaisilla on lähtökohtainen halu kehittää, parantaa ja automatisoida asioita, mukaan lukien myös oma työ. Tämä voi johtaa siihen, että arkkitehtuurista, menetelmistä ja tietorakenteista alkaa tulla niin monimutkaisia, että niiden oppimiskynnys kasvaa ja ymmärtäminen onnistuu vain asioihin syvällisesti vihkiytyneiltä.
Miksi tietovarastoja rakennetaan
Tietovarastoinnin pääidea ei kuitenkaan ole ei ole äsken mainituissa sisäisissä ratkaisuissa. Ideana on tuottaa datasta näkemyksiä ja oivalluksia liiketoiminnalle, päätöksenteon tueksi. Liiketoiminnalle ja analyytikoille tietovaraston pitäisi näyttäytyä helppokäyttöisenä. Sisäisen rakenteen tulee olla omalle IT-väelle ymmärrettävä. Toimituksen pitäisi olla nopeaa.
Käyttäjäryhmiä ovat liiketoimintakäyttäjät ja päättäjät, analyytikot, data scientistit sekä data governance -ihmiset. Kaikki haluaisivat tiedot helppokäyttöisessä muodossa.
Olen konsulttiurani aikana nähnyt useasti monimutkaisia tietovarastoratkaisuja, joita ei ymmärrä kukaan muu kuin toimittaja. Kaikki asiat ovat toimittajan takana. Näin syntyy toimittajalukko.
Infokerros (esityskerros)
Ehkä yleisin esityskerroksen eli infokerroksen rakenne on tähtimalli. Kuten jo mainitsin, Kimball kehitteli sitä jo 90-luvulla, jolloin levytila oli kallista. Ehkä meillä on jo varaa toisenlaiseen, helppokäyttöisempään ratkaisuun.
Tähtimallissa dimensiot voivat olla denormalisoituja (sisältää toisteista tietoa) ja keskellä oleva faktataulu on normalisoitu.
Tyypillisiä dimensioita ovat asiakas, tuote, päivämäärä ja organisaatioyksikkö. Näiden voimassaolo hoidetaan alku- ja loppupäivämäärillä. Tätä tapaa hoitaa historiointi kutsutaan versioinniksi. Kyselyjen kohdistaminen eri ajanhetkille on suhteellisen monimutkaista.
Tähtimallin kyseleminen edellyttää liitosten tekemistä. Historiatietojen hakeminen alku- ja loppupäivien avulla vaatii jo paljon osaamista. Kyselyiden teko ei siis ole helpoimmasta päästä.
Helppokäyttöisin rakenne
Esitän tähtimallille vaihtoehdoksi leveitä, denormalisoituja tauluja, joita kutsun termillä collection. Riveille kootaan kaikki tiettyyn tai joukkoon liiketoimintatarpeita tarvittava tieto valmiiksi jalostettuna. Taulut on esiliitetty, liitoksia ei enää tarvita.
Tällainen leveä taulu eli collection on helpoin mahdollinen kyselyalusta. Historiointi hoidetaan ns. snapshot-menettelyllä. Joka riville tulee tilannekuva jostakin hetkestä, joka voi olla esim. vuosi-kuukausi tai päivämäärä. Rakenne on helppo ymmärtää ja kysellä.
Osaa collectioneista voi ajatella myös siten, että tähtimalli normalisoidaan. Kaikkiin faktariveihin liitetään valmiiksi kaikki dimensiot. Kuulostaa levytilan tuhlaukselta, mutta nykyiset levyhinnat pilvessä ovat edulliset. Kaikkein suurimmille tapahtumamäärille voi edelleen käyttää tähtimallia.
Toteutustapa
Collection-tauluihin perustuva infokerros voidaan toteuttaa kahdella tavalla. Se voidaan toteuttaa fyysisinä tauluina, jotka siis rakennetaan alla olevan integraatiokerroksen avulla. Tällainen toteutus on helppokäyttöisyyden lisäksi myös erittäin nopea kysellä. Haittana on se, että taulut täytyy ylläpitää fyysisillä latausprosesseilla. Levytilan tarve jo mainittiinkin.
Toinen vaihtoehto on rakentaa collection-taulut näkyminä. Lopputulos näyttää samalta, eli leveiltä, valmiiksi liitetyiltä, helppokäyttöisiltä tauluilta. Näkymään kohdistuva kysely kuitenkin toteutuu liitoskyselynä alla oleviin tauluihin. Niinpä kyselynaikainen suorituskyky saattaa hidastua. Etuna on joustavuus (näkymän muuttaminen on nopeaa) ja se, että mitään latausajoja ei tarvita. Myös levytilaa säästyy.
Näiden lisäksi on vielä mahdollisuus rakentaa ns. materialisoituja näkymiä. Ne muistuttavat näkymiä, mutta data ladataan fyysisesti ja järjestelmä tukee niiden tuoreuttamista.
Eri vaihtoehtoja kannattaa kokeilla ja soveltaa eri tilanteisiin.
Collection-tason etuja
Leveät taulut ovat helppokäyttöisiä. Raporttien ja BI-palvelujen rakentaminen collection-tason päälle on nopeaa. On supertärkeää että osa liiketoimintaihmisistä oppii oikeasti itsekin hyvillä välineillä tekemään kyselyjä.
Markkinoilla on jo AI-ohjelmistoja, jotka osaavat muodostaa SQL-lauseita luonnollisesta kielestä. Tiedämme kuitenkin että hankalissa paikoissa ja monimutkaisissa rakenteissa tekoäly hallusinoi. Yksinkertaisilla collection-tauluilla varmistamme, että tekoälyapurit onnistuvat oikeiden SQL-lauseiden muodostamisessa.
Paras tulos saavutetaan kun liiketoimintaihmiset pääsevät omatoimisesti kiinni dataan nopealla aikataululla. Tämän tukemiseksi IT-väen tulee tehdä työtä ja laittaa paukkuja. Oman toiminnan hienosäädöstä ja ”oikeaoppisuudesta” voi ehkä vähän tinkiä.
Yksi etu collection-rakenteissa on, että ne on helppo siirtää Exceliin jatkojalostusta varten. Myös Data Scientistit yleensä haluavat tiettyyn caseen tarvittavat tiedot yhteen tauluun. Niinpä collection-rakenne sopii heillekin.
Tilastoihmiset ovat perinteisesti käyttäneet omia välineitään, esimerkkinä SAS. Näissä ratkaisuissa tilastot usein toteutetaan leveinä tauluina. Heillekin sopii collection-ajattelu.
Metadata ja mallinnus
Colection-tauluja voi tulla paljonkin. Collectionit mallinnetaan tiedonmallinnusohjelman avulla ja kuvataan sinne. Hyvä metadatan hallinta on olennaista. Tässäkin hyviä ratkaisuja löytyy tiedonmallinnusohjelmista, joissa tietoja voi jakaa laajalle käyttäjäryhmälle.
Collectionin luominen
Collectionit synnytetään uuden arkkitehtuurimme integraatiokerroksen avulla. Sieltä saadaan osa tarvittavista tiedoista suoraan ja loput integraatiotason viittausten avulla. Viittaukset voivat olla vanhaan tietovarastoon tai esim. tietoallas-osioon. Palaamme näihin asioihin seuraavassa blogissa.
Tyypillisesti liiketoiminnan tietotarpeilla on kiire. Nopean palvelun saavuttamiseksi kannattaa rakentaa collection-generaattori, joka osaa tuottaa collectionin synnyttävän koodin perustuen sille annettuihin, integraatiokerroksessa oleviin lähtötietoihin. Tällaisen generaattorin luomiseen kannatta hyödyntää tekoälyä.
Kokemuksia uudesta infokerroksesta
Eräässä finanssialan yrityksessä rakennettiin keskitettyä tietovarastoa. Kun ensimmäiset aineistot saatiin sisään tehtiin analyysi tärkeimmistä raportti- ja tietotarpeista. Kävi ilmi, että suurin osa liittyi ns. kokonaisasiakkuuteen. Rakennettiin leveä, aikaleimattu collection-taulu, jossa oli valmiiksi kaikki tarvittavat tiedot tuolle asiakaskokonaisuustasolle, mukaan lukien kaavoilla laskettuja tunnuslukuja. Raportit syntyivät tosi nopeasti.
Eräässä valtion virastossa oli tuotannossa suhteellisen monimutkainen tähtimallirakennelma tiettyjä tilastoja varten. Ulkopuoliselta toimittajalta tilattiin joukko Web-pohjaisia raportteja koko talon sekä ulospäinkin katsottavaksi. Kävi ilmi, että raportit haluttiin summatuilla tasoilla, hieman eri näkökulmista. Rakennettiin muutama summa-tason collection-taulu, joissa oli kaikki valmiina. Toimittaja sai raportit valmiiksi ennätysajassa.
Em. finanssitalosta vielä toinen kokemus. Uusi alue saatiin tietovarastoon. Tuon alueen superkäyttäjien kanssa selvitettiin heidän tietotarpeensa. Näiden pohjalta rakennettiin muutama jalostettu collection-taulu, nopealla aikataululla. Kun rakenne oli helppo, laskentahenkilö liiketoiminnan puolelta teki omatoimisesti kuukaudessa 60 kyselyä ja raporttia. Mikä valtava liiketoimintahyöty!
Pitääkö tietovarasto uusia
Esitän seuraavassa blogissa miten rakentaa tietovarastoa Data Lakehouse -ajatuksella evoluutiona. Ei tarvitse muuttaa eikä hylätä nykyistä tietovarastoa, vaan alkaa rakentaa uutta, kevyttä rakennetta viereen, joka voi vähitellen kasvaa kokonaan uudeksi tietovarastoksi. Tämä sopii erityisen hyvin tilanteeseen, jossa operatiiviset järjestelmät ovat vaihtumassa.
Ari Hovi
