Von Andrew Tan
Der typische Orchestrierungs-Stack eines Datenteams entwickelt sich in vernünftigen Schritten. Man beginnt mit Airflow. Es ist in Ordnung. Das Team kennt es. DAGs laufen nach Zeitplan. Fünf Jahre später laufen 300 DAGs auf Airflow und jeder hat stillschweigend Angst, das Basis-Image zu berühren.
Dann braucht man etwas Modernes. Ein neuer Mitarbeiter drängt auf Prefect — es ist Python-nativ, die Entwicklererfahrung ist besser und die Benutzeroberfläche ist sauberer. Also startet man neue Projekte in Prefect und lässt die alten in Airflow.
Dann taucht ein ML-Team auf. Sie wollen Dagster, weil asset-zentriertes Denken und Abstammungsverfolgung zu ihrer Feature-Store-Arbeit passen. Vernünftig. Man fügt Dagster hinzu.
Niemand hat eine schlechte Entscheidung getroffen. Jedes Tool war im Kontext die richtige Wahl. Aber das Team zahlt jetzt für drei Scheduler, drei Sätze von Arbeitern, drei Überwachungs-Dashboards und drei mentale Modelle. Wenn Daten von Airflow in Dagster fließen, bevor sie zu einem von Prefect orchestrierten API-Aufruf gehen, bricht die Abstammung. Man kann jeden Schritt isoliert sehen. Man kann nicht die gesamte Kette sehen.
Das ist die Orchestrierungssteuer. Und sie ist in Unternehmen, die seit mehr als zwei Jahren Dateninfrastruktur aufbauen, nahezu universell.
Wie die Steuer sichtbar wird
Die versteckte Rechnung erscheint an drei Stellen, die die meisten Teams nicht messen.
Die Koordinationsnaht. Wenn Pipeline A (Airflow) Pipeline B (Dagster) auslösen muss, wie macht sie das? Normalerweise: ein Dateiabwurf, ein Datenbank-Flag, ein API-Aufruf oder — am häufigsten — eine Slack-Nachricht zwischen den Menschen, die jedes System besitzen. Diese "Integration" ist jetzt tragend. Wenn sie bricht, schlägt sie stillschweigend fehl. Man erfährt es drei Stunden später, wenn die Dagster-Pipeline mit den Daten von gestern gelaufen ist.
Einige Teams enden mit einem gesamten Ingenieur, der sich der Pflege dessen widmet, was sie intern die "Kleberschicht" nennen. Das ist eine Vollzeitrolle, die Python-Skripte schreibt, um drei Orchestrierungstools so zu gestalten, als wären sie eins.
Das Debugging-Labyrinth. Ein Datenqualitätsproblem taucht im BI-Tool auf. Die Zahl ist falsch. Wo ist der Fehler aufgetreten? Man beginnt bei den Airflow-Logs. Der DAG war erfolgreich. Man überprüft Prefect — der Ereignisfluss war erfolgreich. Man überprüft Dagster — die Assets wurden materialisiert. Irgendwo im Übergang zwischen den Systemen ging etwas schief, und es gibt keine einheitliche Sicht darauf, was passiert ist.
Die MTTR (Mean Time to Resolution) für systemübergreifende Fehler ist durchweg 3-5x höher als bei fehlern innerhalb eines Systems bei den Teams, die dies verfolgen. Die Debugging-Kosten sind das größte versteckte Stück.
Die Kosten des Kontextwechsels. Der Scheduler von Airflow denkt in Cron-Ausdrücken und Aufgabenabhängigkeiten. Dagster denkt in Assets und Frische-Richtlinien. Prefect denkt in Flows und Deployments. Jedes hat sein eigenes Authentifizierungsmodell, sein eigenes Geheimnismanagement, seine eigene Art, Wiederholungen zu handhaben. Ingenieure werden in allen drei fließend — was bedeutet, dass sie in keinem von ihnen Experten sind, und jeder Werkzeugwechsel kostet kognitive Überlastung, die in keinem Sprint-Tracker auftaucht.
Die Kestra-Situation
Deshalb resoniert Kestrs Marketing. Ihr Versprechen — "Sie können Airflow, Spark, dbt und benutzerdefinierte Skripte aus einem Orchestrator ausführen" — spricht die Frustration über mehrere Tools direkt an.
Aber es gibt einen Unterschied zwischen einer einzigen Glasscheibe und einer einzigen Quelle der Wahrheit. Kestra kann Ihre bestehenden Tools einbinden. Das ist nützlich. Es reduziert jedoch nicht das Problem der verteilten Koordination. Man hat ein weiteres Tool zu drei Tools hinzugefügt.
Die Orchestrierungsausbreitung ist kein UI-Problem. Es ist ein Problem des Datenflussbesitzes. Wer besitzt das Ereignis, das die Kette auslöst? Wer besitzt das Schema der Daten, die zwischen den Systemen übertragen werden? Wer ist verantwortlich, wenn der Übergang zwischen Schritt 2 und Schritt 3 fehlschlägt?
Eine neue Orchestrierungsschicht oben beantwortet diese Fragen nicht. Sie fügt nur ein weiteres System hinzu, das man sich ansehen muss, wenn man um 2 Uhr morgens debuggt.
Was tatsächlich hilft
Lassen Sie uns direkt darüber sprechen, was funktioniert und was das Problem nur verlagert.
Funktioniert: Konsolidierung um ein Modell, aggressiv. Wählen Sie das Tool, das 80% Ihrer aktuellen Arbeitslast gut bewältigt, migrieren Sie alles, was Sie können, und leben Sie mit der Reibung, alte Jobs zu verschieben. Es ist sechs Monate lang schmerzhaft. Danach haben Sie ein Planungsmodell, einen Satz von Arbeitern, einen Ort, an dem Sie nachsehen können, wenn etwas schiefgeht. Die Teams, die dies tun, berichten durchweg von einer Reduzierung der Reaktionszeit bei Vorfällen um 40-60% innerhalb eines Jahres.
Funktioniert: Behandeln von systemübergreifenden Übergaben als erstklassige Daten. Wenn Sie aus legitimen Gründen mehrere Tools betreiben müssen (z.B. profitieren ML-Pipelines wirklich vom Asset-Modell von Dagster), machen Sie jede Übergabe zu einem expliziten, überwachten Datentransfer. Kein Dateiabwurf. Kein Datenbank-Flag, das jemand vor vier Jahren zu einer Tabelle hinzugefügt hat. Ein definiertes Schema, mit Beobachtbarkeit, mit Wiederholungen, mit Alarmierung. Der Kleber wird Teil Ihres Systemdesigns und nicht ein Unfall davon.
Funktioniert nicht: Hinzufügen von Beobachtbarkeit über Fragmentierung. Ein weiteres Dashboard, das den Status aller drei Systeme anzeigt, löst das Koordinationsproblem nicht — es macht den verteilten Fehler nur an mehr Orten sichtbar. Sie brauchen weniger Dinge zu beobachten, nicht bessere Tools, um mehr Dinge zu beobachten.
Funktioniert nicht: Migrations-Theater. "Wir migrieren in den nächsten 18 Monaten zu Dagster" ist kein Plan. Es ist eine Aussage, dass der Schmerz noch nicht groß genug ist, um die eigentliche Arbeit zu tun. Solange Sie das alte Tool nicht tatsächlich außer Betrieb nehmen, fügen Sie nur Integrationsoberfläche hinzu, während Sie planen.
Das Batch/Streaming-Stück
Ein echter Grund, warum Teams mehrere Orchestrierungstools betreiben, ist, dass Batch und Streaming tatsächlich unterschiedliche Anforderungen haben. Airflow plant Jobs. Kafka verarbeitet Streams. Unterschiedliche Paradigmen, unterschiedliche Tools — und wenn Sie versuchen, beide in derselben Datenplattform zu bedienen, enden Sie mit zwei separaten Workflow-Management-Systemen.
Dies ist es wert, direkt benannt zu werden: Eine Plattform, die sowohl Batch als auch Streaming innerhalb desselben Bereitstellungsmodells, derselben Workflow-Definition und derselben Betriebstools behandelt, bedeutet, dass dasselbe Team, das das nächtliche ETL betreibt, auch die Echtzeit-Ereignisverarbeitung übernehmen kann. Nicht weil jemand Airflow oder Kafka neu erfindet, sondern weil die Trennung zwischen "geplant" und "ereignisgesteuert" nicht zwei separate Ingenieurspezialitäten und zwei separate Überwachungssysteme erfordern sollte.
Das Ziel ist nicht, alles zu ersetzen, was Sie haben. Es geht darum, die Steuer nicht mehr zu zahlen.
Die eigentliche Frage
Das Gespräch läuft normalerweise auf dieselbe Frage hinaus: "Ist dies tatsächlich ein Problem, das es zu lösen gilt, oder nur die Natur des Aufbaus von Datensystemen?"
Fair. Jedes Unternehmen hat technische Schulden. Nicht jede Schuld ist es wert, abbezahlt zu werden.
Hier ist eine einfache Möglichkeit, darüber nachzudenken: Wenn Ihre Bereitschaftsrotation "alle drei Scheduler überprüfen" als Schritt in jedem Runbook enthält, zahlen Sie jede Woche die Orchestrierungssteuer. Wenn ein neuer Dateningenieur einen Monat braucht, um produktiv zu werden, weil er die mentalen Modelle mehrerer Tools lernen muss, zahlen Sie sie bei jeder Einstellung. Wenn Ihr Debugging-Prozess das Überkreuzen von drei verschiedenen Log-Systemen erfordert, zahlen Sie sie bei jedem Vorfall.
Addieren Sie das. Dann entscheiden Sie.
Wenn Sie mit Orchestrierungsausbreitung zu kämpfen haben und verstehen möchten, wie ein Weg zur Konsolidierung aussieht — insbesondere wenn Sie sowohl Batch- als auch Echtzeit-Arbeitslasten bewältigen — kontaktieren Sie uns. Wir können Ihre spezifische Einrichtung durchgehen und Ihnen ein ehrliches Bild davon geben, was es wert ist, geändert zu werden und was nicht.
Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, der Unternehmensdatenverarbeitungsinfrastrukturen aufbaut, die sowohl Batch- als auch Echtzeit-Arbeitslasten im großen Maßstab bewältigen.
