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.
Remova os arquivos de dados que não são mais referenciados por uma tabela e que são mais antigos que o limite de retenção executando o comando VACUUM na tabela. Executar VACUUM regularmente é importante para reduzir custos e 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
VACUUMpodem 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 de otimização preditiva para execução automática VACUUM para tabelas. Consulte Otimização preditiva para Unity Catalog gerenciar tabelas.
Algumas tabelas de recursos usam arquivos de metadados para marcar dados como excluídos, em vez de reescrever os arquivos de dados. Use REORG TABLE ... APPLY (PURGE) para commit essas exclusões e reescrever os arquivos de dados. Consulte Excluir apenas metadados para forçar a reescrita de dados.
-
No Databricks Runtime 13.3 LTS e versões superiores, a semântica
VACUUMpara clones superficiais com tabelas de gerenciamento Unity Catalog difere de outras tabelas. Veja clones rasosvacuum e Unity Catalog. -
VACUUMremove todos os arquivos de diretórios não gerenciados pelo Databricks, ignorando diretórios que começam com_ou.. Se você estiver armazenando metadados adicionais, como pontos de verificação de transmissão estruturada, dentro de um diretório de tabela, use um nome de diretório como_checkpoints.- Os dados para o feed de dados de alteração são gerenciados no diretório
_change_datae removidos comVACUUM. Consulte a seção "Usar o feed de dados de alterações do Delta Lake" no Databricks. - Os índices do filtro de Bloom usam o diretório
_delta_index.VACUUMlimpa os arquivos neste diretório. Consulte os índices do filtro de Bloom.
- Os dados para o feed de dados de alteração são gerenciados 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 deVACUUMem 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 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.
No Databricks Runtime 18.0 e versões superiores, use a propriedade de tabela deletedFileRetentionDuration para controlar a retenção. Para tabelas de gerenciamento Unity Catalog , isso se aplica ao Databricks Runtime 12.2 e versões superiores.
Consulte Configurar 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 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 VACUUM e remove esses arquivos de dados da tabela. O modo 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
VACUUMdentro 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 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 lógicas incluem as seguintes:
- Eliminando colunas com o mapeamento de colunas ativado.
- Quaisquer modificações de dados com vetores de exclusão ativados.
Com as exclusões reversíveis habilitadas, 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 esses dados fisicamente da tabela, conclua as seguintes etapas:
- 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
VACUUMpara 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 utilizando todos os nós executor disponíveis 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 para identificar os arquivos a serem excluídos. O motorista permanece sentado durante esse período.
- 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 não é possível vacuum uma mesa 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.
Existe 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 você planeja especificar, desative esta verificação de segurança definindo a propriedade de configuração do Spark spark.databricks.delta.retentionDurationCheck.enabled (Delta) ou spark.databricks.iceberg.retentionDurationCheck.enabled (Iceberg) para false.
Informações de auditoria
VACUUM comprometer-se com o log de transações contém informações de auditoria. Consulte os eventos de auditoria usando DESCRIBE HISTORY.