Monilla aloilla, meidän data-alamme mukaan lukien, uusia ideoita, malleja ja ratkaisuja syntyy huimaa tahtia. On motivoivaa toimia alalla, joka kehittyy jatkuvasti ja tarjoaa uusia mahdollisuuksia ja haasteita. Uusien mallien seassa navigoidessa on välillä hyvä pysähtyä palauttamaan mieleen myös perusasioita ja syitä käytettyihin ratkaisuihin. Menneisiin malleihin ei pidä jäädä jumiin, mutta on aivan yhtä tärkeätä muistaa mitä ongelmia pyrittiin ratkaisemaan ja mistä nämä haasteet syntyivät. Teknologian...
Power BI:ssä, kuten aika monissa muissakin analytiikka välineissä, on aina ollut haasteita, kun siirrytään todella suuriin tietomääriin. Kuten nyt vaikkapa miljardin rivin taulun analysointi. Tällaiseen ongelmaan on pyritty yleensä vastaamaan tallentamalla osa tiedoista analytiikka työvälineen muistiin, jota yleensä on rajoitetusti, ja ohjaamalla sitten tarkennettuja kyselyitä tietokantaan. Vielä muutama vuosi takaperin, testaillessani miten Databricks suoriutuisi Power BI:n suorista kyselyistä, jouduin...
Pyrin yleensä kirjoittamaan sellaisten aiheiden ympäriltä, joiden soveltaminen käytäntöön saattaa olla osaksi teknologian usvan peitossa, mutta joiden tavoite on yleensä hyvinkin selkeä, jopa käsin kosketeltava. Data governance, eli siis tiedon hallintamallit ja prosessit, eivät ole lainkaan suoraviivaisia, yksiselitteisiä tai tarkoin rajattuja. Uudet ideologiat monesti vielä vähemmän. Asiat, joissa ihmiset vaikuttavat huomattavasti tekniikkaa enemmän, harvoin ovat. Tämän kertainen aiheeni, Data Mesh, sisältää...
Väitän, että monessa yrityksessä tiedon hallinta ei ole osa jokapäiväistä tekemistä, eli tiedon omistajuutta, eikä laadun tarkkailuprosesseja ole selkeästi määritelty. Asiaa sekoittaa uusien lähteiden monimuotoisuus. Kaikella tiedolla ei enää ole vastaavaa teknistä määritelmää siitä, milloin se olisi oikein. Tällaisesta hyvä esimerkki on ulkoiset lähteet, kuten sosiaalinen media, jossa tiedon oikeellisuutta mitataan pikemminkin sen merkityksellisyytenä haluttuihin käyttötapauksiin kuin teknisillä raja-arvoilla.
Tiedon laadusta puhuttaessa on perinteisesti pääsääntöisesti keskitytty ihmisen tuottamien virheellisten arvojen havaitsemiseen. Virheitä voi syntyä puhtaan huolimattomuuden takia, kuten vaikkapa väärän arvon syöttämisestä. Tai ne voivat olla prosessipohjaisia, eli vaikkapa tilauksen sulkeminen ennen toimituksen tapahtumista. Tai teknisen järjestelmän kiertämistä, kuten vapaatekstikenttien määrämuotoinen käyttö, eli käyttötapaus, jossa selitekenttää käytetään tallentamaan tuotenumero.
Kuten blogisarjan edellisistä osista kävi ilmi, tiedon laatu on monitahoinen ongelma. Yrityksellä tulisi olla määriteltyjä prosesseja, joilla tiedon laatua pyritään aktiivisesti parantamaan. Näiden tulisi olla osa yrityksen laajempaa datastrategiaa. Mittaamisen tulisikin olla keskeinen osa strategiaa, ja sen toteuttamiseksi Data Platform on arkkitehtuurillisesti luonteva paikka.
Tosiasia on, että huonolaatuinen data maksaa yritykselle huomattavia summia. Tästä esimerkkinä vaikkapa IBM:n tutkimus vuodelta 2018, jossa arvioitiin huonon datan maksavan pelkästään Yhdysvalloissa 3,1 biljoonaa dollaria vuosittain. Se on iso tukku rahaa. Ja vastaavia tutkimuksia on ollut useita.
Tiedon laatu aiheena tuskin herättää kovinkaan monella wow-elämyksiä. Enkä tiedä kuinka pahan inflaation se on kärsinyt viimeisimpien hypetermien myllerryksessä. Tekoälyhän tuli ja sen piti tuoda ratkaisu kaikkeen, eikö vain? Totta puhuen, eihän siinä ihan niin käynyt.
API:t eli ohjelmointirajapinnat ovat tänä päivänä kiinteä osa modernia Data Platformia. Ei pelkästään tiedon lähteenä, vaan myös tiedon jakelukanavana. Rajapintojen etuina ovat keskitetty tietoturva, yhdenmukainen datamalli sekä kehityksen joustavuus ja skaalautuvuus. Ei siis ihme, että meille data-alan ammattilaisille näiden käyttäminen ja rakentaminen on tuttua. API-kehittämisessä, kuten muussakin Data Platform -kehityksessä, ongelmana on usein saada liiketoiminnan kehittäjät innostumaan näistä toiminnalle...
Tuotannon tehostamiseen johtavassa analyysissä käyttäjä havaitsee poikkeaman erään mittalaitteen tiedoissa. Käyttäjä valitsee poikkeaman graafilta, kirjoittaa viestin ja lähettää havainnon eteenpäin raportilta. Tieto merkitään epäluotettavaksi, ja sitä hyödyntävät raportit indikoivat tilanteen käyttäjille. Heräte mahdollisesti epäluotettavasti tiedosta lähetetään tiedosta vastaavalle henkilölle, mukanaan informaatio siitä, kuka merkinnän on tehnyt ja miksi se on merkattu. Mukana kulkee myös tarkka tieto siitä...
