Rimuovere i file di dati inutilizzati con vuoto

Rimuovere i file di dati a cui non fa più riferimento una tabella 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.

L'ottimizzazione predittiva esegue automaticamente VACUUM 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. Consulta Ottimizzazione predittiva per le tabelle gestite di Unity Catalog.

Avvertenze per il sottovuoto

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.

Alcune funzionalità della tabella, ad esempio i vettori di eliminazione, usano i file di metadati per contrassegnare i dati come eliminati anziché riscrivere i file di dati. 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, VACUUM la semantica per cloni superficiali con tabelle gestite di Unity Catalog differisce da altre tabelle. Vedi Usa VACUUM con i cloni superficiali di Unity Catalog.
  • VACUUM rimuove tutti i file dalle directory non gestite da Azure Databricks, ignorando le directory che iniziano con _ o .. Se si archiviano metadati aggiuntivi, ad esempio checkpoint di Structured Streaming, all'interno di una directory di tabella, utilizzare un nome di directory come _checkpoints.
  • La possibilità di eseguire query sulle versioni della tabella precedenti al periodo di conservazione viene persa dopo l'esecuzione di VACUUM.
  • 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.
  • 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

Per rimuovere i file non più richiesti dalle versioni precedenti al periodo di conservazione predefinito, eseguire VACUUM senza configurazioni aggiuntive:

VACUUM table_name

Per visualizzare in anteprima l'elenco dei file da eliminare senza rimuoverli, eseguire VACUUM con DRY RUN:

VACUUM table_name DRY RUN

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

Per informazioni dettagliate sulla sintassi di Scala, Java e Python, vedere la documentazione dell'API Delta Lake.

Note

In Databricks Runtime 18.0 e versioni successive, usare la deletedFileRetentionDuration proprietà della tabella per controllare la conservazione. Per le tabelle gestite di Unity Catalog, questo vale per Databricks Runtime 13.3 LTS e versioni successive.

Vedere Configurare la conservazione dei dati per le query di spostamento cronologico.

Modalità completa e lite

Importante

Questa funzionalità è disponibile in anteprima pubblica in Databricks Runtime 16.4 LTS e versioni successive.

Per migliorare le prestazioni e ridurre i costi evitando di elencare tutti i file nella directory della tabella, specifica la parola chiave LITE nell'istruzione VACUUM per attivare una modalità alternativa di VACUUM. Ciò è utile per tabelle di grandi dimensioni che richiedono operazioni frequenti VACUUM .

LITE la modalità usa il log delle transazioni per identificare i file di dati che non sono più entro la VACUUM soglia di conservazione e rimuove questi file di dati dalla tabella.

Note

L'esecuzione di VACUUM in modalità LITE non eliminerà i file a cui non viene fatto riferimento nel log delle transazioni. Ad esempio, i file creati da una transazione interrotta.

Usare la sintassi seguente per VACUUM in modalità LITE:

VACUUM table_name LITE

La modalità FULL è l'impostazione predefinita per il vuoto. È possibile eseguire in modo esplicito la modalità completa con il comando seguente:

VACUUM table_name FULL

Vedete VACUUM.

Requisiti

La modalità LITE ha i seguenti requisiti:

  • È necessario avere eseguito almeno un'operazione di VACUUM corretta entro la soglia di conservazione del log delle transazioni configurata (30 giorni per impostazione predefinita).

Se questo requisito non viene soddisfatto, quando si tenta di eseguire VACUUM in LITE modalità , viene visualizzato il messaggio di errore seguente. Per continuare, è necessario eseguire VACUUM in modalità FULL.

VACUUM <tableName> LITE cannot delete all eligible files as some files are not referenced by the log. Please run VACUUM FULL.

Purge le eliminazioni solo dei metadati per forzare la riscrittura dei dati

Il comando REORG TABLE con la sintassi APPLY (PURGE) consente di riscrivere i dati per applicare cancellazioni logiche. Le eliminazioni morbide non riscrivono i dati né eliminano i file di dati, ma piuttosto utilizzano i file di metadati per indicare che alcuni valori di dati sono stati modificati. Vedete REORG TABLE.

Le operazioni che creano eliminazioni logiche includono quanto segue:

  • Eliminazione di colonne con mappatura di colonne abilitata.
  • Eventuali modifiche ai dati con vettori di eliminazione 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 il VACUUM deve essere eseguito con un ritardo dopo il REORG per garantire che i file più vecchi siano scaduti. Il periodo di conservazione di VACUUM può essere ridotto per accorciare il tempo di attesa necessario, al costo di ridurre la cronologia massima mantenuta.

Raccomandazioni sulla dimensione del cluster per il vuoto

Per selezionare le dimensioni corrette del cluster per VACUUM, considerare 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. Il processo confronta questo elenco con tutti i file a cui si fa riferimento nel log delle transazioni per identificare i file per l'eliminazione. Il conducente rimane inattivo durante questo periodo.
  2. Il driver rilascia i comandi di eliminazione per ogni file identificato per l'eliminazione. Poiché l'eliminazione dei file è un'operazione eseguita solo dal driver, tutte le operazioni vengono eseguite su un unico nodo mentre i nodi worker restano inattivi.

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

  • Eseguire il comando 'vacuum' in un cluster con scalabilità automatica impostata da 1 a 4 worker, in cui ogni worker ha 8 core.
  • Selezionare un driver con un numero di core compreso tra 8 e 32. Aumentare le dimensioni del driver per evitare errori di esaurimento memoria.

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.

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, aumenta i costi di archiviazione del provider di servizi cloud.

Soglie del vuoto e di bassa ritenzione

Avvertimento

Databricks consiglia vivamente di impostare un intervallo di conservazione di almeno 7 giorni. Se sono presenti processi eseguiti per diversi giorni, i processi con esecuzione prolungata potrebbero scrivere file non ancora sottoposti a commit. Se il periodo di conservazione è troppo breve, VACUUM è possibile eliminare questi file di cui non è stato eseguito il commit prima del completamento del processo.

C'è un controllo di sicurezza per impedire l'esecuzione di un comando pericoloso VACUUM . Se si è certi che in questa tabella non sono in esecuzione operazioni che richiedono più tempo rispetto all'intervallo di conservazione che si prevede di specificare, disattivare questo controllo di sicurezza impostando la retentionDurationCheck configurazione di Spark su false:

Delta

SET spark.databricks.delta.retentionDurationCheck.enabled = false

Iceberg

SET spark.databricks.iceberg.retentionDurationCheck.enabled = false

Informazioni di controllo

VACUUM registra le informazioni di controllo nel log delle transazioni. Eseguire una query sugli eventi di controllo usando DESCRIBE HISTORY.

Per impostazione predefinita, la registrazione di controllo è abilitata in tutte le piattaforme per le tabelle gestite di Unity Catalog. Controllare la registrazione di controllo di VACUUM tramite la configurazione Spark vacuum.logging:

Delta

SET spark.databricks.delta.vacuum.logging.enabled = true

Iceberg

SET spark.databricks.iceberg.vacuum.logging.enabled = true

Per applicare questa configurazione per un'intera area di lavoro, in tutti i cluster usare i criteri del cluster e aggiungere quanto segue al codice JSON dei criteri:

Delta

{
  "spark_conf.spark.databricks.delta.vacuum.logging.enabled": {
    "type": "fixed",
    "value": "true"
  }
}

Iceberg

{
  "spark_conf.spark.databricks.iceberg.vacuum.logging.enabled": {
    "type": "fixed",
    "value": "true"
  }
}

Si veda Creare e gestire i criteri di calcolo

Note

La registrazione di controllo è abilitata anche per impostazione predefinita per le tabelle esterne.

  • Last updated on