Von Andrew Tan
Schema-Drift und Breaking Changes im Upstream sind die Hauptursachen für stille Datenfehler — aber die meisten Pipeline-Inhalte konzentrieren sich auf die Infrastruktur, nicht auf das Verhalten des Quellsystems
Verwandt: Dieser Artikel behandelt Muster 1 aus unserer Analyse von 50 Data-Pipeline-Postmortems von Uber, Netflix, Stripe und anderen. Schema-Drift machte 38 % der Vorfälle aus — die häufigste Ursache, die wir fanden.
Das Feld, das an einem Dienstag den Typ änderte
Ein Team, das ich kenne, führt die Zahlungsabstimmung für ein mittelgroßes E-Commerce-Unternehmen durch. Ihre Pipeline zieht Transaktionsdaten von einem Drittanbieter-Zahlungsabwickler, transformiert sie und lädt sie in ihr Data Warehouse. Sie lief zweieinhalb Jahre ohne Zwischenfälle.
An einem Dienstagnachmittag im November aktualisierte der Zahlungsabwickler stillschweigend seine API. Ein Feld — transaction_amount — änderte sich von einem String (weil einige Altsysteme Geld als "47.50" darstellen) zu einem nativen Float (47.50). Keine Versionierung. Keine Ankündigung der Außerdienststellung. Keine E-Mail. Die Dokumentation wurde irgendwann in der folgenden Woche aktualisiert.
Die Pipeline stürzte nicht ab. Sie lief weiter. Sie verarbeitete weiterhin Transaktionen. Sie meldete weiterhin Erfolg.
Was sie nicht mehr tat, war korrektes Casting. Die nachgelagerte Transformation ging von einer String-Eingabe aus und wendete einen Regex an, um Währungssymbole zu entfernen, bevor sie konvertierte. Mit einem Float, der hereinkam, passte der Regex nichts, die Konvertierung ergab null, und jede Transaktion für die nächsten sechs Stunden hatte einen Betrag von null.
Sechs Stunden lang Transaktionen mit null Dollar, die alle als verarbeitet angezeigt wurden. Niemand bemerkte es, bis der tägliche Abstimmungsbericht am nächsten Morgen herauskam und die Zahlen aussahen, als hätte ein Rundungsfehler das Geschäft verschluckt.
Ich erzähle diese Geschichte, weil sie etwas illustriert, das die meisten Pipeline-Architektur-Schriften übersehen: Die beängstigendsten Fehler kommen nicht von Ihrer Infrastruktur. Sie kommen von Systemen, die Sie nicht kontrollieren.
Drei Arten von Upstream-Änderungen
Nicht alle Upstream-Änderungen sind gleich. Ich habe Teams gesehen, die von jeder von ihnen verbrannt wurden, und sie erfordern unterschiedliche Abwehrmaßnahmen.
Additive Änderungen sind die, die Anbieter als "rückwärtskompatibel" ankündigen. Neue Felder erscheinen in der Antwort. Bestehende Felder bleiben gleich. In der Theorie sollte Ihre Pipeline in Ordnung sein — Sie verwenden die neuen Felder nicht. In der Praxis brechen additive Änderungen Pipelines, wenn sie auf implizite Größenannahmen stoßen (eine JSON-Antwort überschreitet jetzt ein Pufferlimit), wenn Wildcard-Schema-Erfassungen Felder aufnehmen, die Sie nicht erwartet haben, oder wenn dieses neue Feld einen Namen hat, der mit einem Feld kollidiert, das Sie bereits in Ihrer Zieltabelle haben.
Breaking Changes sind zumindest die ehrlichen. Das Feld wird umbenannt. Der Typ ändert sich. Ein Endpunkt wird außer Dienst gestellt. Diese sollten angekündigt werden — und sind es normalerweise auch, bei seriösen Anbietern. Aber "angekündigt" bedeutet nicht "darauf reagiert". Die Ankündigung sitzt in einem E-Mail-Digest, den niemand liest, weil das Team, das ihn erhält, nicht das Team ist, das die Pipeline besitzt, und bis das Außerdienststellungsdatum eintrifft, ist der ursprüngliche Ingenieur zu einem anderen Unternehmen gewechselt.
Stille Änderungen sind die Situation des Zahlungsabwicklers. Die Art, von der Ihnen niemand erzählt, weil sich aus Sicht des Anbieters nichts geändert hat. Die Semantik ist die gleiche. Die Daten sind die gleichen. Nur der Typ hat sich geändert. Oder die Kodierung. Oder das Verhalten der Nullbehandlung. Stille Änderungen sind die, die sich in sechs Stunden Datenkorruptionsereignisse verwandeln, bevor jemand es bemerkt.
Der Anteil jeder Art variiert je nach Reife des Anbieters. Etablierte Finanz-APIs sind meist Breaking Changes mit langen Außerdienststellungsfenstern. SaaS-Produkte mit schnellen Release-Zyklen sind meist still und additiv. Partnerbereitgestellte Datenfeeds — die unglamouröse, kritische Art, die B2B-Integrationen betreiben — sind wirklich unvorhersehbar.
Warum die meisten Pipelines auf der falschen Ebene scheitern
Hier ist das Ding über Schema-Validierung: Fast jedes moderne Pipeline-Tool unterstützt sie. Sie können Schemas definieren. Sie können bei der Aufnahme validieren. Sie können fehlerhafte Datensätze ablehnen.
Die meisten Teams tun es aus verständlichen Gründen nicht.
In den frühen Tagen einer Pipeline ändert sich das Schema ständig. Das Quellsystem ist noch in der Entwicklung. Strikte Validierung würde die Pipeline jedes Mal zum Scheitern bringen, wenn während der normalen Iteration ein Feld hinzugefügt oder umbenannt wird. Also wird die Validierung ausgeschaltet oder auf "bestmögliche Anstrengung" gelockert, und wenn die Pipeline die Produktion erreicht, erinnert sich niemand daran, sie wieder zu verschärfen.
Es gibt auch eine philosophische Spaltung in der Art und Weise, wie Teams über Schema-Durchsetzung denken. Strikte Schema-Validierung fühlt sich defensiv an. Es fühlt sich an, als würden Sie eine Mauer bauen, die die Pipeline jedes Mal brechen wird, wenn das Quellsystem atmet. Permissive Handhabung fühlt sich pragmatisch an. Verarbeiten Sie, was Sie können, lassen Sie durch, was Sie nicht können, lassen Sie das Ziel es herausfinden.
Das Problem bei permissiver Handhabung ist, dass sie die Fehleroberfläche nach unten verschiebt und unsichtbar macht. Ihre Pipeline scheitert nicht. Ihre nachgelagerte Analytik oder Anwendung verarbeitet stillschweigend fehlerhafte Daten. Und wenn Sie es bemerken — Tage später, wenn ein Bericht falsch aussieht oder ein Benutzer eine Diskrepanz meldet — sind die beschädigten Datensätze mit legitimen vermischt, durch nachgelagerte Transformationen verstärkt und möglicherweise gehandelt worden.
Schema-Validierung auf der Pipeline-Ebene geht nicht darum, strikt um der Striktheit willen zu sein. Es geht darum, Fehler laut und früh statt leise und spät zu machen.
Die drei Verteidigungsklassen
Nachdem ich genug von diesen Vorfällen gesehen habe, habe ich festgestellt, dass Teams, die Upstream-Änderungen gut handhaben, drei Dinge konsequent tun.
Formvalidierung, nicht nur Typen. Typvalidierung fängt die Situation des Zahlungsabwicklers ab. Aber Formvalidierung fängt die subtileren Fälle ab: ein erforderliches Feld, das optional wird (und daher manchmal fehlt), ein Array, das früher immer ein Element hatte, jetzt manchmal null, ein Objekt, das früher flach war, jetzt eine Ebene tiefer verschachtelt.
Der Unterschied ist wichtig, weil Typfehler laute Fehler erzeugen. Formfehler erzeugen leise. Ein Feld, das zu 99,9 % der Zeit vorhanden ist und zu 0,1 % der Zeit fehlt, wird einen Nullbehandlungsfehler erzeugen, der Wochen braucht, um aufzutauchen, weil er nur bei seltenen Transaktionstypen, spezifischen geografischen Regionen oder Randfall-Zahlungsmethoden ausgelöst wird.
Schema-Drift-Überwachung, nicht nur Jobstatus. Der Jobstatus sagt Ihnen, ob die Pipeline gelaufen ist. Die Schema-Drift-Überwachung sagt Ihnen, ob das, was die Pipeline heute verarbeitet hat, die gleiche Form hat wie das, was sie gestern verarbeitet hat.
Dafür ist keine ausgeklügelte Beobachtungsplattform erforderlich. Die einfachste Version ist eine tägliche Überprüfung, die das abgeleitete Schema einer Stichprobe von Datensätzen aus jeder Quelle hasht und alarmiert, wenn sich der Hash ändert. Es ist grob, aber effektiv. Die meisten Schema-Drift-Ereignisse sind mit dieser Methode innerhalb von 24 Stunden erkennbar.
Ausgereiftere Versionen verfolgen feldbezogene Statistiken: Nullraten pro Feld, Kardinalität pro Feld, Typverteilung pro Feld. Wenn die Nullrate für transaction_amount von 0,0 % auf 0,1 % steigt, hat sich etwas im Upstream geändert. Vielleicht ist es beabsichtigt. Vielleicht ist es ein Fehler. Auf jeden Fall möchten Sie es wissen, bevor es zu einem Problem wird.
Trennung von Aufnahme und Verarbeitung. Dies ist das architektonische Muster, das die meiste Zeit kauft, wenn Upstream-Änderungen auftreten. Wenn Ihre Pipeline Rohdaten in eine Landezone aufnimmt, bevor sie verarbeitet werden, haben Sie die Möglichkeit, nach der Behebung eines Schema-Problems gegen historische Rohdaten erneut abzuspielen. Wenn Aufnahme und Verarbeitung gekoppelt sind, verlieren Sie diese Option.
Die Roh-Landezone muss nicht teuer oder komplex sein. Für viele Anwendungsfälle ist ein nur anhängender Objektspeicher (S3, GCS, Azure Blob) mit partitioniertem Roh-JSON ausreichend. Die Transformationsebene liest aus der Landezone, nicht direkt aus der Quelle. Wenn etwas im Upstream schiefgeht, beheben Sie die Transformation und spielen Sie erneut ab. Die Daten sind noch da.
Vertragstests auf der Pipeline-Ebene: Lohnt es sich?
Sie werden von verbrauchergesteuerten Vertragstests als der "richtigen" Lösung für dieses Problem hören. Die Idee ist, dass Ihre Pipeline einen Vertrag veröffentlicht — dies sind die Felder, auf die ich angewiesen bin, dies sind die Typen, die ich erwarte, dies ist, was ich als Breaking Change betrachte — und das Quellsystem wird erwartet, dass es gegen diesen Vertrag validiert, bevor Änderungen bereitgestellt werden.
Dies funktioniert gut, wenn Sie beide Seiten der Integration kontrollieren. Wenn Sie interne Mikrodienste integrieren oder mit einem Anbieter arbeiten, der die Stabilität der Integration ernst nimmt, sind Vertragstests wirklich wertvoll. Tools wie Pact machen es handhabbar.
Für die Mehrheit der Integrationen, die ich in der Praxis sehe — Drittanbieter-SaaS, Partner-APIs, Datenfeeds von Systemen, über die Sie keine Kontrolle haben — sind Vertragstests eine schöne Theorie. Sie können einen Zahlungsabwickler nicht zwingen, Ihre Pact-Tests auszuführen, bevor er bereitstellt. Sie können keine Vertragsveröffentlichungsrechte mit einem Anbieter aushandeln, dessen Rechtsabteilung noch nie von verbrauchergesteuerten Verträgen gehört hat.
Der praktischere Rahmen ist: Was können Sie auf Ihrer Seite der Grenze tun, um Änderungen zu erkennen und sich schnell davon zu erholen?
Was mich zurück zu Schema-Überwachung, Landezonen und Pipeline-Level-Validierung bringt. Nicht glamourös. Nicht die technisch interessante Lösung. Aber die, die tatsächlich über die gesamte Bandbreite der Upstream-Szenarien funktioniert, denen Sie begegnen werden.
Die Frage, die Sie bei jedem Integrationsstart stellen sollten
Ich habe angefangen, bei jedem Integrationsdesign-Review eine Frage zu stellen: Was ist der Prozess, wenn sich dies ohne Vorwarnung ändert?
Nicht ob. Wann.
Es klingt pessimistisch. Das Partner-Integrationsteam nimmt es manchmal persönlich. Aber die Frage erzwingt ein Gespräch, das fast immer Annahmen aufdeckt, die niemand explizit gemacht hatte: die Annahme, dass das Team des Quellsystems Breaking Changes kommunizieren wird, die Annahme, dass jemand im Integrationsteam das Änderungsprotokoll liest, die Annahme, dass die Pipeline X Tage fehlerhafte Daten tolerieren kann, bevor jemand es bemerkt.
Diese Annahmen sind normalerweise falsch. Sie explizit zu machen, gibt Ihnen die Chance, darum herum zu entwerfen.
Die Antwort auf "Was passiert, wenn sich dies ohne Vorwarnung ändert" sollte mindestens beinhalten: wo der Alarm ausgelöst wird, wer ihn erhält, wie schnell das Team identifizieren kann, welches Feld sich geändert hat, und wie schnell sie betroffene Daten aus der Roh-Landezone erneut abspielen können. Wenn die Antwort lautet "Wir müssten untersuchen und wahrscheinlich den Anbieter anrufen", ist die Pipeline nicht bereit für die Produktion.
Wo layline.io ins Spiel kommt
Schema-Evolution ist eines der Dinge, über die wir viel nachdenken, wie layline.io die Datenverarbeitung handhabt. Wenn Sie sowohl Batch- als auch Streaming-Pipelines verarbeiten — und die Realität ist, dass die meisten Teams beide auf unbestimmte Zeit betreiben — wird das Problem der Upstream-Änderungen verstärkt. Eine Schema-Änderung in einer Streaming-Quelle trifft Sie in Echtzeit. Die gleiche Änderung in einer Batch-Quelle könnte erst nach 24 Stunden sichtbar werden.
Das Verarbeitungsmodell von layline.io unterstützt Sie bei der Schema-Evolution durch explizites Versionsrouting: Wenn eine neue Schema-Version eingeführt wird, können Sie separate Logik und Validierung anwenden oder diese Datensätze zu einem separaten Flow zur Validierung und Handhabung leiten, anstatt sie Ihren Hauptverarbeitungspfad kontaminieren zu lassen.
Es ist keine Magie. Sie müssen Ihre Integration immer noch mit der Annahme entwerfen, dass sich die Dinge im Upstream ändern werden. Aber es bedeutet, dass, wenn sie sich ändern, die Fehleroberfläche kleiner ist und der Wiederherstellungspfad schneller.
Die Teams, die Upstream-Änderungen gut handhaben, sind nicht die mit der ausgeklügeltsten Infrastruktur. Es sind die, die aufgehört haben anzunehmen, dass das Quellsystem sie niemals überraschen würde.
Wenn Ihr Team mit Schema-Drift oder Zuverlässigkeit von Upstream-Integrationen zu tun hat, layline.io's processing engine behandelt Schema-Evolution und Pipeline-Robustheit für sowohl Batch- als auch Echtzeit-Workloads. Die Community Edition ist kostenlos zu erkunden.
Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, das Unternehmensdatenverarbeitungsinfrastruktur entwickelt, die sowohl Batch- als auch Echtzeit-Workloads in großem Maßstab verarbeitet.