【Meetup回顾】Apache DolphinScheduler在联通的实践和二次开发经验分享
在由 openLooKeng 社区主办,Apahce DolphinScheduler社区、Apache Pulsar 社区、示说网协办的联合 Meetup 上,来自联通数字科技的王兴杰老师分享了DolphinScheduler 在联通的实践和二次开发经验分享。
视频分享请参见 B 站
兴杰老师也总结了本次分享的文字版,欢迎阅读!
2020 年 3 月在完成一套服务监控治理系统的时候,我们接触到了 DolphinScheduler,发现 DolphinScheduler 的功能和我们的业务场景匹配度很高,于是萌生了是否可以使用 DolphinScheduler 或者其他开源调度系统的作为核心调度系统想法。
但由于复杂的业务模式和庞大的数据体量,没有一款开源调度系统的功能能够完全覆盖我们的要求,只能找到一款更适合我们的基于此做二次开发。
我们调研了市面上较为常用的开源调度系统:
Oozie:
配置工作流的过程是编写大量的HPDL语言(一种XML流程定义语言)配置
代码复杂度比较高
Azkaban:
创建job需要手动完成固定格式文件
任务执行中信息存储在内存中并没有持久化,所以一旦失败会丢失所有工作流。
Oozie 和 Azkaban 目前的社区活跃度相对 Airflow 和 DolphinScheduler 较低,并且其开发成本和使用成本较高,所以不在考虑范围。
关于 Airflow 和 DolphinScheduler 我们做了重点的讨论
Airflow:
开发语言 Python
scheduler 使用数据库行锁作为分布式锁(2.0版本升级分布式部署,1.0为单机)
不支持暂停与重跑
分布式架构需要依赖其它组件(RabbitMQ or Redis)
用户需要编写Python脚本完成工作流定义
DolphinScheduler:
开发语言 Java
使用 zk 作为分布式锁
支持重跑、暂停、停止等多种调度策略
去中心化设计,天然支持HA
可拖拽式编排方式
从开发语言上来说,小组的主要技术栈是Java,对于 Python 的使用成本较高。
DolphinScheduler 的分布式架构依赖的是 zookeeper,Airflow 依赖的是 RabbitMQ 或 Redis,zookeeper 集群的运营成本对于我们来说要低于 RabbitMQ 或 Redis。使用 zookeeper 作为分布式锁在任务量大时其性能、稳定性都要略高于数据库行锁。
底层架构各有优缺点,而 DolphinScheduler 的去中心化架构更可以保证 HA的稳定性,而且内部支持的负载均衡策略也是我们所需要的。对于调度策略,我们所需要的主子流程调度、干涉调度策略等 DolphinScheduler 已经原生支持。所以无论是对于公司的业务模式、用户的使用习惯还是对于开发人员来看,DolphinScheduler都是我们更好的选择。
DolphinScheduler 是一个分布式易扩展的可视化 DAG 工作流任务调度开源系统,可拖拽式任务编排的方式对于使用用户来说,更容易接受,更容易操作,技术基础要求更低,从而也就更容易推广,为准备迁移调度系统或从 0 到 1 使用调度系统的企业和用户提供了全新的选择。
Master 和 Worker 两个核心服务都采用了去中心化设计,这样既保证了分布式架构的稳定性,也保证了负载的均摊,没有一个是主,大家又都是主。DolphinScheduler 的 Master 和 Worker 是从服务器级别的负载情况来决定任务的执行策略,这样对于一些部署多种应用的服务器来说,不需要过度担心其他服务对调度服务的影响。
高可靠性,简单易用,丰富的使用场景,高扩展性,这些特性造就了 DolphinScheduler 被原来越多的企业和用户认可。
DolphinScheduler 的使用者分布在各个行业,不仅包含了互联网企业,还有不同类型的传统行业,社区的参与者有很多都是来自一线互联网大厂的大佬,所以在多行业多环境的使用场景和一线技术参与者的加持下 DolphinScheduler 会成为越来越多大数据工作者的选择。
DolphinScheduler 提供了一个很好的基础无中心化架构设计基础上的容错机制,保证了即便是服务器宕机,也可以保证任务不丢失。尽管对于稳定的日常加工来说服务器的不稳定发生的概率相对较低,但是对于研发人员却要耗费大量的时间和精力尽可能地保证万无一失,对于调度系统稳定性的要求肯定是企业要求的最高级别,而 DolphinScheduler 已经为想要使用的企业和用户解决了这一头疼的问题。
但是天有不测风云,研发人员面对的永远都是最好的准备,最坏的打算,即便是做了万全的准备,异常告警也是不可或缺的,DolphinScheduler 已经为用户准备好了多种类型的告警通知,如果不能满足用户的要求,二次开发的成本也是非常低的,我们仅用了两个小时添加了短信告警类型。同时可以通过可视化页面直观的看到服务器的 CPU、内存、负载情况,也配置了工作流执行甘特图,可以覆盖到大部分的使用场景。这些都是 DolphinScheduler 原生具备的特性。
我们的业务场景包括了全局变量、条件判断节点(根据变量值)、延时功能、循环功能、批量调用子流程功能、任务执行并行数量控制。
经过调研后确定研发方案,历时三个星期开发完成主要功能的研发工作并且上线。上线后压测,当时为了最大程度的压测 DolphinScheduler 任务分发和处理的能力我们将 Master 接受 Worker 通知的队列修改为线程池,task 主要包括我们常用的 SQL、shell、条件判断、子流程(批量)节点,SQL 执行 select 和 insert 语句,shell 执行 echo 和 sh 命令,被执行的脚本中不包含业务逻辑,基于 DolphinScheduler 二次开发后的调度系统支持 5000 并发(测试的流程并发 task 数为 5000),累计运行超过 20 万 task,耗时 20 分钟。
从用户的反馈来看,在简单的培训之后便可以进行工作流的配置工作,一般用户配置时出现的错误也可以通过页面展示的日志自行解决。
在开发过程中方案的确定,问题的排查都得到了社区的积极反馈,我们也在反馈社区的过程中不断地优化现有的系统。
二次开发经验
联通数科数据智能事业部
联通数科数据智能事业部的前身是联通大数据,成立于2017年,是联通全网数据商业运营的统一出口。联通数科以上云、用数、赋智为核心,助力社会治理能力和体系现代化,在创新研发能力上不断取得突破。云计算领域沉淀了丰富的全栈自研沃云产品、全面的多云管理能力、大体量的混合云纳管实践以及全流程覆盖的云运营服务能力;大数据治理、运营和安全能力方面达到行业领先,率先通过DCMM(数据管理能力成熟度)四级认证,运营商大数据业务市场份额位居第一。