Dynamic Scaling - How Apache Flink adapts to changing workloads
summary
Apache Flink implements dynamic scaling by splitting keyed state into key groups and non-key state into small units so the system can reassign state when changing parallelism; Kafka source offsets become per-partition Kafka offsets so partitions move between subtasks. Scaling requires taking a safe point snapshot, canceling, and restarting with a new parallelism — a demo shows parallelism 1 → 3 stops Kafka lag growth and then reduces it. Current limits: max parallelism (key-group count) is fixed at job start and live operator rescale and stop-with-atomic-snapshot are planned.
AI-written summary · about
chapters (7)
- 0:00Introduction to dynamic scaling
- 3:59Challenges of rescaling Flink jobs
- 12:49Partitioning state in Flink
- 17:05Live demo of scaling a job
- 29:41Current limitations and future plans
- 33:38Summary and release timeline
- 34:23Q&A session
related talks
20mAutoscaling Apache Flink Applications
38mAutoscaling Flink at Netflix
09mLoad Imbalance
50mStream Processing Smackdown: Kafka Streams vs. Apache Flink
36mApache Flink in the Cloud-native Era
30mDemystifying Deployments: Applications or Clusters, Active and Reactive Scaling - What is it about?
44mFlink’s New Batch Architecture
42mApache Flink deep-dive #bbuzz
