Von Andrew Tan
Ich war letztes Jahr auf einer Konferenz, als mich ein Datenarchitekt — Fortune 500, großes Team, ernsthaftes Budget — zur Seite nahm und mir eine Geschichte erzählte, die ich inzwischen zu oft gehört habe.
Sie verbrachten 14 Monate mit der Migration zu Kafka. Stellten ein neues Team ein. Errichteten neue Infrastruktur. Baut eine ganz neue Bereitschaftsrotation auf. Das volle Programm.
Sechs Monate nach dem Start verlegten sie leise die Hälfte der Pipelines zurück zu Batch.
Kafka brach nicht zusammen. Es funktionierte einwandfrei. Das Problem war banaler: Niemand nutzte die Echtzeitdaten. Die Dashboards wurden immer noch um 9 Uhr überprüft. Berichte liefen weiterhin wöchentlich. Die ML-Modelle wurden immer noch über Nacht neu trainiert. Sie hatten ein Formel-1-Auto gebaut, um zum Supermarkt zu fahren.
Der Konferenzvortrag, der tausend Migrationen auslöste
So beginnt es normalerweise. Jemand im Team sieht sich einen Konferenzvortrag an — wahrscheinlich mit 2-facher Geschwindigkeit auf YouTube — in dem ein FAANG-Ingenieur seine Echtzeit-Pipeline beschreibt. Milliarden von Ereignissen pro Sekunde. Latenz im Sub-Millisekundenbereich. Dashboards, die sich wie in der Matrix aktualisieren.
Dieser Ingenieur kommt inspiriert ins Büro zurück. "Das sollten wir machen." Das Team nickt. Der CTO liebt das Wort "Echtzeit" in der vierteljährlichen Roadmap. Ein Jira-Epos wird geboren.
Was niemand fragt: Braucht jemand in diesem Gebäude tatsächlich Daten schneller, als er sie heute bekommt?
Nicht "wäre es schön". Nicht "es klingt moderner". Erhält eine bestimmte Person, die eine bestimmte Entscheidung trifft, messbar schlechtere Ergebnisse, weil die Daten eine Stunde alt statt eine Sekunde alt sind?
Neun von zehn Mal lautet die ehrliche Antwort nein. Und das eine Mal, wo es ja ist, ist es normalerweise eine Pipeline — nicht die ganze Plattform.
Die Einkaufsliste
Bevor Sie irgendetwas migrieren, machen Sie eine Liste. Ich meine es ernst — öffnen Sie eine Tabelle. Beantworten Sie für jede Pipeline drei Fragen:
Wer konsumiert diese Daten? Ein Name. Ein Team. Ein System. Wenn Sie den Verbraucher nicht benennen können, muss die Pipeline möglicherweise überhaupt nicht existieren, geschweige denn in Echtzeit.
Was machen sie damit und wann? Wenn die Antwort lautet "Sie überprüfen jeden Morgen ein Dashboard" oder "Es fließt in einen Bericht am Freitag ein", wird Streaming das Ergebnis nicht ändern. Sie machen nur die Installation teurer für dasselbe Wasser.
Was passiert, wenn diese Daten 1 Stunde zu spät sind? 1 Tag zu spät? Dies ist die einzige Frage, die tatsächlich Batch von Streaming trennt. Wenn die Antwort auf beide "nichts, wirklich" lautet, haben Sie eine Batch-Arbeitslast, die ein Streaming-Kostüm trägt.
Die meisten Teams entdecken, dass 80% ihrer Pipelines als Batch völlig in Ordnung sind. Die verbleibenden 20% sind dort, wo es interessant wird.
Wo Geschwindigkeit tatsächlich zählt
Einige Daten verderben wirklich. Wie Milch, nicht wie Wein.
Betrugserkennung ist das offensichtliche Beispiel. Eine Kreditkartentransaktion, die fünf Minuten nach dem Ereignis markiert wird, ist keine Betrugserkennung — es ist eine Betrugsbenachrichtigung. Das Geld ist bereits weg. Wenn Ihre Betrugspipeline in Batch läuft, schreiben Sie Entschuldigungsbriefe, anstatt Türen zu blockieren.
Unsere Betrugserkennungslösung bietet Echtzeitbewertung mit einer Latenz von unter 100 ms.
Betriebsalarme — wenn Ihr IoT-Sensor Ihnen mitteilt, dass eine Turbine überhitzt, hat diese Information eine Haltbarkeit, die in Sekunden gemessen wird. Ein stündlicher Batch-Job hier ist nicht nur langsam. Es ist fahrlässig.
Preisgestaltung und Inventar in wettbewerbsintensiven Märkten. Wenn Ihr Konkurrent alle 30 Sekunden Preise aktualisiert und Sie alle 6 Stunden, konkurrieren Sie nicht. Sie beobachten.
Multi-Consumer-Ereignisströme, bei denen sich die Wirtschaftlichkeit summiert. Ein Kafka-Thema, das drei nachgelagerte Systeme speist, kann günstiger sein als drei separate Batch-Jobs, die aus derselben Datenbank ziehen. Streaming verdient sich hier nicht durch Geschwindigkeit, sondern durch architektonische Eleganz.
Das Muster: In jedem Fall gibt es einen spezifischen, messbaren Kostenfaktor für Verzögerungen. Kein vages Gefühl. Eine Zahl.
Die Kosten, die niemand im Jira-Epos aufführt
Streaming-Infrastruktur hat ein Preismodell, das auf der Anbieterseite großartig aussieht und in den tatsächlichen Q3-Zahlen schrecklich.
Es läuft 24/7. Ihr Batch-Job läuft 4 Stunden und schläft. Ihr Streaming-Job läuft den ganzen Tag, die ganze Nacht, an Wochenenden, Feiertagen. Auch wenn das gesamte Datenvolumen identisch ist, ist die Rechenrechnung nicht. Ein Team, das ich kenne, ging von einem $2.000/Monat-Batch-Setup zu einem $11.000/Monat-Streaming — bei der Verarbeitung derselben Daten, die an denselben Ort geliefert und im gleichen Rhythmus konsumiert werden.
Debugging geht von Archäologie zu Quantenphysik. Wenn ein Batch-Job fehlschlägt, erhalten Sie einen Stack-Trace, einen fehlerhaften Datensatz und einen klaren Neustartpfad. Wenn ein Streaming-Job falsche Ausgaben produziert, könnte er überhaupt nicht "fehlschlagen". Er speist einfach stillschweigend Müll nach unten, bis jemand bemerkt, dass das Umsatz-Dashboard drei Tage später seltsam aussieht.
Schemaänderungen werden zu einer diplomatischen Verhandlung. In Batch versionieren Sie Ihren Code, testen auf historischen Daten und pushen. Im Streaming bedeutet das Ändern eines Feldes, dass Sie jeden Produzenten und Verbraucher gleichzeitig in einem Live-System koordinieren müssen. Wenn Sie die Reihenfolge falsch machen, debuggen Sie Datenkorruption um 2 Uhr morgens.
Die Bereitschaftssteuer ist real. Verbraucherlatenz, Partitionsschieflage, Broker-Failover — das sind keine seltenen Randfälle, das ist Dienstag. Wenn Ihr Team bereits dünn besetzt ist, löst Streaming das Problem nicht. Es vervielfacht es.
Ein Framework, das tatsächlich hilft
Hier ist, was ich empfehlen würde. Es dauert etwa zwei Stunden mit den richtigen Leuten im Raum.
Schritt 1: Benennen Sie die Entscheidungen. Identifizieren Sie für jede Pipeline die spezifische Geschäftsentscheidung, die sie unterstützt. Nicht "Analytics" — die tatsächliche Entscheidung. "Diese Transaktion genehmigen oder ablehnen." "Dieses SKU nachbestellen." "Die Wartungscrew alarmieren." Wenn Sie es nicht benennen können, ist Batch in Ordnung.
Schritt 2: Zeitliche Entscheidungen. Wie oft wird diese Entscheidung getroffen? Jede Sekunde? Jede Stunde? Jeden Montag? Passen Sie den Pipeline-Rhythmus an den Entscheidungsrhythmus an. Subsekundenschnelle Lieferung für eine tägliche Entscheidung ist Verschwendung.
Schritt 3: Preis der Verzögerung. Was kostet eine einstündige Verzögerung in Dollar? Dies ist die schwierigste und wichtigste Frage. Wenn die Antwort lautet "wir wissen es nicht" oder "wahrscheinlich nichts", haben Sie keinen Streaming-Anwendungsfall. Sie haben einen Streaming-Wunsch.
Schritt 4: Beginnen Sie mit einer. Wählen Sie die Pipeline mit den klarsten Verzögerungskosten. Migrieren Sie sie. Führen Sie sie parallel zur Batch-Version für einen vollständigen Zyklus aus. Vergleichen Sie. Beheben Sie, was kaputt geht. Dann entscheiden Sie, ob Sie erweitern möchten.
Teams, die dies gut machen, enden normalerweise mit 2–3 Streaming-Pipelines und 15 Batch-Pipelines. Teams, die diesen Prozess überspringen, enden mit 18 Streaming-Pipelines, einem ausgebrannten Betriebsteam und einer leisen Migration zurück zu Batch sechs Monate später.
Es ist nicht entweder/oder
Hier ist das, was die meisten Streaming-Anbieter Ihnen nicht sagen werden: Die besten Datenarchitekturen sind langweilig. Sie sind nicht all-streaming oder all-batch. Sie sind ein Mix, der Pipeline für Pipeline gewählt wird, basierend darauf, was die Daten tatsächlich tun müssen.
Batch für Berichterstattung. Batch für ML-Training. Batch für alles, wo "täglich" schnell genug ist und Einfachheit Ihnen $8.000 pro Monat an Betriebskosten spart.
Streaming für Betrug. Streaming für Betriebsalarme. Streaming für die wenigen Pipelines, bei denen Verzögerung ein Dollarzeichen hat.
Genau aus diesem Grund haben wir layline.io so gebaut, wie wir es getan haben. Es behandelt sowohl Batch als auch Streaming auf derselben Plattform — gleiche Workflows, gleiche Tools, gleiches Team. Sie müssen nicht eine Welt wählen und die andere aufgeben. Sie beginnen mit dem, was Sie haben, fügen Echtzeit hinzu, wo es sich lohnt, und behalten Batch, wo es sinnvoll ist. Kein Rip-and-Replace. Kein entweder/oder.
Das Architekturdiagramm wird keine Konferenzvorträge gewinnen. Aber das Team geht um 17 Uhr nach Hause und die Bereitschaftsrotation schläft tatsächlich die Nacht durch.
Das ist die Art von Langeweile, die skaliert.
Wenn Sie evaluieren, welche Pipelines in Echtzeit gehören und welche als Batch völlig in Ordnung sind, ermöglicht Ihnen layline.io, beides auf einer einzigen Plattform auszuführen — so können Sie den Geschäftsnutzen validieren, bevor Sie Infrastruktur festlegen. Sprechen Sie mit uns über Ihre spezifische Architektur.
Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, der Unternehmensdatenverarbeitungsinfrastruktur entwickelt, die sowohl Batch- als auch Echtzeit-Workloads im großen Maßstab bewältigt.