Dinky: the Flink SQL workbench where development and operations share a screen

Immersive Flink SQL development

Dinky is an open-source real-time computing platform built with Apache Flink as its core, capable of real-time application job development, data debugging and runtime monitoring. The development experience is the first feature, immersive Flink SQL data development with prompt completion, statement beautification, online debugging, syntax verification, logic plan display, catalog integration, lineage and version comparison. The Monaco Editor in the acknowledgements is the editing surface behind that experience, and the version comparison feature addresses the operational reality that Flink SQL jobs evolve, so seeing what changed between versions is part of maintaining them, not just authoring them. The lineage and logic plan surfaces complete the authoring loop, a developer can see how Flink compiled their SQL before submitting it, and after a job has run for months, lineage answers the downstream question of which dashboards and jobs consume a table someone is about to change.

Five execution modes, from Local to Kubernetes Application

The deployment story spans how Flink actually runs in organizations, with support for multiple development and execution modes, Local, Standalone, Yarn Session, Kubernetes Session, Yarn Per-Job, and Yarn or Kubernetes Application. A single SQL job definition can therefore move from a developer's local Flink to the cluster topology without rewriting, which is the practical value of the mode abstraction. The gateway layer is visible in the repository as dinky-gateway, and the resource management feature tracks cluster instances and cluster configuration alongside data sources, alert definitions, documents, global variables, git projects, UDFs, resources and system configuration, the inventory an operating team maintains around the jobs themselves. The Per-Job and Application mode distinction the list preserves is worth knowing when choosing, Per-Job spins a cluster per submission while Application packages the job as the cluster's entrypoint, and Dinky exposing both means the platform follows the deployment convention an operations team already standardized rather than forcing its own.

The Flink ecosystem, wired in

The platform's ecosystem support names Connector, FlinkCEP, FlinkCDC, Paimon and PyFlink, and the CDC depth is its own feature line, real-time warehousing and lake entry for the entire FlinkCDC database and FlinkCDC Pipeline tasks, meaning one configuration can sync a whole source database into a warehouse or lake rather than table by table. The syntax enhancement layer extends FlinkSQL itself with database synchronization, execution environments, global variables, table-valued aggregate functions, load dependency, row-level permissions and execute jar, the extensions that turn FlinkSQL from a query language into a deployment language. The acknowledgements list mirrors the ecosystem, Apache Flink, FlinkCDC, Paimon, DolphinScheduler and Doris among the foundations. PyFlink support extends the same job management to Python-defined jobs, so teams that wrote UDFs or jobs in Python keep one operations surface, and the catalog integration means metadata defined once in the platform is visible to every job it manages.

Online debugging: Preview Table, ChangeLog and UDF

The debugging feature is singled out, real-time online debugging supporting Preview Table, ChangeLog and UDF. The three preview modes map to how streaming developers actually verify logic, Preview Table shows the materialized result, ChangeLog shows the insert-and-update stream that Flink's dynamic tables really produce, and UDF debugging isolates the custom functions that otherwise hide bugs inside the job. For a workflow that traditionally means submitting to a cluster and reading logs, in-platform debug previews before deployment are the feature that changes the development loop's length from minutes to seconds. Because the preview runs in the platform's own runtime, the debugging result also validates the connector configuration and dependency loading, the two places streaming jobs most often fail only after reaching a cluster.

Operations: snapshots, savepoints and alarm groups

The operations features cover the job lifecycle after deployment, real-time task operation and maintenance spanning online and offline state, job information, job logs, version info, job snapshots, monitoring, SQL lineage and alarm records. SavePoint and CheckPoint recovery and triggering are automatically managed with latest, earliest and specified options, the restart policy choices that decide whether a failed job resumes from its most recent checkpoint or starts clean. Alerting supports alarm groups across DingTalk, WeChat, Feishu, E-mail, SMS and Http, matching the notification channels Chinese enterprises standardize on, and the dinky-alert module in the repository carries that surface. Enterprise management adds multi-tenant, user, role and token controls.

A Java monorepo of twenty-plus modules

The repository layout names the architecture, dinky-admin for the management layer, dinky-core and dinky-client, dinky-app for assembly, dinky-flink for the version-dependent Flink shims, dinky-gateway for execution modes, dinky-cdc, dinky-catalog, dinky-metadata, dinky-connectors, dinky-function, dinky-alert, dinky-daemon for the background scheduler, dinky-scheduler, dinky-sandbox, dinky-extends and dinky-web for the frontend, plus e2e_test and deploy directories with build scripts for shell and Windows. SpringBoot, Mybatis Plus, Sa-Token and Ant-Design-Pro in the acknowledgements identify the stack behind admin and web, and the JetBrains free license note marks the IDE the team develops with.

Branch model, release rhythm, and community channels

The contribution section states the branch model directly, the dev branch is Dinky 1.3.0 and the 1.2 branch is Dinky 1.2.5, with contributions flowing through pull requests and a documented how-to-contribute guide. Releases on the 1.2 line landed roughly quarterly, v1.2.3 in March 2025, v1.2.4 in July and v1.2.5 on 2025-11-05, with the repository pushed 2026-08-25. Community support is multiplexed, GitHub issues with clear descriptions, the documentation site at dinky.org.cn, a WeChat user community entered by adding a contact with remarks in the format Dinky plus company name plus position, a QQ group numbered 543709668, and a WeChat public account publishing official articles, the channel mix of a project whose users live in the Chinese enterprise ecosystem. The screenshots section names the four surfaces a user actually lives in, Data Studio, Data Debug, Task Monitor and Task Metrics, which is a fair one-line summary of the platform's layout before any installation.

Editorial conclusion

Use Dinky when a team develops and operates Flink SQL jobs in production and wants one web platform covering the full cycle, authoring with completion and syntax checks, online debugging with table and ChangeLog previews, deployment across Yarn and Kubernetes, and alerting into Chinese workplace channels. Teams running only occasional batch jobs or managing Flink entirely through Kubernetes operators may not need its scope. Before deploying, follow the compile and deployment guides in the docs since installation is from source builds, verify your Flink version against the release, and note the branch model, dev carrying 1.3.0 while the 1.2 branch holds the v1.2.5 stable.

Frequently asked questions

Official sources

1. DataLinkDC/dinky on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases