Si votre organisation produit des données d’événements via Kafka ou des plateformes de streaming similaires, les schema registries fournissent une application des contrats en amont de l’entrepôt. C’est un monde différent de l’ELT par batch, mais il est pertinent pour les analytics engineers qui consomment des flux d’événements — et c’est l’exemple le plus mature de validation au moment de l’écriture dans l’écosystème data.
Ce que fait un schema registry
Un schema registry stocke des schémas — généralement au format Avro, Protobuf ou JSON Schema — et applique des règles de compatibilité quand les producteurs tentent d’enregistrer de nouvelles versions. Quand un producteur publie un message vers un topic Kafka, le sérialiseur vérifie le message par rapport au schéma enregistré. Si le message n’est pas conforme, il est rejeté au moment de l’écriture. Les données invalides n’atteignent jamais le topic, et par conséquent aucun consommateur ni entrepôt en aval.
Confluent Schema Registry est l’implémentation la plus répandue. AWS Glue Schema Registry et Apicurio Registry sont des alternatives, mais le modèle de compatibilité est né chez Confluent et les concepts se transfèrent.
Modes de compatibilité
Les modes de compatibilité correspondent directement aux garanties du contrat. Ils contrôlent quels types d’évolution de schéma sont autorisés quand un producteur enregistre une nouvelle version :
- BACKWARD — les nouveaux consommateurs peuvent lire les données écrites avec l’ancien schéma. Vous pouvez ajouter des champs optionnels ou supprimer des champs. C’est le mode par défaut et le plus courant en pratique.
- FORWARD — les anciens consommateurs peuvent lire les données écrites avec le nouveau schéma. Vous pouvez supprimer des champs optionnels ou ajouter des champs avec des valeurs par défaut. Cela protège les consommateurs qui n’ont pas encore été mis à jour.
- FULL — requiert à la fois la compatibilité backward et forward. Le mode le plus strict pour l’évolution individuelle des schémas.
- NONE — pas de vérification de compatibilité. Les changements de schéma sont sans contrainte. Utile uniquement pendant le développement initial.
Les variantes transitives (BACKWARD_TRANSITIVE, FORWARD_TRANSITIVE, FULL_TRANSITIVE) vérifient contre toutes les versions historiques, pas seulement la plus récente. Les modes non transitifs vérifient uniquement le nouveau schéma par rapport à la version immédiatement précédente. En production, les modes transitifs sont plus sûrs car ils empêchent qu’une séquence de changements individuellement compatibles crée un écart incompatible entre des versions distantes.
Pour les besoins de l’analytics engineering, la compatibilité BACKWARD est généralement ce que vous souhaitez. Cela signifie que vos consommateurs (y compris vos jobs de chargement en entrepôt) peuvent toujours lire les nouvelles données. Si l’équipe en amont ajoute un nouveau champ optionnel à un événement, il passe de manière transparente. S’il tente de supprimer un champ obligatoire ou de changer un type, le registry rejette la nouvelle version du schéma.
Règles de validation avec CEL
Au-delà de la compatibilité structurelle, Confluent Schema Registry prend en charge des règles de validation utilisant CEL (Common Expression Language). Ces règles appliquent des contraintes de contenu au moment de l’écriture — pas seulement « le message a-t-il les bons champs ? » mais « les valeurs de ces champs sont-elles valides ? »
rule = Rule( name="age_must_be_positive", kind="CONDITION", mode="WRITE", type="CEL_FIELD", expr="message.age > 0", on_failure="ERROR")Les messages qui échouent à la validation sont rejetés au moment de l’écriture. Selon la configuration, ils peuvent déclencher une erreur (bloquant le producteur), être routés vers une dead letter queue pour investigation, ou être silencieusement ignorés. Le pattern de production le plus courant est le mode ERROR pour les règles critiques et le routage DLQ pour les règles où certaines données non conformes sont attendues.
Les règles CEL sont effectivement des vérifications de qualité de données embarquées qui s’exécutent avant que les données ne soient persistées. Une règle comme message.amount > 0 fait la même chose qu’un test dbt_expectations.expect_column_values_to_be_between, mais elle s’exécute au point de production plutôt qu’après le chargement. Les données invalides n’existent jamais dans l’entrepôt en premier lieu.
Pratiques de production
Pour les équipes analytics qui consomment des topics Kafka, plusieurs pratiques de production valent la peine d’être connues :
Désactivez l’auto-registration en production. Définir auto.register.schemas=false empêche les producteurs d’enregistrer de nouvelles versions de schéma à l’exécution. Tous les changements de schéma doivent être pré-enregistrés via des pipelines CI/CD. Cela force chaque changement de schéma à passer par une revue de code — ce qu’un contrat devrait faire.
Utilisez CI/CD pour l’enregistrement de schémas. Le workflow : un développeur propose un changement de schéma dans une pull request. Le CI vérifie la compatibilité avec le registry. Si la vérification de compatibilité passe et que les reviewers approuvent, la nouvelle version du schéma est enregistrée lors du déploiement. Cela reproduit le fonctionnement des contrats d’API en ingénierie logicielle : le changement d’interface est revu, approuvé et déployé via un processus contrôlé.
Définissez la stratégie de nommage des sujets sur TopicRecordNameStrategy. Le TopicNameStrategy par défaut lie un schéma à un topic. TopicRecordNameStrategy permet plusieurs types d’événements par topic, chacun avec son propre schéma. Pour l’analytics, cela compte car un seul topic peut transporter plusieurs types d’événements (pages vues, clics, conversions) qui ont des schémas différents mais partagent une couche de transport.
Surveillez les échecs de compatibilité. Quand le changement de schéma d’un producteur est rejeté par le registry, c’est une violation de contrat. Suivez ces rejets pour comprendre à quelle fréquence les équipes en amont tentent des changements incompatibles et quelles équipes ont besoin de plus de sensibilisation aux dépendances en aval.
Où s’appliquent les schema registries
Yali Sassoon de Snowplow a fait une distinction utile qui délimite où les schema registries — et les contrats plus largement — peuvent réellement fonctionner : les contrats fonctionnent bien pour les données créées délibérément (des événements que vous définissez et émettez) mais sont impraticables pour les exports SaaS où vous ne contrôlez pas le schéma.
Les schema registries sont le mécanisme d’application pour les données créées délibérément. Votre équipe d’ingénierie définit le schéma d’événement, contrôle l’émetteur, et peut appliquer les changements via le registry. Cela s’applique à :
- Les flux d’événements internes (actions utilisateurs, événements système, enregistrements de transactions)
- La communication microservice-à-microservice via bus d’événements
- La télémétrie IoT où vous contrôlez le firmware des appareils
- Tout pipeline de données où le producteur est un logiciel que votre organisation possède
Les schema registries ne s’appliquent pas à :
- Les exports de données SaaS (Salesforce, HubSpot, Google Ads) — vous ne contrôlez pas le schéma source
- Les réplications de bases de données depuis des systèmes tiers
- Les extractions d’API batch où le fournisseur peut changer le format de réponse
- Les échanges de données basés sur des fichiers où le format n’est pas appliqué par l’infrastructure
Pour les sources batch sans schema registry, l’application doit se faire au niveau de l’outil EL ou après le chargement. Le concept de contrat s’applique toujours — vous avez toujours besoin d’attentes sur ce à quoi les données devraient ressembler — mais le mécanisme d’application est différent.
Pertinence pour les analytics engineers
Les analytics engineers consomment généralement des données d’événements depuis des schema registries plutôt que de les opérer. Si une organisation utilise Kafka avec un schema registry, les données d’événements dans l’entrepôt ont déjà passé des vérifications de compatibilité et une validation de contenu. La stratégie de test de source peut être calibrée en conséquence — les surprises structurelles venant de sources appliquées par registry sont moins probables.
Les schema registries illustrent que l’application de contrats en amont à grande échelle est faisable. Le pattern « valider avant de persister » est une infrastructure standard pour les architectures event-driven dans les grandes entreprises tech. Étendre la même discipline aux pipelines batch et aux données SaaS — où l’outillage est moins mature — est le défi ouvert décrit dans Défis d’adoption des contrats de données.