100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Programming

Flink Quick Reference

A cheat sheet of core Flink APIs, configuration keys, CLI commands, and deployment modes.

PracticeBeginner6 min readJul 10, 2026
Analogies

This quick reference collects the Flink APIs, configuration keys, and CLI commands you reach for most often once you already understand the underlying concepts. It's meant as a fast lookup, not a tutorial — pair it with the deeper best-practices and architecture guides when you need the full reasoning behind a setting.

🏏

Cricket analogy: A Flink quick-reference sheet is like a fielding cheat card taped to a captain's wrist during a T20 final — a fast lookup for CLI commands, config keys, and API basics when there's no time to dig through documentation.

Core APIs and Operators Cheat Sheet

The DataStream API's core building blocks are map/flatMap (transform each record), keyBy (logically partition by key), window (group records within a time or count boundary), and process (custom low-level logic via ProcessFunction/KeyedProcessFunction with timers). The Table API and Flink SQL sit on top of the same runtime and offer a declarative, relational way to express the same joins, aggregations, and windowing, and can be freely converted to and from DataStreams via StreamTableEnvironment.

🏏

Cricket analogy: The DataStream API's map, keyBy, and window operators are like a match's basic actions — scoring a run (map transforms each event), grouping deliveries by bowler (keyBy), and tallying totals per over (window) — while the Table API is like reading the same match through a simplified scorecard summary.

Configuration Quick Reference

Common flink-conf.yaml and job-level settings: parallelism.default sets the cluster-wide default parallelism when an operator doesn't specify its own; state.backend selects hashmap or rocksdb; execution.checkpointing.interval controls how often checkpoints fire in milliseconds; and taskmanager.memory.process.size sets the total memory budget for a TaskManager process, which Flink then subdivides into managed memory, network buffers, and JVM heap/off-heap regions automatically.

🏏

Cricket analogy: parallelism.default is like a team management deciding the standard number of bowlers to rotate through an innings by default, while state.backend is like choosing whether the scorebook is kept on paper (HashMap, fast but limited) or in a filing cabinet (RocksDB, larger capacity).

yaml
# flink-conf.yaml essentials
parallelism.default: 4
state.backend: rocksdb
state.checkpoints.dir: s3://my-bucket/checkpoints
execution.checkpointing.interval: 30000
execution.checkpointing.mode: EXACTLY_ONCE
taskmanager.memory.process.size: 4096m
jobmanager.memory.process.size: 2048m
taskmanager.numberOfTaskSlots: 4

# Common CLI commands
flink run -d -p 8 -c com.example.MyJob my-job.jar
flink list
flink savepoint <job-id> s3://my-bucket/savepoints
flink cancel -s s3://my-bucket/savepoints <job-id>
flink run -s s3://my-bucket/savepoints/savepoint-abc123 -c com.example.MyJob my-job.jar

Common CLI Commands and Deployment Modes

Session mode runs a long-lived Flink cluster that accepts multiple jobs submitted over time, sharing JobManager and TaskManager resources — convenient for development and short-lived ad-hoc jobs. Per-job mode (largely superseded by application mode in newer Flink versions) spins up a dedicated cluster for a single job's lifetime. Application mode runs the job's main() method inside the JobManager itself rather than on the client, producing a cluster dedicated to exactly one application and avoiding the need to ship the job's dependencies to a submitting client — the recommended default for production.

🏏

Cricket analogy: Session mode is like a stadium's shared floodlight rig used across multiple matches in a tournament, while application mode is like setting up a dedicated broadcast rig just for one specific final — flink run is simply how the umpire signals 'play' to start the match.

Application mode is the recommended default for production deployments because it avoids shipping job dependencies to a client machine and isolates each application in its own cluster, improving both security and resource isolation.

Do not use session mode for production workloads that need strong resource isolation — jobs in the same session cluster share JobManager memory and a misbehaving job can affect others running in the same cluster.

  • Core DataStream operators: map/flatMap, keyBy, window, and process (via ProcessFunction).
  • Table API/SQL offers a declarative layer over the same runtime, interoperable with DataStreams.
  • Key config: parallelism.default, state.backend, execution.checkpointing.interval, taskmanager.memory.process.size.
  • flink run, flink list, flink cancel, and flink savepoint are the core CLI commands for job lifecycle management.
  • Session mode shares a long-lived cluster across jobs; application mode dedicates a cluster to one job and runs main() in the JobManager.
  • Application mode is the recommended production default for isolation and dependency management.
  • Always trigger a savepoint before cancelling a job you intend to resume or rescale later.

Practice what you learned

Was this page helpful?

Topics covered

#Programming#ApacheFlinkStudyNotes#FlinkQuickReference#Flink#Quick#Reference#Core#StudyNotes#SkillVeris#ExamPrep