Remover arquivos de dados não utilizados com o vacuum
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.
O senhor pode remover os arquivos de dados que não são mais referenciados por uma tabela Delta e 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 para compliance 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 pelo
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 vacuum
O limite de retenção de 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 consultas de viagem do tempo.
VACUUM
pode deixar para trás diretórios vazios após remover todos os arquivos de dentro deles. As operações subsequentes do site VACUUM
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. O senhor pode usar REORG TABLE ... APPLY (PURGE)
para commit essas exclusões e reescrever os arquivos de dados. Consulte Eliminar exclusões somente de metadados para forçar a regravação dos dados.
-
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. Consulte vacuum e Unity Catalog clones rasos. -
VACUUM
remove todos os arquivos dos diretórios não gerenciados por Delta Lake, ignorando os diretórios que começam com_
ou.
. Se o senhor estiver armazenando metadados adicionais, como pontos de verificação de transmissão estruturada, em um diretório da tabela Delta, use um nome de diretório como_checkpoints
.- Os dados para o feed de dados de alteração são gerenciados por Delta Lake no diretório
_change_data
e removidos comVACUUM
. Consulte Usar o feed de dados de alterações do Delta Lake na Databricks. - Os índices de filtro Bloom usam o diretório
_delta_index
gerenciado por Delta Lake.VACUUM
limpa os arquivos neste diretório. Consulte os índices do filtro Bloom.
- Os dados para o feed de dados de alteração são gerenciados por Delta Lake no diretório
-
A capacidade de consultar versões de tabelas anteriores ao período de retenção é perdida após a execução de
VACUUM
. -
Os arquivos de registro são excluídos automaticamente e de forma assíncrona após as operações de checkpoint e não são regidos por
VACUUM
. Embora o período de retenção de default dos arquivos log seja de 30 dias, a execução deVACUUM
em uma tabela remove os arquivos de dados necessários para a viagem do tempo.
Quando o cache de disco está ativado, um clustering pode conter dados de Parquet arquivos que foram excluídos com VACUUM
. Portanto, talvez seja possível consultar os dados das versões anteriores da tabela cujos arquivos foram excluídos. Reiniciar o clustering removerá os dados armazenados em cache. Consulte Configurar o cache de disco.
Exemplo de sintaxe para 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 sobre a sintaxe do site Spark SQL, consulte vacuum.
Consulte a documentação da API do Delta Lake para obter detalhes de sintaxe em Scala, Java e Python.
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.
Modo completo versus modo lite
Visualização
Esse recurso está em Public Preview em Databricks Runtime 16.1 e acima.
O senhor pode especificar a palavra-chave LITE
na instrução vacuum para acionar um modo alternativo de VACUUM
que evita a listagem de todos os arquivos no diretório da tabela.
LITE
usa o log de transações Delta para identificar os arquivos de dados que não estão mais dentro do limite de retenção VACUUM
e remove esses arquivos de dados da tabela. LITE
é especialmente útil para tabelas grandes que exigem operações VACUUM
frequentes, pois evita a necessidade de listar todos os arquivos para identificar os arquivos de dados a serem removidos.
A execução do site 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 abortada.
Use a seguinte sintaxe para VACUUM
no modo LITE
:
VACUUM table_name LITE
LITE
o modo tem o seguinte requisito:
- O senhor deve ter executado pelo menos uma operação bem-sucedida
VACUUM
dentro do limite de retenção configurado para a transação log (30 dias por default).
Se esse requisito não for atendido, quando o senhor tentar executar o VACUUM
no modo LITE
, será exibida a seguinte mensagem de erro. Para continuar, o senhor deve executar VACUUM
no modo FULL
.
VACUUM <tableName> LITE cannot delete all eligible files as some files are not referenced by the Delta log. Please run VACUUM FULL.
FULL
O modo é o default para vacuum. O senhor pode executar explicitamente o modo completo com o seguinte comando:
VACUUM table_name FULL
Veja vacuum.
Limpe as exclusões somente de metadados para forçar a reescrita dos dados
O comando REORG TABLE
fornece a sintaxe APPLY (PURGE)
para reescrever os dados e aplicar exclusões flexíveis. As exclusões reversíveis não reescrevem dados nem excluem arquivos de dados, mas usam arquivos de metadados para indicar que alguns valores de dados foram alterados. Consulte REORG TABLE.
As operações que criam exclusões temporárias no Delta Lake incluem o seguinte:
- Eliminando colunas com o mapeamento de colunas ativado.
- Excluindo linhas com vetores de exclusão habilitados.
- Qualquer modificação de dados no clustering ativado pelo Photon quando os vetores de exclusão estã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 as passos a seguir:
- execução
REORG TABLE ... APPLY (PURGE)
. Depois de fazer isso, os dados antigos não estarão mais presentes nos arquivos atuais da tabela, mas ainda estarão presentes nos arquivos antigos que são usados para a viagem do tempo. - execução
VACUUM
para excluir esses arquivos 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 no histórico anteriores a essa 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, embora os dados na versão atual da tabela permaneçam consistentes.
Os arquivos de dados só são excluídos 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 diminuir o tempo de espera necessário, ao custo de reduzir o histórico máximo que é retido.
De que tamanho de clustering o site vacuum precisa?
Para selecionar o tamanho correto do clustering para VACUUM
, é útil entender que as operações ocorrem em duas fases:
- O trabalho começa usando todos os nós disponíveis do site executor para listar os 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.
- O driver emite um comando 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 worker ficam parados.
Para otimizar o custo e o desempenho, o site Databricks recomenda o seguinte, especialmente para trabalhos de longa duração em vacuum:
- execução vacuum em um clustering com escalonamento automático definido para 1-4 trabalhadores, em que 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 VACUUM
operações estiverem excluindo regularmente mais de 10 mil arquivos ou levando mais de 30 minutos de tempo de processamento, talvez o senhor queira aumentar o tamanho do driver ou o número de trabalhadores.
Se o senhor perceber que a lentidão ocorre durante a identificação dos arquivos a serem removidos, adicione mais nós worker. Se a lentidão ocorrer enquanto o comando delete estiver em execução, tente aumentar o tamanho do driver.
Com que frequência o senhor deve executar o vacuum?
A Databricks recomenda a execução regular do site VACUUM
em todas as tabelas para reduzir o excesso de custos de armazenamento de dados na nuvem. O limite de retenção do site default para vacuum é de 7 dias. A definição de um limite mais alto dá ao senhor acesso a um histórico maior para a sua tabela, mas aumenta o número de arquivos de dados armazenados e, como resultado, incorre em custos de armazenamento mais altos do seu provedor de nuvem.
Por que o senhor não pode vacuum uma tabela Delta com um limite de retenção baixo?
Recomenda-se que o senhor defina um intervalo de retenção de pelo menos 7 dias,
porque o Snapshot antigo e os arquivos não confirmados ainda podem estar em uso pelos leitores ou gravadores da tabela
concorrente. Se o VACUUM
limpar os arquivos ativos, os leitores do
concorrente podem falhar ou, pior ainda, as tabelas podem ser corrompidas quando o VACUUM
excluir arquivos que ainda não foram confirmados. O senhor deve escolher um intervalo
que seja maior do que a transação concorrente mais longa em execução e o período
mais longo que qualquer transmissão pode ficar atrás da atualização mais recente da tabela.
O Delta Lake tem uma verificação de segurança para evitar que o senhor execute um comando VACUUM
perigoso. Se o senhor tiver certeza de que não há operações sendo executadas nessa tabela que demorem mais do que o intervalo de retenção que pretende especificar, poderá desativar 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
VACUUM
confirmar a transação Delta log contém informações de auditoria. Você pode consultar os eventos de auditoria usando DESCRIBE HISTORY
.