Die Pipeline, die bis gestern noch einwandfrei lief, ist heute Morgen leer
Bei internen Quellen passiert so etwas selten. Für Schemaänderungen gibt es Abstimmungen, vor dem Löschen von Spalten gibt es Vorankündigungen, und bei Problemen gibt es Verantwortliche, die dafür geradestehen. Quellen aus dem externen Web, etwa Wettbewerbspreise, Bewertungen oder Marktdaten, sind jedoch anders.
Eines Tages stellt die Zielwebsite den Bewertungsbereich auf React um, verschiebt die Preisangabe und blendet zuvor nur nach Anmeldung sichtbare Elemente aus. Ohne Vorankündigung. In diesem Moment gibt das Parsing, das bis gestern noch funktionierte, leere Werte zurück, das dbt-Modell lässt sie unverändert durch, und im Dashboard bleiben die Daten von gestern als Lücke zurück. Die Fachabteilung fragt: „Warum stimmen die Daten nicht?“, und das Datenteam repariert den Parser mitten in der Nacht.
Dieser Artikel erläutert aus der Perspektive von Datenverträgen (Data Contracts), warum sich diese Situation wiederholt und wie Verantwortlichkeiten unter der Annahme gestaltet werden, dass Brüche unvermeidbar sind.
Warum gerade das Web immer wieder bricht
Ein Datenvertrag ist eine explizite Vereinbarung zwischen Quelle und Verbraucher: „Diese Daten werden in dieser Form, mit dieser Bedeutung und in diesem Rhythmus bereitgestellt.“ Er ist nicht nur eine einfache Schemadefinition, sondern umfasst auch, wer bei Änderungen was und wann tut.
In internen Systemen funktioniert dieser Vertrag als organisatorische Norm. Wenn das Quellteam ein Schema ändern will, informiert es darüber, vor dem Löschen einer Spalte gibt es eine Deprecation-Phase, und bei einem Bruch gibt es eine verantwortliche Person im Organigramm. Entscheidend ist, dass die Quelle ein kooperationsfähiger Akteur ist. Man kann miteinander sprechen, Termine abstimmen und Verantwortung einfordern.
Externe Webdaten sind schwierig, weil diese Voraussetzung wegfällt. Die Zielwebsite ist keine Vertragspartei unseres Vertrags. Sie nimmt keine Rücksicht auf die Umstände unserer Pipeline, es gibt keine Benachrichtigungen, und wir können auch keinen Rollback verlangen. Zudem sind Weboberflächen von vornherein nicht als Eingabe für Pipelines gebaut. Da eine für Menschen geschaffene Ansicht rückwärts als Daten interpretiert wird, erschüttern folgende Eigenschaften den Vertrag.
- Umbauten ohne Vorankündigung: Durch Marketing-Relaunches oder Framework-Wechsel ändern sich DOM-Struktur und Rendering-Methode (SSR→CSR) über Nacht.
- A/B-Tests und bedingte Ansichten: Dieselbe URL liefert bei jedem Zugriff eine andere Ansicht, und je nach Region, Anmeldung, Mitgliedsstufe oder Gerät unterscheiden sich die sichtbaren Elemente. Wenn nicht gemeinsam festgehalten wird, unter welchen Bedingungen Daten gesehen wurden, verändert sich die Bedeutung desselben Feldes unbemerkt.
- Partielle Ausfälle durch Anti-Bot-Maßnahmen und Sperrungen: Bei Sperren, Captchas oder Rate Limits fehlen nicht alle Daten vollständig, sondern nur einzelne Teile. „Reduzierte Daten, die normal wirken“ führen dazu, dass nachgelagerte Systeme stillschweigend falsche Aggregationen berechnen.
Allen Fällen ist gemeinsam, dass die für interne Quellen geltende Annahme eines stabilen Schemas im externen Web nicht zutrifft. Daher muss ein Datenvertrag für externe Webseiten nicht behandeln, dass „nichts bricht“, sondern wer unter der Voraussetzung von Brüchen für Erkennung, Korrektur und erneute Erfassung verantwortlich ist.
Warum ein kleiner Umbau zu einem Problem für die gesamte Organisation wird
Ein kleiner Umbau auf einer Website breitet sich in die nachgelagerten Systeme aus. Wenn Parsing-Regeln und tatsächliches DOM auseinanderlaufen, fehlen Felder bereits in der Erfassungsphase oder Werte werden verändert. Ohne in der Ladetabelle gefiltert zu werden, gelangen sie in dbt-Transformationen, erzeugen stillschweigende NULL-Fortpflanzung und falsche Aggregationen und führen schließlich zu Lücken in Dashboards und fehlerhaften Entscheidungen.
Zwei Faktoren vergrößern den Explosionsradius. Erstens: stilles Versagen. Es wäre sogar besser, wenn das Parsing eine Ausnahme auslöst und stoppt. Gefährlich ist, wenn leere Zeichenfolgen oder NULL als normale Werte zurückgegeben werden und nachgelagerte Systeme sie unverändert passieren lassen: Die Pipeline zeigt Grün, aber nur die Zahlen sind falsch. Zweitens: wenn Feldverträge zu weit gefasst werden. Wenn nachgelagerte Modelle und Dashboards sämtliche erfassten Felder direkt referenzieren, erschüttert bereits die Änderung eines einzigen Elements auf der Website alle davon abhängigen Ergebnisse.
Puffergestaltung — damit nachgelagerte Systeme trotz Bruch nicht zusammenbrechen
Die Instabilität des externen Webs lässt sich nicht beseitigen. Stattdessen wird eine Pufferschicht dazwischengelegt, damit sich Instabilität nicht in die nachgelagerten Systeme ausbreitet.
Raw-Aufbewahrung. Die erfassten Originaldaten (HTML-Snapshots, Originalantworten, Bilder vor OCR usw.) werden getrennt von den Parsing-Ergebnissen aufbewahrt. Wenn sich herausstellt, dass das Parsing falsch war, können historische Daten durch erneutes Parsing ohne Neuerfassung wiederhergestellt werden, sofern die Originaldaten vorhanden sind. Werden Originaldaten verworfen, wird ein Parsing-Bug unmittelbar zu einem dauerhaften Datenverlust. Die Raw-Aufbewahrung bildet die gemeinsame Grundlage für Neuerfassung, Audit und Lineage.
Feldvertrag minimieren. Die Felder, von denen nachgelagerte Systeme abhängen, werden auf die wesentlichen Kernfelder reduziert und eng vertraglich festgelegt. Nebenelemente, die Websites häufig ändern, werden nicht in den Vertrag aufgenommen, sondern nur in Raw-Daten belassen. Vertraglich vereinbarte Kernfelder werden auf Typ, Pflichtstatus und Wertebereich geprüft und bei Verletzungen nicht an nachgelagerte Systeme weitergegeben. Je enger der Vertrag, desto kleiner auch der Explosionsradius eines Umbaus.
Änderungserkennung. Wer nur prüft, ob das Parsing eine Ausnahme ausgelöst hat, übersieht stille Fehler. Deshalb wird die Form der Ergebnisse selbst überwacht. Es wird geprüft, ob sich die Anzahl der Datensätze gegenüber dem Normalzustand stark verändert hat, ob die Fehlerrate bei Kernfeldern plötzlich gestiegen ist oder ob die Werteverteilung den normalen Bereich verlässt (etwa Preise von 0 oder ungewöhnlich hohe Preise). Sobald auch nur eines davon auffällt, wird der Kanal des Datenteams benachrichtigt. Ziel ist es, Umbauten zuerst anhand der Formveränderung der Daten zu erkennen, bevor ein Mensch sie bemerkt.
Auf dieser Pufferbasis arbeiten wir mit Datenteams wie folgt zusammen. Das Schema wird zu Beginn gemeinsam mit dem Datenteam definiert. Es wird abgestimmt, welche Felder als Kernvertrag gelten sollen und welche Typen, NULL-Zulässigkeit und Bedeutung jedes Feld hat; auf diesen Vertrag referenzieren dann dbt und die nachgelagerten Dashboards. Auch wenn Änderungen notwendig werden, tauschen wir das Schema nicht einseitig aus. Änderungen werden vorab angekündigt, es gibt eine Deprecation-Phase, und während dieser Zeit werden alte und neue Version parallel bereitgestellt. So erhalten nachgelagerte Systeme Zeit zur Migration, bevor die alte Version entfernt wird. Selbst wenn sich die Website ändert, können nachgelagerte Systeme innerhalb des angekündigten Zeitfensters umsteigen, und ein Umbau führt nicht unmittelbar zu einer Dashboard-Lücke.
Verantwortlichkeiten unter der Annahme von Brüchen gestalten
Technische Puffer allein reichen nicht aus. Was die praktische Arbeit tatsächlich zum Erliegen bringt, ist eine Situation, in der im Vertrag nicht festgelegt ist, wer einen Bruch behebt. Deshalb müssen Datenverträge neben dem Schema auch die Eigentümer von Erkennung, Korrektur und Neuerfassung enthalten.
| Verantwortlichkeit | Im Vertrag festzulegen |
|---|---|
| Erkennung | Wer betreibt die Warnsignale, über welchen Kanal wird informiert, und bis wann gilt das Wiederherstellungsziel? Für die Erkennung ist nicht der Verbraucher verantwortlich, sondern die Seite, die die Erfassung betreibt |
| Korrektur | Wer ist verantwortlich für die Reparatur der Regeln, wenn ein Parser durch einen Website-Umbau bricht? Bei Auslagerung: der Dienstleister |
| Neuerfassung(backfill) | Gibt es ein Standardverfahren, um die Lücken des fehlerhaften Zeitraums wieder aufzufüllen? |
Die Kernleistung einer Auslagerung besteht darin, die Verantwortung für Korrekturen beim Dienstleister zu verankern. Laufende Wartungsarbeiten wie die Reaktion auf Sperrungen, das Verfolgen von Website-Änderungen und die Reparatur von Parsern werden nicht dem für den DAG-Betrieb zuständigen Personal des Datenteams aufgebürdet; das Datenteam konzentriert sich auf Laden, Modellierung und Nutzung.
Neuerfassung wird nicht als Ausnahme, sondern als Standardverfahren behandelt. Lücken werden für einen festgelegten Zeitraum und unter definierten Bedingungen aufgefüllt, wobei idempotentes Laden vorausgesetzt wird, damit sich auch bei mehrfacher Ladung derselben Schlüssel keine Duplikate ansammeln. Mit Watermarks und inkrementellen Cursorn werden nur die aufzufüllenden Bereiche präzise ergänzt. Zusätzlich werden Metadaten mitgeliefert, die unmittelbar für Validierung nach dem Laden (DQ), Audit und Lineage genutzt werden können. Erfassungszeitpunkt und Erfassungsbedingungen (Region, Anmeldung) bilden die Grundlage für die Interpretation der Wertebedeutung; Quell-URL und Erfassungsfrequenz werden für Katalog- und Lineage-Registrierungen genutzt; Datensatzanzahl sowie Fehlend-/Anomalie-Flags fließen in automatische Validierungsgates ein. Zudem wird ein Abschlussmarker (manifest/_SUCCESS) hinterlassen, damit nachgelagerte Systeme beurteilen können, dass der Ladevorgang vollständig abgeschlossen ist. Dadurch wird verhindert, dass die Orchestrierung Transformationen auf teilgeladenen Daten ausführt. Nur so lässt sich bei einem Audit die Frage beantworten: „Woher kommt diese Zahl?“
Zusammengefasst ist ein Datenvertrag für externe Webseiten nicht das Versprechen, dass „nichts bricht“, sondern die Vereinbarung darüber, wer bei einem Bruch Erkennung, Korrektur und Neuerfassung verantwortet und bis wann die Wiederherstellung erfolgt. Nur wenn diese Verantwortlichkeiten im Vertrag festgehalten sind, lassen sich externe Webquellen intern wie gut verwaltete Quellsysteme behandeln.
Zusammenfassung
Der grundlegende Grund, warum externe Webdaten immer wieder brechen, ist, dass die Quelle im Gegensatz zu internen Quellen keine kooperationsfähige Vertragspartei ist. Umbauten ohne Vorankündigung, A/B-Tests und bedingte Ansichten zerstören die Annahme von Schemastabilität. Deshalb darf ein Datenvertrag für externe Webseiten nicht lauten, dass „nichts bricht“, sondern muss unter der Annahme von Brüchen die Eigentümer von Erkennung, Korrektur und Neuerfassung klar benennen.
Hashscraper arbeitet auf diese Weise mit Datenteams zusammen. Wir definieren das Schema gemeinsam, führen Änderungen über Vorankündigungen und parallele Versionen ein, behandeln Neuerfassungen mit idempotentem Laden und watermarkbasierten Standardverfahren und liefern Metadaten sowie Abschlussmarker mit, die unmittelbar für Katalog, Lineage und DQ genutzt werden können. Entwicklung, Wartung, Reaktion auf Sperrungen und Erfassungsüberwachung sind in der monatlichen Auslagerungspauschale enthalten, sodass das für den DAG-Betrieb zuständige Personal nicht durch die Wartung externer Erfassungen aufgerieben wird. Auch im Hinblick auf die Größenordnung verfügen wir über Erfahrung darin, groß angelegtes Online-Monitoring einer Regulierungsbehörde als regelmäßige Pipeline im Auftrag zu betreiben.
Lagern Sie die Erfassung und Wartung externer Webseiten aus und behandeln Sie sie wie gut verwaltete Quellsysteme, während sich das Datenteam auf Laden, Modellierung und Nutzung konzentriert — das ist der realistische Weg, externe Daten im Zeitalter ständiger Website-Umbauten zuverlässig in Dashboards bereitzustellen.
Weiterführende Artikel
- Wie Crawling-Daten zu Entscheidungsgrundlagen werden
- Daten in Excel erhalten vs. Daten im Dashboard sehen — was das Lieferformat verändert
- Unternehmen, in denen jede Abteilung separat crawlt — Data-Governance für die unternehmensweite Datenerfassung zur Beendigung doppelter Investitionen
Jetzt direkt starten
Wir prüfen gemeinsam, welche Verträge für die externen Webquellen erforderlich sind, die derzeit an Ihre Pipeline angebunden sind, damit Ihr Dashboard nicht bei einem einzigen Umbau leer bleibt. Von der Schemadefinition über Änderungsbenachrichtigungen und Verantwortlichkeiten für Neuerfassungen bis hin zu Übertragungsspezifikationen gestalten wir alles passend zu der Pipeline Ihres Datenteams.
