State, Checkpointing and Streaming Patterns Quiz
Distinguish the chapter's Flink/Kafka and Flink/Iceberg version combinations.
- Does choosing RocksDB remove heap, GC and memory-sizing concerns?
Show Answer
Answer: No. Native caches, managed memory, user objects, operator state and buffers still consume resources.
Explanation: Keyed-operator backends can share a slot memory budget. Measure workloads/state and checkpoint/restore rather than using a fixed MB cutoff.
- Are incremental snapshots exclusive to RocksDB in Flink 2.2?
Show Answer
Answer: No. Experimental ForSt also uses asynchronous incremental snapshots.
Explanation: Check its remote-SST/local-cache model and API/snapshot limitations. This chapter's configuration example uses RocksDB.
- Does incremental-checkpoint upload size depend only on logical key changes?
Show Answer
Answer: No. It persists new SSTs/metadata, and compaction can rewrite large files.
Explanation: Reusable shared SSTs are referenced. Expiring files that are still referenced can break recovery.
- Does incremental restore replay all earlier checkpoints sequentially?
Show Answer
Answer: No. It restores files referenced by the selected checkpoint.
Explanation: Full checkpoints are not necessarily single files. Recovery depends on networking, file counts, I/O and canonical-state reconstruction costs.
- Is a savepoint always permanent until someone manually deletes it?
Show Answer
Answer: No. Operator retention/disposal and CLAIM/NO_CLAIM ownership affect its lifecycle.
Explanation: Checkpoints can also have explicit triggers and externalized retention. Check storage, references and deletion responsibility.
- Does Operator last-state always use one last checkpoint file?
Show Answer
Answer: Recovery depends on accessible HA metadata or the last checkpoint/savepoint and the applicable path.
Explanation: Valid metadata, state compatibility, UIDs and serializers are required; the label alone does not guarantee recovery or migration safety.
- What do Kafka EXACTLY_ONCE guarantees require from checkpoints and consumers?
Show Answer
Answer: Transaction commits are coordinated with checkpoint completion, and downstream consumers must use read_committed.
Explanation: Replayable sources and recoverable state are also needed. Different sinks/all subtasks do not become one global transaction.
- When should transactionalIdPrefix be unique, and when should it remain stable?
Show Answer
Answer: Unique across independent concurrent sinks/jobs; stable across restarts of the same logical execution.
Explanation: Collisions can cause fencing, while changes can delay lingering-transaction cleanup and consumer progress.
- Does a 60-second checkpoint interval cap added Kafka latency at 60 seconds?
Show Answer
Answer: No. Checkpoint duration, commits, failures/recovery and consumer delay also contribute.
Explanation: Align transaction timeout with broker limits and worst-case recovery. The 5.0.0 builder defaults to one hour.
- Does every Kafka connector transaction-naming strategy create a new ID each time?
Show Answer
Answer: No. Optional POOLING reuses names, unlike default INCREMENTING.
Explanation: POOLING requires Kafka 3+, additional topic-read permissions and migration checks. Measure frequent-commit load separately.
- What real DynamicIcebergSink API and runtime combination were checked?
Show Answer
Answer: forInput → generator → catalogLoader → append; Iceberg 1.11.0 with Flink 2.1.3.
Explanation: The generator emits DynamicRecords to a Collector. A Flink 2.1 runtime JAR is not presented as validated with Flink 2.2.1.
- Can the insert-only Dynamic Iceberg helper serve unchanged as a Debezium CDC processor?
Show Answer
Answer: No. Validate RowKind, equality fields, upsert, table formats and schema-evolution limits.
Explanation: Managed Firehose/MSK Connect alternatives also need source, permissions, keys, formats, buffering and failure handling checked.
- Is declaring an event_time TIMESTAMP column enough for the SQL window query?
Show Answer
Answer: A streaming event-time window needs a time attribute; the example declares a WATERMARK.
Explanation: The reviewed planner rejects the plain-timestamp variant without it. Connector/format JARs are also needed.
- What version-specific limits apply to the S3 plugin and bundled demo?
Show Answer
Answer: The plugin contains end-of-support AWS SDK v1.12.779; StateMachineExample sets a two-second checkpoint interval in code.
Explanation: Do not mix in v2 provider classes blindly. Inspect min-pause and application overrides rather than inferring cadence only from config.
- Are late records after a watermark always dropped or automatically sent to a side output?
Show Answer
Answer: No. Watermarks estimate progress; windows can fire again during allowed lateness.
Explanation: Side output after cleanup requires explicit configuration. Check timestamp extraction, idleness and SQL/DataStream differences.