https://dolphinscheduler.apache.org/
https://www.apache.org/dyn/closer.lua/dolphinscheduler/1.3.9/apache-dolphinscheduler-1.3.9-bin.tar.gz
Apache DolphinScheduler是一个分布式、易扩展的可视化DAG工作流任务调度平台。致力于解决数据处理流程中错综复杂的依赖关系,使调度系统在数据处理流程中开箱即用。
(1)MasterServer
MasterServer采用分布式无中心设计理念,MasterServer主要负责 DAG 任务切分、任务提交监控,并同时监听其它MasterServer和WorkerServer的健康状态。 MasterServer服务启动时向Zookeeper注册临时节点,通过监听Zookeeper临时节点变化来进行容错处理。 MasterServer基于netty提供监听服务。
该服务内主要包含:
Distributed Quartz分布式调度组件,主要负责定时任务的启停操作,当quartz调起任务后,Master内部会有线程池具体负责处理任务的后续操作
MasterSchedulerThread是一个扫描线程,定时扫描数据库中的 command 表,根据不同的命令类型进行不同的业务操作
MasterExecThread主要是负责DAG任务切分、任务提交监控、各种不同命令类型的逻辑处
MasterTaskExecThread主要负责任务的持久化
(2)WorkerServer
WorkerServer也采用分布式无中心设计理念,WorkerServer主要负责任务的执行和提供日志服务。 WorkerServer服务启动时向Zookeeper注册临时节点,并维持心跳。 Server基于netty提供监听服务。Worker
该服务包含:
FetchTaskThread主要负责不断从Task Queue中领取任务,并根据不同任务类型调用TaskScheduleThread对应执行器。
LoggerServer是一个RPC服务,提供日志分片查看、刷新和下载等功能
(3)ZooKeeper
ZooKeeper服务,系统中的MasterServer和WorkerServer节点都通过ZooKeeper来进行集群管理和容错。另外系统还基于ZooKeeper进行事件监听和分布式锁。 我们也曾经基于Redis实现过队列,不过我们希望DolphinScheduler依赖到的组件尽量地少,所以最后还是去掉了Redis实现。
(4)Task Queue
提供任务队列的操作,目前队列也是基于Zookeeper来实现。由于队列中存的信息较少,不必担心队列里数据过多的情况,实际上我们压测过百万级数据存队列,对系统稳定性和性能没影响。
(5)Alert
提供告警相关接口,接口主要包括告警两种类型的告警数据的存储、查询和通知功能。其中通知功能又有邮件通知和**SNMP(暂未实现)**两种。
(6)API
API接口层,主要负责处理前端UI层的请求。该服务统一提供RESTful api向外部提供请求服务。 接口包括工作流的创建、定义、查询、修改、发布、下线、手工启动、停止、暂停、恢复、从该节点开始执行等等。
(7)UI
系统的前端页面,提供系统的各种可视化操作界面。
安全中心主要有租户管理、用户管理、告警组管理、Worker分组管理、队列管理、令牌管理等功能。安全中心只有管理员账户才有操作权限。
2.1.1 队列管理
此处的队列对应的是Yarn调度器的资源队列。故队列概念只对跑在Yarn上的任务类型有效。此处创建出的队列,可供后续任务进行选择。需要注意的是,在DolphinScheduler中创建队列,并不会影响到Yarn调度器的队列配置。
此处可不创建队列。
2.1.2 租户管理
租户对应的是Linux系统用户,是Worker执行任务使用的用户。如果Worker所在节点没有这个用户,Worker会在执行任务时创建这个用户。
此处创建一个atguigu租户,如下图。
注:
租户编码:对应Worker执行任务所使用的用户名。
租户名称:用于在DolphinScheduler中显示。
队列:该租户提交Yarn任务时的默认队列。
2.1.3 用户管理
用户对应的是DolphinScheduler的用户,用于登录DolphinScheduler。用户分管理员用户和普通用户。默认情况下,管理员只有授权和用户管理等权限,而普通用户只有创建项目,定义工作流、执行工作流等权限。
此处创建一个普通用户atguigu,如下图。
注:
用户名:DolphinScheduler登录账户
租户:该用户关联的租户
队列:默认为租户所关联的队列。
邮件、手机号:主要用于告警通知。
2.1.4 告警组管理
告警组可包含多名用户,用于指定告警发送对象。
1)创建告警组
2.1.5 Worker分组管理
在任务执行时,可以将任务分配给指定Worker组,最终由该组中的Worker节点执行该任务。默认情况下,所有Worker均位于default组。
此处可不做配置。
2.1.6 令牌管理
令牌用于通过接口访问DolphinScheduler各项服务时的用户验证。普通用户通过UI页面访问各项服务时,无需使用令牌。若需将DolphinScheduler与第三方服务进行集成,则需调用其接口,此时需使用令牌。
2.2.1 切换用户
默认不使用管理员用户操作项目和工作流等,故需先切换到普通用户atguigu。
1)admin用户退出
下图为工作流配置页面,共包含三个模快,分别为工作流定义、工作流实例和任务实例。
工作流定义:用于定义工作流,包括工作流各节点任务详情及各节点依赖关系等。
工作流实例:工作流每执行一次就会生成一个工作流示例。此处可查看正在运行的工作流以及已经完成的工作流。
任务实例:工作流中的一个节点任务,每执行一次就会生成一个任务实例。此处可用于查看正在执行的节点任务以及已经完成的节点任务。
2.3.1 工作流定义
工作流要求:工作流需包含三个Shell类型的任务节点,分别是A,B,C。三个任务的依赖关系如下图所示:
2.3.2 提交执行工作流
1)上线工作流
工作流须上线之后才能执行。处于上线状态的工作流定义不可修改,如需修改,须先下线。
DolphinScheduler支持对任务节点进行灵活的传参,任务节点可通过${参数名}引用参数值。
3.1.1 局部参数
局部参数是指只针对单个任务节点有效的参数。
1)修改helloworld工作流Node-A节点如下
2)保存工作流并运行,查看Node-A输出日志。
3.1.2 全局参数
全局参数是指针对整个工作流的所有任务节点都有效的参数。
1)修改helloworld工作流每个任务节点如下
(1)节点A配置
3)执行工作流,查看三个任务节点输出日志。
3.1.3 系统内置参数
DolphinScheduler提供了一些时间相关的系统参数,方便定时调度使用。
1)系统参数
参数 | 说明 |
---|---|
${system.biz.date} | 定时时间前一天,格式为 yyyyMMdd |
${system.biz.curdate} | 定时时间,格式为 yyyyMMdd |
${system.datetime} | 定时时间,格式为 yyyyMMddHHmmss |
2)时间自定义参数
可通过时间自定义参数,设置任意格式、任意时间的日期。
(1)自定义日期格式
$[yyyyMMdd], $[HHmmss], $[yyyy-MM-dd]
(2)自定义时间
参数 | 说明 |
---|---|
$[add_months(yyyyMMdd,12*N)] | 后 N 年 |
$[add_months(yyyyMMdd,-12*N)] | 前 N 年 |
$[add_months(yyyyMMdd,N)] | 后 N 月 |
$[add_months(yyyyMMdd,-N)] | 前 N 月 |
$[yyyyMMdd+7*N] | 后 N 周 |
$[yyyyMMdd-7*N] | 前 N 周 |
$[yyyyMMdd+N] | 后 N 天 |
$[yyyyMMdd-N] | 前 N 天 |
$[HHmmss+N/24] | 后 N 小时 |
$[HHmmss-N/24] | 前 N 小时 |
$[HHmmss+N/24/60] | 后 N 分钟 |
$[HHmmss-N/24/60] | 前 N 分钟 |
3)配置示例
若执行的脚本需要一个格式为yyyy-MM-dd的前一天日期的参数,进行如下配置即可。
有些任务需要引用一些额外的资源,例如MR、Spark等任务需引用jar包,Shell任务需要引用其他脚本等。DolphinScheduler提供了资源中心来对这些资源进行统一管理。
下面以Shell任务为例,演示如何引用资源中心的其他脚本。
1)在资源中心创建脚本
3)保存工作流并执行,查看对应节点输出日志。
3.3.1 准备电子邮箱账户
如需使用DolphinScheduler的邮件告警通知功能,需要准备一个电子邮箱账号,并启用SMTP服务。
1)点击邮箱账号设置
3.3.2 配置AlertServer
1)修改AlertServer配置文件/opt/server/dolphinscheduler/conf/alert.properties
[linux@node1 ~]$ vim /opt/server/dolphinscheduler/conf/alert.properties
2)配置以下参数
(1)不使用加密协议
#alert type is EMAIL/SMS
alert.type=EMAIL
# mail server configuration
mail.protocol=SMTP
mail.server.host=smtp.qq.com
mail.server.port=25
mail.sender=*********@qq.com
mail.user=*********@qq.com
mail.passwd=*************
# TLS
mail.smtp.starttls.enable=false
# SSL
mail.smtp.ssl.enable=false
mail.smtp.ssl.trust=smtp.exmail.qq.com
(2)使用STARTTLS加密协议
#alert type is EMAIL/SMS
alert.type=EMAIL
# mail server configuration
mail.protocol=SMTP
mail.server.host=smtp.qq.com
mail.server.port=587
mail.sender=*********@qq.com
mail.user=*********@qq.com
mail.passwd=*************
# TLS
mail.smtp.starttls.enable=true
# SSL
mail.smtp.ssl.enable=false
mail.smtp.ssl.trust=smtp.qq.com
(3)使用SSL加密协议
#alert type is EMAIL/SMS
alert.type=EMAIL
# mail server configuration
mail.protocol=SMTP
mail.server.host=smtp.qq.com
mail.server.port=465
mail.sender=*********@qq.com
mail.user=*********@qq.com
mail.passwd=*************
# TLS
mail.smtp.starttls.enable=false
# SSL
mail.smtp.ssl.enable=true
mail.smtp.ssl.trust=smtp.qq.com
注:各邮箱支持的加密协议:https://blog.csdn.net/wustzjf/article/details/52481309
3.3.3 测试
若工作流执行到一半失败了,需要重新启动工作流。重新启动时可选择从起点开始执行,也可选择从断点开始执行。
1)模拟失败场景
(1)修改Node-A配置如下