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)

Azure

Cloud

Terraform

Docker

Arvid Mildner

Kubernetes

Typescript

Frontend

Golang

Backend

Håkon Gjertsen Norbye

Splunk

Sikkerhet

Embedded

ESP32

Rust

Morten Jansrud

React

.NET

Java

Kunstig Intelligens

GraphQL

Next.js

Simen Johnsrud

Kotlin

Øystein Lasson

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.

Python

Våre utviklere med erfaring i python

Python i våre prosjekter

Dataplattform for Vipps MobilePay

Dette skriver vi om python

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

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