Anine Harto

Når man jobber med data som endrer seg over tid, er det helt naturlig å ville beholde historikken. Dette er kjernen i det som kalles Slowly Changing Dimensions type 2 (SCD2), som er en måte å sørge for at vi alltid kan se hvordan en rad så ut før, samtidig som den oppdateres med ny informasjon.

I Delta Lake og PySpark skulle man jo tro at dette var et løst problem. Det virker så grunnleggende at man nesten forventer en ferdig funksjon for det, for eksempel:

Det viser seg at PySpark kun støtter én handling per match i en MERGE. Du kan enten 

 en ny, men ikke begge deler for samme match. Og det er akkurat det man trenger i en klassisk SCD2-operasjon.

 i PySpark burde dette vært enkelt. Helst noe sånn som dette:

... men dette går dessverre ikke. PySpark tillater nemlig kun én 

 for samme rad. Prøver du, får du en feilmelding. Du kan heller ikke kjøre to merge-operasjoner etter hverandre uten å risikere datainkonsistens, siden de ikke garanteres å kjøre som én transaksjon.

Etter å ha prøvd meg fram med PySpark-API-et og noen kreative workarounds, landet jeg på en løsning som er både robust og gjenbrukbar: en to-trinnsmetode som bruker SQL under panseret.

Jeg skrev en metode som først lukker eksisterende rader der data har endret seg, og deretter setter inn nye versjoner. Metoden kan brukes mot en hvilken som helst tabell ved å angi nøkler, kolonnenavn og schema.

Denne løsningen fungerer fordi begge trinnene kjøres som én transaksjon i Delta Lake. Delta håndterer committen som én helhet, slik at du slipper risiko for halvveis oppdateringer. Resultatet er en enkel, forutsigbar og fleksibel implementasjon av SCD2 uten å måtte skrive skreddersydd SQL for hver tabell. Bare å kopiere uten skam dersom dette er noe du også trenger!

Denne metoden har fungert stabilt i produksjon, og gir meg kontroll over hele SCD2-flyten uten å ofre lesbarhet. Noen ganger må man bare preppe sine egne løyper.

Vi digger å dele erfaringer og lære nye triks! Hvis du har ideer, spørsmål eller bare vil slå av en prat, kast oss gjerne en snøball på hei@snokam.no.

PySpark støtter bare én handling per match i en MERGE, noe som gjør Slowly Changing Dimensions (SCD2) vanskelig. Her viser jeg hvordan jeg løste det i Delta Lake med en to-trinns tilnærming.

Delta Lake er et lagringsformat som gjør det enklere å håndtere store datamengder på en trygg og strukturert måte. Den bygger videre på eksisterende datalagring i skyen, men legger til funksjoner som versjonskontroll, transaksjoner og mulighet til å rette opp feil uten å miste data.
Hos Snøkam bruker vi Delta Lake som en del av dataarkitekturen vår for å sikre at data alltid er oppdatert, konsistent og lett tilgjengelig. Det gjør det enklere å bygge datamodeller, kjøre analyser og hente innsikt på tvers av store og komplekse datasett.
Med Delta Lake får vi en mer robust og effektiv dataflyt – en løsning som kombinerer fleksibiliteten fra rådata med tryggheten til en strukturert database.

Data Plattform

Deltalake

Apache Spark er et verktøy for å behandle store mengder data raskt og effektivt. Det gjør det mulig å analysere data i sanntid eller utføre avanserte beregninger på tvers av store datamengder.
Vi bruker Spark fordi det gir oss kraften til å hente ut innsikt fra store datakilder, bygge maskinlæringsmodeller og støtte løsninger som krever høy ytelse og skalerbarhet.

Spark

Databricks er en plattform for å jobbe med data på en enkel og effektiv måte. Den samler databehandling, analyse og maskinlæring på ett sted, slik at utviklere og dataanalytikere kan samarbeide bedre.
Vi bruker Databricks fordi det gjør det mulig å hente innsikt raskere, bygge datadrevne løsninger og ta bedre beslutninger basert på fakta.

Databricks

Python er et programmeringsspråk som er kjent for å være enkelt å lese og bruke. Det brukes til alt fra databehandling og automatisering til kunstig intelligens og webutvikling.
Vi bruker Python fordi det gir oss stor fleksibilitet, et enormt utvalg av verktøy og gjør det mulig å bygge alt fra små skript til avanserte dataløsninger på en effektiv måte.

Python

Hvorfor PySpark MERGE ikke håndterer SCD2 (og hvordan fikse dette i Delta Lake)

dbt (data build tool) er et verktøy som virkelig har skutt fart de siste årene, og det er ikke rart. Endelig har vi fått et verktøy som gjør det enkelt å versjonere, dokumentere, teste og release data ved hjelp av SQL. Eller?

Enkelt er vel kanskje å ta litt hardt i, spesielt for den gjenge dataanalytiker som ikke er vant med de gode praksisene fra softwareutvikling. Ofte ligger ikke IDE (Integrated Development Environment) og Git til fingerspissene, og da kan terskelen for å ta i bruk et verktøy som dbt, nærmere bestemt dbt Core, virke ganske høy.

dbt Core er nemlig gratisversjonen fra dbt Labs og er i bunn og grunn et kommandolinjeverktøy (CLI) og et rammeverk der du selv må sette opp konfigurering, administrasjon av miljøer, og integrasjon med andre verktøy f.eks Databricks, Apache Airflow eller lignende. Med andre ord krever både oppsett og bruk en viss teknisk kompetanse. dbt Cloud derimot er den dyre storebroren som er en administrert SaaS-versjon av dbt Core, og tilbyr egentlig alt du trenger innebygd, og er derfor et naturlig valg for de fleste dataanalytikere.

Hos en av kundene jeg nylig satt hos var det et spørsmålet om vi skulle begynne å ta i bruk dbt for å lage nye dataprodukter i dataplattformen vår. For å overbevise dataanalytikerne i organisasjonen bestemte vi oss for å vise i praksis hvilke muligheter dbt ville gi og hvor lett det var å ta i bruk. Utfordringen var den: vi måtte gjøre dette ved å bruke dbt Core. Ettersom dataplattformen vår var i Databricks, stilte vi oss spørsmålet:

Kan vi bruke Databricks og dets integrasjon med Git til å erstatte behovet for en IDE?

Før vi går videre må jeg bare understreke at ettersom løsningen utelukkende hadde som mål å vise mulighetene dbt tilbyr, så er det flere aspekter som mangler for å kunne bruke dette som en permanent løsning.

1. Opprett en Databricks notebook for å kjøre dbt-kommandoer

Det vi må finne ut av er hvordan vi skal bygge og deploye prosjektet vårt fra Databricks istedenfor vår lokale terminal. Dette gjorde vi ved å lage en veldig enkel notebook 

Denne notebooken vil kjøre kommandoene som laster ned nødvendig avhengigheter og kjører dbt-prosjektet direkte i Databricks-miljøet.

Vi opprettet en designert profileringsfil 

 for de som ønsker å bruke Databricks til dbt-utvikling i en egen mappe.

: Bestemmer hvilket miljø som skal brukes.

: Navnet på skjemaet der dbt skal opprette tabeller.

Ved lokal utvikling bruker vi OAuth user-to-machine autentisering som tillater systemtilgang på vegne av en bruker, her dbt klienten, ved å hente et OAuth token gjennom en browser popup fra Azure Entra ID. Dbt bruker deretter dette tokenet til å koble seg til DBSQL API. Dette er dessverre ikke støttet når vi kjører dbt fra et Databricks cluster, så vi måtte nøye oss med å bruke OAuth machine-to-machine. Selv om dette ikke er ideelt i en produksjonssetting, fungerte det bra for vårt formål.

3. Sett opp cluster policy med biblioteker og miljøvariabler i Databricks

Deretter lagde vi en cluster policy med de nødvendige bibliotekene for å kjøre dbt-kommandoer: 

DBT_PROFILES_DIR=./<mappen med profile.yml>

: dbt sjekker denne miljøvariablen for å avgjøre hvilket profileringsfil som skal brukes

CLIENT_SECRET={{secrets/<secret scope>/<secret name>}}

: vi henter denne verdien gjennom Azure Key Vault backed secret scopes

: vi lar brukeren sette denne verdien selv

Det eneste brukerne måtte gjøre selv var dermed å lage et personlig cluster med denne cluster policyen og kjøre 

Denne løsningen fungerte utmerket for å raskt kunne onboarde nye, ikke-tekniske ressurser til dbt Core, og for å ta avgjørelsen om at man ønsket å gå videre med dbt Cloud. Dersom dette er en løsning man skulle gått for på en mer permanent basis, ville jeg tenkt over følgende:

 er standard praksis for dbt Core, men automatisering av dette (f.eks. 

) er dessverre ikke støttet i Databricks.

 Som nevnt satte vi dette opp med OAuth machine-to-machine som betyr at alle brukere deler samme service principal, noe som ikke er ideelt for logging og sikkerhet.

Jeg syns det var veldig gøy å tenke litt utenfor boksen og komme frem til en løsning som gjør datautvikling tilgjengelig for flere, men det krever fortsatt noen avveininger.

Jeg vil gjerne høre din historie her! Hvordan onboardet dere de ansvarlige for utvikling av dataprodukter i dbt?

Hemmeligheten som skaperne bak dbt ikke vil at du skal vite om!

dbt (data build tool) er et verktøy som hjelper oss å strukturere og bearbeide data på en ryddig og effektiv måte. Det lar oss skrive SQL-spørringer som bygges og kjøres som kode, slik at vi kan transformere rådata til forståelige modeller og rapporter.
Hos Snøkam bruker vi dbt for å gjøre dataarbeid mer forutsigbart og gjennomsiktig. Det gjør det enkelt å holde oversikt over hvordan data flyter gjennom systemene våre, og sikrer at analyser og rapporter alltid bygger på oppdaterte og pålitelige kilder.
dbt passer perfekt inn i moderne dataarbeidsflyter fordi det kombinerer utviklerverktøy, versjonskontroll og dokumentasjon i én strukturert prosess.

Hvordan demokratisere datautvikling: dbt Core og Databricks for alle

Arvid Mildner

er i bunn og grunn bare en samling filer, typisk lagret på billig skylagring som Azure Blob Storage eller Amazon S3. Det er praktisk fordi du kan lagre enorme mengder rådata uten å betale for dyre databasesystemer. Hvorfor ikke bare bruke en relasjonsdatabase? Du kunne sikkert gjort det. For eksempel Postgres er en veldig allsidig og bra database. Men du sparer trolig en del penger på å bruke noe som er designet for analyse. I tillegg er slike databaser ofte radorienterte, mens analysejobber yter bedre med kolonnebasert lagring.

For eksempel Postgres organiserer data som komplette rader. Bra for transaksjonelle systemer (OLTP), hvor du ofte henter all data i en rad på en gang.

Lagrer data kolonnevis. Ideelt for analyse (OLAP), hvor du ofte jobber med aggregering og store datamengder på tvers av rader. For eksempel "finn summen av alle penger vi tjente over alle produkter denne måneden". Da kan databasemotoren i en kolonnebasert database ta kun den kolonnen, fordi hele kolonnen ligger på samme sted i minnet. Mer info 

Om du går for delta lake-sporet, vil du raskt oppdage at råfiler alene ikke er nok. Du trenger struktur og kontroll, og aller helst noen av de gode gamle databasegarantiene:

: systemet går fra én gyldig tilstand til en annen.

: samtidige operasjoner forstyrrer ikke hverandre.

: når data er skrevet, blir det værende.

Rå blob-lagring gir deg nesten ingen av disse garantiene. Du risikerer at data overskrives midt i en operasjon, eller at flere prosesser krasjer i hverandre.

inn. Dette er ikke et nytt filformat eller databasesystem, men mer likt en 

. Klientene følger en avtale: alle lesinger og skrivinger går gjennom en transaksjonslogg. Dette er en spesiell fil som ligger sammen med rådataen. Filer behandles som uforanderlige. Når du oppdaterer data, skriver du en ny fil og oppdaterer loggen. Det hele fungerer som en ACID-database, så lenge alle følger reglene. Derfor er det enkelt å gjøre en mappe med Parquet-filer (hvor dataen er lagret på en kolonnebasert måte) om til en Delta-tabell: du legger til en 

-mappe med loggfilerne og bruker et verktøy som forstår Delta-protokollen. Det er ikke noe mer magi en det, og det er det som gør det så smart! En Delta lake er da alltså en samling av delta tabeller.

Ovenfor ser vi innholdet i en delta-tabell: en komprimert Parquet-fil og en mappe med transaksjonslogg.

Hvis du bruker for eksempel Databricks, er 

 standardmotoren for å lese Delta-tabeller. Spark er kraftig, men også tung og kompleks. Ofte er det overkill dersom alt du trenger er å kjøre noen SQL-spørringer eller hente ut et lite datagrunnlag.

Et lettere alternativ: Apache Arrow og DuckDB

 er et in-memory-format for kolonnebasert data, optimalisert for hastighet og analyse.

Raskt (zero-copy reads, SIMD-akselererte operasjoner)

Language bindings for flere språk (Python, Rust, C++, m.m.)

Grunnlaget for flere moderne analyseverktøy

Byggesteinen på toppen? Du kan for eksempel bruke noe så kult som 

. Til tross for navnet er dette en svært kapabel SQL-motor, helt uten server eller oppsett. DuckDB kan lese direkte fra Parquet- og Delta-tabeller i skylagring (og fra lokal disk selvfølgelig). La meg gjenta her: det finnes ingen database med noen port 5432 og connection strings. Alt skjer i RAM, og dataen ligger på for eksempel blob storage.

Eksempel: spørring fra Azure Blob Storage

La oss koble oss opp mot en blob storage i Azure, og lese noe data fra et gitt tidsintervall. Her har vi lagret noe bitcoin-prisdata på blob storage som en Delta-tabell, som vi nå vil lese.


Resultatet? Data hentet direkte fra blob storage, på under to sekunder, helt uten Spark.

Bygg lettvekts-API-er på toppen av Delta

Hvis du allerede bruker Spark til ETL/ELT og skriver ut data til Delta-tabeller i blob-lagring, kan du nå bygge små og effektive API-er med for eksempel FastAPI og DuckDB. Det gjør det enkelt å tilgjengeliggjøre read-only-data til interne eller eksterne brukere, til en svært lav kostnad. Og med et lokalt cache-lag, for eksempel på disk i en Kubernetes-pod, kan responstiden forbedres ytterligere.

Vi digger å dele erfaringer og lære nye triks! Hvis du har ideer, spørsmål eller bare vil slå av en prat, send oss gjerne en e-post på hei@snokam.no.

Hva er en Delta Lake og en Delta-tabell, og trenger vi egentlig Spark?

DuckDB er en lettvekts database bygget for analyse. Den lar oss jobbe med data direkte fra filer – uten å måtte sette opp en stor database eller sende data til skyen.
Hos Snøkam bruker vi DuckDB til raske analyser, testing og databehandling lokalt i prosjekter. Den er spesielt nyttig når vi ønsker å utforske data uten å sette opp tunge systemer eller kompliserte miljøer.
DuckDB gir oss fleksibilitet, hastighet og enkelhet i ett – perfekt når vi vil eksperimentere med data eller bygge løsninger som krever raske, lokale analyser.

DuckDB

Hva er en  Delta Lake og en Delta-tabell, og trenger vi egentlig Spark?

Azure

Cloud

Terraform

Docker

Kubernetes

Typescript

Frontend

Golang

Backend

Øystein Lasson

Splunk

Sikkerhet

Håkon Gjertsen Norbye

Embedded

ESP32

Rust

Morten Jansrud

React

.NET

Java

Kunstig Intelligens

GraphQL

Next.js

Simen Johnsrud

Kotlin

Her deler vi erfaringer vi har gjort oss med {{tagTitle}} i prosjekter og i hverdagen vår som utviklere.

Vi du vite mer om hvordan vi bruker {{tagTitle}} i Snøkam?

Våre utviklere med erfaring i {{tagTitle}}

{{tagTitle}} er en sentral del av flere av våre kundeprosjekter. Her ser du noen eksempler på hvordan vi har brukt teknologien i praksis.

{{tagTitle}} - Teknologi i Snøkam

plattform handler om å samle, strukturere og gjøre data tilgjengelig for analyse, innsikt og beslutningsstøtte. En god dataplattform sørger for at informasjon flyter trygt og effektivt fra ulike kilder til rapporter, modeller og applikasjoner som skaper verdi. Det er her grunnlaget legges for datadrevne beslutninger, automatisering og bruk av kunstig intelligens – med fokus på kvalitet, skalerbarhet og pålitelighet.

Vipps MobilePay hadde behov for en plattform som kunne forenkle dataflyten mellom produsenter og konsumenter, samtidig som den gjorde vedlikehold enklere og mer effektivt. Den eksisterende infrastrukturen var tungvinn å vedlikeholde og begrenset i skalerbarhet. Dataprodusenter hadde ikke verktøy for rask og enkel deling av data, og datakonsumenter opplevde utfordringer med å finne, forstå og ta i bruk tilgjengelige dataprodukter.

Vi i Snøkam bidro til å bygge en moderne, selvbetjent dataplattform som adresserte Vipps MobilePay sine utfordringer. Gjennom automatisert infrastruktur med Terraform ble implementeringen robust og skalerbar. Tilgangsstyring ble forenklet med Purpose Based Access Control (PBAC), som sikret trygg og målrettet tilgang til data. For dataprodusenter var vi med å utvikle verktøy som muliggjorde rask oppsett av dataintegrasjoner gjennom datakontrakter. For datakonsumenter ble det designet brukervennlige grensesnitt som gjorde det enkelt å forespørre, analysere og bruke data. Automatisering av skjemaendringer og versjonering forenklet vedlikehold og reduserte risikoen for feil.

Den nye plattformen kobler tekniske og ikke-tekniske brukere tettere sammen, noe som legger til rette for smartere datadeling og raskere, datadrevne beslutninger. Vipps MobilePay har nå et solid, skalerbart fundament som støtter videre innovasjon, med en sterkere datakultur på tvers av organisasjonen.

Vipps MobilePay

Vipps MobilePay hadde behov for en plattform som kunne forenkle dataflyten mellom produsenter og konsumenter, samtidig som den gjorde vedlikehold enklere og mer effektivt.

Data Plattform

Våre utviklere med erfaring i data plattform

Data plattform i våre prosjekter

Dataplattform for Vipps MobilePay

Dette skriver vi om data plattform

Hvorfor PySpark MERGE ikke håndterer SCD2 (og hvordan fikse dette i Delta Lake)

Hvordan demokratisere datautvikling: dbt Core og Databricks for alle

Hva er en Delta Lake og en Delta-tabell, og trenger vi egentlig Spark?

Vi du vite mer om hvordan vi bruker data plattform i Snøkam?