Back to App

Guides

Flink

Compute pools, SQL statements, the SQL Workspace, and no-SQL topic actions

Overview

Flink lets you process your streaming data with SQL — straight from the portal, without touching the Confluent Cloud console. The portal covers the full surface:

  • Compute pools — the capacity (billed in CFUs) that Flink statements run on.
  • Statements — every Flink SQL program in your landing zone: list, inspect, stop, resume and delete them.
  • SQL Workspace — write and run Flink SQL interactively, with streaming results.
  • Topic actions — guided wizards (Transform, Deduplicate, Mask fields) that deploy common transformations without writing any SQL.

Flink maps onto your context naturally: your landing-zone environment is the catalog, your Kafka cluster is the database, and every topic is a table.

Access & roles

  • Viewers can see compute pools and statements (read-only) — no workspace, no actions.
  • Developers get the SQL Workspace and topic actions, and manage the statements in their business-unit scope: create, stop, resume and delete.
  • Admins additionally own the compute-pool lifecycle — create, resize, delete — because pool capacity is the main Flink cost lever.

Compute pools

A compute pool is where your statements execute. Flink → Compute Pools lists the pools in your landing zone with status and capacity (current vs. max CFU). The pool detail page shows:

  • Metrics — CFU consumption over time (with your max-CFU ceiling drawn in) and message in/out throughput, over a selectable window (last hour up to 7 days).
  • Statements on the pool — with per-statement type, creator, and live messages behind / in / out columns, plus the same search and status filters as the main statements list.
  • Open SQL Workspace — the entry point for running SQL on this pool.

Admins create pools with a name (prefixed via the resource-naming rules) and a max CFU, capped by a platform guardrail; the cloud/region is fixed to your landing zone. Resizing changes only the max CFU. Deleting a pool requires typing its name and warns about statements still running on it.

Default compute pools

Pools marked with the DEFAULT badge are created automatically by Confluent for each environment. They are platform-managed: you can run statements on them, but resizing and deletion are not offered — use a pool your team created when you need control over capacity.

Statements

Every query or deployment — from the workspace, a topic action, or the Confluent console — is a statement. Flink → Statements lists the ones in your scope with a status badge, a source badge telling you where it came from (Workspace — the self-service SQL Workspace or a Confluent-console workspace —, Topic action, or Other for statements created elsewhere, e.g. the Confluent CLI), compute pool, created date and an SQL preview. The list offers search, a multi-status filter (COMPLETED is hidden by default), a multi-source filter (Workspace experiments are hidden by default — re-include them there), a "Mine only" toggle showing just the statements you created, and bulk stop / resume / delete over a selection. The cogwheel above the table lets you choose which columns are shown — your selection is remembered per table.

The statement detail page shows everything about one statement: its status with the raw diagnostic detail, throughput metrics (records in/out per minute and the pending-records backlog, from Confluent telemetry), the full SQL with syntax highlighting and a copy button, a data flow card linking the topics it reads from and writes to, and its recent runtime exceptions — the first place to look when a statement is FAILED or DEGRADED.

Stop, resume, delete

Anything active can be stopped. Only background statements (INSERT INTO, CREATE TABLE … AS) can be resumed — a stopped exploratory SELECT can only be re-run. Deleting a statement is permanent, but never deletes the topics it created — those remain yours to keep or clean up.

Using the SQL Workspace

Just want the steps?

Follow the Query a topic with Flink SQL how-to — no SQL writing needed, the pre-filled query does the work.
  1. Open Flink → SQL Workspace in the sidebar. Your SQL runs on a compute pool: with one pool it is picked automatically; with several you choose once and the workspace remembers your choice — and you can switch the active pool in place from the workspace header at any time. (You can also enter from a pool's detail page via Open SQL Workspace, or jump straight in from a topic's Query with Flink SQL button — the editor arrives pre-filled with a SELECT on that topic.)
  2. Write Flink SQL in the editor. The catalog tree beside the editor shows your environment → cluster → Tables (your topics), using the same names Flink resolves queries against. Selecting a table opens its schema panel underneath — every field with its Flink SQL type, plus the system columns key and $rowtime. Clicking a field inserts its name at the cursor, and the describe icon adds a ready-to-run DESCRIBE EXTENDED statement.
  3. The workspace holds multiple statements: use the icons in a statement's left gutter to add another statement below it, duplicate it, or delete it (deleting also stops its running query). Each statement has its own editor, Run button and results.
  4. Pick a Mode next to Run: Once (the default) runs once over the data as of now and finishes with a final result set — the right choice for quick look-ups and aggregations; Continuous runs continuously and streams results until stopped.
  5. Click Run (or ⌘/Ctrl+Enter). Your query is submitted as a statement under your business unit's Flink service account.
  6. Results stream into the table as they're produced. Column names and types are shown; for changelog queries each row is tagged INSERT / UPDATE / DELETE. Click a column header to sort, or type in the filter row under the headers to narrow the rows — both work while the stream is live.
  7. For a never-ending streaming query, click Stop when you've seen enough.
  8. The History button lists your recent workspace queries, newest first — one click opens a previous query in a new statement, leaving your current work untouched.

Bounded vs. streaming queries

SHOW TABLES, DESCRIBE, bounded SELECTs and anything run in Once mode finish on their own and show "finished". An unbounded Continuous SELECT on a live topic keeps streaming until you press Stop — it never completes by itself.

Every query you run appears in Flink → Statements like any other statement. When you leave the workspace, your ad-hoc query is stopped (not deleted) — it stays available in your history. Queries left idle — streaming with nobody watching — are stopped automatically after the idle timeout, and the workspace tells you when that happened. Deployments (CREATE TABLE … AS, INSERT INTO) are meant to keep running and are never touched.

Topic actions — stream processing without SQL

Just want the steps?

Follow the Apply a topic action how-to for a click-by-click worked example (Deduplicate).

The Actions menu on a topic's detail page offers guided recipes for common stream-processing chores. Each is a short wizard — every input is picked from your topic's schema or pre-filled, so no SQL is required end to end. They work with Avro, JSON Schema and Protobuf value schemas alike.

  • Transform — produce a reshaped copy of a topic: a different key, partition count, serialization format, or renamed fields.
  • Deduplicate — produce an exact copy of a topic with duplicate records removed: you pick the field that identifies duplicates, and only the earliest-arriving record per value is kept. Key and value are otherwise unchanged; the original topic is untouched.
  • Mask fields — produce a copy with selected string fields masked, using per-field presets (Alphanumeric, Word, Digit, First N, All but last N). The original topic is untouched — point consumers at the masked copy.

The review step summarises the outcome in plain language; the generated SQL sits behind a collapsed "view SQL" for the curious, with "Edit in SQL Workspace" as the escape hatch for hand-tuning. Deploying creates an ordinary statement — it appears in the statements list, shows up in Stream Lineage while running, and is governed by the same stop/delete rules as everything else. The output topic name is prefixed by the naming rules; a new topic is always created, never overwritten.

What it costs (CFUs)

Flink is billed in CFUs (Confluent Flink Units). A compute pool has a max CFU ceiling, and running statements consume CFUs from it — so cost follows how much you run, not how many pools exist. A pool with nothing running on it costs nothing. Platform admins can see Flink's actual spend as its own product group in the admin cost view, and tune the guardrails (max-CFU cap, default pool size, workspace idle timeout) per landing zone in the admin settings.

A streaming query keeps spending until you stop it

An unbounded SELECT (or a deployed CREATE TABLE … AS) runs — and consumes CFUs — until it is stopped or deleted. The portal has your back for exploration: leaving the workspace stops your ad-hoc query, and abandoned idle queries are stopped automatically. Deployments are yours to manage — they keep running (and spending) until you stop or delete them.

Tips

  • If a query fails, the workspace shows the real Flink error inline (in red). A common one is "Error while deserializing value from topic …" — that means the topic's records don't match its declared value schema, not a problem with your SQL.
  • Fully-qualify table names (`catalog`.`database`.`table`) if a plain name isn't found — the default catalog/database context covers the common case.
  • To inspect a query in depth — status, full SQL, throughput metrics and exception history — open it from Flink → Statements, where every query you run appears.
  • A statement that is RUNNING but processing nothing may simply have no new input: check the pending records chart on its detail page — a flat zero backlog means it's caught up, not stuck.
Esc