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, ZORDEReller 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 OPTIMIZEfinns 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.