Compatibilidade de recursos e protocolos do Delta Lake

Os protocolos de tabela Delta Lake especificam quais as funcionalidades que um cliente deve suportar para ler ou escrever uma tabela. Esta página aborda versões de protocolos, funcionalidades de tabelas, requisitos de compatibilidade e como o Azure Databricks gere atualizações de protocolos. Ver também Rever os detalhes da tabela com descrever detalhes.

Protocolo de tabela e compatibilidade

Cada tabela Delta Lake tem uma especificação de protocolo que indica o conjunto de capacidades necessárias para ler e escrever na tabela. As aplicações utilizam a especificação do protocolo para determinar se conseguem suportar todas as funcionalidades que a tabela utiliza. Se uma aplicação não conseguir suportar uma funcionalidade no protocolo atual de uma tabela, então essa aplicação não pode ler nem escrever essa tabela.

A maioria das novas capacidades do Delta Lake exige que atualizes o protocolo de tabela.

A tabela seguinte lista termos-chave que descrevem os protocolos Delta Lake:

Os protocolos de escrita e as funcionalidades de escrita afetam apenas a compatibilidade com clientes de escrita, permitindo o acesso apenas de leitura à tabela a partir de cargas de trabalho legadas.

Nem todos os recursos do Delta Lake são compatíveis entre si.

Algumas funcionalidades da tabela não podem ser eliminadas depois de ativadas. Consulte Remover uma funcionalidade da tabela Delta Lake e fazer downgrade do protocolo da tabela.

Versões do protocolo e funcionalidades das tabelas

Todas as tabelas Delta Lake incluem uma versão de protocolo baseada em inteiros representada por minReaderVersion e minWriterVersion. Cada versão agrupa várias funcionalidades, e as funcionalidades são cumulativas entre as várias versões. Para cumprir o protocolo Delta Lake, os clientes devem implementar suporte para todas as funcionalidades de uma determinada versão, incluindo todas as funcionalidades previamente lançadas.

No Databricks Runtime 12.2 LTS e superiores, as características da tabela substituem o protocolo baseado em inteiros por flags granulares que indicam quais as características que uma tabela utiliza. Isto permite verificações de compatibilidade mais detalhadas entre clientes e tabelas.

As funcionalidades do escritor de tabelas afetam a forma como os dados são escritos. Eles exigem minWriterVersion=7 , mas não bloqueiam, clientes leitores.

As funcionalidades do leitor de tabela afetam a forma como os dados são lidos. Todas as funcionalidades do leitor também são funcionalidades do escritor, e requerem minReaderVersion=3 e minWriterVersion=7. Um cliente não consegue escrever numa tabela que não consegue ler.

Quando as funcionalidades de tabela estão ativadas, aparecem no protocolo como readerFeatures ou writerFeatures. O Delta Lake resolve o protocolo de tabela para a versão mais baixa que suporta todas as funcionalidades ativadas. Ver Protocolo mais baixo possível.

Alterações ao protocolo

O protocolo para uma tabela muda nas seguintes condições:

• Se um novo recurso estiver habilitado, o protocolo será atualizado.
• Se um recurso de tabela for descartado, o protocolo será rebaixado.

Desligar uma funcionalidade de tabela não resulta numa degradação do protocolo. Deve eliminar a funcionalidade para a remover completamente do protocolo. Nem todas as funcionalidades da tabela podem ser descartadas. Consulte Remover uma funcionalidade da tabela Delta Lake e fazer downgrade do protocolo da tabela.

Todas as operações de alteração de protocolo entram em conflito com escritas concorrentes. As leituras de streaming falham quando encontram uma confirmação que altera os metadados da tabela. Para continuar, reinicie os fluxos afetados. Para obter os métodos recomendados, consulte Considerações de produção para streaming estruturado.

O que desencadeia uma atualização de protocolo

Quando ativas uma funcionalidade, o protocolo de tabela é automaticamente atualizado.

As atualizações de protocolo são desencadeadas das seguintes formas:

• Ativar automaticamente com base na sintaxe usada nas CREATE instruções ou.ALTER Por exemplo, CLUSTER BY numa CREATE TABLE instrução ativa automaticamente o agrupamento de líquidos e GENERATED ALWAYS AS as colunas geradas.
• Ativar explicitamente através das propriedades da tabela. Por exemplo, a definição 'delta.enableDeletionVectors' = true ativa vetores de eliminação.
• Ativar uma funcionalidade pode ativar automaticamente as funcionalidades necessárias. Por exemplo, ativar o UniForm permite automaticamente o mapeamento de colunas, e ativar o agrupamento de líquidos ativa automaticamente o checkpoint V2. Consulte a documentação relevante do Azure Databricks para determinar que características de tabela uma determinada funcionalidade requer.

As funcionalidades do leitor atualizam tanto os protocolos de leitura como de escrita. Por exemplo, o mapeamento de colunas é uma funcionalidade do leitor e requer a atualização de ambos os protocolos porque os dados são armazenados de forma diferente no armazenamento.

Funcionalidades de escrita, como CHECK restrições, apenas atualizam o protocolo de escrita.

Protocolo mais baixo possível

O Delta Lake resolve o protocolo de tabela para a versão mais baixa que suporta todas as funcionalidades ativadas. Isto só pode diminuir minReaderVersion ou minWriterVersion, nunca aumentá-los. As funcionalidades da tabela nunca são removidas automaticamente. Use DROP FEATURE para remover uma funcionalidade de tabela do protocolo.

Se todas as funcionalidades ativadas forem totalmente suportadas numa versão inferior de protocolo baseada em inteiros, a tabela pode reverter para essa versão e desaparecer readerFeatureswriterFeatures do protocolo. Isto não desativa nenhuma funcionalidade. Versões de protocolo mais baixa aumentam a compatibilidade porque todos os clientes devem respeitá-las.

Azure Databricks and Databricks Runtime compatibility

Azure Databricks introduz suporte para novas funcionalidades do Delta Lake nas versões Databricks Runtime:

• Tabelas escritas por uma versão Databricks Runtime inferior têm suporte total de leitura e escrita em versões Databricks Runtime superiores.
• Tabelas escritas por uma versão de Runtime Databricks superior podem usar funcionalidades de tabela não suportadas em versões de Runtime Databricks inferiores.
• Algumas funcionalidades permitem escritas a partir de versões inferiores do Databricks Runtime, sem aplicar totalmente todas as otimizações para a funcionalidade ativada.

Se só usares tabelas Delta Lake através do Azure Databricks, só precisas de acompanhar o suporte a funcionalidades usando os requisitos mínimos de tempo de execução do Databricks. Se lê ou escreve tabelas de sistemas externos, deve verificar se esses clientes suportam as funcionalidades de tabela ativadas nas suas tabelas.

Suporte a funcionalidades de tabelas backportadas

No Databricks Runtime 12.2 LTS e superiores, as características da tabela substituíram o protocolo baseado em inteiros por flags granulares que indicam quais as características que uma tabela utiliza.

O Azure Databricks transferiu o suporte a funcionalidades de tabelas para o Databricks Runtime 11.3 LTS e inferiores, em vez de suportar apenas versões do protocolo inteiro, mas apenas para funcionalidades já suportadas nessa versão.

Por exemplo, pode ler e escrever numa tabela com colunas geradas ativadas usando funcionalidades de tabela no Databricks Runtime 9.1 LTS. No entanto, não pode usar o Databricks Runtime 9.1 LTS para ler e escrever numa tabela com colunas de identidade ativadas usando características de tabela porque as colunas de identidade requerem Databricks Runtime 10.4 LTS e superiores.

Ao utilizar características de tabela com suporte backported, algumas operações disponíveis numa dada versão Databricks Runtime podem não estar disponíveis na versão correspondente do OSS Delta Lake. Se a sua arquitetura inclui clientes OSS Delta Lake, teste a compatibilidade antes de ativar as funcionalidades das tabelas nas tabelas de produção.

Recursos do Delta Lake e versões necessárias do Databricks Runtime

A tabela seguinte lista a versão mais baixa do Databricks Runtime, com suporte total para cada funcionalidade, de modo que todas as capacidades geralmente disponíveis para leituras e escritas sejam suportadas.

Consulte as Notas sobre as versões e compatibilidade do Databricks Runtime.

Características por versão do protocolo

O Delta Lake utiliza valores separados minReaderVersion e minWriterVersion para especificar capacidades do protocolo. O protocolo open source Delta Lake padronizou as funcionalidades das tabelas, mas alguns clientes ainda utilizam versionamento de protocolo legado. Como alguns clientes podem não suportar todas as funcionalidades, a Databricks recomenda que verifique com a documentação do cliente e a compatibilidade dos testes antes de ativar novas funcionalidades nas tabelas de produção.

O Apache Iceberg usa uma única format-version em vez de versões separadas para leitura e escrita. Uma versão em formato Iceberg indica quais as funcionalidades disponíveis, mas não obriga a sua utilização. As funcionalidades são opt-in, exceto o rastreamento de linhas, que é obrigatório na versão 3 do formato. Quando uma característica mostra N/A na coluna do Icebergue, é uma característica específica do Delta sem um equivalente direto ao Iceberg.

A tabela seguinte lista os requisitos de versão do protocolo para as funcionalidades das tabelas Delta Lake e Apache Iceberg. O tipo de característica indica se uma funcionalidade deve ser respeitada apenas para escritas ou para ambas as leituras e escritas.

(1): O agrupamento líquido implementa partição oculta.

(2): Requer que o mapeamento de colunas esteja ativado.