Ennen vanhaan oli kaikki paremmin. Tai ainakin helpompaa. Vai oliko sittenkään?
Kilpailutin jonkin aikaa sitten uutta data platformia eräälle Suomen suurimmista pörssiyhtiöistä. Toimittajien kiusaksi speksattiin asiakkaan kanssa erilaisia käyttötapauksia monista näkökulmista, mutta kuitenkin jalat tiukasti maassa.
Eräässä vastineessa — kuitenkin aika peruskäyttötapaukseen — ehdotettiin käytettävän 23 eri komponenttia.
Kahtakymmentäkolmea. 😳
Ennen pärjättiin ETL-työkalulla ja relaatiotietokannalla. Siihen päälle Cognoksen Transformer ja Report Studio.
Eikä tästä nyt niin kovin pitkä aika ole. Koulutin pitkään Talentumilla Business Intelligencen tehokas hyödyntäminen -nimistä kurssia, jonka viimeinen toteutus taisi olla vuonna 2015. Kurssimateriaalista löytyi alla oleva kuva, joka vielä tänä päivänäkin on arkea monessa organisaatiossa.
Perusasiat eivät ole kauheasti muuttuneet viidessä vuodessa, mutta OLAP-kuutiot tuntuvat nyt kovin vanhanaikaisilta. Toisaalta edelleenkin dataa kerätään eri puolilta organisaatiota keskitetysti yhteen paikkaan ja muutamien välivaiheiden kautta tarjoillaan liiketoiminnalle hyödynnettäväksi.
Konepellin alla on kuitenkin muuttunut paljon ja teknologia menee huimaa vauhtia eteenpäin.
Nykyään kun seuraa data-arkkitehtuurien kiemuroita, tulee väistämättä mieleen makrotaloustieteen tenttiin valmistuminen vuosien takaa:
Jos ei ole sinut asian ja alan termistön kanssa, niin vaikeaksi menee. Minulle tietojohtamisen opiskelijana makroteoria kuulosti tuolloin yhtä kiinnostavalle ja monimutkaiselle, kuin kansantaloustieteen opiskelijalle tietovaraston sisäinen rakenne blobeineen, hubeineen ja sateliitteineen.
Datastrategia ohjaa data-arkkitehtuurin kehittämistä
Kuten opimme, datastategian myötä syntyy portfolioon iso joukko priorisoituja liiketoiminnan kehitystarpeita, eräänlaisia business case -aihioita tai datatuotteita. Ylätasolla voisi näyttää jotain tällaiselta:
Nämä yksinään tai niputettuna isommaksi kokonaisuudeksi tukevat olemassa olevaa liiketoimintaa ja mahdollistavat myös ihan uudenlaisen liiketoiminnan toteutumisen.
Entäpä data-arkkitehtuuri?
Kun datastrategian myötä kuvatut liiketoiminnan tarpeet käännetään teknisiksi vaatimuksiksi, ollaan data-arkkitehtuurin kehittämisen ytimessä.
Data-arkkitehtuuri ei itsessään kuitenkaan tee vielä mitään — se ei ole mitenkään käsin hypisteltävissä tai suoraan kaupan hyllyltä ostettavissa. Se on ennemminkin kasa erilaisia kuvauksia (konsulttijargonissa artefaktoja), jotka valmistelevat organisaatiota datan hallintaa varten.
Se siis kuvaa, miten kaikki dataan liittyvät eri palaset toimivat sujuvasti yhteen ja tukevat muun muassa datan laadun kehittämistä, datan omistajuutta, dataintegraatioiden toteuttamista ja tietojärjestelmien välistä yhteistoimintaa.
Kun data-arkkitehtuuria kehitetään systemaattisesti, mielestäni lopputuotosten tulisi vastata ainakin seuraaviin kysymyksiin:
- Missä dataa luodaan — kuvataan tietolähteet ja niihin integroituminen
- Miten data liikkuu — kuvataan tietovirrat
- Missä data sijaitsee — kuvataan data platformin sisäinen rakenne
- Mitä datalle tehdään — kuvataan datan määritykset, liiketoimintasäännöt, duplikaattien poistot, muunnokset ym.
- Miten dataa on saatavissa ja kulutetaan — kuvataan datan jakelukanavat organisaation sisällä sekä sen ulkopuolella
Lisäksi on paljon datan hallintaperiaatteisiin (governance) liittyviä asioita, kuten datan omistajuudet ja kehittämisen pelisäännöt, mutta jätän näiden käsittelyn toiseen kertaan.
Näiden kysymysten ja tuotosten avulla syntyy konkreettisena lopputuloksena tarpeet ja vaatimukset data-alustalle (data platform), joka nykypäivänä rakennetaan useimmin julkiseen pilvipalveluun (AWS, Azure, GCP…). Data-alustan käyttötapaukset saadaan puolestaan johdettua datastrategiassa tunnistetuista kehitysaihioista.
Data-alustalla ne 23 eri komponenttia sitten siirtelevät dataa kulloinkin oikeaan paikkaan ja mahdollistavat business casejen toteutumisen.
Data-arkkitehtuurin kehittymisen ajureita
Vielä kymmenkunta vuotta sitten tietovarastoja rakennettiin pitkälti tiettyä käyttötarkoitusta varten ja data-arkkitehtuurin rooli onkin ollut ennen kaikkea tietovarastoinnin kehittämisessä. Haluttiin raportoida myyntiä tuoteryhmittäin, nähdä talouslukuja tileittäin tai kustannuspaikoittain, tarkastella varastosaldoja varastoittain jne. Tarpeet ovat toki edelleen olemassa, mutta ympärillä on paljon muutakin.
Datan määrä kasvaa edelleen
Yksi merkittävä ajuri on tietenkin kasvanut datan määrä.Ei niin kauan sitten haluttiin kerätä kaikki mahdollinen data talteen riippumatta sen tulevaisuuden käyttötarkoituksesta. Ylevä ja kaunis ajatus, mutta johti usein erilaisiin datakaatopaikkoihin ja saastuneisiin datajärviin.
Nykypäivänä organisaatioissa ollaan jonkinlaisessa välimallissa ja entistä enemmän tulevaisuuden datatarpeita kartoitetaan liiketoimintalähtöisesti datastrategioiden avulla. Tämän jälkeen laitetaan kehityspanostukset merkityksellisen datan keräämiseen laadukkaasti.
Kävimme viime syksynä tutustumassa Kiinan piilaaksossa Hangzhoussa erilaisiin AI-startuppeihin, joissa monen liiketoimintamalli oli kerätä ensimmäiset pari vuotta (toivottavasti merkityksellistä) dataa. Tämän jälkeen oli disruptiivisten liiketoimintamallien vuoro.
Tietovarasto ei ole enää kingi data-arkkitehtuurissa
Siinä missä perinteinen tietovarasto oli ennen data-arkkitehtuurin kingi, sen rooli pienenee jatkuvasti. Tarkennettakoon, että tietovarastolla on edelleen ja tulevaisuudessakin keskeinen sekä tärkeä rooli osana data-arkkitehtuuria, mutta ympärille on tullut ne parikymmentä muutakin komponenttia ja käyttötarkoitusta.
Tähän on paljon syitä, joista yksi on luonnollisesti datan monimuotoisuus.
- On IoT-tyyppistä dataa, jota saattaa tulla satojatuhansia eventtejä sekunnissa eri laitteilta ympäri maailmaa 24/7. Tämä pitää hillota talteen ja olla kyvykkyydet esimerkiksi ennustaa suhteellisen reaaliajassa laiteiston vikaantumista. Samalla pitää huolehtia, etteivät varastoinnin ja käsittelyn kustannukset karkaa ihan käsistä
- Perinteisesti markkinointi on puuhastellut data-asioita omassa siilossaan. Nykyään halutaan tietää yhä enemmän ja enemmän esimerkiksi asiakkaan käyttäytymisestä, mikä johtaa erityyppisen martech-datan keräämiseen vaikkapa sisällönhallinnan, verkkokaupan, markkinoinnin automaation lähteistä tai esimerkiksi verkkosivujen klikkaustietojen tapahtumista. Yllättävää kyllä, tämäkään ei ihan peruskauraa perinteisessä tietovarastointiympäristössä ole ja tätäkin dataa (esim. JSON-muotoisena) tulee paljon
- On tarve tallentaa kuvia ja videoita, jotta voidaan rakentaa koneoppimismalleja vaikkapa erilaisten sairauksien tunnistamiseksi datasta. Näissä tapauksissa datamäärät ovat helposti teratavuja vuorokaudessa
Näitä ei enää säilötäkään siihen perinteiseen relaatiotietokannassa olevaan Kimballin oppien mukaan mallinnettuun dimensionaaliseen tietovarastoon (relaatiotietokantaan). On syntynyt uudenlaisia tiedon tallennuspaikkoja ja tietorakenteita.
Datalla on enemmän hyödyntäjiä
Perinteisen kolmen V:n (volume, velocity and variety) lisäksi paljon muutakin on muuttunut.
Vanhalla työnantajallani V:t muuten suomennettiin P:ksi (paljon, pikainen ja polymorfinen). Neljäskin P oli, joka viittasi datan laatuun.
Eräs keskeinen asia on data-alustan rooli. Kun ennen tuotettiin määrämuotoista dataa lähinnä sisäisiin raportoinnin tarpeisiin, nykyään datan hyödyntäjiä on paljon muitakin:
- Data-alusta saattaa toimia lähteenä digitaalisille verkko- ja mobiilipalveluille, jolloin vanhan kunnon ETL-välineen tapa käsitellä dataa eräajotyyppisesti ei vain enää toimi. Data pitää saada virtaamaan jo taustajärjestelmistä lähes reaaliajassa
- Data tulee saada kumppaneiden ja muiden sidosryhmien käytettäväksi modernien rajapintojen kautta
- Hyödyntäjä voi olla myös toinen liiketoimintasovellus, jolloin data pitää saada liikkumaan reaaliajassa paikasta toiseen — vaikkapa CRM:stä markkinoinnin automaatiojärjestelmälle
- Tai halutaan julkaista koneoppimismalli kontitettuna API-palveluna, jolloin voidaan kysellä sen kautta vaikkapa asiakaspoistumia
Pilven merkitystä ei voi väheksyä
Pilviympäristöt toimivat modernien datastrategioiden sekä data-arkkitehtuurien mahdollistajana ja niillä on ollut iso merkitys esimerkiksi tekoälyalgoritmien suorituskyvyn ja ennustetarkkuuden parantumisen taustalla.
Laskenta- sekä tallennuskapasiteettia voi ostaa ja skaalata aina kulloisen tarpeen mukaisesti (toki luottokortin limittien sallimissa rajoissa). Joskin — omien kokemusten mukaan — yleensä enemmän ylöspäin, sillä aika harva organisaatio esimerkiksi ajaa palveluita yöksi alas, jos ne eivät ole käytössä.
Pilvipalveluissa on toki omat haasteensa. Ne tarvitsevat uudenlaista osaamista, mitä tyypillisesti ei kauheasti oman talon sisältä löydy. Lisäksi ei ole olemassa yhtä oikeaa tapaa tehdä asioita, vaan pilviekosysteemien sisällä voi olla useitakin samankaltaisia komponentteja, joista pitää valita sopivimmat. Ja mielellään vielä sellaiset, jotka löytyvät ekosysteemistä vielä ylihuomennakin.
Eri arkkitehtuuriporukoiden rajat hämärtyvät
Nykyään tietovarastoarkkitehdit ja sovellusarkkitehdit tekevät entistä tiiviimpää yhteistyötä datan ympärillä. Sekä datan käsittely, mutta myös sovellusten rakentaminen on muuttunut vauhdilla molemmissa koulukunnissa.
Tällä hetkellä näkyy aika paljon näkemyseroa siitä, pitäisikö dataputket toteuttaa perinteisin ETL-työkaluin eräajoilla, tapahtumapohjaisesti (esimerkiksi Kafkan avulla) tai EAI-työkaluilla. Ainakin toistaiseksi kaikkia tarvitaan ja tämä on myös yksi syy, minkä takia data-alustat ovat tällä hetkellä niin monimutkaisia.
Perinteinen tietovarastokoulukunta
Perinteinen tietovarastointikoulukunta on keskitettyjen EDW-tyyppisten tietovarastojen kannalla, joka mallinnetaan Data Vaultilla ja rakennetaan tietovarastoautomaatiota (esim. WhereScape) käyttäen.
Datat ladataan data lake -kerroksen kautta tietovarastokerrokseen (Redshift, Synapse, Snowflake…) ja tarjoillaan perinteisemmän dimensionaalisen tietomallin kautta raportoitavaksi tai enemmän denormalisoituna (=leveeeeiiitttäää tauluja, 1 rivi per asiakas ja 100 attribuuttia sarakkeilla) vaikkapa analyytikoiden hyödynnettäväksi.
Tapahtumapohjainen integraatiokoulukunta
Eräajopohjaisten integraatioiden toteuttamisen sijaan visioidaan myös kaiken datan virtauttamisesta reaaliajassa paikasta toiseen. Ideana on, että ei haetakaan säännöllisin väliajoin jotain datajoukkoa, vaan odotellaan, että lähde(järjestelmä) lähettää tietoa tilaamistamme tapahtumista — esimerkiksi kun tulee uusi liidi CRM-järjestelmään. Tämä tieto saadaan sitten vietyä kerralla useaan eri paikkaan.
Tässä koulukunnassa on monoliittisten tietovarastojen sijaan suuntana hajautetut mikrotietovarastot, streaming-tyyppiset alustat ja Open Source -palikat (Kafka, Airflow, Amundsen…).
Hieno ajatus kyllä, jos vaikka Debeziumin tapaisella CDC-työkalulla saataisiin peilattua vanhojen keskuskoneopohjaisten järjestelmien datoja (ja muutoksia datoissa) lähes reaaliajassa Kafka-jonoon ja siitä eteenpäin mobiilipalveluihin tai perinteiseen tietovarastoon. Nythän ne usein ladataan esimerkiksi backup-tiedostoista kerran yössä.
Tämän haittapuoli (vielä) nykypäivänä on rakentamiskustannukset ja tekninen monimutkaisuus sekä yleisesti kokonaisuuden hallittavuus, kun kehittäminen on käytännössä käsin Pythonilla/Scalalla tms. skriptaamista ja työkalut eivät ole erityisen kehittyneitä (vaikka saa niitä toki PaaS-palveluinakin Confluentin, Azuren Events Hubin tai AWS:n Kinesiksen muodossa).
Millainen on data-alusta vuonna 2020?
Veikkaanpa, että aika montaa lukijaa kiinnostaa, miltä se blogin alkupään raportointi- ja tietovarastointiarkkitehtuurikuva näyttää päivitettynä 2020-luvulle. Osin lukemisen helpottamiseksi (ja pääosin omaa laiskuttani peitellääkseni) jaoin sen omaan kirjoitukseensa, jonka julkaisen lähiaikoina.
Alussa mainitsemani asiakas muuten päätyi lopulta valitsemaan AWS:n ja nuo 23 eri komponenttia. Pienistä alkukankeuksista huolimatta ihan hyvin menee kuulemma nykyään.
Lähteitä ja lisälukemista:
- Enterprise Data Architecture
- Future of Data Engineering
- How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh
- Building and Scaling Data Lineage at Netflix to Improve Data Infrastructure Reliability, and Efficiency
- The Changing Face of ETL
- Event-pohjaiset integraatiot
- The Log: What every software engineer should know about real-time data’s unifying abstraction
