Remova arquivos de dados não utilizados usando a função vacuum

Remova os arquivos de dados não mais referenciados por uma tabela e que são mais antigos que o limite de retenção executando o comando VACUUM na tabela. O uso VACUUM regularmente é importante para o custo e a conformidade por conta das seguintes considerações:

  • A exclusão dos arquivos de dados não utilizados reduz os custos de armazenamento em nuvem.
  • Os arquivos de dados removidos por VACUUM podem conter registros que foram modificados ou excluídos. A remoção permanente desses arquivos do armazenamento em nuvem garante que esses registros não estejam mais acessíveis.

Em tabelas com leituras Iceberg ativadas, VACUUM também limpa arquivos de metadados Iceberg inacessíveis. Veja VACUUMlimpeza de metadados do Iceberg.

A otimização preditiva executa VACUUM automaticamente nas tabelas gerenciadas do Unity Catalog. O Databricks recomenda habilitar as otimizações preditivas de todas as tabelas gerenciadas do Unity Catalog para simplificar a manutenção de dados e reduzir os custos de armazenamento. Consulte Otimização Preditiva para Tabelas Gerenciadas do Unity Catalog.

Advertências para vácuo

O limite de retenção padrão para arquivos de dados após a execução de VACUUM é de 7 dias. Para alterar esse comportamento, confira Configurar retenção de dados para consultas de viagem no tempo.

VACUUM pode deixar para trás diretórios vazios depois de remover todos os arquivos de dentro deles. As operações VACUUM subsequentes excluem esses diretórios vazios.

Alguns recursos de tabela, como vetores de exclusão, usam arquivos de metadados para marcar dados como excluídos em vez de reescrever arquivos de dados. Use REORG TABLE ... APPLY (PURGE) para confirmar essas exclusões e reescrever arquivos de dados. Confira Limpar exclusões somente de metadados para forçar a regeneração de dados.

Importante

  • No Databricks Runtime 13.3 LTS ou posterior, a semântica VACUUM para clones rasos com tabelas gerenciadas do Unity Catalog difere de outras tabelas. Consulte Usar VACUUM com clones superficiais do Unity Catalog.
  • VACUUM remove todos os arquivos de diretórios não gerenciados por Azure Databricks, ignorando diretórios que começam com _ ou .. Se você estiver armazenando metadados adicionais, como pontos de verificação de streaming estruturados em um diretório de tabela, use um nome de diretório como _checkpoints.
  • A capacidade de consultar versões de tabela mais antigas que o período de retenção é perdida após a execução de VACUUM.
  • Os arquivos de log são excluídos automaticamente e de forma assíncrona após operações de ponto de verificação e não são governados por VACUUM. Embora o período de retenção padrão dos arquivos de log seja de 30 dias, a execução de VACUUM em uma tabela remove os arquivos de dados necessários para viagem no tempo.
  • Quando o armazenamento em cache do disco está habilitado, um cluster pode conter dados de arquivos Parquet que foram excluídos com VACUUM. Portanto, talvez seja possível consultar os dados das versões anteriores das tabelas das quais os arquivos foram excluídos. Reiniciar o cluster remove os dados armazenados em cache. Veja Configurar o cache de disco.

Sintaxe de exemplo para o vacuum

Para remover arquivos não mais necessários por versões anteriores ao período de retenção padrão, execute VACUUM sem configurações adicionais:

VACUUM table_name

Para visualizar a lista de arquivos a serem excluídos sem removê-los, execute VACUUM com DRY RUN:

VACUUM table_name DRY RUN

Para obter detalhes da sintaxe do Spark SQL, consulte VACUUM.

Para obter detalhes de sintaxe scala, Java e Python, consulte a documentação da API delta lake.

Observação

No Databricks Runtime 18.0 e em versões posteriores, use a propriedade da tabela deletedFileRetentionDuration para controlar a retenção. Para tabelas gerenciadas do Unity Catalog, isso se aplica ao Databricks Runtime 13.3 LTS e versões posteriores.

Consulte Configurar retenção de dados para consultas de viagem no tempo.

Modo completo versus lite

Importante

Esse recurso está em Visualização Pública no Databricks Runtime 16.4 LTS e superior.

Para melhorar o desempenho e reduzir os custos, evitando listar todos os arquivos no diretório da tabela, especifique a palavra-chave LITE em seu comando VACUUM para acionar um modo alternativo de VACUUM. Isso é útil para tabelas grandes que exigem operações frequentes VACUUM .

LITE O modo usa o log de transações para identificar arquivos de dados que não estão mais dentro do VACUUM limite de retenção e remove esses arquivos de dados da tabela.

Observação

Executar VACUUM no modo LITE não excluirá nenhum arquivo que não seja referenciado no log de transações. Por exemplo, arquivos que foram criados por uma transação anulada.

Use a seguinte sintaxe para VACUUM no modo LITE:

VACUUM table_name LITE

O modo FULL é o padrão para o vácuo. Você pode executar explicitamente o modo completo com o seguinte comando:

VACUUM table_name FULL

Consulte VACUUM.

Requirements

O modo LITE tem o seguinte requisito:

  • Você deve ter executado pelo menos uma operação de VACUUM bem-sucedida dentro do limite de retenção de log de transações configurado (30 dias por padrão).

Se esse requisito não for atendido, quando você tentar executar VACUUM no LITE modo, a mensagem de erro a seguir será exibida. Para continuar, você deve executar VACUUM no modo FULL.

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

Limpar somente de metadados para forçar a regravação de dados

O REORG TABLE comando com a APPLY (PURGE) sintaxe permite que você reescreva os dados para aplicar exclusões temporárias. As exclusões temporárias não regeneram dados nem excluem arquivos de dados, mas usam arquivos de metadados para indicar que alguns valores de dados foram alterados. Consulte REORG TABLE.

As operações que criam exclusões temporárias incluem o seguinte:

  • Descartando colunas com o mapeamento de colunas habilitado.
  • Quaisquer modificações de dados com vetores de exclusão habilitados.

Com as exclusões temporárias habilitadas, os dados antigos podem permanecer fisicamente presentes nos arquivos atuais da tabela mesmo depois que os dados forem excluídos ou atualizados. Para remover fisicamente esses dados da tabela, conclua as seguintes etapas:

  1. Execute REORG TABLE ... APPLY (PURGE). Depois de fazer isso, os dados antigos não estão mais presentes nos arquivos atuais da tabela, mas ainda estão presentes nos arquivos mais antigos que são usados para viagens no tempo.
  2. Execute VACUUM para excluir esses arquivos mais antigos.

REORG TABLE cria uma nova versão da tabela à medida que a operação é concluída. Todas as versões de tabela no histórico anterior a essa transação se referem a arquivos de dados mais antigos. Conceitualmente, isso é semelhante ao comando OPTIMIZE, em que os arquivos de dados são reescritos, embora os dados na versão da tabela atual permaneçam consistentes.

Importante

Os arquivos de dados só são excluídos quando os arquivos tiverem expirado de acordo com o período de retenção de VACUUM. Isso significa que o VACUUM deve ser feito algum tempo após o REORG para garantir que os arquivos mais antigos tenham expirado. O período de retenção de VACUUM pode ser reduzido para reduzir o tempo de espera necessário, com o custo de reduzir o histórico máximo retido.

Recomendações de tamanho de cluster para vácuo

Para selecionar o tamanho VACUUMcorreto do cluster, considere que a operação ocorre em duas fases:

  1. O trabalho começa usando todos os nós de execução disponíveis para listar arquivos no diretório de origem em paralelo. O trabalho compara essa lista a todos os arquivos atualmente referenciados no log de transações para identificar arquivos para exclusão. O driver fica inativo durante esse período.
  2. O driver emite comandos de exclusão para cada arquivo identificado para exclusão. Como a exclusão de arquivos é uma operação executada apenas pelo driver, todas as operações são executadas em um único nó, enquanto os nós de trabalho ficam ociosos.

Para otimizar o custo e o desempenho, a Databricks recomenda o seguinte, especialmente para trabalhos de vácuo de longa duração:

  • Execute o comando vacuum em um cluster com dimensionamento automático definido para 1 a 4 trabalhadores, em que cada trabalhador tem 8 núcleos.
  • Selecione um driver com entre 8 e 32 núcleos. Aumente o tamanho do driver para evitar erros de memória insuficiente (OOM).

Se as operações VACUUM excluírem regularmente mais de 10 mil arquivos ou levarem mais de 30 minutos de tempo de processamento, convém aumentar o tamanho do driver ou o número de trabalhos.

Se você achar que a lentidão ocorre ao identificar os arquivos a serem removidos, adicione mais nós de trabalho. Se a desaceleração ocorrer enquanto os comandos de exclusão estiverem em execução, experimente aumentar o tamanho do driver.

O Databricks recomenda executar VACUUM regularmente em todas as tabelas para reduzir o excesso de custos de armazenamento de dados na nuvem. O limite de retenção padrão para o vacuum é de sete dias. Definir um limite mais alto oferece acesso a um histórico maior para sua tabela, mas aumenta o número de arquivos de dados armazenados e, como resultado, aumenta os custos de armazenamento do seu provedor de nuvem.

Vácuo e baixos limites de retenção

Aviso

O Databricks recomenda fortemente a definição de um intervalo de retenção de pelo menos 7 dias. Se você tiver trabalhos que são executados por vários dias, trabalhos de execução prolongada poderão criar arquivos que ainda não foram finalizados. Se o período de retenção for muito curto, VACUUM poderá excluir esses arquivos não confirmados antes que o trabalho seja concluído.

Há uma verificação de segurança para impedir que você execute um comando perigoso VACUUM . Se você tiver certeza de que não há operações em execução nesta tabela que levem mais tempo do que o intervalo de retenção que você planeja especificar, desative essa verificação de segurança definindo a configuração do retentionDurationCheck Spark como false:

Delta

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

Iceberg

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

Informações de auditoria

VACUUM grava informações de auditoria no log de transações. Consultar os eventos de auditoria usando DESCRIBE HISTORY.

Por padrão, a auditoria de registros está habilitada em todas as plataformas para tabelas gerenciadas pelo Catálogo Unity. Controlar o registro em log de auditoria de vácuo com a configuração vacuum.logging do Spark:

Delta

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

Iceberg

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

Para aplicar essa configuração a um workspace inteiro, em todos os clusters, use uma política de cluster e adicione o seguinte ao JSON da política:

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"
  }
}

Confira Criar e gerenciar políticas de computação.

Observação

O log de auditoria também está habilitado por padrão para tabelas externas.

  • Last updated on