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

Azure

Cloud

Terraform

Docker

Arvid Mildner

Kubernetes

Typescript

Frontend

Golang

Backend

Øystein Lasson

Splunk

Sikkerhet

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.

Databricks

Våre utviklere med erfaring i databricks

Databricks i våre prosjekter

Dataplattform for Vipps MobilePay

Dette skriver vi om databricks

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

Hvordan demokratisere datautvikling: dbt Core og Databricks for alle

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