Comment gérer le changement de schéma avec Apache Pulsar

Les schémas sont une partie essentielle de toute plate-forme de données. Ce sont des métadonnées qui définissent la forme des données ainsi que les noms et les types de données des propriétés. Les schémas sont utiles de deux manières. Premièrement, ils fournissent un modèle fixe pour le format des données, ce qui peut empêcher l'utilisation de données mal formées dans le contexte du schéma. Deuxièmement, les schémas permettent aux utilisateurs de comprendre comment analyser les données et à quoi s'attendre de ses propriétés.

Apache Pulsar est un système de messagerie open source distribué de publication-abonnement (pub-sub) qui permet le transport de données de serveur à serveur en utilisant le schéma . Les messages sont envoyés via des sujets, le producteur plaçant des messages sur ces sujets pour qu'ils soient lus par le consommateur. Un utilisateur peut définir un schéma pour un sujet stocké dans le registre de schémas de Pulsar. Lorsque des messages sont ajoutés au sujet, le courtier Pulsar vérifie que le message est conforme au schéma et s'assure que seuls des messages valides sont envoyés. Le schéma agit comme un contrat entre le producteur et les consommateurs, permettant aux deux parties de connaître le format exact des données.

Au fil du temps, à mesure que les applications évoluent, il se peut que les données produites par l'application changent également. Cependant, les modifications de schéma peuvent affecter les consommateurs en aval des données qui attendent des données dans un format spécifique. Sans moyen de gérer les schémas entre les producteurs et les consommateurs, il est difficile d'apporter des modifications aux données écrites dans les messages ou les événements sans risquer de casser les applications en aval. Pour éviter ce genre de problème, le schéma des messages doit également évoluer au fur et à mesure que de nouvelles propriétés sont ajoutées et permettre aux consommateurs de comprendre les données dans les anciens et les nouveaux formats. Ce concept est connu sous le nom d'évolution de schéma et Pulsar le prend en charge.

Cet article explique pourquoi les schémas évoluent avant de se plonger dans la façon dont Pulsar implémente et prend en charge l'évolution des schémas.

Pourquoi les schémas évoluent

Les schémas fournissent un contexte sur les données brutes. Ils décrivent souvent une entité particulière dans un système, englobant toutes les propriétés de cette entité. Par exemple, vous pouvez avoir une application qui inscrit les utilisateurs. Il stocke les détails des utilisateurs tels que les noms, les adresses e-mail et les âges. Il y aurait un schéma utilisateur décrivant les données sous-jacentes et fournissant un contexte, tel que le nom du champ et le type de données qu'il contient. Le schéma peut ressembler à ceci :

Supposons maintenant que vous vouliez étendre les données capturées pour inclure les données d'adresse et prendre en charge le publipostage direct aux utilisateurs. Vous devrez ensuite développer le schéma pour inclure les nouveaux champs de saisie des adresses, tels que la première ligne de l'adresse, la ville et le code postal. Après avoir inclus ces nouveaux champs, le schéma ressemblera à ceci :

Il s'agit d'une forme simple d'évolution du schéma, car les champs d'origine n'ont pas changé et seuls de nouveaux champs ont été ajoutés. Dans la plupart des cas, cela ne devrait pas être un changement radical pour les consommateurs en aval, car les consommateurs peuvent continuer comme si les nouveaux champs étaient absents. Les consommateurs auraient juste besoin d'être mis à jour pour consommer et utiliser les nouvelles propriétés.

Cependant, les champs existants doivent parfois être modifiés pour prendre en charge de nouvelles fonctionnalités. Par exemple, disons que les utilisateurs n'étaient pas à l'aise de donner un âge exact, et à la place, vous modifiez l'application pour capturer des tranches d'âge comme 18-24, 25-39, 40-49 et 60+. La colonne d'âge aurait besoin que son type de données soit modifié d'entier en chaîne.

Il s'agit d'une évolution de schéma plus complexe, car cela pourrait briser les consommateurs en aval qui traitent la propriété age et s'attendent à ce qu'il s'agisse d'un nombre ou qui analysent le nombre à l'aide d'un langage strictement typé comme Java. Ils pourraient également effectuer des calculs numériques sur la propriété, qui ne fonctionneraient plus dans son nouveau format.

Pour surmonter ce défi, les plates-formes de données peuvent prendre en charge l'évolution du schéma pour gérer des scénarios comme celui-ci. Pulsar reconnaît l'importance du schéma pour le traitement des données ; en fait, il le traite comme un citoyen de première classe en incluant une prise en charge intégrée de l'évolution du schéma. Voyons comment Pulsar fait cela.

Comment Pulsar prend en charge l'évolution des schémas

Pulsar définit les schémas dans une structure de données appelée `SchemaInfo`. Il s'agit d'une structure de données spécifique à Pulsar, qui est elle-même un schéma, qui décrit le schéma des messages transportés via Pulsar. Chaque `SchemaInfo` appartient à un sujet (canal de message) et décrit les messages à produire et à consommer à l'aide de ce sujet.

Chaque `SchemaInfo` a un type qui détaille le type de schéma utilisé. Il peut s'agir d'un nombre entier, d'une chaîne ou d'un schéma complexe tel qu'Avro ou Protobuf.

Soutenir évolution du schéma , Pulsar utilise des contrôles de compatibilité de schéma pour comparer un schéma entrant au(x) schéma(s) connu(s) d'un sujet. Les vérifications de compatibilité de schéma se produisent lorsqu'un producteur ou un consommateur tente de se connecter à un sujet particulier. La stratégie est choisie lors de la configuration du courtier, avec la valeur `schemaCompatibilityStrategy`. Le but est de vérifier les `SchemaInfo` fournis par le client qui se connecte avec les `SchemaInfo` existants pour voir s'ils sont compatibles.

Pulsar prend en charge huit types différents de stratégies de compatibilité de schéma , que vous pouvez définir en fonction des exigences de la modification. Ces stratégies sont également accompagnées de règles décrivant les modifications pouvant être apportées et des indications sur les clients à mettre à jour en premier. (Consultez la documentation liée ci-dessus pour une explication plus approfondie de chaque stratégie de compatibilité).

Revenant aux exemples précédents, implémentons les changements de schéma en utilisant la stratégie de compatibilité de Pulsar. Tout d'abord, commencez par le schéma utilisateur initial (sans l'adresse).

Ce sera la V1 de votre schéma. Ainsi, lorsque vous implémentez un producteur ou un consommateur Pulsar pour la première fois, le `SchemaInfo` de cette version sera stocké, et le producteur et le consommateur fonctionneront comme prévu.

Ensuite, vous souhaitez ajouter les nouveaux champs d'adresse à votre schéma utilisateur. La première étape consiste à consulter les stratégies de compatibilité des schémas et à déterminer celle qui convient le mieux à ce changement. En utilisant la colonne "modifications autorisées" de la documentation, vous recherchez une stratégie permettant l'ajout de nouveaux champs. Cela vous donne BACKWARD, BACKWARD_TRANSITIVE, FORWARD et FORWARD_TRANSITIVE.

BACKWARD doit être utilisé lorsqu'il n'y a aucune garantie que les consommateurs utilisant une ancienne version puissent comprendre le nouveau schéma. FORWARD est utilisé lorsque les consommateurs de la dernière version du schéma peuvent ne pas être en mesure de lire les données dans les anciennes versions. Si vous souhaitez d'abord mettre à jour tous les consommateurs pour qu'ils utilisent le nouveau schéma, utilisez une stratégie BACKWARD. Sinon, FORWARD est le meilleur.

En regardant la situation dans son ensemble, Pulsar fait référence à l'ensemble de l'acte d'évolution du schéma d'un sujet comme vérification de schéma . C'est la combinaison d'un producteur ou d'un consommateur fournissant `SchemaInfo`, la stratégie de compatibilité choisie pour le sujet, et le courtier décidant quoi faire.

Conclusion

Il est rare que les schémas restent les mêmes pour toujours. Au fur et à mesure que de nouvelles fonctionnalités sont introduites dans les applications, les schémas doivent souvent évoluer pour prendre en charge ces fonctionnalités. Cependant, maintenir les producteurs et les consommateurs de données synchronisés peut souvent être un défi lorsque les schémas sont modifiés.

Les concepts d'évolution de schéma intégrés de Pulsar aident à gérer ces changements. À l'aide de stratégies de compatibilité de schéma, il peut définir les règles de compatibilité des différentes versions d'un schéma. Pulsar l'utilise en conjonction avec un processus de vérification de schéma qui utilise ensuite ces règles pour déterminer quels schémas peuvent être utilisés par un consommateur lors de la connexion à un sujet particulier.

Également publié ici.