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