Tamanho da tabela no Azure Databricks

O tamanho da tabela reportado para as tabelas Delta Lake e Apache Iceberg difere do tamanho total dos diretórios de ficheiros correspondentes no armazenamento de objetos na cloud. Estes formatos de dados mantêm versões anteriores dos ficheiros de dados para permitir consultas de viagem no tempo. Os ficheiros de dados só são removidos quando VACUUM é executado após ser ultrapassado o limiar de retenção. Consulte Remover arquivos de dados não utilizados com vácuo.

Por que o tamanho da tabela difere do tamanho do diretório

Os tamanhos das tabelas indicados no Azure Databricks nas interfaces de utilizador e nos comandos DESCRIBE referem-se ao tamanho total dos ficheiros de dados no armazenamento referentes aos ficheiros referenciados na versão atual da tabela. A maioria das operações de escrita em tabelas requer a reescrita dos ficheiros de dados subjacentes e preserva os ficheiros de dados antigos para permitir consultas de histórico temporal.

Nota

Se você excluir ou atualizar registros regularmente em tabelas, os vetores de exclusão podem acelerar as consultas e reduzir o tamanho total dos arquivos de dados. Ver Vetores de eliminação em Databricks.

Calcular métricas de armazenamento para uma tabela

Aplica-se a:marcado como sim Runtime Databricks 18.0 e superiores

Para perceber porque é que o tamanho total do armazenamento difere do tamanho da tabela, use ANALYZE TABLE … COMPUTE STORAGE METRICS. Este comando mostra uma divisão detalhada da alocação de armazenamento, ajudando-o a:

  • Identificar oportunidades de otimização de custos: Veja quanto armazenamento pode ser recuperado com VACUUM
  • Analisar a sobrecarga das viagens no tempo: Compreender o custo de reter dados históricos
  • Acompanhar padrões de armazenamento: Monitorize como o armazenamento em tabela evolui ao longo do tempo, executando periodicamente o comando
  • Auditar o armazenamento entre tabelas: Execute o comando num ciclo para analisar todo o seu património de dados

O comando devolve métricas abrangentes, incluindo:

  • Tamanho total do armazenamento: Área total incluindo todos os dados, metadados e registos
  • Dados ativos: Tamanho da versão atual da tabela
  • Dados recuperáveis: Espaço recuperável
  • Dados de viagem no tempo: Dados históricos para reversões

Isto é particularmente valioso para tabelas geridas pelo Unity Catalog, onde o Azure Databricks gere automaticamente o armazenamento através de otimização preditiva.

...ANALYZE TABLE COMPUTE STORAGE METRICS para sintaxe completa e exemplos.

Use a otimização preditiva para controlar o tamanho dos dados

A Databricks recomenda o uso de tabelas gerenciadas do Unity Catalog com otimização preditiva habilitada. Com tabelas geridas e otimização preditiva, o Databricks executa automaticamente os comandos OPTIMIZE e VACUUM para evitar a acumulação de ficheiros de dados não utilizados. Espere que sempre haja uma diferença de tamanho entre a versão atual de uma tabela e o tamanho total dos arquivos de dados no armazenamento de objetos na nuvem. Os ficheiros de dados não referenciados na versão atual são necessários para suportar consultas de viagem no tempo. Consulte Otimização preditiva para tabelas gerenciadas do Unity Catalog.

VACUUM Métricas de armazenamento

Quando você limpa arquivos de dados não utilizados com VACUUM ou usa DRY RUN para visualizar os arquivos definidos para remoção, as métricas relatam o número de arquivos e o tamanho dos dados removidos. O tamanho e o número de ficheiros removidos por VACUUM variam drasticamente, mas é comum que o tamanho dos ficheiros removidos ultrapasse o tamanho total da versão atual da tabela.

OPTIMIZE Métricas de armazenamento

Quando OPTIMIZE é executado em uma tabela de destino, novos arquivos de dados combinam registros de arquivos de dados existentes. As alterações cometidas durante OPTIMIZE apenas afetam a organização dos dados, e não ocorrem alterações ao conteúdo subjacente dos dados. O tamanho total dos ficheiros de dados subjacentes da tabela aumenta após a execução de OPTIMIZE, porque os novos ficheiros compactados coexistem no diretório que os contém com os antigos ficheiros de dados não otimizados.

O tamanho da tabela relatada após OPTIMIZE geralmente é menor do que o tamanho antes de OPTIMIZE ser executado, porque o tamanho total dos arquivos de dados referenciados pela versão atual da tabela diminui com a compactação de dados. Para remover os ficheiros de dados subjacentes, VACUUM deve ser executado depois de o limiar de retenção ser ultrapassado.

Nota

Você pode ver métricas semelhantes para operações como REORG TABLE ou DROP FEATURE. Todas as operações que exigem a regravação de arquivos de dados aumentam o tamanho total dos dados no diretório que contém até VACUUM remove os arquivos de dados que não são mais referenciados na versão da tabela atual.