La oss kutte gjennom alle buzzwords. En delta lake 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.

• Rad-orienterte databaser
  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.
• Kolonne-orienterte databaser
  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 her.
  

Struktur i ustrukturert lagring

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: ACID.

• Atomicity: alt eller ingenting skjer.
• Consistency: systemet går fra én gyldig tilstand til en annen.
• Isolation: samtidige operasjoner forstyrrer ikke hverandre.
• Durability: 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.

Delta Lake og Delta-tabeller

Her kommer da alltså delta lake og konseptet Delta-tabeller inn. Dette er ikke et nytt filformat eller databasesystem, men mer likt en protokoll. 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 _delta_log-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.

Men trenger du Spark?

Hvis du bruker for eksempel Databricks, er Apache Spark 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

Apache Arrow 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 DuckDB. 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.

import duckdb

STORAGE_ACCOUNT = "my_test_storage_account"
CONTAINER_NAME =  "deltadata"
TABLE_NAME = "crypto_BTC"
DELTA_PATH = f"abfss://{CONTAINER_NAME}/{TABLE_NAME}"

duck_con = duckdb.connect()
duck_con.execute("INSTALL azure")
duck_con.execute("LOAD azure")

# Bruker lokal Azure CLI-autentisering
duck_con.execute(f"""CREATE SECRET IF NOT EXISTS storage_auth (
    TYPE azure,
    PROVIDER credential_chain,
    CHAIN 'cli',
    ACCOUNT_NAME '{STORAGE_ACCOUNT}'
);""")

query = f"""SELECT *
FROM delta_scan('{DELTA_PATH}')
WHERE date >= 2025-07-01 AND date < 2025-07-02
ORDER BY date
LIMIT 10""" 

df = duck_con.execute(query).fetchdf()
print(df.to_dict(orient="records"))

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.

Vil du snakke mer om dette?

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.