Condividi tramite

Rimuovere i file di dati inutilizzati con vuoto

  • Articolo

L'ottimizzazione predittiva viene eseguita VACUUM automaticamente nelle tabelle gestite di Unity Catalog. Databricks consiglia di abilitare le ottimizzazioni predittive per tutte le tabelle gestite di Unity Catalog per semplificare la manutenzione dei dati e ridurre i costi di archiviazione. Vedere Ottimizzazione predittiva per le tabelle gestite di Unity Catalog.

È possibile rimuovere i file di dati a cui non fa più riferimento una tabella Delta precedente alla soglia di conservazione eseguendo il VACUUM comando nella tabella. L'esecuzione VACUUM regolare è importante per i costi e la conformità a causa delle considerazioni seguenti:

  • L'eliminazione di file di dati inutilizzati riduce i costi di archiviazione cloud.
  • I file di dati rimossi da VACUUM possono contenere record modificati o eliminati. Rimuovendo definitivamente questi file dall'archiviazione cloud, questi record non sono più accessibili.

Avvertenze per il vuoto

La soglia di conservazione predefinita per i file di dati dopo l'esecuzione VACUUM è di 7 giorni. Per modificare questo comportamento, vedere Configurare la conservazione dei dati per le query di spostamento del tempo.

VACUUM potrebbe lasciare le directory vuote dopo aver rimosso tutti i file dall'interno di essi. Le operazioni successive VACUUM eliminano queste directory vuote.

Databricks consiglia di usare l'ottimizzazione predittiva per l'esecuzione VACUUM automatica per le tabelle Delta. Vedere Ottimizzazione predittiva per le tabelle gestite di Unity Catalog.

Alcune funzionalità di Delta Lake usano i file di metadati per contrassegnare i dati come eliminati anziché riscrivere i file di dati. È possibile usare REORG TABLE ... APPLY (PURGE) per eseguire il commit di queste eliminazioni e riscrivere i file di dati. Per forzare la riscrittura dei dati, vedere Eliminare solo i metadati.

Importante

  • In Databricks Runtime 13.3 LTS e versioni successive la VACUUM semantica per cloni superficiali con tabelle gestite di Unity Catalog differiscono da altre tabelle Delta. Vedere Vacuum and Unity Catalog shallow clones (Cloni superficiali di Vacuum e Unity Catalog).
  • VACUUM rimuove tutti i file dalle directory non gestite da Delta Lake, ignorando le directory che iniziano con _ o .. Se si archiviano metadati aggiuntivi, ad esempio checkpoint structured streaming all'interno di una directory di tabella Delta, usare un nome di directory, _checkpointsad esempio .
  • La possibilità di eseguire query sulle versioni della tabella precedenti al periodo di conservazione viene persa dopo l'esecuzione VACUUMdi .
  • I file di log vengono eliminati automaticamente e in modo asincrono dopo le operazioni di checkpoint e non sono regolati da VACUUM. Mentre il periodo di conservazione predefinito dei file di log è di 30 giorni, l'esecuzione VACUUM in una tabella rimuove i file di dati necessari per il viaggio nel tempo.

Nota

Quando la memorizzazione nella cache del disco è abilitata, un cluster potrebbe contenere dati da file Parquet eliminati con VACUUM. Pertanto, potrebbe essere possibile eseguire query sui dati delle versioni precedenti della tabella i cui file sono stati eliminati. Il riavvio del cluster rimuoverà i dati memorizzati nella cache. Vedere Configurare la cache del disco.

Sintassi di esempio per vacuum

VACUUM table_name   -- vacuum files not required by versions older than the default retention period

VACUUM table_name RETAIN 100 HOURS  -- vacuum files not required by versions more than 100 hours old

VACUUM table_name DRY RUN    -- do dry run to get the list of files to be deleted

Per informazioni dettagliate sulla sintassi di Spark SQL, vedere VACUUM.

Vedere la documentazione dell'API Delta Lake per informazioni dettagliate sulla sintassi Scala, Java e Python.

Nota

Usare la RETAIN parola chiave per specificare la soglia utilizzata per determinare se è necessario rimuovere un file di dati. Il VACUUM comando usa questa soglia per esaminare in tempo la quantità di tempo specificata e identificare la versione della tabella più recente in quel momento. Delta mantiene tutti i file di dati necessari per eseguire query sulla versione della tabella e su tutte le versioni più recenti della tabella. Questa impostazione interagisce con altre proprietà della tabella. Vedere Configurare la conservazione dei dati per le query di spostamento del tempo.

Elimina solo i metadati per forzare la riscrittura dei dati

Il REORG TABLE comando fornisce la APPLY (PURGE) sintassi per riscrivere i dati per applicare eliminazioni temporanea. Le eliminazioni non riscrivono i dati o eliminano i file di dati, ma usano i file di metadati per indicare che alcuni valori di dati sono stati modificati. Vedere TABELLA REORG.

Le operazioni che creano eliminazioni temporanea in Delta Lake includono quanto segue:

  • Eliminazione di colonne con mapping di colonne abilitato.
  • Eliminazione di righe con vettori di eliminazione abilitati.
  • Eventuali modifiche ai dati nei cluster abilitati per Photon quando i vettori di eliminazione sono abilitati.

Con le eliminazioni temporaneamente abilitate, i dati precedenti possono rimanere fisicamente presenti nei file correnti della tabella anche dopo l'eliminazione o l'aggiornamento dei dati. Per rimuovere questi dati fisicamente dalla tabella, seguire questa procedura:

  1. Eseguire REORG TABLE ... APPLY (PURGE). Dopo aver eseguito questa operazione, i dati precedenti non sono più presenti nei file correnti della tabella, ma sono ancora presenti nei file meno recenti usati per il viaggio nel tempo.
  2. Eseguire VACUUM per eliminare questi file meno recenti.

REORG TABLE crea una nuova versione della tabella al termine dell'operazione. Tutte le versioni della tabella nella cronologia precedenti a questa transazione fanno riferimento ai file di dati meno recenti. Concettualmente, questo è simile al OPTIMIZE comando, in cui i file di dati vengono riscritti anche se i dati nella versione della tabella corrente rimangono coerenti.

Importante

I file di dati vengono eliminati solo quando i file sono scaduti in base al VACUUM periodo di conservazione. Ciò significa che l'oggetto VACUUM deve essere eseguito con un ritardo dopo l'oggetto REORG in modo che i file meno recenti siano scaduti. Il periodo di conservazione di può essere ridotto per ridurre il tempo di VACUUM attesa necessario, riducendo la cronologia massima mantenuta.

Quali dimensioni sono necessarie per il cluster vacuum?

Per selezionare le dimensioni corrette del cluster per VACUUM, è utile comprendere che l'operazione si verifica in due fasi:

  1. Il processo inizia usando tutti i nodi executor disponibili per elencare i file nella directory di origine in parallelo. Questo elenco viene confrontato con tutti i file a cui si fa attualmente riferimento nel log delle transazioni Delta per identificare i file da eliminare. Il conducente rimane inattiva durante questo periodo.
  2. Il driver rilascia quindi i comandi di eliminazione per ogni file da eliminare. L'eliminazione di file è un'operazione solo driver, ovvero tutte le operazioni si verificano in un singolo nodo mentre i nodi di lavoro si trovano inattive.

Per ottimizzare i costi e le prestazioni, Databricks consiglia quanto segue, in particolare per i processi vacuum a esecuzione prolungata:

  • Eseguire vacuum in un cluster con un set di scalabilità automatica per 1-4 ruoli di lavoro, in cui ogni ruolo di lavoro ha 8 core.
  • Selezionare un driver con una lunghezza compresa tra 8 e 32 core. Aumentare le dimensioni del driver per evitare errori di memoria insufficiente.

Se VACUUM le operazioni eliminano regolarmente più di 10 mila file o richiedono più di 30 minuti di tempo di elaborazione, è possibile aumentare le dimensioni del driver o il numero di ruoli di lavoro.

Se si rileva che il rallentamento si verifica durante l'identificazione dei file da rimuovere, aggiungere altri nodi di lavoro. Se il rallentamento si verifica durante l'esecuzione dei comandi di eliminazione, provare ad aumentare le dimensioni del driver.

Con quale frequenza è consigliabile eseguire il vuoto?

Databricks consiglia di eseguire VACUUM regolarmente su tutte le tabelle per ridurre i costi di archiviazione dei dati cloud in eccesso. La soglia di conservazione predefinita per il vuoto è di 7 giorni. L'impostazione di una soglia più elevata consente di accedere a una cronologia maggiore per la tabella, ma aumenta il numero di file di dati archiviati e, di conseguenza, comporta costi di archiviazione maggiori dal provider di servizi cloud.

Perché non è possibile eseguire il vuoto di una tabella Delta con una soglia di conservazione bassa?

Avviso

È consigliabile impostare un intervallo di conservazione di almeno 7 giorni, perché gli snapshot precedenti e i file di cui non è stato eseguito il commit possono essere ancora in uso da lettori o writer simultanei alla tabella. Se VACUUM pulisce i file attivi, i lettori simultanei possono avere esito negativo o, peggio, le tabelle possono essere danneggiate quando VACUUM elimina i file non ancora sottoposti a commit. È necessario scegliere un intervallo più lungo rispetto alla transazione simultanea più lunga e il periodo più lungo per cui qualsiasi flusso può essere ritardato rispetto all'aggiornamento più recente della tabella.

Delta Lake ha un controllo di sicurezza per impedire l'esecuzione di un comando pericoloso VACUUM . Se si è certi che non sono state eseguite operazioni su questa tabella che richiedono più tempo dell'intervallo di conservazione che si prevede di specificare, è possibile disattivare questo controllo di sicurezza impostando la proprietà spark.databricks.delta.retentionDurationCheck.enabled di configurazione spark su false.

Informazioni di controllo

VACUUM i commit nel log delle transazioni Delta contengono informazioni di controllo. È possibile eseguire query sugli eventi di controllo usando DESCRIBE HISTORY.