Dataplattform | Historisk utvikling

Definisjonen for hva en dataplattform er har utviklet seg over tid. Kortversjonen: vi begynte med rapportering på toppen av databaser, beveget oss over til 30 år med datavarehus, før data lake og nå data lakehouse har tatt over.

Dataplattformen har en lang historie

1960 til ca 1985: Databasene dukker opp

Hullkort, mainframes og PCer dukket opp gradvis fra 60-tallet frem til 80-tallet. For data og analyse kom den virkelig store revolusjonen da relasjonsdatabasene gjorde sitt inntog på 80-tallet. Disse lot brukerne skrive Structured Query Language (SQL) for å hente data og lage enkle historiske rapporter. Parallelt vokste det frem rapporterings- og analyseprogramvare som Cognos, SPSS og SAS.

Ca 1985 til 2015: Datavarehuset støtter historisk rapportering

Ledere i store virksomheter på 80-tallet visste stort sett ikke hvordan det gikk med salg og bunnlinje før etter regnskapstallene var klare, gjerne først 15 dager inn i neste måned. Lederne spurte IT om ikke de kunne fikse dette: “Vi har jo alle disse dataene i økonomisystemet, i produksjonssystemet og i HR-løsningen. Kunne ikke dere hente disse ut og lagre de et sentralt sted? La oss kalle dette stedet et datavarehus” (det sa nok lederne strengt tatt ikke, det var det Bill Inmon som sa).

“OK”, sa IT, og kjøpte inn servere, programvare for integrasjon, lagring og visualisering. IT jobbet hardt med å få ut dataene fra kildesystemene. Controllerne og lederne laget dashboards med fine grafer, der de kunne bryte ned tallene per produkt, region, uke etc. Dermed så lederne hvordan det hadde gått med salg og bunnlinje, og virksomhetene fikk bedre kontroll.

Etter hvert vokste det frem nye roller som informasjonsarkitekter, ETL-utviklere, Business Intelligence-utviklere og databaseadministratorer. Kimball og Inmon kranglet seg imellom om hvordan dataene best burde struktureres, og faget modnet raskt.

En milliardindustri var født. Det var enn så lenge halvgode verktøy for rapportering, lagring og dataintegrasjon, men vi var på vei. Brukerterskelen var noe høy. De store aktørene som IBM, Oracle, SAP og Microsoft hev seg på der vi først bare hadde mindre selskap.

Ca 2012-2018: Data laken håndterer stordata for å understøtte analyse

Rundt 2012 begynte mange å slite med begrensningene til datavarehuset og så etter alternativer. Virksomhetene hadde stadig mer data som de ønsket å analysere, og i tillegg fikk de i stadig større grad weblogger, video og lyd som de ønsket å få lagret og analysert. Men datavarehuset hadde ikke plass, og i tillegg var det ganske dyre servere der nede i kjelleren. De både kostet mye og var vanskelige å skalere opp eller ned etter endringer i behovene.

Data laken (eller datasjøen om du vil) kom dermed til verden. Data lake-teknologien hadde utspring i Yahoo, Google og de andre nye teknologiselskapene tidlig på 2000-tallet. Disse selskapene skapte masse data hvert sekund de måtte håndtere. Det skjedde mye teknologiutvikling innad i de store datadrevne selskapene som Google og Amazon, og de store tech-selskapene som Oracle, SAP, IBM og Microsoft kjøpte seg også inn i dette voksende markedet.

McKinsey bidro til å skape en hype rundt stordata i 2011 med en rapport som gjorde at data ble snakket om i styrerommene: “Big data – the next frontier for innovation, competition, and productivity”. Den største hypen kom i 2012, med en artikkel i Harvard Business Review som het “Data scientists - the sexiest job of the 21st century”.

Vi fikk nye roller, som Chief Data Officer og Data Scientist. Det var stort fokus på å bruke maskinlæring til å løse alle mulige problemer, men forretningsanalyse kom også frem i rampelyset. Det hjalp at brukerterskelen hadde gått ned i rapporteringsverktøy som Qlik, Tableau og Power BI. Og ikke minst, vi fikk større fleksibilitet og skalerbarhet gjennom skybasert infrastruktur og tjenester.

Med alle disse mulighetene ønsket ikke virksomhetene å lenger nøye seg med å se på tallene fra i går, selv i fine grafer. Analytikere, ledere og fagspesialister var alle enige: “Vi vil se hva som kommer til å skje, og ikke minst forutse hvilke kunder som kan forlate oss. Dessuten, hadde det ikke også vært fint å unngått kvalitetsvariasjonene vi hadde i produksjonen?”. Maskinlæring og AI trengte data og prosessering for for å kunne understøtte behovene.

Men datavarehuset greide ikke å levere godt på slike brukerhistorier, det ble for mye data og ikke minst for lite fleksibilitet. Derimot var data laken med sin arkitektur, velegnet for å lagre store mengder data billig. “Vi dumper alle dataene her”, tenkte IT. “Og med Spark fikk har vi dessuten muligheten for å skalere prosesseringen av store datamengder”, tenkte de.

Det mange innså etter å ha dyttet inn mye data inn i data laken var at data uten beskrivelser og praktisk anvendelse ga liten nytte. Det ble i perioden brukt unødige ressurser på data laker med data som ingen trengte, og på proof-of-concepts hvor maskinlæring ble brukt på problemer som nok burde vært løst med andre og kanskje enklere metoder. Det ble derfor noe mindre fokus på etablering av nye data laker etter den største hypen endte rundt 2017-2018.

Som et resultat flyttet IT etter hvert de viktigste dataene tilbake til datavarehuset hvor de hadde rutiner og verktøy for å ha kontroll. Mange virksomheter endte dermed opp med å ha både et (eller flere) datavarehus og en data lake, med til dels overlappende data og formål.

Samtidig så vi at selskap som Spotify og Netflix baserte hele sin suksess på smart bruk av data. The Economist skrev i 2017: “The world’s most valuable resource is no longer oil, but data”. Selv om stordata som begrep døde hen fortsatte de fleste virksomhetene å styrke seg på bruken av data.

Ca 2018: Data lakehouse-begrepet brer om seg

Siden behandling av data etter hvert hadde blitt svært viktig for mange virksomheter og kommet på agendaen i styrerommene fikk datafaget en oppdatering. Universitetene tok utviklingen på alvor (noe sent), og startet spesialiserte studieretninger innen datafaget.

Vi begynte å jobbe smidig og snakket om dataprodukter. Der vi i programmeringsverdenen lenge hadde snakket om DevOps, fikk vi dette oversatt til dataverdenen som DataOps.

Gjennom artikkelen “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh” av Zhamak Dehghani ble det i 2017 snakket enda mer om hvordan vi ønsket å organisere oss for å få mest mulig verdi fra dataene. Det var sunt, og vi snakker om dette fortsatt. Prinsippene Dehghani foreslo var ikke helt nye - hun lånte mye fra utvikling av programvare.

Innen arkitektur fikk vi nok et begrep. Data lakehouse er et arkitekturmønster som ble introdusert av Databricks i 2018-2019. I deres definisjon søker de å prosessere data der de er, og fjerne skillet mellom hvor dataene til datavarehuset og data laken ligger. Vi har med andre ord fusjonert datavarehuset og data laken.

En stor fordel med data lakehouse som konsept er at vi unngår to konkurrerende arkitekturer, brukt for henholdsvis rapporteringsformål (datavarehuset) og analyseformål (data laken).

Hvilke muligheter gir skyplattformer?