Batch vs. Streaming: das richtige Paradigma wählen

Das 12-Millionen-Dollar-Refresh, das niemand angesehen hat

2019 baute ein großererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → nordamerikanischer Retailer seine Inventory-Analytics auf einem vollständigen Streaming-Stack neu auf, Kafka, Flink, das ganze Programm, damit Store Manager Lagerbestände „in Echtzeit" sehen konnten. Achtzehn Monate und rund 12 Millionen Dollar später brachte ein internes Audit die unschöne Wahrheit zutage: Der durchschnittliche Store Manager schaute einmal pro Schicht auf die Inventory-Dashboards, und Nachbestellentscheidungen waren an einen nächtlichen Replenishment-Zyklus gekoppelt, der ohnehin um 2 Uhr morgens lief. Das Unternehmen hatte Latenz im Sub-Sekunden-Bereich für eine Entscheidung gekauft, die sich einmal täglich bewegte. Die Streaming-PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → war ein Ferrari, der im Leerlauf auf einem Parkplatz stand.

Das ist die Falle. Streaming ist zum Statussymbol geworden, zum Beweis, dass eine Datenorganisation „modern" ist. Aber Latenz ist ein Kostenfaktor, keine Tugend. Ihre Aufgabe als CDO besteht nicht darin, Latenz zu minimieren; sie besteht darin, Latenz an die Entscheidung anzupassen, die sie konsumiert. Bauen Sie zu groß, verbrennen Sie Budget und Headcount für operative Komplexität, die niemand verlangt hat. Bauen Sie zu klein, ersticken Sie einen Use Case, Fraud, Dynamic PricingDynamic PricingPreise automatisch und in Echtzeit anpassen, basierend auf Nachfrage, Wettbewerb oder Nutzerverhalten, um Umsatz, Marge oder Conversion zu optimieren.Vollständige Definition ansehen →, Fleet Routing, der ohne Freshness tatsächlich stirbt.

Diese Lektion gibt Ihnen das Entscheidungsframework und die operative Disziplin, um diese Zuordnung richtig zu treffen.

Das Decision-Latency-Framework

Hören Sie auf zu fragen „sollte das real-time sein?". Das ist die falsche Frage, weil sie von Engineering-Begeisterung beantwortet wird. Fragen Sie stattdessen: Wie hoch ist die Decision Latency des konsumierenden Prozesses?

Decision Latency ist die Zeit zwischen dem Eintreten eines Events und dem Moment, in dem ein Mensch oder ein System tatsächlich so *handeln* kann, dass sich ein Ergebnis ändert. Sie hat drei Komponenten, die Sie getrennt hinterfragen müssen:

• Data Freshness, wie schnell die Daten ankommen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen.
• Decision Cadence, wie oft der konsumierende Prozess tatsächlich eine Wahl trifft.
• Action Latency, wie lange die Ausführung nach der Entscheidung dauert.

Die bindende Beschränkung ist die *langsamste* der drei. Der Retailer oben hatte Freshness unter einer Minute, eine Decision Cadence von einmal pro Tag und eine Action Latency (physisches Replenishment) im Bereich von Stunden. Freshness war nie der Bottleneck. Geld auszugeben, um sie zu verbessern, war ökonomischer Analphabetismus.

Daraus folgt diese Regel: Freshness ist nur bis zu dem Punkt kaufwürdig, an dem sie aufhört, die bindende Beschränkung zu sein. Darüber hinaus erzeugt jeder Dollar Latenzreduktion null Verbesserung der Entscheidung.

Die Value-Decay-Kurve

Tragen Sie für jeden Use Case auf, wie der Wert eines Datenpunkts mit dem Alter verfällt. Die Form sagt Ihnen das Paradigma.

• Cliff Decay, der Wert fällt innerhalb von Sekunden bis Minuten auf nahezu null. Fraud-Autorisierung, Ad Bidding, algorithmischer Handel, Fleet Dispatch, anomaliegetriggerte Sicherheitsabschaltungen. Hier ist Streaming kein Luxus; verspätete Daten sind *wertlose* Daten. Ein Fraud Score, der 400 ms nach Freigabe der Transaktion geliefert wird, ist ein Report, keine Kontrolle.
• Linear Decay, der Wert erodiert gleichmäßig über Stunden. Operatives Monitoring, Supply Chain am selben Tag, Kontext im Customer Service. Micro-Batch (Intervalle von 1 bis 15 Minuten) gewinnt hier meist: der größte Teil des Werts, ein Bruchteil der Komplexität.
• Flat-then-drop, der Wert ist einen Tag oder länger stabil und zählt dann an einer festen Grenze. Financial Close, regulatorisches Reporting, wöchentliche Cohort-Analyse, Model Retraining. Nightly Batch ist hier kein Kompromiss; es ist das *korrekte* Engineering.

Der Fehler, den CDOs machen, ist, die Value-Decay-Kurve als Eigenschaft der *Daten* zu behandeln („Transaktionen sind wichtig, also müssen sie real-time sein"). Sie ist eine Eigenschaft der *Entscheidung, die die Daten konsumiert*. Derselbe Transaktionsdatensatz speist einen Fraud Check mit Cliff Decay *und* einen Quartalsumsatz-Report mit Flat Decay aus derselben Quelle. Der eine verlangt Streaming; der andere darf es nicht nutzen.

Die Gesamtkosten der Latenz

Der Ferrari ist nicht nur teuer in der Anschaffung. ErErDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → ist teuer im *Unterhalt*, und diese Unterhaltskosten sind der Punkt, an dem die meisten CDO-Business-Cases stillschweigend lügen.

Batch-Systeme haben einen nachsichtigen Failure Mode: Ein Job stirbt um 2 Uhr morgens, Sie werden gepagt, Sie starten ihn neu, und um 6 Uhr sieht die Welt aus wie vorher. Idempotente Reruns, klare Checkpoints, einfache Backfills. Streaming-Systeme kennen diese Gnade nicht. Sie fallen kontinuierlich und im Flug aus, was Kostenkategorien einführt, die auf dem ersten Architektur-Slide nie auftauchen:

• Exactly-once-Semantik. Zu garantieren, dass jedes Event genau einmal verarbeitet wird, nicht null Mal, nicht zweimal, und das bei Teilausfällen, ist wirklich schwer. Fehler bedeuten doppelt belastete Kunden oder doppelt gezählte Metriken.
• Out-of-order- und spät eintreffende Events. Echte Event-Streams kommen nicht in der richtigen Reihenfolge an. Sie brauchen Watermarking und Windowing-Logik, um zu entscheiden, wie lange Sie auf Nachzügler warten, bevor Sie ein Window schließen, ein Tradeoff zwischen Vollständigkeit und Latenz, für den es keine kostenlose Antwort gibt.
• Backpressure und Replay. Wird ein nachgelagerter Consumer langsam, muss die ganze PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → sauber degradieren, sonst verlieren Sie Daten. Die Erholung von einem Bug bedeutet Replay ab einem Offset, was voraussetzt, dass Sie den Raw Stream aufbewahrt haben.
• On-Call-Realität. Streaming ist eine operative 24/7-Verpflichtung. Ein Nightly Batch hat ein Maintenance-Window; ein Stream schläft nie. Budgetieren Sie die On-Call-Rotation und den Burnout, nicht nur den Cluster.

Eine nützliche Heuristik von Teams, die beides betrieben haben: Eine Streaming-Pipeline in Produktion kostet etwa 3-5x den gesamten operativen Aufwand einer äquivalenten Batch-Pipeline, sobald Sie On-Call, Testkomplexität und den Aufpreis für Spezialisten einrechnen. Dieser Multiplikator ist Ihre Hurdle Rate. Der Streaming-Use-Case muss mindestens den 3-5-fachen *Entscheidungswert* der Batch-Alternative erzeugen, um die Nulllinie zu erreichen, bevor Sie einen Dollar Upside verdient haben.

Das rahmt den Business Case neu. Die Frage ist nicht „kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen wir es uns leisten, Streaming zu bauen?". Sie lautet „übersteigt der marginale Entscheidungswert frischerer Daten ein 4-faches Kostenmultiple?". Für Fraud, Dynamic PricingDynamic PricingPreise automatisch und in Echtzeit anpassen, basierend auf Nachfrage, Wettbewerb oder Nutzerverhalten, um Umsatz, Marge oder Conversion zu optimieren.Vollständige Definition ansehen → im großen MaMaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßstab oder Real-Time-Personalisierung auf einer Property mit hohem Traffic: problemlos ja. Für ein internes Ops-Dashboard, auf das zweimal täglich geschaut wird: fast nie.

Die Micro-Batch-Mitte

Die meisten CDOs rahmen das als Binärentscheidung. Das ist es nicht. Micro-Batch, also Batch-Jobs in engen Intervallen (alle 1, 5 oder 15 Minuten), erfasst den größten Teil des Freshness-Vorteils von Streaming und behält dabei die operative Vernunft von Batch: Reruns bleiben einfach, die Semantik ist schlichter, und Sie behalten eine normale Maintenance-Haltung.

Das architektonische Signal ist unkompliziert:

# Micro-batch: still batch semantics, near-real-time cadence.
# You get idempotent reruns and simple checkpointing.
spark.readStream \
    .format("delta") \
    .load("/events/transactions") \
    .writeStream \
    .trigger(processingTime="5 minutes") \
    .foreachBatch(upsert_to_warehouse) \
    .start()

Ändern Sie processingTime auf "1 minute" und Sie sind enger dran; setzen Sie es auf availableNow=True und Sie sind zurück beim geplanten Batch, *mit demselben Code*. Genau das ist der Punkt: Micro-Batch erlaubt es Ihnen, am Freshness-Regler zu drehen, ohne sich auf das volle operative Gewicht von kontinuierlichem Streaming einzulassen. Ein großererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → Teil der Use Cases, die in Anforderungsdokumenten als „real-time" bezeichnet werden, ist mit einem 5-Minuten-Micro-Batch vollständig abgedeckt. Greifen Sie nur dann zu echtem Event-at-a-time-Streaming, wenn die Value-Decay-Kurve ein echter Cliff ist *und* Ihre Action Latency Freshness unter einer Minute tatsächlich ausnutzen kann.

Die Entscheidung am Montagmorgen treffen

Hier ist die Abfolge, die Sie durchgehen, wenn ein Stakeholder „real-time" verlangt.

1. Erzwingen Sie das Gespräch über Decision Latency. Fragen Sie: „Wenn diese Daten frischer sind, welche konkrete Entscheidung ändert sich, wer trifft sie, und wie oft?" Kann die Person die Entscheidung nicht benennen, ist die Anforderung aspirational, nicht real. In neun von zehn Fällen bedeutet „real-time" „ich habe die veralteten Dashboards satt", ein Datenqualitäts- oder Refresh-Frequenz-Problem, kein Paradigma-Problem.

2. Finden Sie die bindende Beschränkung. Kartieren Sie die drei Latenzkomponenten. Dominiert die Action Latency (eine menschliche Freigabe, ein physischer Prozess, ein nachgelagerter Nightly Job), ist Freshness weiter oben verschwendet. Der Replenishment-Lock des Retailers machte das im Rückblick offensichtlich; machen Sie es *vorab* offensichtlich.

3. Bepreisen Sie den Entscheidungswert. Schätzen Sie den inkrementellen Wert, N Minuten früher zu handeln. Fraud hat eine klare Zahl: verhinderter Verlust in Dollar pro Minute schnellerer Erkennung. Dynamic PricingDynamic PricingPreise automatisch und in Echtzeit anpassen, basierend auf Nachfrage, Wettbewerb oder Nutzerverhalten, um Umsatz, Marge oder Conversion zu optimieren.Vollständige Definition ansehen →: Umsatzuplift pro Pricing-Zyklus. Ist die Zahl schwammig oder klein, haben Sie Ihre Antwort.

4. Wenden Sie den Multiplikator an. Übersteigt der Entscheidungswert die Hürde von 3-5x Betriebskosten gegenüber der Micro-Batch-Alternative? Wenn nicht, liefern Sie Micro-Batch aus und machen Sie weiter.

5. Entscheiden Sie im Default für das einfachere Paradigma. Bei echter Unsicherheit wählen Sie die Option mit geringerer Komplexität. Ein Micro-Batch-Intervall kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen Sie später immer verkürzen oder eine PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → auf Streaming hochstufen. Einen über-engineerten Streaming-Stack zurückzubauen, von dem inzwischen drei Teams abhängen, ist ein politischer und technischer Albtraum.

Die Portfolio-Sicht

Sie wählen nicht *ein* Paradigma für die Organisation. Sie managen ein Portfolio, und die erfolgreiche Architektur betreibt meist beides gegen dieselben Quelldaten, das Muster, das Sie als Two-Track-Design kennen, bei dem ein schneller Serving Layer Cliff-Decay-Entscheidungen bedient und ein Batch Layer den autoritativen, abgestimmten Datensatz erzeugt.

Die CDO-Disziplin ist Placement: zu entscheiden, welcher Use Case auf welchem Track sitzt, und sich zu weigern, Engineering-Begeisterung oder Management-Mode Flat-Decay-Workloads auf teure Infrastruktur zu ziehen. Führen Sie ein einfaches Register, halten Sie für jedes größere Datenprodukt Decay-Form, bindende Beschränkung, gewähltes Paradigma und den rechtfertigenden Entscheidungswert fest. Nehmen Sie es zur Hand, wenn jemand ein Upgrade verlangt. Damit wird aus „sollte das Streaming sein?" statt eines wiederkehrenden emotionalen Streits eine governte, evidenzbasierte Entscheidung.

Eine weitere Falle, die benannt werden muss: Freshness Theater. Führungskräfte lieben ein Dashboard-Tile, das jede Sekunde tickt. Es *fühlt* sich modern an. Es treibt Streaming-Investitionen, die von jeder Entscheidung losgelöst sind. Wenn Sie eine Real-Time-Visualisierung sehen, deren zugrunde liegende Entscheidung sich täglich bewegt, sehen Sie Kosten, die als Capability verkleidet sind. Killen Sie sie, oder stufen Sie sie auf Micro-Batch herunter, und verlagern Sie die Einsparung auf einen Use Case, der am Cliff lebt.

Wenn Batch die mutigere Wahl ist

Es gibt eine kulturelle Dimension, die Senior Leaders unterschätzen. In vielen Datenorganisationen wird die Wahl von Batch als die Wahl des *Hinterherlaufens* gelesen. Ambitionierte Engineers wollen Streaming im Lebenslauf; Vendors verkaufen es als Table Stakes; der Board hat einen McKinsey-Artikel über Real-Time-Unternehmen gelesen. Der Druck läuft in eine Richtung.

Eine Batch-Entscheidung zu verteidigen oder eine Streaming-Ambition auf Micro-Batch herunterzustufen, verlangt mehr organisatorischen Mut als das Abnicken des glänzenden Dings. Aber es ist häufig die urteilsstärkere Entscheidung. Die 12-Millionen-Dollar-Lektion des Retailers war kein Technologieversagen; jede Komponente funktionierte wie entworfen. Es war ein Placement-Versagen und ein Mut-Versagen: Niemand mit genug Senioritätsgewicht fragte, ob die Entscheidung, die die PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → speiste, sich tatsächlich schnell genug bewegte, um sie zu rechtfertigen.

Ihre Glaubwürdigkeit als CDO baut sich zum Teil darauf auf, zu anspruchsvollen Dingen aus unanspruchsvollen Gründen nein zu sagen. Wenn Sie ablehnen, einen Workload zu streamen, dokumentieren Sie die Decision-Latency-Logik und den Kostenmultiplikator. Diese Aktenlage verwandelt eine „konservative" Wahl in eine verteidigbare, quantifizierte, und schützt Sie, wenn der Modezyklus dreht und jemand fragt, warum das Unternehmen nicht „überall real-time" ist.

Der umgekehrte Mut zählt ebenso. Wenn ein Use Case wirklich am Cliff lebt, Fraud, Safety, Real-Time Bidding, und jemand Geld sparen will, indem ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → ihn in einen Nightly Batch zwingt, müssen Sie in die andere Richtung genauso hart kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →ämpfen. Einen Cliff-Decay-Use-Case von Freshness abzuschneiden, ist keine Sparsamkeit; es heißt, ein Kontrollsystem auszuliefern, das nach dem Event ankommt, das es verhindern sollte. Das ist schlimmer, als es nicht zu bauen, weil es falsche Sicherheit erzeugt.

Key Takeaways

• Passen Sie Latenz an Decision Latency an, nicht an Ambitionen. Kaufen Sie Freshness nur so lange, bis sie aufhört, die bindende Beschränkung unter Data Freshness, Decision Cadence und Action Latency zu sein. Jenseits dieses Punkts bringt jeder Latenz-Dollar null Rendite.

• Klassifizieren Sie nach Value-Decay-Form, pro Entscheidung, nicht pro Datensatz. Cliff Decay → Streaming. Linear Decay → Micro-Batch. Flat-then-drop → Batch. Dieselbe Quelle speist unterschiedliche Entscheidungen auf unterschiedlichen Tracks; behandeln Sie Placement als Ihre Kerndisziplin als CDO.

• Nutzen Sie den 3-5x-Kostenmultiplikator als Hurdle Rate. Die echten Kosten von Streaming, Exactly-once-Semantik, Out-of-order-Handling, Replay, 24/7-On-Call, liegen bei einem Mehrfachen des Batch-Äquivalents. Der Use Case muss dieses Multiple im inkrementellen Entscheidungswert überschreiten, bevor Sie zusagen.

• Wählen Sie bei Unsicherheit im Default Micro-Batch. Ein 5-Minuten-Intervall erfüllt die meisten „real-time"-Anforderungen mit operativer Vernunft auf Batch-Niveau, und derselbe Code lässt sich von geplantem Batch bis nahe Real-Time einstellen. Stufen Sie nur bei echten Cliffs auf echtes Streaming hoch.

• Killen Sie Freshness Theater, und haben Sie den Mut, Batch zu verteidigen. Ein Real-Time-Dashboard, das eine tägliche Entscheidung speist, sind Kosten, die als Capability verkleidet sind. Dokumentieren Sie die Decision-Latency-Logik hinter jeder Paradigma-Entscheidung, damit aus einer konservativen Wahl eine quantifizierte, verteidigbare wird.