Optimera layouten för datafiler
Förutsägande optimering körs OPTIMIZE
automatiskt på hanterade Unity Catalog-tabeller. Databricks rekommenderar att du aktiverar förutsägande optimering för alla hanterade Unity Catalog-tabeller för att förenkla dataunderhållet och minska lagringskostnaderna. Se Förutsägande optimering för hanterade Unity Catalog-tabeller.
Kommandot OPTIMIZE
skriver om datafiler för att förbättra datalayouten för Delta-tabeller. För tabeller med flytande klustring aktiverat OPTIMIZE
skriver du om datafiler för att gruppera data efter flytande klustringsnycklar. För tabeller med definierade partitioner utförs filkomprimering och datalayout i partitioner.
Tabeller utan flytande klustring kan eventuellt innehålla en ZORDER BY
sats för att förbättra dataklustring vid omskrivning. Databricks rekommenderar att du använder flytande kluster i stället för partitioner, ZORDER
eller andra metoder för datalayout.
Se OPTIMERA.
Syntaxexempel
Du utlöser komprimering genom att OPTIMIZE
köra kommandot:
SQL
OPTIMIZE table_name
Python
from delta.tables import *
deltaTable = DeltaTable.forName(spark, "table_name")
deltaTable.optimize().executeCompaction()
Scala
import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "table_name")
deltaTable.optimize().executeCompaction()
Om du har en stor mängd data och bara vill optimera en delmängd av den kan du ange ett valfritt partitionspredikat med :WHERE
SQL
OPTIMIZE table_name WHERE date >= '2022-11-18'
Python
from delta.tables import *
deltaTable = DeltaTable.forName(spark, "table_name")
deltaTable.optimize().where("date='2021-11-18'").executeCompaction()
Scala
import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "table_name")
deltaTable.optimize().where("date='2021-11-18'").executeCompaction()
Kommentar
- Optimering av bin-packning är idempotent, vilket innebär att om den körs två gånger på samma datauppsättning har den andra körningen ingen effekt.
- Bin-packning syftar till att producera jämnt balanserade datafiler med avseende på deras storlek på disken, men inte nödvändigtvis antalet tupplar per fil. De två åtgärderna är dock oftast korrelerade.
- Python- och Scala-API:er för körning
OPTIMIZE
är tillgängliga från Databricks Runtime 11.3 LTS och senare.
Läsare av Delta-tabeller använder ögonblicksbildisolering, vilket innebär att de inte avbryts när OPTIMIZE
onödiga filer tas bort från transaktionsloggen. OPTIMIZE
gör inga datarelaterade ändringar i tabellen, så en läsning före och efter en OPTIMIZE
har samma resultat. Att utföra OPTIMIZE
en tabell som är en strömmande källa påverkar inte några aktuella eller framtida strömmar som behandlar den här tabellen som en källa. OPTIMIZE
returnerar filstatistiken (min, max, total och så vidare) för de filer som tagits bort och de filer som lagts till av åtgärden. Optimeringsstatistik innehåller även statistik för Z-beställning, antalet batchar och partitioner som är optimerade.
Du kan också komprimera små filer automatiskt med automatisk komprimering. Se Automatisk komprimering för Delta Lake på Azure Databricks.
Hur ofta ska jag köra OPTIMIZE
?
Aktivera förutsägande optimering för hanterade Unity Catalog-tabeller för att säkerställa att körs OPTIMIZE
automatiskt när det är kostnadseffektivt.
När du väljer hur ofta du ska köra OPTIMIZE
finns det en kompromiss mellan prestanda och kostnad. Kör oftare för bättre frågeprestanda OPTIMIZE
för slutanvändare. Detta medför en högre kostnad på grund av den ökade resursanvändningen. För att optimera kostnaden kör du den mindre ofta.
Databricks rekommenderar att du börjar med att köra OPTIMIZE
dagligen och sedan justera frekvensen för att balansera kostnads- och prestandaavvägningar.
Vilken är den bästa instanstypen att köra OPTIMIZE
(bin-packing och Z-Ordering) på?
Båda åtgärderna är CPU-intensiva åtgärder som utför stora mängder Parquet-avkodning och kodning.
Databricks rekommenderar beräkningsoptimerade instanstyper. OPTIMIZE
fördelar med anslutna SSD:er.