Wie Cloudflare seinen Data Stack rund um dbt, Fivetran und Airflow neu gebaut hat

Mitte 2022 pflegte das Data-Engineering-Team von Cloudflare mehrere Hundert eigens geschriebene Python-Skripte, die Daten aus Produktdatenbanken, Salesforce, Stripe und einem Dutzend weiterer Quellen nach Snowflake bewegten. Die Skripte waren über Jahre schnellen Einstellens entstanden, jedes nach etwas anderen Konventionen geschrieben, ohne gemeinsames Testing-Framework und ohne verlässliche Möglichkeit nachzuvollziehen, was wann lief. Wenn Pipelines brachen, war der Fehlermodus meist stillschweigend: Ein Dashboard weiter unten wurde veraltet, und drei Tage später fiel es jemandem im Finanzbereich auf. Für ein Unternehmen, das täglich Billionen DNS-Abfragen verarbeitet und Enterprise-Kunden nutzungsbasierte Verträge verkauft, waren veraltete Umsatzdaten kein abstraktes Problem.

Das Team stand vor einer Wahl, die in schnell wachsenden B2B-SaaS-Unternehmen häufig vorkommt: das bestehende System weiter flicken oder bewusst einen architektonischen Neuanfang machen. Sie entschieden sich für Letzteres, und wie sie dabei vorgegangen sind, lässt sich weit über den spezifischen Kontext von Cloudflare hinaus übertragen.

Was sie getan haben

Die architektonische Wette lag auf drei Komponenten im Zusammenspiel: Fivetran für managed Ingestion, dbt (data build tool) für Transformation und Apache Airflow für Orchestrierung. Jeder Layer hatte eine eigene Begründung.

Fivetran (ein kommerzieller Anbieter, diese Einschätzungen sollten also zusammen mit unabhängigen Benchmarks gelesen werden) ersetzte die selbst gebauten Ingestion-Skripte. Die Logik war einfach: CDC-Connectoren (Change Data Capture) für Salesforce, Zendesk und Stripe zu pflegen, ist für ein Unternehmen für Netzwerkinfrastruktur keine Quelle von Wettbewerbsvorteilen. Diesen Wartungsvertrag einzukaufen, befreite die Engineers von der Connector-Pflege und verlagerte das Handling von Ingestion-Fehlern in ein Vendor-SLA. Der Tradeoff sind Kosten und Lock-in, was Cloudflare akzeptierte, weil die Opportunitätskosten ihrer Engineering-Zeit höher waren als die Abo-Gebühr.

Im dbt-Layer wurden die interessanteren architektonischen Entscheidungen getroffen. Cloudflare strukturierte sein dbt-Projekt nach einem Staging/Intermediate/Mart-Muster, das inzwischen eine breit übernommene Konvention ist, teils weil dbt Labs (das kommerzielle Unternehmen hinter dbt Core und dbt Cloud) es propagiert hat, wobei unabhängige Praktiker-Communities es als tatsächlich nützlich bestätigt haben. Staging-Modelle taten nichts anderes, als Spalten aus den Rohquellen umzubenennen und leicht zu bereinigen. Intermediate-Modelle jointen und filterten. Mart-Modelle waren der einzige Layer, den Business-Nutzer und BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.Vollständige Definition ansehen →-Tools direkt abfragten. Diese Trennung bedeutete: Wenn Salesforce einen Feldnamen änderte, war der Fix auf ein Staging-Modell begrenzt statt über Dutzende nachgelagerte Queries verstreut.

Das Team investierte außerdem stark in das Testing-Framework von dbt und schrieb Not-Null-, Uniqueness- und Referential-Integrity-Tests für jedes Modell. Das klingt banal, war aber der Mechanismus, über den stille Fehler zu lauten wurden. Wenn ein Fivetran-Sync einen fehlerhaften Batch lieferte, fingen die dbt-Tests ihn ab, bevor der Mart-Layer lief, und Airflow machte den Fehler als gebrochenen DAG-Schritt mit Slack-Alert sichtbar. Die Schleife von Fehler bis Erkennung verkürzte sich von Tagen auf Minuten.

Airflow übernahm die Orchestrierung, weil Cloudflare bereits Kubernetes-Infrastruktur und die interne Python-Expertise hatte, um sie zu betreiben. Das ist erwähnenswert: Airflow gut zu betreiben ist operativ teuer. Teams ohne bestehende Kubernetes-Erfahrung stellen oft fest, dass managed Alternativen wie Prefect, Dagster oder der Scheduler von dbt Cloud die gesamte operative Last deutlich senken. Cloudflares Entscheidung war kontextabhängig, nicht allgemein richtig.

Der Data-Contract-Layer, den sie später ergänzt haben

Ein Element, über das in den meisten ELTELTELT (Extract, Load, Transform) is a data integration pattern where raw data is loaded into a target system first, then transformed inside it using the platform's compute power.Vollständige Definition ansehen →-Case-Studies kaum berichtet wird, ist das, was Cloudflares Team auf den Standard-Stack aufgesetzt hat. Ende 2023 führten sie leichtgewichtige Data Contracts auf der Staging-Ebene ein: explizite Schemadefinitionen, an die sich vorgelagerte, produzierende Teams halten sollten, mit automatisierter Validierung in der dbt-PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen →. Wenn ein Backend-Engineering-Team das Events-SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen → in seinem Kafka-Topic änderte, schlug der Contract-Check fehl, bevor irgendein nachgelagertes Modell lief, und das produzierende Team erhielt den Alert, anstatt dass das Data-Team den Bruch stillschweigend auffing. Diese organisatorische Verschiebung, Produzenten für Schemastabilität verantwortlich zu machen, war genauso folgenreich wie jede Tooling-Entscheidung.

Die Ergebnisse

Cloudflare hat keine detaillierte öffentliche Nachbetrachtung mit konkreten prozentualen Verbesserungen veröffentlicht, ein Teil des Folgenden stammt also aus Konferenzvorträgen und Engineering-Blogposts, nicht aus geprüften Zahlen. Die Aussagen sollten mit diesem Vorbehalt gelesen werden.

Ihr Engineering-Blog vermerkte, dass die Zahl der Datenvorfälle mit manuellem Eingriff in den sechs Monaten nach dem vollständigen Rollout des dbt-Testing-Frameworks deutlich zurückging. Die Entwicklungszeit für Pipelines neuer Datenquellen sank nach eigener Schätzung des Teams von mehreren Wochen (inklusive Connector-Pflege) auf Tage mit Fivetran plus einem neuen dbt-Staging-Modell. Der Business-Effekt, den sie am häufigsten nannten, betraf die Umsatzrealisierung: Die Finance-Teams konnten den Monatsabschluss nach einem konsistenten, wiederholbaren Zeitplan abschließen, statt auf Ad-hoc-Datenfixes zu warten.

Aus öffentlichen Informationen überprüfbar ist, dass der Headcount von Cloudflares Data-Team zwischen 2022 und 2025 nicht linear mit dem Wachstum des Datenvolumens des Unternehmens mitskalierte. Das ist bedeutsam: Es legt nahe, dass die architektonische Investition Leverage gebracht hat, auch wenn der Beitrag des ELT-Stacks von anderen Faktoren (Qualität der Einstellungen, Tooling an anderer Stelle) nicht einfach zu isolieren ist.

Was übertragbar ist

Das Muster, das über Kontexte hinweg funktioniert, ist die strikte Trennung von Ingestion, Transformation und Orchestrierung als eigenständige Aufgaben mit eigenständiger Verantwortung. Sind diese drei Funktionen in monolithischen Skripten zusammengefallen, birgt jede Änderung Risiko für die gesamte Pipeline. Ihre Trennung schafft ein System, in dem ein Connector-Fehler die Transformationslogik nicht verdirbt und ein Transformations-Bug kein Ingestion-Problem verdeckt.

Der Data-Contract-Ansatz überträgt sich besonders gut auf Organisationen, in denen mehrere Produktteams ein zentrales Data WarehouseData WarehouseA central repository that consolidates data from many source systems into a structured, query-optimized store designed for analytics, reporting, and business intelligence.Vollständige Definition ansehen → befüllen. Ohne Contracts wird das Data-Team zum dauerhaften Vermittler, der jede vorgelagerte Änderung auffängt. Mit Contracts wird Schemastabilität zu einer gemeinsamen Engineering-Verantwortung.

Wo sich Cloudflares Kontext von den meisten unterscheidet: Sie hatten eine starke interne Kubernetes-Infrastruktur und ein Data-Engineering-Team mit senioren Python-Leuten. Kleinere Organisationen oder solche ohne diese Infrastruktur sollten managed Orchestrierung ernsthaft prüfen, bevor sie standardmäßig auf selbst gehostetes Airflow setzen. Das Tooling ist nicht der Punkt. Die architektonische Trennung ist es.

Der praktische Einstieg ist für die meisten Teams nicht, Cloudflares kompletten Stack auf einmal nachzubauen. Setzen Sie dbt-Tests zuerst auf Ihre kritischsten Mart-Modelle, leiten Sie Fehler in einen Slack-Channel und beobachten Sie, wie schnell sich das Verhältnis der Organisation zur Datenzuverlässigkeit ändert. Diese Feedback-Schleife ist der Mechanismus. Alles andere ist Implementierungsdetail.