dbt verlässt das Warehouse. Sind Ihre Pipelines bereit?

Von Andrew Tan

Der geplante Lauf, der früher ausreichte

Für den Großteil des letzten Jahrzehnts sah der Analytics-Workflow so aus:

Daten aus Ihren Quellen extrahieren. In ein Warehouse laden. SQL-Modelle in dbt schreiben. Diese alle paar Stunden ausführen lassen. Dashboards darauf aufbauen. Wenn das Unternehmen fragt, warum die Zahlen nicht stimmen, überprüfen Sie das Aktualitätsabzeichen und entdecken, dass der Job vor sechs Stunden fehlgeschlagen ist.

Es war nicht perfekt, aber es war vorhersehbar. Der Vertrag zwischen Analytics und Engineering war klar: Modelle werden im Warehouse, nach einem Zeitplan, in SQL erstellt. dbt machte diesen Vertrag elegant. Versionskontrollierte Modelle, automatisierte Tests, Abhängigkeitsdiagramme, Dokumentation, die aus dem Code generiert wird. Für Batch-Analytics war es ein echter Fortschritt.

Dann begann das Unternehmen, nach frischeren Daten zu fragen. Nicht am nächsten Tag frisch. Nicht stündlich frisch. Ereignisgesteuert frisch. Die Art von Frische, bei der ein Kunde sein Profil aktualisiert und die Empfehlungsmaschine davon weiß, bevor er wegklickt.

Und plötzlich reicht der geplante Lauf nicht mehr aus.

Warum der Erfolg von dbt eine Laufzeitlücke geschaffen hat

Die Kernidee von dbt war die Trennung der Modelllogik von der Ausführungsinfrastruktur. Sie schreiben das SQL. dbt kümmert sich um den DAG, die Tests, die Dokumentation, die Materialisierungsstrategie. Die eigentliche Berechnung läuft dort, wo Sie es angeben — Snowflake, BigQuery, Redshift, Databricks. dbt ist es egal. Es ist ein Compiler und Orchestrator für SQL-Modelle, keine Laufzeitumgebung.

Diese Trennung war genial für Batch-Workloads. Es bedeutete, dass Analytics-Ingenieure die Modelllogik besitzen konnten, ohne Cluster, Partitionierungsstrategien oder Speichertuning verwalten zu müssen. Das Warehouse kümmerte sich um all das. Der Analytics-Ingenieur konzentrierte sich auf die Semantik: Was bedeutet dieses Modell, wie wird es getestet, wer ist davon abhängig.

Aber diese Trennung setzt etwas Wichtiges voraus: dass die Ausführungsschicht die Workload bewältigen kann, die Sie ihr auferlegen. Und für geplante Batch-Jobs gegen ein modernes Warehouse stimmt das. Für Real-time Processing gegen Streaming-Daten nicht.

Die Lücke liegt nicht im SQL. dbt's SQL ist immer noch SQL. Die Lücke liegt in allem, was zwischen dem Ereignis und dem Modellergebnis passiert:

• Aktualitäts-SLA. Ein dbt-Modell, das alle fünfzehn Minuten läuft, ist immer noch fünfzehn Minuten hinterher. In einem Streaming-Kontext sind fünfzehn Minuten ein Batch-Job in einem kleineren Kostüm.
• Ungeordnete Ereignisse. Gestreamte Daten kommen spät, dupliziert oder in falscher Reihenfolge an. Ein SQL-Modell, das geordnete Eingaben voraussetzt, liefert ohne Warnung falsche Ergebnisse.
• Zustandsbehaftete Operationen. Fensterfunktionen, Sessionisierung, Duplikatentfernung — diese müssen den Zustand über Ereignisse hinweg beibehalten. dbt's Materialisierungsstrategien (Tabelle, inkrementell, ephemer) wurden nicht für das Management von Ereigniszeit-Zuständen entwickelt.
• Operative Joins. Einen Strom von Bestellungen in Echtzeit mit einer sich langsam ändernden Dimensionstabelle zu verbinden, ist ein anderes Problem als zwei Warehouse-Tabellen über customer_id zu verbinden. Die Dimension könnte sich während der Abfrage ändern. Der Stream wartet nicht.

Dies sind keine Randfälle. Sie sind die bestimmenden Merkmale der Stream-Verarbeitung. Und dbt delegiert, durch Design, all diese an die Ausführungsschicht.

Was die Anbieter tatsächlich verkaufen

Wenn Sie im letzten Jahr auf einer Datenkonferenz waren, haben Sie den Marketingwandel gesehen. Confluent drängt auf dbt-native Modellierung auf Flink. Fivetran hat dbt Wizard mit KI-unterstützter Modellerstellung eingeführt. Snowflake hat Dynamic Tables angekündigt, BigQuery hat Materialized Views, Databricks setzt verstärkt auf Delta Live Tables.

Die Botschaft ist konsistent: Sie können Ihren dbt Workflow beibehalten und einfach... in Echtzeit umsetzen. Das SQL bleibt gleich. Der DAG bleibt gleich. Das Einzige, was sich ändert, ist die Geschwindigkeit.

Das ist ungefähr zur Hälfte wahr.

Ja, Sie können SQL auf Streaming-Daten ausführen. Flink SQL, Spark Structured Streaming und eine wachsende Liste von Stream-Prozessoren unterstützen SQL-Syntax, die vertraut aussieht. Ja, Sie können diese SQL-Dateien versionieren und DAGs erstellen. Einige Tools unterstützen sogar dbt-ähnliche Tests und Dokumentation.

Was sie Ihnen nicht sagen, ist, dass die andere Hälfte des Problems — die Laufzeithälfte — nicht verschwindet. Sie ändert nur ihre Form.

Wenn Sie von geplanten Batch- zu kontinuierlichem Streaming wechseln, übernehmen Sie ein neues Set von Bedenken, die dbt nie lösen musste:

Das SQL mag gleich aussehen. Aber das System, das es ausführt, löst ein völlig anderes Set von Problemen.

Die Eigentumsfrage, die niemand beantworten will

Hier wird es organisatorisch. dbt schuf eine klare Grenze: Analytics-Ingenieure besitzen die Modelle, Plattform-Ingenieure das Warehouse. Wenn ein Modell fehlschlägt, ist es normalerweise ein SQL-Problem oder ein Datenqualitätsproblem. Wenn das Warehouse langsam ist, ist es ein Plattformproblem. Die Trennung der Anliegen entsprach sauber einer Trennung der Teams.

Streaming durchbricht diese Grenze.

Wenn eine Real-time Pipeline fehlschlägt, ist es dann ein SQL-Problem oder ein Infrastrukturproblem? Wenn Ereignisse ungeordnet ankommen, schreibt der Analytics-Ingenieur die Fensterlogik um, oder konfiguriert der Plattform-Ingenieur die Wasserstandseinstellungen des Stream-Prozessors neu? Wenn ein spät ankommendes Ereignis eine materialisierte Ansicht beschädigt, wer behebt es — die Person, die das SQL geschrieben hat, oder die Person, die das Checkpointing verwaltet?

Ich habe Teams gesehen, die dies auf drei Arten handhaben, und nur eine davon funktioniert:

Option 1: Analytics-Ingenieure lernen Stream-Verarbeitung. Sie werden fließend in Checkpointing, Backpressure, Ereigniszeit vs. Verarbeitungszeit und genau-einmal-Semantik. Das funktioniert für kleine Teams mit erfahrenen Leuten. Es skaliert nicht.

Option 2: Plattform-Ingenieure besitzen alles, was nach Kafka kommt. Die Analytics-Ingenieure schreiben SQL-Spezifikationen, und das Plattform-Team implementiert sie in Flink oder Spark. Dies bewahrt die Trennung, schafft aber eine Übersetzungsschicht. SQL-Spezifikationen sind mehrdeutig in Bezug auf das Verhalten zur Ereigniszeit. Das Plattform-Team trifft Annahmen. Diese Annahmen werden sechs Monate später zu Bugs.

Option 3: Trennen Sie die Modelllogik von der Laufzeitverantwortung. Analytics-Ingenieure besitzen, was das Modell bedeutet — die Geschäftslogik, die Tests, die Semantik. Plattform-Ingenieure besitzen, wie es läuft — die Ausführungs-Engine, das Zustands-Backend, die Fehlerbehebung. Beide Seiten einigen sich auf einen Vertrag: das Modell erwartet geordnete Eingaben innerhalb einer begrenzten Verspätung, und die Laufzeit garantiert diesen Vertrag oder zeigt einen klaren Fehler an.

Diese dritte Option ist schwieriger einzurichten. Sie erfordert, dass beide Teams sich im Voraus auf Schnittstellen und Fehlermodi einigen. Aber es ist die einzige, die skaliert, ohne Ihre Analytics-Ingenieure in verteilte Systemexperten zu verwandeln oder Ihr Plattform-Team in Gedankenleser.

Was "Real-time dbt" tatsächlich erfordert

Wenn Ihr Team ernsthaft daran interessiert ist, dbt-ähnliche Modelle in Real-time Pipelines zu integrieren, benötigen Sie Folgendes — nicht das, was im Marketing-Deck steht:

Eine Laufzeit, die die Ereigniszeit versteht. Nicht nur die Verarbeitungszeit. Der Unterschied zwischen "Wann ist das angekommen" und "Wann ist das passiert" ist der Unterschied zwischen korrekten Ergebnissen und subtil falschen Ergebnissen, die auf einem Dashboard gut aussehen.

Explizites Zustandsmanagement. Fensterung, Duplikatentfernung und Sessionisierung erfordern alle einen Zustand. Dieser Zustand muss gesichert, wiederherstellbar und für das Debugging abfragbar sein. Wenn Sie nicht inspizieren können, was das System letzten Dienstag um 14:47 Uhr dachte, können Sie keinen Produktionsvorfall debuggen.

Schemaentwicklung mit Substanz. Eine Spalte hinzuzufügen ist einfach. Einen Typwechsel, eine Umbenennung oder eine semantische Verschiebung in der Bedeutung einer Spalte zu handhaben, ist schwer. Ihre Pipeline muss diese Änderungen erkennen, entscheiden, ob sie sicher sind, und entweder anpassen oder mit einem klaren Fehler stoppen.

Wiedergabe und Nachfüllung als erstklassige Operationen. Im Batch bedeutet Neuverarbeitung, einen Job neu auszuführen. Im Streaming bedeutet es, ein Protokoll zurückzuspulen und Ereignisse durch dieselbe Logik erneut abzuspielen. Wenn Ihre Real-time Pipeline nicht genau wiedergeben kann, können Sie keine Fehler beheben, keine Änderungen gegen historische Daten testen und keine Compliance nachweisen.

Kostenübersicht nach Workload. Batch-Kosten sind leicht zu verstehen: Dieser Job hat so viele Daten verarbeitet und so lange gedauert. Streaming-Kosten sind kontinuierlich: Der Job läuft immer, verbraucht immer Ressourcen, und die Kosten korrelieren nicht sauber mit dem Geschäftsergebnis. Sie benötigen Telemetrie, die den Infrastrukturverbrauch mit dem Pipeline-Verhalten verbindet.

Keines davon sind SQL-Funktionen. Es sind Laufzeitfunktionen. Und sie sind der Unterschied zwischen einer Demo, die zehn Minuten läuft, und einem System, das zehn Monate läuft.

Das ehrliche Angebot

dbt hat verändert, wie Analytics-Teams arbeiten. Es brachte Software-Engineering-Praktiken — Versionskontrolle, Tests, Dokumentation — in eine Disziplin, die diese dringend benötigte. Dieser Beitrag ist real und dauerhaft.

Aber dbt wurde für eine Welt gebaut, in der Daten in Batches bewegt werden, Warehouses der Schwerpunkt sind und "frisch" bedeutet "diese Stunde aktualisiert". Die Branche bewegt sich in Richtung einer Welt, in der Daten kontinuierlich bewegt werden, Modelle im Flug angewendet werden und "frisch" bedeutet "diese Millisekunde aktualisiert".

Das macht dbt nicht obsolet. Es macht dbt unvollständig für eine wachsende Anzahl von Anwendungsfällen.

Die Anbieter, die "Real-time dbt" verkaufen, reagieren auf eine echte Nachfrage. Aber was sie verkaufen, ist normalerweise eine SQL-Schnittstelle auf einem Stream-Prozessor, keine Lösung für die Laufzeitprobleme, die die Stream-Verarbeitung mit sich bringt. Das SQL ist der einfache Teil. Das Zustandsmanagement, die Fehlerbehebung, die Schemaentwicklung und die betriebliche Beobachtbarkeit sind die schwierigen Teile. Und diese schwierigen Teile verschwinden nicht, nur weil das SQL vertraut aussieht.

Wenn Sie eines dieser Tools evaluieren, fragen Sie nicht "Kann es meine dbt-Modelle schneller ausführen?" Fragen Sie "Was passiert, wenn ein Knoten mitten im Fenster neu startet?" "Wie spiele ich die Daten vom letzten Dienstag durch ein Modell, das ich gestern geändert habe?" "Was macht das System, wenn sich das Schema um 2 Uhr morgens ändert?"

Die Antworten auf diese Fragen werden Ihnen sagen, ob Sie ein schnelleres Batch-Tool oder eine echte Streaming-Laufzeit kaufen.

Wo wir hineinpassen

Bei layline.io haben wir eine Laufzeit entwickelt, die sowohl Batch- als auch Streaming in derselben Pipeline verarbeitet. Nicht zwei separate Systeme mit einem SQL-Anstrich über jedem. Ein System, in dem dasselbe Team geplante Warehouse-Ladungen und Real-time Event Processing erstellen kann, ohne Werkzeuge, Kontexte oder mentale Modelle zu wechseln.

Die Analytics-Ingenieure behalten die Verantwortung für die Modellsemantik. Das Plattform-Team behält die Verantwortung für die Ausführungsinfrastruktur. Aber beide Seiten arbeiten in derselben Umgebung, mit derselben Beobachtbarkeit und denselben Garantien bezüglich Wiedergabe, Zustandswiederherstellung und Schemaentwicklung.

dbt hat der Branche beigebracht, dass Modelllogik Strenge verdient. Wir bauen auf dieser Idee auf — und fügen die Laufzeitstrenge hinzu, die Real-time Daten erfordern.

Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, das Unternehmensdatenverarbeitungsinfrastruktur entwickelt, die sowohl Batch- als auch Real-time Workloads in großem Maßstab verarbeitet.