Komprimera datafiler med optimering på Delta Lake

  • Artikel

Se OPTIMERA.

Delta Lake på Azure Databricks kan förbättra läshastigheten för frågor från en tabell. Ett sätt att förbättra den här hastigheten är att slå samman små filer till större filer.

Kommentar

I Databricks Runtime 13.3 och senare rekommenderar Databricks att du använder klustring för Delta-tabelllayout. Se Använda flytande klustring för Delta-tabeller.

Databricks rekommenderar att du använder förutsägelseoptimering för att automatiskt köra OPTIMIZE för Delta-tabeller. Se Förutsägande optimering för Delta Lake.

Syntaxexempel

Du utlöser komprimering genom att OPTIMIZE köra kommandot:

SQL

OPTIMIZE delta.`/data/events`

Python

from delta.tables import *
deltaTable = DeltaTable.forPath(spark, "/data/events")
deltaTable.optimize().executeCompaction()

Scala

import io.delta.tables._
val deltaTable = DeltaTable.forPath(spark, "/data/events")
deltaTable.optimize().executeCompaction()

eller, alternativt:

SQL

OPTIMIZE events

Python

from delta.tables import *
deltaTable = DeltaTable.forName(spark, "events")
deltaTable.optimize().executeCompaction()

Scala

import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "events")
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 events WHERE date >= '2022-11-18'

Python

from delta.tables import *
deltaTable = DeltaTable.forName(spark, "events")
deltaTable.optimize().where("date='2021-11-18'").executeCompaction()

Scala

import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "events")
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?

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.