Wenn die Anforderung „Wir möchten auch Wettbewerbsdaten in unserem Dashboard sehen“ beim Datenteam ankommt
Interne Quellen sind stabil. Wir kontrollieren das Schema, Änderungen werden über Release Notes angekündigt, und selbst bei Ausfällen gibt es Verfahren zur Wiederverarbeitung. Doch in dem Moment, in dem Management und Fachbereiche fordern: „Wir möchten auch Wettbewerberpreise, Bewertungen und Marktdaten im selben Dashboard sehen“, entsteht die Herausforderung, Quellen außerhalb unseres Kontrollbereichs an die Pipeline anzubinden.
Das externe Web gehört uns nicht, und wir besitzen auch nicht dessen Schema. Zielseiten ändern ihre Seitenstruktur unangekündigt, während Blockierungsrichtlinien laufend verschärft werden. Fehlen gestern erhobene Daten, entstehen heute Lücken im Dashboard; Daten aus Excel-Dateien lassen sich nicht einfach an einen DAG anbinden. Dieser Artikel behandelt, wie externe Webdatenerhebung in interne DW- und Data-Lake-Pipelines integriert wird — also die Integrationsmethode. Die Prämisse ist einfach: Die Datenerhebung wird ausgelagert, während sich das Datenteam auf Laden, Modellierung und Nutzung konzentriert. Denn um das externe Web wie ein „gut verwaltetes Quellsystem“ zu behandeln, muss diese Quelle einen Vertrag in der Sprache des Datenteams erfüllen.
1. Worin unterscheiden sich externe Webdaten von internen Quellen?
Bevor man sie anbindet, muss man zunächst verstehen, was anders ist, damit ein Integrationsdesign entstehen kann. Bei internen Tabellen liegen Spaltenänderungen innerhalb unseres Release-Prozesses, während externe Websites Änderungen nach eigenem Ermessen vornehmen. Ein gestern vorhandenes Feld kann heute verschwunden sein, und derselbe „Preis“ kann gemischt als 12,900원 und 12900 eingehen. Auch Aktualisierungen erfolgen nicht transaktional, sondern als regelmäßige Batches in festgelegten Intervallen. Deshalb müssen DAG-Zeitpläne und Freshness-SLAs des Dashboards an diesen Rhythmus gekoppelt werden.
Der gefährlichste Unterschied liegt in den Fehlermodi. Interne Jobs werfen bei einem Fehler eine Ausnahme und stoppen, doch der schlimmste Fall bei externen Crawlern ist, dass sie kaputt sind, aber scheinbar erfolgreich leere Werte anhäufen. Ändert sich die Seitenstruktur und ein Selektor greift ins Leere, endet der Job zwar regulär, aber es gibt entweder 0 Datensätze oder Datensätze voller fehlender Werte. Eine Prüfung nur der Datensatzanzahl erkennt das nicht; da vergangene Webansichten nicht erneut erhoben werden können, bleiben diese Lücken dauerhaft bestehen. Deshalb ist die Integration externer Daten nicht mit „nur laden“ abgeschlossen, sondern die Validierung nach dem Laden gehört zwingend dazu.
2. Integrationsmuster nach Bereitstellungsformat — keine Einheitslösung, sondern passend zum Standard
Wie externe Datenerhebung an eine Pipeline angebunden wird, hängt vom Bereitstellungsformat ab. Grundsätzlich gibt es drei Wege; keiner ist per se richtig, vielmehr wird nach dem Pipeline-Standard des Datenteams gewählt.
| Muster | DAG-Trigger | Geeignet für | Abstimmungspunkte |
|---|---|---|---|
| API-Polling | Zeitplan+Sensor | Das Datenteam steuert, wann Daten abgerufen werden | Inkrementeller Cursor·Paginierung·Authentifizierung |
| Direktes Laden in DB·S3 | Ankunftssensor | Große Datenmengen, Vermeidung von Polling-Last | Abschlussmarker·Tabellen-/Präfixstandard |
| Dateieingang | Dateisensor | Niedrige Frequenz, Übergang von Excel zur Pipeline | Dateiname·Pfad·Sheet-Schema |
Beim API-Polling-Modell werden die erhobenen Daten per API bereitgestellt, und der DAG ruft seit dem letzten Wasserzeichen nur inkrementelle Daten ab und lädt sie in die Landing Zone. Der Kern besteht darin, dass das Datenteam den inkrementellen Cursor kontrolliert, damit bereits empfangene Bereiche nicht erneut abgerufen werden. Beim direkten Laden in DB·S3 lädt die Erhebungsseite direkt in das DW oder den Lake, während der DAG lediglich die Ankunft erkennt und die nachgelagerte Verarbeitung ausführt. Hier muss vorab ein Abschlussmarker-Standard wie Manifest·_SUCCESS vereinbart werden, damit nicht halb angelieferte Daten verarbeitet werden. Beim Dateieingangsmodell werden standardisierte Dateien an einem festgelegten Ort abgelegt, geparst und geladen; dies eignet sich für die Übergangsphase, in der ein Excel-zentrierter Betrieb in eine Pipeline überführt wird.
Allen drei Mustern liegt zugrunde, dass wir (die Erhebungsseite) und das Datenteam zuerst die Schnittstellenspezifikation abstimmen. API-Antwortformate, DB-Tabellen/S3-Präfixe und Dateikonventionen werden passend zur Pipeline des Datenteams vereinbart; welches Format bereitgestellt wird, ergibt sich umgekehrt aus diesen Standards. Diese Abstimmung ist nur möglich, wenn neben Excel auch API, Direktladen und S3-Drop als Bereitstellungsformate offenstehen.
3. Landing Zone — ein Puffer, der verhindert, dass nachgelagerte Systeme bei Änderungen externer Quellen brechen
Werden externe Daten direkt in die Modellierungsebene eingebracht, brechen am Tag einer Quelländerung alle nachgelagerten Komponenten (dbt·Dashboards). Die Landing Zone ist der Puffermechanismus und verarbeitet hier drei Dinge.
Erstens, die Aufbewahrung des Raw-Originals. Eine unveränderte Kopie der empfangenen Daten (API-Antwortrohtext, Originaldatei) wird archiviert. Damit kann bei fehlerhafter Parsing-Logik oder später benötigten weiteren Feldern erneut aus dem Original geparst werden, ohne die Daten neu erheben zu müssen. Da vergangene Webansichten nicht wiederherstellbar sind, ist diese Originalaufbewahrung faktisch das Sicherheitsnetz.
Zweitens, Schema-Versionierung. Unser Standard für die Zusammenarbeit mit Datenteams sieht so aus: Schemaänderungen werden vorab angekündigt und erhalten eine Deprecation-Phase. Während dieses Zeitraums werden alte und neue Versionen parallel bereitgestellt, sodass nachgelagerte Systeme in ihrem eigenen Tempo umstellen können. Beispielsweise wird price_daily.v1 weiterhin ausgegeben, während parallel v2 mit der zusätzlichen Spalte currency bereitsteht. Nachgelagertes dbt verschiebt die Referenz, sobald es vorbereitet ist; nach Ablauf der Deprecation wird v1 entfernt. So wird aus „Die Quelle wurde gestern umgestellt und heute ist das Dashboard ausgefallen“ ein „Parallelbetrieb bis zum nächsten Quartal, Umstellung innerhalb dieses Zeitraums“. Da Änderungsverantwortung und Pufferzeit im Vertrag festgelegt sind, wird das Datenteam nicht unangekündigt zum Feuerwehrteam.
Drittens behandeln wir Backfills als Standardverfahren. Wenn die Erhebung mehrere Tage ausgefallen ist oder neue Felder auch für historische Zeiträume ergänzt werden müssen, führen wir anhand eines festgelegten Zeitraums und Bedingungen eine erneute Erhebung durch und laden die Daten erneut in die Landing Zone; der DAG modelliert dann nur diesen Zeitraum neu. Voraussetzung ist ein idempotentes Design durch Partitionsaustausch·Upsert-Schlüssel, damit beim erneuten Laden desselben Bereichs keine Duplikate entstehen. Da die Schnittstelle für erneute Erhebung bei uns liegt, muss das Datenteam nur festlegen, „welcher Zeitraum erneut verarbeitet werden soll“.
4. Validierung nach dem Laden — stille fehlende Daten innerhalb des DAG erkennen
Die in Abschnitt 1 beschriebenen „stillen fehlenden Daten“ lassen sich nur durch Validierung nach dem Laden erkennen. Vor publish wird ein DQ-Gate eingefügt; wenn die Prüfung nicht bestanden wird, erfolgt keine Hochstufung in nachgelagerte Systeme. Statt dass fehlerhafte Daten bis ins Dashboard fließen, bleiben sie in der Landing Zone stehen und lösen eine Benachrichtigung aus. Das Gate prüft typischerweise vier Punkte: ob die Datensatzanzahl nicht abrupt unter die erwartete Untergrenze fällt (stille fehlende Daten), ob die Rate fehlender Pflichtfelder unter dem Schwellenwert liegt (teilweise Erhebung), ob keine Parsing-Anomalieflags vorhanden sind (Strukturumbau) und ob der Erhebungszeitpunkt innerhalb des Freshness-SLA liegt (Aktualität).
Damit das Datenteam DQ-Regeln nicht von Grund auf erstellen muss, liefern wir zusammen mit den Daten auch Validierungsmetadaten: Erhebungszeitpunkt (Freshness), Erhebungsbedingungen (welche Suchbegriffe·Kategorien·Bereiche), Quell-URL (Lineage·Audit), Datensatzanzahl (starker Rückgang gegenüber der Erwartung) sowie Missing-/Anomalieflags. Die Überwachung erfolgt nicht nur bei einem Crawler, sondern sowohl auf Seiten der Quelle (Erhebung) als auch der Pipeline (Laden). Werden Erhebungsanomalien oder Verzögerungen erkannt, informieren wir den Kanal des Datenteams (Slack·Webhook) und teilen zugleich die erwartete Wiederherstellungszeit mit. So entsteht ein Zustand, in dem beantwortet werden kann: „Warum fehlen Daten, und wann werden sie ergänzt?“
5. Katalog·Lineage — beantworten können: „Woher stammt diese Zahl?“
Sobald externe Daten im Dashboard erscheinen, kommt bei einer Prüfung oder Managementsitzung irgendwann die Frage: „Woher stammt dieser Wettbewerberpreis?“ Um darauf antworten zu können, müssen Herkunfts- und Zyklusmetadaten im Katalog und in der Lineage registriert sein. Damit diese Registrierung unmittelbar erfolgen kann, liefern wir die Quelldomain/URL, den Erhebungszyklus, die Erhebungsbedingungen (Zielbereich), die aktuelle Schemaversion sowie den Hinweis, dass es sich um eine ausgelagert betriebene Quelle handelt. Diese Angaben überschneiden sich mit den Validierungsmetadaten, werden jedoch um katalogrelevante Elemente ergänzt.
Wenn diese Metadaten bei der Dataset-Registrierung ausgefüllt werden, lässt sich ein Dashboard-KPI im Lineage-Graphen bis zur Quell-URL zurückverfolgen. Ein Zustand, in dem die Frage „Woher stammt diese Zahl?“ mit wenigen Klicks beantwortet werden kann — das bedeutet, dass externe Daten gleichrangig mit internen Quellen in die Governance aufgenommen wurden. Hier laufen die Gründe für die Abstimmung von Schema·Backfill·Metadaten mit dem Datenteam zusammen. Nur wenn externe Quellen in einer Form bereitgestellt werden, die offiziell im Katalog registriert werden kann, werden sie zu einem „verwalteten Quellsystem“.
Zuletzt geht es um Freshness. Externe Datenerhebung erfolgt als regelmäßiger Batch in festgelegten Intervallen, weshalb auch das Dashboard-SLA an diesen Batch-Zyklus angepasst werden muss. Läuft der Batch einmal täglich, sollte das Dashboard ebenfalls als „täglich aktualisierte Kennzahl“ gestaltet werden; auch die Beschriftung sollte den Batch-Erhebungszeitpunkt ausweisen, etwa als „Stand ○ Uhr“, damit Betrieb und Darstellung nicht auseinanderlaufen. Bei Freshness ist es sicherer, sowohl mit dem Datenteam als auch den Fachbereichen nicht über „wie aktuell“ zu sprechen, sondern darüber, „auf welchem Batch-Zeitpunkt“ die Daten basieren.
Was diese Integration dem Datenteam hinterlässt
Der Kern der Integration externer Webdatenerhebung in eine Pipeline besteht darin, eine unkontrollierbare Quelle hinter eine kontrollierbare Schnittstelle zu stellen. Werden Schema durch Versionsverträge, Fehler durch DQ-Gates, Herkunft durch Katalogmetadaten und Wiederverarbeitung durch standardisierte Backfill-Verfahren abgesichert, können auch externe Daten wie interne Quellen behandelt werden.
Die letzte Entscheidung lautet, wer den fortlaufenden Betrieb hinter dieser Schnittstelle übernimmt — Umgang mit Blockierungen, Verfolgung von Website-Umstellungen, Überwachung der Erhebung und Reparaturen. Übernimmt dies das Datenteam, werden die für den DAG-Betrieb zuständigen Mitarbeitenden durch die Wartung externer Datenerhebung aufgerieben. Wir übernehmen Entwicklung·Wartung·Blockierungsmaßnahmen·Erhebungsüberwachung im Rahmen eines monatlichen Festpreises und übergeben dem Datenteam eine Quelle mit Schema-Vertrag·Validierungsmetadaten·Katalogmetadaten. Da wir über Erhebung→Bereinigung→KI-Analyse hinweg nicht Raw-Daten, sondern ladbare strukturierte Daten bereitstellen, reduziert sich auch der Bereinigungsaufwand in der Landing Zone.
Das Fazit ist eindeutig. Externe Webdatenerhebung·Wartung wird ausgelagert und wie ein gut verwaltetes Quellsystem behandelt, während sich das Datenteam auf Laden·Modellierung·Nutzung konzentriert. Tatsächlich betreiben wir das großangelegte Online-Monitoring einer Regulierungsbehörde ausgelagert als regelmäßige Pipeline; auch umfangreiche und abteilungsübergreifende Anforderungen werden auf diese Weise über einen zentralen Ansprechpartner gebündelt.
Weiterführende Artikel
- Wie Crawling-Daten zu Entscheidungsgrundlagen werden
- Daten aus Excel erhalten vs. Daten im Dashboard sehen — was das Lieferformat verändert
- Unternehmen, in denen jede Abteilung separat crawlt — unternehmensweite Data-Collection-Governance zur Beendigung doppelter Investitionen
Jetzt starten
Teilen Sie uns mit, welchen Standard Ihre aktuelle Pipeline verwendet — Airflow-Orchestrierung, S3-Data-Lake oder direktes Laden ins DW — und wir entwerfen gemeinsam von der Schnittstelle an, wie sich externe Webdatenerhebung passend zu diesem Standard anbinden lässt. Von Schema-Verträgen über Validierungsmetadaten bis zu Katalogmetadaten stimmen wir alles auf die Sprache des Datenteams ab.
