Condividi tramite


Dimensioni delle tabelle in Azure Databricks

Le dimensioni della tabella segnalate per le tabelle supportate da Delta Lake in Azure Databricks differiscono dalle dimensioni totali delle directory di file corrispondenti nell'archiviazione di oggetti cloud. Questo articolo illustra perché questa differenza esiste e raccomandazioni per controllare i costi.

Perché le dimensioni della tabella Delta non corrispondono alle dimensioni della directory?

Le dimensioni delle tabelle segnalate in Azure Databricks tramite interfacce utente e comandi DESCRIBE fanno riferimento alle dimensioni totali dei file di dati su disco per tali file a cui si fa riferimento nella versione corrente della tabella Delta. La maggior parte delle operazioni che scrivono in tabelle richiede la riscrittura dei file di dati sottostanti, ma i file di dati precedenti vengono conservati per un periodo di tempo per supportare le query di spostamento del tempo.

Nota

Se si eliminano o aggiornano regolarmente i record nelle tabelle, i vettori di eliminazione possono accelerare le query e ridurre le dimensioni totali dei file di dati. Si veda Che cosa sono i vettori di eliminazione?.

Calcolare le metriche di archiviazione per una tabella

Si applica a:check contrassegnato come sì Databricks Runtime 18.0 e versioni successive

Per comprendere perché le dimensioni di archiviazione totali differiscono dalle dimensioni della tabella, usare ANALYZE TABLE … COMPUTE STORAGE METRICS. Questo comando fornisce una suddivisione dettagliata dell'allocazione dell'archiviazione, che consente di:

  • Identificare le opportunità di ottimizzazione dei costi: vedere quanto spazio di archiviazione può essere recuperato con VACUUM
  • Analizzare il sovraccarico del viaggio nel tempo: comprendere il costo di conservazione dei dati cronologici
  • Tenere traccia dei modelli di archiviazione: monitorare l'evoluzione dell'archiviazione tabelle nel tempo eseguendo periodicamente il comando
  • Controllare l'archiviazione tra tabelle: eseguire il comando in un ciclo per analizzare l'intero patrimonio di dati

Il comando restituisce metriche complete, tra cui:

  • Dimensioni totali di archiviazione: Ingombro complessivo, inclusi dati, metadati e log
  • Dati attivi: dimensioni della versione corrente della tabella
  • Dati recuperabili: spazio che può essere recuperato
  • Dati di spostamento temporale: dati cronologici per i rollback

Ciò è particolarmente utile per le tabelle gestite di Unity Catalog in cui Azure Databricks gestisce automaticamente l'archiviazione tramite l'ottimizzazione predittiva.

Vedere COMPUTE STORAGE METRICS per sintassi ed esempi completi.

Usare l'ottimizzazione predittiva per controllare le dimensioni dei dati

Databricks consiglia di usare tabelle gestite di Unity Catalog con l'ottimizzazione predittiva abilitata. Con le tabelle gestite e l'ottimizzazione predittiva, Databricks esegue automaticamente i comandi OPTIMIZE e VACUUM per impedire l'accumulo di file di dati inutilizzati. Ci si aspetta che ci sia sempre una differenza di dimensione tra la versione corrente di una tabella e le dimensioni totali dei file di dati nell'archiviazione di oggetti cloud. Ciò è dovuto al fatto che i file di dati non a cui si fa riferimento nella versione corrente sono necessari per supportare le query di spostamento temporale. Consulta Ottimizzazione predittiva per le tabelle gestite di Unity Catalog.

Quali metriche dei VACUUM file vengono report?

Quando si puliscono i file di dati inutilizzati con VACUUM o si usa DRY RUN per visualizzare in anteprima i file impostati per la rimozione, le metriche segnalano il numero di file e le dimensioni dei dati rimossi. Le dimensioni e il numero di file rimossi da VACUUM variano drasticamente, ma non è raro che le dimensioni dei file rimossi superino le dimensioni totali della versione corrente della tabella.

Quali metriche dei OPTIMIZE file vengono report?

Quando OPTIMIZE viene eseguito in una tabella di destinazione, i nuovi file di dati combinano i record dei file di dati esistenti. Modifiche di cui è stato eseguito il commit durante OPTIMIZE solo l'organizzazione dei dati di impatto e non vengono apportate modifiche al contenuto dei dati sottostanti. Le dimensioni totali dei file di dati associati alla tabella aumentano dopo l'esecuzione di OPTIMIZE, perché i nuovi file compattati coesistono nella directory contenitore con i file di dati a cui non si fa più riferimento.

Le dimensioni della tabella segnalate dopo OPTIMIZE sono in genere inferiori alle dimensioni prima dell'esecuzione di OPTIMIZE, perché le dimensioni totali dei file di dati a cui fa riferimento la versione corrente della tabella diminuiscono con la compattazione dei dati. VACUUM deve essere eseguito dopo il superamento della soglia di conservazione per rimuovere i file di dati sottostanti.

Nota

È possibile che vengano visualizzate metriche simili per operazioni come REORG TABLE o DROP FEATURE. Tutte le operazioni che richiedono la riscrittura dei file di dati aumentano le dimensioni totali dei dati nella directory contenitore fino a quando VACUUM rimuove i file di dati a cui non si fa più riferimento nella versione della tabella corrente.