我和Apache DolphinScheduler的这一年

Apache DolphinScheduler，为Apache开源项目, 简称”DS”, 中文名 “小海豚调度”（海豚聪明、人性化，又左右脑可互相换班，终生不用睡觉）。希望 DolphinScheduler 就像它的名字一样，成为一个“开箱即用”的灵活易用的调度系统。社区发展非常迅速，目前已有像IBM、腾讯、美团、360等 400+ 公司在生产上使用，代码+文档贡献者近200位，社区用户4000 +人。

主人翁介绍

姓名：张伯毅
某上市公司大数据工程师,目前主要负责大数据平台研发.技术控,喜欢阅读源码,CSDN博客专家.

DolphinScheduler已经一岁了,很荣幸与它一起成长, 2020年就剩几天了,记录一下,就当是对这一年多的成长做了一个梳理
(开启碎碎念模式…).

一. 相遇

2019年10月公司决定开展中台方面的业务,基于大数据体系,要搞一套从数据接入到数据输出一站式的"全家桶". 在大数据体系,其实各项技术已经相对成熟了. 之前公司用的技术栈是HDP体系,所以一直使用Oozie作为调度系统. 在调研阶段,出于各种原因吧,但是我觉得Oozie并不是很好用,比如在考虑到定制开发的时候,觉得前端开发成本有点高以及最重要的是觉得在DAG可视化方面并不是很好等等各种原因,所以就开始寻找其他的解决方案.
机缘巧合之下,我在gitee上找到了人气爆棚的Easy Scheduler (DolphinScheduler的前身). 然后就被它的两张图所吸引.

一种心动的感觉,不慌不慌,稳住. 再看技术体系:

后端: SpringBoot (2.x)
前端: VUE
编译: Maven(3.3+) ,
元数据存储: Mysql5.5+
分布式无中心化设计: ZooKeeper(3.4.6+)

我去,都是主流技术栈,二次开发基本零门槛. 再看一下其他的特性,

• 以DAG图的方式将Task按照任务的依赖关系关联起来，可实时可视化监控任务的运行状态
• 支持丰富的任务类型：Shell、MR、Spark、SQL(mysql、postgresql、hive、sparksql),Python,Sub_Process、Procedure等
• 支持工作流定时调度、依赖调度、手动调度、手动暂停/停止/恢复，同时支持失败重试/告警、从指定节点恢复失败、Kill任务等操作
• 支持工作流优先级、任务优先级及任务的故障转移及任务超时告警/失败
• 支持工作流全局参数及节点自定义参数设置
• 支持资源文件的在线上传/下载，管理等，支持在线文件创建、编辑
• 支持任务日志在线查看及滚动、在线下载日志等
• 实现集群HA，通过Zookeeper实现Master集群和Worker集群去中心化
• 支持对Master/Worker cpu load，memory，cpu在线查看
• 支持工作流运行历史树形/甘特图展示、支持任务状态统计、流程状态统计
• 支持补数
• 支持多租户
• 支持国际化

O(∩_∩)O哈哈~ , 就这样一见钟情 …

---

二. 相识

接下来,就是考虑怎么跟领导推荐这个技术,当时也调研了一些其他的技术,比如NIFI, Azkaban,AirFlow等等.
首先排除掉的就是NIFI和AirFlow. 不是这两个不好,是一些其他的原因.
NIFI是做的最完善的,但是太重了,出问题用源码定位费劲. 维护/二开成本真要命.
AirFlow是Python写的,因为公司的人基本都是JAVA体系,考虑到这点就直接放弃了.

剩下的无非就是做对比了,出一份报告,然后跟领导汇报.虽然我个人是推崇DS的,
但是DS比较特殊.毕竟是草根,也没有一些大厂背书,所以领导这边也在犹豫.
转机:
2019年12月27日DolphinScheduler发布了第一个 apache版本,真正成为中国在apache中为数不多的开源项目之一
背靠大树好乘凉,最终调度系统决定采用DolphinScheduler作为技术原型.

二. 相知

人生是由无数个第一次组成的,总有那么一些事情值得回忆~

2.1. 贡献PR

2020年3月31日,第一次PR被merge . 虽然只是解决了一个小小的问题,对我来说确是一个从0到1的开始. 这是我走进开源的第一步.

更多的可能是一些心态上的转变, 平时虽然读过一些项目的源码,但是从来没有考虑贡献过自己的PR,最多也就是写写博客记录一下,便于以后查找. 当看到自己的PR被merge的时候. 瞬间成就感满满,还开心的发了一个朋友圈mark了一下.
技术人嘛,快乐就是这么简单.

2.2. 文章入选公众号

2020年过年因为疫情的原因,在家办公. ( ps :所以这也是我自从毕业之后,陪爸妈最久的一次. 待久了真容易遭嫌弃. )
在家搞调度的设计文档,需要工作流定义创建时有关于task任务数据结构的说明.当前的版本工作流里面的DAG图是拼装一个很大很大的Json字符串, 我需要对这里数据做一个梳理,可以给外部系统调用. 但是官方没有,就自己梳理了一下,习惯性的写了一篇文章,方便以后查找. 正好当时微信群里有一个哥们也需要,就共享了一下. 官方在征求我的同意之后,转发到了官方[海豚调度]公众号上. 开心是肯定的,不过想起来很久之前立下的要写公众要的flag,脸疼.
现在,更疼…

2.3. 基于源码开发

设计完成了,肯定是要进入到开发阶段的 ,当时有两个版本可选一个是1.2.1版本,另一个是1.3.0版本, 不过1.3.0版本正在开发中,还不稳定.
但是1.3.0相对比1.2.1多了很多新特性. 比如: 重构了worker架构.资源文件支持目录创建,新增了条件分支、Sqoop、DataX任务类型的节点.工作流定义支持移动/导入/导出等等多个特性, 所以就选了1.3.0版本进行开发.
因为1.3.0的worker进行了重构,所以又得重新过一遍源码,重构之后worker节点确实简洁了很多. 就是看master类型节点的时候有点费劲.
翻出来之前看master源码画的图,看着依旧觉得代码有点绕.庆幸,官方下一个阶段要做的事情就是对master进行重构,欢迎加入哦.

贴一张之前分析master的图代码逻辑图:

2.4. 贡献文档

大多数人应该都知道DS的github代码库的地址, 但是很少知道 DolphinScheduler文档库的地址.
随着DolphinScheduler的用户不断的增多,文档的缺失成为了DolphinScheduler的一个短板,所以代老板(DolphinScheduler PPMC) 在开发群里提出文档的需求,大家有空的话,多贡献点文档, 为此还单独发了一个issue,长期置顶了很久,有需要啥文档的小伙伴可以过去留言.

因为之前写过关于task的数据结构的文档,就先报名写了一篇任务总体存储结构.

当然随后又写了几篇.有一件事让我印象深刻[ 为了一段文档,我来回改了好几次,我得吐槽一下代老板…].
事情是这样滴.

有一阵用户老问关于1.3.x版本worker分组创建和资源中心如何配置的问题. 所以我就想着把文档完善一下.

先写了worker分组如何配置文档, 然后又写的资源中心如何配置. 因为改的是同一个文件,所以合并到同一个pr里面了.

代老板反馈: 写的不错, 最好能拆开分两个PR进行提交. 修改 + 1

正常在提交的代码的时候,正常来说首先要先提一个issue,每个PR用于处理issue中的问题, 每个PR只能处理一个问题.如果有多个问题,需要拆分为多个PR **

代老板反馈: 资源中心配置的时候, 你关于kerbos的配置怎么给删了 ? 现在用kerbos的人还是蛮多的,把这个加上吧. 修改 + 1

个人觉得用kerbos的人比较少,直接就把kerbos部分的配置就先删了,只保留了几条非kerbos配置…

代老板反馈: 你咋加了这么多参数 ? 这样不够直观啊 . 修改 + 1

我把关于hdfs的大部分需要改的配置都列上了,嗯,这是嫌多了… _

代老板反馈: 中文合并了,刚翻译的英文用户手册兄弟检查一下,看看是不是也有这个问题 修改 + 1

同步修改英文的文档, 蹭了一个PR O(∩_∩)O哈哈~

思考: 是不是有些事情可以做的更好,不只是追求95% , 而是99% ~

2.5. 配置checkstyle

每一个人写代码的时候都有自己的习惯,开源参与的人比较多,随着时间的推移,但是如何代码规范一直是一个问题,之前DolphinScheduler社区是采用sonarcloud做一些初步的验证,比如代码的UT覆盖率必须到33%以上, 使用sonarcloud做code smell检查. 然后必须有两个review ( + 1) 之后,才会被merge到代码库.但是代码的风格不好控制, 比如代码的缩进,空格,换行的数量等等的代码风格上的问题. 后来一个小伙伴贡献了一个code style 检查约束.
使用sonarcloud自动检查,并根据配置的代码风格给与提示.之前我一直用阿里的代码检查工具, 这个还真是第一次用,配置这个当时花了不少时间.

其实不管用什么工具,在代码的质量上开始做要求并给与规范化的限定, 这不是一件好事么~

参考的配置 记录一下,方便以后自己查找:

checkstyle 参考[https://checkstyle.sourceforge.io/]是一种帮助开发者编写遵循编码规范的 Java 代码开发工具。它可以自动化检查 Java 代码的方法以及格式，使得开发者不用再做这项无聊（但很重要）的任务。它非常适合于希望实施编码标准的项目。

在 DolphinScheduler 中配置 checkstyle 和 code-style 的方式：

.checkstyle 和 code-style 配置文件
checkstyle: https://github.com/apache/incubator-dolphinscheduler/blob/dev/style/checkstyle.xml
code-style: https://github.com/apache/incubator-dolphinscheduler/blob/dev/style/intellij-java-code-style.xml

2.6. 群管理

9月初,代老板在开发群里的说 DolphinScheduler已经有10来个群了, 想找一些人帮忙代为管理,正好我在用户群里面,就主动报了名,感谢信任.我顺利成为了二,五,七这三个用户群里的管理员. DolphinScheduler的发展很快,前一阵又开通了DolphinScheduler的第八个用户群. 当时新任的管理员问需要注意哪些事项,我就梳理了一些,发了出来.

1.管理一下群里的日常.给大家提供一个积极向上的环境.
2.新人审核,邀请时验证信息需要填写验证信息“公司+职位+姓名” 或 “学校+姓名”。(有效过滤广告神器)
3.回答问题,解决用户遇到的问题,当初我就是在社区大佬的帮助下走过来的,投桃报李.
4.微信群的特权只有国内的用户享有. apache组织对微信群是不提倡的,一般只是认可issue或者邮件. 微信记录不利于知识的沉淀,考虑到社区的良性发展,需要引导发Issue, 积累久了,有问题可以做到搜索issue直接获取答案.简单高效.毕竟微信群里的答疑的人都是义务性质的,都有自己的工作要忙.回复的时效性没有办法保障. 而issue会有专人来处理,肯定不会遗漏…
5.群里发招聘信息的让他配100元红包，10分钟内不发的也可以送飞

哈哈,第五条是代老板给加的,我专门拿小本本记下来的 …

三. 相守

自从参与了DolphinScheduler之后,觉得社区的技术氛围会特别好,尤其是一个技术人,跟一堆牛人在一起,相互成长是一件蛮幸福的事情.
比如最近一阵官方有大动作,比如重构工作流定义数据结构, 重构master服务. 光线上的架构讨论会就开了四次. 一群技术人在聊架构,聊设计,分享思路这个是平时很难遇到的. 在讨论的过程中,真的是考验知识储备灵活运用的时刻.收获良多.越发的认可一句话:
一个人可能会走的很快,但是一群人才能走的更远.

PS: 推荐一项福利,对DolphinScheduler有过贡献的人,可以进入到开发群,遇到问题可以优先帮忙解决.我当时搞定制开发的时候,就收到过很多大佬的帮助,重要的问题可以获取到第一手资料,及时反馈到生产.

最后秀两张Apache DolphinScheduler Group 8 群 @ SUN 同学画的两张工作流的图,谁说程序员不懂浪漫~

---

欢迎加入APachec dolphinscheduler社区

https://github.com/apache/incubator-dolphinscheduler (请记得fork和star)
订阅邮件列表
用自己的邮箱向dev-subscribe@dolphinscheduler.apache.org发送一封邮件，主题和内容任意。
接收确认邮件并回复。完成步骤1后，将收到一封来自dev-help@dolphinscheduler.apache.org的确认邮件（如未收到，请确认邮件是否被自动归入垃圾邮件、推广邮件、订阅邮件等文件夹）。然后直接回复该邮件，或点击邮件里的链接快捷回复即可，主题和内容任意。
接收欢迎邮件。完成以上步骤后，会收到一封主题为WELCOME to dev@dolphinscheduler.apache.org的欢迎邮件，至此已成功订阅Apache DolphinScheduler（Incubating）的邮件列表。