Compartilhar via

Remover arquivos de dados não utilizados com o vacuum

  • Artigo

A otimização preditiva executa automaticamente VACUUM 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 Catálogo do Unity.

Você pode remover arquivos de dados que não são mais referenciados por uma tabela Delta que são mais antigos do que o limite de retenção executando o comando VACUUM na tabela. A execução VACUUM regularmente é importante para o custo e a conformidade devido às 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.

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.

O Databricks recomenda usar a otimização preditiva para executar VACUUM automaticamente para as tabelas Delta. Consulte Otimização preditiva para tabelas gerenciadas do Catálogo do Unity.

Alguns recursos do Delta Lake usam arquivos de metadados para marcar os dados como excluídos, em vez de reescrever os arquivos de dados. Você pode usar REORG TABLE ... APPLY (PURGE) para confirmar essas exclusões e regenerar 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 e superior, VACUUM a semântica para clones superficiais com tabelas gerenciadas do Unity Catalog difere de outras tabelas Delta. Consulte Clones shallow do Vacuum e do Catálogo do Unity.
  • VACUUM remove todos os arquivos de diretórios não gerenciados pelo Delta Lake, ignorando diretórios que começam com _ ou .. Se você estiver armazenando metadados adicionais, como pontos de verificação de Streaming Estruturado em um diretório de tabela Delta, 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.

Observação

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

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

VACUUM table_name RETAIN 100 HOURS  -- vacuum files not required by versions more than 100 hours old

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

Para obter detalhes de sintaxe do Spark SQL, confira VACUUM.

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

Observação

Use a palavra-chave RETAIN para especificar o limite usado para determinar se um arquivo de dados deve ser removido. O comando VACUUM usa esse limite para examinar o tempo especificado e identificar a versão mais recente da tabela nesse momento. Delta retém todos os arquivos de dados necessários para consultar essa versão da tabela e todas as versões mais recentes da tabela. Essa configuração interage com outras propriedades da tabela. Consulte Configurar retenção de dados para consultas de viagem no tempo

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

O comando REORG TABLEfornece a sintaxeAPPLY (PURGE) para regenerar os dados e 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 a TABELA REORG .

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

  • Removendo colunas com o mapeamento de colunas habilitado.
  • Excluindo linhas com os vetores de exclusão habilitados.
  • Quaisquer modificações de dados em clusters habilitados para Photon quando os vetores de exclusão estiverem habilitados.

Com a exclusão temporária ativada, os dados antigos podem permanecer fisicamente presentes nos arquivos atuais da tabela mesmo após a exclusão ou atualização dos dados. 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 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 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 reduzir o tempo de espera necessário, com o custo de reduzir o histórico máximo retido.

Qual é o tamanho do cluster que o vácuo precisa?

Para selecionar o tamanho correto do cluster para VACUUM, é útil reconhecer 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. Essa lista é comparada a todos os arquivos atualmente referenciados no log de transações Delta para identificar os arquivos a serem excluídos. O driver fica inativo durante esse período.
  2. Em seguida, o driver emite comandos de exclusão para cada arquivo a ser excluído. A exclusão de arquivos é uma operação somente do driver, o que significa que todas as operações ocorrem 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 vácuo em um cluster com dimensionamento automático definido para 1 a 4 trabalhos, em que cada trabalho 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.

Com que frequência você deve executar o vacuum?

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 fornece acesso a um histórico maior para a tabela, mas aumenta o número de arquivos de dados armazenados e, como resultado, gera custos de armazenamento maiores no provedor de nuvem.

Por que você não consegue executar o vacuum em uma tabela Delta com um limite de retenção baixo?

Aviso

É recomendável que você defina um intervalo de retenção de pelo menos 7 dias, porque instantâneos antigos e arquivos não confirmados ainda podem estar em uso por leitores ou gravadores simultâneos. Se VACUUM limpa arquivos ativos, os leitores simultâneos podem experimentar falhas ou, pior, as tabelas podem ser corrompidas quando VACUUM exclui arquivos que ainda não foram confirmados. Você deve escolher um intervalo maior do que a transação simultânea em execução mais longa, e o período mais longo que os fluxos de dados podem ficar atrasados em relação à atualização mais recente da tabela.

O Delta Lake tem uma verificação de segurança para impedir que você execute um comando perigoso VACUUM. Se tem certeza de que nenhuma operação em execução nessa tabela vai demorar mais do que o intervalo de retenção que você planeja especificar, desative essa verificação de segurança definindo a propriedade de configuração do Spark spark.databricks.delta.retentionDurationCheck.enabled como false.

Informações de auditoria

Os commits de VACUUM no log de transações do Delta contêm informações de auditoria. Você pode consultar os eventos de auditoria usando DESCRIBE HISTORY.