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.
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.
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...
Organisatorisen datan ja raportoinnin salaisuudet Mistä tämä data oikein tulee?
Tuomo Riihentupa työskentelee Lead Architectina Cloud1:lla. Hän vastaa osasta Cloud1:n merkittävimpiä asiakkuuksia. Tuomon taustasta löytyy kokemusta toimimisesta sekä konsulttina että loppuasiakkaana. Nykyiseen työhönsä hän haluaakin tuoda mukanaan vahvaa ymmärrystä asiakkaan tarpeista ja arjen haasteista. Datasta kaikki irti on ollut Cloud1:n statement jo useita vuosia. Tuomo allekirjoittaa edelleen ydinajatuksen, jonka kenties jo hieman käytettykin lausahdus pitää sisällään. Samalla Tuomo avaa tuota...
DataOps ottaa kantaa, DevOpsilta lainattujen asioiden lisäksi, myös projektinhallintamalliin, sekä esittää uuden tavan nähdä tietojärjestelmät tuotantolinjaston kaltaisena perinteisen ohjelmistotuoteajattelun sijaan. Vaikka DevOpsin opit ovat itsessään tärkeitä, ei se ole silti saanut samaa pitoa datapuolella, kuin ohjelmistokehityksessä. Syynä tähän nähdäkseni on se, että dataprojektit eivät noudata täsmälleen samoja lainalaisuuksia kuin perinteinen ohjelmistokehitys. Näin ollen DevOpsin opit eivät suoraan...
Aikaisemmissa blogipostauksissa esiteltiin Databricksin arkkitehtuuria, kehitystä, tehokkuutta ja kustannuksia sekä visualisointien avustamaa analysointia. Tässä blogisarjan viimeisessä osassa esittelen mielestäni tärkeimmät huomiot toteutuksesta teknisellä tasolla. Pyrin ennen kaikkea nostamaan esille ne hankalammin Googlella löydettävät yksityiskohdat, jotka mahdollistavat sarjassa esitellyn arkkitehtuurillisen toteutuksen.
Edellisissä osissa on käyty läpi miten data saadaan käyttöön ja hyödynnettävään muotoon. Jäljellä on vielä tiedon analysointi johon tässä osassa syvennytään.
Edellisissä osissa käytiin läpi arkkitehtuuri sekä kokemukset kehityksestä. Tässä osassa käyn läpi miten laskennan hajautus käytännössä vaikuttaa ajoaikoihin ja miten tämä vaikuttaa tuotantoratkaisun kustannusten arvioimiseen.
Edellisessä Databricksiä käsittelevässä blogipostauksessa kerroin millainen kokonaisarkkitehtuuri tarvitaan big data AdHoc-analytiikkaan. Hajautetun laskentamoottorin virkaa toimitti tässä esimerkissä Databricks. Tässä osassa käyn läpi millaisen kehitysponnistuksen tiedon valmisteleminen vaatii.
