Stream Processing Engines - Spark Streaming & Flink

In contemporary data-intensive computing, the assumption that data arrives in clean, bounded, static batches is fundamentally obsolete. Real-world business data—financial market transactions, mobile telemetry, IoT telemetry sensor streams, ride-share GPS coordinates, and cyber-threat telemetry—is inherently an unbounded, continuous event stream. Batch processing systems that run hourly or nightly cron jobs impose an artificial temporal barrier, converting real-time operational phenomena into stale historical reports.

To extract real-time insights and execute autonomous actions, distributed computing evolved specialized Stream Processing Engines (SPEs). Led by the foundational principles of the Google Dataflow model (Akidau et al., 2015), modern stream processing bridges the theoretical dichotomy between high-throughput Micro-Batching (exemplified by Spark Structured Streaming) and true, record-at-a-time Native Event-Driven Streaming (exemplified by Apache Flink). By formalizing the distinctions between Event Time and Processing Time, orchestrating Asynchronous Barrier Snapshotting (ABS), and enforcing Exactly-Once state semantics, these engines provide robust mathematical guarantees over erratic, out-of-order data streams.

1. Theoretical Foundations: The Modern Streaming Paradigm#

The Four Questions of Stream Processing#

In their seminal 2015 paper, "The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing", Tyler Akidau and the Google engineering team established that any robust streaming engine must answer four fundamental questions:

1. What is being computed? (Transformations: aggregations, joins, projections, machine learning inference).
2. Where in event time is it being computed? (Windowing: tumbling, sliding, or session windows).
3. When in processing time are results materialized? (Watermarks and triggers).
4. How do those results relate to previous materializations? (Accumulating, retracting, or discarding intermediate state).

+-----------------------------------------------------------------------------------+
|                        EVENT TIME VS. PROCESSING TIME SKEW                        |
+-----------------------------------------------------------------------------------+
|  REALITY (Event Time): Time when the physical fact occurred on client device      |
|  INFRASTRUCTURE (Processing Time): Time when the record reaches the stream engine |
|                                                                                   |
|  Event Time Axis:       [ 12:00:01 ] -------> [ 12:00:02 ] -------> [ 12:00:03 ]  |
|                               \                     /                     |       |
|  Network Latency Jitter:       \ (Stalled in 3G)   / (Fast Fiber Link)   |       |
|                                 \                 /                       |       |
|  Processing Time Arrival:        \               /                        |       |
|  Engine Clock Axis:     [ 12:00:05 ] <----------+                         |       |
|                         (Event 12:00:02 Arrives First!)                   |       |
|                                                  [ 12:00:08 ] <-----------+       |
|                                                  (Event 12:00:03 Arrives)         |
|                                                                    [ 12:00:15 ] <-+
|                                                                    (Event 12:00:01 Arrives Late!)
+-----------------------------------------------------------------------------------+

The Three Notions of Time#

• Event Time: The timestamp embedded directly within the record at the physical moment of creation (e.g., the timestamp generated by a smartphone GPS sensor or POS register). Event time is immutable and reflects ground truth.
• Ingestion Time: The timestamp assigned to the record when it is durably appended to the message broker's log (e.g., Kafka broker offset timestamp).
• Processing Time: The local system clock of the specific worker machine executing the stream transformation. Processing time is non-deterministic: the identical stream replayed on two different clusters will observe completely different processing times due to CPU load, garbage collection pauses, and network congestion.

Watermarks: Bounding Out-of-Order Event Time#

In an ideal network, records would arrive strictly in event-time order. In reality, mobile devices enter subway tunnels, wireless connections drop packets, and distributed queues induce arbitrary reordering. A stream engine cannot simply close a 12:00:00 to 12:05:00 window when its local clock hits 12:05:00, because events generated at 12:04:30 may still be in transit.

A Watermark is a monotonically increasing temporal metric flowing through the data stream that asserts:

Watermark(t) ⟹ No further events with Event Time t' < t will arrive.

Bounded-Out-of-Orderness Watermarks:

In practice, engines cannot wait forever. They configure a heuristic lag threshold Δ t:

W(t) = max_{i}(EventTime_i) - Δ t

If the engine observes an event with timestamp 12:10:00, and Δ t = 2 minutes, it emits a watermark of W = 12:08:00. Any window ending before 12:08:00 is immediately closed and its aggregate result emitted.

Late Data Handling:

If an event arrives with an Event Time older than the current Watermark (t_{event} < W), it is classified as Late Data. Engines provide explicit policies:

1. Drop: The record is discarded with an incremented telemetry metric.
2. Side Output: The record is routed to a Dead Letter Queue (DLQ) for forensic analysis.
3. Window Update / Retraction: If allowed lateness is configured (allowedLateness(5.minutes)), the window is reopened, the aggregate recomputed, and a retraction/update record is emitted downstream.

2. Windowing Mechanics in Distributed Streams#

Windowing divides an unbounded stream into discrete, finite slices for aggregation:

TUMBLING WINDOWS (Fixed, Disjoint, Non-Overlapping):
|--- [ 12:00 - 12:05 ] ---|--- [ 12:05 - 12:10 ] ---|--- [ 12:10 - 12:15 ] ---|
Records fall into exactly one window.

SLIDING (HOPPING) WINDOWS (Fixed Duration, Regular Hop Interval, Overlapping):
|--------- [ 12:00 - 12:10 ] ---------|
      |--------- [ 12:05 - 12:15 ] ---------|
            |--------- [ 12:10 - 12:20 ] ---------|
Records fall into multiple overlapping windows.

SESSION WINDOWS (Data-Driven, Dynamic Gap Threshold):
[User Events: e1, e2, e3] --(Gap > 30 min)--> [User Events: e4, e5]
|--- Session Window 1 ---|                     |--- Session Window 2 ---|

1. Tumbling Windows: Fixed duration with zero overlap (e.g., 5-minute tumbling windows). Every record belongs to exactly one window.
2. Sliding Windows: Fixed duration with a periodic slide/hop interval (e.g., 10-minute window sliding every 2 minutes). A single record belongs to multiple concurrent windows (D / S windows, where D is duration and S is slide interval).
3. Session Windows: Dynamic, data-driven windows defined by periods of user activity separated by a minimum inactivity threshold (gap timeout, e.g., 30 minutes of inactivity). Session windows start on an event and merge dynamically when late-arriving events bridge the temporal gap between two previously separate sessions.

3. Engine Architectures: Micro-Batching vs. Native Event-Driven#

Spark Structured Streaming: Micro-Batch Execution#

Spark Structured Streaming treats stream processing as an infinite append-only table:

Stream Processing = Continuous Micro-Batch Incremental Query

+-----------------------------------------------------------------------------------+
|                    SPARK STRUCTURED STREAMING (MICRO-BATCH)                       |
+-----------------------------------------------------------------------------------+
|  Incoming Unbounded Stream (Kafka Partition Log)                                  |
|  [ e1 ][ e2 ][ e3 ] | [ e4 ][ e5 ][ e6 ] | [ e7 ][ e8 ][ e9 ]                     |
|  <-- Batch N-1 ---> | <-- Batch N -----> | <-- Batch N+1 --->                     |
|                                                                                   |
|  1. Ingestion Buffer collects records for Trigger Interval (e.g., 200 ms)         |
|  2. Driver constructs miniature Spark DataFrame from buffered slice               |
|  3. Catalyst Optimizer optimizes relational plan; Tungsten generates bytecode     |
|  4. Tasks dispatched to worker executors; processed in parallel across threads    |
|  5. State stored in HDFS-backed Delta State Store; Offsets committed              |
|  Latency Floor: ~100 ms to 500 ms (High Throughput, High Vectorization)          |
+-----------------------------------------------------------------------------------+

• Advantages: Reuses the battle-tested Spark SQL Catalyst optimizer, Tungsten whole-stage code generation, and columnar execution. Achieves massive throughput on high-volume feeds.
• Disadvantages: Structural latency floor. Because records must be accumulated into batches before scheduling, end-to-end processing latency cannot drop below approximately 50 ms to 100 ms.

Apache Flink: Native Event-Driven Pipeline#

Apache Flink was engineered from first principles as a true, record-at-a-time streaming engine:

Batch Processing = Special Case of Streaming (Finite Bounded Streams)

+-----------------------------------------------------------------------------------+
|                        APACHE FLINK (NATIVE STREAMING)                            |
+-----------------------------------------------------------------------------------+
|  Continuous Operator Pipeline (Threads run continuously across TaskManagers)      |
|                                                                                   |
|  [Kafka Source] =====> [Filter Operator] =====> [Keyed State Agg] =====> [Sink]   |
|         |                     |                         |                  |      |
|       (e1)                  (e1)                      (e1)               (e1)     |
|                                                                                   |
|  1. Record e1 is fetched from Kafka socket buffer immediately.                    |
|  2. Pushed through in-memory operator pipeline without batching.                  |
|  3. Updates RocksDB embedded state directly in memory.                            |
|  4. Emitted to downstream network buffer immediately.                             |
|  Latency Floor: Sub-millisecond (~1 ms to 10 ms, True Continuous Processing)      |
+-----------------------------------------------------------------------------------+

• Advantages: Ultra-low latency (sub-millisecond). Native support for complex event processing (CEP), session windows, and fine-grained state manipulation.
• Disadvantages: Requires dedicated state management tuning (RocksDB off-heap memory, garbage collection optimization) and careful cluster capacity planning.

4. Fault Tolerance: Chandy-Lamport & Asynchronous Barrier Snapshotting (ABS)#

In traditional batch systems, failure recovery relies on restarting tasks and replaying data from disk. In a 24/7 continuous streaming pipeline processing millions of events per second, stopping the entire system to take a synchronous snapshot would cause unacceptable latency spikes.

Apache Flink achieves fault tolerance using Asynchronous Barrier Snapshotting (ABS), a variant of the classic Chandy-Lamport distributed snapshotting algorithm:

Stream Flow Direction: ------------->
[Operator A] ===== (Data Record) ===== [Barrier n] ===== (Data Record) =====> [Operator B]

1. JobManager injects Checkpoint Barrier n into source streams.
2. Barriers flow interleaved with normal data records; they NEVER overtake data!
3. When an operator receives Barrier n from all input channels:
   - Operator pauses processing on that channel (Alignment Phase).
   - Once aligned, operator takes a non-blocking local snapshot of its State (RocksDB).
   - Emits Barrier n to downstream output channels.
   - Resumes data processing immediately while snapshot writes asynchronously to S3!

The Alignment Phase#

When an operator has multiple input channels (e.g., joining two streams):

1. Barrier n arrives on Channel 1, but has not yet arrived on Channel 2 (due to network delay).
2. The operator pauses consumption of Channel 1 (or buffers incoming Channel 1 records in memory).
3. The operator continues processing Channel 2 until Barrier n arrives on Channel 2.
4. Once Barrier n has arrived across all input channels, the operator state is mathematically guaranteed to reflect all records before Barrier n and zero records after Barrier n.
5. The operator snapshots its local state to durable storage (S3/HDFS) asynchronously in the background.

End-to-End Exactly-Once via Two-Phase Commit Sink#

Snapshots guarantee that internal engine state is restored exactly after a crash. However, if the sink writes data to an external database (e.g., PostgreSQL or Kafka), duplicate external writes will occur unless the sink coordinates with the snapshot.

Flink provides the Two-Phase Commit Protocol (`TwoPhaseCommitSinkFunction`):

1. Phase 1 (Pre-Commit): When Barrier n arrives at the sink, the sink opens an external transaction on the target database, writes records within that transaction, and prepares for commit.
2. Phase 2 (Commit): When the JobManager receives confirmation that all operators across the entire cluster have successfully completed snapshot n, it issues a cluster-wide "Commit Success" broadcast. The sink formally commits the external database transaction, guaranteeing end-to-end Exactly-Once semantics.

5. University-Grade Checkpoint Practice Problems#

Problem 1: Chandy-Lamport Barrier Alignment Latency & In-Flight Buffer Sizing#

Context: An Apache Flink stream processing application joins two high-volume financial transaction streams:

• Stream 1: Card Authorization Stream (R_1 = 40,000 events/second).
• Stream 2: Fraud Telemetry Stream (R_2 = 20,000 events/second).

Both streams flow into a stateful join operator running on a worker TaskManager:

• Average serialized event size: S = 500 bytes.
• At checkpoint cycle n, the JobManager injects Checkpoint Barrier n simultaneously into the sources of both streams at time t = 0.

Network Path Asymmetry:

• Due to routing through an external security inspection gateway, Stream 2 experiences higher network propagation delay:

* Stream 1 Barrier Arrival Time at Join Operator: t_1 = 15 ms.

* Stream 2 Barrier Arrival Time at Join Operator: t_2 = 85 ms.

The Join Operator implements standard aligned checkpointing (Chandy-Lamport):

• Upon receiving Barrier n from Channel 1 at t_1, the operator suspends Channel 1 and buffers all subsequent incoming Channel 1 records in memory until Barrier n arrives from Channel 2 at t_2.

Task:

1. Calculate the exact duration of the Barrier Alignment Phase (Δ t_{align}).
2. Calculate the total number of Channel 1 records that must be buffered in heap memory during the alignment phase.
3. Calculate the physical RAM memory footprint (in Megabytes) consumed by the alignment buffer.
4. Explain how Unaligned Checkpoints (introduced in modern Flink) eliminate alignment buffer memory pressure and calculate the trade-off in snapshot state size.

Solution:

1. Barrier Alignment Duration:

Δ t_{align} = t_2 - t_1 = 85 ms - 15 ms = 70 ms = 0.070 seconds

1. Records Buffered During Alignment:

* Channel 1 continues streaming data into the operator's input buffer at rate R_1 = 40,000 events/second.

* Total events buffered over 70 ms:

N_{buffered} = R_1 × Δ t_{align} = 40,000 events/s × 0.070 s = 2,800 events

1. Alignment Buffer RAM Footprint:

* Each event occupies S = 500 bytes.

* Total raw byte payload:

B_{raw} = 2,800 × 500 bytes = 1,400,000 bytes

* Accounting for JVM object reference wrapper overhead (approximately 32 bytes per queued object in Java):

B_{total} = 2,800 × (500 + 32) = 1,489,600 bytes ≈ 1.42 MB

1. Unaligned Checkpoints Evaluation:

Mechanism: In unaligned checkpoints, the operator does not wait for Barrier n to arrive on Channel 2. The moment Barrier n arrives on Channel 1, it immediately takes a local snapshot of its current state plus all in-flight channel buffers*, and instantly forwards Barrier n downstream.

Memory Impact*: Alignment latency is eliminated (Δ t_{align} = 0 ms), preventing backpressure from propagating upstream.

Trade-off*: In-flight channel data must be persisted into the checkpoint file itself, increasing total checkpoint snapshot size on S3/HDFS.

Problem 2: Gaussian Event-Time Skew & Watermark Lateness Optimization#

Context: An IoT fleet of M = 50,000 connected industrial power turbines transmits pressure sensor metrics to a central Kafka topic.

Network & Clock Jitter Modeling:

• Let T_{event} represent the true physical event timestamp recorded on the turbine.
• Let T_{arrival} represent the timestamp when the record is ingested by the stream processing engine.
• The arrival latency lag τ = T_{arrival} - T_{event} follows a normal (Gaussian) distribution:

τ ~ N(μ, σ^2)

with mean network transit time μ = 8.0 seconds and standard deviation σ = 2.5 seconds.

The stream processing engine evaluates a 1-minute tumbling window on event time:

W_k = [k × 60, (k + 1) × 60)

The engine implements a Bounded-Out-of-Orderness Watermark generator with delay parameter D:

Watermark(t) = max(EventTime) - D

When the Watermark exceeds the end of a window, the window triggers and closes. Any event arriving with T_{event} < Watermark is dropped as late data.

Operational SLA Requirement:

The business dictates that at least 99.9\% (0.999) of all sensor events must be successfully included in window computations. Less than 0.1\% (0.001) may be dropped as late data.

Task:

1. Formulate the mathematical condition for an event to arrive before the watermark passes its timestamp.
2. Determine the critical standard normal value (z-score) corresponding to the 99.9\% inclusion threshold.
3. Calculate the minimum required watermark delay parameter D_{min} (in seconds) that satisfies the 99.9% completeness constraint.
4. Discuss the architectural trade-off between watermark delay D and end-to-end business alerting latency.

Solution:

1. Mathematical Condition for Event Acceptance:

* An event is accepted if its transit lag τ does not exceed the watermark delay buffer D:

P(τ ≤ D) ≥ 0.999

1. Standard Normal Inverse Cumulative Distribution Function:

* Standardizing the Gaussian variable:

Z = (D - μ / σ)

P(Z ≤ z) = Φ(z) = 0.999

* Looking up the standard normal quantile:

z = Φ^{-1}(0.999) ≈ 3.0902

1. Minimum Watermark Delay Calculation:

z = (D - μ / σ) ⟹ D = μ + z × σ

* Substituting known parameters (μ = 8.0 s, σ = 2.5 s):

D_{min} = 8.0 + (3.0902 × 2.5) = 8.0 + 7.7255 = 15.7255 seconds ≈ 15.73 seconds

* The stream engine must configure its watermark generator with a delay of at least D = 15.73 seconds (rounded in production to 16 seconds).

1. Architectural Latency Trade-Off:

* A watermark delay of 16 seconds guarantees that 99.9\% of data is captured.

* However, window results cannot be emitted until the watermark advances past the window end boundary. For a window ending at 12:05:00, the result will not be calculated until local time reaches approximately 12:05:16.

Trade-off*: Increasing D increases data completeness at the expense of adding artificial latency to real-time dashboards and automated safety shutdowns.

Problem 3: Tumbling vs. Sliding Window State Memory Sizing in RocksDB#

Context: An algorithmic high-frequency trading platform aggregates currency exchange quotes across an unbounded event stream.

Stream Workload Metrics:

• Incoming quote velocity: R = 20,000 quotes/second.
• Each quote belongs to one of K = 500 distinct currency pairs (e.g., EUR/USD, GBP/JPY).
• Quotes are uniformly distributed across all 500 currency keys (40 quotes/sec per key).
• Each incoming record has a size of S = 250 bytes.
• The application maintains a sliding aggregate tracking the moving average price and trading volume over a temporal window of duration D = 1 hour = 60 minutes = 3,600 seconds.

We evaluate two stateful window aggregation architectures in Apache Flink using the RocksDB State Backend:

• Architecture 1 (Non-Incremental Raw Buffer Window):

* The window retains all raw incoming events in state memory until the window closes.

* Window configuration: Sliding window of duration D = 60 minutes, with a slide interval of S_{slide} = 1 minute.

• Architecture 2 (Incremental Aggregate Function with `AggregateFunction`):

* The window does not store raw records. Instead, as each event arrives, it updates an in-place accumulator tuple:

Accumulator = ⟨ count: int64, sum\_price: float64, volume: float64 ⟩

* Accumulator size in memory: A_{size} = 32 bytes per key per active window slice.

Task:

1. Calculate the total number of concurrent active windows N_{windows} maintained by the engine at any instant in time for Architecture 1 and Architecture 2.
2. Calculate the total physical state memory consumed in RocksDB under Architecture 1 (storing raw records across all overlapping windows).
3. Calculate the total physical state memory consumed under Architecture 2 (using incremental pre-aggregation).
4. Compute the memory compression ratio achieved by Architecture 2 and explain why raw buffering in sliding windows causes severe OutOfMemory failures.

Solution:

1. Concurrent Active Windows N_{windows}:

* Window duration D = 60 minutes.

* Slide interval S_{slide} = 1 minute.

* Number of concurrent overlapping windows:

N_{windows} = (D / S_slide) = (60 min / 1 min) = 60 active windows

1. State Memory Consumption under Architecture 1 (Raw Record Buffering):

* In a sliding window with 60 overlapping instances, each individual event falls into 60 distinct concurrent windows.

* Total events arriving per hour:

N_{events/hour} = 20,000 quotes/s × 3,600 s = 72,000,000 events

* Raw data volume generated per hour:

V_{hour} = 72,000,000 × 250 bytes = 18,000,000,000 bytes = 18.0 GB

* Because each record is duplicated across all 60 overlapping active windows:

M_{state, Arch 1} = 60 × 18.0 GB = 1,080 GB = 1.08 TB

RocksDB must maintain over 1 TB of state data on local SSDs*, generating massive compaction I/O and cache thrashing.

1. State Memory Consumption under Architecture 2 (Incremental Pre-Aggregation):

* Under incremental aggregation, the engine maintains only the accumulator per key per window slice.

* Number of unique keys K = 500.

* Each active window maintains 1 accumulator per key:

N_{accumulators} = N_{windows} × K = 60 × 500 = 30,000 accumulators

* Memory per accumulator A_{size} = 32 bytes.

* Total state memory:

M_{state, Arch 2} = 30,000 × 32 bytes = 960,000 bytes ≈ 0.96 MB

1. Memory Compression Comparison:

* Compression Ratio:

Ratio = (M_state_Arch1 / M_state_Arch2) = (1,080,000,000,000 bytes / 960,000 bytes) = 1,125,000×

Architectural Conclusion: Architecture 2 slashes state memory from 1.08 TB down to less than 1 MB*, an efficiency improvement exceeding 1,000,000×. Using incremental AggregateFunction or ReduceFunction is mandatory for high-velocity sliding windows.

Problem 4: Micro-Batch vs. Continuous Streaming End-to-End Latency Breakdown#

Context: A cybersecurity threat-hunting platform evaluates two distributed stream processing architectures to detect brute-force SSH attacks in real time:

• Engine A: Apache Spark Structured Streaming (Micro-Batch Architecture).
• Engine B: Apache Flink (Native Continuous Event-Driven Architecture).

Latency Pipeline Breakdown:

1. Ingestion Buffer Latency (T_{buf}):

* Spark Structured Streaming buffers incoming events into micro-batches with trigger interval T_{trigger} = 200 ms. Average buffering latency:

T_{buf, Spark} = (T_trigger / 2) = (200 ms / 2) = 100 ms

* Flink processes records immediately upon socket read:

T_{buf, Flink} ≈ 0.5 ms

1. Network Serialization & Inter-Process Transit (T_{net}):

* Spark Tungsten row serialization + RPC task scheduling: T_{net, Spark} = 15 ms.

* Flink netty network buffer forwarding: T_{net, Flink} = 2.0 ms.

1. Operator Computation Latency (T_{comp}):

* Spark whole-stage code generation vector processing: T_{comp, Spark} = 8 ms.

* Flink per-record state lookup in RocksDB cache: T_{comp, Flink} = 1.5 ms.

1. State Checkpoint & Transactional Sink Commit (T_{sink}):

* Spark commits micro-batch offset to HDFS/S3 write-ahead log before releasing downstream outputs:

T_{sink, Spark} = 35 ms

* Flink emits uncommitted alert downstream immediately to a Kafka alerting topic; Exactly-Once snapshotting executes asynchronously in the background without blocking the record pipeline:

T_{sink, Flink} = 1.0 ms

Task:

1. Calculate the total end-to-end processing latency L_{Spark} under Spark Structured Streaming.
2. Calculate the total end-to-end processing latency L_{Flink} under Apache Flink.
3. Compute the speedup factor of Flink over Spark for this real-time detection task.
4. Under what architectural conditions would an enterprise choose Spark Structured Streaming over Apache Flink despite the higher latency?

Solution:

1. Spark Structured Streaming Total Latency L_{Spark}:

L_{Spark} = T_{buf, Spark} + T_{net, Spark} + T_{comp, Spark} + T_{sink, Spark}

L_{Spark} = 100 ms + 15 ms + 8 ms + 35 ms = 158 ms

1. Apache Flink Total Latency L_{Flink}:

L_{Flink} = T_{buf, Flink} + T_{net, Flink} + T_{comp, Flink} + T_{sink, Flink}

L_{Flink} = 0.5 ms + 2.0 ms + 1.5 ms + 1.0 ms = 5.0 ms

1. Latency Comparison & Speedup:

Speedup = (L_Spark / L_Flink) = (158 ms / 5.0 ms) = 31.6×

Flink delivers alert notifications over 31× faster than Spark Structured Streaming, detecting automated intrusion attempts in 5 milliseconds compared to nearly a sixth of a second.

1. When to Prefer Spark Structured Streaming:

Unified Batch/Streaming Codebase*: When the organization maintains massive existing batch ETL jobs written in PySpark or Spark SQL, using Structured Streaming allows 95% of business logic to be shared between batch and real-time.

Massive Throughput Requirements*: If end-to-end latency of 1 to 2 seconds is acceptable (e.g., hourly financial reporting or log indexing), Spark's micro-batch vectorization achieves higher raw event throughput per dollar of compute than record-at-a-time streaming.

Operational Simplicity*: Managing a single Spark unified platform simplifies enterprise DevOps compared to maintaining separate operational stacks for Spark (batch) and Flink (streaming).