Remover uma funcionalidade da tabela Delta Lake e fazer downgrade do protocolo da tabela

Este artigo descreve como eliminar os recursos de tabela Delta Lake e rebaixar versões de protocolo.

Essa funcionalidade está disponível no Databricks Runtime 16.3 e superior. Nem todas as funcionalidades da tabela Delta Lake podem ser removidas. Consulte Que funcionalidades da tabela Delta Lake podem ser removidas?

Deve utilizar DROP FEATURE apenas para garantir a compatibilidade com versões anteriores do Databricks Runtime, OpenSharing ou clientes externos de leitura ou escrita do Delta Lake.

Note

O suporte herdado para DROP FEATURE está disponível a partir do Databricks Runtime 14.3 LTS. O Databricks recomenda o uso do Databricks Runtime 16.3 e superior para todos os DROP FEATURE comandos, que substitui o comportamento herdado. Para obter a documentação da funcionalidade herdada, consulte Drop Delta table features (legacy).

Remova um recurso Delta Lake

Para soltar um recurso de tabela, use a seguinte sintaxe:

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

Deve usar o Databricks Runtime 16.3 ou posterior e ter privilégios MODIFY na tabela Delta Lake de destino. Você só pode eliminar um recurso de tabela com cada comando DROP FEATURE.

Consulte ALTER TABLE para obter mais detalhes.

Importante

Todas as DROP FEATURE operações entram em conflito com todas as escritas concorrentes.

As leituras de streaming falham quando encontram uma confirmação que altera os metadados da tabela. Se quiser que o fluxo continue, tem de reiniciá-lo. Para obter os métodos recomendados, consulte Considerações de produção para streaming estruturado.

O que acontece quando um recurso de tabela é descartado?

Quando se elimina uma funcionalidade da tabela, o Delta Lake confirma atomicamente as alterações na tabela para realizar o seguinte:

  • Desative as propriedades das tabelas que utilizam a funcionalidade da tabela.
  • Reescreva os ficheiros de dados conforme necessário para remover os vestígios da funcionalidade de tabela dos ficheiros de dados que suportam a tabela na versão atual.
  • Crie um conjunto de pontos de verificação protegidos que permitam aos clientes leitores interpretar o histórico da tabela corretamente.
  • Adicione o recurso checkpointProtection de tabela do gravador ao protocolo de tabela.
  • Faça o downgrade do protocolo de tabela para as versões mais baixas de leitor e gravador que suportam todos os recursos restantes da tabela. Consulte Protocolo mais baixo possível.

O que é o recurso de checkpointProtection tabela?

Quando desativa uma funcionalidade, o Delta Lake reescreve os dados e metadados no histórico da tabela como pontos de verificação protegidos para respeitar a redução da versão do protocolo. Após o downgrade, a tabela deve ser sempre legível por mais clientes leitores. Isso ocorre porque o protocolo para a tabela agora reflete que o suporte para o recurso descartado não é mais necessário para ler a tabela. Os pontos de verificação protegidos e o checkpointProtection recurso realizam o seguinte:

  • Os clientes de leitura que entendem o recurso de tabela descartada podem acessar todo o histórico de tabelas disponíveis.
  • Os clientes de leitura que não suportam o recurso de tabela removida só precisam ler o histórico da tabela a partir da versão de degradação do protocolo.
  • Os clientes do gravador não reescrevem os pontos de verificação antes do downgrade do protocolo.
  • As operações de manutenção da tabela respeitam os requisitos definidos pela checkpointProtection, que marcam os pontos de verificação de degradação do protocolo como protegidos.

Embora você só possa soltar um recurso de tabela com cada DROP FEATURE comando, uma tabela pode ter vários pontos de verificação protegidos e recursos descartados em seu histórico de tabelas.

Todas as versões do Databricks Runtime suportam a funcionalidade de tabela checkpointProtection, o que significa que esta funcionalidade de tabela não bloqueia leituras ou escritas em Azure Databricks.

O recurso de tabela checkpointProtection não deve bloquear o acesso em modo de leitura de clientes OSS Delta Lake. Para fazer o downgrade completo da tabela e remover o checkpointProtection recurso de tabela, você deve usar TRUNCATE HISTORY. O Databricks recomenda usar esse padrão somente se você precisar gravar em tabelas com clientes Delta externos que não suportam checkpointProtection. Consulte Protocolos completos de downgrade de tabela para clientes antigos.

Quais características da tabela Delta Lake podem ser removidas?

Pode eliminar as seguintes características da tabela Delta Lake:

Não podes eliminar outras funcionalidades da tabela do Delta Lake.

Importante

Descartar o mapeamento de colunas de uma tabela não remove os prefixos aleatórios usados em nomes de diretório para tabelas particionadas. Veja se Delta Lake e Parquet compartilham estratégias de particionamento.

Algumas funcionalidades do Delta Lake permitem múltiplas funcionalidades de tabelas. Alguns recursos de tabela dependem de outros recursos de tabela e podem bloquear a remoção dos recursos de tabela dependentes. Como algumas funcionalidades da tabela não podem ser eliminadas, isto significa que a habilitação para algumas características 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 ativar funcionalidades que atualizam protocolos de leitor ou escrita para dados de produção.

Fazer 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 suportem o checkpointProtection recurso de tabela, você deverá usar TRUNCATE HISTORY para remover totalmente todos os vestígios dos recursos de tabela desabilitados e fazer o downgrade total do protocolo de tabela.

Databricks recomenda testar o comportamento padrão para DROP FEATURE antes de prosseguir com TRUNCATE HISTORY. Executar TRUNCATE HISTORY remove todo o histórico da tabela com duração superior a 24 horas.

O downgrade completo da tabela ocorre em duas etapas, com um intervalo de pelo menos 24 horas entre elas.

Passo 1: Prepare-se para eliminar uma funcionalidade de tabela

Durante a primeira etapa, o utilizador prepara-se para eliminar o recurso de tabela. A seguir descreve-se o que acontece durante esta etapa:

  1. Tu executas o ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORY comando.
  2. As propriedades da tabela que habilitam especificamente um recurso de tabela têm valores definidos para desabilitar o recurso.
  3. As propriedades da tabela que controlam comportamentos associados ao recurso descartado têm opções definidas como valores padrão antes da introdução do recurso.
  4. Conforme necessário, os arquivos de dados e metadados são reescritos respeitando as propriedades atualizadas da tabela.
  5. O comando termina a execução e retorna uma mensagem de erro informando ao usuário que ele deve esperar 24 horas para prosseguir com a remoção do recurso.

Depois de desativar um recurso pela primeira vez, você pode continuar gravando na tabela de destino antes de concluir o downgrade do protocolo, mas não pode usar o recurso de tabela que está removendo.

Note

Se deixar a tabela neste estado, as operações contra a tabela não utilizam a funcionalidade de tabela, mas o protocolo ainda suporta a funcionalidade de tabela. Até completar o passo final de downgrade, a tabela não é legível pelos clientes Delta que não compreendem a funcionalidade da tabela.

Passo 2: Rebaixar o protocolo e eliminar uma funcionalidade de tabela

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

  1. Após pelo menos 24 horas, execute o ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORY comando.
  2. O cliente confirma que nenhuma transação no limite de retenção especificado usa o recurso de tabela e, em seguida, trunca o histórico da tabela até esse limite.
  3. O recurso de tabela é descartado durante o downgrade do protocolo.
  4. Se as características da tabela presentes na tabela puderem ser representadas por uma versão de protocolo inferior, os minReaderVersion e minWriterVersion para a tabela são rebaixados para a versão mais baixa que suporta as restantes funcionalidades em uso pela tabela Delta Lake.

Importante

Executar ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORY remove todos os dados do log de transações com mais de 24 horas. Após utilizar este comando para rebaixar o protocolo da tabela, não terá acesso ao histórico da tabela ou à viagem no tempo.

Consulte Compatibilidade de recursos e protocolos do Delta Lake.

  • Last updated on