摘要：本文整理自阿里云 EMR 数据开发团队负责人孙一凡（Evans 忆梵），在 Spark&DS Meetup 的分享。本篇内容主要分为四个部分：
- 我们是谁
- 为什么选择 DolphinScheduler
- 社区贡献
- 商业化实践
一、我们是谁
我们团队的日常工作主要包含以下两部分内容。
- 第一，深度参与和贡献大数据开发开源项目。在过去两年的时间里，我们参与了很多开源项目。比如在交互式数据开发领域，重点参与了 Zeppelin 和 Jupyter；在调度系统领域，投入了今天主题要提到的 DS，以及当前在全球范围内最流行的调度系统 Airflow。
- 第二，基于开源组件打造云原生大数据开发产品。EMR 产品线当中的数据开发组件。无论是目前正处于邀测状态的 EMR Notebook，还是即将进入邀测 EMR Workflow，都是我们基于开源项目实现的云原生 serverless 大数据开发服务。
二、为什么选择 DolphinScheduler
在日常工作当中，对于各类开源引擎的评估是非常重要的前置工作，这也决定了我们最终商业化产品的 roadmap。所以在正式选择 DS 社区之前，我们对市面上各类大数据的调度引擎都进行了非常详尽的评估和对比。
除了 DS 外，我们还选择了三种大数据调度项目，比如在全球范围内拥有最多用户基数的 Airflow，以及 Hadoop 生态圈中的老牌调度系统 Oozie 和 Azkaban。
我们主要的参考因素包含了两个方面。第一个方面是产品和技术层面，上图就列出了我们重点考察的产品和技术层面的细分维度。
比如从系统定位层面上，DS 的系统定位是 DataOps 平台，这也就意味着 DS 不仅仅是调度平台，未来非常有可能会 include 更加广泛的能力。比如构建在调度系统之上，数据质量和数据血缘相关的能力，抑或是和大数据紧密相关的 AIOps 相关的能力。而这一些能力，在其他几个调度平台上，由于系统定位的关系，基本上不太可能会出现在这些系统的 roadmap 中。因此对于社区参与者，参与 DS 社区无疑会有更大的发挥空间。
从用户体验层面上，DS 系统中所有的操作基本都可以在可视化 UI 上操作，无论是 Workflow 和 Task 编辑，Workflow 的端到端运行，还是像 resource 上传、脚本上传等操作。相比之下，其他的调度系统在格式化以外的操作，相比 DS 就要略逊一筹。
比如如果要使用 Airflow 作为调度系统，首先需要有 Python 的编码基础，其次需要去 follow Airflow 的带编码规范。如果使用 Azkaban 或者 Ozzie，虽然它们都有各自的可视化操作流程，但整个可视化操作流程都没有做到完整闭环。比如 Azkaban 在操作的时候必须要在本地进行编码打包上传，或者 Ozzie 必须在本地做非常繁杂的 XML 配置。
除此之外，DS 在调度系统功能层面，相比其他几个调度系统要更加完善，比如补数据、重跑、版本管理等常见辅助功能。所以总的来说，DS 更加符合国内用户的使用习惯，也更容易让非程序员的群体使用 Workflow 系统。
最后对于可用性、扩展性、实现语言的技术对比，在这里就不多过多赘述了，上图我们已经给出了一些总结性的结论，供大家参考。
第二个方面是社区层面，我们主要考虑社区的活跃度、地区分布等数据型的因素，以及社区开放包容度等软性因素。从上图可以看出，社区活跃度等一些数据型对比。从社区活跃度上看，DS 社区目前的 star 和 issue 指标数量在最近两年内有非常巨幅的提升，它的增长速度已经和当前最流行的开源调度系统 Airflow 处于并驾齐驱的状态。
从地域分布上看，DS 在国内拥有更多的贡献者和用户。对于这一点，我相信所有参与过国外开源社区主导的开源项目同学，都会有非常深刻的体会。当第一天提交 pr 或者 issue 的时候，通常无法及时获得 reply，这个 reply 通常需要等到第二天甚至更长的时间才能得到。这无疑对我们参与开源社区的效率和兴趣长生极大的打击。而在 DS 的开源项目中，通常就不会存在这样的问题，因为 DS 大多数的贡献者和用户都集中在国内。
从更多的软性因素上看，比如社区的开放度，DS 由于本身定位的关系，对一些比较高级或者关联性比较高的 topic，比如数据血缘、数据质量等都会有更大的包容和接纳。所以，参与 DS 的体感也会比其他开源社区更好。
综上所述，尽管 Airflow 社区拥有更大的用户基础和更成熟的项目基础，我们最终依然选择了 DS 作为重点投入的开源项目，并把它排到了 EMR 数据开发商业化 roadmap 中的第一优先级。
三、社区贡献
3.1 交互式开发系统整合
第一部分工作是交互式开发系统在 DS 中的集成。相比于传统的服务端或者外部后端开发，大数据开发流程至今仍然缺乏平滑易用的最佳实践。导致这个结果的因素可能非常多，但我个人认为其中最重要的两个因素是计算资源和数据。它们很难在本地调试中直接进行模拟和 mock，所以通常情况下传统的大数据开发流程就会是上图中左侧的样子。
首先在本地的 IDE 中进行编码。无论是写 Spark、Flink 还是 SQL，在编码过程中都无法进行调试，因为在本地缺少计算资源和数据，所以我们必须在编码结束之后进行手动打包，并把相关的代码传到集群环境中。这个集群环境对于一些较大的公司，测试环境和生产环境通常是分开的，而对于一些小公司，生产环境和测试环境通常都是同一个。
然后会手工测试代码逻辑是否符合预期。如果不符合预期，就需要把整个流程回退到第一步，重新进行在 IDE 中的编码，循环往复直到代码逻辑测试通过，之后才能在调度平台和实时平台上进行生产发布和运维监控。
从刚才流程上看，很明显有两个痛点。第一是调试困难，我们会发现在 IDE 中的编码以及在集群环境中的调试是两个非常割裂的流程。第二是上线流程缺少自动化的 pipeline，这和 web 开发有非常大的区别。因为 web 开发在本地开发完后，只要将代码 push 到 Git 仓库中，后面就都有自动化的 pipeline 去执行单元测试、集成测试、发布等操作，我们对这些流程都不需要有过多的担心。
而大数据的开发流程显然缺少这样的自动化流程，因此为了解决这两个痛点，我们通过引入 Notebook 这个交互式开发工具来解决调试困难的问题，以及通过和 DS 的集成来解决大数据开发流程自动化 pipeline 的问题。
优化后的流程就如上图右侧所示。首先在集群或者类集群环境下，基于 Notebook 进行交互式开发，进行快速编码调试来解决调试困难问题。然后在交互式开发系统中，通过自动化对接调度平台，实现开发之后的自动化生产发布、运维监控。
在具体实践中，我们选择了目前市面上最流行的两种 Notebook，分别是 Zeppelin Notebook 和 Jupyter Notebook，并完成了和 DS 的初步整合。下面就分别来介绍一下，这两种 Notebook 以及我们基于它们在 DS 上的相关工作。
首先是 Zeppelin Notebook，它在纯大数据开发场景下会拥有较多的客户，因为它的需求起源就来自于使用 Spark、Flink 的 Native API 进行开发。目前 Zeppelin 支持的语言和引擎已经非常广泛，除了 Spark、Flink 开发中常用的 Scala 之外，基本包含了绝大部分主流的计算和存储引擎。
除此之外，Zeppelin 也借鉴了 Jupyter Notebook 中的一些 feature，目前也具备了一定的数据可视化能力。上图是我们基于 Zeppelin 开发到上线的全流程。
首先在 Zeppelin Notebook 中去进行编码，我们还可以通过可视化的操作让整个编码调试过程更加直观。完成调试后，我们直接在 DS 中使用 Zeppelin 作业类型进行编辑。这个编辑过程并不需要任何打包上传代码的操作，只需要填写刚才编辑的 Notebook 以及 Notebook 中的 paragraph ID，即可完成 Zeppelin 类型的作业编辑。编辑完成之后，就可以直接把这个作业放在 DS 中进行调度。
其次是 Jupyter Notebook。Jupyter Notebook 社区相比于 Zeppelin Notebook 社区会有一定的区别。因为 Jupyter Notebook 社区主要的关注受众是 AI 群体，在大数据相关领域 Jupyter 的子项目，数量和成熟度都偏低。但 Jupyter Notebook 的功能，会比 Zeppelin Notebook 更加成熟。比如 IDE 相关的功能，代码自动补全、跳转、数据可视化等。
因此我们也实现了 Jupyter Notebook 和 DS 的集成，它的集成方式和 Zeppelin 类似。但对 Jupyter 来说，除了配置基本 Notebook、Python 执行环境等参数之外，我们还可以利用其中的 feature 进行一些特殊的实现。
以上图左侧中叫 parameter tags 的 feature 为例，我们可以在实现调度系统集成的过程中，实现调度系统内置参数和 Jupyter 内部参数联动的 feature，这样 Notebook 就可以非常方便的完成生产和测试变量之间的切换。也就是在调试过程中使用常量放在 Notebook 中执行，在实际生产调用的时候，传一个可变参数到 Notebook 中。整体的切换流程非常平滑和自然，且不需要在 Notebook 上做任何代码层面的变更。
目前，我们在 Notebook 集成 DS 上还处于初级阶段，还有很多地方需要改进。比如我们在使用过程中，仍然需要跨两个系统进行操作。对于大部分非大数据开发人员，尤其是像商业分析师和算法工程师这样的岗位，他们通常只对 Notebook 或者交互式开发系统更熟悉，对 Workflow 这样的系统通常是无感的。那么能否将他们的用户入口保持在 Notebook 上，屏蔽调度系统的实现细节呢？
上图展示的是来自 IBM 的 elyra AI 项目，这个项目给了我们一定方向性的启发。从这张图上可以看到，这是 Notebook 系统，它除了 Notebook 的基础能力，比如编写 Notebook 以及编写脚本之外，还实现了一些插件。我们可以通过拖、拉、拽的方式把编写的 Notebook 或者 script 加到可视化界面中，完成 dag 编写。
这个 dag 通过自动化可以对接到 Workflow 系统，同步到调度平台上。无论调度平台是 Airflow、还是这里还没实现的 DS 都可以实现，这样整个用户的操作界面就只会停留在 Notebook 系统中。相比于刚刚的实现流程，省去了两个系统之间的切换，对使用者来说会更加友好和自然。
3.2 项目质量
第二部分工作关于项目质量，主要包括 Metrics、代码质量、测试覆盖度。
在 Metrics 方面，我们和社区一起完成了各个重要模块组件和系统 Metrics 的梳理。Metrics 覆盖了 DS 的各个核心组件，比如 Master Server、Work Server、API Server 等，以及 Workflow、Task、Resource 等业务型指标。与此同时，我们也和社区一起完成了主要 Metrics 埋点工作。对于 DS 的用户来说，基于 Metrics 进行基本的系统监控和运维就具备了最基础的能力。
在代码质量方面，我们通过引入 Spotless 插件对整个项目中的 code style error 进行了统一修复。并把 Spotless 插件直接放到了整个项目的 CI 流程中。这样所有行政代码就会自动对 code style 进行修复，使项目永远保持在 clean 状态。
在单元测试和覆盖方面，我们和社区一起完成了 PowerMock 的去除和 JUnit 的统一升级。提升了整体测试的覆盖度，奠定了非常坚实的基础。
但目前，DS 项目的整体单侧覆盖度仍然偏低，所以未来我们将和社区继续 drive 这方面的工作，把这块重要但是不紧急的事情持续不断的做下去。
3.3 云原生
第三部分工作关于云原生，主要包括云原生部署架构的优化、云原生资源以及日志存储、云原生多租。
我们在最近几期 DS 社区内部讨论中，提出了很多相关的 issue，同时也建到了 Github 上。欢迎感兴趣的同学和我们一起讨论，共建 DS 云原生相关的 topic。
四、商业化实践
我们的商业化实践主要分为两个阶段。第一阶段，我们将各种开源大数据的开发、调度组件整合到 EMR 集群中，并去适配 EMR 集群当中的各类大数据、开源大数据的计算和存储引擎。当用户购买了 EMR 集群或者 EMR 边缘节点后，就可以直接使用这些组件在 EMR 集群上进行数据开发。这种产品形态非常直接了当，但也存在缺陷。
- 第一，用户很可能会为数据开发相关组件去购买其他的云资源，以实现数据开发组件和 EMR 核心组件之间的解耦部署。
- 第二，用户在平时仍然需要花费一定的精力，对数据开发组件进行运维。
以上两个缺陷，对于一些中小型客户来说显然是不能接受的。因为他们希望得到的是即开即用、无需部署的服务，而不是半托管服务。为此，我们基于 DS 和阿里云的基础能力，在 EMR 产品线上构建了 serverless 的数据开发服务，也就是 EMR Notebook 和 EMR Workflow。
接下来，我将重点介绍一下 EMR Workflow 这个产品。
- 第一，EMR Workflow 是基于 DS 来实现的大数据调度服务。因为使用了 DS，所以无论你是在 IDC 上还是在其他的云上，只要使用了 DS 就可以非常方便的进行作业之间的互相迁移，进而实现多云架构。其次，EMR Workflow 是一款随开随用的产品，无需购买额外的云资源。可以直接在这个系统中进行 Workflow 的编辑、Task 的编辑以及所有和 Workflow 相关的操作。
- 第二，EMR Workflow 可以无缝对接 EMR 中的计算引擎、存储引擎、EMR 平台能力。重点提一下 EMR 平台能力，它在集群创建速度和弹性扩缩容速度上，在业界已经处于领先地位，因此我们可以利用数据开发层面的对接，实现高效的存算分离架构。
- 第三，未来我们将会把 EMR Workflow 和 EMR Notebook 这两款 serverless 数据开发服务进行无缝对接，实现大数据开发体验的优化和大数据开发流程的重新定义。
上图展示了 EMR Workflow 的一些关键性 feature。可以看到，我们可以在完全没有 EMR 计算集群的情况下，直接从 EMR Workflow 这个产品出发做大数据的开发和调度。
如上图中间截图所展示，首先可以在 Workflow 中编辑一个叫 create cluster 的 Task，它可以为我们创建一个 EMR 集群。随后编辑在集群上的作业，比如 Spark、Hive、OLAP 等都可以运行在刚刚创建的集群上。最后当这个 Workflow 跑完之前，我们可以把这个刚刚创建的集群释放掉，这样就可以实现所谓的存算分离以及成本优化的动作。
