Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Delta-tabelfiler bliver fragmenterede over tid. Fragmentering øger fildriftsomkostninger, reducerer komprimeringseffektiviteten og kan begrænse læserens parallelisme. Kompaktering omskriver mange små filer til færre filer i den rigtige størrelse, så Spark kan læse og behandle data mere effektivt.
Kommandoen OPTIMIZE er den primære komprimeringsoperation. Den grupperer små filer i beholdere, der sigter mod en ideel filstørrelse, og omskriver dem derefter til storage.
For vejledning på tværs af arbejdsbelastninger om kompaktionsstrategier på tværs af SQL Analytics Endpoint, Power BI Direct Lake og Spark, se vedligeholdelse og optimering af tværarbejdsbelastningstabeller.
Komprimeringsmetoder
Microsoft Fabric tilbyder flere tilgange til at opretholde optimale filstørrelser i Delta-tabeller:
OPTIMIZE kommando
Kommandoen OPTIMIZE er den grundlæggende handling til at komprimere Delta-tabeller. Den omskriver små filer til større filer for at forbedre datalayoutet i Delta-tabeller.
| Egenskab | Beskrivelse | Standardværdi | Konfiguration af session |
|---|---|---|---|
| minFileSize | Filer, der er mindre end denne grænse, grupperes sammen og omskrives som større filer. | 1073741824 (1 GB) | spark.databricks.delta.optimize.minFileSize |
| maxFileSize | Målfilstørrelse produceret af kommandoen OPTIMIZE . |
1073741824 (1 GB) | spark.databricks.delta.optimize.maxFileSize |
OPTIMIZE er idempotent, men en oversized minFileSize kan øge skriveforstærkningen. For eksempel minFileSize kan en 900 MB fil omskrives efter en lille ekstra skrivning med sat til 1 GB. For automatisk vejledning til filstørrelsesstyring, se adaptiv målfilstørrelse.
OPTIMIZE med Z-Order
Når du bruger klausulen ZORDER BY , omskriver den aktive filer, OPTIMIZE så rækker med lignende værdier er samlet i de samme filer. Det colocerede layout forbedrer filspring for selektive filtre. Brug Z-Order, når:
- Dine forespørgsler filtrerer ofte på to eller flere kolonner sammen (f.eks. dato + customer_id), og
- Disse prædikater er selektive nok til, at spring på filniveau reducerer antallet af scannede filer.
OPTIMIZE dbo.table_name ZORDER BY (column1, column2)
OPTIMIZE med V-Order
Klausulen VORDER resulterer i, at de filer, der er begrænset til komprimering, får V-Order-optimeringen anvendt. For mere information om V-Order, se den detaljerede dokumentation.
OPTIMIZE dbo.table_name VORDER
Du kan kombinere Z-Order og V-Order i én enkelt kommando. Spark anvender operationerne i denne rækkefølge: bin-komprimering → Z-orden → V-orden.
OPTIMIZE dbo.table_name ZORDER BY (column1, column2) VORDER
V-Order-adfærd under OPTIMIZE afhænger af, hvordan du fremkalder kommandoen:
| Påkaldelse | Adfærd |
|---|---|
OPTIMIZE table VORDER |
Tvinger V-Order på omskrevne filer, uanset session- eller tabelindstillinger. |
OPTIMIZE table (ingen VORDER nøgleord) |
Arver V-Order-adfærd fra TBLPROPERTIES("delta.parquet.vorder.enabled") hvis sat, ellers falder tilbage til sessionskonfigurationen spark.sql.parquet.vorder.default. |
OPTIMIZE med væskeklynger
Væskeklynger er angivet som en tabelindstilling; Se Aktivér væskeklynger for at få flere oplysninger. Når flydende klynger er aktiveret, udføres den fysiske omskrivning, OPTIMIZE der anvender klyngepolitikken.
Vigtigt!
Data grupperes kun, når OPTIMIZE de køres på flydende grupperede aktiverede tabeller. Regelmæssige skrivehandlinger grupperer IKKE dataene. Det er vigtigt at have en komprimeringsstrategi, f.eks. ved hjælp af automatisk komprimering eller manuel planlægning af optimeringsjob, for at sikre, at fordelene ved klyngedata (dvs. forbedret Delta-filspring) kan realiseres.
Hurtig optimering
Hurtig optimering analyserer intelligent Delta-tabelfiler og springer komprimeringshandlinger over, der sandsynligvis ikke vil forbedre ydeevnen meningsfuldt.
I stedet for blindt at komprimere filer, når der findes små filer, evaluerer Fast Optimize, om hver kandidatbeholder (gruppe af små filer) opfylder konfigurerbare mål for komprimering af bedste praksis. Fast Optimize kører kun komprimering på en bakke med filer, hvis det er sandsynligt, at fletning af dem vil nå din mindste målstørrelse, eller hvis der er for mange små filer. Ellers springer den gruppen over eller reducerer, hvor mange filer den komprimerer.
Hurtig optimering kan finjusteres baseret på dine komprimeringsforventninger:
| Egenskab | Beskrivelse | Standardværdi | Konfiguration af session |
|---|---|---|---|
| minNumFiles | Antallet af små filer, der skal findes i en placering, for at optimering kan udføres, hvis placeringen ikke indeholder nok data, der er estimeret til at producere en komprimeret fil. | 50 | spark.microsoft.delta.optimize.fast.minNumFiler |
| parketKoefficient | Ganget med den mindste filstørrelse for optimering af kontekst for at bestemme den mindste mængde små fildata, der skal findes i en placering, for at placeringen kan medtages i komprimeringsomfanget. | 1.3 | spark.microsoft.delta.optimize.fast.parquetCoefficient |
Notat
Resultatet parquetCoefficient er, at målstørrelsen for en placering er større end den mindste målfilstørrelse for optimeringskonteksten. Denne koefficient tager højde for den virkelighed, at kombination af flere små parketfiler resulterer i bedre komprimering og dermed færre data end summen af små filer. Øg værdien for at være mere konservativ i, hvor hurtigt man optimerer containere, eller sænk værdien for at tillade mere tilladende bin-spring.
Sådan fungerer det
Hurtig optimering introducerer ekstra kontroller, før skraldespande komprimeres. For hver kandidatbeholder evaluerer hurtig optimering:
- Den anslåede mængde rådata i placeringen (summen af små filstørrelser)
- Om kombinationen af de små filer anslås at producere en fil, der opfylder den konfigurerede minimumsmålstørrelse
- Om placeringen mindst indeholder det konfigurerede mindste antal små filer
Fast Optimize evaluerer hver bin med små filer og kompakter kun de bins, der sandsynligvis vil nå minimumsmålstørrelsen eller overstige minimumsfilantallet. Placeringer, der ikke opfylder disse tærskler, springes over eller komprimeres delvist. Hvis du springer suboptimale placeringer over, reduceres unødvendige omskrivninger, skriveforstærkning sænkes og OPTIMER-job bliver mere idempotente.
Notat
Den nøjagtige implementering kan udvikle sig over tid.
Hurtig optimering kan reducere omskrevne data over en Delta-tabels livscyklus. Som vist i det følgende diagram, springer hurtig optimering suboptimale bins over, hvilket resulterer i hurtigere og mere idempotente OPTIMIZE jobs med mindre skriveforstærkning.
Notat
Kun til illustrationsformål antager ovenstående diagrammer, at størrelsen af filen skrevet fra komprimering er summen af størrelsen af små filer. Det indebærer også a parquetCoefficient på 1.
Begrænsninger
- Gælder ikke for væskeklynger og Z-Order-operationer
- Hurtig optimering ændrer ikke funktionsmåden for automatisk komprimering
Komprimeringsmål på filniveau
For at undgå omskrivning af data, der tidligere blev betragtet som komprimerede (store nok) baseret på ændring af mål for komprimering af min. og maks. filstørrelse, spark.microsoft.delta.optimize.fileLevelTarget.enabled kan aktiveres for at forhindre omkomprimering af allerede komprimerede filer. Når den er aktiveret, komprimeres filer ikke, hvis de tidligere har opfyldt mindst halvdelen af målfilstørrelsen på komprimeringstidspunktet. Vedligeholdelse af filniveaumål minimerer skriveforstærkning, da kompaktionsmålets størrelse ændrer sig over tid (for eksempel fra adaptiv målfilstørrelse, evaluering og sætning af et større mål). Hvis den er aktiveret, føjes OPTIMIZE_TARGET_SIZE koden til nye filer, når OPTIMIZE køres, eller til en skrivehandling, hvis egenskaben delta.targetFileSize eller delta.targetFileSize.adaptive tabel er angivet.
Notat
Selvom det ikke er aktiveret som standard, anbefaler Microsoft, at du aktiverer komprimeringsmål på filniveau for at begrænse potentiel skriveforstærkning.
Automatisk komprimering
Automatisk komprimering evaluerer partitionstilstanden efter hver skrivehandling. Når den registrerer overdreven filfragmentering (for mange små filer) i en partition, udløser den en synkron OPTIMIZE handling umiddelbart efter, at skrivningen er begået. Denne forfatterdrevne tilgang til filvedligeholdelse er optimal, fordi komprimering kun udføres, når det er programmatisk bestemt at være gavnligt.
Aktiver på sessionsniveau
Sat spark.databricks.delta.autoCompact.enabled på sessionsniveau for at muliggøre automatisk komprimering for nye tabeller oprettet i den Spark-session:
Aktiver på tabelniveau
Sæt tabelegenskab delta.autoOptimize.autoCompact for at aktivere automatisk komprimering for specifikke tabeller:
CREATE TABLE dbo.table_name
TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
Brug DataFrameWriter-muligheden delta.autoOptimize.autoCompact til at aktivere automatisk komprimering, når du opretter en tabel:
df.write.option('delta.autoOptimize.autoCompact', 'true').saveAsTable('dbo.table_name')
Aktiver den samme tabelegenskab på en eksisterende tabel:
ALTER TABLE dbo.table_name
SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
Reducer evalueringsomkostninger
Fra Fabric Spark runtime 2.0 (Delta 4.1) kan du aktivere onCheckpointOnly autokomprimeringstilstand. Som standard evaluerer automatisk komprimering filmetadata efter hver skriveoperation for at afgøre, om en tabel har for mange små filer. Med , udskydes evalueringen til log-checkpoint-operationer onCheckpointOnly(typisk hver 10. commit). Ved checkpoint-tidspunktet er tabelsnapshot'en allerede fuldt rekonstrueret, så evalueringen læser fra metadata, der allerede er i hukommelsen i stedet for at kræve en ekstra scanning. Den udsatte evaluering reducerer overhead pr. commit, samtidig med at tabellerne stadig komprimeres periodisk.