Pular para o conteúdo principal
Última atualização em

Remover um recurso de tabela Delta Lake e fazer downgrade do protocolo da tabela

Este artigo descreve como descartar recursos da tabela Delta Lake e fazer downgrade das versões do protocolo.

Esta funcionalidade está disponível no Databricks Runtime 16.3 e acima. Nem todos os recursos de tabela do Delta Lake podem ser removidos. Consulte Quais recursos da tabela Delta Lake podem ser removidos?.

Só deve ser usado DROP FEATURE para oferecer suporte à compatibilidade com versões anteriores do Databricks Runtime, OpenSharing ou clientes de leitura ou gravação externos do Delta Lake.

nota

O suporte herdado para DROP FEATURE está disponível a partir do Databricks Runtime 14.3 LTS. A Databricks recomenda o uso do Databricks Runtime 16.3 e acima para todos os comandos DROP FEATURE, o que substitui o comportamento legado. Para documentação da funcionalidade legada, consulte Remover recursos da tabela Delta (legada).

Remover um recurso do Delta Lake​

Para excluir um recurso da tabela, utilize a seguinte sintaxe:

SQL
ALTER TABLE <table-name> DROP FEATURE <feature-name>

Você deve usar o Databricks Runtime 16.3 ou acima e ter privilégios MODIFY na tabela de destino do Delta Lake. Só é possível descartar um recurso de tabela com cada comando DROP FEATURE.

Consulte ALTER TABLE para mais detalhes.

importante

Todas as DROP FEATURE operações conflitam com todas as gravações concorrentes.

As leituras de transmissão falham quando encontram um commit que altera os metadados da tabela. Para que a transmissão continue, é preciso reiniciá-la. Para métodos recomendados, consulte Considerações de produção para transmissão estructurada.

O que acontece quando um recurso da tabela é descartado?​

Ao remover um recurso de tabela, o Delta Lake confirma atomicamente as alterações na tabela para realizar o seguinte:

  • Desativar propriedades da tabela que usam o recurso da tabela.
  • Os arquivos de dados devem ser reescritos, conforme necessário, para remover todos os vestígios do recurso da tabela dos arquivos de dados que dão suporte à tabela na versão atual.
  • Criar um conjunto de pontos de verificação protegidos que permite aos clientes leitores interpretar a história da tabela corretamente.
  • Adicione o recurso de tabela de gravação checkpointProtection ao protocolo da tabela.
  • É necessário fazer o downgrade do protocolo da tabela para as versões de leitor e gravador mais baixas que ofereçam suporte a todos os recursos de tabela restantes. Consulte Protocolo mínimo possível.

Qual é o recurso de tabela checkpointProtection?​

Ao remover um recurso, o Delta Lake reescreve os dados e metadados na história da tabela como pontos de verificação protegidos para respeitar o downgrade do protocolo. Após o rebaixamento, a tabela deve ser sempre legível por mais clientes leitores. Isto ocorre porque o protocolo da tabela agora reflete que o suporte para o recurso descontinuado não é mais necessário para a leitura da tabela. Os pontos de verificação protegidos e o recurso checkpointProtection realizam o seguinte:

  • Clientes leitores que compreendem o recurso de tabelas descartadas podem acessar toda a história de tabelas disponível.
  • Clientes de leitura que não oferecem suporte ao recurso de tabela descartado precisam apenas ler a história da tabela a partir da versão de downgrade do protocolo.
  • Clientes de gravação não regravam os pontos de verificação antes do downgrade do protocolo.
  • As operações de manutenção de tabela respeitam os requisitos definidos por checkpointProtection, que marcam os pontos de verificação de downgrade de protocolo como protegidos.

Embora seja possível descartar apenas um recurso de tabela com cada comando DROP FEATURE, uma tabela pode ter vários pontos de verificação protegidos e recursos descartados em seu histórico de tabela.

Todas as versões do Databricks Runtime suportam o recurso de tabela checkpointProtection, o que significa que este recurso de tabela não bloqueia leituras ou gravações no Databricks.

O recurso de tabela checkpointProtection não deve impedir o acesso somente leitura de clientes OSS Delta Lake. Para fazer o downgrade completo da tabela e remover o recurso de tabela checkpointProtection, você deve usar TRUNCATE HISTORY. O Databricks recomenda usar este padrão somente se for necessário gravar em tabelas com clientes Delta externos que não suportam checkpointProtection. Consulte Fazer downgrade completo dos protocolos de tabela para clientes legados.

Quais recursos da tabela Delta Lake podem ser removidos?​

Você pode remover os seguintes recursos da tabela Delta Lake:

Não é possível remover outros recursos de tabela Delta Lake.

importante

A remoção do mapeamento de coluna de uma tabela não remove os prefixos aleatórios usados nos nomes de diretório para tabelas particionadas. Consulte O Delta Lake e o Parquet compartilham estratégias de particionamento?.

Alguns recursos do Delta Lake permitem vários recursos de tabela. Alguns recursos da tabela dependem de outros recursos da tabela e podem bloquear a exclusão de recursos da tabela dependentes. Como alguns recursos de tabela não podem ser removidos, isso significa que a habilitação de alguns recursos do Delta Lake não pode ser revertida.

A Databricks recomenda sempre testar cargas de trabalho e sistemas dependentes quanto à compatibilidade com novas funcionalidades antes de habilitar funcionalidades que atualizam protocolos de leitura ou gravação para dados de produção.

Fazer o downgrade completo dos protocolos de tabela para clientes legados​

Se as integrações com clientes externos do Delta Lake exigirem gravações que não oferecem suporte ao recurso de tabela checkpointProtection, você deve usar TRUNCATE HISTORY para remover completamente todos os vestígios dos recursos de tabela desabilitados e fazer o downgrade completo do protocolo da tabela.

O Databricks recomenda testar o comportamento default para DROP FEATURE antes de prosseguir com TRUNCATE HISTORY. Executar TRUNCATE HISTORY remove toda a história da tabela maior que 24 horas.

O downgrade completo da tabela ocorre em dois passos que devem ocorrer com um intervalo de pelo menos 24 horas.

O passo 1: preparar para descartar um recurso da tabela​

Durante a primeira fase, o usuário se prepara para descartar o recurso da tabela. O seguinte descreve o que acontece durante esta etapa:

  1. Você executa o comando ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORY.
  2. Propriedades da tabela que ativam especificamente um recurso da tabela têm valores definidos para desativar o recurso.
  3. Propriedades da tabela que controlam comportamentos associados ao recurso removido têm opções definidas como valores default antes que o recurso fosse introduzido.
  4. Quando necessário, os arquivos de dados e metadados são reescritos, respeitando as propriedades da tabela atualizadas.
  5. O comando finaliza a execução e retorna uma mensagem de erro informando que é preciso aguardar 24 horas para prosseguir com a remoção do recurso.

Após a desativação inicial de um recurso, é possível continuar gravando na tabela de destino antes da conclusão do downgrade do protocolo, mas não é possível usar o recurso de tabela que está sendo removido.

nota

Se a tabela permanecer neste estado, as operações na tabela não usarão o recurso da tabela, mas o protocolo ainda oferece suporte ao recurso da tabela. Até que se conclua o passo final de downgrade, a tabela não pode ser lida por clientes Delta que não entendem o recurso da tabela.

O passo 2: Fazer downgrade do protocolo e remover um recurso da tabela​

Para remover completamente todo o histórico de transações associado ao recurso e fazer downgrade do protocolo:

  1. Após decorridas pelo menos 24 horas, você executa o comando ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORY.
  2. O cliente confirma que nenhuma transação no limite de retenção especificado utiliza o recurso de tabela, então trunca o histórico da tabela para esse limite.
  3. O recurso da tabela é descartado durante o downgrade de protocolo.
  4. Se os recursos da tabela que estão presentes na tabela puderem ser representados por uma versão de protocolo inferior, os minReaderVersion e minWriterVersion da tabela são rebaixados para a versão mais baixa que suporta os recursos restantes em uso pela tabela Delta Lake.
importante

A execução de ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORY remove todos os dados de log de transação com mais de 24 horas. Após usar este comando para fazer o downgrade do protocolo da tabela, não há acesso ao histórico da tabela ou à viagem do tempo.

Consulte a compatibilidade de recursos e protocolos do Delta Lake.

Nesta página