Un registre de schémas est un service centralisé qui stocke, gère et valide les schémas utilisés pour sérialiser et désérialiser les données échangées via Apache Kafka. Plutôt que de permettre à chaque application Producteur et Consommateur de définir de manière indépendante les formats de messages, un registre de schémas fournit une « source de référence » partagée qui explique la manière dont sont structurées les données d’événements.
Dans Kafka, les événements sont souvent sérialisés à l’aide de formats comme Apache Avro, JSON Schema ou Protocol Buffers, souvent abrégés en protobuf. Le registre de schémas stocke les définitions de ces formats et attribue à chaque schéma un identifiant unique. C’est ce que l’on appelle l’identifiant du schéma.
Lorsqu’un producteur écrit un message dans une rubrique Kafka, il inclut généralement l’identifiant du schéma avec les données sérialisées plutôt que d’intégrer l’intégralité du schéma dans chaque message. Les consommateurs de messages récupèrent alors le schéma correspondant depuis le registre et l’utilisent pour désérialiser et interpréter correctement les données.
Un registre de schémas est important dans un système basé sur les événements, car il permet de s’assurer que les producteurs et les consommateurs s’accordent sur la structure des données échangées, ce qui favorise la qualité et l’intégrité des données.
Sans registre centralisé, les applications devraient gérer les schémas de messages de manière indépendante, ce qui augmente le risque de modifications incompatibles susceptibles de provoquer des défaillances chez les consommateurs d’événements ou une mauvaise interprétation des données.
Le registre de schémas prend également en charge ce que l’on appelle l’évolution des schémas. Cela permet aux développeurs de modifier les structures d’événements au fil du temps tout en préservant la compatibilité avec les applications existantes.
Par exemple, il est souvent possible d’ajouter un nouveau champ optionnel sans briser le format attendu par les consommateurs Kafka existants. Les règles de compatibilité permettent de garantir la sécurité des modifications de schéma avant de les déployer.
Restez au fait des tendances les plus étonnantes du secteur dans le domaine de l’IA, de l’automatisation, des données et bien d’autres avec la newsletter Think. Consultez la Déclaration de confidentialité d’IBM.
Parmi les autres avantages importants figure l’amélioration de la gouvernance des données. Les schémas sont stockés dans un référentiel central, ce qui permet aux entreprises de documenter, d’examiner, de contrôler les versions et d’auditer la structure de leurs données d’événements.
Cette approche facilite le travail des équipes de développement pour :
Dans les plateformes de données modernes, un registre de schémas peut également permettre la mise en place de contrats de données entre les producteurs Kafka et les consommateurs Kafka. Ces contrats définissent non seulement la structure des données, mais aussi les attentes quant à la manière dont ces données devraient évoluer au fil du temps.
En validant les modifications de schéma avant leur publication, un registre de schémas peut aider à empêcher que les modifications radicales ne soient mises en production et à améliorer la fiabilité des architectures pilotées par les événements.
Un registre de schémas fournit un mécanisme centralisé pour la gestion des schémas d’événements, assurant la compatibilité entre ces schémas et prenant en charge les modifications qui leur sont apportées.
Un registre peut également permettre aux développeurs de créer de nouveaux schémas sur des schémas plus anciens, créant ainsi une composition structurée dans les schémas, et de normaliser les noms d’événements grâce à une stratégie de nommage des sujets.
Ces méthodes aident les applications à échanger des données en fonction de l’évolution des systèmes et des exigences.
Un registre de schémas fonctionne en stockant et en gérant les schémas qui définissent la structure des données d’événements échangées entre producteurs et consommateurs. Lorsqu’un producteur envoie des données à une rubrique Kafka, il sérialise le message selon un schéma enregistré et inclut des informations qui permettent d’identifier le schéma correspondant. Un consommateur peut ensuite utiliser ce schéma pour désérialiser et interpréter le message correctement. Au fur et à mesure que les schémas évoluent au fil du temps, le registre peut également appliquer des vérifications de compatibilité aux nouvelles versions de schéma avant leur enregistrement, aidant ainsi les producteurs et les consommateurs à continuer de travailler avec l’évolution des structures de données.
Imaginez un grand détaillant en ligne disposant de plusieurs systèmes générant et consommant des données : un site d’e-commerce, une application mobile, un moteur de recommandations, un système de gestion des stocks, une plateforme d’expédition et une plateforme d’analyse client. Chacun de ces systèmes communique en publiant et en consommant des événements via des clusters Apache Kafka utilisant Confluent Cloud et diffuse ces événements vers un entrepôt de données en utilisant Kafka Connect dans son pipeline de données.
Chaque action sur le site Web génère plusieurs événements dans les systèmes du détaillant. Chaque fois qu’un client passe une commande, le site Web publie un événement
Plusieurs applications en aval consomment le même événement. Le système de gestion des stocks réserve les articles achetés, le système de paiement confirme la transaction et l’entrepôt commence le traitement de la commande. Le moteur de recommandation met à jour les préférences du client, la plateforme analytique enregistre la vente et le service de notification envoie une confirmation par e-mail.
Initialement, l’événement
Imaginez maintenant que, quelques mois plus tard, l’entreprise décide de prendre en charge les ventes à l’international. Les développeurs mettent à jour le site Web afin que chaque commande inclue désormais deux nouveaux champs :
Sans registre de schémas, il n’existe aucun mécanisme centralisé pour coordonner ce changement. Certains consommateurs de données d’événements s’attendent à ces nouveaux champs, tandis que d’autres non. Si un développeur renomme
Alors, à quoi pourrait ressembler le même scénario avec un registre de schémas Confluent destiné à faciliter la gestion des schémas ?
Avant de déployer le producteur mis à jour, l’équipe de développement enregistre une nouvelle version du schéma
Si les modifications proposées respectent ces règles de compatibilité, la nouvelle version du schéma peut être enregistrée. Si une modification enfreint la politique de compatibilité configurée, le registre peut la rejeter avant que les applications ne commencent à utiliser le schéma incompatible.
Cela signifie que les développeurs peuvent détecter les ruptures de schéma pendant le développement, et non après le déploiement. Les consommateurs existants peuvent continuer à fonctionner avec les modifications compatibles, tandis que les équipes de développement peuvent progressivement mettre à jour leurs applications pour utiliser de nouveaux champs lorsqu’elles sont prêtes.
Les avantages d’un registre de schémas deviennent plus importants à mesure que l’entreprise se développe. Des centaines d’applications développées par des dizaines d’équipes d’ingénieurs peuvent échanger des données via des milliers de types d’événements différents.
Sans registre de schémas, chaque équipe devrait coordonner manuellement les modifications de schémas à l’aide de documentation manuscrite, de réunions ou par tâtonnements. Ce processus manuel peut ralentir le développement et augmenter le risque que des modifications incompatibles soient mises en production.
Avec un registre de schémas en place, les schémas d’événements deviennent des actifs gérés de manière centralisée. Les producteurs peuvent publier des données selon des schémas enregistrés, les consommateurs peuvent utiliser ces définitions de schéma pour interpréter les événements entrants et les contrôles de compatibilité peuvent identifier les modifications de schéma incompatibles.
Les nouvelles équipes peuvent également découvrir les définitions d’événements existantes au lieu de procéder à la rétro-ingénierie des formats de messages, ce qui facilite la création de nouvelles applications et l’intégration de nouveaux systèmes.
À mesure que le détaillant évolue, le registre de schémas fournit un moyen centralisé de gérer les schémas d’événements évolutifs entre les producteurs et les consommateurs.
La compatibilité des schémas détermine si les applications utilisant différentes versions d’un schéma peuvent continuer à échanger et à interpréter correctement les données à mesure que les schémas évoluent. Les principaux modes de compatibilité sont la compatibilité descendante, la compatibilité ascendante et la compatibilité totale.
Certains registres de schémas prennent également en charge les versions transitives de ces modes de compatibilité. Au lieu de vérifier la nouvelle version d’un schéma uniquement par rapport à la version précédente, les contrôles de compatibilité transitive la comparent à toutes les versions antérieures pertinentes. Les règles exactes de compatibilité et les modifications autorisées du schéma dépendent du format du schéma et des paramètres de compatibilité du registre.
La compatibilité ascendante est utile lorsque d’anciens producteurs doivent continuer à fonctionner tandis que de nouveaux consommateurs doivent traiter les données provenant de ces anciens producteurs sans interruption. Dans ce cas, la priorité est de s’assurer que les applications nouvellement déployées restent compatibles avec les messages qui sont encore générés par les anciennes versions du logiciel producteur.
Imaginez une installation électrique nationale qui exploite un réseau intelligent. Ce réseau se compose de millions de compteurs intelligents installés dans les foyers et les entreprises. Chacun publie des événements de consommation d’électricité sur Apache Kafka. Ces compteurs restent en service pendant des années et leur micrologiciel ne peut recevoir de mises à jour que pendant les périodes de maintenance programmées. Cela signifie que de nombreux compteurs continuent de produire des événements à l’aide d’un ancien schéma bien après la publication des nouvelles versions du logiciel.
Dans le même temps, l’installation met régulièrement à niveau ses applications de surveillance et d’analyse. Une nouvelle version de la plateforme analytique prend en charge des informations supplémentaires, telles que les indicateurs de qualité de l’énergie et la production d’énergie renouvelable. Ces nouveaux champs sont utiles lorsqu’ils sont disponibles, mais la plateforme doit continuer à traiter les données provenant d’anciens compteurs qui ne les transmettent pas.
Dans ce scénario, la compatibilité ascendante est plus importante que la compatibilité avec une version antérieure, car les consommateurs sont mis à jour en premier, tandis que de nombreux producteurs restent sur des versions de schéma plus anciennes. Le nouveau logiciel grand public doit être capable de lire correctement les événements écrits avec des schémas plus anciens, même si ces événements ne disposent pas des champs nouvellement introduits. L’application peut traiter les champs manquants comme facultatifs ou leur attribuer des valeurs par défaut tout en continuant à exécuter ses fonctions principales.
Si la compatibilité descendante était la principale préoccupation, les développeurs s’attacheraient plutôt à garantir que les nouveaux consommateurs puissent lire les données écrites avec les anciens schémas de production. Cependant, le défi immédiat de l’entreprise est de soutenir une flotte durable d’appareils anciens tout en modernisant les systèmes de traitement centralisés.
L’utilisation d’un registre de schémas avec des règles de compatibilité appropriées permet à l’installation d’électricité de faire évoluer ses schémas d’événements sans avoir à mettre à jour simultanément des microprogrammes sur des millions de compteurs déployés. Cela permet un déploiement progressif au cours duquel les producteurs et les consommateurs peuvent être mis à jour à différents moments, tout en respectant les exigences de compatibilité configurées par l’entreprise.
Un registre de schémas peut soutenir les efforts de conformité concernant les réglementations sur la confidentialité des données, telles que le Règlement général sur la protection des données (RGPD) et le California Consumer Privacy Act (CCPA).
Bien qu’un registre de schémas ne garantisse pas la conformité à lui seul, il peut aider les entreprises à mettre en œuvre des pratiques de gouvernance des données, de cohérence et d’audit permettant de répondre aux exigences réglementaires.
L’un des principaux avantages réside dans une meilleure visibilité sur les données en cours de traitement.
Chaque schéma d’événement est stocké dans un dépôt centralisé, qui documente les champs représentés dans le schéma. Cela fournit une source d’information sur les données existantes, ce que représentent les champs spécifiques et la structure des applications des données qu’elles produisent ou consomment.
Cela peut aider les organisations à identifier les schémas contenant des données personnelles, telles que des noms, des adresses e-mail ou des numéros de compte.
Un registre de schémas peut également prendre en charge la minimisation des données, l’un des principes du RGPD.
Avant qu’un schéma ne soit approuvé, les développeurs et les équipes de gouvernance des données peuvent évaluer si chaque champ est nécessaire à l’objectif commercial prévu. Ce processus d’examen peut aider à empêcher les applications de collecter ou de partager des données personnelles inutiles.
La validation des schémas peut également contribuer à prévenir les modifications non autorisées ou accidentelles qui introduisent de nouvelles données sensibles dans les systèmes de production.
Par exemple, si un développeur tente d’ajouter le numéro de sécurité sociale ou le numéro de permis de conduire d’un client à un événement Kafka existant, le schéma proposé peut être examiné avant d’être déployé.
Cette approche crée un point de contrôle de gouvernance supplémentaire en parallèle des tests d’applications normaux.
La gestion des versions et l’historique des schémas fournissent des fonctionnalités d’audit.
Chaque évolution de schéma est enregistrée, permettant aux entreprises de déterminer quand les champs ont été ajoutés, modifiés ou supprimés.
Lors d’un audit de conformité, cet historique peut aider à démontrer que les structures de données sont gérées de manière contrôlée et traçable.
Un registre de schémas peut également améliorer la cohérence entre plusieurs systèmes.
Étant donné que les producteurs et les consommateurs s’appuient sur des définitions de schéma communes, les applications peuvent interpréter les champs selon des définitions structurelles courantes.
Cela peut réduire la gestion incohérente des données entre les applications.
De nombreuses entreprises utilisent un registre de schémas dans le cadre de la mise en œuvre des contrats de données.
Ces contrats définissent non seulement la structure d’un événement, mais aussi les métadonnées sur les données qu’il contient.
La validation automatisée peut alors être utilisée pour vérifier si les nouvelles versions de schéma continuent de répondre aux exigences définies.
Les registres de schémas peuvent également s’intégrer à des outils plus larges de gouvernance des données et de sécurité.
Les métadonnées stockées aux côtés des schémas peuvent être utilisées par des systèmes comme :
Un registre de schémas peut donc constituer un composant d’une architecture de gouvernance plus large.
Associée au chiffrement, aux contrôles d’accès, aux politiques de conservation des données et à la journalisation des audits, la gestion des schémas peut aider les organisations à gérer la manière dont les données personnelles sont collectées, traitées et partagées.
Plusieurs plateformes offrent des fonctionnalités de registre de schémas pour Kafka et les systèmes de données associés.
Confluent Schema Registry est un registre de schémas spécifique à Kafka largement utilisé.
Il fait partie du système Confluent et est disponible à la fois comme composant autogéré de la plateforme Confluent et comme service géré dans Confluent Cloud.
Il prend en charge Avro, Protobuf et JSON Schema et permet la gestion des versions de schémas, les règles de compatibilité, la validation et l’intégration aux producteurs et aux consommateurs Kafka.
Amazon Web Services propose AWS Glue Schema Registry.
Il s’agit d’un registre de schémas géré qui s’intègre à Apache Kafka, Amazon Managed Streaming for Apache Kafka (MSK), Amazon Kinesis, Amazon Managed Service for Apache Flink et AWS Lambda.
Il prend en charge Avro, JSON Schema et Protobuf.
Apicurio Registry est un registre open source de schémas et d’artefacts d’API qui peut être utilisé avec Kafka.
Il prend en charge des formats tels que Avro, JSON Schema et Protobuf et peut être déployé dans des environnements tels que Kubernetes.
Apicurio offre également une compatibilité avec l’API Confluent Schema Registry, ce qui peut faciliter son utilisation avec les applications Kafka conçues autour des interfaces de registre de schémas de Confluent.
Redpanda inclut également un service compatible avec registre de schémas dans sa plateforme de diffusion compatible avec Kafka.
Cette approche peut s’avérer utile lorsqu’une entreprise utilise Redpanda plutôt qu’Apache Kafka directement, car la gestion des schémas peut être assurée au sein même de la plateforme de diffusion.
Le registre Redpanda est mieux intégré à une plateforme de diffusion alternative compatible avec Kafka.
Non, aucun registre de schémas ne fait partie du logiciel Apache Kafka de base. Kafka stocke et transporte les enregistrements. Un registre de schémas est un service distinct qui stocke et gère les schémas pour les données contenues par ces enregistrements. Les registres de schémas sont couramment utilisés avec Kafka pour aider les producteurs et les consommateurs à interpréter de manière cohérente les données d’événements structurées.
Un identifiant de schéma est un identifiant pour une définition particulière de schéma. Une version de schéma indique où ce schéma apparaît dans la séquence de versions préservées pour un schéma ou un sujet particulier. L’implémentation exacte varie selon le registre. Dans Confluent Schema Registry, par exemple, un identifiant de schéma identifie de manière unique le schéma dans le registre, tandis que la version appartient à un sujet. Un même schéma peut donc avoir le même identifiant de schéma tout en étant associé à différentes versions sous différents sujets.
Un registre de schémas stocke et gère principalement des schémas lisibles par machine utilisés par les applications pour comprendre la structure des données. Il peut également fournir des fonctionnalités telles que la gestion des versions de schémas et les vérifications de compatibilité.
Un catalogue de données a pour objectif plus large d’aider les personnes et les systèmes à découvrir, comprendre et gérer les actifs de données au sein d’une entreprise. Un catalogue peut contenir des descriptions métier, des informations sur la propriété, des classifications et d’autres métadonnées concernant les jeux de données et les systèmes de données. Les registres de schémas et les catalogues de données peuvent donc se compléter. Le registre gère les schémas utilisés par les applications, tandis que le catalogue fournit des informations plus générales sur les actifs de données de l’entreprise.
Un schéma définit la structure des données, incluant des éléments tels que les champs et les types de données. Un contrat de données peut inclure le schéma, mais également définir les attentes générales entre les producteurs de données et les consommateurs. Un schéma peut être un composant d’un contrat de données, au même titre que les contraintes d’intégrité, les métadonnées et les politiques.
Le choix du registre de schémas dépend des exigences techniques de l’entreprise et de son architecture de données existante. Les facteurs à prendre en compte incluent les formats de schéma pris en charge par le registre, ses règles de compatibilité, l’intégration à Apache Kafka et à d’autres systèmes de données, la prise en charge de l’API et des clients, les capacités de sécurité et d’authentification, ainsi que la nature gérée ou auto-gérée du service.
Les organisations peuvent également envisager comment le registre prend en charge l’évolution des schémas, la gouvernance des données, les métadonnées et les contrats de données, ainsi que sa compatibilité avec les producteurs, consommateurs et pipelines de données existants. Différents produits de registre offrent différentes combinaisons de ces fonctionnalités, donc la sélection dépend généralement des systèmes et des exigences que le registre doit prendre en charge.