背景
没错，本文的主人翁就是那个在多个 DolphinScheduler 用户群超级活跃，”孜孜不倦“ 地给用户各种答疑的小伙，如果你在群里问过问题，伯毅多半概率回答过，哈哈，今天就是这样一个不仅贡献代码而且愿意帮助别人成长的小伙子的心路历程分享给大家。
主人翁：张伯毅，某上市公司大数据工程师, 目前主要负责大数据平台研发. 技术控,喜欢阅读源码, CSDN 博客专家.
DolphinScheduler 从开源算起马上 2 岁了,很荣幸与它一起成长, 离春节就剩几天了, 记录一下, 就当是对这一年多的成长做了一个回忆。
01
相遇
2019 年 10 月公司决定开展中台方面的业务,基于大数据体系,要搞一套从数据接入到数据输出一站式的 "全家桶". 在大数据体系,其实各项技术已经相对成熟了. 之前公司用的技术栈是 HDP 体系,所以一直使用 Oozie 作为调度系统. 在调研阶段,出于各种原因吧,但是我觉得 Oozie 并不是很好用,比如在考虑到定制开发的时候,觉得前端开发成本有点高以及最重要的是觉得在 DAG 可视化方面并不是很好等等各种原因,所以就开始寻找其他的解决方案.
机缘巧合之下,我在 Gitee 上找到了人气爆棚的 Easy Scheduler (DolphinScheduler的前身). 然后就被它的两张图所吸引.
当时的界面，至今收藏
一种心动的感觉,不慌不慌,稳住. 再看技术体系:
整体采用分布式无中心化设计: ZooKeeper(3.4.6+)
元数据存储: Mysql5.5+
前端: VUE
后端: Java, 也用到了很多优秀的项目，比如 google guava/guice, grpc, netty, quartz等
我去,都是主流技术栈,二次开发基本零门槛. 再看一下其他的特性,
以DAG图的方式将Task按照任务的依赖关系关联起来，可实时可视化监控任务的运行状态
支持丰富的任务类型：Shell、MR、Spark、SQL(mysql、postgresql、hive、sparksql), Python, Sub_Process、Procedure 、Datax、Sqoop、Waterdrop 等
支持工作流定时调度、依赖调度、手动调度、手动暂停/停止/恢复，同时支持失败重试/告警、从指定节点恢复失败、Kill任务等操作
支持工作流优先级、任务优先级及任务的故障转移及任务超时告警/失败
支持工作流全局参数及节点自定义参数设置
支持资源文件的在线上传/下载，管理等，支持在线文件创建、编辑
支持任务日志在线查看及滚动、在线下载日志等
实现集群HA，通过 Zookeeper 实现 Master 集群和 Worker 集群去中心化
支持对 Master/Worker cpu load，memory，cpu 在线查看
支持工作流运行历史树形/甘特图展示、支持任务状态统计、流程状态统计
支持补数
支持多租户
支持国际化
O(∩_∩)O哈哈~ , 就这样一见钟情 …
02
相识
接下来,就是考虑怎么跟领导推荐这个技术,当时也调研了一些其他的技术,比如 NIFI, Azkaban, AirFlow 等等.
首先排除掉的就是 NIFI 和 AirFlow. 不是这两个不好,是一些其他的原因.
NIFI 是做的最完善的, 但是太重了, 出问题用源码定位费劲. 维护/二开成本真要命.
AirFlow 是 Python 写的, 因为公司的人基本都是 JAVA 体系, 考虑到这点就直接放弃了.
剩下的无非就是做对比了, 出一份报告, 然后跟领导汇报. 虽然我个人是推崇 DS 的,
但是 DS 比较特殊. 毕竟是草根, 也没有一些大厂背书,所以领导这边也在犹豫.
转机:
2019 年 12 月 27 日 DolphinScheduler 发布了第一个 apache 版本, 真正成为中国在 apache 中为数不多的开源项目之一
背靠大树好乘凉,最终调度系统决定采用 DolphinScheduler 作为技术原型.
03
相知
人生是由无数个第一次组成的,总有那么一些事情值得回忆~
3.1. 贡献PR
2020 年 3 月 31 日, 第一次 PR 被 merge . 虽然只是解决了一个小小的问题,对我来说确是一个从 0 到 1 的开始. 这是我走进开源的第一步.
更多的可能是一些心态上的转变, 平时虽然读过一些项目的源码, 但是从来没有考虑贡献过自己的 PR, 最多也就是写写博客记录一下, 便于以后查找. 当看到自己的PR 被 merge 的时候. 瞬间成就感满满,还开心的发了一个朋友圈 mark 了一下.
技术人嘛, 快乐就是这么简单.
3.2. 文章入选公众号
2020 年过年因为疫情的原因,在家办公. ( ps :所以这也是我自从毕业之后,陪爸妈最久的一次. 待久了真容易遭嫌弃. )
在家搞调度的设计文档,需要工作流定义创建时有关于 task 任务数据结构的说明.当前的版本工作流里面的 DAG 图是拼装一个很大很大的 Json 字符串, 我需要对这里数据做一个梳理,可以给外部系统调用. 但是官方没有,就自己梳理了一下,习惯性的写了一篇文章, 方便以后查找. 正好当时微信群里有一个哥们也需要,就共享了一下. 官方在征求我的同意之后,转发到了官方 [海豚调度] 公众号上. 开心是肯定的,不过想起来很久之前立下的要写公众要的 flag, 脸疼.
现在, 更疼…
3.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 的图代码逻辑图:
3.4. 贡献文档
大多数人应该都知道 DS 的 github 代码库的地址, 但是很少知道 DolphinScheduler文档库 的地址.
随着 DolphinScheduler 的用户不断的增多,文档的缺失成为了 DolphinScheduler 的一个短板,所以 Lidong Dai(DolphinScheduler PPMC) 在开发群里提出文档的需求, 大家有空的话, 多贡献点文档, 为此还单独发了一个 issue, 长期置顶了很久, 有需要啥文档的小伙伴可以过去留言.
因为之前写过关于 Task 的数据结构的文档, 就先报名写了一篇 任务总体存储结构.
当然随后又写了几篇. 有一件事让我印象深刻 [ 为了一段文档,我来回改了好几次, 我得吐槽一下…].
事情是这样滴.
有一阵用户老问关于 1.3.x 版本 worker 分组创建和资源中心如何配置的问题. 所以我就想着把文档完善一下.
先写了 worker 分组如何配置文档, 然后又写的资源中心如何配置. 因为改的是同一个文件, 所以合并到同一个 pr 里面了.
Lidong 反馈: 写的不错, 最好能拆开分两个PR进行提交. 修改 + 1
正常在提交的代码时,正常来说首先要先提一个 issue,每个 PR 用于处理 issue
中的问题, 每个 PR 只能处理一个问题. 如果有多个问题,需要拆分为多个 PR
又反馈: 资源中心配置的时候, 你关于 kerberos 的配置怎么给删了 ? 现在用 kerberos 的人还是蛮多的, 把这个加上吧. 修改 + 1
个人觉得用 kerberos 的人比较少,直接就把 kerberos 部分的配置就先删了,
只保留了几条非 kerberos 配置…
又反馈: 你咋加了这么多参数 ? 这样不够直观啊 . 修改 + 1
我把关于 hdfs 的大部分需要改的配置都列上了, 嗯, 这是嫌多了… _
又反馈: 中文合并了, 刚翻译的英文用户手册兄弟检查一下, 看看是不是也有这个问题 修改 + 1
同步修改英文的文档, 蹭了一个PR O(∩_∩)O哈哈~
思考: 是不是有些事情可以做的更好, 不只是追求 95% , 而是 99% . 在与社区的交流中，你始终能感受的到的是他们的热情并且追求进步 ~
3.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
3.6. 群管理
9 月初, 有伙伴在开发群里的说 DolphinScheduler 已经有 10 来个群了, 想找一些人帮忙代为管理, 正好我在用户群里面,就主动报了名, 感谢信任. 我顺利成为了二,五,七这三个用户群里的管理员. DolphinScheduler 的发展很快,前一阵又开通了 DolphinScheduler 的第八个用户群(8 群也已 300+ 人了). 当新任的管理员问需要注意哪些事项, 我就梳理了一些, 发了出来.
1.管理一下群里的日常.给大家提供一个积极向上的环境.
2.新人审核,邀请时验证信息需要填写验证信息“公司+职位+姓名” 。(有效过滤广告神器)
3.回答问题,解决用户遇到的问题,当初我就是在社区大佬的帮助下走过来的,投桃报李.
4.微信群的特权只有国内的用户享有. apache 组织对微信群是不提倡的,
一般只是认可 issue 或者邮件. 微信记录不利于知识的沉淀,
考虑到社区的良性发展,需要引导发Issue, 积累久了,
有问题可以做到搜索issue直接获取答案.简单高效.
毕竟微信群里的答疑的人都是义务性质的,都有自己的工作要忙.
回复的时效性没有办法保障. 而issue会有专人来处理,肯定不会遗漏…
5.群里发招聘信息的让他配 100 元红包，10 分钟内不发的也可以送飞
哈哈,第五条是社区给加的, 我专门拿小本本记下来的 …
03
相守
自从参与了 DolphinScheduler 之后, 觉得社区的技术氛围会特别好, 尤其是一个技术人, 跟一堆牛人在一起, 相互成长是一件蛮幸福的事情.
比如最近一阵官方有大动作, 比如重构工作流定义数据结构, 重构 master 服务. 光线上的架构讨论会就开了四次. 一群技术人在聊架构, 聊设计, 分享思路这个是平时很难遇到的. 在讨论的过程中, 真的是考验知识储备灵活运用的时刻. 收获良多. 越发的认可一句话:
一个人可能会走的很快,但是一群人才能走的更远.
PS: 推荐一项福利, 对 DolphinScheduler 有过贡献的人, 可以进入到开发群, 遇到问题可以优先帮忙解决. 我当时搞定制开发的时候, 就收到过很多大佬的帮助, 重要的问题可以获取到第一手资料, 及时反馈到生产.
最后秀两张 Apache DolphinScheduler Group 8 群 @ SUN 同学画的两张工作流的图,谁说程序员不懂浪漫~
04
后记
至此，我与开源社区这一年的故事就讲完了，期待与您的相遇，让我们一起携手，让本土开源一起壮大。我在 DolphinScheduler 社区等您来。
