Skip to main content

Demystifying the Dataflow Model: True Stream Processing with Flink

Module Duration: 3-4 hours Focus: Research foundations + Flink’s streaming architecture Prerequisites: Basic distributed systems, Java or Scala Hands-on Labs: 8+ streaming examples

Introduction: The Streaming Revolution

The Problem That Needed Solving

In 2013, Google faced a critical challenge: existing batch processing frameworks (like MapReduce and Spark) couldn’t handle real-time streaming data properly. The industry had two bad options:
  1. Batch Processing (MapReduce, early Spark):
    • Wait hours for results
    • Can’t handle continuous data
    • Good for historical analysis, terrible for real-time
  2. Micro-Batching (Spark Streaming):
    • Chop stream into tiny batches
    • Latency measured in seconds (at best)
    • Pretends batches are streams
    • Event time processing is a hack
What was missing? A framework that treats streaming as the default, not an afterthought.
Critical Distinction:Micro-batching (Spark Streaming):
True Streaming (Flink):

Part 1: The Research Foundation - Google’s Dataflow Model

The Paper That Changed Everything

Full Citation: Tyler Akidau, Robert Bradshaw, Craig Chambers, Slava Chernyak, Rafael J. Fernández-Moctezuma, Reuven Lax, Sam McVeety, Daniel Mills, Frances Perry, Eric Schmidt, and Sam Whittle. 2015. “The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing”. VLDB ‘15.

The Authors: Google’s Stream Processing Team

  • Tyler Akidau (Lead Author): Principal Engineer at Google, later joined Confluent. Creator of Apache Beam. Author of the book “Streaming Systems”.
  • Craig Chambers: Senior Staff Engineer at Google, previously led Flumejava project.
  • Robert Bradshaw: Tech Lead for Google Cloud Dataflow, Apache Beam PMC Chair.
  • Team Background: This wasn’t academic research - it was the formalization of Google’s internal streaming infrastructure (MillWheel + FlumeJava).

Publication Venue and Impact

Conference: VLDB 2015 (Very Large Data Bases) - the top database conference Impact Metrics:
  • 5,000+ citations (as of 2024)
  • Industry Adoption: Led to Apache Beam, influenced Flink design
  • Google’s Implementation: Powers Google Cloud Dataflow
  • Academic Recognition: Foundational paper for stream processing research

Historical Context: 2013-2015

Before the Dataflow Model:
  • MapReduce dominated batch processing
  • Storm provided low-latency streaming (but no correctness guarantees)
  • Spark Streaming used micro-batching (high latency)
  • No framework handled out-of-order, unbounded data with event time semantics
The Problem Statement from the Paper:
“Existing systems force an uncomfortable choice: either sacrifice latency (batch systems), or sacrifice correctness (streaming systems that ignore event time).”

Part 2: Core Concepts from the Dataflow Model

The Four Questions Framework

The Dataflow Model paper introduced a simple but profound framework for reasoning about stream processing. Every streaming pipeline must answer:

1. WHAT are you computing?

This is the transformation logic - the “business logic” of your pipeline.

2. WHERE in event time are you computing it?

Windowing divides the infinite stream into finite chunks for aggregation.

3. WHEN in processing time do you materialize results?

Triggers control when windows emit results (early, on-time, late).

4. HOW do refinements relate to each other?

Accumulation mode determines whether results are cumulative or deltas.

Deep Dive: Event Time vs Processing Time

This is the most important concept in stream processing.

Event Time

Definition: When an event actually occurred (according to embedded timestamp).

Processing Time

Definition: When an event is processed by the streaming system.

Why Event Time is Critical

Scenario: Mobile app usage analytics
With Processing Time (WRONG):
With Event Time (CORRECT):
Rule of Thumb:Use Event Time when:
  • Events can arrive out-of-order
  • Delays are unpredictable (mobile, IoT, distributed systems)
  • Correctness matters more than simplicity
Use Processing Time when:
  • Events arrive in order
  • You control the entire pipeline
  • Latency is negligible
  • You’re aggregating server logs from a single machine

Part 3: Watermarks - The Core Innovation

What are Watermarks?

From the Dataflow Model paper:
“A watermark is a monotonically increasing timestamp indicating that no more events with timestamps less than the watermark will arrive.”
In Plain English: A watermark is the streaming system saying: “I’m confident that all events with timestamps before time T have arrived. I can now safely compute results for time T.”

Visual Example

What Happens:
  • At processing time 10:02, watermark reaches 10:02
  • This means: “All events with timestamps ≤ 10:02 have arrived”
  • Windows covering time ≤ 10:02 can now emit results
  • At processing time 10:03, event with timestamp 10:01 arrives (LATE!)
  • Watermark stays at 10:02 (watermarks are monotonic)

Watermark Strategies

Perfect Watermarks (Rare in Practice)

When to Use: Controlled environments, pre-sorted data, append-only logs. Downside: One late event = watermark stuck forever!

Bounded Out-of-Orderness (Production Standard)

How it Works:
When to Use: Most production scenarios (IoT, mobile, distributed logs).

Custom Watermark Generators

Late Events and Allowed Lateness

Behavior:
  1. Watermark passes end of window → Window closes and emits result
  2. Late events (within allowed lateness) → Window reopens, updates result
  3. Very late events (beyond allowed lateness) → Sent to side output

The Streaming Landscape (2015-2024)

Flink’s Unique Advantages

1. True Streaming (Not Micro-Batching)

2. Stateful Stream Processing

Storm doesn’t have built-in managed state. Spark has state but with higher latency.

3. Exactly-Once Semantics with Chandy-Lamport

From the research paper “Lightweight Asynchronous Snapshots for Distributed Dataflows” (Paris Carbone et al., 2015): Flink implements the Chandy-Lamport distributed snapshot algorithm for exactly-once processing. How it Works (Simplified):
Result: Even if a node crashes mid-processing, each event is processed exactly once.

Components

JobManager (Master)

Responsibilities:
  1. Job Scheduling: Converts logical plan to physical execution plan
  2. Checkpoint Coordination: Triggers and tracks checkpoints
  3. Resource Management: Allocates slots to tasks
  4. Failure Recovery: Restarts failed tasks from checkpoints
High Availability:
Multiple standby JobManagers, one active. On failure, standby takes over.

TaskManager (Worker)

Responsibilities:
  1. Execute Tasks: Run operator instances (map, filter, window, etc.)
  2. Buffer Data: Manage network buffers for data exchange
  3. Maintain State: Store keyed state (backed by RocksDB or heap)
  4. Checkpoint State: Snapshot state to durable storage
Configuration:

Data Exchange: Task Slots and Parallelism

Task Slot Allocation:
Flink pipelines operators into single tasks when possible (called “operator chaining”).

Part 6: Hands-On Examples

Example 1: Word Count with Event Time

Output:

Example 2: Sensor Data with Late Events

Example 3: Scala API (for Scala developers)


Part 7: The Academic Reception and Industry Impact

Initial Reception (2015-2016)

VLDB 2015 Reviews:
  • “Significant contribution to stream processing theory”
  • “Elegant unification of batch and streaming”
  • “Practical impact is enormous”
Academic Citations (by research area):
  • Stream Processing Systems: 2,800+ citations
  • Event Time Processing: 1,200+ citations
  • Distributed Snapshots: 600+ citations
  • Windowing Semantics: 400+ citations

Industry Adoption Timeline

2015: Google publishes Dataflow Model paper
  • Google Cloud Dataflow launched (proprietary)
  • Apache Flink adopts Dataflow Model concepts
2016: Apache Beam created
  • Unified programming model (Google-donated)
  • Flink becomes a Beam runner
2017-2018: Explosion of Flink adoption
  • Alibaba (largest Flink deployment: 10,000+ nodes)
  • Uber (real-time analytics platform)
  • Netflix (keystone real-time data platform)
2019-2020: Flink becomes industry standard
  • AWS Kinesis Data Analytics (managed Flink)
  • Ververica (Flink creators) acquired by Alibaba
  • Confluent integrates Flink with Kafka
2021-2024: Maturity and dominance
  • 25,000+ production deployments
  • De facto standard for stateful stream processing
  • Chosen for: fraud detection, real-time ML, CEP, analytics
vs Storm (2011-2015):
  • Storm: No exactly-once semantics (at-least-once only)
  • Storm: No managed state (developers roll their own)
  • Storm: No event time support
  • Flink: All of the above, built-in
vs Spark Streaming (2013-present):
  • Spark: Micro-batching (seconds latency)
  • Spark: Event time added later (second-class citizen)
  • Flink: True streaming from day one (millisecond latency)
vs Samza (LinkedIn, 2013-present):
  • Samza: Tightly coupled to Kafka
  • Samza: Limited adoption outside LinkedIn
  • Flink: Source-agnostic, wider ecosystem

Part 8: Common Misconceptions

Reality: Flink treats batch as a special case of streaming (bounded streams).
Flink’s DataSet API (batch) and DataStream API (streaming) share the same execution engine.

Misconception 2: “Watermarks solve all late data problems”

Reality: Watermarks are heuristic. They can be:
  • Too aggressive (drop valid late data)
  • Too conservative (delay results unnecessarily)
You must tune watermarks based on your data characteristics.

Misconception 3: “Exactly-once means no duplicates in external systems”

Reality: Exactly-once is within Flink’s state. External sinks (databases, files) may still see duplicates on retries. Solution: Use idempotent sinks or two-phase commit sinks (Flink’s KafkaSink, JDBCSink with XA).

Part 9: Interview Preparation

Conceptual Questions

Q1: Explain event time vs processing time. When would you use each? Answer:
  • Event Time: Timestamp embedded in the event (when it happened). Use when events can arrive out-of-order or with delays (mobile, IoT, distributed logs).
  • Processing Time: Timestamp when Flink processes the event. Use when events arrive in order and low latency matters more than correctness.
Q2: What is a watermark? Why is it necessary? Answer: A watermark is a monotonically increasing timestamp indicating “all events before time T have (probably) arrived.” Necessary because:
  • Infinite streams have no natural “end”
  • Need to know when to close windows and emit results
  • Allows handling late data gracefully
Q3: How does Flink achieve exactly-once semantics? Answer: Flink uses the Chandy-Lamport distributed snapshot algorithm:
  1. Periodically injects barriers into the stream
  2. Operators snapshot state when barrier arrives
  3. On failure, restores from last successful checkpoint
  4. Replays events from checkpoint point
Q4: Why is Flink better than Spark Streaming for low-latency use cases? Answer:
  • Flink: True per-record processing (millisecond latency)
  • Spark: Micro-batching (minimum 0.5-2 second latency)
  • Flink’s event time support is first-class, Spark’s is retrofitted

Coding Questions

Q: Implement a Flink job that counts events per 5-second window with 2-second allowed lateness.
Q: How would you handle a data stream where 10% of events arrive > 1 hour late? Answer:

Summary and Key Takeaways

What You’ve Learned

Dataflow Model Foundations: The four questions (What, Where, When, How) ✅ Event Time Processing: Why it matters, how it works ✅ Watermarks: The core innovation for handling infinite streams ✅ Flink Architecture: JobManager, TaskManager, task slots, parallelism ✅ Exactly-Once Semantics: Chandy-Lamport snapshots ✅ Hands-On Examples: Word count, sensor monitoring, late data handling

Core Principles to Remember

  1. Streaming First: Flink treats batch as bounded streaming
  2. Event Time Default: Always prefer event time unless you have a good reason not to
  3. Watermarks are Heuristics: Tune them for your data characteristics
  4. State is First-Class: Flink’s managed state is a superpower
  5. Exactly-Once is Hard: Flink makes it easy (within the system)

The Dataflow Model’s Legacy

The 2015 Dataflow Model paper didn’t just create a framework - it created a new way of thinking about stream processing:
  • Before: “How do I adapt my batch code to streaming?”
  • After: “How do I express my logic independently of execution?”
This mental model shift is why Flink (and Beam) succeeded where earlier frameworks failed.

Next Steps

Next Module Preview

In Module 2: DataStream API & Transformations, you’ll learn:
  • Complete DataStream API reference
  • Stateful transformations (mapWithState, process functions)
  • Stream joins and patterns
  • Async I/O for enrichment
  • Production ETL pipelines

Module 2: DataStream API & Transformations

Master the low-level DataStream API

Additional Resources

Research Papers

  1. The Dataflow Model (Akidau et al., VLDB 2015)
    • PDF
    • The foundational paper this module is based on
  2. Lightweight Asynchronous Snapshots (Carbone et al., 2015)
    • Flink’s exactly-once semantics mechanism
    • PDF
  3. State Management in Apache Flink (Carbone et al., VLDB 2017)
    • Deep dive into Flink’s state backends
    • PDF

Books

  • “Streaming Systems” by Tyler Akidau et al. (O’Reilly, 2018)
    • Written by the Dataflow Model authors
    • Definitive guide to stream processing concepts
  • “Stream Processing with Apache Flink” by Fabian Hueske and Vasiliki Kalavri (O’Reilly, 2019)
    • Practical Flink programming guide
    • Written by Flink committers

Online Resources

Practice Time: Spend 4-6 hours implementing the examples in this module with your own data sources (Kafka, files, sockets) to truly internalize these concepts.