亿云基于 DolphinScheduler 的数据服务实践！

基于 Apache Dolphinscheduler 调度平台，云计算和大数据提供商亿云信息已经服务公司多个项目部的地市现场平稳运行一年之久。

结合政务信息化生态建设业务，亿云信息基于 DolphinScheduler 构建了资产数据管控平台的数据服务模块。他们是如何进行探索和优化的？**亿云信息研发工程师 孙浩 **进行了详细的用户实践交流分享。

01 研发背景

亿云主要的业务主要是 ToG 的业务，而业务前置的主要工作，在于数据的采集和共享，传统 ETL 工具，例如 kettle 等工具对于一线的实施人员的来说上手难度还是有的，再就是类似 kettle 的工具本身做为独立的部分，本身就增加了现场项目运维的使用难度。因此，如何实现一套数据采集（同步）—数据处理—数据管理的平台，就显得尤为重要。出于这样的考虑，我们开发了数据资产管理平台，而管理平台的核心就是我们基于DolphinSchduler（简称 DS）实现的数据服务模块。DolphinScheduler 是一个分布式去中心化，易扩展的可视化 DAG 调度系统，支持包括 Shell、Python、Spark、Flink 等多种类型的 Task 任务，并具有很好的扩展性。其整体架构如下图所示：

图片

典型的 master-slave 架构，横向扩展能力强，调度引擎是 Quartz，本身作为 Spring Boot 的 java 开源项目，对于熟悉 Spring Boot 开发的人，集成使用更加的简单上手。
DS 作为调度系统支持以下功能：
调度方式：系统支持基于 cron 表达式的定时调度和手动调度。命令类型支持：启动工作流、从当前节点开始执行、恢复被容错的工作流、恢复暂停流程、从失败节点开始执行、补数、定时、重跑、暂停、停止、恢复等待线程。其中恢复被容错的工作流和恢复等待线程两种命令类型是由调度内部控制使用，外部无法调用。
定时调度：系统采用 quartz 分布式调度器，并同时支持 cron 表达式可视化的生成。
依赖：系统不单单支持 DAG 简单的前驱和后继节点之间的依赖，同时还提供任务依赖节点，支持流程间的自定义任务依赖。
优先级 ：支持流程实例和任务实例的优先级，如果流程实例和任务实例的优先级不设置，则默认是先进先出。
邮件告警：支持 SQL任务 查询结果邮件发送，流程实例运行结果邮件告警及容错告警通知。
失败策略：对于并行运行的任务，如果有任务失败，提供两种失败策略处理方式，继续是指不管并行运行任务的状态，直到流程失败结束。结束是指一旦发现失败任务，则同时Kill掉正在运行的并行任务，流程失败结束
补数：补历史数据，支持区间并行和串行两种补数方式。我们基于 Dolphinscheduler 与小伙伴一起进行如下的实践。

02 基于DS构建数据同步工具

回归业务本身，我们的业务场景，数据同步的业务需要是类型多，但数据量基本不会特别大，对实时要求并不高。所以在架构选型之初，我们就选择了 datax+ds 的组合，并进行对应业务的改造实现，现在作为服务产品融合在各个项目中，提供离线同步服务。

图片

同步任务分为了周期任务和一次性任务，在配置完成输入输出源的配置任务之后，周期任务的话，需要配置 corn 表达式，然后调用保存接口，将同步任务发送给DS 的调度平台。

图片

我们这里综合考虑放弃了之前 DS 的 UI 前端（第二部分在自助开发模块会给大家解释），复用 DS 后端的上线、启停、删除、日志查看等接口。

图片

图片

图片

整个同步模块的设计思路，就是重复利用 datax 组件的输入输出 plugin 多样性，配合 DS 的优化，来实现一个离线的同步任务，这个是当前我们的同步的一个组件图，实时同步这块不再赘述。

图片

03 基于DS的自助开发实践

熟悉 datax 的人都知道它本质上是一个 ETL 工具，而其 Transform 的属性体现在，它提供了一个支持 grovy 语法的 transformer 模块，同时可以在 datax 源码中进一步丰富 transformer 中用到工具类，例如替换、正则匹配、筛选、脱敏、统计等功能。而 Dolphinscheduler 的任务，是可以用 DAG 图来实现，那么我们想到，是否存在一种可能，针对一张表或者几张表，把每个 datax 或者 SQL 抽象成一个数据治理的小模块，每个模块按照 DAG 图去设计，并且在上下游之间可以实现数据的传递，最好还是和 DS 一样的可以拖拽式的实现。于是，我们基于前期对 datax 与 ds 的使用，实现了一个自助开发的模块。

图片

image.gif

每个组件可能是一个模块，每个模块功能之间的依赖关系，我们利用 ds 的depend 来处理，而对应组件与组件传递数据，我们利用前端去存储，也就是我们在引入 input（输入组件）之后，让前端来进行大部分组件间的传递和逻辑判断，因为每个组件都可以看作一个 datax 的(输出/输出)，所有参数在输入时，最终输出的全集基本就确定了，这也是我们放弃 DS 的 UI 前端的原因。之后，我们将这个 DAG 图组装成 DS 的定义的类型，同样交付给 ds 任务中心。
PS：因为我们的业务场景可能存在跨数据库查询的情况（不同实例的 mysql 组合查询），我们的 SQL 组件底层使用 Presto 来实现一个统一 SQL 层，这样即使是不同 IP 实例下的数据源（业务上有关联意义），也可以通过 Presto 来支持组合检索。

04 其他的一些简单尝试

熟悉治理流程的人都知道，如果能够做到简单的治理流程化，那么必然可以产出一份质量报告。我们在自助开发的基础上进行优化，将部分治理的记录写入 ES 中，再利用 ES 的聚合能力来实现了一个质量报告。

图片

image.gif

图片

以上便是我们使用 DS 结合 datax 等中间件，并结合业务背景所做的一些符合自身需求的实践。

05 感谢

从 EasyScheduler 到现在的 DolphinScheduler 2.0，我们更多时候还是作为旁观者，或者是追随者，而这次更多地是从这一年来使用 Dolphinscheduler 构建我们数据资产管控平台数据服务模块的实践来进行交流分享。当前基于Dolphinscheduler 调度平台，我们已经服务了公司多个项目部的地市现场运行。随着 DolphinScheduler 2.0 发版，我们也和 DolphinScheduler 一起在不断进步的社区环境中共同成长。