ms-ai-architect/skills/ms-ai-engineering/references/data-engineering/delta-lake-parquet-optimization.md

# Delta Lake and Parquet Format Optimization

**Last updated:** 2026-02
**Status:** GA
**Category:** Data Engineering for AI

---

## 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 Cosmo

- **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.