Von Andrew Tan
Die teure Wahrheit über moderne Data Stacks
Wer länger mit Data-Platform-Teams zusammenarbeitet, hört immer dieselbe Geschichte. Ein Unternehmen baut seinen "modernen Data Stack" auf — Warehouse, Processing Layer, Orchestrator — und auf dem Architekturdiagramm sieht alles sauber aus. Dann beginnt die Warehouse-Rechnung zu steigen. Ingestion-Jobs fallen öfter aus als erwartet. Und jedes Mal, wenn etwas bricht, dauert es einen halben Tag herauszufinden, ob das Problem beim Load, beim Reshape, beim Orchestrator oder im Warehouse selbst liegt.
Irgendwann sagt jemand im Team den stillen Teil laut: "Ich glaube, wir haben versehentlich ein wirklich teures Integrationstool gebaut."
Meist hat er recht.
Der Kategorienfehler
Ein Data Warehouse ist ein Query- und Storage-Engine. Es ist auf eine Sache optimiert: analytische Fragen über große Datensätze schnell zu beantworten.
Eine Data Pipeline ist eine Runtime für Bewegung und Verarbeitung. Sie ist auf etwas anderes optimiert: Daten von dort, wo sie sind, dorthin zu bringen, wo sie hingehören — in der richtigen Form, zur richtigen Zeit, zuverlässig.
Das sind verschiedene Aufgaben. Aber in den letzten zehn Jahren haben wir das Warehouse stillschweigend gebeten, beides zu tun.
Es begann harmlos. Warehouses wurden besser im Laden von Daten. Dann kamen Stored Procedures. Dann machte dbt aus SQL einen Processing Layer. Dann begannen Orchestrator, Warehouse-Queries auszulösen, um Daten zwischen Tabellen zu bewegen. Und bevor jemand es benannte, war das Warehouse zur Standard-Integrationsschicht geworden.
Das Ergebnis ist vorhersehbar. Das Warehouse ist exzellent in Analytics. Es ist mittelmäßig in Integration. Und wenn man es zwingt, Integration in großem Maßstab zu übernehmen, zahlt man dafür in drei Währungen: Kosten, Zuverlässigkeit und architektonische Fragilität.
Was schiefgeht, wenn das Warehouse zur Pipeline wird
Die Compute-Rechnung wird zur Überraschung
Warehouse Compute ist für analytische Queries bepreist. Analysten führen einige große Queries aus, warten auf Ergebnisse und treffen dann Entscheidungen. Der Compute ist bursty und menschlich getaktet.
Integrations-Workloads sehen anders aus. Sie laufen kontinuierlich oder in engen Zeitfenstern. Sie bewegen Millionen von Zeilen. Sie führen dieselben Konvertierungen immer wieder aus. Sie machen keine Pause, damit Menschen Dashboards lesen können.
Wenn man diese Art von Workload in einem Warehouse ausführt, dreht sich der Zähler anders. Es ist üblich, dass ein "einfacher" stündlicher Sync mehr Credits verbraucht als die gesamte Analytics-Workload. Nicht weil das Warehouse schlecht ist, sondern weil es die falsche Engine für diese Aufgabe ist.
Fehler werden undurchsichtig
Eine Pipeline hat eine klare Aufgabe: Daten von A nehmen, transformieren, an B liefern. Wenn sie fehlschlägt, will man wissen, welcher Schritt warum gescheitert ist.
Wenn das Warehouse die Pipeline ist, verteilt sich der Fehler über mehrere Ebenen. War der Load langsam, weil das Warehouse überlastet war? Hat der Orchestrator die Verbindung verloren? Ist die Reshape-Query in ein Timeout gelaufen? Sind die Daten falsch wegen der Quelle, der Konvertierung oder einer Änderung des Warehouse-Ausführungsplans?
Debuggen wird zur Archäologie. Man wühlt sich durch Query-Verlauf, Orchestrator-Logs und Warehouse-Metriken und versucht zu rekonstruieren, was tatsächlich passiert ist. Die Tools sind alle vorhanden. Die Klarheit fehlt.
Latency ist das, was das Warehouse bestimmt
Wenn Ihre Pipeline aus einer Reihe von Warehouse-Queries besteht, ist Ihre Latency durch Warehouse-Scheduling begrenzt. Eine Query wartet in einer Warteschlange. Sie kompiliert. Sie läuft. Vielleicht wird sie unterbrochen. Vielleicht skaliert sie hoch. Vielleicht auch nicht.
Für Batch-Analytics ist das in Ordnung. Niemanden interessiert es, ob ein nächtlicher Report um 3:00 Uhr oder 3:15 Uhr fertig wird.
Für operationale Use Cases ist es das nicht. Fraud Detection, Bestandsaktualisierungen, kundenorientierte Dashboards — diese brauchen Minuten oder Sekunden, keine Warehouse-Warteschlangenzeit. Wenn das Warehouse Ihre Pipeline ist, erben Sie dessen Tempo. Und dieses Tempo ist für Analysten, nicht für Operationen, konzipiert.
Lock-in vertieft sich
Je mehr Integrationslogik im Warehouse lebt, desto schwieriger wird es, es wieder zu verlassen. Ihre Rewrites sind in warehouse-spezifischen SQL-Dialekten. Ihre Orchestrierung ist an Warehouse-Sessions gebunden. Ihre Datenqualitätsregeln laufen als Warehouse-Queries. Sogar Ihre Kostensichtbarkeit ist warehouse-geformt.
Das ist keine Verschwörung. Es passiert einfach, wenn ein Tool für zu viele Aufgaben verantwortlich wird. Die Migrationskosten wachsen, bis es einfacher erscheint, unglücklich zu bleiben, als zu wechseln.
Wie saubere Trennung aussieht
Die Lösung ist nicht, das Warehouse wegzuwerfen. Das Warehouse ist gut in dem, was es tut. Die Lösung ist, es das tun zu lassen und es nicht mehr für alles andere zu beanspruchen.
In der Praxis bedeutet das meist zwei Plattformen, nicht eine:
Integration und Orchestration Runtime
Hier bewegen sich Daten, werden reshaped, validiert und an die richtigen Consumer geroutet. Hier werden auch Pipelines geplant, Fehler wiederholt, Abhängigkeiten durchgesetzt und nachgelagerte Arbeiten ausgelöst — sowohl innerhalb der Plattform als auch in externen Systemen. Sie läuft auf einer Engine, die für kontinuierlichen Datenfluss und nicht für Query-Latency konzipiert ist.
Warehouse
Hier werden Daten gespeichert und abgefragt. Es empfängt saubere, sofort abfragbare Daten aus der Integrationsschicht. Es kümmert sich nicht darum, wie die Daten dorthin gelangt sind, wann der nächste Load ankommt oder was bei einem Job-Fehler zu tun ist. Es beantwortet einfach Fragen.
Logisch kann man Integration und Orchestrierung nach wie vor als getrennte Belange betrachten. Operationell gehören sie oft in dieselbe Runtime. Eine Pipeline, die Daten bewegen, aber sich nicht selbst planen, nicht selbst wiederholen und nicht den nächsten Schritt auslösen kann, ist nur halb nützlich. Die besten Plattformen vereinen beides.
Wenn diese Belange vom Warehouse getrennt sind, wird jedes Tool einfacher. Die Integrationsschicht ist auf Throughput und Zuverlässigkeit optimiert. Der Orchestrator ist auf Abhängigkeitsmanagement und Fehlerbehebung optimiert. Das Warehouse ist auf Query-Performance optimiert.
Am wichtigsten bleiben Probleme in ihrer Spur. Wenn Ingestion fehlschlägt, schaut man in die Integration Runtime. Wenn ein Report falsch ist, schaut man ins Warehouse. Wenn ein Job nicht läuft, schaut man in den Orchestrator — der bei sauberer Setup Teil derselben Runtime ist, die die Daten bewegt.
Wann Warehouse-as-Pipeline tatsächlich in Ordnung ist
Ich will das nicht übertreiben. Für manche Teams funktioniert das Warehouse-as-Pipeline-Muster gut.
Wenn Sie klein sind, Ihre Datenvolumen gering, Ihr Reshape einfach und Ihre Latency-Anforderungen "morgen reicht" lauten, dann ist es ein vernünftiger Tradeoff, alles an einem Ort zu behalten. Die operationelle Einfachheit wiegt mehr als die architektonische Reinheit.
Die Probleme beginnen, wenn das Muster über sein natürliches Limit hinaus skaliert. Ein Team, das es überwächst, merkt das in der Regel. Die Rechnungen werden seltsam. Die Fehler werden mysteriös. Die Idee, einen Real-Time Use Case hinzuzufügen, wird zu einem mehrmonatigen Projekt statt einer Konfigurationsänderung.
Die Frage ist nicht, ob das Muster schlecht ist. Die Frage ist, ob es immer noch das richtige Muster für Ihren aktuellen Stand ist.
Der Migrationspfad, den niemand geht
Die meisten Teams stellen sich diese Trennung als Rip-and-Replace-Projekt vor. Das muss sie nicht sein.
Der bessere Ansatz ist, zuerst die Movement Layer zu extrahieren. Wählen Sie eine Datenquelle. Statt sie direkt in das Warehouse zu laden und dort zu reshapen, bewegen Sie sie zuerst durch eine dedizierte Integration Runtime. Bereinigen Sie sie. Validieren Sie sie. Dann schreiben Sie die sauberen Daten in das Warehouse.
Das Warehouse ändert sich nicht viel. Die Analysten fragen weiterhin dieselben Tabellen ab. Aber jetzt werden diese Tabellen von einer Pipeline gefüttert, die darauf ausgelegt ist, Tabellen zu füttern.
Sobald eine Quelle umgezogen ist, wiederholt sich das Muster. Quelle für Quelle. Pipeline für Pipeline. Mit der Zeit hört das Warehouse auf, der Integration Hub zu sein, und wird das, was es sein sollte: der Analytics Hub.
Teams, die das erfolgreich tun, fangen nicht mit der schwierigsten Pipeline an. Sie fangen mit einer langweiligen an. Die langweiligen Pipelines lehren das Muster, ohne das Risiko. Die schwierigen Pipelines werden einfacher, sobald das Muster etabliert ist.
Wo layline.io passt
Ich sage es direkt: Das ist die architektonische Wette hinter layline.io.
Wir haben eine Datenverarbeitungsplattform gebaut, die die Integrations- und Orchestrierungsschicht übernimmt — sowohl Batch als auch Streaming — ohne das Warehouse schwer arbeiten zu lassen. Pipelines bewegen Daten, reshapen sie, validieren sie und liefern sie aus. Sie planen sich auch selbst, wiederholen sich bei Fehlern, setzen Abhängigkeiten durch und lösen nachgelagerte Workflows innerhalb von layline oder in externen Systemen aus.
Das Warehouse speichert die Daten und fragt sie ab. Jedes Tool erledigt seinen eigenen Job.
Weil layline Batch und Streaming in derselben Runtime verarbeitet, enden Sie nicht mit einem Tool für Ihre stündlichen Loads und einem anderen für Ihre Real-Time Events. Dieselben Workflows. Dieselbe Observability. Dasselbe Team. Und weil Orchestrierung eingebaut ist, brauchen Sie keinen separaten Orchestrator darüber, der zwischen layline und allem anderen koordiniert.
Das ist nicht für jeden gedacht. Wenn Ihr Warehouse-as-Pipeline-Setup funktioniert und Ihre Rechnungen vernünftig sind, brauchen Sie uns nicht. Aber wenn Sie auf eine verdreifachte Warehouse-Rechnung starren und sich fragen, wie ein "einfacher" Sync so teuer werden konnte, ist die Trennung, die wir beschreiben, wahrscheinlich genau das, wonach Sie suchen.
Die Frage, die Sie Ihrem Team stellen sollten
Wählen Sie Ihre drei teuersten Warehouse-Workloads aus. Nicht die größten analytischen Queries — die, die den ganzen Tag laufen, um Daten zu bewegen und zu reshapen.
Fragen Sie: Beantworten diese Workloads Geschäftsfragen, oder bringen sie die Daten nur in eine Form, in der sie Geschäftsfragen beantworten können?
Wenn die Antwort die zweite ist, läuft Integrationsarbeit in einer Analytics-Engine. Das ist kein moralisches Versagen. Es ist eine sehr verbreitete Architektur. Aber auch eine sehr behebbare.
Das Warehouse ist ein mächtiges Tool. Es ist eben nicht das einzige.
Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, der Unternehmensdatenverarbeitungsinfrastruktur entwickelt, die sowohl Batch- als auch Echtzeit-Workloads in großem Maßstab verarbeitet.
