Pular para o conteúdo principal
Última atualização em

Remova arquivos de dados não utilizados com Vacuum

A otimização preditiva executa automaticamente VACUUM para tabelas gerenciadas do Unity Catalog. O Databricks recomenda habilitar otimizações preditivas para 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.

Remover arquivos de dados não mais referenciados por uma tabela que são mais antigos do que o limite de retenção, executando o comando VACUUM na tabela. Executar VACUUM regularmente é importante para o custo e compliance devido às seguintes considerações:

  • A exclusão de arquivos de dados não utilizados reduz os custos de armazenamento em nuvem.
  • Arquivos de dados removidos por VACUUM podem conter registros que foram modificados ou excluídos. A exclusão permanente destes arquivos do armazenamento em nuvem garante que estes registros não sejam mais acessíveis.

Ressalvas para vacuum​

O limite de retenção default para arquivos de dados após a execução de VACUUM é de sete dias. Para alterar este comportamento, consulte Configurar a retenção de dados para consultas de viagem do tempo.

VACUUM Pode deixar diretórios vazios depois de remover todos os arquivos de seu interior. As operações VACUUM subsequentes excluem esses diretórios vazios.

A Databricks recomenda o uso da otimização preditiva para execução automaticamente VACUUM para tabelas. Consulte Otimização preditiva para tabelas gerenciadas do Unity Catalog.

Alguns recursos da tabela utilizam arquivos de metadados para marcar dados como excluídos em vez de reescrever arquivos de dados. Use REORG TABLE ... APPLY (PURGE) para fazer o commit dessas exclusões e regravar arquivos de dados. Consulte Limpar exclusões somente de metadados para forçar a reescrita de dados.

importante

  • No Databricks Runtime 13.3 LTS e acima, a semântica VACUUM para clones rasos com tabelas gerenciadas Unity Catalog difere de outras tabelas. Consulte Usar VACUUM com clones rasos do Unity Catalog.

  • VACUUM Remove todos os arquivos dos diretórios não gerenciados pelo Databricks, ignorando os diretórios que começam com _ ou .. Caso se armazenem metadados adicionais, como pontos de verificação de transmissão estructurada, em um diretório de tabela, utilize um nome de diretório como _checkpoints.

  • A capacidade de consultar versões da tabela mais antigas do que o período de retenção é perdida após executar VACUUM.

  • Arquivos de log são excluídos automática e assincronamente após operações de ponto de verificação e não são governados por VACUUM. Enquanto o período de retenção default de arquivos de log é de 30 dias, a execução de VACUUM em uma tabela remove os arquivos de dados necessários para a viagem do tempo.

nota

Quando o cache em disco está ativado, um cluster pode conter dados de arquivos Parquet que foram excluídos com VACUUM. Portanto, pode ser possível consultar os dados de versões anteriores de tabelas cujos arquivos foram excluídos. A reinicialização do cluster removerá os dados armazenados em cache. Consulte Configurar o cache em disco.

Exemplo de sintaxe para VACUUM​

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

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

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

Consulte a documentação da API do Delta Lake para obter detalhes de sintaxe de Scala, Java e Python.

nota

No Databricks Runtime 18.0 e acima, use a propriedade de tabela deletedFileRetentionDuration para controlar a retenção. Para tabelas gerenciadas pelo Unity Catalog, isso se aplica ao Databricks Runtime 12.2 e acima.

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

Modo completo versus modo leve​

info

Visualização

Este recurso está em Visualização pública no Databricks Runtime 16.1 e acima.

Você pode especificar a palavra-chave LITE na sua instrução VACUUM para acionar um modo alternativo de VACUUM que evita listar todos os arquivos no diretório da tabela.

LITE o modo utiliza o log de transações para identificar arquivos de dados que não estão mais dentro do limite de retenção VACUUM e remove esses arquivos de dados da tabela. O modo LITE é especialmente útil para tabelas grandes que requerem operações VACUUM frequentes, pois evita a necessidade de listar todos os arquivos para identificar esses arquivos de dados a serem removidos.

nota

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 interrompida.

Use a sintaxe a seguir para VACUUM no modo LITE:

SQL
VACUUM table_name LITE

LITE O modo tem o seguinte requisito:

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

Se este requisito não for cumprido, quando o senhor tentar executar VACUUM no modo LITE, a seguinte mensagem de erro é exibida. Para continuar, é preciso 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.

FULL Modo é o default para vacuum. Você pode executar explicitamente o modo completo com o seguinte comando:

SQL
VACUUM table_name FULL

See vacuum.

Limpar exclusões que afetam apenas os metadados para forçar a reescrita de dados​

O comando REORG TABLE com a sintaxe APPLY (PURGE) permite reescrever dados para aplicar exclusões suaves. Exclusões reversíveis não reescrevem dados nem excluem arquivos de dados, mas sim usam arquivos de metadados para indicar que alguns valores de dados foram alterados. See REORG TABLE.

Operações que criam exclusões lógicas incluem o seguinte:

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

Com as exclusões reversíveis ativadas, os dados antigos podem permanecer fisicamente presentes nos arquivos atuais da tabela, mesmo depois que os dados forem excluídos ou atualizados. Para remover esses dados fisicamente da tabela, conclua os passos a seguir:

  1. Execute REORG TABLE ... APPLY (PURGE). Após isso, os dados antigos não se encontram mais presentes nos arquivos atuais da tabela, mas ainda se encontram nos arquivos mais antigos que são usados para viagem do tempo.
  2. Execute VACUUM para excluir esses arquivos mais antigos.

REORG TABLE cria uma nova versão da tabela ao concluir a operação. Todas as versões da tabela no histórico anteriores a esta transação se referem a arquivos de dados mais antigos. Conceitualmente, isso é semelhante ao OPTIMIZE comando, onde arquivos de dados são reescritos, ainda que os dados na versão atual da tabela permaneçam consistentes.

importante

Os arquivos de dados só são excluídos quando os arquivos expiraram de acordo com o período de retenção de VACUUM. Isso significa que o VACUUM deve ser feito com um atraso após o REORG para que os arquivos mais antigos tenham expirado. O período de retenção de VACUUM pode ser reduzido para encurtar o tempo de espera necessário, ao custo de reduzir a história máxima que é retida.

Qual o tamanho de cluster o vacuum precisa?​

Para selecionar o tamanho correto do cluster para VACUUM, é útil entender que a operação ocorre em duas fases:

  1. O job inicia-se utilizando todos os nós executores disponíveis para listar arquivos no diretório de origem em paralelo. Esta lista é comparada com todos os arquivos referenciados atualmente no log de transação para identificar arquivos a serem excluídos. O driver fica parado durante este período.
  2. O driver em seguida emite comandos de exclusão para cada arquivo a ser excluído. Exclusão de arquivos é uma operação somente do driver, significando que todas as operações ocorrem em um único nó enquanto os nós worker ficam parados.

Para otimizar o custo e o desempenho, a Databricks recomenda o seguinte, especialmente para jobs de vacuum de longa duração:

  • Executar o vacuum em um cluster com autoescalonamento configurado para 1–4 workers, onde cada worker tem 8 núcleos.
  • Selecione um driver com entre 8 e 32 núcleos. Aumente o tamanho do driver para evitar erros de falta de memória (OOM).

Se VACUUM operações estiverem excluindo regularmente mais de 10 mil arquivos ou levando mais de 30 minutos de tempo de processamento, talvez seja interessante aumentar o tamanho do driver ou o número de workers.

Se for constatado que a lentidão ocorre durante a identificação de arquivos a serem removidos, recomenda-se adicionar mais nós worker. Se a lentidão ocorrer enquanto comandos de exclusão estiverem em execução, tente aumentar o tamanho do driver.

Com que frequência deve-se executar VACUUM?​

O Databricks recomenda executar VACUUM regularmente em todas as tabelas para reduzir o excesso de custos de armazenamento de dados em cloud. O limite de retenção default para vacuum é de 7 dias. Configurar um limite mais alto proporciona acesso a um histórico maior para sua tabela, mas aumenta o número de arquivos de dados armazenados e, como resultado, incorre em maiores custos de armazenamento do seu provedor de cloud.

Por que não é possível fazer VACUUM em uma tabela com um limite de retenção baixo?​

atenção

A Databricks recomenda enfaticamente definir um intervalo de retenção de pelo menos 7 dias. Para jobs que são executados por vários dias, jobs de execução longa podem gravar arquivos que ainda não foram confirmados. Se o seu período de retenção for muito curto, VACUUM poderia excluir esses arquivos não confirmados antes que o Job seja concluído.

Há uma verificação de segurança para impedir a execução de um comando VACUUM perigoso. Se tiver certeza de que nenhuma operação está sendo executada nesta tabela que leve mais tempo do que o intervalo de retenção que você planeja especificar, desative esta verificação de segurança, definindo a propriedade de configuração do Spark spark.databricks.delta.retentionDurationCheck.enabled (Delta) ou spark.databricks.iceberg.retentionDurationCheck.enabled (Iceberg) como false.

Informações de auditoria​

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

O registro de auditoria de Vacuum é controlado por configurações no nível do workspace spark.databricks.delta.vacuum.logging.enabled (Delta) ou spark.databricks.iceberg.vacuum.logging.enabled (Iceberg). Por padrão, o registro de auditoria está habilitado em todas as plataformas para tabelas gerenciadas do Unity Catalog.

importante

Na AWS, o registro de auditoria não está habilitado por default para tabelas externas armazenadas no S3 devido às garantias de consistência limitadas fornecidas pelo S3 em relação às gravações em vários workspaces. Para capturar informações de auditoria para tabelas externas, é preciso habilitar explicitamente esta configuração. Se você habilitar o log de auditoria para tabelas no S3, certifique-se de que não haja Jobs do LakeFlow que envolvam gravações em vários workspaces. Não fazê-lo pode resultar em perda de dados.

Nesta página