Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo descreve como remover recursos da tabela do Delta Lake e fazer downgrade das versões do protocolo.
Essa funcionalidade está disponível no Databricks Runtime 16.3 e superior. Nem todos os recursos de tabela Delta podem ser removidos. Veja quais recursos da tabela Delta podem ser descartados?.
Você só deve usar DROP FEATURE para dar suporte à compatibilidade com versões anteriores do Databricks Runtime, Delta Sharing ou clientes externos de leitura ou gravação do 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, o que substitui o comportamento herdado. Para a documentação de funcionalidades herdadas, consulte Drop Delta table features (legacy).
Remover um recurso do Delta Lake
Para remover 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 descartar um recurso de tabela com cada DROP FEATURE comando.
Confira ALTER TABLE para obter mais detalhes.
Importante
Todas as operações DROP FEATURE entram em conflito com todas as gravações simultâneas.
As leituras de streaming falham quando encontram uma confirmação que altera os metadados da tabela. Se você quiser que o fluxo continue, precisará reiniciá-lo. Para obter métodos recomendados, consulte considerações de produção para Streaming Estruturado.
O que acontece quando um recurso de tabela é descartado?
Quando você remove um recurso de 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 arquivos de dados conforme necessário para remover todos os traços do recurso de tabela dos arquivos de dados que sustentam a tabela na versão atual.
- Crie um conjunto de pontos de verificação protegidos que permitem que os clientes leitores interpretem o histórico da tabela corretamente.
- Adicionar o recurso de tabela de gravador
checkpointProtectionao protocolo de tabela. - Faça downgrade do protocolo de tabela para as versões de leitor e gravador mais baixos que dão suporte a todos os recursos restantes da tabela. Veja o protocolo de nível mais baixo possível.
O que é o recurso de tabela checkpointProtection?
Quando você remove um recurso, o Delta Lake reescreve os dados e os metadados no histórico da tabela como pontos de verificação protegidos para respeitar o downgrade do protocolo. Após o downgrade, a tabela sempre deverá ser legível para mais clientes leitores. Isso ocorre porque o protocolo da 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 leitores que entendem o recurso de tabela descartada podem acessar todo o histórico de tabelas disponível.
- Os clientes leitores que não dão suporte ao recurso de tabela removido só precisam ler o histórico da tabela a partir da versão de downgrade do protocolo.
- Os clientes gravadores não reescrevem 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 você só possa descartar 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 somente leitura de clientes do Delta Lake de software de código aberto. Para fazer downgrade completo da tabela e remover o recurso de tabela checkpointProtection, use TRUNCATE HISTORY. O Databricks recomenda usar esse padrão somente se você precisar gravar em tabelas com clientes Delta externos que não dão suporte checkpointProtection. Veja Fazer downgrade completo dos protocolos de tabela nos clientes herdados.
Quais recursos da tabela Delta podem ser descartados?
Você pode remover os seguintes recursos da tabela Delta:
-
checkConstraints. Consulte restrições no Azure Databricks. -
collations-preview. Veja Suporte de ordenação para o Delta Lake. -
columnMapping. Veja Renomear e remover colunas usando o mapeamento de colunas do Delta Lake. -
deletionVectors. Veja o que são vetores de exclusão?. -
typeWidening. Veja Ampliação de tipo. -
v2Checkpoint. Consulte Compatibilidade para tabelas com agrupamento líquido. -
checkpointProtection. Veja O que é o recurso de tabelacheckpointProtection?.
Não é possível descartar outros recursos da tabela Delta.
Importante
Remover o mapeamento de coluna de uma tabela não remove os prefixos aleatórios usados em nomes de diretório para tabelas particionadas. Confira O Delta Lake e o Parquet compartilham 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 de recursos de tabela dependentes. Como alguns recursos de tabela não podem ser descartados, 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 para compatibilidade com novas funcionalidades antes de habilitar a funcionalidade que atualiza protocolos de leitor ou gravador para dados de produção.
Fazer downgrade completo dos protocolos de tabela nos clientes herdados
Se as integrações aos clientes externos do Delta Lake exigirem gravações que não dão suporte ao recurso de tabela checkpointProtection, use TRUNCATE HISTORY para remover totalmente todos os rastreamentos dos recursos de tabela desabilitados e fazer downgrade completo do protocolo de tabela.
O Databricks recomenda testar o comportamento padrão para DROP FEATURE antes de continuar com TRUNCATE HISTORY. Executar TRUNCATE HISTORY remove todo o histórico de tabelas com mais de 24 horas.
O downgrade completo da tabela ocorre em duas etapas que devem ocorrer com, pelo menos, 24 horas de diferença.
Etapa 1: Preparar-se para remover um recurso de tabela
Durante o primeiro estágio, o usuário se prepara para remover o recurso de tabela. O seguinte descreve o que acontece durante este estágio:
- Você executa o comando
ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORY. - As propriedades de tabela que habilitam especificamente um recurso de tabela têm valores definidos para desabilitar o recurso.
- As propriedades da tabela que controlam os comportamentos associados ao recurso removido têm opções definidas como valores padrão antes da introdução do recurso.
- Conforme for necessário, os arquivos de dados e metadados são reescritos respeitando as propriedades da tabela atualizada.
- O comando termina de ser executado e retorna uma mensagem de erro informando ao usuário que ele deve aguardar 24 horas para prosseguir com a remoção do recurso.
Depois de primeiro desabilitar um recurso, você pode continuar gravando na tabela de destino antes de concluir o downgrade de 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 poderá ser lida pelos clientes Delta que não entendem o recurso de tabela.
Etapa 2: fazer downgrade do protocolo e remover um recurso de tabela
Para remover totalmente todo o histórico de transações associado ao recurso e fazer downgrade do protocolo:
- Depois de pelo menos 24 horas, você executará o
ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORYcomando. - 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 para esse limite.
- O recurso de tabela é descartado durante o downgrade de protocolo.
- Se os recursos de tabela presentes na tabela puderem ser representados por uma versão de protocolo inferior, o
minReaderVersioneminWriterVersionpara a tabela serão rebaixados para a versão mais baixa que dá suporte aos 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 das transações com mais de 24 horas. Depois de usar esse comando para fazer downgrade do protocolo de tabela, você não terá acesso ao histórico da tabela ou à viagem no tempo.
Consulte a compatibilidade de recursos e protocolos do Delta Lake.