Dlink Roadmap 站在巨人的肩膀上

摘要：本文介绍了 Dlink 的 Roadmap，站在巨人肩膀上的它，是否真的未来可期？内容包括：

1. 前言
2. 目前
3. 近期
4. 未来
5. 总结

一、前言

在上篇文章中，我们主要回首过去，并了解了 Dlink 的前生今世。本文将带您了解它的 Roadmap，一起看看站在巨人肩膀上的它是否真的未来可期。

二、目前

定位

Dlink 是一个专业的 FlinkSQL Studio，可以在线开发、补全、校验 、执行、调试、预览 FlinkSQL，支持 Flink 官方所有语法及其增强语法，并且可以同时对多 Flink 集群实例进行提交、停止、SavePoint 等运维操作，如同您的 IntelliJ IDEA For Flink SQL。

这是 Dlink 在 Github 上的项目简介，可以发现它目前很像开源领域中的 Hue 和 Apache Zeppelin，但相比差距却甚远，其唯一的优势是提供了部分 Apache Flink 的 FlinkSQL 交互开发能力，暂时弥补了 sql-client 的不足。

那该定位如何产生的呢？

在 Flink 自发布 1.11 版本至今，FlinkSQL 的能力逐渐成熟，而近期 Flink CDC 2.1 发布，使 FlinkSQL 的应用能力更加强大。

Apache Flink PMC Member & Committer 阿里巴巴技术专家 —— 伍翀(云邪)老师在近期发布的《Flink CDC 新一代数据集成框架 技术原理、入门与生产实践》电子书中谈到 “ Apache Flink 作为一款非常优秀的流处理引擎，其 SQL API 又提供了强大的流式计算能力，因此结合 Flink CDC 能带来非常广阔的应用场景。”，这即是指引 Dlink 目前发展的方向与动力。此外，Dlink 的诞生也与云邪老师在 Apache Flink 项目中的杰出贡献息息相关，Dlink 核心灵感与思路以及实现均源自云邪的源码指引，可以这么说 ” 没有云邪的贡献便没用如今的 Dlink “。

2019年2月12日，云邪发布了博客《如何从小白成长为 Apache Committer》，讲述了如何参与社区贡献，如何成为 Apache Committer。然而我在 2021 年 10 月才刚开始接触 Flink，后续了解到云邪的贡献与博客以及相关的视频，（天哪！居然这么帅！> 。< ）==> 年少有为）,一时成为了奋斗的目标，当时深知自己能力不够，然后便先研究起 FlinkSQL 的应用与优化。历经半年不断实践积累了一些经验与成果，但均为应用方向，很难通过直接贡献代码来回馈社区，所以在 2020 年 6 月我下定决心通过建设 Flink 的生态项目来回馈社区。

在应用 Flink 的半年中，发现其开发和运维模式大大增加了使用门槛，在建设数据中台及实时数仓的过程中，为解决大量开发任务带来的研发与维护成本，自研了 Flink SQL 的敏捷提交及运维的开发平台，而对于 FlinkSQL 的一些优化都直接改进在了源码中。后续 Flink 版本的迭代带来的增强对我们的应用至关重要，但每次升级都需要重新改进源码，而且开发平台简陋的功能难以支撑日益增加的数据任务开发需求，所以在 2020 年 6 月时我梳理了开发平台的实现思路与不足，当时的开发平台和 sql-client 非常像，不同点在于它是个 web 应用。用时两周的业余时间重新设计并开发了 Dlink，然后于 6 月 6 日开源，定位专业的 FlinkSQL 开发平台以弥补 Flink 生态的缺失。说实话，开源很容易提升一个人的心态与能力，在此也建议未参与开源事业的朋友们尝试一下。

现状

历经六个月，Dlink 的发展虽然主要是由我一人在晚上的业余时间主导和推动，但其的发展速度仍是较快的。自 Dlink 0.4 发布以来的一个月里，有越来越多的朋友参与贡献与测试，也与很多开源界的大佬不谋而合、达成共识，在此非常感谢，三生有幸。

目前 Dlink 已经发展到 0.5-SNAPSHOT 版本，相对于我们的中台自身的开发平台来说，其能力已经远远超过，以致于内部放弃了对开发平台的扩展维护，将所有的数据开发任务转移到 Dlink 上完成。尽管我们的场景只有 Yarn-Session 和 Yarn-Application 两种模式，但开源回馈及追赶云邪大神（别人追鹿晗，那我追云邪咯）的驱动力促使我完成了所有模式的 FlinkSQL 敏捷提交与其他诸多的交互功能 ，当然还有很多缺陷正在完善。

Dlink 0.5 定位仍是专业的 FlinkSQL Studio，具备 Readme 所列举的大量开发交互功能。与 0.4 不同的是架构上支持了通过 SPI 方式扩展外部数据的元数据查询、sql查询及执行的能力，增强了其作为 Data Studio 的核心能力——查询，而该能力也将是 Dlink 从 FlinkSQL Studio 过渡到专业的实时计算平台的跃折点。

对比

有很多朋友在问，Dlink 和 Streamx、FlinkX、Apache Zeppelin、Scriptis 有什么不同，接下来我们以 Dlink 的角度简单分析它与其他数据平台的不同点。

首先是 StreamX，它定义为 Make Spark|Flink easier ，即使 Spark 和 Flink 的开发和应用更加便捷，与近期较火的 SeaTunnel 较为相似，均是架构与 Spark 和 Flink 之上，其区别是 StreamX 更偏重于 Flink 的支持，Spark 的支持还在孵化，此外StreamX 提供 Yarn 和 K8S 的 Application 部署模式的 Jar 任务和 FlinkSQL 任务定义及运维，其更适合作为久驻的 Flink 流任务的运维，而 SeaTunnel 则更专注于依赖 Spark 的数据同步，2.0 也支持了 Flink 的架构。

那 Dlink 和他们相比又有什么不同呢？首先，Dlink 更侧重于 FlinkSQL 的开发交互过程，尽管其具备较为齐全的任务提交能力与集群交互能力，但其未进行平台化功能的设计，在平台运维方面功能缺乏；其次 Dlink 的 K8S 起步较晚，由于其敏捷 FlinkSQL 提交的设计增加了部署门槛，目前需要人工提前搭建好需求的镜像才能自动化提交 FlinkSQL，而 StreamX 则可以通过 Flink 任务的定义来自动化部署 K8S 的任务；最后其实现思路与架构设计区别较大，StreamX 使用 Java 和 Scala 的混合开发以及前端更适合开源参与的 Vue 框架，后端门槛较高，Dlink 则完全使用 Java 开发，其前端为更偏企业应用的 Ant Design Pro 的 React 框架，前端门槛较高。

那二者选择哪个更好呢？其实，他们之间的关系目前并不是互相竞争的关系，两者可以互相协作生产，即 Dlink 负责 FlinkSQL 的开发与调试，StreamX 负责 Flink 任务的运维。然而，在两者的 Roadmap 上却发现，StreamX 将实现 Data Studio 来支撑 FlinkSQL 的开发，而 Dlink 则将实现专门的运维中心来支持任务的运维需求，或许后续两者的应用场景会出现冲突。

那为什么不融合在一起做强做大呢？因为 Dlink 与 StreamX 在底层 Flink 任务提交的实现完全不同，扩展架构也完全不兼容，导致他们难以融合在一块。不如让其各自发展，或许可以达到更好的效果与成绩。

由于 Dlink 和 StreamX 较为相似，使用了大篇幅来说明两者的不同点以及诸多疑问，那接下来要说的是 FlinkX。

Dlink 与FlinkX 的差别还是较大的，FlinkX 是一个基于 Flink 的后端框架项目，内部实现了非常多的外部数据源的 Connector ，通过 Reader 和 Writer 的模板配置进行快捷的任务定义，然后翻译成 JobGraph 在 Flink 执行，支持断点续传和脏数据管理，和 Datax 以及 SeaTunnel 很相似，更适合进行数据的高效同步。惊喜的是，Dlink 支持 Flink 的所有 Connector，而 FlinkX 的 Connector 是基于 Flink 开发，所以 FlinkX 已实现的大量的 Connector 可以直接或者稍加修改后被 Dlink 所使用。

然后我们来说下 Apache Zeppelin。Apache Zeppelin 是一个基于 Web 的 Notebook，提供交互数据分析和可视化。后台支持接入多种数据处理引擎，如 Spark，Hive 及 Flink 等。支持多种语言：Scala(Apache Spark)、Python(Apache Spark)、SparkSQL、FlinkSQL 、Hive、 Markdown、Shell等。其底层通过在不同的 JVM 中创建 Interpreter 来扩展各种计算引擎，后端通过 Server 来进行 Http 和 Websocket 的交互，前端则通过 Notebook 来完成数据开发及图表展现，十分强大。但由于其专业的定位使其对作业运维的支持有限，更适合数据科学家来进行交互式数据分析与可视化。

最后我们来说下微众开源的 Scriptis，Scriptis 一款支持在线写 SQL、Pyspark、HiveQL 等脚本，提交给 Linkis 执行的数据分析 Web工具，且支持 UDF、函数、资源管控和智能诊断等企业级特性。搭配 Apache Linkis 和 DataSphereStudio 可以满足企业一站式离线数据平台或中台的建设需求。Dlink 与 Scriptis 非常相似，区别在于 Dlink 为实时轻量级定义，并且主攻 FlinkSQL 方向，而未来 Scriptis 将通过 DataSphereStudio 的 Streamis 来实现 Flink 实时平台的支撑。

以上简单对比了 Dlink 和其他开源平台的区别，可以发现新生的 Dlink 虽然能力有限，但其发展空间还是很大。

总结

Dlink 目前的现状为开源社区提供了新颖的 FlinkSQL 交互开发的选择，降低了 Flink 的使用门槛，但却缺乏完备的运维托管能力，使其完全依靠它进行小规模的企业生产还存在难度与门槛。当然，对比其今天的 Flink Forward Asia 2021 中业内大佬们带来的企业平台分享可以发现还缺乏很多能力。

三、近期

Dlink 将于一月中旬发行 0.5.0 版本，相比如此前的 0.5 规划，其完成了 K8S 多种执行模式的支持、OpenAPI 的实现、外部数据源的SQL 操作、FlinkSQLEnv、UDF 的代码管理、多实例托管多版本的方案、以及修复了部分 0.4 的 bug等。

K8S 多种执行模式的支持

Dlink 在 0.5 中支持了外部 K8S 集群的 FlinkSQL 提交。

对于 K8S Session，可以直接将已存在的 K8S Session 实例（需要将 JobManager 的 rest 端口开放到 NodePort) 直接注册到 Dlink 的集群实例中，后续使用过程同 Standalone 和 Yarn Session。

对于 K8S Application，则需要首先以 Centos7 为基础镜像，将其所需要的 Flink 环境（包括用到的 Connector 、 UDF 和其他依赖）和 FlinkSQL 敏捷提交所需要的通用模板 Jar dlink-app.jar 以 dlink 的 extends 目录下的 Dockerfile 为模板修改相关参数，自行打包成镜像装载到 Docker 中。最后通过 FlinkSQL 中的 set 语法（推荐）或者右侧的自定义参数配置 K8S 执行 Application 所需要的参数即可，如下所示：

set kubernetes.namespace = 'demo';
set kubernetes.cluster-id = 'k8s-app';
set kubernetes.container.image = 'flinkapp';

注意：K8S Application 更多的操作与特性还需要自身拥有其知识栈才能灵活配置并生效，目前使用门槛较高。后续将优化为平台自动化过程。

OpenAPI 的实现

Dlink 开放了部分核心 API，主要包括Dlink自身作业提交、自定义作业提交、作业运维、数据预览等接口，接口入参 Json 模板位于 dlink-admin 子项目的 resources 下的 json 文件夹中。

比如，通过 http://127.0.0.1:8888/openapi/submitTask?id=1 可以触发ID为1的作业执行，通常用于第三方调度平台如 DolphinScheduler 和 XXL-Job 等通过 Http 请求调度触发 Dlink 中的 Flink 作业提交。

再者，通过 http://127.0.0.1:8888/openapi/executeSql 则可以把 Dlink 当作 Server 来提交作业，而不使用它自身的开发运维功能。其提交 perjob 任务的 Json 模板如下所示：

{
  /* required-start */
  "type":"yarn-per-job",
  "statement":"CREATE TABLE Orders (\r\n    order_number INT,\r\n    price        DECIMAL(32,2),\r\n    order_time   TIMESTAMP(3)\r\n) WITH (\r\n  'connector' = 'datagen',\r\n  'rows-per-second' = '1',\r\n  'fields.order_number.kind' = 'sequence',\r\n  'fields.order_number.start' = '1',\r\n  'fields.order_number.end' = '1000'\r\n);\r\nCREATE TABLE pt (\r\nordertotal INT,\r\nnumtotal INT\r\n) WITH (\r\n 'connector' = 'print'\r\n);\r\ninsert into pt select 1 as ordertotal ,sum(order_number)*2 as numtotal from Orders",
  "gatewayConfig":{
    "clusterConfig":{
      "flinkConfigPath":"/opt/src/flink-1.13.3_conf/conf",
      "flinkLibPath":"hdfs:///flink13/lib/flinklib",
      "yarnConfigPath":"/usr/local/hadoop/hadoop-2.7.7/etc/hadoop"
    },
    "flinkConfig": {
      "configuration":{
        "parallelism.default": 1
      }
    }
  },
  /* required-end */
  /* default-start */
  "useResult":false,
  "useStatementSet":false,
  "fragment":false,
  "maxRowNum":100,
  "checkPoint":0,
  "parallelism":1,
  /* default-start */
  /* custom-start */
  "jobName":"openapitest",
  "savePointPath":"hdfs://ns/flink/savepoints/savepoint-5f4b8c-4326844a6843",
  "configuration":{
    "table.exec.resource.default-parallelism":2
  }
  /* custom-end */
}

外部数据源的 SQL 操作

Dlink 在 0.5 中支持了外部数据源的元数据查询、sql 语句校验、查询与执行的操作。在 GitHub 的源码中仅提供了 Mysql、Oracle、PostGre、ClickHouse 的实现，通过 Mysql 可以实现 Doris 的支持。此外可以在 dlink-metadata 子项目下通过 SPI 来扩展其他数据源。

FlinkSQLEnv

Dlink 在 0.5 中实现了 FlinkSQLEnv，即 FlinkSQL 语句复用，主要用于 set 、create 等语句的初始化及复用，实现 FlinkSQL 层面的 Catalog 持久化。其他 FlinkSQL 任务可以选择该 FlinkSQLEnv 为运行环境，则可直接执行 insert 和 select 语句。

UDF 代码管理

Dlink 在 0.5 中扩展了多种方言，其中包含 Java，用于管理 UDF 的代码，目前仅仅实现了管理功能，比较鸡肋，为后续 scala、python 等其他语言的 UDF 及UDF开发调试装载等功能做铺垫。

多实例托管多版本

Dlink 在 0.5 中没有实现 rpc 架构，而是被推迟到了几近 1.0 版本。当前的 0.5 版本的 Dlink 目前只能通过同时启动多个实例，为每个实例分别加载不同版本的 Flink 依赖来实现多版本的支持，需要注意的是虽然连接了同一个 Mysql 作为业务库，但其后台未设计分布式读写的实现，有些功能如共享会话、数据预览等是完全隔离的。当然需要人工区分哪个 Dlink 实例是用来提交哪个版本的 Flink 任务，属实尴尬。

官网上线

Dlink 在 0.5 代码中新维护了 docs 子项目模块，并将之前的文章进行了简单整理，最后搭建 Github Pages 和官网。官网内容后续改进及补充。

修复 0.4 的 bug

1.新增 JobPlanGraph 来替代 StreamGraph；

2.新增 SQLServer Jdbc Connector 的实现；

3.修复编辑集群配置测试后保存会新建的bug；

4.新增 Local 的运行模式选择并优化 JobManager；

5.修复登录页报错弹框；

6.优化所有模式的所有功能的执行逻辑；

7.优化 ClickHouse SQL 校验逻辑；

8.解决 Yarn Application 解析数组异常问题；

9.解决自定义Jar配置为空会导致异常的bug；

10.解决任务提交失败时注册集群报错的bug；

11.解决set在perjob和application模式不生效的问题

12.解决perjob和application模式的任务名无法自定义的问题；

13.支持 Yarn 的 kerboros 验证。

更名 Dinky

由于原名 Dlink 存在路由器及其他企业数据平台的商标冲突问题，Dlink 将在 0.5 发布时更名为 Dinky。依据如下：

1.Dinky 英译为 “ 小巧而精致的 ” ，最直观的表明了它的特征：轻量级但又具备复杂的大数据开发能力。

2.为 “ Data Integrate No Knotty ” 的首字母组合，英译 “ 数据整合不难 ”，寓意 “ 易于建设批流一体平台及应用 ”。

3.从 Dlink 改名为 Dinky 过渡平滑，即解决了冲突又更加形象的阐明了开源项目的目标，始终指引参与者们 “不忘初心，方得始终 ”。

四、未来

Dlink 在 2022 年的 Roadmap。Dlink 在 0.5 发布后将开始建设运维中心、优化交互功能、分享生态案例、对接开源项目、增强更多 Flink 特性等。

任务生命周期管理

FlinkSQL 生命周期：创建、开发、调试、发布、上线、注销。

Dlink 的 FlinkSQL Studio 负责 FlinkSQL 的开发和调试，在确定最终的 SQL 口径及任务配置后，可通过任务发布功能自动地在运维中心注册测试或生产环境下的最终任务，同时具备版本的管理，将开发与运维分离，保证生产环境的稳定性。

在运维中心可以上线已发布的任务，或者将已上线的任务进行下线，然后可以通过维护功能将任务重新进入开发和调试的进度。

最后，可以在运维中心注销已经不需要或者错误的任务，将被彻底删除。

元数据管理

Dlink 目前支持对外部元数据的采集功能，将建设统一的元数据管理，使其可以不需要依赖第三方元数据平台，独自进行更加适应实时数仓的元数据消费操作，统一规范拥有大量数据表、复杂关系的建设需求。

元数据主要包含采集、构建、管理、同步四大功能。

采集：Dlink 通过 SPI 来扩展实现更多数据源的元数据采集功能，使其可以轻松对接第三方存储库、元数据平台等，甚至可以将消息队列的元数据采集进行扩展，以便于洞悉实时数仓的流数据结构。

构建：Dlink 提供构建逻辑表、字段、关系的能力，解耦外部存储层，通过词根维护来规范命名定义。

管理：Dlink 支持对逻辑表和物理表的结构的可视化管理能力，可添加物理表不支持的信息如标签、分类、注释、权限等。

同步：Dlink 支持自动或手动地将元数据变动同步至对应数据源，或根据逻辑表在数据源上创建物理表。

血缘和影响分析

Dlink 目前具备任务表级的 FlinkSQL 血缘分析，通过 FlinkSQL 解析并构造后的 StreamGraph 来获取血缘关系，规避了冗余 Create Table 等的影响，同时支持多 Create View 的语句，使 FlinkSQL 结构更加清晰明了易于维护。

FlinkSQL 任务被发布到运维中心时，会自动生成血缘关系，与元数据管理的元数据信息做对应，进而形成全局的数据链路关系，便同时得到了影响分析。拥有了血缘和影响分析，便更加方便的管理和优化所有的数据任务。

处在 Studio 开发环节的任务，则可以根据已发布的任务构成的数据链路关系来获取自身的全局血缘及影响分析。

单从血缘分析来说，含有表级、字段级、记录级。Dlink 将完善字段级血缘并开放，记录级则是未来探索的一个方向，记录级的血缘将会更直观地展现出数据的治理过程，便于排查数据内容问题。

集群运维

Dlink 目前的 FlinkSQL 敏捷需要提取部署好外部的环境才能使用，而该过程目前是通过人工手动进行，需要进行复杂的运维操作，此外还要解决因依赖导致的各种问题。

Dlink 将对集群环境的搭建和启停等操作进行自动化地支持。

首先配置免密通信集群的节点信息，将部署资源提前放到 Dlink 目录下或通过镜像地址进行下载，通过集群模板的配置来分发和部署所使用的 Flink 资源及其他资源，若为 K8S 环境则打包镜像并装载至容器。资源到位后可直接通过 Dlink 启动对应集群如 Standalone 、Yarn-Session 和 K8S-Session等。做到集群部署运维托管 Dlink 。

运行监控

Dlink 需要对集群资源及 Flink 作业进行时序监控，支持外部对接 Prometheus 消费定制化的时序数据。

Dlink 通过 SPI 的方式来实现自定义监控接口实现，使其可以插件化地管理不同的中间件的不同的 Metrics 的实现或者对接外部 Metrics 采集组件。

Dlink 通过 JobManager 对 Flink 作业进行状态监控，反馈异常的指标，辅助用户对作业进行口径或者参数优化。

报警推送

Dlink 通过 SPI 来扩展报警方式，将先实现钉钉的报警插件，后续企业号、邮箱等留给社区贡献开发。

Dlink 通过自定义报警规则及内容模板来触发报警或者推送报表，使用户第一时间知晓生产环境的异常状况以及其自定义的报表及推送信息如批流任务启停、依赖任务启停、集群操作推送等。

依赖调度

Dlink 定位是批流一体平台，不排除用户存在大量的复杂依赖关系的调度需求。

Dlink 提供依赖调度引擎，通过全局的数据链路关系自动获得任务的 DAG 图，根据指定的依赖调度作业参数手动或定时拉起守护线程 Daemon，Daemon 通过子调度组、 DAG 及节点权重、并行度、黑名单、超时时间、异常处理策略、任务历史执行信息、运行监控反馈的资源信息等来通过 SDJF（短依赖作业优先）算法进行大量依赖作业的动态调度编排，合理充分利用资源的同时缩短整个数仓的数据周期。Daemon 触发报警规则或异常时会进行报警，执行完所有的任务后会触发推送，并根据后驱依赖调度组配置进行递归调度。

在容错方面，Daemon 可以在异常任务处跳过当前节点或后续影响节点，也可触发停止并报警。当 Daemon 因异常原因停止后，由于其自身状态信息根据归档周期进行持久化存储，所以可以从最新的快照恢复 Daemon ，从而恢复后续任务的正常执行。当然可以对Daemon进行暂停、或停止操作，进行作业维护，维护成功后可以恢复执行。

以上的特性将使用户无需梳理复杂的依赖关系或者手动配置 DAG，也不需要估测调度间隔或者长期观察任务执行情况进行手动优化。由于 Daemon 依据任务历史执行数据作为调度影响因子，随着时间的推移会自动编排出最合适的并行调度计划（类似于机器学习）。此外由于子依赖调度组的设计可以在执行前合并子组的 DAG，使用户可以将大量任务以业务主题划分调度组，更有利于作业的维护，而其后驱依赖调度组的设计则可以以时序的方式隔离两个调度组，实现隔离 DAG 调度。

作业自动恢复

Dlink 批流一体的发展趋势必然会出现越来越多的流或批流一体任务。

而其守护线程 Daemon 分为两者，一种是上文说到的依赖调度守护线程，另一种则是实时任务守护线程。在实时任务守护线程下，Daemon 支持根据 savepoint 周期配置项来周期性地进行 savepoint 的触发，满足在任务异常失败后自动从 savepoint 恢复的机制，checkpoint 则依赖 Flink 自身的恢复能力自动从 checkpoint 恢复任务，当然也可以通过 RocksDB 管理 checkpoint 并存储至文件系统，Daemon 在任务异常失败后自动从 checkpoint 恢复。可见两种恢复机制的成本不一样，根据具体需求选择。周期性的备份状态自然会造成大量的冗余文件，可以配置保留的备份次数，自动清除过期状态。当作业超过失败重启次数后，Daemon 会自动报警；当满足推送周期可自动推送任务的运行信息。

守护进程

在RPC版本发布前，仍为守护线程，上文谈到了 Daemon 的两种线程分类，此外还一种守护进程，位于 RPC 版本。

在 RPC 版本中，上文所说的两种 Daemon 主线程会在运行期间周期地及手动触发地发送自身信息给 Daemon 进程，当 Daemon 在预计的延时内未接受到 Daemon 主线程的信息，会认为该线程异常中断，便远程通信使其自动从快照恢复。

守护进程 Daemon 还管理作业执行等线程，Dlink 的 FlinkSQL 作业提交看似简单，但其后台进行了复杂的多步处理如：准备执行环境、解析增强语法、组装语句集、解析翻译优化得到 JobGraph、获取 YarnClient、提交JobGraph、等待响应。提交线程将其进度以及需要持久化到数据库的信息发送给 Daemon，Daemon 负责管理以及委托持久化。当然也可以通过 Daemon 来中断提交线程。

此外 Daemon 也负责 dlink-client 、dlink-server 与 dlink-admin三个进程的实例管理，配合 dubbo 来治理服务及扩展新服务。

库表数据同步

Dlink 将提供基于 Flink 引擎的可视化构建库表数据同步任务的功能。

离线方面，Dlink 通过界面配置库表同步的作业配置，作业启动后，Dlink 从配置中获取数据源信息及库表选择信息等其他配置项，自动构建 Flink 批作业并交由 Daemon 依赖调度托管大量任务的有序稳定执行。

实时方面，Dlink 则根据配置信息自动构建 FlinkCDC 无锁作业，并交由 Daemon 实时任务守护进行流任务托管。

批流一体方面，Dlink 则将由上述两个 Daemon 协作完成，后者启动流任务后，前者通过批任务完成历史数据合并，或直接使用 FlinkCDC自带的批流一体读取来实现同步，具体按需求选择。

以上数据同步任务的定义将提供 SQL 语句 create datasync 来实现一句 SQL 定义任务的效果。

企业级功能

Dlink 将提供轻量的企业管理能力，如多租户、项目、角色、权限、审计。

此外 Dlink 将重新设计后台架构，使其更加解耦且插件化，基于服务的治理来满足大型场景的建设需求。

多版本 Flink-Client Server

在单机版本中，dlink-client 的执行环境所需要的依赖均从项目的 lib 和 plugins 目录下加载，一个 Dlink 实例只能部署一个版本的 Flink 环境。

在 RPC 版本中，将通过服务治理来同时支持不同版本的 dlink-client 任务提交。dlink-admin 管理 dlink-client，通知 dlink-server 来启动 dlink-client，dlink-client 可以根据指定的依赖启动对应的 Flink Client环境并久驻，也可以根据环境变量来作为插件部署到 Flink 集群直接启动对应的 Flink Client环境并久驻。

Dlink 的任务在提交时，会根据指定集群实例或集群配置来获取对应版本号或者指定的 dlink-client 来选择对应的 dlink-client 进行任务的提交等其他操作。

Flink StreamGraph 和 JobGraph 的可视化修改

Dlink 将提供 StreamGraph 和 JobGraph 两种状态下的任务计划可视化修改功能，如修改 StreamGraph 的算子并行度、自动追加 Sink 等。还支持将 Jar 提交任务在 dlink-client 转换成 StreamGraph 和 JobGraph ，然后进行分析、修改及统一提交，这样 Jar 任务也将可以得到血缘分析，进而可以被合并到数据链路图，被依赖调度一起托管。

Flink 自动化动态扩缩容

Flink 流任务的动态扩缩容是个降本增效的好措施，Dlink 将提供自动化的自动动态扩缩容来应对 Reactive Mode 和非 Reactive Mode 两种场景。

首先 Dlink 会通过运行监控接口获取流作业的时序资源占用数据，以天级别或周级别甚至月级别来计算和评估资源的占用模型。

对于 Reactive Mode ，即 Flink 1.13 之后的 Standalone Application Mode 模式下，可通过 Kubernetes Horizontal Pod Autoscaler 进行自动扩缩容。

而对于非 Reactive Mode ，Dlink 将通过 Daemon 依据资源预测模型进行周期性的作业调整并行度等其他优化配置和重启作业来完成较高成本的自动化动态扩缩容。

FlinkSQL OLAP & BI

Dlink 将投入更多精力来优化基于 FlinkSQL 来进行 OLAP 查询和查询结果BI化，使其可以通过柱状图、折线图、饼图等直观地展现出数据特征。

在 FlinkSQL OLAP 方面，一是，Dlink 将优化 Session 模式的作业提交效率与作业配置，逐步减少整个查询请求的响应时间；二是，Dlink 将自动装载指定数据源的元数据到对应会话中，使其 SQL 开发只需要关注 select 的口径，无需再次编写 set 和 create。

在 BI 方面，Dlink 将 FlinkSQL 及其他查询引擎如 jdbc 的查询结果进行自动化的转换，将表格数据转换为柱状图、折线图、饼图等其他图形所需要的数据格式，并进行渲染，便于数据科学家更值观地分析数据。

FlinkSQL 翻译及生成

Dlink 将提供 FlinkSQL 翻译功能，该功能可以将传统 SQL 如 Mysql、Oracle 等 DDL 、DQL 语句翻译为 FlinkSQL 语句，便于作业迁移和降低门槛。通过SPI来扩展其他 Dialect 的转换。

Dlink也将提供 FlinkSQL 生成功能，通过元数据来生成 DDL，自动对齐 insert into select 等，使 FlinkSQL 开发更加便捷。

Dlink-Jdbc

Dlink 将提供自身 jdbc 组件来便捷基于 Dlink 引擎的 FlinkSQL 任务提交。第三方系统（业务系统、数据库工具、调度平台、BI平台等等使用 jdbc 的系统）通过引入 dlink-jdbc.jar，如同开发 Mysql 的 jdbc 应用操作来执行 FlinkSQL，与 dlink-server 进行通信，dlink-server 根据 url 参数配置在对应版本的 dlink-client 上执行其 FlinkSQL。

FlinkSQL Studio 交互优化

Dlink 目前提供了简陋的 Studio ，虽然可以满足基本的开发需求，但 Studio 其他功能同样对开发调试具有重大影响，如项目导入导出、文件导入导出、开发Demo、配置模板、执行日志、SQL 对比等功能。

Dlink 除了将逐步完成以上功能外，还要进行交互上的优化，使其更加接近专业的 IDE，如风格切换、面板调整、定时保存、History对比和恢复等。

实践分享

Dlink 将投入更多精力围绕业界主流的存储架构、平台等进行应用实践分享。

Dlink 通过用户在生产上对接各种生态的实践进行总结和整理，最终在公众号、官网中分享各实践主题下的用户经验与操作说明，如 FlinkCDC、Hive、ClickHouse、Doris、Hudi、Iceberg 等基于 Dlink 快速落地的经验。

Dlink 也将积极对接其他开源平台如 Linkis、AirFlow、DolphinScheduler、DataSphere Studio 等，使其可以为各平台在 Flink 支持上提供更多一种的选择，也将实现对应的批量作业导入功能，使其可以低成本地迁移作业。

开源协作共建共赢

由于篇幅有限，上述 Roadmap 只阐述了核心的方向点，还有诸多细节未涉及，相信您已经大饱眼福了。丰富的新特性与功能并不是一朝一夕就可以实现的，虽然个人拥有大多数功能的实践经验与实现思路，但更期望的是 Dlink 的发展可以由社区主导而不是我个人主导。

开源不是一种商业模式，而是一种质量更高的协作开发模式，从贡献源码、测试、文档、答疑、应用实践等多方面渠道，都可以参与开源项目的共建，最终可以帮助用户将更多精力投入到业务建设中，推动国家整体信息化水平的快速发展。

五、总结

Flink Forward Asia 2021 已经落下帷幕，众多企业分享了其自身基于 Flink 的优化及应用，更有开源解决方案的专题特别分享了 Flink 与其他开源项目的协作生产的经验。可见 Flink 当前势头正大，未来发展更快。

在《Apache Flink 不止于计算，数仓架构或兴起新一轮变革》中，Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰（莫问）重点介绍了 Flink 在流批一体架构演进和落地方面的最新进展，并提出了 Flink 下一步的发展方向——流式数仓（Streaming Warehouse，简称 Streamhouse）。而 Dlink 的发展方向是基于 Flink 的实时计算平台，由上文的 Roadmap 可以看出流式数仓正是其应用的核心场景，可见 Dlink 与 Flink 的发展正趋于一致，为 FlinkSQL 而生的它，亦为 Flink 发展而前仆后继，勇于探索。

最后，站在巨人肩膀上的 Dlink 是否未来可期，相信您已经拥有了自己的答案，那快快行动起来吧。