<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=266259327823226&amp;ev=PageView&amp;noscript=1">

Uutisia ja puheenvuoroja

Lue blogista digitaalisuuden arkkitehtien tuoreimmat uutiset ja näkökulmat.

Kirjoittaja: Marko Oja
Marko Oja
Marko Oja
Data-arkkitehti, joka auttaa asiakasta ymmärtämään tekniikan mahdollisuudet ja muuntaa innovatiiviset ideat teknisiksi ratkaisuiksi. Ketterät kehitysmenetelmät ja kehitystyötä tukevat prosessit ovat lähellä Markon sydäntä.

Edelliset postaukset

Tiedon laadunhallinnan tulisi lähteä analytiikasta

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

Azure Synapse fresh from the oven

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.

DevOpsista DataOpsiin

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

Miksi DataOps ei ole vain yksi hypetermi?

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.

Databricksin hyödyntäminen big data -analytiikassa (5/5) – Tekninen toteutus

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.

Databricksin hyödyntäminen big data -analytiikassa (4/5) – Analysointi

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.

Databricksin hyödyntäminen big data -analytiikassa (3/5) – Tehokkuus ja kustannukset

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.

Databricksin hyödyntäminen big data -analytiikassa (2/5) – Kehitys

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.

Databricksin hyödyntäminen big data -analytiikassa (1/5) – Arkkitehtuuri

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.

Kuuluuko kiire kehitysprojektiin?

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


Asiakkaitamme

Autamme monia yrityksiä eri toimialoilta saamaan datasta kilpailuetua.

Tilaa blogi