Lakehouse-arkitektur 2026: Iceberg, Delta och Hudi för svenska org

Lakehouse har gått från modeord till en arkitektur jag faktiskt rekommenderar. Idén är att slippa välja mellan datasjöns billiga flexibilitet och datalagrets pålitliga struktur, och i stället få bådadera. Nyckeln är tabellformaten Iceberg, Delta och Hudi. Här jämför jag dem för svenska organisationer som väger sin nästa plattform, och jag försöker hålla mig till det som faktiskt påverkar valet.

Innan jag går in på formaten vill jag nyansera entusiasmen. Lakehouse är en kraftfull idé, men det är inte rätt för alla. För ett mindre bolag med måttliga datavolymer kan ett vanligt molnlager vara både enklare och billigare, och då finns ingen anledning att ta på sig den extra arkitektoniska komplexiteten. Lakehouse lönar sig framför allt när du har stora datavolymer, blandade arbetsbelastningar och ett behov av att flera olika verktyg ska kunna arbeta mot samma data. Jag tar därför alltid först diskussionen om ni faktiskt behöver ett lakehouse innan vi ens börjar jämföra format.

Vad ett lakehouse är

Ett lakehouse lägger ett öppet tabellformat ovanpå billig objektlagring och får på köpet sådant vi förknippar med databaser: transaktioner, schemahantering och möjlighet att ändra och radera rader. Du behåller sjöns låga lagringskostnad men slipper dess klassiska kaos, eftersom formatet ger struktur och garantier.

Varför formatet är hjärtat

Det är tabellformatet som ger lakehouset sina garantier. Utan det är en datasjö bara en hög med filer där ingen vet om en läsning fångade ett halvskrivet tillstånd. Formatet hanterar atomära ändringar, versioner och schema, vilket är skillnaden mellan en pålitlig plattform och en samling filer man hoppas är konsekventa.

Apache Iceberg: det öppna standardvalet

Iceberg har vuxit till ett brett stött format med stark uppslutning från många olika motorer och leverantörer. För organisationer som vill undvika inlåsning och kunna byta beräkningsmotor över tid är det ofta det tryggaste valet, just för att så många system talar det.

• Brett stöd över många motorer, vilket minskar risken för inlåsning.
• Genomtänkt hantering av schemaändringar utan att skriva om data.
• Stark uppslutning som gör det till ett rimligt standardval framåt.

Att välja format med inlåsning i åtanke är en av de viktigaste arkitekturbesluten, och något vi alltid väger noga i vårt arbete med dataplattform.

Delta Lake: moget i Databricks-världen

Delta Lake är moget och välintegrerat, särskilt i Databricks ekosystem. Om ni redan lever där eller lutar åt det är Delta ofta det smidigaste valet, eftersom integrationen är tät och vägen kort. Det öppnas alltmer även utanför Databricks, men hemmaplanen märks fortfarande.

Apache Hudi: byggt för uppdateringar och streaming

Hudi har sin styrka i arbetsflöden med många uppdateringar och inkrementell bearbetning, inklusive streaming. Om er datakälla genererar en jämn ström av ändringar som ska speglas effektivt är Hudi värt en närmare titt, eftersom det designats just för den typen av föränderlig data.

Underhåll: kompaktering och gamla filer

En sida av lakehouse som sällan nämns i de glättiga beskrivningarna är att det kräver underhåll. När du skriver och uppdaterar data i ett tabellformat ackumuleras med tiden många små filer och gamla versioner som inte längre behövs. Utan skötsel blir läsningarna långsammare och lagringen onödigt dyr. Därför behöver du regelbundet kompaktera, alltså slå ihop små filer till färre och större, och rensa bort gamla ögonblicksbilder som ingen längre frågar mot. De olika formaten erbjuder verktyg för det, men det är lätt att glömma tills prestandan börjar svikta. Jag bygger in det underhållet som schemalagda rutiner från början, precis som man vakuumerar en databas.

Vem som äger katalogen

I en lakehouse-arkitektur blir katalogen, som håller reda på vilka tabeller som finns och var de ligger, en central och ibland underskattad komponent. Eftersom flera olika beräkningsmotorer kan läsa samma data behöver de enas om var sanningen om tabellerna bor. Valet av katalog påverkar hur lätt det är att låta olika verktyg samarbeta och hur stor risken för inlåsning blir. Jag ser till att katalogfrågan tas upp tidigt, för en illa vald katalog kan undergräva just den öppenhet som är hela poängen med ett lakehouse. Det handlar också om styrning: katalogen är en naturlig plats att hantera behörigheter och hålla ordning på vad som finns.

Hur jag väljer

För de flesta som börjar nytt och vill hålla dörrarna öppna lutar jag åt Iceberg för dess breda stöd. Är ni djupt i Databricks är Delta ofta smidigast. Har ni tunga uppdaterings- och streamingbehov tittar jag på Hudi. Som alltid får era faktiska arbetsflöden väga tyngre än vilket format som är populärast just nu. Fler exempel finns i vår casebook.

Relaterat

• Data quality-ramverk: Great Expectations + dbt tests i CI/CD
• Semantic layer 2026: dbt Semantic Layer vs Cube vs LookML
• dbt vs SQLMesh 2026: Modern transformation-lager för Snowflake/BigQuery

Vill du ta det vidare?

Om ni väger en lakehouse-arkitektur och inte vet vilket format som passar er väg framåt, hör av dig via kontaktsidan. Jag hjälper dig välja med inlåsning och arbetsflöden i åtanke.