Les pipelines qui rejettent à l'ingestion un changement de schéma source inattendu le détectent plus tôt en amont, mais échouent plus souvent que les pipelines qui forcent la conversion

Hypothèse

Lorsqu'un système source change la forme de ce qu'il émet, un pipeline peut, à l'ingestion, faire l'une de deux choses. Il peut comparer le schéma entrant avec le schéma déclaré et faire échouer la tâche sur toute différence qu'il ne peut résoudre ; les règles de résolution de schéma de la spécification Avro fonctionnent ainsi, signalant une erreur, par exemple, quand le schéma d'enregistrement du lecteur a un champ sans valeur par défaut que le schéma de l'écrivain ne fournit pas. Ou il peut forcer la conversion (coercion) : ajouter les colonnes manquantes en tant que null, abandonner les colonnes inconnues, convertir quand c'est possible, et continuer de fonctionner. Le mode strict est communément qualifié de fragile et le mode permissif de dangereux, avec peu de preuves sur l'ampleur de ce compromis. L'hypothèse est que les deux intuitions sont justes et que les ampleurs comptent : les pipelines stricts détectent les changements de schéma en amont dès une exécution planifiée et laissent presque jamais passer un changement inaperçu, au prix d'un nombre d'exécutions échouées plusieurs fois plus élevé, la plupart pour des changements qui auraient été inoffensifs ; les pipelines qui forcent la conversion échouent moins et laissent un nombre significatif de changements atteindre les consommateurs sans être remarqués, avec des délais de détection de l'ordre de jours plutôt que d'heures.

Prédiction

Sur les mêmes sources et la même période, le pipeline strict présente un temps médian plus court entre un changement de schéma en amont et sa première détection (une exécution en échec) que le pipeline qui force la conversion (une plainte de consommateur, une alerte de qualité des données ou un audit ultérieur), davantage d'exécutions en échec, une proportion plus élevée d'échecs jugés a posteriori inoffensifs, et moins de changements de schéma ayant atteint une table de consommateur sans détection enregistrée. Si le pipeline qui force la conversion détecte les changements à peu près aussi vite, ou si les échecs supplémentaires du pipeline strict concernent surtout des changements nuisibles, l'hypothèse est fausse sur ce point.

Test proposé

1. Diviser les sources d'un même pipeline en deux groupes à fréquence de changement comparable, et faire fonctionner l'un en mode strict et l'autre en mode de conversion forcée pendant au moins six mois.
2. Tenir un registre des changements de schéma : chaque changement en amont, la date de sa prise d'effet, comment il a été détecté en premier, par qui, après combien de temps, et s'il a ensuite été jugé nuisible (valeurs erronées, données perdues, consommateur cassé) ou inoffensif.
3. Compter les exécutions en échec par groupe et classer chaque échec comme lié ou non au schéma ; pour les échecs liés au schéma, consigner si le changement était nuisible.
4. Comparer les distributions des temps de détection, le nombre d'échecs et le nombre de changements nuisibles non détectés ou détectés tardivement ; présenter les résultats par source, car une source bruyante peut dominer.

Statut

Aucun résultat n'est revendiqué. Le registre de l'étape 2 est la partie difficile, car les changements non détectés du pipeline qui force la conversion ne sont, par définition, pas remarqués sur le moment ; un audit périodique du schéma par rapport à la source est nécessaire pour les trouver, et l'intervalle d'audit borne le temps de détection mesurable.