Von Andrew Tan
Das Problem mit Schema-Überwachung
Schema-Überwachung soll breaking changes erkennen. Tut sie aber nicht.
Eine Pipeline läuft monatelang ohne Probleme. Dann fügt ein Upstream-Service ein revenue_v2-Feld hinzu. Das alte revenue-Feld existiert noch, ist aber jetzt veraltet und immer null. Die Pipeline nimmt die Nullwerte problemlos auf. Keine Fehler. Alles grüne Lichter.
Die Geschäftsmetrik ist einfach falsch.
Das passiert, weil die Überwachung auf strukturelle Änderungen achtet, nicht auf semantische.
Warum Überwachung versagt
Die meisten Teams richten Alarme für neue Spalten ein. Typänderungen. Fehlende Felder. Ein Mensch überprüft jeden Alarm.
Nach der fünfzigsten Benachrichtigung über ein "neues optionales Feld" hört man auf zu lesen. Das Gehirn genehmigt automatisch. INT zu BIGINT? Harmlos. Genehmigen. Weitergehen.
Echte Probleme schleichen sich durch. Das oben genannte Problem war nicht strukturell. Es war semantisch. Ein neues Feld erschien — angeblich sicher. Das alte Feld existierte. Keine breaking changes erkannt.
Der Vertrag war gebrochen. Niemand bemerkte es.
Überwachung fängt Unfälle auf. Sie brauchen etwas, das Lügen aufdeckt.
Verträge vs. Register
Ein Schema-Register überprüft die Struktur. Feldnamen, Typen, Nullfähigkeit. Wichtig. Nicht genug.
Ein Datenvertrag überprüft Versprechen.
- Haben Sie eine Zahl gesendet?
- Bedeutet sie, was Sie gesagt haben?
- Ist sie positiv? Im Bereich? Referenziell intakt?
Denken Sie an REST-APIs. Sie überprüfen nicht nur, ob JSON geparst wird. Sie überprüfen, ob der Endpunkt das tut, was die Dokumentation sagt. Brechen Sie dieses Versprechen und es ist eine breaking change, selbst wenn das JSON technisch gültig ist.
Datenpipelines brauchen dasselbe. Nachgelagerte Systeme bauen auf impliziten Versprechen auf. Wenn diese brechen, bricht alles.
Wie gute Verträge aussehen
Die Teams, die dies gut machen, definieren drei Dinge für jeden Datensatz:
Strukturelle Garantien. Aber mit einem Twist: jede Abweichung ist breaking. Neues optionales Feld? Versionssprung. Klingt schmerzhaft. Beseitigt "stille semantische Änderungen" vollständig.
Semantische Erwartungen. Geschäftsregeln als Validierung. Patientenalter 0-120. Diagnosecodes müssen in der Referenztabelle existieren. Zeitstempel innerhalb von 24 Stunden nach Dateierstellung.
Verbraucherzusagen. Nachgelagerte Systeme erklären Abhängigkeiten. Ändern Sie ein Feld, das drei kritische Pipelines verwenden? Hohes Risiko. Selbst wenn es strukturell "sicher" aussieht.
Schemaänderungen gehen von Tagen der Koordination auf Stunden. Stille semantische Drifts sinken auf null.
Das Schwierige ist organisatorisch
Verträge erzwingen Gespräche, die die meisten Menschen nicht führen wollen.
Produzenten müssen Dinge über Daten versprechen, die sie nicht vollständig kontrollieren. Das CRM-Team kennt nicht jeden nachgelagerten Verbraucher. Das Mobile-Team weiß nicht, wie Data Science ihre Ereignisse nutzt.
Drei Muster für Eigentum:
Produzenten-gesteuert. Das Team, das die Daten erstellt, definiert den Vertrag. In der Theorie sauber. Scheitert oft, weil Produzenten für Bequemlichkeit optimieren, nicht für nachgelagerte Bedürfnisse.
Verbraucher-gesteuert. Nachgelagerte definiert Anforderungen. Schützt Verbraucher, aber Produzenten können nicht immer nachkommen. Sie erhalten Verträge auf Papier, die in der Praxis verletzt werden.
Plattform-vermittelt. Zentrales Team vermittelt das Gespräch. Mehr Aufwand. Funktioniert tatsächlich.
Plattform-vermittelt mit vierteljährlichen Überprüfungen ist teuer in der Besprechungszeit. Billig im Vergleich zu Vorfällen.
Klein anfangen
Sie brauchen keine Plattform, um zu beginnen.
Schreiben Sie drei Dinge für Ihre kritischen Datensätze:
Was stellt dies dar? Keine Felddefinitionen. Das Geschäftskonzept. "Täglicher Schnappschuss aktiver Abonnements" unterscheidet sich von "Tabelle hat customer_id, plan_type, renewal_date."
Worauf können sich Menschen verlassen? Nullfähigkeit, Aktualisierungshäufigkeit, Aufbewahrung. Die Dinge, die jeder implizit annimmt.
Was passiert, wenn es bricht? Wen rufen Sie an? Wie schnell? Was ist der Rollback?
Beginnen Sie mit Ihren drei kritischsten Assets. Das ist alles.
Verträge schaffen auch Probleme
Sie verfestigen sich. Eine Vertragsänderung erfordert Koordination. Das ist der Punkt — verhindert breaking changes — verlangsamt aber auch gute Änderungen. Teams vermeiden es, Änderungen vorzuschlagen, wegen der Koordinationskosten.
Sie lügen. Ein Vertrag ist nur so gut wie seine Validierung. Zu sagen "alle customer_ids müssen existieren" ohne Überprüfung? Theater. Falsches Vertrauen ist schlimmer als keines.
Sie schieben die Schuld. Verbraucher erkennt eine Verletzung. Antwort: "Produzent hat sein Versprechen gebrochen." Wahr. Unhilfreich. Das Ziel ist es, die Daten zu reparieren, nicht die Schuld zuzuweisen. Sie brauchen Wiederherstellungsverfahren, nicht Schuldzuweisungen.
Die Werkzeuge
Great Expectations und Soda haben Vertragsfunktionen hinzugefügt. Keine vollständigen Plattformen, aber sie erzwingen semantische Erwartungen an den Grenzen.
Data Contract Club und AICP entstehen. Erstklassige Verträge mit Versionierung und Validierung.
Datenkataloge — Collibra, Alation, Atlan — haben jetzt Vertragsmanagement. In der Regel arbeitsablaufintensiv, validierungsleicht. Besser für Dokumente als für Durchsetzung.
Bei layline.io betten wir Verträge in Workflows ein. Definieren Sie Datenbewegung, definieren Sie die Versprechen. Schemaerwartungen, Validierungsregeln, Qualitätsgrenzen. Durchgesetzt zur Laufzeit, nicht nachträglich überprüft.
Aber Sie brauchen keine ausgefallenen Werkzeuge. Eine JSON-Schema-Datei mit einem Validierungsschritt ist ein funktionierender Vertrag. Organisatorische Praxis schlägt Technologie.
Der Test
Wählen Sie ein kritisches Datenasset. Etwas, das weh tun würde, wenn es falsch wäre.
Upstream ändert ihr Format. Technisch gültig — neue Felder, gleiche Typen. Semantisch falsch. Wie lange dauert es, bis Sie es bemerken?
Wenn die Antwort "wenn sich jemand beschwert" ist, brauchen Sie Verträge.
Wenn es "wir würden es in der Überwachung erfassen" ist, graben Sie tiefer. Erfasst Ihre Überwachung semantische Änderungen oder nur strukturelle?
Das Ziel ist nicht perfekte Datenqualität. Es geht darum, die dummen Probleme zu verhindern. Diejenigen, die aus Annahmen entstehen, die niemand aufgeschrieben hat.
Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, der Unternehmensdatenverarbeitungsinfrastruktur aufbaut, die sowohl Batch- als auch Echtzeit-Workloads im großen Maßstab verarbeitet.