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)

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

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

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

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

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

{{technologyTitle}} - Teknologi i Snøkam

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.

Spark

Våre utviklere med erfaring i spark

Spark i våre prosjekter

Dataplattform for Vipps MobilePay

Dette skriver vi om spark

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

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

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