Uutisia ja puheenvuoroja

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ä...

Microsoft's newest offering to Azure's Data Stack is Azure Synapse. This product has just hit public preview, but I am sure most of you have heard about it all ready. We were lucky enough to have the privilege of participating to the private preview and even before that to the development phase of SQL On-demand feature.

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...

DataOps rantautui Gartnerin hype-termistöön vuonna 2018. Sen ympärille on noussut muutama startup ja suuremmat yritykset ovat sovitelleet termiä tuotteisiinsa. DataOps on saanut myös manifestin (koska sehän kuuluu nykyään asiaan), ja aiheesta löytyy myös muutama laajempia ideaa avaavia dokumentteja. Käsitteenä se on kuitenkin hyvin uusi, mutta ideat joista se koostuu on hyödynnetty datakehityksessä jo aikansa.

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.

Ad hoc -raportointi. Itsepalveluanalytiikka. Niistähän on puhuttu jo vuosia. Markkinoilla onkin useita Self-Service BI-tuotteita, kuten Microsoft Power BI (Desktop). Näiden työkalujen käyttöä kuitenkin usein rajoittaa käyttäjän läppärin suorituskyky, ja ne soveltuvat lopulta huonosti tai jopa surkeasti suurten tietomassojen pika-analyyseihin.

Olen välillä yrittänyt herätellä keskustelua kiireen keinotekoisuudesta projekteissa. Tällä tarkoitan tilannetta, joissa projektissa ei ole lainkaan suvantovaiheita kiireellisten ominaisuuksien tuottamiseksi, vaan tekijöillä on jatkuvat kiireelliset määräajat, milloin minkäkin ominaisuuden valmiiksi saattamiseksi. Tällainen voi jatkua kuukausia tai pahimmillaan jopa vuosia. Olen itsekin ollut kehittäjänä tällaisissa projekteissa. Asia, jonka tuona aikana opin oli se, että hyvin harva ominaisuus oli oikeasti...