Remova arquivos de dados não utilizados com vácuo

Otimização preditiva executando automaticamente VACUUM em Unity Catalog gerenciar tabelas. Databricks recomenda habilitar otimizações preditivas para todas as tabelas gerenciais do Unity Catalog para simplificar a manutenção de dados e reduzir os custos de armazenamento. Consulte Otimização preditiva para Unity Catalog gerenciar tabelas.

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

  • A exclusão de arquivos de dados não utilizados reduz os custos de armazenamento cloud .

  • Os arquivos de dados removidos por VACUUM podem conter registros que foram modificados ou excluídos. A remoção permanente desses arquivos do armazenamento cloud garante que esses registros não sejam mais acessíveis.

Advertências para o vácuo

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

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

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

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 commit essas exclusões e reescrever arquivos de dados. Consulte Limpar exclusões somente de metadados para forçar a regravação de dados.

Importante

  • Em Databricks Runtime 13.3 LTS e acima, a semântica VACUUM para clones rasos com tabelas gerenciar Unity Catalog difere de outras tabelas Delta. Veja os clones rasos do Vacuum e do Unity Catalog.

  • VACUUM remove todos os arquivos dos diretórios não gerenciados pelo Delta Lake, ignorando os diretórios que começam com _ ou .. Se você estiver armazenando metadados adicionais, como pontos de verificação de transmissão estruturada em um diretório de tabela Delta, use um nome de diretório como _checkpoints.

  • A capacidade de query versões de tabelas anteriores ao período de retenção é perdida após a execução de VACUUM.

  • os arquivos logs são excluídos automaticamente e de forma assíncrona após as operações de ponto de verificação e não são controlados por VACUUM. Embora o período de retenção default dos arquivos logs seja de 30 dias, a execução de VACUUM em uma tabela remove os arquivos de dados necessários para viagem do tempo.

Observação

Quando o cache de disco está ativado, os clusters podem conter dados de arquivos Parquet que foram excluídos com VACUUM. Portanto, pode ser possível query os dados de versões anteriores da tabela cujos arquivos foram excluídos. Reiniciar os clusters 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.

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 analisar o período de tempo especificado e identificar a versão mais recente da tabela naquele momento. A 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 a retenção de dados para consultas de viagem do tempo.

Limpar exclusões somente de metadados para forçar a reescrita de dados

O comando REORG TABLE fornece a sintaxe APPLY (PURGE) para reescrever dados para aplicar exclusões reversíveis. As exclusões temporárias não reescrevem dados ou excluem arquivos de dados, mas usam arquivos de metadados para indicar que alguns valores de dados foram alterados. Consulte TABELA REORG.

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

  • Eliminação de colunas com o mapeamento de colunas ativado.

  • Excluindo linhas com vetores de exclusão ativados.

  • Quaisquer modificações de dados em clusters habilitados para Photon quando os vetores de exclusão estiverem habilitados.

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 as passos a seguir:

  1. execuçã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 antigos que são usados para viagem do tempo.

  2. execução VACUUM para excluir esses arquivos mais antigos.

REORG TABLE cria uma nova versão da tabela à medida que as operações são concluídas. Todas as versões de tabelas na história anterior a esta transação referem-se a arquivos de dados mais antigos. Conceitualmente, isso é semelhante ao comando OPTIMIZE , em que os 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ão excluídos apenas quando expiram de acordo com o período de retenção 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 o histórico máximo que é retido.

De que tamanho clusters o vácuo precisa?

Para selecionar o tamanho correto clusters para VACUUM, é importante entender que as operações ocorrem em duas fases:

  1. A Job começa usando todos os nós executores disponíveis para listar os arquivos no diretório de origem em paralelo. Essa lista é comparada a todos os arquivos atualmente referenciados nos logs de transação Delta para identificar os arquivos a serem excluídos. O motorista fica parado durante esse tempo.

  2. O driver então emite comandos de exclusão para cada arquivo a ser excluído. A exclusão de arquivo é uma operação somente de driver, o que significa que todas as operações ocorrem em um único nó enquanto os nós de worker ficam parados.

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

  • vácuo de execução em clusters com dimensionamento automático definido para 1-4 worker, 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 as operações VACUUM estiverem excluindo regularmente mais de 10 mil arquivos ou levando mais de 30 minutos de tempo de processamento, convém aumentar o tamanho do driver ou o número de worker.

Se você descobrir que a lentidão ocorre durante a identificação de arquivos a serem removidos, inclua mais nós worker . Se a lentidão ocorrer durante a execução dos comandos de exclusão, tente aumentar o tamanho do driver.

Com que frequência você deve executar o vácuo?

A Databricks recomenda a execução regular de VACUUM em todas as tabelas para reduzir os custos excessivos de armazenamento de dados cloud . O limite de retenção default para vácuo é de 7 dias. Definir um limite mais alto dá a você 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 de seu provedor cloud .

Por que você não pode limpar uma tabela Delta com um limite de retenção baixo?

Aviso

É recomendável definir um intervalo de retenção de pelo menos 7 dias, porque Snapshot antigo e os arquivos não confirmados ainda podem estar em uso por leitores ou gravadores concorrentes na tabela. Se VACUUM limpar arquivos ativos, leitores concorrentes podem falhar ou, pior, 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 concorrente mais longa e o período mais longo que qualquer transmissão pode demorar em relação à atualização mais recente da tabela.

Delta Lake tem uma verificação de segurança para impedir que você execute um comando VACUUM perigoso. Se você tiver certeza de que não há operações sendo executadas nesta tabela que demorem mais do que o intervalo de retenção que 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ção de auditoria

VACUUM commit para os logs de transações Delta contêm informações de auditoria. Você pode query os eventos de auditoria usando DESCRIBE HISTORY.

Para capturar informações de auditoria, habilite spark.databricks.delta.vacuum.logging.enabled. O log de auditoria não é habilitado por default para tabelas AWS S3 devido às garantias limitadas de consistência fornecidas pelo S3 com relação a gravações em váriosworkspace . Se você habilitá-lo no S3, verifique se não há fluxo de trabalho que envolva gravações em váriosworkspace . Não fazer isso pode resultar em perda de dados.