Pipelines, die beim Einlesen unerwartete Schemaänderungen der Quelle ablehnen, erkennen vorgelagerte Änderungen früher, scheitern aber häufiger als Pipelines, die sie anpassen

Hypothese

Wenn ein Quellsystem die Form dessen ändert, was es ausgibt, kann eine Pipeline beim Einlesen zwei Dinge tun. Sie kann das eingehende Schema mit dem deklarierten vergleichen und den Vorgang bei jeder nicht auflösbaren Abweichung scheitern lassen; so funktionieren die Schema-Resolution-Regeln der Avro-Spezifikation, die zum Beispiel einen Fehler melden, wenn das Datensatzschema des Lesers ein Feld ohne Default enthält, das im Schema des Schreibers fehlt. Oder sie kann anpassen: fehlende Spalten als null ergänzen, unbekannte verwerfen, wo möglich umwandeln, und weiterlaufen. Der strikte Modus gilt gemeinhin als zerbrechlich, der nachgiebige als gefährlich, wobei kaum Belege dazu vorliegen, wie gross diese Kompromisse tatsächlich sind. Die Hypothese lautet, dass beide Einschätzungen zutreffen und dass die Grössenordnung entscheidend ist: Strikte Pipelines erkennen vorgelagerte Schemaänderungen innerhalb eines geplanten Laufs und lassen fast nie eine Änderung unbemerkt durch – auf Kosten mehrfach häufigerer fehlgeschlagener Läufe, von denen die meisten harmlose Änderungen betreffen; anpassende Pipelines scheitern seltener, lassen aber eine relevante Zahl von Änderungen unbemerkt bis zu den Konsumenten durch, mit Erkennungszeiten von Tagen statt Stunden.

Vorhersage

Über dieselben Quellen und denselben Zeitraum hinweg zeigt die strikte Pipeline eine kürzere mediane Zeitspanne von einer vorgelagerten Schemaänderung bis zu ihrer ersten Erkennung (ein fehlgeschlagener Lauf) als die anpassende Pipeline (eine Konsumentenbeschwerde, ein Datenqualitäts-Alarm oder ein späteres Audit), mehr fehlgeschlagene Läufe, einen höheren Anteil nachträglich als harmlos eingestufter Fehlschläge und weniger Schemaänderungen, die eine Konsumententabelle ohne erfasste Erkennung erreicht haben. Erkennt die anpassende Pipeline Änderungen etwa gleich schnell, oder betreffen die zusätzlichen Fehlschläge der strikten Pipeline überwiegend schädliche Änderungen, ist die Hypothese in diesem Teil widerlegt.

Vorgeschlagener Test

1. Die Quellen einer Pipeline in zwei Gruppen mit vergleichbarer Änderungshäufigkeit aufteilen und eine Gruppe mindestens sechs Monate lang strikt, die andere anpassend betreiben.
2. Ein Register der Schemaänderungen führen: jede vorgelagerte Änderung, das Datum ihres Inkrafttretens, wie sie erstmals erkannt wurde, von wem, nach welcher Zeitspanne, und ob sie nachträglich als schädlich (falsche Werte, verlorene Daten, defekter Konsument) oder harmlos eingestuft wurde.
3. Fehlgeschlagene Läufe pro Gruppe zählen und jeden Fehlschlag als schemabedingt oder nicht klassifizieren; bei schemabedingten Fehlschlägen festhalten, ob die Änderung schädlich war.
4. Verteilungen der Erkennungszeiten, Anzahl der Fehlschläge sowie Anzahl unentdeckter oder spät entdeckter schädlicher Änderungen vergleichen; je Quelle auswerten, da eine einzelne störanfällige Quelle das Bild dominieren kann.

Status

Es wird kein Ergebnis behauptet. Das Register aus Schritt 2 ist der schwierige Teil, denn die unerkannten Änderungen der anpassenden Pipeline werden per Definition zum jeweiligen Zeitpunkt nicht bemerkt; um sie zu finden, ist ein periodisches Schema-Audit gegen die Quelle nötig, und das Auditintervall begrenzt die messbare Erkennungszeit.