跳到主要内容

Dinky

· 阅读需 6 分钟
tanzhuo

前言​

做实时计算的同学大多有类似的体会：Flink 本身足够强大，但围绕它的开发和运维体验并不友好。写好的 SQL 要打包提交、调试要翻日志、多个集群各管各的，任务一多就乱。最近在调研实时数仓的工具链时接触到了 Dinky，这里记录一下它解决了哪些问题。

Dinky 是一款开源的 Flink 作业管理与开发平台，整体设计轻量、易用，能够统一管理多个 Flink 集群。
开发者可以通过 Web 控制台直接在线编写和调试 Flink SQL，并在完成开发后一键提交到指定的 Flink 集群执行作业，大大降低了实时计算任务的开发和运维成本。

换句话说，它把「写 SQL、调试、提交、监控」这一整条链路收进了一个浏览器页面。对比原生 Flink 的使用方式——本地写代码、打 jar 包、命令行提交、去 Flink Web UI 看状态——这种一站式的体验对纯 SQL 化的实时任务开发非常省事。

官网地址​

https://github.com/DataLinkDC/dinky

功能描述​

Dinky 内置 整库同步能力，可以将微服务系统中的数据库表数据同步到实时数仓，从而有效解决微服务架构下的数据孤岛问题。

这一点值得展开说说。微服务架构下每个服务都有自己的数据库，数据分析时往往需要把几十上百张表汇聚到一起。如果用原生 Flink CDC，通常一张表就要写一个 source 定义，表多了既繁琐又占用大量数据库连接。整库同步的思路是：一个作业读取整个库的变更日志（如 MySQL 的 binlog），再在作业内部按表分流写入下游，配置量和资源占用都小得多。

同时，Dinky 支持 多版本 Flink SQL 的开发与管理，并提供 数据血缘分析能力，帮助开发者更清晰地了解数据流向及依赖关系，便于问题排查与系统维护。

血缘分析的价值在任务规模上来之后才明显：当某张结果表数据异常时，可以顺着血缘图向上追溯它依赖的中间表和源表，而不是靠人脑记忆或翻代码；反过来要下线或改动一张表时，也能先看清有哪些下游任务会受影响。

整体来看，Dinky 在实时数据开发、任务管理以及数据治理方面的功能较为完善，是一款非常实用的 Flink 数据开发平台，值得在实时数仓项目中进行使用和推广。

实时数仓建设​

通过 Flink SQL + Dinky，可以快速构建实时数仓任务，例如：

  • 用户行为实时分析
  • 交易数据实时统计
  • 实时风控系统

这类场景的共同点是：数据源源不断进来，业务方要求分钟级甚至秒级看到结果。传统的离线数仓按天或按小时跑批，满足不了这种时效性要求；而用 Flink SQL 把逻辑写成流式任务，再交给 Dinky 托管生命周期，开发节奏和写离线 SQL 已经很接近了。

数据同步与 CDC​

利用 Dinky 的整库同步能力，可以实现数据库变更数据捕获（CDC），将业务数据库中的数据实时同步到数据仓库或消息队列中。

CDC 的原理简单说就是订阅数据库的事务日志：每一条 INSERT / UPDATE / DELETE 都会在日志中留下记录，CDC 工具把这些记录解析成变更事件流。相比定时全表扫描的同步方式，它对源库的侵入小、延迟低，还能捕获到删除操作。一个典型的 Flink SQL CDC 源表定义大致长这样：

-- 声明一张 CDC 源表，实时捕获 MySQL 中 orders 表的变更
CREATE TABLE orders_source (
  order_id BIGINT,
  user_id BIGINT,
  amount DECIMAL(10, 2),
  PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
  'connector' = 'mysql-cdc',   -- 使用 MySQL CDC 连接器读取 binlog
  'hostname' = '...',
  'database-name' = '...',
  'table-name' = 'orders'
);

在 Dinky 中这段 SQL 可以直接在线调试、预览结果，确认无误后再提交到集群，省去了本地反复打包验证的过程。

实时数据开发平台​

Dinky 也可以作为企业内部统一的实时计算开发平台，为数据开发工程师提供标准化的开发环境。

统一平台的意义不只是省事：SQL 脚本集中托管、有版本记录，任务的提交和运维方式一致，新人接手项目时不需要先搞清楚每个人各自的提交脚本和环境差异。这对团队协作的价值往往比单个功能点更大。

踩坑与注意​

  • Dinky 本身不运行计算任务，它是提交和管理的入口，Flink 集群仍然需要单独部署和维护，两者的版本兼容性要提前确认。
  • 使用 CDC 整库同步前，需要确认源数据库已开启变更日志（如 MySQL 的 binlog），并给同步账号授予相应权限，否则作业起不来。
  • 在线调试很方便，但调试环境的资源和数据量与生产集群不同，逻辑复杂的任务上线前仍建议在生产同规格环境验证一遍。
提示

选型时建议直接拉起一个测试环境，用自己业务里最复杂的一条链路（比如一张大表的整库同步 + 一段多表 join 的 SQL）跑通全流程，比看功能列表更能说明问题。

小结​

Dinky 补上的是 Flink 生态里「开发体验」这块短板：在线写 SQL、一键提交、整库同步、血缘分析，覆盖了实时数仓开发的主要日常。如果团队的实时任务以 Flink SQL 为主，又苦于没有统一的开发和管理入口，它值得纳入选型范围。

评论 / COMMENTS