ms-ai-architect/skills/ms-ai-engineering/references/data-engineering/delta-lake-parquet-optimization.md
Kjell Tore Guttormsen ddce43d8b2 feat(ms-ai-architect): Spor 1 — Port-1-substrat migrert på 4 ikke-advisor-skills (243 Source + 327 Type + 325 TOC + stale-verified poison fjernet) [skip-docs]
Steg 9 (R4): unified migrate-corpus.mjs --write over engineering/governance/
infrastructure/security. 327 filer mutert, verified=null, prosa byte-identisk
(fra første ## seksjon), advisor urørt (0 endringer).

To applier-fixes oppdaget under kjøring (TDD, RED→GREEN):
- insertHeaderFields: anker faller nå tilbake når en meta-linje selv passerer
  500B (2 filer pakket et avsnitt i **Status:** → Type/Source landet utenfor
  scan-vinduet, applierens post-write-assertion fanget + restaurerte).
- normalizeStaleVerified: fjerner nå ALLE stale non-date **Verified:** i
  500B-vinduet, inkl. stray body-dup rett under --- (9 mlops-genaiops-filer var
  ellers falskt "verified"/fresh, droppet fra worklist). Operatør-godkjent
  utvidelse av carve-out; kun stray metadata-linjer, aldri prosa.

test-transform-criterion: precondition oppdatert til post-migrasjons-sannhet
(fila bærer nå Source). Suite 728/728 grønn.
2026-07-04 10:19:11 +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 Cosmo](#for-cosmo)
## 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.