Compatibilité et protocoles des fonctionnalités Delta Lake

Les protocoles de table Delta Lake spécifient les fonctionnalités qu’un client doit prendre en charge pour lire ou écrire une table. Cette page couvre les versions de protocole, les fonctionnalités de table, les exigences de compatibilité et la façon dont Azure Databricks gère les mises à niveau de protocole. Consultez également les détails du tableau de révision avec les détails de la description.

Protocole de table et compatibilité

Chaque table Delta Lake a une spécification de protocole qui indique l’ensemble des fonctionnalités requises pour lire et écrire dans la table. Les applications utilisent la spécification du protocole pour déterminer si elles peuvent prendre en charge toutes les fonctionnalités utilisées par la table. Si une application ne peut pas prendre en charge une fonctionnalité dans le protocole actuel d’une table, cette application ne peut pas lire ou écrire cette table.

La plupart des nouvelles fonctionnalités Delta Lake vous obligent à mettre à niveau le protocole de table.

Le tableau suivant répertorie les termes clés qui décrivent les protocoles Delta Lake :

Terme	Description
Client Delta Lake	Tout système qui lit ou écrit dans une table Delta Lake.
Protocole de lecture	Spécifie la prise en charge requise pour qu’un client Delta Lake lise une table.
Protocole d’écriture	Spécifie la prise en charge requise pour qu’un client Delta Lake écrive dans une table.
minReaderVersion	Valeur entière du protocole lecteur. Les valeurs valides sont 1, 2ou 3.
minWriterVersion	Valeur entière du protocole writer. Les valeurs valides sont des entiers 2 via 7.
Fonctionnalité de table	Alternative affinée aux versions de protocole utilisées quand minReaderVersion = 3 et minWriterVersion = 7. Les fonctionnalités de tableau correspondent à des fonctionnalités Delta Lake pouvant être activées de manière optionnelle.
Fonctionnalité Writer	Fonctionnalité de table qui nécessite une prise en charge du client d’écriture, mais qui ne bloque pas l’accès en lecture seule.
Fonctionnalité lecteur	Fonctionnalité de table qui nécessite à la fois la prise en charge du client en lecture et en écriture. Consultez les versions du protocole et les fonctionnalités de table.

Les protocoles d’écriture et les fonctionnalités d’enregistreur affectent uniquement la compatibilité avec les clients writer, ce qui autorise l’accès en lecture seule à la table à partir de charges de travail héritées.

Toutes les fonctionnalités Delta Lake ne sont pas compatibles les unes avec les autres.

Certaines fonctionnalités de table ne peuvent pas être supprimées une fois activées. Consultez Supprimer une fonctionnalité de table Delta Lake et passer à une version antérieure du protocole de table.

Versions de protocole et fonctionnalités de table

Toutes les tables Delta Lake incluent une version de protocole basée sur un entier représentée par minReaderVersion et minWriterVersion. Chaque version regroupe plusieurs fonctionnalités et les fonctionnalités sont cumulatives entre les versions. Pour se conformer au protocole Delta Lake, les clients doivent implémenter la prise en charge de toutes les fonctionnalités d’une version donnée, y compris toutes les fonctionnalités précédemment publiées.

Dans Databricks Runtime 12.2 LTS et versions ultérieures, les fonctionnalités de table remplacent le protocole basé sur l’entier par des indicateurs granulaires qui indiquent quelles fonctionnalités une table utilise. Cela permet des vérifications de compatibilité plus précises entre les clients et les tables.

Les fonctionnalités de l’enregistreur de tables affectent la façon dont les données sont écrites. Ils nécessitent minWriterVersion=7 mais ne bloquent pas les clients de lecteur.

Les fonctionnalités de lecteur de table affectent la façon dont les données sont lues. Toutes les fonctionnalités de lecteur sont également des fonctionnalités d’écriture, et nécessitent minReaderVersion=3 et minWriterVersion=7. Un client ne peut pas écrire dans une table qu’il ne peut pas lire.

Lorsque les fonctionnalités de table sont activées, elles apparaissent dans le protocole en tant que readerFeatures ou writerFeatures. Delta Lake résout le protocole de table en version la plus basse qui prend en charge toutes les fonctionnalités activées. Consultez le protocole le plus bas possible.

Note

Azure Databricks inclut la prise en charge partielle non cassant des fonctionnalités de table dans toutes les versions de Databricks Runtime prises en charge. Les clients Delta Lake OSS choisissent comment implémenter la prise en charge des fonctionnalités données.

Modifications du protocole

Le protocole d’une table change dans les conditions suivantes :

• Si une nouvelle fonctionnalité est activée, le protocole est mis à niveau.
• Si une fonctionnalité de table est supprimée, le protocole est rétrogradé.

La désactivation d’une fonctionnalité de table n’entraîne pas de rétrogradation du protocole. Vous devez supprimer la fonctionnalité pour la supprimer entièrement du protocole. Toutes les fonctionnalités de table ne peuvent pas être supprimées. Consultez Supprimer une fonctionnalité de table Delta Lake et passer à une version antérieure du protocole de table.

Toutes les opérations de modification de protocole sont en conflit avec les écritures simultanées. Les lectures en flux échouent lorsqu’elles rencontrent un commit qui modifie les métadonnées d’une table. Pour continuer, redémarrez les flux affectés. Pour connaître les méthodes recommandées, consultez Considérations relatives à la production pour Structured Streaming.

Note

Databricks recommande de ne jamais modifier directement les propriétés et minReaderVersion les propriétés de minWriterVersion la table. La modification de ces propriétés n’empêche pas les mises à niveau de protocole et la définition de ces propriétés sur une valeur inférieure ne rétrograde pas la table. Consultez Supprimer une fonctionnalité de table Delta Lake et passer à une version antérieure du protocole de table.

Ce qui déclenche une mise à niveau de protocole

Lorsque vous activez une fonctionnalité, le protocole de table est automatiquement mis à niveau.

Les mises à niveau de protocole sont déclenchées de la manière suivante :

• Activez automatiquement en fonction de la syntaxe utilisée dans CREATE ou ALTER des instructions. Par exemple, dans une CLUSTER BY instruction, CREATE TABLE active automatiquement le clustering liquide et GENERATED ALWAYS AS active les colonnes générées.
• Activez explicitement par le biais des propriétés de table. Par exemple, le paramètre 'delta.enableDeletionVectors' = true active les vecteurs de suppression.
• L’activation d’une fonctionnalité peut activer automatiquement les fonctionnalités requises. Par exemple, l’activation automatique d’UniForm active automatiquement le mappage de colonnes et l’activation du clustering liquide active automatiquement le point de contrôle V2. Passez en revue la documentation Azure Databricks appropriée pour déterminer les fonctionnalités de table dont une fonctionnalité donnée a besoin.

Les fonctionnalités de lecture mettez à niveau les protocoles de lecture et d’écriture. Par exemple, le mappage de colonnes est une fonctionnalité de lecteur et nécessite la mise à niveau des deux protocoles, car les données sont stockées différemment dans le stockage.

Fonctionnalités d’enregistreur, telles que CHECK les contraintes, mettez à niveau uniquement le protocole d’écriture.

Warning

La plupart des mises à niveau de version de protocole sont irréversibles et peuvent interrompre les lecteurs de table Delta Lake existants, les enregistreurs ou les deux. Mettez à niveau des tables spécifiques uniquement si nécessaire et vérifiez que tous les outils de production actuels et futurs prennent en charge la nouvelle version du protocole.

Il est possible de passer à une version antérieure du protocole pour certaines fonctionnalités. Consultez Supprimer une fonctionnalité de table Delta Lake et passer à une version antérieure du protocole de table.

Protocole possible le plus bas

Delta Lake résout le protocole de table en version la plus basse qui prend en charge toutes les fonctionnalités activées. Cela ne peut que diminuer minReaderVersion ou minWriterVersion, jamais les élever. Les fonctionnalités de table ne sont jamais supprimées automatiquement. Permet DROP FEATURE de supprimer une fonctionnalité de table du protocole.

Si toutes les fonctionnalités activées sont entièrement prises en charge à une version de protocole basée sur un entier inférieur, la table peut revenir à cette version et supprimer readerFeatures ou writerFeatures à partir du protocole. Cela ne désactive aucune fonctionnalité. Les versions de protocole inférieures augmentent la compatibilité, car tous les clients doivent les respecter.

compatibilité Azure Databricks et Databricks Runtime

Azure Databricks introduit la prise en charge des nouvelles fonctionnalités Delta Lake dans les versions de Databricks Runtime :

• Les tables écrites par une version databricks Runtime inférieure ont une prise en charge complète de la lecture et de l’écriture dans les versions ultérieures de Databricks Runtime.
• Les tables écrites par une version databricks Runtime supérieure peuvent utiliser des fonctionnalités de table non prises en charge dans les versions inférieures de Databricks Runtime.
• Certaines fonctionnalités permettent d’écrire à partir de versions inférieures de Databricks Runtime sans appliquer entièrement toutes les optimisations pour la fonctionnalité activée.

Si vous utilisez uniquement des tables Delta Lake via Azure Databricks, vous devez uniquement suivre la prise en charge des fonctionnalités à l’aide des exigences minimales de Databricks Runtime. Si vous lisez ou écrivez des tables à partir de systèmes externes, vous devez vérifier que ces clients prennent en charge les fonctionnalités de table activées sur vos tables.

Prise en charge des fonctionnalités de table rétroportée

Dans Databricks Runtime 12.2 LTS et versions ultérieures, les fonctionnalités de table ont remplacé le protocole basé sur un entier par des indicateurs granulaires qui indiquent les caractéristiques qu’une table utilise.

Azure Databricks prend en charge les fonctionnalités de table rétroportées dans Databricks Runtime 11.3 LTS et ci-dessous, au lieu de prendre uniquement en charge les versions de protocole entier, mais uniquement pour les fonctionnalités déjà prises en charge dans cette version.

Par exemple, vous pouvez lire et écrire dans une table avec des colonnes générées activées à l’aide des fonctionnalités de table dans Databricks Runtime 9.1 LTS. Toutefois, vous ne pouvez pas utiliser Databricks Runtime 9.1 LTS pour lire et écrire dans une table avec des colonnes d’identité activées à l’aide des fonctionnalités de table, car les colonnes d’identité nécessitent Databricks Runtime 10.4 LTS et versions ultérieures.

Lors de l’utilisation des fonctionnalités de table avec prise en charge rétroportée, certaines opérations disponibles dans une version databricks Runtime donnée peuvent ne pas être disponibles dans la version correspondante de OSS Delta Lake. Si votre architecture inclut des clients OSS Delta Lake, testez la compatibilité avant d’activer les fonctionnalités de table sur les tables de production.

Fonctionnalités Delta Lake et versions de Databricks Runtime requises

Le tableau suivant répertorie la version databricks Runtime la plus basse avec une prise en charge complète de chaque fonctionnalité, de sorte que toutes les fonctionnalités généralement disponibles pour les lectures et les écritures sont prises en charge.

Fonctionnalité	Nécessite la version Databricks Runtime ou une version ultérieure.	Documentation
CHECK contraintes	Toutes les versions de Databricks Runtime prises en charge	CHECK Contrainte
Modifier le flux de données	Toutes les versions de Databricks Runtime prises en charge	Utiliser le flux de données modifiées sur Azure Databricks
Colonnes générées	Toutes les versions de Databricks Runtime prises en charge	Colonnes générées par Delta Lake
Mappage de colonnes	Toutes les versions de Databricks Runtime prises en charge	Renommer et supprimer des colonnes avec le mappage de colonnes Delta Lake
Colonnes d’identité	Toutes les versions de Databricks Runtime prises en charge	Colonnes d’identité
Fonctionnalités de table	Toutes les versions de Databricks Runtime prises en charge	Versions de protocole et fonctionnalités de table
Vecteurs de suppression	Toutes les versions de Databricks Runtime prises en charge	Vecteurs de suppression dans Databricks
TimestampNTZ	Databricks Runtime 13.3 LTS	Type TIMESTAMP_NTZ
UniForm	Databricks Runtime 13.3 LTS	Lire des tables Delta Lake avec des clients Iceberg à l’aide de UniForm
Regroupement de liquide	Databricks Runtime 13.3 LTS	Utiliser le clustering liquide pour les tables
Suivi des lignes	Databricks Runtime 14.3 LTS	Suivi des lignes dans Azure Databricks
Élargissement du type	Databricks Runtime 15.4 LTS	Élargissement des types
Variant	Databricks Runtime 15.4 LTS	Prise en charge des types variant pour Apache Iceberg et Delta Lake
Classements	Databricks Runtime 16.1	Prise en charge du classement pour Delta Lake
Points de contrôle protégés	Databricks Runtime 16.3	Supprimer une fonctionnalité de table Delta Lake et rétrograder le protocole de table
Validations de catalogue	Databricks Runtime 16.4 LTS	Commits du catalogue

Consultez Notes de publication, versions et compatibilité de Databricks Runtime.

Note

Les pipelines Lakeflow et Databricks SQL mettez automatiquement à niveau les environnements d’exécution avec des versions régulières pour prendre en charge de nouvelles fonctionnalités. Consultez les notes de publication des pipelines Lakeflow et le processus de mise à niveau des versions et les notes de publication databricks SQL.

Fonctionnalités par version de protocole

Note

Pour la compatibilité databricks Runtime, consultez Azure Databricks et la compatibilité databricks Runtime.

Delta Lake utilise des valeurs distinctes minReaderVersion et minWriterVersion pour spécifier des fonctionnalités de protocole. Le protocole Delta Lake open source a normalisé les fonctionnalités de table, mais certains clients utilisent toujours le contrôle de version de protocole hérité. Étant donné que certains clients peuvent ne pas prendre en charge toutes les fonctionnalités, Databricks vous recommande de vérifier avec votre documentation cliente et de tester la compatibilité avant d’activer de nouvelles fonctionnalités sur les tables de production.

Apache Iceberg utilise un seul format-version au lieu de versions distinctes pour le lecteur et l'enregistreur. Une version de format Iceberg indique quelles fonctionnalités sont disponibles, mais n’impose pas leur utilisation. Les fonctionnalités sont optionnelles, à l'exception du suivi des rangées obligatoire dans la version 3 du format. Lorsqu’une fonctionnalité affiche N/A dans la colonne Iceberg, il s’agit d’une fonctionnalité spécifique à Delta sans équivalent direct d’Iceberg.

Le tableau suivant répertorie les exigences de version du protocole pour les fonctionnalités de la table Delta Lake et Apache Iceberg. Le type de fonctionnalité indique si une fonctionnalité doit être respectée uniquement pour les écritures ou pour les lectures et les écritures.

Fonctionnalité	Delta minWriterVersion	Delta minReaderVersion	Iceberg format-version	Type de fonctionnalité
Fonctionnalités de base	2	1	1	Écrivain
CHECK Contraintes	3	1	N/A	Écrivain
Modifier le flux de données	4	1	N/A	Écrivain
Colonnes générées	4	1	N/A	Écrivain
Mappage de colonnes	5	2	N/A	Lecteur et écrivain
Colonnes d’identité	6	1	N/A	Écrivain
Suivi des lignes	7	1	3	Écrivain
Vecteurs de suppression	7	3	3	Lecteur et écrivain
TimestampNTZ	7	3	1	Lecteur et écrivain
Agrégation liquide	7	3	1	Lecteur et enregistreur (1)
Lecteurs Iceberg (UniForm)	7	2	N/A	Writer (2)
Élargissement des types	7	3	N/A	Lecteur et écrivain
Variant	7	3	3	Lecteur et écrivain
Élimination de variantes	7	3	3	Lecteur et écrivain
Jeux de collations	7	3	N/A	Lecteur et écrivain
Points de contrôle protégés	7	1	N/A	Écrivain
Commits du catalogue	7	3	N/A	Lecteur et écrivain

(1) : le clustering liquide implémente le partitionnement masqué.

(2) : Nécessite l’activation du mappage de colonnes.