Ripristinare le tabelle Delta

Con Delta Lake, è possibile usare il RESTORE comando per rendere nuovamente aggiornato lo stato precedente della tabella. RESTORE ripristina una tabella Delta a una versione precedente della tabella o allo stato della tabella in corrispondenza di un timestamp specifico.

Usare RESTORE quando è necessario eseguire rapidamente il ripristino da una modifica non valida senza ricompilare manualmente la tabella. Poiché le tabelle Delta mantengono la cronologia delle transazioni, è spesso possibile eseguire il rollback a uno stato valido noto in un singolo comando.

Cosa fa RESTORE

RESTORE modifica lo stato corrente di una tabella Delta in modo che corrisponda a una versione di cui è stato eseguito il commit precedente.

È possibile ripristinare una tabella quando è necessario:

  • Ripristino da eliminazioni o aggiornamenti accidentali
  • Annullare un'operazione non valida MERGE, sovrascrivere o accodare
  • Eseguire il rollback di una modifica dello schema che suddivide i carichi di lavoro downstream
  • Recuperare da un danneggiamento causato da un'operazione di scrittura o da una fase della pipeline difettosa

A differenza di una query cronologica di sola lettura, RESTORE modifica lo stato della tabella dinamica visualizzato dai nuovi lettori.

Sintassi

Utilizzare uno di questi moduli per ripristinare una tabella Delta.

Eseguire il ripristino in una versione specifica della tabella Delta:

RESTORE TABLE schema_name.table_name TO VERSION AS OF 5

Ripristinare lo stato della tabella in un timestamp specifico:

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

Prima di eseguire il ripristino, esaminare la cronologia delle tabelle in modo da poter scegliere la versione corretta:

DESCRIBE HISTORY schema_name.table_name

Un flusso di lavoro di ripristino comune è simile al seguente:

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

I metodi PySpark DeltaTable eseguono la stessa operazione logica del comando SQL RESTORE TABLE .

Cosa accade durante il ripristino

Quando si esegue RESTORE, Delta Lake non sovrascrive direttamente la versione di destinazione. Crea invece una nuova versione nel log Delta che fa riferimento ai file di dati associati alla versione o al timestamp selezionato.

Questo comportamento ha alcune conseguenze importanti:

  • RESTORE crea una nuova versione corrente della tabella.
  • I file dal punto ripristinato diventano nuovamente attivi.
  • I file dallo stato corrente di pre-ripristino non vengono eliminati immediatamente.
  • Questi file ora senza riferimenti possono essere puliti in un secondo momento con VACUUM.
  • Il ripristino stesso viene registrato come una modifica a una tabella versionata.

Poiché RESTORE è soggetto a controllo delle versioni, puoi ispezionarlo nella cronologia della tabella:

DESCRIBE HISTORY schema_name.table_name

RESTORE, viaggio nel tempo e VACUUM

RESTORE e il viaggio nel tempo usano la stessa cronologia Delta, ma risolvono problemi diversi.

  • Usa time travel quando devi solo leggere dati precedenti senza modificare lo stato corrente della tabella.
  • Usare RESTORE quando si desidera che lo stato precedente diventi lo stato corrente per tutte le nuove letture e scritture.

VACUUM influisce sul ripristino perché rimuove i file non referenziati dalla risorsa di archiviazione. Dopo un ripristino, i file dello stato che in precedenza era quello corrente di solito rimangono senza riferimenti. Se non sono più necessari, è possibile pulirli con VACUUM.

Il contrario è anche importante: VACUUM può impedire un ripristino futuro. Se VACUUM i file necessari per la versione da ripristinare sono già stati rimossi, RESTORE l'operazione non riesce perché la cronologia delle tabelle non ha più accesso a tali file fisici.

Limitations

RESTORE funziona solo quando la versione di destinazione dispone ancora di tutti i file di dati necessari disponibili.

Tenere presenti questi limiti:

  • È possibile ripristinare solo le versioni i cui file di dati sono ancora presenti.
  • Se VACUUM questi file sono stati rimossi, l'operazione di ripristino non riesce.
  • La cronologia dei ripristini è governata dalle impostazioni di conservazione delta, tra cui delta.logRetentionDuratione dalla conservazione effettiva dei file di dati nell'archiviazione.
  • In pratica, sia la conservazione dei log delle transazioni che la conservazione dei file influiscono sul tempo di ripristino possibile.

Procedure consigliate

Usare queste procedure per ridurre i rischi:

  • Eseguire DESCRIBE HISTORY prima di eseguire il ripristino in modo da poter confermare la versione o il timestamp corretto.
  • Usare prima le query di spostamento temporale se è sufficiente esaminare i dati meno recenti e non si vuole modificare lo stato corrente della tabella.
  • Eseguire VACUUM dopo un ripristino quando si desidera pulire i file non referenziati dallo stato di pre-ripristino.
  • Prova prima il percorso di ripristino su una tabella clone quando lavori con dati di produzione critici.