agentleFS
Sign inStart free
gordonmurraygordonmurray/data-engineering-skills/flink/SKILL.md

flink

Skill47 starsChanged 4 months agoMITView on GitHub

Architect, implement, deploy, upgrade, and troubleshoot Apache Flink stream processing jobs. Use for Flink SQL, Table API, or DataStream implementation, 1.x to 2.x migration, savepoint and state compatibility, checkpoint failures, backpressure, watermark and late-data problems, Kubernetes Operator deployment, Flink CDC pipelines, or Iceberg, Paimon, and Fluss connector work.

2 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 1

    1. pravsjv/claude-skills★ 057% same

    Wrote their own version · 1

    1. awslabs/managed-service-for-apache-flink-agent-steering-files★ 5same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository8 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use savepoints, not checkpoints, for planned upgrades and topology changes.

    line 65
  2. Distinctive:

    Prefer the Kubernetes Operator for long-running production jobs on Kubernetes.

    line 70
  3. Distinctive:

    Use Iceberg, Paimon, and Fluss connectors only at versions compatible with the selected Flink line.

    line 71
  4. Distinctive:

    Do not delete checkpoint or savepoint directories until the replacement job has run and completed a checkpoint of its own.

    line 82
  5. Very specific:

    Keep credentials out of config.yaml and job arguments.

    line 84
  6. Distinctive:

    After a restore, check that state size is in the expected range.

    line 92
  7. Distinctive:

    Update Helm/doc URLs when operator versions change.

    line 104

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Apache Flink Data Streaming Expert

Scope

Production Flink architecture, operations, SQL and DataStream implementation, upgrade planning, and lakehouse streaming integrations.

For table-format internals use the iceberg, paimon, or fluss skills. This skill covers the Flink job and its connectors, not the storage format's own maintenance operations.

For streaming AI agent applications, use flink-agents if installed. Keep core job operations here; agent Actions, Resources, and recovery need separate checks.

Current Facts

Release guidance checked on 2026-11-03. Recheck the linked sources before selecting versions for a new deployment; preserve existing project pins.

  • Current Flink line: 2.3.x. Flink 2.3.0 was released June 25, 2026 and is the latest stable release.
  • Other releases listed on downloads: 2.2.1, 2.1.3, and 1.20.5 (LTS). A download listing alone is not a maintenance-policy guarantee.
  • Kubernetes Operator: 1.16.1, released September 23, 2026, supports Flink 2.3.x, 2.2.x, 2.1.x, 2.0.x, 1.20.x, and 1.19.x. The old 2.2 ceiling no longer applies to the operator.
  • Flink CDC: 3.7.0, with published distributions for Flink 1.20.x and 2.2.x. Do not infer CDC support for 2.3 from operator support.
  • Flink Agents: 0.4.0 is a separate preview release with distributions for Flink 1.20 and 2.0–2.3. Its version and compatibility contract are independent of core Flink.
  • Java: Flink 2.x requires Java 11+. Java 17 is the practical default for new deployments; Java 21 support is experimental.

Critical 2.x Notes

  • DataSet API removed; use DataStream, Table API, or SQL.
  • Scala DataStream/DataSet APIs removed from the core distribution.
  • SourceFunction/SinkFunction and Sink V1 patterns are obsolete; prefer Source/Sink V2 connectors.
  • flink-conf.yaml was replaced by standard YAML config.yaml in Flink 2.x.
  • Per-job deployment mode was removed; use Application mode or Kubernetes Operator patterns.
  • Validate savepoint compatibility carefully before 1.x to 2.x migrations.

Inspect First

Establish before recommending or changing anything:

  1. The Flink version of the running cluster and of the job's dependencies. These drift apart more often than users expect.
  2. Deployment mode: Application, Session, Kubernetes Operator, YARN, or standalone.
  3. State backend, checkpoint storage location, and whether a recent savepoint exists.
  4. For migrations, the exact source version, every connector version, and whether the existing savepoint can be restored by the target version.
  5. For troubleshooting, read real metrics rather than inferring: checkpoint duration and failure count, backpressure, restart count, state size, and watermark lag.

Decision Rules

  • For greenfield work, consider 2.3.x with Operator 1.16.1 when every required connector supports it. CDC 3.7 and Paimon 2.1 still constrain those pipelines to supported older lines, commonly 2.2.x. Check each artifact independently.
  • Enable checkpointing and set explicit checkpoint storage. The default is not durable across cluster restarts.
  • Use savepoints, not checkpoints, for planned upgrades and topology changes.
  • Set explicit operator UIDs before the first production deploy. A generated UID changes when the job graph changes and silently breaks state restore.
  • Make event-time assumptions visible: choose watermark strategy and allowed lateness deliberately, and decide explicitly where late data goes.
  • Prefer the Kubernetes Operator for long-running production jobs on Kubernetes.
  • Use Iceberg, Paimon, and Fluss connectors only at versions compatible with the selected Flink line.

Safety

  • Take a savepoint before any upgrade, topology change, or parallelism change, and confirm it completed before stopping the job.
  • --allowNonRestoredState silently discards state for operators missing from the new job graph. Never pass it to get past a restore failure without first identifying which operator's state is being dropped and confirming that loss is acceptable.
  • Do not delete checkpoint or savepoint directories until the replacement job has run and completed a checkpoint of its own.
  • Keep credentials out of config.yaml and job arguments; use platform secrets.
  • Rescaling and state migration are not free. State the expected downtime before proposing them for a production job.

Verify

  • Confirm the job reaches RUNNING and completes at least one checkpoint after deployment. A RUNNING job that never checkpoints is not healthy.
  • After a restore, check that state size is in the expected range. Near-zero state after a restore usually means state was silently dropped.
  • Compare checkpoint duration, restart count, and backpressure against the values from before the change.
  • For SQL changes, read the EXPLAIN plan before running against production data.
  • Report the Flink version, deployment mode, and which metrics you actually observed rather than which ones should improve.

Update Checklist

  • Recheck Flink downloads for core, CDC, connector, and Kubernetes Operator versions.
  • Update Helm/doc URLs when operator versions change.

Sources

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free