从开源使用者到Apache PPMC之路

近日, 观远数据联合创始人&首席架构师吴宝琪, 做为 Apache DolphinScheduler 的PPMC参加了 Apache DolphinScheduler 的首届用户大会, 并在大会上作了《从开源使用者到Apache PPMC之路》的分享, 如下是分享的主要内容。

---

Table of Contents
• 1. Part 1. 缘起
o 1.1. 阶段1, Airflow自己是很是强大的, 咱们也作了大量的Operator扩展
o 1.2. 阶段2, Apache NiFi 和 StreamSets Data Collector (简称 SDC)
o 1.3. 阶段2.5, Kettle 和 Talend DI
o 1.4. 阶段3, 开始调研各类开源调度项目, 并最终选定 DolphinScheduler
• 2. Part 2. 开工
o 2.1. 在项目中作的贡献
o 2.2. 简单谈谈为何贡献开源
o 2.3. 开源的收获
• 3. Part 3. 将来
o 3.1. 打算探索的一些功能

---

1 Part 1. 缘起

观远数据是一家BI + AI的数据科技公司. 好比: 对于BI(Business Intelligence,商业智能)来讲, 并不简单的是酷炫的可视化, 而是会涉及到大量的外部系统对接和数据融合, 这里都会牵扯到复杂的数据清洗和任务调度. 虽然咱们的BI中也内置了轻量的数据处理模块, 可是, 对于更复杂的任务调度/补数据等需求, 以及AI产品中的一些数据清洗/特征工程/调度等, 咱们也在寻找更适合的开源工具.

1.1 阶段1, Airflow自己是很是强大的, 咱们也作了大量的Operator扩展

不过Airflow有个主要问题: "太依赖于Python编程, 须要作大量的Python扩展, 任务的依赖编排都要经过写Python实现"
而咱们对于调度工具的主要定位是: 须要顾问同事也能实施. 对于不会编程序的顾问同事来讲, 要求每一个人都写Python太难了. 因此咱们得出的结论: 须要一个有不错的可视化界面的web工具, 不能假设用户都会编程序.

1.2 阶段2, Apache NiFi 和 StreamSets Data Collector (简称 SDC)

主要结论:
• Nifi支持非结构化数据, 功能也比SDC多
• 可是: StreamSets SDC 更易用, 更好看! (更好看也是很重要的), 尤为是以下三点:
o 实时Metrics支持 (实时看到pipeline的运行信息, 并且是可视化的图形展现)
o 代码写的很赞!
o 插件化设计赞! 编写自定义插件更容易!
虽然SDC很吸引人, 不过SDC主要场景仍是实时数据抽取转化. BI还是离线定时任务为主, 因此不是彻底匹配.

1.3 阶段2.5, Kettle 和 Talend DI

主要结论:
• 这两个都是传统的ETL, 调度功能都偏弱 (注: Talend DI是评估的开源版本, 商业版本有更复杂的调度能力, 可是价格不菲)
• 插件扩展都有点复杂
• Talend 能够把job翻译成 Java工程, 赞! (这样不用每台机器都安装 Talend, 能够直接跑Jar包程序, 不过也有问题, 好比: 不少报错都是java的exception, 不少自定义扩展都须要使用者会基本的Java)

可是这两个项目的代码都十分复杂, 阅读/掌握代码基本上太难, 而对因而否使用一个开源项目的一个很重要的考量指标是: 是否本身公司的同事能掌握这个项目.

1.4 阶段3, 开始调研各类开源调度项目, 并最终选定 DolphinScheduler

主要结论: DolphinScheduler (加入Apache前叫 EasyScheduler) 更适合咱们的场景. 主要缘由:
• Apache License
• Process/Task的definition 和 instance 分离, 支持补数据, 概念清晰. 路走对了, 就不怕远
• 有还不错的图形化配置界面, 而不是什么都要写json配置, 或者python设置DAG等.
• 基于JVM, 之后方便Java Shop来扩展

2 Part 2. 开工

做为公司的首席架构师, 一部分的工做是思考和尝试一些公司的将来方向, 因此, 开始对于DolphinScheduler的贡献公司内部主要是我一我的奋斗 (固然我不是一我的, 我是和开源社区的不少不少小伙伴们一块儿奋斗), 不过如今公司内部也有其余伙伴在和我一块儿为开源作贡献.

2.1 在项目中作的贡献

主要的方式是: 从简单到复杂, 逐步融入社区

最开始:
• 熟悉项目代码, 搭建本地环境
• 修复一些小bug

接下来能够作一些简单的功能:
• 增长 Clickhouse 支持
• 增长 Oracle 支持
• 增长 SQL Server支持

接下来就能够作一些更复杂些的功能了:
• SQL任务增长 Pre/Post Statement支持
• 支持Minio/S3 做为”资源中心”的文件存储
• 支持CombinedServer: 多个Server一块儿启动, 方便本地开发
• 用 Sifting Appender 解决 task 日志错乱问题

固然, 贡献不是光指合并的pull request. 而还包括:
• Pull Request Review
• 社区回答问题
• 也包括: 来 User Meeting 分享, 宣传DolphinScheduler等 :)

2.2 简单谈谈为何贡献开源

为开源作贡献也是一个必然的选择. 我以前在前公司就遇到过这么一个项目: (具体的公司/项目名就隐藏了)

开始一切都很美好,
• 咱们基于某个开源软件, 实现了一个功能
• 在上面作了大量的扩展,大量的修改

直到某一天, PM过来讲:
• 这个软件已经由 1.x 升级到了 2.0
• 这个 2.0 作了大量的代码重构, 性能大幅提高
• 支持新的国际标准, 有不少新的script功能!
• 我们来升级支持一下吧

结果, 负责升级的同事升级了6个月. 他天天作的工做就是以下三件事:
• 编译C++到各个平台, 修复各类build error
• 仔细学习《Modern C++ Design》 这本书来了解各类特殊的C++ template写法和模式
• 在版本控制软件中, 查看和了解每一个commit的缘由/修改, 而后试着应用到新的版本上

后来, 咱们反思, 除了C++和跨平台编译等缘由外, 另外一个重要结论就是: 对于使用的开源软件, 必定要千方百计把扩展/bugfix 合并到官方repository中, 这样长期来看会大大减小维护成本.

2.3 开源的收获

开源软件发展到今天
• 已经再也不只是极客的我的项目为主了
• 开源这十年发展太快了, 开源是将来的趋势
• 开源和商业自己并不矛盾, 开源只是商业的一种形式
• 代码只是开源的一小部分, 更重要的实际上是围绕这个开源项目的社区
为开源作贡献, 不仅是能得到到apache邮箱, 也能同时:
• 提升代码质量, 写更多注释 (内心想着, 我写的代码, 未来要被成千上万人围观)
• 方案须要更通用
• 志同道合的朋友们
• 更多的使用者, 更快发现问题
• 对于公司来讲, 也更利于公司吸引人才

3 Part 3. 将来

3.1 打算探索的一些功能
• 插件化
• 相似于Airflow的Pool功能, 限制同时执行的指定任务个数
• 工做流调度增长基于 时间触发, 复杂规则, webhook触发等机制
• Task Metrics支持, 实时查看每一个组件的一些metrics (好比: 输入记录数, 输出记录数, 执行时间. 以及近30次运行的变化曲线等)
• 工做流定义, 资源文件 等的 简单多版本管理,(查看历史, 回滚到指定版本)
• 数据血缘关系(data lineage)上报组件

我心中的DolphinScheduler (不负责任瞎想)将来架构, 固然, 这个只是一个设想, DolphinScheduler目前架构不是如此, 将来也不会彻底同样, 只是我的的一种对于通用数据调度平台的想法

以上是我对于参与DolphinScheduler开源项目的经历的简单分享, 由于主要面向技术人员, 因此没有介绍太多比较虚的项目背景, 项目意义, 将来方向等内容. 提早剧透一下, 根据文章反馈, 将来适当时间也会介绍一些观远怎么基于DolphinScheduler作的一些将来产品. Stay Tuned!