Compatibilité des fonctionnalités et protocoles de 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 Databricks gère les mises à niveau de protocole. Voir aussi Passer en revue les détails de la table avec la description détaillée.
Protocole de table et compatibilité
Chaque table Delta Lake possède 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 de 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, alors cette application ne peut pas lire ou écrire cette table.
La plupart des nouvelles fonctionnalités de 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. |
Lire le protocole | Spécifie le support requis pour qu'un client Delta Lake puisse lire une table. |
Protocole d'écriture | Spécifie le support requis pour qu’un client Delta Lake écrive dans une table. |
| Valeur entière du protocole du lecteur. Les valeurs valides sont |
| Valeur entière du protocole d’écriture. Les valeurs valides sont les nombres entiers de |
Fonctionnalité de table | Une alternative granulaire aux versions de protocole utilisées lorsque |
Fonctionnalité d'écriture | Une fonctionnalité de table qui nécessite la prise en charge du client d'écriture, mais qui ne bloque pas l'accès en lecture seule. |
Fonctionnalité de lecture | Une fonctionnalité de table qui nécessite la prise en charge des clients en lecture et en écriture. Consultez les versions de protocole et les fonctionnalités de table. |
Les protocoles d’écriture et les fonctionnalités d’écriture n’affectent que la compatibilité avec les clients d’écriture, permettant un accès en lecture seule à la table à partir de charges de travail héritées.
Toutes les fonctionnalités de Delta Lake ne sont pas compatibles entre elles.
Certaines fonctionnalités de table ne peuvent pas être supprimées une fois activées. Voir supprimer une fonctionnalité de table Delta Lake et rétrograder le protocole de table.
Versions de protocole et fonctionnalités de table
Toutes les tables Delta Lake incluent une version de protocole basée sur des entiers 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 supérieures, les *fonctionnalités de table* remplacent le protocole basé sur des entiers par des indicateurs granulaires qui indiquent les fonctionnalités utilisées par une table. Cela permet des vérifications de compatibilité plus fines entre les clients et les tables.
Les fonctionnalités d'écriture de table affectent la façon dont les données sont écrites. Ils nécessitent minWriterVersion=7 mais ne bloquent pas les clients lecteurs.
Les fonctionnalités de lecture de table affectent la manière 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 la table sont activées, elles apparaissent dans le protocole en tant que readerFeatures ou writerFeatures. Delta Lake résout le protocole de la table vers la version la plus basse qui prend en charge toutes les fonctionnalités activées. Voir Protocole le plus bas possible.
Databricks inclut un support partiel non bloquant pour les fonctionnalités de table dans toutes les versions prises en charge de Databricks Runtime. Les clients d'OSS Delta Lake 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 déclassé.
La désactivation d'une fonctionnalité de table n'entraîne pas de déclassement de protocole. Vous devez supprimer la fonctionnalité pour la retirer 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 rétrograder le protocole de table.
Toutes les opérations de changement de protocole entrent en conflit avec les écritures simultanées. Les lectures en streaming échouent lorsqu'elles rencontrent un commit qui modifie les métadonnées de la table. Pour continuer, redémarrez les flux concernés. Pour les méthodes recommandées, consultez Considérations de production pour Structured Streaming.
Databricks vous recommande de ne jamais modifier directement les propriétés de table minReaderVersion et minWriterVersion. La modification de ces propriétés n'empêche pas les mises à niveau de protocole, et leur affectation d'une valeur inférieure ne déclassera pas la table. Voir la fonctionnalité de suppression de table Delta Lake et la rétrogradation du protocole de table.
Qu'est-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 du protocole sont Trigger de la manière suivante :
- Activer automatiquement en fonction de la syntaxe utilisée dans les instructions
CREATEouALTER. Par exemple,CLUSTER BYdans une instructionCREATE TABLEactive automatiquement le liquid clustering, etGENERATED ALWAYS ASactive les colonnes générées. - Activez explicitement via les propriétés de la table. Par exemple, la configuration de
'delta.enableDeletionVectors' = trueactive les vecteurs de suppression. - L'activation d'une fonctionnalité peut activer automatiquement les fonctionnalités requises. Par exemple, l'activation d'UniForm active automatiquement le mappage de colonnes, et l'activation du clustering liquide active automatiquement le checkpoint V2. Consultez la documentation Databricks pertinente pour déterminer les fonctionnalités de table requises par une fonctionnalité donnée.
Les fonctionnalités du lecteur mettent à niveau les protocoles de lecture et d'écriture. Par exemple, le mappage de colonnes est une fonctionnalité du lecteur et nécessite la mise à niveau des deux protocoles, car les données sont stockées différemment dans le stockage.
Les fonctionnalités de rédaction, telles que les contraintes CHECK, ne mettent à niveau que le protocole d'écriture.
La plupart des mises à niveau des versions de protocole sont irréversibles et peuvent rompre les lecteurs, les écrivains ou les deux de table Delta Lake existants. Ne mettez à niveau les tables spécifiques qu'en cas de besoin, et vérifiez que tous les outils de production actuels et futurs prennent en charge la nouvelle version du protocole.
Les rétrogradations de protocole sont disponibles pour certaines fonctionnalités. Voir supprimer une fonctionnalité de table Delta Lake et rétrograder le protocole de table.
Protocole le plus bas possible.
Delta Lake résout le protocole de table à la version la plus basse qui prend en charge toutes les fonctionnalités activées. Cela ne peut que réduire minReaderVersion ou minWriterVersion, jamais les augmenter. Les fonctionnalités de table ne sont jamais supprimées automatiquement. Utilisez DROP FEATURE pour supprimer une fonctionnalité de table du protocole.
Si toutes les fonctionnalités activées sont entièrement prises en charge par une version de protocole inférieure basée sur des entiers, la table peut revenir à cette version et supprimer readerFeatures ou writerFeatures 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é de Databricks et Databricks Runtime
Databricks introduit la prise en charge de nouvelles fonctionnalités Delta Lake dans les versions de Databricks Runtime :
- Les tables écrites par une version inférieure de Databricks Runtime bénéficient d'un support complet en lecture et en écriture dans les versions supérieures de Databricks Runtime.
- Les tables écrites par une version supérieure de Databricks Runtime peuvent utiliser des fonctionnalités de table non prises en charge dans les versions inférieures de Databricks Runtime.
- Certaines fonctionnalités autorisent les écritures à partir de versions antérieures de Databricks Runtime sans appliquer entièrement toutes les optimisations de la fonctionnalité activée.
Si vous utilisez uniquement des tables Delta Lake via Databricks, vous n'avez qu'à 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ées
Dans Databricks Runtime 12,2 LTS et versions supérieures, les *fonctionnalités de table* ont remplacé le protocole basé sur les entiers par des indicateurs granulaires qui indiquent les fonctionnalités utilisées par une table.
Databricks a rétroporté la prise en charge des fonctionnalités de table vers Databricks Runtime 11.3 LTS et versions antérieures, au lieu de ne prendre en charge que 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. Cependant, 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 de fonctionnalités de table avec un support rétroporté, certaines opérations disponibles dans une version donnée de Databricks Runtime peuvent ne pas être disponibles dans la version correspondante d'OSS Delta Lake. Si votre architecture comprend des clients OSS Delta Lake, testez la compatibilité avant d'activer les fonctionnalités de table sur les tables de production.
Fonctionnalités de Delta Lake et versions de Databricks Runtime requises
Le tableau suivant répertorie la version la plus basse de Databricks Runtime avec une prise en charge complète de chaque fonctionnalité, de sorte que toutes les capacités généralement disponibles pour les lectures et les écritures soient prises en charge.
Fonctionnalité | Nécessite la version Databricks Runtime ou ultérieure | Documentation |
|---|---|---|
| Toutes les versions de Databricks Runtime prises en charge | |
Flux de données de modification | Toutes les versions de Databricks Runtime prises en charge | |
Colonnes générées | Toutes les versions de Databricks Runtime prises en charge | |
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 | |
Fonctionnalités de la table | Toutes les versions de Databricks Runtime prises en charge | |
Vecteurs de suppression | Toutes les versions de Databricks Runtime prises en charge | |
TimestampNTZ | Databricks Runtime 13.3 LTS | |
UniForm | Databricks Runtime 13.3 LTS | Lire les tables Delta Lake avec des clients Iceberg à l'aide de UniForm |
Clustering fluide | Databricks Runtime 13.3 LTS | |
Suivi des lignes | Databricks Runtime 14.3 LTS | |
Élargissement de type | Databricks Runtime 15.4 LTS | |
Variante | Databricks Runtime 15.4 LTS | Prise en charge des types de variantes pour Apache Iceberg et Delta Lake |
Classements | Databricks Runtime 16.1 | |
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 |
Commits de catalogue | Databricks Runtime 16.4 LTS |
Consultez les versions et la compatibilité des notes de publication de Databricks Runtime.
LakeFlow Pipelines et Databricks SQL mettent automatiquement à niveau les environnements d'exécution avec des versions régulières pour prendre en charge les nouvelles fonctionnalités. Voir les notes de version de LakeFlow Pipelines et le processus de mise à niveau de la version et les notes de version de Databricks SQL.
Fonctionnalités par version de protocole
Pour la compatibilité Databricks Runtime, consultez Compatibilité Databricks et Databricks Runtime.
Delta Lake utilise des valeurs minReaderVersion et minWriterVersion distinctes pour spécifier les capacités du protocole. Le protocole open source Delta Lake a standardisé les fonctionnalités de table, mais certains clients utilisent encore des versions de protocole héritées. Étant donné que certains clients peuvent ne pas prendre en charge toutes les fonctionnalités, Databricks vous recommande de vérifier la documentation de votre client 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 de lecteur et d'enregistreur séparées. Une version du format Iceberg indique les fonctionnalités disponibles, mais n'en impose pas l'utilisation. Les fonctionnalités sont facultatives, à l'exception du suivi des lignes qui est 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 dans Iceberg.
Le tableau suivant répertorie les exigences de version de protocole pour les fonctionnalités de table Delta Lake et Apache Iceberg. Le type de fonctionnalité indique si une fonctionnalité doit être prise en compte uniquement pour les écritures ou pour les lectures et les écritures.
Fonctionnalité | Delta | Delta | Iceberg | Type de fonctionnalité |
|---|---|---|---|---|
2 | 1 | 1 | Agent d'écriture | |
3 | 1 | N/A | Agent d'écriture | |
4 | 1 | N/A | Agent d'écriture | |
4 | 1 | N/A | Agent d'écriture | |
5 | 2 | N/A | Lecteur et rédacteur | |
6 | 1 | N/A | Agent d'écriture | |
7 | 1 | 3 | Agent d'écriture | |
7 | 3 | 3 | Lecteur et rédacteur | |
7 | 3 | 1 | Lecteur et rédacteur | |
7 | 3 | 1 | Lecteur et rédacteur (1) | |
7 | 2 | N/A | Écriture (2) | |
7 | 3 | N/A | Lecteur et rédacteur | |
7 | 3 | 3 | Lecteur et rédacteur | |
7 | 3 | 3 | Lecteur et rédacteur | |
7 | 3 | N/A | Lecteur et rédacteur | |
7 | 1 | N/A | Agent d'écriture | |
7 | 3 | N/A | Lecteur et rédacteur |
(1) : Le clustering liquide met en œuvre un partitionnement caché.