Partilhar via

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 todos os recursos da tabela Delta podem ser descartados. Consulte Quais recursos da tabela Delta podem ser descartados?.

Você só deve usar DROP FEATURE para oferecer suporte à compatibilidade com versões anteriores do Databricks Runtime, Delta Sharing ou clientes externos de leitor ou gravador Delta Lake.

Observação

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>

Você deve usar o Databricks Runtime 16.3 ou superior e ter MODIFY privilégios na tabela Delta 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 da tabela que usam o recurso de 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 dão suporte ao recurso de tabela, o checkpointProtection que significa que esse recurso de tabela não bloqueia leituras ou gravações no 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 recursos da tabela Delta podem ser descartados?

Você pode remover os seguintes recursos da tabela Delta:

Não é possível descartar outros recursos da tabela Delta.

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 partilham estratégias de particionamento.

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

O Databricks recomenda sempre testar cargas de trabalho e sistemas dependentes quanto à compatibilidade com novas funcionalidades antes de habilitar a funcionalidade que atualiza os protocolos de leitor ou gravador 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.

Etapa 1: Preparar para excluir uma funcionalidade da 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.

Observação

Se você deixar a tabela nesse estado, as operações na tabela não usarão o recurso de tabela, mas o protocolo ainda oferece suporte ao recurso de tabela. Até que você conclua a etapa final de downgrade, a tabela não é legível por clientes Delta que não entendem o recurso de tabela.

Etapa 2: Fazer downgrade do protocolo e soltar um recurso 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 os recursos da tabela que estão presentes na tabela podem ser representados por uma versão de protocolo inferior, o minReaderVersion e minWriterVersion para a tabela são rebaixados para a versão mais baixa que suporta os recursos restantes em uso pela tabela Delta.

Importante

A execução 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.