摘要：本文介绍了 Dlink 2021 年终总结，前生今世，未来可期。内容包括：
- 前言
- 由来
- 发展
- 应用
- 前景
- 感谢
- 结语
Tips：历史传送门～
《Dlink 如何在 IDEA 中调试开发》
《Dlink 在 Flink-mysql-cdc 到 Doris 的实践》
《Dlink On Yarn 三种 Flink 执行方式的实践》
《Dlink 在 Hive 的实践》
GitHub 地址
https://github.com/DataLinkDC/dlink
欢迎大家关注 Dlink 的发展~
一、前言
来到了 2021 年的最后一天，自 6 月 6 日开源立项到今天，历时 6 个月，Dlink 终于崭露头角。而 0.5 版本也将于一月中旬与大家相见。本文将带您领略 Dlink 的由来、发展、应用及前景，那我们就直接开始吧！
二、由来
记得 19 年刚毕业的夏天，我原本执迷于深度学习与 NLP 应用，一心想投身人工智能领域的研究。一次巧合，领导临时的一个数据 ETL 任务托付给我来完成，然而正是这次任务，彻底转变了我的研究方向。
这个 ETL 任务是个异构的大宽表处理，位于 Oracle，大宽表具有一百多个列，部分列具备明确的字典值域，而业务表也位于 Oracle 则数据质量较差，值域也与目标值域不同。仔细分析后得出了以下几步处理：关联查询、复杂处理、字典映射、写入数据库，而领导要求使用 kettle 或者 Java 程序来完成。刚毕业，那学习能里强，边用边学，研究了半天 kettle 然后又花费了一天时间将整个任务调通，看着画布上超复杂的 DAG，内心满是成就感。但是，维护起来太麻烦了，还老出错，效率也很慢。然后又试了第二种方案，写 Java 程序，然后顺利的 OOM，再加批次处理，最终跑通了，但效率也很慢，还要手撕 Java，编译打包，我的天！（为什么不用其他的处理方式如 Datax 和 Flink 等？身为外行人没导师领路哪懂呢。）
看着手中的两种高成本的实现方式，又看了一眼剩余的 ETL 任务数量多达 100 多个，这如何汇报呢，kettle 的方式运维复杂而且都是打工仔别人不想学，Java 的方式这相当于码一百多个系统吗，运维更加困难，哪一种方式也会被这一百多个任务折腾死。无奈的我拿着厕纸走进厕所，蹲着思考了少许，被旁边的冲水声惊醒，使用者可以简单的操作便把厕所清洁干净和开发人员使用简单的运维就完成数据 ETL 有异曲同工之妙呢！（几乎一样呢，弄过 ETL 的都懂，翔 一样的数据真是让人难上加难）厕所提供了固定的坑位及冲洗的按钮还有隐私的隔板，为使用者带来了便捷。那么说，是不是可以提供一个复用的变量、流动的数据、隔离的环境来实现大量的 ETL 运维呢？完事后回到工位立马开始梳理思路，复用的变量等于 SQL、流动的数据等于查询结果、隔离的环境等于任务的定义（资源呢？刚入门还没想到哈哈）。按着我的思路，写了一个简单的原型，发现效果还不错。说到 SQL 那是人人都会，那基于 SQL 实现一个 ETL 平台将显著地降低 ETL 任务的成本及门槛。
最终的思路是：select => Groovy 动态脚本 => upsert。
（哈哈，是不是把 select 换成 kafka 的数据源就能处理实时流数据了，我可真是个小精灵鬼，开个玩笑别当真）
其中 select 可以解决大部分的 ETL 需求（同源关联），Groovy 则来解决复杂逻辑与 NLP 接口调用以及字典映射等需求，upsert 则来解决分批次的追加与更新数据，使得增量任务可以容错。领导认可后我又用时两周陆续开发了多数据源注册、任务定义与实时监控、异常反馈与日志查询、NLP 智能字典映射、NLP 智能字段匹配、定时调度与报表等功能。此后的 100 多个批任务均由另一位业务大佬提供 sql口径来实现。这 100 个任务从平台研发到最终上线只用时了一个月，后续平稳运行至今约两年时间，期间未出现过事故。也正是这一个月的经历，让我明白了开发及托管平台对于一个企业的重要性，一劳永逸是降低成本最大的方式。（此处为 Dlink 的诞生埋下了伏笔。）
后续又与其他工具如 kettle 等作性能与成本对比，收益明显，此后在公司内推广使用，就业仅仅半年就站在讲台上为各业务组负责人讲解 ETL 平台的原理及使用，这一份肯定，坚实了我投身数据平台建设的信念，发挥个人价值的新方向。
由于我的能力得到了公司领导们的认可，我便接到了更多更重要的数据建设任务，在后续又实现了一站式大数据及数据仓库平台，将 NLP 的成果应用在数据建模与分析挖掘中，一直到 2020 年八月，我接到了一份实时数仓的需求，看着自己的成果又陷入了沉思。（此前一直在做批，没考虑到实时！天啊，大数据真是越做越难）
2020 年的九月金秋，下定决心既然要做实时需求，那就做批流一体，然后调研了 CDC、kafka、datax、spark、storm、flink，最终选择了在批流一体上更加出色的 Apache Flink，还记得那时候 Flink 版本最新还是 1.11 ，也正是 1.11 带来了更加成熟的 FlinkSQL 开发与应用。我知道，冥冥之中，这便是缘分，此后便开始了我与 Flink 的日夜陪伴。
计算层要重构为 Flink，那是不是可以直接搞实时数据中台，采集、治理、服务、BI一体化的能力输出。于是国庆节后，便带队成立研发团队，从微服务架构、前端架构、计算层架构、存储层架构、应用层架构五大块进行了设计实现。微服务采用 SpringCloud Alibaba 全家桶，包含 Nacos、Gataway、Sentinel、Redis、ELK、GPE 等应用；前端采用基于 Layui 自研封装实现了一整套企业级中台单页面框架，支持模块化复用开发（现在看来思路挺像 Ant Design Pro，可惜是个 JQuery。为什么不用 Vue ？我会用，但别人不会怎么办啊）；计算层主要分为 Datax 同构同步与 Flink 异构批流处理两方面，使用 Datax 来弥补 Flink 在批处理上的不足；存储层则选用 Hbsae、Mysql、ClickHouse 等多种库协同存储；应用层设计实现数据服务、自助查询、BI报表等模块。还有诸多模块及功能，最终我们实现了类似于微众开源的 DSS 的一站式数据中台，主要区别在于技术栈定制化。相比 DSS 的优势是可以提供从数据采集到最终应用的一站式 Devops 功能，使得我们为用户建设数仓或者中台时，可以产品化部署及无代码开发，极大的降低了项目成本与使用门槛。当然，不足之处还有很多，仍在完善中。
我们在设计及开发数据中台时，并没有模仿其他厂商的产品，我们认为只有真正给自己降低成本的功能才是我们所需要的，当然，最主要的原因是我们没有大厂强大的研发团队，人力及研发资源受限，只能先做实用的功能。（学会思考要远比学会模仿更重要）始终秉承一个思路，把所有的数据工作全都无代码化、标准化、流程化。（此处认为 FlinkSQL 不算代码）
一个数据中台，除了功能的实用与齐全，最重要的底层核心的支撑。在建设数据中台的技术栈时，深入接触了 Nacos、Datax、Flink、xxl-job等非常优秀的开源项目，这些顶尖项目为我们的中台赋予了强大的能力，所谓近朱者赤，也正是长期与开源社区交流，逐渐激发了我将业余时间投入开源事业的崇高理想。而 Dlink 的思路则来源于中台的 Dlink数据处理中心的实践。
中台最先解决的问题是数据的来源问题，离线数据方面，我们从 Dataxweb 的优秀项目中受到启发，为 Datax 研发了更加便捷的自动化运维；实时数据方面，我们打通了 kafka-connector 的管理，可以自动化部署 Mysql 及 Oracle 的 CDC 无锁任务。此外还实现了数据源中心微服务，提供数据源注册、查询、运维的能力，为后续自动化提供查询及修改数据库的能力。
然后是建模方面，我们设计了 ODS、DWD、DIM、DWS、ADS 五大层来辅助数据治理，自研了元数据中心，可以同步数据源中心采集到的元数据，也可以驱动数据源中心在存储层进行建表、清表等操作，同时也为 Datax Json 与 FlinkSQL 的生成提供了元数据依据。元数据中心可以算是中台的核心，所有的任务都会与对应的模型绑定，属实为贯穿中台的主线。基于元数据与 FlinkSQL 的异构口径，我们便可轻易得到每个任务的血缘分析，进行形成全局的血缘及影响分析。此处需要注意的是，我们摒弃了 Flink UserJar，采用 100% 的 FlinkSQL 来建设所有的异构批流任务，虽然在批处理上 Flink 受限，但批的时延要求低，又能避免我们维护两套计算框架，同时这也是批流一体的方向，我们认为既然要做批流一体，那就得破釜沉舟，勇于在艰难道路上探索。
面对大量的批任务，我最头痛的是如何配置任务调度，然而我们的批任务数量远多于流任务。所幸，既然有了全局的血缘分析，那我们就可以轻易得到所有批任务的调度 DAG 关系，为此我们又自研依赖调度引擎，可以根据自动生成的 DAG 图作为依据来完成数百任务间复杂的依赖关系的调度。依赖调度引擎根据 DAG 及相关配置如黑名单、并行度、调度策略、执行策略、钉钉报警等，可以实时进行 Datax 与 Flink 批任务的监控，并根据监控反馈的结果根据算法进行实时任务编排，任务异常及结束都会通过钉钉通知。最终我们实现将所有 400 多个批任务交由依赖调度引擎托管，避免了人工梳理 DAG 以及 Cron 的成本。说实话，哪个任务会在几点触发我们并不知道，当然我们也不需要知道，因为目前实测可靠稳定且完全信任它。目前打算后续的数据质量任务也将完全交管依赖调度。（为什么不用海豚调度？因为自研了依赖调度已经满足所有的需求，后续再看看如何集成使用海豚调度强大的能力）
面对实时流任务，我们此前使用 kafka-connector 及 debezium 来做CDC，然后通过 Flink 进行加工处理。目前 Flink-CDC 已经 2.1版本，我们正在做 FlinkSQLCDC 入库 Doris 的迁移实现。
最后便是数据的消费场景，数据服务、自助查询、BI报表老生常谈了，不再做描述。
那为什么会出现 Dlink 这个开源项目呢？
首先，Flink 的版本更新较快，我们全 SQL 的任务进行 Flink 版本升级时成本较低，但对 Flink 源码的众多改进都要重来一边，而且中台的 FlinkSQL 开发功能较为简单，不能满足 FlinkSQL 开发的需求，同时也是受开源社区的积极影响，更主要的是目前开源领域没有一个专业的 FlinkSQL 开发工具，仅有的 sql-client 又十分有限，所以我便下定决心，利用晚上的业余时间，从0手写一个完整 FlinkSQL 交互式开发平台来回馈开源社区，共建共赢。惊喜的事，现在的 Dlink 的能力远超我们数据中台的数据开发能力。
为什么不使用 zeppelin？
不得不说，Apache Zeppelin 是一个非常出色的项目，它和 Dlink 非常相似，比 Dlink 更加强大，但它的强大更适合数据科学家使用，在 FlinkSQL 方面与我们中台集成成本较高且有些大材小用。
为什么不用 Flinkx ？
同样，来自 DTStack 的 Flinkx 也是一个非常出色的项目，内置众多的连接器，便捷的同步方式，但其优势的功能对我们的中台帮助甚微，因为我们的数据源相对固定，且异构处理要求高。
为什么不用 flink-streaming-platform-web？
目前，有很多公司使用了这个优秀的开源项目，来完成 Flink 任务的运维与预警。但我们中台使用全 FlinkSQL 的实现思路，要求避免编译和打包的过程，所以不适合。
为什么不用 StreamX ？
作为都是今年开源，相伴发展的好基友 StreamX，它开源时我们已经建成了中台的 FlinkSQL 开发及提交的平台，目前 StreamX 已相对成熟，但其缺乏 FlinkSQL 的开发能力，以及对 Yarn 执行模式的支持有限，而其自动化的编译部署及任务监控、K8S支持等多个能力对于我们中台来说无法利用其优势。
为什么要用 Dlink ？
因为 Dlink 的定位是专业的交互式 FlinkSQL Studio，其 FlinkSQL 增强特性，更符合我们的需求。目前我们中台的所有 FlinkSQL 开发及调试工作全转移到 Dlink 上来，Dlink 调试通过后，将 FlinkSQL 发布到中台进行运维托管。目前有计划实现 Dlink 的运维中心，将 Flink 集群及任务运维完全托管给 Dlink，就像我们把所有的定时任务托管给依赖调度。（即：Dlink 目前的发展是由企业级生产需求直接推动的，目前已在多个企业内应用与上线）
三、发展
Dlink 历经了六个月的曲折发展，那我们就来了解一下吧。
成果
Starred：215；
Fork：94；
总提交代码行数：82346；
Contributors：4；
Commit：300
v0.1.0
Dlink 于 6 月 6 日开源并发布 0.1.0 版本，此版本主要包含交互式的 Studio、Flink 集群管理、任务管理、文档管理。
v0.2.0
Dlink 于 6 月 8 日发布 0.2.0 版本，此版本主要重构了 Dlink 的 FlinkSQL 底层引擎，支持各种 Connector。
v0.3.0
Dlink 于 7 月 27 日发布 0.3.0 版本，此版本主要包含批流 SELECT、共享会话、数据源注册、执行历史、集群作业管理、血缘分析、语句校验与逻辑检查。
v0.4.0
Dlink 于 12 月 2 日发布 0.4.0 版本，此版本主要包含Yarn的所有模式提交支持、sql 自动提示与补全、Flink 版本扩展、集群配置管理、Jar 管理、savepoint 管理、set 语法支持等功能。
v0.5.0-SNAPSHOT
Dlink 将于 2022 年 1 月中旬发布 0.5.0，目前 main 具备的功能有 K8S 提交支持、外部数据源查询与执行、OpenAPI、官网文档建立、FlinkSQLEnv 方言实现、各种应用实践等。
四、应用
Dlink 作为专业的 FlinkSQL Studio，它具备较多的应用场景。
交互式 FlinkSQL 开发与调试
多数企业内部大都建立了自己的 Flink 任务托管平台，在 FlinkSQL 的趋势下，其 sql 的开发与调试的需求日益显现。Dlink 则可以提供开源领域最专业的 FlinkSQL 开发与调试环境，避免盲写口径带来的诸多问题与高成本。
在部署 Dlink 之后，通过搭建相关外部执行环境，如 Yarn-Session，可以使用共享会话功能或者 FlinkSQLeEnv 来持久化 Flink 的 Catalog；通过 Select 实时预览功能，为 FlinkSQL 进行 OLAP 或子句查询提供了强力支持；基于文档与上下文的自动提示与补全则可以快速辅助编写 sql，避免单词书写错误、官网翻 UDF、Ctrl C V set 配置等；语法片段则可以实现全局变量或者sql片段，使得sql语句可以被复用；CREATE AGGTABLE 则可以提供目前 SQL API 不支持的表值聚合函数的定义与使用；语法校验与逻辑检查则可以用真实环境来校验语句，及指导修改的能力，做到通过即用的效果；支持血缘分析与查看 JobPlan；支持其他数据源的 SQL 查询与执行的能力，例如执行 Mysql、Doris 等的语句。
可见，Dlink 与企业内部的平台以及其他开源项目如 StreamX 等并不冲突，反而可以相辅相成，互相协作。
未来 Dlink 将支持元数据生成 FlinkSQL 、元数据预装载 Catalog、传统 SQL 翻译成 FlinkSQL、UDF 在线开发等非常实用的功能。
Flink 任务提交与定时调度
Dlink 可以提交 FlinkSQL 和 Jar 到指定的集群，对于所有任务，可以将任务一键提交并可以通过集群进程进行任务的 SavePoint 和 Cancel 操作，并对 SavePoint 进行自动化管理及恢复。
Dlink 提供了 submitTask 的执行接口，参数只需要一个 id，即可通过 xxljob、DolphinScheduler 等调度平台的 Http 调度功能来调度 Dlink 提交任务，进而实现 Flink 批任务的定时调度。
Dlink 也提供了其他功能的接口，如 executeSql 接口，第三方系统只需要传一个简单的 json 即可完成各种任务的提交，不需要在 Dlink 进行任务开发操作，当作 Server 使用，其他接口请查阅 Readme。
未来 Dlink 将实现上文所述的运维中心与依赖调度能力。
搭建实时计算平台
Dlink 的发展路线将围绕实时计算平台的需求进行，使其可以胜任企业内实时任务从开发到运维的一体化管理，由于其架构与实现易扩展、Springboot Ant Design Pro、Flink SDK 等，使得企业基于它建立与迭代自己的实时计算平台成本较低，目前已有多家企业内部基于 Dlink 来定制自己的需求并计划回馈给社区。
五、前景
Readme 的项目介绍已经写的明明白白，本文再稍作总结。
基于 Apache Flink 解耦开发，顺应 FlinkSQL 批流一体
Dlink 的功能实现完全基于 Apache Flink 源码二次开发，并解耦实现定制，使其具备不同版本 Flink 的兼容性的同时，还能具备自身的增强。Flink 绝大多数功能及扩展 Dlink 都支持，且其内部信息都可以通过 Dlink 来获取到并展示到前端。可以这么说，Dlink 是开源领域中最贴近 Flink 实现的项目，而且在未来 FlinkSQL 批流一体的趋势下，它正好可以来弥补 FlinkSQL 在开发交互上的缺陷，降低使用成本与门槛。所以说，它很容易站到巨人肩膀上创新，也直接推动 Flink 发展。
对标企业级需求发展
Dlink 和传统的开源项目不同，一般开源项目只为在某一领域提供强大的能力支撑，企业应用还需要集成成本。而 Dlink 的设计与实现则直接由企业生产中的需求推动与指导，使其可以开箱即用，降低建设成本，同时依赖企业环境快速发展。
具备自身创新能力
Dlink 的设计与实现均以创新的方向为指引，使其未来可以在众多开源项目中脱颖而出，同时可以分享思路及技术实现，为开源提供更多的可能。
具备外部平台的对接潜力
Dlink 提供了自身 Flink 增强引擎，并提供了大多数功能的 OpenAPI，未来也在计划实现 dlink-jdbc 驱动。以上使得 Dlink 可以对接到 DSS、DolphinScheduler 等生态提供了可能。该工作也是 Dlink 发展规划中即将进行的工作。
六、感谢
今朝今日，能有这么一份充实的年终总结，要感谢我的同事 @lewnn、以及开源事业的伙伴 @coderTomato、@walkhan 等其他社区伙伴的支持，感谢 Linkis @wushengyeyouya 大佬的指导与支持，感谢 StreamX @benjobs @ AI-assad 大佬的陪伴与支持。
当然，十分感谢 Apache Flink 所有贡献者，没有他们便没有今天的 Dlink。
感谢 Mybatis Plus、ant-design-pro、Monaco Editor 等其他优秀项目的支持。
感谢 JetBrains 提供的免费开源 License 赞助。
七、结语
写完整篇年终总结，发现居然一点了，从八点开始，写了五个小时我也是惊了，那只能 2022 年元旦送给大家当作礼物了，希望本篇总结可以让大家了解Dlink 的前生今世以及未来可期~
