Remover ficheiros de dados não utilizados com o VACUUM

  • Artigo

A otimização preditiva é executada VACUUM automaticamente em tabelas gerenciadas pelo 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.

Você pode remover arquivos de dados não mais referenciados por uma tabela Delta que são mais antigos do que o limite de retenção executando o VACUUM comando na tabela. Executar VACUUM regularmente é importante para o custo e a conformidade devido às seguintes considerações:

  • A exclusão de 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 VACUUM é de 7 dias. Para alterar esse comportamento, consulte Configurar a 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 subsequentes VACUUM excluem esses diretórios vazios.

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

Alguns recursos do Delta Lake usam arquivos de metadados para marcar dados como excluídos em vez de reescrever arquivos de dados. Você pode usar REORG TABLE ... APPLY (PURGE) para confirmar essas exclusões e reescrever arquivos de dados. Consulte Limpar exclusões somente de metadados para forçar a regravaçã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 superficiais do Vacuum e do Unity Catalog.
  • VACUUM remove todos os arquivos de diretórios não gerenciados pelo Delta Lake, ignorando diretórios começando 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 anteriores ao período de retenção é perdida após a execução VACUUMdo .
  • Os arquivos de log são excluídos automaticamente e de forma assíncrona após as operações do ponto de verificação e não são controlados pelo VACUUM. Embora o período de retenção padrão dos arquivos de log seja de 30 dias, a execução VACUUM em uma tabela remove os arquivos de dados necessários para a viagem no tempo.

Nota

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

Exemplo de sintaxe para vácuo

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 da sintaxe do Spark SQL, consulte VACUUM.

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

Nota

Use a RETAIN palavra-chave para especificar o limite usado para determinar se um arquivo de dados deve ser removido. O VACUUM comando usa esse limite para olhar para trás no tempo a quantidade de tempo especificada e identificar a versão mais recente da tabela naquele momento. O 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 exclusões somente de metadados para forçar a regravação de dados

O REORG TABLE comando fornece a APPLY (PURGE) sintaxe para reescrever dados para aplicar exclusões suaves. As exclusões suaves não reescrevem dados ou excluem arquivos de dados, mas usam arquivos de metadados para indicar que alguns valores de dados foram alterados. Ver REORG TABLE.

As operações que criam exclusões suaves no Delta Lake incluem o seguinte:

  • Soltar colunas com mapeamento de colunas habilitado.
  • Exclusão de linhas com vetores de exclusão habilitados.
  • Quaisquer modificações de dados em clusters habilitados para Fóton quando vetores de exclusão estão habilitados.

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

  1. Execute o 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 esta transação referem-se a arquivos de dados mais antigos. Conceitualmente, isso é semelhante ao comando, onde os OPTIMIZE arquivos de dados são reescritos mesmo 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 VACUUM retenção. 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 o histórico máximo que é mantido.

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

Para selecionar o tamanho correto do cluster para VACUUMo , ele ajuda a entender que a operação ocorre em duas fases:

  1. O trabalho começa usando todos os nós executores 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 motorista fica parado durante esse tempo.
  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 de 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 vácuo em um cluster com dimensionamento automático definido para 1-4 trabalhadores, onde 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 falta de memória (OOM).

Se VACUUM as operações excluem regularmente mais de 10 mil arquivos ou levam mais de 30 minutos de tempo de processamento, convém aumentar o tamanho do driver ou o número de trabalhadores.

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

Com que frequência deve correr a vácuo?

O Databricks recomenda a execução VACUUM regular em todas as tabelas para reduzir os custos excessivos de armazenamento de dados na nuvem. O limite de retenção padrão para vácuo é de 7 dias. Definir um limite mais alto dá-lhe acesso a um histórico maior para a sua tabela, mas aumenta o número de ficheiros de dados armazenados e, como resultado, incorre em maiores custos de armazenamento do seu fornecedor de nuvem.

Por que você não pode aspirar uma mesa Delta com um baixo limiar de retenção?

Aviso

É recomendável definir 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 na tabela. Se VACUUM limpar arquivos ativos, leitores simultâneos podem falhar ou, pior, tabelas podem ser corrompidas quando VACUUM exclui arquivos que ainda não foram confirmados. Tem de escolher um intervalo mais longo do que a transação simultânea de execução prolongada e o período mais longo em que qualquer fluxo pode ficar aquém da atualização mais recente para a tabela.

Delta Lake tem uma verificação de segurança para evitar que você execute um comando perigoso VACUUM . Se tiver certeza de que não há operações sendo executadas nesta tabela que levem mais do que o intervalo de retenção que você planeja especificar, você pode desativar essa verificação de segurança definindo a propriedade spark.databricks.delta.retentionDurationCheck.enabled de configuração do Spark como false.

Informações de auditoria

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