途家大数据平台基于 Apache DolphinScheduler 的探索与实践
本文主要包括 4 个部分。第一部分是途家的平台的现状,介绍途家的数据的流转过程,如何提供数据服务,以及 Apache DolphinScheduler 在平台中扮演的角色。第二部分,调度选型,主要介绍调度的一些特性,以及接入的过程。第三部分主要介绍我们对系统的的一些改进和功能扩展,包括功能表依赖的支持,邮件任务扩展,以及数据同步的功能,第四部分是根据业务需求新增的一些功能,如 Spark jar 包支持发布系统,调度与数据质量打通,以及表血缘展示。
首先介绍一下途家数据平台的架构以及 Apache DolphinScheduler 在数据平台扮演的角色。
途家数据平台架构
上图为我司数据平台的架构,主要包括数据源,数据采集,数据存储,数据管理,最后提供服务。
数据源主要来源包括三个部分:业务库 MySQL API 数据同步,涉及到 Dubbo 接口、http 接口,以及 web 页面的埋点数据。
数据采集采用实时和离线同步,业务数据是基于 Canal 的增量同步,日志是 Flume,Kafka 实时收集,落到 HDFS 上。
数据存储过程,主要涉及到一些数据同步服务,数据落到 HDFS 后经过清洗加工,推送到线上提供服务。
数据管理层面,数据字典记录业务的元数据信息,模型的定义,各层级之间的映射关系,方便用户找到自己关心的数据;日志记录任务的运行日志,告警配置故障信息等。调度系统,作为大数据的一个指挥中枢,合理分配调度资源,可以更好地服务于业务。指标库记录了维度和属性,业务过程指标的规范定义,用于更好的管理和使用数据。Abtest 记录不同指标和策略对产品功能的影响;数据质量是数据分析有效性和准确性的基础。
最后是数据服务部分,主要包括数据的即席查询,报表预览,数据下载上传分析,线上业务数据支持发布等。
下面着重介绍调度系统在平台扮演的角色。数据隧道同步,每天凌晨定时拉去增量数据。数据清洗加工后推送到线上提供服务。数据的模型的加工,界面化的配置大大提高了开发的效率。定时报表的服务,推送邮件,支持附件,正文 table 以及折线图的展示。报表推送功能,数据加工后,分析师会配置一些数据看板,每天 DataX 把计算好的数据推送到 MySQL,做报表展示。
第二部分介绍我们接入 Apache DolphinScheduler 做的一些工作。
Apache DolphinScheduler 具有很多优势,作为大数据的一个指挥中枢,系统的可靠性毋庸置疑,Apache DolphinScheduler 去中心化的设计避免了单点故障问题,以及节点出现问题,任务会自动在其他节点重启,大大提高了系统的可靠性。
此外,调度系统简单实用,减少了学习成本,提高工作效率,现在公司很多人都在用我们的调度系统,包括分析师、产品运营,开发。
调度的扩展性也很重要,随着任务量的增加,集群能及时增添资源,提供服务。应用广泛也是我们选择它的一个重要原因,它支持丰富的任务类型:Shell、MR、Spark、SQL(MySQL、PostgreSQL、Hive、SparkSQL),Python,Sub_Process,Procedure 等,支持工作流定时调度、依赖调度、手动调度、手动暂停 / 停止 / 恢复,同时支持失败重试 / 告警、从指定节点恢复失败、Kill 任务等操作等。它的优势很多,一时说不完,大家都用起来才知道。
接下就是我们定时调度的升级。
在采用 Apache DolphinScheduler 之前,我们的调度比较混乱,有自己部署本地的 Crontab,也有人用 Oozie 做调度,还有部分是在系统做定时调度。管理起来比较混乱,没有统一的管理调度平台,时效性,和准确性得不到保障,管理任务比较麻烦,找不到任务的情况时有发生。此外,自建调度稳定性不足,没有配置依赖,数据产出没有保障,而且产品功能单一,支持的任务调度有限。
2019 年,我们引入 Apache DolphinScheduler ,到现在已经接近三年时间,使用起来非常顺手。
下面是我们迁移系统的一些数据。
我们搭建了 DS 集群 ,共 4 台实体机 ,目前单机并发支持 100 个任务调度。
算法也有专门的机器,并做了资源隔离。
Oozie 任务居多 ,主要是一些 Spark 和 Hive 任务 。还有 Crontab 上的一些脚本,一些邮件任务以及报表系统的定时任务。
在此之前,我们也对系统做过优化,如支持表级别的依赖,邮件功能的扩展等。接入 Apache DolphinScheduler 后,我们在其基础之上进行了调度系统构建,以能更好地提供服务。
第一. 支持表依赖的同步,当时考虑到任务迁移,会存在并行的情况,任务一时没法全部同步,需要表任务运行成功的标记,于是我们开发了一版功能,解决了任务迁移中的依赖问题。然而,每个人的命名风格不太一样,导致配置依赖的时候很难定位到表的任务,我们也无法识别任务里面包含哪些表,无法判断表所在的任务,这给我们使用造成不小的麻烦。
第二. 邮件任务支持多 table。调度里面自带邮件推送功能,但仅支持单个 table , 随着业务要求越来越多,我们需要配置多个 table 和多个 sheet,要求正文和附件的展示的的条数不一样,需要配置,另外还需要支持折线图的功能,丰富正文页面。此外,用户还希望能在正文或者每个表格下面加注释,进行指标的说明等。我们使用 Spark jar 包实现了邮件推送功能,支持异常预警、表依赖缺失等。
第三. 支持丰富的数据源同步。由于在数据传输方面存在一些问题,在以前迁移的过程中,我们需要修改大量的配置代码,编译打包上传,过程繁琐,经常出现漏改,错该,导致线上故障,数据源不统一,测试数据和线上数据无法分开;在开发效率方面,代码有大量重复的地方,缺少统一的配置工具,参数配置不合理,导致 MySQL 压力大,存在宕机的风险;数据传输后,没有重复值校验,数据量较大的时候,全量更新,导致 MySQL 压力比较大。MySQL 传输存在单点故障问题,任务延迟影响线上服务。
我们在此过程中简化了数据开发的流程,使得 MySQL 支持 pxc/mha 的高可用,提升了数据同步的效率。
我们支持输入的数据源支持关系型数据库,支持 FTP 同步,Spark 作为计算引擎,输出的数据源支持各种关系型数据库,以及消息中间件 Kafka、MQ 和 Redis。
接下来讲一下我们实现的过程。
我们对 Apache DolphinScheduler 的数据源做了扩展,支持 kafka mq 和 namespace 的扩展,MySQL 同步之前首先在本地计算一个增量,把增量数据同步到 MySQL,Spark 也支持了 MySQL pxc/qmha 的高可用。另外,在推送 MQ 和 Redis 时会有 qps 的限制,我们根据数据量控制 Spark 的分区数和并发量。
第四部分主要是对系统新增的一些功能,来完善系统。主要包含以下三点:
Spark 支持发布系统
数据质量打通
数据血缘的展示
由于我们平时的调度 80% 以上都是 Spark jar 包任务,但任务的发布流程缺少规范,代码修改随意,没有完整的流程规范,各自维护一套代码。这就导致代码不一致的情况时有发生,严重时还会造成线上问题。
这要求我们完善任务的发布流程。我们主要使用发布系统,Jenkens 打包功能,编译打包后生成 btag,在测试完成后再发布生成 rtag ,代码合并到 master 。这就避免了代码不一致的问题,也减少了 jar 包上传的步骤。在编译生成 jar 包后,系统会自动把 jar 包推送到 Apache DolphinScheduler 的资源中心,用户只需配置参数,选择 jar 包做测试发布即可。在运行 Spark 任务时,不再需要把文件拉到本地,而是直接读取 HDFS 上的 jar 包。
接下来将介绍如何将数据质量和调度系统打通。调度任务运行完成后,发送消息记录,数据质量平台消费消息,触发数据质量的规则监控 根据监控规则来阻断下游运行或者是发送告警消息等。
数据血缘是元数据管理、数据治理、数据质量的重要一环,其可以追踪数据的来源、处理、出处,为数据价值评估提供依据,描述源数据流程、表、报表、即席查询之间的流向关系,表与表的依赖关系、表与离线 ETL 任务,调度平台、计算引擎之间的依赖关系。数据仓库是构建在 Hive 之上,而 Hive 的原始数据往往来自生产 DB,也会把计算结果导出到外部存储,异构数据源的表之间是有血缘关系的。
追踪数据溯源:当数据发生异常,帮助追踪到异常发生的原因;影响面分析,追踪数据的来源,追踪数据处理过程。
评估数据价值:从数据受众、更新量级、更新频次等几个方面给数据价值的评估提供依据。
生命周期:直观地得到数据整个生命周期,为数据治理提供依据。血缘的收集过程主要是 :Spark 通过监控 Spark API 来监听 SQL 和插入的表,获取 Spark 的执行计划 ,并解析 Spark 执行计划。
作者简介:
昝绪超,途家大数据工程师 数据开发工程师,主要负责大数据平台的开发,维护和调优。
点击底部阅读原文访问 InfoQ 官网,获取更多精彩内容!
点个在看少个 bug 👇