Tietovarastoinnin isän Bill Inmonin ja teknologiayhtiö Databricksin tunnetuksi tekemä Data Lakehouse -arkkitehtuuri on viime vuosina lähtenyt yleistymään Suomessakin. Hovilla uskomme tämän kehityksen jatkuvan: Tulevaisuudessa yhä useampi uusi organisaatiotason keskitetty tietoratkaisu rakennetaan Data Lakehouse -termin alle yhdistyvien ajatusten pohjalta.
Data Lakehouse on ennemminkin osa luonnollista jatkumoa tietojen siirtymisessä pilveen kuin jotain täysin uutta ja erilaista. Se ei myöskään aseta tiukkoja raameja tekniselle toteutukselle, vaan lähinnä sisältää ajatuksen tietoaltaan ja tietovaraston välisen eron kaventamisesta ja parhaiden puolien poimimisesta kummastakin.
Taustaa – tyypillinen tietoarkkitehtuuri pilvessä
Tällä hetkellä tyypillinen suuren organisaation tietoarkkitehtuuri pilvessä koostuu tietoaltaasta (data lake) object storagessa, eli pilvialustalla sijaitsevassa tiedostojärjestelmässä, ja tietovarastosta relaatiotietokannassa.
Tietoaltaalla ja tietovarastolla on molemmilla omat käyttötarkoituksensa ja käyttäjäryhmänsä. Tietoallas toimii keskitettynä analyysikäyttöön talletettavan tiedon varastopaikkana, mihin voidaan tallettaa tietoa riippumatta sen rakenteesta ja tiedostomuodosta. Rakenteeseen tarvitsee ottaa kantaa vasta myöhemmin – siinä vaiheessa, kun tietoa halutaan hyödyntää (schema on read).
Tietovarastoon tuotaessa tieto strukturoidaan relaatiomalliin. Tietovarastossa tieto on mallinnettu ja muokattu, niin että se on helppo löytää, yhdistellä ja analysoida (schema on write).
Kuva 1: Tyypillinen tietoarkkitehtuuri pilvessä
Tietoaltaalle raakadataa voidaan tallettaa pienellä kynnyksellä esimerkiksi tutkijoiden ja datatieteilijöiden saataville. Tietoallas palvelee erityisen hyvin tutkivaa datan tonkimista ja kertaluontoisia analyysitarpeita. Tiedon hyödyntäjän täytyy tuntea data hyvin ja pystyä itse taivuttamaan se haluamaansa muotoon. Tiedon laatu saattaa myös olla vaihtelevaa. Tiedon hyödyntämiseksi on tehtävä selvitys ja jalostustyötä.
Tietovarastossa tietoa siivotaan, järjestellään ja pureksitaan käyttäjälle valmiiksi liiketoiminnan logiikkaa mukailevaan ja erilaisia toistuvia analyysitarpeita palvelevaan tietomalliin. Tietomallissa otetaan kantaa siihen, miten eri tiedot liittyvät toisiinsa ja mistä järjestelmästä mikäkin tieto otetaan ensisijaisesti. Sinne talletetaan systemaattisesti erityisen merkityksellisten tietojen historia ja määritellään, miten keskeiset luvut – vaikkapa myynti ja henkilöstömäärä – lasketaan organisaatiotasolla. Kaikki tämä logiikka automatisoidaan keskitettyyn paikkaan niin, ettei sitä tarvitse toistaa jokaiseen käyttötarkoitukseen uudestaan. Automatisoinnin lisäksi tavoitteena on saattaa tieto helppokäyttöiseen muotoon sellaisille käyttäjille, jolla ei ole osaamista raakadatan työstämiseen tai joille ei ole tarkoituksenmukaista käyttää aikaa siihen.
Tietoaltaan tiedot ovat yleisissä tiedostomuodoissa, joita voidaan helposti lukea useimmilla työkaluilla. Näin voidaan käyttää kuhunkin käyttötarkoitukseen sopivinta tai kullekin käyttäjälle tutuinta työkalua eikä olla sidoksissa vaikkapa tiettyyn ohjelmointikieleen. Object storagessa tallennustilan hinta kasvaa lineaarisesti tallennettavan tiedon määrän mukaan ja tallennuskapasiteetti skaalaa portaattomasti.
Tietovaraston tietoa prosessoidaan pääsääntöisesti relaatiokannan omalla prosessointiteholla ja tiedot tallennetaan kunkin teknologian hupun alla piilossa olevaan tallennustilaan, johon pääsee käsiksi vain alustan oman prosessointitehon kautta pääsääntöisesti SQL:ää käyttämällä. Teknologiasta riippuen hinta voi nousta kapasiteetin tarpeen kasvaessa suhteessa korkeammaksi, skaalaaminen ei välttämättä onnistu portaattomasti ja tallennustila ja prosessointiteho eivät välttämättä skaalaudu erikseen. Prosessointitehoa tai tallennuskapasiteettia voidaan myös joutua pitämään varalla, vaikka sitä ei jatkuvasti käytettäisi.
Metatiedon keräämiseen ja dokumentointiin liittyvät käytännöt ovat tietovarastojen osalta vakiintuneemmat, kun taas tietoaltaiden suhteen käytännöissä on enemmän variaatiota. Tietovarastosta on yleensä saatavilla tietomalli, joka toimii karttana sille, mitä tietoa löytyy, mistä sitä löytyy ja miten tiedot liittyvät yhteen. Lisäksi tulisi löytyä kuvaukset tietovirroista, eli siitä, mistä mikäkin tieto on peräisin ja minkä väliportaiden kautta se päätyy loppukäyttäjille ja miten muokattuna.
Data Lakehouse – yksi yhtenäinen tietoarkkitehtuuri
Data Lakehousen perusidea on, että tietoallas ja tietovarasto eivät ole täysin erillisiä, vaan kaikki tieto sijaitsee samalla tietoalustalla object storageen avoimesti tallennettuna. Eri tasoisesti käsitellyille ja eri vaiheisiin putsatuille ja pureskelluille tiedoille on kuitenkin omat alueensa. Strukturoimattomalle tiedolle on oma osastonsa ja strukturoidulle omansa.
Kaikki tieto on avoimesti eri työkalujen saavutettavissa, eikä sitä tarvitse siirtää alustalta toiselle erilaisia hyödyntämistarpeita varten. Pilvipalvelun skaalautuvuus saadaan optimaalisesti käyttöön, kun tallennustila ja prosessointiteho voidaan täysin eriyttää toisistaan, eikä ylimääräistä kapasiteettia tarvitse pitää varalla. Tallennustilasta ja prosessointitehosta maksetaan erikseen ja toteutuneen käytön mukaan.
Hovilla olemme usein törmänneet siihen, että tietoallas- ja tietovarastoihmiset tekevät osittain päällekkäistä työtä ja heillä voi olla kynnystä hyödyntää samaa dataa, vaikka se olisi tarkoituksenmukaista, koska he ovat tottuneet käyttämään eri työkaluja ja toimimaan erilaisissa ympäristöissä. Yhden yhteisen tietoalustan käyttö voi olla keino vähentää turhaa siiloutumista. Esimerkiksi käyttöoikeuksia ei tällöin tarvitse hallita monessa eri paikassa.
Metatiedon keräämistä ja dokumentointia on syytä tarkastella kokonaisuutena koko tiedonhyödyntämisputken läpi. Myös raakadatasta tarvitaan metatietoa ja kuvauksia, jotta se olisi ymmärrettävissä, löydettävissä ja sääntelyn mukaista. Data Lakehouse -ajattelussa painotetaan tätä. Ei riitä, että tiedot vain dumpataan tietoaltaalle. Silloin ne eivät ole hyödynnettävissä.
CASE – iso SOTE-organisaatio
Isossa soteorganisaatiossa tietoalustaa on lähdetty toteuttamaan data lakehouse ja mitalliarkkitehtuurin pohjalta.
Mitalliarkkitehtuurin ajatus on hyvin lähellä tyypillistä nykymallia, mutta kattaa koko tietoputken ilman erillistä tietoallasta ja tietovarastoa. Pronssitasolle tuodaan raakadata organisaation operatiivisista järjestelmistä pitkälti sellaisenaan. Pronssitasolla dataa on myös määrällisesti eniten valmiina tulevaisuuden käyttötarpeisiin ja vain osaa siitä on jalostettu eteenpäin hopea- ja kultatasoille.
Hopeatasolla ja siitä eteenpäin tietoa käsitellään pääsääntöisesti SQL:llä. Mikään ei kuitenkaan estä käsittelemästä sitä myös esimerkiksi Pythonilla eikä yhdistelemästä prosessoinnissa dataa eri tasoilta. Hopeataso on mallinnettu perinteiseen normalisoituun tietomalliin käsitemallin pohjalta. Hopeatason tarkoitus on toimia koko organisaation laajuisena yhteiskäyttöisenä tietopohjana.
Kultatasolta löytyvät palvelulinjakohtaiset ja käyttötarvekohtaiset tietomallit. Esimerkiksi palvelulinjojen omien määrittelyjen mukaan rajatut asiakastiedot ja tähtimallit eri raportointitarpeisiin.
Tämä arkkitehtuuri vaikuttaa palvelevan kyseistä organisaatiota hyvin. Tiedosta on saatu arvoa toiminnan kehittämiseen suhteellisen nopeasti. Samalla on kuitenkin varmistettu arkkitehtuurin joustavuus ja hyvä kokonaiskuva. Tietoalustatoimittajan ja organisaation omien tietoasiantuntijoiden yhteistyö toimii ja uudet tietoasiantuntijat ovat päässeet nopeasti tekemisessä alkuun.
Mirjamaria Petäjäniemi
Konsultti / kouluttaja
