Genopret Delta-tabeller

Med Delta Lake kan du bruge kommandoen RESTORE til at gøre en ældre tabel opdateret igen. RESTORE gendanner en Delta-tabel til en tidligere tabelversion eller til tabeltilstanden ved et bestemt tidsstempel.

RESTORE Brug den, når du har brug for hurtigt at komme dig efter en dårlig ændring uden manuelt at genopbygge bordet. Fordi Delta-tabeller gemmer transaktionshistorik, kan du ofte rulle tilbage til en kendt god tilstand med en enkelt kommando.

Hvad RESTORE gør

RESTORE ændrer den aktuelle tilstand af en Delta-tabel, så den matcher en tidligere committet version.

Du kan gendanne en tabel, når du har brug for det:

• Genopretning fra utilsigtede sletninger eller opdateringer
• Fortryd en dårlig MERGE, overwrite eller tilføj operation
• Rull en skemaændring tilbage, der bryder downstream workloads
• Genopretning fra korruption forårsaget af et fejlbehæftet skrive- eller pipeline-trin

I modsætning til en skrivebeskyttet historisk forespørgsel ændrer den RESTORE live table-tilstand, som nye læsere ser.

Syntaks

Brug en af disse formularer til at gendanne en Delta-tabel.

Genopret til en specifik Delta-tabel-version:

Spark SQL

RESTORE TABLE schema_name.table_name TO VERSION AS OF 5

PySpark

from delta.tables import *
deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
deltaTable.restoreToVersion(5)

Scala

import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
deltaTable.restoreToVersion(5)

Genfør til tabellens tilstand ved et bestemt tidsstempel:

Spark SQL

RESTORE TABLE schema_name.table_name TO TIMESTAMP AS OF '2026-05-01 12:00:00'

PySpark

from delta.tables import *
deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
deltaTable.restoreToTimestamp("2026-05-01 12:00:00")

Scala

import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
deltaTable.restoreToTimestamp("2026-05-01 12:00:00")

Før du gendanner, skal du gennemgå tabellens historik, så du kan vælge den korrekte version:

Spark SQL

DESCRIBE HISTORY schema_name.table_name

PySpark

from delta.tables import DeltaTable
deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
display(deltaTable.history())

Scala

import io.delta.tables.DeltaTable
val deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
display(deltaTable.history())

En almindelig gendannelsesarbejdsgang ser sådan ud:

Spark SQL

DESCRIBE HISTORY dbo.orders;
RESTORE TABLE dbo.orders TO VERSION AS OF 42

PySpark

from delta.tables import *
deltaTable = DeltaTable.forName(spark, "dbo.orders")

# Review history to find target version
display(deltaTable.history())

# Restore to the target version
deltaTable.restoreToVersion(42)

Scala

import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "dbo.orders")

// Review history to find target version
display(deltaTable.history())

// Restore to the target version
deltaTable.restoreToVersion(42)

PySpark-metoderne DeltaTable udfører samme logiske operation som SQL-kommandoen RESTORE TABLE .

Hvad sker der under gendannelsen

Når du kører RESTORE, omskriver Delta Lake ikke målversionen på stedet. I stedet opretter den en ny version i Delta-loggen, som peger tilbage til datafilerne, der er tilknyttet den version eller tidsstempel, du har valgt.

Den adfærd har nogle vigtige konsekvenser:

• RESTORE opretter en ny aktuel version af tabellen.
• Filerne fra det genoprettede punkt bliver aktive igen.
• Filerne fra den nuværende tilstand før gendannelsen bliver ikke slettet med det samme.
• De nu ikke-refererede filer kan senere ryddes op med VACUUM.
• Selve gendannelsen registreres som en versioneret tabelændring.

Fordi RESTORE er versioneret, kan du inspicere det i tabelhistorikken:

Spark SQL

DESCRIBE HISTORY schema_name.table_name

PySpark

from delta.tables import *
deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
display(deltaTable.history())

Scala

import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
display(deltaTable.history())

RESTORE, tidsrejse og VACUUM

RESTORE og tidsrejser bruger den samme Delta-historie, men de løser forskellige problemer.

• Brug tidsrejser , når du kun behøver at læse ældre data uden at ændre den aktuelle tabelstatus.
• Brug RESTORE den, når du vil have den ældre tilstand til at blive den nuværende tilstand for alle nye læsninger og skrivninger.

VACUUM Det påvirker gendannelsen, fordi det fjerner urefererede filer fra lagringen. Efter en gendannelse bliver filerne fra den tidligere nuværende tilstand som regel urefererede. Hvis du ikke længere har brug for dem, kan du gøre dem rene med VACUUM.

Det modsatte er også vigtigt: VACUUM det kan forhindre en fremtidig genopretning. Hvis de VACUUM filer allerede er fjernet, fejler de filer, der kræves til den version, RESTORE du vil gendanne, fordi tabelhistorikken ikke længere har adgang til de fysiske filer.

Begrænsninger

RESTORE Det virker kun, når målversionen stadig har alle nødvendige datafiler tilgængelige.

Husk disse grænser:

• Du kan kun gendanne versioner, hvis datafiler stadig eksisterer.
• Hvis VACUUM de filer fjernes, fejler gendannelsesoperationen.
• Gendannelseshistorik styres af Delta-retentionsindstillinger, herunder delta.logRetentionDuration, og af den faktiske opbevaring af datafiler i lagring.
• I praksis påvirker både transaktionslogsopbevaring og filopbevaring, hvor langt tilbage du kan gendanne.

Bedste fremgangsmåder

Brug disse praksisser til at reducere risikoen:

• Kør DESCRIBE HISTORY det før du gendanner, så du kan bekræfte den rigtige version eller tidsstempel.
• Brug tidsrejseforespørgsler først, hvis du kun skal inspicere ældre data og ikke ønsker at ændre den aktuelle tabelstatus.
• Kør VACUUM efter en gendannelse, når du vil rydde op i urefererede filer fra pre-restore-tilstanden.
• Test gendannelsesstien på en klontabel først, når du arbejder med kritiske produktionsdata.

Relateret indhold

• Tidsrejser
• Inspektér metadata fra Delta-tabellen
• VAKUUM Delta-tabeller
• Klondelta-tabeller