Confluent Apache Flink Certificate key terms

The timestamp when an event actually occurred, carried inside the record itself rather than assigned on arrival. It lets results stay correct when data arrives late or out of order.

The wall-clock time on the machine doing the processing at the moment a record is handled. It is simple and fast but gives non-deterministic results when input order or speed varies.

A progress marker flowing through the stream asserting that no event with a timestamp earlier than the watermark is expected. It drives event-time timers and window closure decisions.

A configured grace period after a window's watermark passes during which late records are still accepted. Each late arrival may trigger an updated window result rather than being dropped.

A fixed-size, non-overlapping, gap-free time interval that assigns each event to exactly one window. Common for periodic aggregations such as per-minute counts.

A fixed-size window that advances by a step smaller than its length, so windows overlap and an event can belong to several. Used for moving averages and rolling metrics.

A window whose boundaries are defined by activity rather than fixed time: it groups events separated by less than a configured inactivity gap and closes after the gap elapses.

An incremental computation over the records assigned to a window, combining each new element into an accumulator. Results are emitted when the window fires according to its trigger.

The policy deciding when a window's contents should be evaluated and emitted, independent of when the window is finally purged. Examples include on watermark, on element count, or on processing-time timers.

A stream partitioned by a key extractor so all records sharing a key are processed by the same parallel subtask. Required before keyed state, keyed windows, and most stateful operators.

The transformation that hashes a stream by a chosen key so records with equal keys land on the same operator instance. It changes the stream's partitioning and enables keyed state.

The number of parallel subtasks an operator is split into within a job. It can be set per operator, per job, or at the cluster default level.

A scheduling feature that lets subtasks of different operators in the same job share one task slot, so a pipeline needs only as many slots as its highest-parallelism operator.

A periodic, consistent snapshot of operator state and source positions, coordinated by the JobManager. It enables recovery to an approximately identical state after failure.

A manually triggered, user-owned snapshot of job state used for planned upgrades, code changes, rescaling, or migration. Unlike checkpoints, it is retained until explicitly deleted.

The pluggable component that stores and snapshots operator state, such as heap memory or embedded RocksDB. Choice affects state size limits, throughput, and checkpoint behavior.

State scoped to the currently active key, so each key sees its own value such as a running count or last event. It is only accessible from operators on a keyed stream.

State bound to a parallel operator instance rather than a key, such as a list of buffered records or source offsets. It is redistributed among subtasks when parallelism changes.

A processing guarantee where each input record affects the result exactly one time, even across failures. It normally relies on checkpoints plus transactional or idempotent sinks.

A guarantee that no record is lost, though duplicates may occur after recovery or retries. It is cheaper than exactly-once and acceptable when downstream consumers can deduplicate.

A sink that writes through a transaction: it pre-commits data during checkpoints and commits only once a checkpoint completes. This yields exactly-once output to transactional systems.

A time-to-live setting that automatically expires and removes stale entries from keyed state, bounding state growth for keys that stop receiving updates.

The coordinating process that accepts jobs, schedules tasks, coordinates checkpoints, and handles failover. In high-availability setups a standby takes over if the leader fails.

The worker process that executes operator subtasks, holds task slots, and manages local state and memory. Each cluster runs one or more of them.

The unit of resource allocation inside a TaskManager, representing a fixed slice of its memory and CPU capacity. Subtasks are scheduled into slots.

The primary Java and Python API for building streaming pipelines from sources, transformations, and sinks, with explicit control over time, state, and windows.

A declarative, relational interface for expressing queries over static tables or continuous streams. It supports unified batch and streaming semantics and integrates with catalogs.

The relational abstraction of a changing stream: a table whose contents evolve over time as new records arrive. Queries over it produce a continuous changelog of results.

A stream of insert, update, and delete records that represents changes to a table. It is how streaming SQL results are converted back into an append or retract stream.

Custom logic registered with the Table API or SQL so queries can call it, such as scalar, table, or aggregate functions written in Java, Python, or Scala.

A pluggable source or sink implementation that reads from or writes to an external system such as Kafka, a file system, or a database, including format and fault-tolerance behavior.

The connectors that read from and write to Apache Kafka topics, supporting offset tracking in checkpoints and transactional producers for exactly-once output.

A DDL clause on a table column that declares how event-time watermarks are generated, for example with a bounded-out-of-orderness delay strategy.

The location, such as a durable filesystem, where checkpoint and savepoint data is written so state survives loss of a TaskManager or the whole cluster.

Configuration controlling how a failed job is restarted, including fixed-delay or exponential-delay retries and failure-rate thresholds before the job is finally failed.

The mechanism by which a slow downstream operator signals upstream producers to slow down, preventing unbounded buffering. Persistent backpressure indicates insufficient capacity.

A managed service that runs Flink SQL and streaming jobs against Confluent Cloud data, using Kafka topics and Schema Registry without operating a cluster yourself.

The binding that lets Flink SQL read and write Avro, Protobuf, or JSON Schema topics by resolving schema IDs, keeping table definitions aligned with governed schemas.