Évolution de schéma avec Avro et Parquet : schémas lecteur et écrivain, fusion de fichiers et modes de compatibilité

Ce que c'est

Les lecteurs doivent composer avec des enregistrements écrits sous une autre version de schéma. La spécification Avro (citée) résout le schéma de l'écrivain, qui voyage avec les données, face au schéma du lecteur, attendu par l'application. Les champs des enregistrements sont appariés par nom, l'ordre n'a pas d'importance ; un champ de l'écrivain absent chez le lecteur est ignoré ; un champ du lecteur absent chez l'écrivain prend la valeur par défaut du lecteur, et en l'absence de valeur par défaut, une erreur est signalée. Les promotions se font dans un seul sens (int vers long, float ou double ; long vers float ou double ; float vers double) ; string et bytes sont interchangeables. Parquet n'a pas d'étape de résolution : chaque fichier porte son propre schéma, et la documentation de Spark (citée) décrit la fusion des schémas de fichiers différents mais mutuellement compatibles, désactivée par défaut en tant qu'opération relativement coûteuse, et activable par lecture avec mergeSchema. La documentation du Confluent Schema Registry (citée) nomme les modes de compatibilité qu'un registre peut imposer : ascendante (« backward », les consommateurs utilisant le nouveau schéma peuvent lire les données produites avec le schéma précédent), descendante (« forward », les anciens consommateurs lisent les nouvelles données), totale (« full », les deux), et des variantes transitives vérifiées par rapport à toutes les versions antérieures ; ascendante est le mode par défaut, car il permet aux consommateurs de revenir au début d'un topic.

Pourquoi c'est important

Un champ renommé chez le producteur est, pour un lecteur dont le schéma ne porte aucun alias pour l'ancien nom, un champ supprimé et un champ ajouté (Avro possède des alias de champ, mais la spécification laisse leur usage optionnel) ; un champ ajouté sans valeur par défaut casse tous les consommateurs de données anciennes ; un champ dont le type passe de int à string casse la résolution. Ces échecs apparaissent au moment de la lecture, chez des consommateurs que l'auteur du schéma ne connaît pas forcément.

Comment l'appliquer

• Ajouter les champs comme optionnels avec une valeur par défaut (en Avro, une union avec null, valeur par défaut null) ; ne jamais supprimer un champ que des consommateurs lisent encore.
• Traiter un renommage comme un ajout suivi d'une suppression sur deux versions, en écrivant les deux champs entre-temps, sauf si tous les lecteurs respectent les alias.
• Garder des noms de colonnes Parquet stables et se fier aux noms plutôt qu'aux positions ; n'activer la fusion de schémas que pour les lectures qui en ont besoin, et enregistrer le schéma courant dans le catalogue de tables.
• Choisir le mode de compatibilité en fonction de l'ordre de déploiement : ascendante lorsque les consommateurs se déploient en premier, descendante lorsque ce sont les producteurs, totale dans les deux cas.
• Pour un changement incompatible, créer un nouveau sujet, un nouveau topic ou une nouvelle version de table, et écrire dans les deux tant que d'anciens lecteurs existent.

Pièges

Une valeur par défaut Avro doit être une valeur autorisée par le schéma du champ ; pour une union, elle doit correspondre à l'une des branches de l'union. Un symbole d'énumération inconnu du lecteur est une erreur, sauf si l'énumération du lecteur a une valeur par défaut. Des fichiers Parquet issus d'outils différents peuvent diverger sur les types logiques (horodatages, décimaux) même quand les types physiques concordent.

Quel mode de compatibilité impose quelle règle

Un registre n'impose que la direction que nomme son mode. BACKWARD (le mode par défaut de Confluent) vérifie qu'un nouveau schéma de consommateur lit les anciennes données ; il autorise la suppression de champs et l'ajout de champs avec valeur par défaut, et enregistrera donc un schéma de producteur qui supprime un champ que d'anciens consommateurs lisent encore. FORWARD vérifie que les anciens consommateurs lisent les nouvelles données ; il autorise l'ajout de champs et la suppression des seuls champs optionnels. FULL vérifie les deux, et les variantes transitives vérifient par rapport à chaque version antérieure plutôt qu'à la seule dernière. Choisir le mode selon qui se déploie en premier : les consommateurs en premier, BACKWARD ; les producteurs en premier, FORWARD ; inconnu ou nombreux consommateurs, FULL. La règle « ne jamais supprimer un champ que des consommateurs lisent encore » n'est imposée par le registre que sous FORWARD ou FULL.