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

Remova arquivos de dados não utilizados com Vacuum

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.

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.

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.

Alguns recursos da tabela, como vetores de exclusão, usam arquivos de metadados para marcar dados como excluídos em vez de regravar 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.

  • 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​

Para remover arquivos que não são mais necessários por versões mais antigas do que o período de retenção default, faça a execução de VACUUM sem configurações adicionais:

SQL
VACUUM table_name

Para pré-visualizar a lista de arquivos a serem excluídos sem removê-los, faça a execução de VACUUM com DRY RUN:

SQL
VACUUM table_name DRY RUN

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

Para detalhes de sintaxe de Scala, Java e Python, consulte a documentação da API do Delta Lake.

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 13.3 LTS 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 Pré-visualização Pública no Databricks Runtime 16.4 LTS e acima.

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

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

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

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

SQL
VACUUM table_name FULL

See vacuum.

Requisitos​

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.

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

Recomendações de tamanho de cluster para vacuum​

Para selecionar o tamanho correto do cluster para VACUUM, considere 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. O job compara esta lista com todos os arquivos atualmente referenciados no log de transação para identificar arquivos para exclusão. O driver fica parado durante este 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 exclusiva do driver, 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.

Frequência recomendada de 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. Definir um limite mais alto oferece acesso a uma história 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 cloud.

Vacuum e limites de retenção baixos​

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 você tiver certeza de que não há operações em execução nesta tabela que demorem mais do que o intervalo de retenção que planeja especificar, desative esta verificação de segurança definindo a configuração retentionDurationCheck Spark como false:

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

Informações de auditoria​

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

Por default, o registro de auditoria é habilitado em todas as plataformas para tabelas gerenciadas do Unity Catalog. Controle o registro de auditoria do vacuum com a configuração vacuum.logging do Spark:

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

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

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

Consulte Criar e gerenciar políticas de compute.

importante

No AWS, o registro de auditoria não está ativado por default para tabelas externas armazenadas no S3 devido às garantias de consistência limitadas que o S3 tem para gravações em multi-workspace. Para capturar informações de auditoria para tabelas externas, é preciso habilitar explicitamente esta configuração. Se você ativar o registro de auditoria para tabelas no S3, verifique se nenhum Job do Lakeflow usa gravações em multi-workspace. Deixar de fazer isso pode resultar em perda de dados.

Nesta página