Arkkitehtuurin pohjatyöt kuntoon: ­IoT-datan käsittely ohjelmistokehittäjän näkökulmasta

Datan määrä, mutta myös sen muoto, siirtämisen tavat ja varastointi vaikuttavat valmiin IoT-ratkaisun helppokäyttöisyyteen. Datan käsittelyyn on onneksi tarjolla vaihtoehtoja, jotka säästävät aikaa ja kustannuksia. Edge-laskenta sekä valmiita ominaisuuksia sisältävät time series -tietokannat ovat esimerkkejä niistä.

IoT (Internet of Things) -ratkaisuilla haetaan tehoa ja ennakoitavuutta muun muassa laitekannan ylläpitoon ja tuotannon seurantaan. Datan lopullinen käyttötarkoitus sanelee sen, millainen arkkitehtuuri IoT-ratkaisun perustaksi kannattaa rakentaa. On siis hyvä pitää koko ajan mielessä, miksi dataa kerätään, mitä sen avulla halutaan saavuttaa sekä minkälaisia esitystapoja tai analytiikkaa dataan halutaan kohdistaa.

Kun uuden IoT-ratkaisun tuotekehitys alkaa, ensimmäinen Minimum Viable Product -versio auttaa verifioimaan, että datan lähettäminen, tallentaminen ja hyödyntäminen onnistuu perustasolla. Kiireessä ei aina tunnisteta esimerkiksi sitä, minkälaisista datamääristä tulevaisuudessa puhutaan. Alkumetreistä asti kannattaa kuitenkin tehdä arkkitehtuurin valinnat huolella.

Datan määrän arviointi: miltä näyttää maksimitilanne?

IoT-ratkaisuissa datan kokonaismassaa voi hahmottaa päätelaitteiden määrän ja toisaalta tarvittavan mittaustiheyden perusteella. Kun datan määrän “worst case scenario” on selvillä, voi seuraavaksi pohtia, onko tarpeen huomioida kaikki datapisteet vai voiko kerättyä dataa aggregoida, eli säilyttää kaikkien raaka-arvojen sijaan vain keskiarvoja esimerkiksi viiden minuutin aikajaksoilta.

Myös datan muoto vaikuttaa datan määrään, samoin mahdollisuudet sen pakkaamiseen (ja toisaalta pakatun datan avaamiseen). Jos binäärimuotoinen data halutaan avata helpommin luettavaan, selkokieliseen muotoon tietokantaan, sen vaatima tallennustila kasvaa eksponentiaalisesti. Suurtenkin datamäärien keräämisen voi hyväksyä osaksi käsillä olevaa, tarpeiden sanelemaa IoT-arkkitehtuuria etenkin silloin, jos vanhaa dataa on mahdollista määräajoin poistaa.

Lue lisää: Suunnitteilla uusi IoT-ratkaisu? Varaudu kasvuun, vältä sudenkuopat

Datan tallennusmuoto ja säilytysaika ohjaavat etsimään sopivimmat varastointitavat

Levytila on tänä päivänä melko edullista, mutta jos tietokantoihin säilöö tukuittain dataa, hintakin alkaa kivuta. Ennen kaikkea säilytysratkaisu vaikuttaa siihen, miten helppoa (tai vaikeaa) dataa on myöhemmin analytiikkavaiheessa hyödyntää.

Pilvipohjaiset object storage -ratkaisut toimivat silloin, kun binäärimuotoisen, strukturoimattoman datan säilöminen riittää halutun lopputuloksen saavuttamiseksi. Helppokäyttöisyys painaa kuitenkin vaakakupissa, jos selainkäyttöliittymän loppukäyttäjä haluaa nähdä havainnollisen graafin heti. Ei ole realistista kehottaa käyttäjää odottamaan kahden minuutin ajan, että kuvaaja piirtyy näkyviin.

Jatkuvasti kehittyvät tietoallasratkaisut (data lake), joita esimerkiksi Apache Spark -teknologia edustaa, mahdollistavat suurtenkin datamäärien pitkäaikaisen säilytyksen. Big data -järjestelmiä varten rakennettu tietoallasteknologia nivotaan tiedostojärjestelmän päälle, ja se toimii tietokantana datalle.

Edge-laskenta keventää pilveen lähetettävän datan määrää, REST API vie sen sulavasti eteenpäin

Datan määrään liittyviä ongelmia voi ratkoa reunalaskennan (edge processing) avulla. Sitä hyödynnetään etenkin silloin, kun IoT-järjestelmään kytkettävien laitteiden määrä aletaan laskea tuhansissa. Mittapisteissä kertyvää dataa käsitellään paikallisesti teollisuus-pc:illä ja lähetetään eteenpäin pilveen vasta silloin, kun signaaliarvossa esiintyy poikkeamia normaalista.

REST API:t ovat nopea tapa saada tuo relevantti data hyödynnettävään muotoon. Esimerkiksi näin me hyödynnämme niitä käytännössä:

• Keräämme edge-laskennan tuottaman datan REST API:en kautta pilvipalveluun binääripaketteina tai datapaketteina.
• Kun uusi datapaketti on säilötty pilveen, kuten AWS:n S3 Object Storageen, pystymme luomaan siitä uuden tapahtuman.
• Tapahtuma välitetään kaikille relevanteille kuuntelijoille eli analyyttisille palveluille, joilla on mahdollisuus tehdä jatkoprosessointia datalle.
• Näin voimme hyödyntää levytilatallennusta ilman tietokantoja.
• Analyyttiset palvelut voivat puolestaan päättää, luodaanko kokonaisdatasta elementtejä niiden omaan tietokantaan, vai luodaanko vain notifikaatioita ja tapahtumia (event).

Time series -pohjaiset tietokannat helpottavat datan käsittelyä ja IoT-ratkaisujen tuotekehitystä

Uusimmat, time series -pohjaiset tietokantaratkaisut sisältävät paljon sellaisia valmiita ominaisuuksia, joita kehittäjät ovat aikaisemmin joutuneet tekemään sovellustasolla. Näitä ovat esimerkiksi:

• datan automaattinen aggregoiminen (min-, max-, average-funktiot),
• datan redusoiminen (vanhan datan poistaminen tietyn ajan, kuten yhden kuukauden jälkeen) ja
• datan pakkaaminen.

Kun tietokantafunktioita ei tarvitse enää kirjoittaa manuaalisesti, eikä datapisteitä tarvitse käydä erikseen poistamassa tai pakkaamassa, vähentyy manuaalinen työ ja myös virheiden mahdollisuus. On kaikkien kannalta järkevää, että toistuviin työvaiheisiin on tarjolla valmisratkaisuja.

Minkälaisen datan käsittelyyn time series -tietokanta sopii, mihin ei?

Aikasarjapohjaiset tietokannat soveltuvat nimensä mukaisesti tapauksiin, joissa kerättävät arvot ovat mittausaikaan sidottuja suureita. Datapisteet kirjoitetaan tällöin tietokantaan kerran kuvaamaan mitattavan laitteen tilaa, ja niitä on harvoin tarve muokata jälkikäteen. Time series -tietokantaan tallennetusta datasta on yksinkertaista muodostaa kehityskulkuja kuvaavia graafeja ja analyyttisin keinoin edelleen erilaisia indikaattoreita hälytyksineen. Aikasarjadata ja sen jalostaminen analyyttisen prosessin kautta on hyödyllistä esimerkiksi juuri teollisuuden IoT-ratkaisuissa.

Time series -pohjainen tietokanta ei sovellu datan varastointiin silloin, jos tiettyjä datapisteitä halutaan säilyttää hyvin pitkään ja elementtien tilaa tarvitsee säännöllisesti muuttaa jälkikäteen. Tällainen on tilanne esimerkiksi asiakastietokannassa, jossa vanhoja tietoja päivitetään jatkuvasti. Perinteinen relaatiotietokanta toimii silloin paremmin.

Käytännössä erilaisia tietokantoja on viisasta yhdistellä ja hyödyntää ristiin, jotta ratkaisu palvelee asiakasta parhaiten.