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

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

No Databricks Runtime 16.4 LTS e acima, DROP FEATURE remove um recurso de tabela do Delta Lake e faz downgrade do protocolo da tabela para a versão mais baixa que oferece suporte aos recursos restantes. Use isso apenas para restaurar a compatibilidade com versões anteriores do Databricks Runtime, OpenSharing ou clientes externos do Delta Lake.

Nem todos os recursos podem ser descartados. Consulte Recursos de tabela compatíveis.

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​

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. É preciso reiniciar as transmissões afetadas. Para métodos recomendados, consulte Considerações de produção para transmissão estructurada.

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.

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

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

Consulte ALTER TABLE para mais detalhes.

Comportamento​

Quando um recurso de tabela é removido, o Delta Lake realiza o commit das seguintes alterações na tabela:

  • Desativar propriedades da tabela que usam o recurso da tabela.
  • Reescreva os arquivos de dados subjacentes conforme necessário para remover todos os vestígios do recurso da tabela da versão atual da tabela.
  • Crie um conjunto de pontos de verificação protegidos que permitem que clientes leitores leiam 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 mais baixo possível.

O checkpointProtection recurso da tabela​

Ao remover um recurso, o Delta Lake reescreve dados e metadados na história da tabela como checkpoints protegidos para respeitar o downgrade do protocolo.

Após o downgrade, a tabela não exige que os clientes ofereçam suporte ao recurso descartado. Os checkpoints protegidos e o recurso checkpointProtection realizam o seguinte:

  • Clientes leitores que suportam o recurso de tabela descartado podem ler todas as versões disponíveis da história da tabela.
  • Clientes leitores que não suportam o recurso removido podem ler as versões da história da tabela a partir da versão de downgrade do protocolo.
  • Os clientes gravadores não modificam os pontos de verificação criados antes do downgrade do protocolo.
  • checkpointProtection Marca os pontos de verificação de downgrade de protocolo como protegidos, e as operações de manutenção da tabela respeitam esses marcadores.

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.

checkpointProtection não bloqueia 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 esse padrão apenas se você precisar gravar em tabelas com clientes Delta externos que não suportam checkpointProtection. Consulte Fazer downgrade completo dos protocolos de tabela para clientes legados.

Recursos de tabela com suporte​

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

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

importante

A Databricks recomenda que você sempre teste as cargas de trabalho e os sistemas dependentes quanto à compatibilidade com novos recursos antes de habilitar os recursos que atualizam os protocolos de leitura ou gravação para dados de produção.

Considere o seguinte:

  • 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 múltiplos recursos de tabela que dependem uns dos outros, o que pode impedi-lo de remover recursos dependentes. Não é possível reverter recursos que não podem ser removidos.

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

Se você usar clientes externos do Delta Lake com gravações que não oferecem suporte ao recurso de tabela checkpointProtection, você deve usar TRUNCATE HISTORY para fazer o downgrade completo do protocolo da tabela e remover todos os vestígios dos recursos de tabela removidos. A execução de TRUNCATE HISTORY remove toda a história da tabela com mais de 24 horas.

A Databricks recomenda testar o comportamento default para DROP FEATURE antes de executar TRUNCATE HISTORY.

O downgrade completo exige os passos, dois deles com pelo menos 24 horas de diferença.

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

Faça a execução do comando ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORY. O comando aplica o seguinte:

  • Atualizar as propriedades da tabela para desativar o recurso.
  • Reset as propriedades de tabela associadas ao recurso para seus default.
  • Reescreve arquivos de dados e metadados conforme necessário para refletir as propriedades atualizadas.
  • Retorna uma mensagem exigindo que você espere pelo menos 24 horas antes de executá-lo novamente para concluir o downgrade do protocolo.

Após desativar um recurso, é possível continuar a gravar na tabela de destino antes de concluir o downgrade do protocolo, mas não é possível usar o recurso de tabela que está sendo removido.

nota

Se você deixar a tabela 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 você conclua o passo final de downgrade, a tabela não poderá ser lida por clientes Delta que não oferecem suporte ao recurso da tabela.

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

Após pelo menos 24 horas, execute o comando ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORY novamente. O comando aplica o seguinte:

  • Trunca a história da tabela para o limite de retenção.
  • Confirma que nenhuma transação restante usa o recurso.
  • Remove o recurso e faz o downgrade do protocolo da tabela para a versão mais baixa que oferece suporte aos recursos restantes.
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. Depois de usar este comando para fazer o downgrade do protocolo da tabela, você não poderá acessar a história da tabela ou a viagem do tempo.

Consulte a compatibilidade de recursos e protocolos do Delta Lake.

Nesta página