大数据调度产品对比（海豚调度和天融信神灯）

背景

随着数字化转型的趋势，各行业都在建设自身的大数据中台，实现数字化运营。在大数据中台建设中，必然涉及到大量大数据任务、机器学习任务以及各类脚本任务的运行。随着业务量的增长就会自然需要建设一个集中式的任务调度系统。

笔者企业内部大数据调度平台从天融信公司采购，产品名称为神灯（magiclanp）调度系统。在使用过程中，也在关注Apache基金会的开源调度项目—DolphinScheduler（下面简称海豚调度）。

在使用神灯调度系统过程中，我们也参考海豚调度系统，完成了调度系统服务分布式高可用架构的改造。

本文将以介绍神灯调度系统，并与海豚调度进行产品比较。内容主要分为：业务架构、技术架构两个方面展开。

第一部分业务架构

1.1 业务抽象

神灯（magiclanp）调度系统，将所有类型的大数据任务（MapReduce、Spark、Flink）均抽象为DAG计算图。计算图的数据结构使用XML文件进行定义。

将大数据计算任务原子化为各类算子，算子通过计算依赖关系组成计算图（pipline）。算子按照功能分为：输入算子、数据处理算子、输出算子以及控制算子。

输入算子

负责各类数据输入对接各类内外部数据源。数据分为文件系统和外部数据库两种类型。
数据处理算子

负责对上游算子输出数据进行ETL处理。
输出算子

负责对处理结果传输至内外部文件系统、数据库存储、消息中间件等进行持久化。
控制算子

负责控制数据处理逻辑，例如条件分支等。

为了增加系统易用性，系统提供用户web可视化方式，支持画布、托拉拽方式进行创建大数据处理任务，系统内部定义为大数据模型。

例如下图的Spark模型案例：

1.2 模型类型

平台按照模型的研发方法，模型分为：画布模型和程序模型。另外按照模型使用场景，分为：规则模型和机器学习模型。

1.2.1 画布模型

调度平台支持MapReduce、Spark、Flink三种计算框架。每类计算框架编写一套自身的pipline处理JDK，任务提交至Yarn集群运行时，通过解析xml文件和算子jar包，完成任务计算处理。

画布模型对于业务人员较为友好，极大降低了大数据使用技术门槛。但是平台算子集合毕竟是有限的，所以算子组合的模型表达能力是有上限的。对于更为灵活和复杂的大数据处理场景依然需要代码级别的研发。这就是更为灵活的程序模型。

1.2.2 程序模型

支持用户灵活化开发Python任务、Spark任务，后续将支持Flink计算框架。按照规范打包后，由平台创建模型后调度运行。

1.2.3 规则模型

规则模型主要是为了和机器学习模型区分。模型主要使用SQL处理算子等，对数据按照规则配置，进行数据过滤和筛选。

1.2.4 机器学习模型

目前只有Spark计算框架实现了基于Spark ML内置模块，研发了各类机器学习算子。对于更灵活的机器学习任务，目前支持PySpark模式提交至集群运行，即：PySpark On Yarn模式。

1.3 任务调度

系统中创建的大数据模型是一个静态概念（即静态计算图），需要针对模型创建相应的调度任务后运行模型。模型的调度方式，支持即时任务、定时任务、流式任务。

即时任务

即刻发起一次大数据模型运行。使用场景通常为模型试运行。
定时任务

按照定时周期，有平台周期性调度运行任务。
流式任务（服务）

针对流处理模型（例如Flink计算框架），任务运行后常驻运行。

1.4 任务编排

在实际业务场景中，存在复杂场景不能通过单个模型完成，需要多个模型共同协作完成，模型之间还存在顺序依赖关系。这就需要平台具备各类模型的编排能力。

神灯调度系统基于该场景进行支持。

1.5 数据源支持

目前支持的

1.6 权限管理

1.6.1 用户管理

神灯平台集成了企业内部统一认证系统，就不展开介绍了。

1.6.2 数据源权限管理

神灯平台对接了各类数据源，企业内部不同人员对于数据访问就需要权限隔离。目前权限管理颗粒度到表的读、写、删。

还没有对

1.7 监控告警

1.8 任务高可用

第二部分技术架构

2.1 系统整体架构

目前神灯平台还属于传统应用，业务架构图如下：

2.2 系统高可用设计

目前只有MapReduce计算框架实现了分布式处理能力。其他任务仍然是单机模式。

2.3 易用性功能

2.4 大数据任务安全认证架构

2.4.1 `Kerberos`票据模式

架构上，系统所有调度节点均部署定时服务，周期性（11小时）向集群kerboros服务申请票据（有效期24小时）。票据缓存在本地/tmp目录，所有大数据任务提交至Yarn集群的时候，只需要使用票据即可。不需要实时使用Principal和keytab文件。

架构上这样设计主要是减少Kerboros服务的请求压力。目前线上集群实时任务量500+，避免了Kerboros服务瓶颈（虽然没有压测过）。

2.4.2 多集群互信机制

对于线上环境多集群场景下，引入了Kerberos的集群互信机制。例如线上有3个集群分别是为：A、B、C集群，架构上选取A集群为主集群。配置A与B互信，A与C互信。这样调度平台每个节点只需要申请A集群的票据即可完成资源认证。

2.5 Python程序技术架构

第三部分总结

3.1 功能差异

天融信神灯平台除了调度功能，还集成了各种大数据任务无代码创建功能。对于业务人员只需要懂SQL语法就可以上手完成大数据任务的创建到调度运行。

优点：用户面向业务人员也面对开发人员

海豚调度更专注于调度功能。面向用户为大数据研发人员（需要会自己编写大数据任务并打包成可运行的jar包）

3.2 架构上

3.3 整体对照表

单机部署：

https://dolphinscheduler.apache.org/zh-cn/docs/1.3.4/user_doc/standalone-deployment.html

参考文献及资料

1、官网地址，链接:https://tomcat.apache.org/

目录

背景

第一部分 业务架构