22.6.2017Blogi

Modernin tietovarastoinnin onnistumisen teesit

Monet suunnittelevat parhaillaan tietovaraston seuraavan sukupolven rakentamista, joko pilvipalveluiden tai perinteisten on-premise teknologioiden päälle. Tässä kirjoituksessa kerron käytännön työssä havaittuja konkreettisia vinkkejä onnistuneeseen uuden tietovaraston kehitykseen.

Moderni tietovarasto, data lake, data-alusta ja data hub. Puheissa pyörii eri nimiä samankaltaiselle tietojärjestelmälle, jonka ideana on kerätä tietoa laajasti eri lähteistä yhteen paikkaan harmonisoitavaksi, tallennettavaksi ja edelleen jaettavaksi. Käyttökohteena voivat olla esimerkiksi edistynyt analytiikka, perinteinen raportointi tai integraatiot.

Uudet pilviteknologiat mahdollistavat erityisesti lisää joustavuutta tekemiseen ja maltillisemmilla kustannuksilla valtavien tietomassojen tallentamisen ja käsittelemisen. Olemme Solitalla huomanneet, että uusien teknologioiden päälle tehtyjen tietovarastojen haasteet ovat kuitenkin samankaltaisia perinteisten tietovarastojen kanssa. Tietovarastointia on tehty jo vuosikymmeniä ja sen piirissä on muodostunut paljon hyviä käytäntöjä.

1: Tarkoituksenmukainen hallintamalli

Vähän iäkkäämmän tietovaraston yleinen kipukynnys on dokumentaatio. Tietovaraston ympärille kertyy oma datan ja integraatioiden ekosysteeminsä, joka ei ilman säntillistä dokumentointia pysy hyppysissä.

Viimeistään avainhenkilöiden vaihtuminen varmistaa, että elinkaaren aikana tehdyt suunnittelupäätökset unohtuvat, jos niitä ei ole kirjattu ylös.

Tietovarastosta voi olla monen kymmenen sivun Word-dokumentti, jonka toteutusprojekti on aikoinaan tehnyt ja jota ei ole hetkeen päivitetty. Luottamus dokumentaatioon on heikko ja sitä ei uskalleta käyttää, joten asioita joudutaan selvittämään suoraan sovelluksien koodia tulkkaamalla. Tämä on hidasta ja työlästä.

Uutta tietovarastoa rakennettaessa kannattaa tekemiseen ottaa ryhtiliike niin, että jo alusta lähtien kirjataan ylös sovittuja ja päätettyjä asioita.

  1. Kaikkeen tietoon liitetään mukaan riittävä metadata sovitun mukaisella tasolla. Esimeriksi jokaiseen luotuun tietokantatauluun kirjataan kommentit suoraan taulun ja kenttien kylkeen. Tietokantojen ulkopuolella, esimerkiksi AWS S3:ssa tai Azure Blob Storagessa, pidetään huoli, että nekin tulevat kuvatuksi. Kuvaustietojen ollessa kunnossa muodostuu näistä pienellä vaivalla datakatalogi, jota voidaan käyttää viestittäessä ratkaisun käyttömahdollisuuksista.
  2. Sisään- ja ulospäinmenevät tietovirrat kuvataan sopivan korkealla tasolla toteutuksen yhteydessä ja päivitetään tarpeen mukaan. Tästä tiedosta voidaan milloin tahansa tarkistaa riippuvuudet eri järjestelmiin ja saadaan yleiskuva tietovaraston asemoinnista muihin järjestelmiin nähden. Tietovirtakuvauksissa tulee keskittyä kokonaiskuvan luomiseen ja jättää usein muuttuvat yksityiskohdat kuten taulu- ja kenttätason määritykset ja ajastustiedot tarkemman teknisen metatiedon huoleksi.
  3. Muodostetaan vuosikelloajattelu joka tarkoittaa, että tehtyä dokumentaatiota katselmoidaan riittävän usein, esimerkiksi kvartaaleittain. Tässä yhteydessä katselmoidaan myös muita tärkeitä asioita – esimerkiksi tietokantakäyttäjät – ja korjataan ripeästi havaitut puutteet.

Hallintamalli ei saa olla liian raskas, jottei organisaatio uuvu sen alle. Toisaalta sen on tarjottava sellainen selkänoja, että dataan liittyvät uudetkin vaatimukset pystytään sen perusteella tekemään. Tästä oivana esimerkkinä on uusi EU-tietosuoja-asetus. Mikäli dokumentaatio on riittävällä tasolla, on varsin nopeaa selvittää, missä kohtaa ratkaisua käsitellään ja tallennetaan henkilötietoja.

2: Laadukkaat tuotantokelpoiset tietovirrat

Tietovaraston tietovirtojen vianselvitys ja -korjaus on tuntuva osa normaalia ylläpitoa, koska lähdejärjestelmissä tapahtuvat muutokset ja katkokset heijastuvat helposti tietovarastoon. Modernin data-alustan osalta haasteet pysyvät ennallaan ja voivat jopa lisääntyä: konesalissa vierekkäin olevien palvelinten sijaan jatkossa data voi muodostua toisessa pilvessä ja siirtyä julkiverkon yli toiseen pilveen välissä ollen monta vikaantuvaa osaa.

Perinteisesti tietovirtojen automaattiseen toipumiseen ei ole kiinnitetty kovinkaan paljon huomiota: työkalujen kyvykkyys on ollut tähän rajallista sekä valitut toteutusmallit ovat saattaneet pakottaa tekemään käsityötä esimerkiksi ennen tietovirtojen uudelleen käynnistämistä.

Uuden alustan toteutuksessa on tähän syytä ottaa ryhtiliike, eikä hyväksyä, että pienikin hikka keskeyttää tietovirrat.

Modernit toteutukset osaavat toipua monenmoisista vikatilanteista itsekseen ja ylläpitäjän tehtäväksi voi siltä osin jäädä triviaalien vikojen seuraaminen ja vakavien vikojen tarpeenmukainen hoitaminen. Toisaalta mekanismien pitää tietää, milloin nostaa robottikädet ylös ja antaa ihmisen päättää onko eteneminen suotavaa: datan korruptoituminen liian pitkälle viedyn automatiikan takia ei ole hyväksyttävää.

3: Riittävä tietomallinnus

Tiedon siirryttyä pilveen raakakerrokselle on suorastaan houkuttelevaa ladata raakadatat sellaisenaan relaatiotietokantaan ja lukea datat suoraan analytiikkatyökaluun. Tässä on riskinsä.

Erityisesti dimensiotyyppiseen tietoon (asiakas, sopimus, jne.) liittyy paljon liiketoimintasääntöjä, jotka on toteutettu perinteiseen tietovarastoon. CRM-järjestelmässä voi olla hyvin erilainen näkemys asiakkaasta kuin mitä analytiikkakerroksessa halutaan käyttää ja esimerkiksi yhden ja saman asiakkaan tiedot voivat olla hajautuneena moneen CRM-järjestelmään ja niiden sisällä moneen asiakkuuteen.

Riittävällä tietomallinnuksella pidetään huoli, että nämä tulkinnat tehdään kerralla kuntoon, jonka jälkeen analytiikkatyökaluilla on käytettävissään samat liiketoimintasäännöt.

Mikäli päättelyitä toteutetaan tarveperustaisesti eri analytiikkasovelluksiin pitää sääntöjen muuttuessa käydä tekemässä muutokset jokaiseen sovellukseen erikseen. Toisaalta ratkaisun on mahdollistettava protoilu- ja kokeilukulttuuri, missä raakadatan lataaminen numeronmurskaukseen on kokeilumielessä sallittua. Protovaiheen jälkeen sovellus tuotannollistetaan ja käännetään lukemaan yhteisiä tietomalleja.

Koska käytettävä data luodaan muissa järjestelmissä, on data-alusta täysin muun IT-arkkitehtuurin muutosten armoilla. Mikäli jokin järjestelmä päätetään vaihtaa toiseen, tarkoittaa se muutoksia myös tietosisältöihin. Riittävän joustava tietomallinnusmenetelmä kuten Data Vault mahdollistaa IT-järjestelmien muutoksen piilottamisen analytiikka- ja raportointikerrokselta. Tällöin dataintegraatiomuutosten tekeminen kertaalleen riittää ja analytiikkasovellukset eivät välttämättä näe IT-arkkitehtuurissa tehtyjä muutoksia millään tavalla.

Yhteenveto

Pilviteknologiat ovat raikas tuulahdus tietovarastointimaailmaan. Teknisesti modernit ratkaisut eivät kuitenkaan poista tietovarastojen hallinnan tarvetta. Ylläpidossa ja kehityksessä tarvitaan jatkossakin ihmisiä, jotka:

  • tuntevat tietovarastoinnin ja tiedonhallinnan lainalaisuudet
  • toimivat nopeasti, kun tietovaraston toiminta häiriintyy
  • tukevat analytiikkatyötä rautaisella tietosisältöjen tuntemisella
  • kykenevät kehittämään tietovarastoa liiketoimintavaatimusten mukaiseksi analytiikan monitoimityökaluksi
Pekka Haavisto työskentelee Solitalla Agile Data -tiimissä. Hän on IT-alan moniottelija, jonka intohimona on yhdistää perinteisten tietojärjestelmien parissa hankittu teräksenkova ammattitaito moderneihin tiedonhallintamenetelmiin. Pekkaa motivoi mahdollisuus toimia eri tekemisen tasoilla ja hän on yhtä kotonaan automatisoimassa asioita sovelluskehitystyökaluilla kuin suunnittelemassa pitkän aikavälin arkkitehtuuritiekarttoja. Uusien teknologioiden osalta Pekka pyrkii pääsemään nopeasti höttökerroksen läpi käytäntöön ymmärtääkseen uutuuksien tuoman lisäarvon tiedonhallintahaasteiden ratkaisemisessa.