近日 , 观远数据联合创始人 & 首席架构师吴宝琪 , 作为 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 更易用 , 更好看 ! ( 更好看也是很重要的 ), 尤其是如下三点 :
• 实时 Metrics 支持 ( 实时看到 pipeline 的运行信息 , 而且是可视化的图形展示 )
• 代码写的很赞 !
• 插件化设计赞 ! 编写自定义插件更容易 !

虽然 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!