ms-ai-architect/skills/ms-ai-engineering/references/data-engineering/delta-lake-parquet-optimization.md
Kjell Tore Guttormsen 3a73eeafdc refactor(ms-ai-architect): R13 del 1 — nøytraliser Cosmo-personaen i ref-korpusets headinger, etter å ha rettet en gate som var målt usann to ganger
Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:

1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
   produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
   substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
   `Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
   tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
   kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
   formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
   132 bokføres til R13b/R14.

Tre korreksjoner av premisser som sto i ordren og STATE:
  «ca 320 produkt»   -> 451 (case-sensitivt nett manglet 327 lowercase
                        TOC-ankre + 99 identifikatorer; sann nevner 1 638)
  «169 headinger»    -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
                        internt inkonsistent med sin egen topp-variant (204)
  «417 matcher ingen
   populasjon»       -> 417 er cosmo-headinger utenfor kodefences; briefens
                        nevner var reell hele tiden

Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.

TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.

Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.

Verifisering (alle 7 kriterier fra ordren):
  G1 persona på heading-linjer   401 -> 0
  G2 døde fragmentlenker         1 -> 1 (pre-eksisterende, unntatt)
  G3 produkt-forekomster         451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
  de 3 kun-produkt-filene        byte-identiske
  nettet validert begge veier    injisert persona feller G1; genitiv feller G1;
                                 produkt-heading og de 3 filene passerer
  hele diffen                    802 heading-linjer + 654 TOC-linjer, ANNET = 0
  linjeantall                    728 lagt til = 728 slettet
  suite                          1120/1120 (1097 + 23 nye)
  validate-plugin                250 PASS / 0 FAIL
  stikkprøve                     10 filer, alle 5 skills, inkl. de 3 mest
                                 produkt-tunge (26/20/19) — kun heading+TOC

Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 22:12:28 +02:00

409 lines
15 KiB
Markdown

# Delta Lake and Parquet Format Optimization
**Last updated:** 2026-06-24
**Status:** GA
**Category:** Data Engineering for AI
**Type:** reference
**Source:** https://learn.microsoft.com/fabric/data-engineering/delta-optimization-and-v-order
---
## Innhold
- [Introduksjon](#introduksjon)
- [Delta Lake ACID Transactions and Z-Order](#delta-lake-acid-transactions-and-z-order)
- [Parquet Compression Codecs and Row Groups](#parquet-compression-codecs-and-row-groups)
- [File Size Tuning and Auto-Compaction](#file-size-tuning-and-auto-compaction)
- [V-Order Optimization](#v-order-optimization)
- [Small File Handling and Garbage Collection](#small-file-handling-and-garbage-collection)
- [Best Practices for AI-arbeidsbelastninger](#best-practices-for-ai-arbeidsbelastninger)
- [Referanser](#referanser)
- [For arkitekten](#for-arkitekten)
## Introduksjon
Delta Lake er det foretrukne tabellformatet i Microsoft Fabric, bygget oppå Apache Parquet med ACID-transaksjoner, skjemavalidering og tidsreise. For AI-arbeidsbelastninger er ytelsen til underliggende lagring kritisk: dårlig filstruktur kan gjore treningsjobber 10x tregere og forre til unodvendig hoy kostnad. Optimalisering av Delta Lake og Parquet-filer er derfor en kjerneferdighet for enhver dataingenioor som bygger AI-pipelines.
Microsoft Fabric introduserer V-Order, en Parquet-skrivetidsoptimalisering som gir dramatisk raskere lesetider for alle Fabric-beregningsmotorer. Kombinert med Z-Order, auto-kompaktering og intelligent filstorrelsesstyring kan organisasjoner oppna opptil 50% bedre komprimering og ordre-av-storrelse raskere sporringsytelse.
For norsk offentlig sektor, der datavolumer vokser raskt og budsjettkrav er strenge, er det avgjorende a forstaa disse optimaliseringene. Riktig konfigurerte Delta-tabeller reduserer bade lagrings- og beregningskostnader, samtidig som de sikrer at data er tilgjengelig for analytikere, Power BI-rapporter og AI-modeller med minimal ventetid.
---
## Delta Lake ACID Transactions and Z-Order
### ACID-transaksjoner i Delta Lake
Delta Lake sikrer datakonsistens gjennom ACID-transaksjoner (Atomicity, Consistency, Isolation, Durability). Hver skriveoperasjon til en Delta-tabell oppretter en ny versjon i transaksjonsloggen (`_delta_log/`), som gjor det mulig med:
- **Atomiske skrivinger**: Hele operasjonen lykkes eller feiler som en enhet
- **Konsistente lesninger**: Lesere ser alltid en konsistent snapshot
- **Tidsreise**: Tilgang til historiske versjoner via versjonsnummer eller tidsstempel
- **Samtidige skrivinger**: Optimistisk samtidskonfliktllosning
```python
# Tidsreise - les historisk versjon
df_historical = spark.read \
.option("versionAsOf", 5) \
.table("lakehouse.default.ai_training_data")
# Eller via tidsstempel
df_timestamp = spark.read \
.option("timestampAsOf", "2026-01-15T10:00:00.000Z") \
.table("lakehouse.default.ai_training_data")
```
### Z-Order Clustering
Z-Order er en teknikk som samlokaliserer rader med lignende verdier i kolonnene du spesifiserer, slik at filbasert hopping (file skipping) blir effektiv for sporringer som filtrerer pa disse kolonnene.
```sql
-- Z-Order pa to kolonner som brukes i hyppige filtre
OPTIMIZE lakehouse.default.customer_embeddings
ZORDER BY (region_id, created_date);
```
**Naar du bor bruke Z-Order:**
| Scenario | Anbefaling |
|----------|------------|
| Sporringer filtrerer ofte pa 2-3 kolonner sammen | Bruk Z-Order pa disse kolonnene |
| Hoy kardinalitet i filterkolonner | Z-Order gir best effekt |
| Partisjonering allerede brukt for lav-kardinalitet | Kombiner partisjonering + Z-Order |
| Kun en filterkolonne | Vurder vanlig sortering i stedet |
**Begrensninger:**
- Z-Order krever full omskriving av data (kostbart)
- Best kjort under stille perioder (natt/helg)
- Ikke kompatibel med liquid clustering pa samme tabell
### Liquid Clustering (anbefalt for nye tabeller)
Liquid clustering er en nyere tilnaerming som erstatter bade partisjonering og Z-Order:
```sql
-- Opprett tabell med liquid clustering
CREATE TABLE lakehouse.default.ml_features
CLUSTER BY (tenant_id, feature_date)
AS SELECT * FROM raw_features;
-- Optimaliser for a anvende clustering
OPTIMIZE lakehouse.default.ml_features;
```
---
## Parquet Compression Codecs and Row Groups
### Komprimeringsalgoritmer
Parquet stotter flere komprimeringsalgoritmer. Valget pavirker filstorrelse, skrivetid og lesetid:
| Codec | Komprimering | Skrivetid | Lesetid | Bruksomrade |
|-------|-------------|-----------|---------|-------------|
| **Snappy** | Moderat (standard) | Rask | Rask | Generell bruk, Fabric standard |
| **ZSTD** | Hoy | Moderat | Rask | Langtidslagring, arkivering |
| **GZIP** | Hoy | Treg | Moderat | Kompatibilitet med eldre systemer |
| **LZ4** | Lav | Veldig rask | Veldig rask | Streaming, lav latens |
| **Uncompressed** | Ingen | Raskest | Raskest | Testing, mellomsteg |
```python
# Sett komprimering for en spesifikk skriveoperasjon
df.write \
.format("delta") \
.option("compression", "zstd") \
.mode("overwrite") \
.saveAsTable("lakehouse.default.archived_embeddings")
# Sesjonsniva-konfigurasjon
spark.conf.set("spark.sql.parquet.compression.codec", "zstd")
```
### Row Groups og Column Chunks
Parquet organiserer data i row groups (radgrupper), der hver row group inneholder column chunks for hver kolonne. Storrelsen pa row groups pavirker:
- **Leseparallellitet**: Flere row groups = bedre parallellitet
- **Predicate pushdown**: Statistikk per row group muliggjor filtrering
- **Minnebruk**: Storre row groups krever mer minne under lesing
```python
# Konfigurer row group-storrelse (standard 128 MB i Fabric)
spark.conf.set("spark.sql.parquet.rowGroupSize", str(128 * 1024 * 1024))
# For AI-arbeidsbelastninger med store batcher, vurder storre row groups
spark.conf.set("spark.sql.parquet.rowGroupSize", str(256 * 1024 * 1024))
```
### Encoding-strategier
Parquet bruker automatisk optimale encoding-strategier per kolonne:
| Datatype | Encoding | Beskrivelse |
|----------|----------|-------------|
| Integer, Long | Delta Binary Packed | Lagrer differanser mellom verdier |
| String (lav kardinalitet) | Dictionary | Erstatter verdier med korte koder |
| String (hoy kardinalitet) | Plain | Lagrer verdier direkte |
| Boolean | Run Length | Komprimerer gjentatte verdier |
| Timestamp | Delta Binary Packed | Effektiv for tidsserier |
---
## File Size Tuning and Auto-Compaction
### Smaa filer-problemet
Hyppige smaa skrivinger (streaming, micro-batch) forer til tusenvis av smaa filer, noe som:
- Oker metadata-overhead (transaksjonslogg, statistikk)
- Reduserer sporingsytelse pa grunn av fil-overhead
- Oker IOPS-kostnader i OneLake
### Optimal filstorrelse
| Tabellstorrelse | Anbefalt filstorrelse | Begrunnelse |
|----------------|----------------------|-------------|
| < 1 GB | 64-128 MB | Unnga for store filer for smaa tabeller |
| 1-100 GB | 256 MB - 1 GB | Standard Fabric-anbefaling |
| > 100 GB | 1 GB | Reduser antall filer, forbedre skanning |
```python
# Konfigurer mal-filstorrelse for OPTIMIZE
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", str(1024 * 1024 * 1024))
spark.conf.set("spark.databricks.delta.optimize.minFileSize", str(256 * 1024 * 1024))
```
### Auto-Compaction
Auto-kompaktering evaluerer partisjonshelsen etter hver skriveoperasjon og trigger OPTIMIZE automatisk naar det er for mange smaa filer:
```python
# Aktiver auto-kompaktering pa sesjonsniva
spark.conf.set("spark.databricks.delta.autoCompact.enabled", "true")
# Konfigurer pa tabellniva
spark.sql("""
ALTER TABLE lakehouse.default.streaming_features
SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")
```
### Optimize Write
Optimize Write reduserer antall filer som skrives ved a sammensla smaa partisjoner for de skrives til disk:
```python
# Aktivert som standard i Fabric
spark.conf.set("spark.databricks.delta.optimizeWrite.enabled", "true")
# Deaktiver for spesifikke jobber der skrivelatens er kritisk
df.write \
.format("delta") \
.option("optimizeWrite", "false") \
.mode("append") \
.saveAsTable("lakehouse.default.realtime_signals")
```
### Fast Optimize
Fast Optimize analyserer Delta-tabellens filer og hopper over kompakteringsoperasjoner som ikke forbedrer ytelsen vesentlig:
```python
# Aktiver Fast Optimize
spark.conf.set("spark.microsoft.delta.optimize.fast.enabled", "true")
# Konfigurer parametere
spark.conf.set("spark.microsoft.delta.optimize.fast.minParquetCoefficient", "0.5")
spark.conf.set("spark.microsoft.delta.optimize.fast.maxBinCount", "3")
```
---
## V-Order Optimization
### Hva er V-Order?
V-Order er en Fabric-spesifikk skrivetidsoptimalisering for Parquet-filer som aktiverer lynraske lesninger i alle Microsoft Fabric-beregningsmotorer. V-Order optimaliserer:
1. **Sortering**: Optimal radrekkefølge for Verti-Scan-teknologi
2. **Row group-distribusjon**: Jevn fordeling av data pa tvers av row groups
3. **Encoding**: Forbedret dictionary encoding og RLE
4. **Komprimering**: Opptil 50% bedre komprimering
### V-Order Ytelsespavirkning
| Motor | Uten V-Order | Med V-Order | Forbedring |
|-------|-------------|-------------|-----------|
| Power BI (Direct Lake) | Baseline | In-memory-lignende | 5-10x raskere |
| SQL Endpoint | Baseline | Verti-Scan | 3-5x raskere |
| Apache Spark | Baseline | Optimalisert lesing | 10-50% raskere |
| Skriveytelse | Baseline | ~15% tregere | Akseptabel trade-off |
### Konfigurere V-Order
```sql
-- Aktiver V-Order pa sesjonsniva
SET spark.sql.parquet.vorder.default = TRUE;
-- Aktiver pa tabellniva
ALTER TABLE lakehouse.default.ml_predictions
SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");
-- Anvend V-Order under OPTIMIZE
OPTIMIZE lakehouse.default.ml_predictions VORDER;
-- Kombiner Z-Order og V-Order
OPTIMIZE lakehouse.default.ml_predictions
WHERE prediction_date >= '2026-01-01'
ZORDER BY (model_id, customer_segment) VORDER;
```
### Ressursprofiler for V-Order
Fabric tilbyr ressursprofiler som automatisk konfigurerer V-Order:
```python
# For lesekrevende arbeidsbelastninger (aktiverer V-Order automatisk)
# Sett via Fabric workspace-innstillinger: readHeavyforSpark
# For skrivekrevende arbeidsbelastninger (V-Order deaktivert)
# Standard i nye Fabric-arbeidsomrader
```
### V-Order og 100% Parquet-kompatibilitet
V-Order er fullt kompatibelt med Apache Parquet-formatet. Alle Parquet-motorer kan lese V-Order-filer som vanlige Parquet-filer. Dette betyr at:
- Data forblir portabel til andre plattformer
- Ingen vendor lock-in
- Eksisterende ETL-pipelines trenger ikke endring
---
## Small File Handling and Garbage Collection
### VACUUM for Garbage Collection
VACUUM fjerner Parquet-filer som ikke lenger er referert i gjeldende Delta-commit:
```sql
-- Fjern filer eldre enn 7 dager (standard)
VACUUM lakehouse.default.training_dataset;
-- Fjern filer eldre enn 24 timer (forsiktig!)
VACUUM lakehouse.default.training_dataset RETAIN 24 HOURS;
-- Dry run - vis hva som vil fjernes
VACUUM lakehouse.default.training_dataset DRY RUN;
```
**Viktige hensyn:**
- Ikke sett retensjon lavere enn den lengste kjorende jobben
- Direct Lake-modeller refererer til spesifikke commit-versjoner - sikre at VACUUM ikke sletter disse
- Standard retensjon er 7 dager, noe som gir rom for tidsreise
### File-Level Compaction Targets
For a unnga omskriving av allerede kompakterte filer:
```python
# Aktiver file-level compaction targets
spark.conf.set("spark.microsoft.delta.optimize.fileLevelTarget.enabled", "true")
```
### Automatisert Vedlikehold
```python
# Komplett vedlikeholdsrutine for AI-datatabeller
from delta.tables import DeltaTable
def maintain_delta_table(table_name: str):
"""Kjor vedlikehold pa en Delta-tabell."""
delta_table = DeltaTable.forName(spark, table_name)
# 1. Kompakter smaa filer
delta_table.optimize().executeCompaction()
# 2. Anvend V-Order pa kompakterte filer
spark.sql(f"OPTIMIZE {table_name} VORDER")
# 3. Fjern gamle filer
spark.sql(f"VACUUM {table_name} RETAIN 168 HOURS")
print(f"Vedlikehold fullfort for {table_name}")
# Planlegg via Fabric Data Pipeline
tables = [
"lakehouse.default.raw_documents",
"lakehouse.default.embeddings",
"lakehouse.default.ml_features",
"lakehouse.default.predictions"
]
for table in tables:
maintain_delta_table(table)
```
### Lakehouse Table Maintenance UI
Fabric tilbyr en brukergrensesnitt for ad-hoc vedlikehold:
1. Apne Lakehouse i Fabric-portalen
2. Hoyreklikk pa tabellen
3. Velg **Maintenance** > **Optimize** eller **Vacuum**
4. Konfigurer innstillinger og kjor
### Overvaking av filhelse
```python
# Sjekk filstatistikk for en tabell
detail = spark.sql("DESCRIBE DETAIL lakehouse.default.ml_features")
detail.select("numFiles", "sizeInBytes", "properties").show(truncate=False)
# Sjekk transaksjonslogg for smaa filer
history = spark.sql("DESCRIBE HISTORY lakehouse.default.ml_features LIMIT 20")
history.select("version", "timestamp", "operation", "operationMetrics").show(truncate=False)
```
---
## Best Practices for AI-arbeidsbelastninger
### Anbefalte innstillinger per lag i Medallion-arkitektur
| Lag | V-Order | Auto-Compact | Filstorrelse | Z-Order |
|-----|---------|-------------|-------------|---------|
| **Bronze** | Deaktivert | Aktivert | 256 MB | Ingen |
| **Silver** | Valgfritt | Aktivert | 512 MB | Pa filtreringskolonner |
| **Gold** | Aktivert | Aktivert | 1 GB | Pa rapporteringskolonner |
| **ML Features** | Aktivert | Aktivert | 256 MB | Pa entitets-ID |
### Vedlikeholdsplan
| Operasjon | Frekvens | Tidsvindu |
|-----------|----------|-----------|
| Auto-Compact | Kontinuerlig | Automatisk |
| OPTIMIZE (full) | Ukentlig | Helg |
| OPTIMIZE + Z-Order | Manedlig | Helg |
| VACUUM | Daglig | Natt |
| Filhelse-sjekk | Daglig | Morgen |
---
## Referanser
- [Delta Lake table optimization and V-Order](https://learn.microsoft.com/en-us/fabric/data-engineering/delta-optimization-and-v-order) -- Komplett guide til V-Order og Delta-optimalisering i Fabric
- [Compacting Delta tables](https://learn.microsoft.com/en-us/fabric/data-engineering/table-compaction) -- Auto-kompaktering, Fast Optimize og filstorrelsesstyring
- [Tune file sizes for Delta Lake](https://learn.microsoft.com/en-us/fabric/data-engineering/tune-file-size) -- Adaptive filstorrelser og Optimize Write
- [Lakehouse and Delta Lake tables](https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-and-delta-tables) -- Oversikt over stottede formater og standardinnstillinger
- [Understand Direct Lake query performance](https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-understand-storage) -- V-Order-pavirkning pa Direct Lake-modeller
- [Delta Lake table maintenance](https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-table-maintenance) -- UI-basert vedlikehold i Lakehouse
---
## For arkitekten
- **Bruk denne referansen** naar kunder spor om ytelsesoptimalisering av Delta Lake-tabeller, Parquet-filformat, eller filvedlikehold i Fabric Lakehouse.
- **V-Order er det forste du bor anbefale** for lesekrevende arbeidsbelastninger som Power BI-rapporter, Direct Lake-modeller og AI-inferens. For skrivekrevende pipelines (ETL/streaming), behold standard deaktivert V-Order.
- **Liquid clustering bor anbefales over Z-Order** for nye tabeller i Fabric, da det er enklere a vedlikeholde og ikke krever full omskriving.
- **Auto-kompaktering bor alltid vaere aktivert** for streaming- og micro-batch-pipelines for a unnga smaafilproblemet.
- **For norsk offentlig sektor**: Fremhev at V-Order er 100% Parquet-kompatibelt og ikke skaper vendor lock-in -- viktig for anskaffelsesprosesser og etterlevelse av EIF-prinsippet om interoperabilitet.