大数据平台迁移实践 | Apache DolphinScheduler 在当贝大数据环境中的应用

大家下午好，我是来自当贝网络科技大数据平台的基础开发工程师 王昱翔，感谢社区的邀请来参与这次分享，关于 Apache DolphinScheduler 在当贝网络科技大数据环境中的应用。

本次演讲主要包含四个部分：

• 平台建设的背景

• 大数据平台重构

• 大数据调度平台建设

• 下一步规划

王昱翔

当贝大数据平台基础开发工程师

毕业于电子科技大学，主要是做大数据平台的构建、集成及组件的运维的工作。

01 背景

在当贝网络科技使用 Apache DolphinScheduler 作为大数据调度平台之前，我们在平台、测试环境和调度环境中都面临着不少问题需要解决。

02 大数据平台架构

这次我将从架构重构的目标、ClickHouse 迁移、大数据平台成功迁移、计算分离，以及大数据平台监控架构设计等几个方面给大家进行分享。

平台重构目标

1. 打造一个高效稳定的大数据平台，这是平台的首要目标；

2. 实现数据的海量存储；

3. 实现平台的安全高可用架构；

4. 实现计存分离；

5. 环境可视化操作；

6. 监控即时告警。

7. 大数据平台重构架构设计

我们对大数据平台进行了重构设计。

最下面是基础环境，中间是数据源，再向上是数据的预处理，即 CDC，数据导图工具。以及数据存储。平台基于 HDFS、OSS、 ClickHouse、ES、Kafka 和 Hudi 进行存储，向上是数据处理的计引擎，再向上是任务调度权限管控，接口管理等基础服务管理，架构的最上层是在此之上进行的公司业务处理。

大数据平台需求分析

此前，公司的大数据平台存在一些问题。从平台环境来说，主要存在的问题包括版本较低，服务部署混乱，计算引擎 MR 速度比较慢，存储不足，而且扩容较难，服务缺乏高可用的架构，服务挂掉之后数据缺失；缺少可视化的操作，需要后台操作；还缺乏报警机制，任务挂掉之后没有通知；运维起来也很困难，需要人肉运维。

在测试环境上，缺少测试环境，本地开发完后直接提交代码上生产，没有经过测验证，导致晚上任务异常报错。

调度环境上，我们原来使用的是 Ooize 调度，其系统配置比较复杂，可视化效果较差，没有补数，不支持权限管理，不支持多租户，还容易出现死锁。另外，运维监控能力不足，可视化效果差，无法在线查看日志，故障排除进入后台排错，流程复杂。

大数据平台问题调研分析

经过调研分析，我们找到了大数据平台的主要问题在于几个方面：OS 版本低，组件部署混乱，多系统数据磁盘共用，磁盘空间不足也是一大问题，导致每天晚上零点之前需要把昨天的数据删掉，来保证有 T+1 数据的存储空间。

大数据平台问题及解决方案

针对大数据平台混合部署的问题，我们历时一个半月的时间迁移了 ClickHouse。

关于版本过低的问题，我们把 CDH 从 5.7 升级到 6.3.0（Hadoop 3.0）重构了一套集群。

MR 计算引擎计算时间较长，我们将计算引擎从 MR 切换带 Spark，主要是跑 hive-sql，代码改造较少。

针对存储不足的问题，我们采用了计存分离的方案，使用 yarn+oss，并用 jindoFS 作为中间加速层。

原来的 Ooize 调度无法满足我们现有的业务调度的需求，于是我们就改用 Apache DolphinScheduler 进行调度。后者的好处包括是支持多数据源，支持容错告警，以及相当有用的多租户功能。

针对无监控告警这一点，我们采用 Prometheus+Grafana，以及 Python 脚本去做监控，分为组件级别、任务级别、服务器状态级别，以及调度报错。

最后，我们使用 HA (Namenode、ResourceManager) 管理单节点，进行故障转移。

ClickHouse 迁移方案

在迁移 ClickHouse 时，我们多种备选方案，分别是直接停机进行 copy，使用 Remote 表函数，使用 Clickhouse copier，以及 更简单的 copy 数据目录的方法。

但是从操作复杂度、全量同步、增量同步、性能等多方面考虑，我们选用了第二种方案。此方案支持全量同步和增量同步，潜意识图，性能也较好，但局限性在于不太适合达标，需要相同的拓扑结构。

ClickHouse 迁移方案 &迁移过程

迁移执行过程：

一、找出原来建表语句

select database,create_table_query from system.tables where database in('athena','dmp','sony');

二、在新的 clickhouse 创建 databases 和 table

创建数据库

create database dmp ON CLUSTER cluster_clickhouse; 创建表:导出后搞成自动化脚本去执行

三、数据迁移语句(可以用 python 写成脚本的方式去执行，可以线下交流)

insert into dmp.dws_dmp_user_local ON CLUSTER cluster_clickhouse SELECT * FROM remote('192.168.1.1:9000', dmp, dws_dmp_user, 'default', '');

四、数据迁移前的注意事项

1.cluster_5shards_1replicas-->cluster_clickhouse

2.表名后面添加 ON CLUSTER cluster_clickhouse

大数据平台迁移升级方案

在迁移 ClickHouse 为平台提供了足够空间后，我们设计了平台的迁移和升级方案。有两种备选方案：

方案一、原地升级

这种方案是卸载旧的 CDH，保留原来数据，安装新版 CDH 并升级。其优点是不需要任何额外硬件资源，但缺点是停机时间较长，需要多种验证。

方案二 、重构升级

第二种方案是安装新的 CDH 集群，将现有数据拷贝到新集群，切换为生产集群。其优点是没有数据丢失的风险，停机时间较短，缺点是需要额外的硬件资源，需要迁移数据，以及 整体升级周期较长。

由平台建议，一个实施流程基本上分为三个阶段：一个是预备期，第二个是并行期，第三个是运行期。预备期是在测试搭建一道测试环境，然后进行方案验证,验证通过后在新建一套生产集群。并行期的两个集群，老集群数据和服务的迁移到新的集群上，然后对数据和服务进行验证。就是迁移的时候要考虑到两个集群增量的数据的持平这一块。运行期新老集群割接.因方案一停机时间较长、原地升级失败后回滚风险较大，有丢失数据的风险，所以我们选择了方案二。

任务迁移流程

平台迁移流程主要包括对历史任务、Schema、批量脚本和外部应用的数据迁移。

平台迁移任务主要分为评估、测试/改在、迁移/并行、优化/割接四个阶段。

实施流程

经过搭建新集群，数据迁移，旧集群下线和新集群切换，新集群正式运行。

此外，为了进行大数据平台构建和迁移，我们还进行了数据一致性校验，Hive 元数据迁移等一系列工作。

计存分离架构

并采用计存分离的存储架构，实现数据更高效的存储。

集成 jindoFS

我们还将阿里的 jindoFS 和 CDH 集成，实现了高效的数据分析、数据加速和数据存储。

计存分离数据效果图

监控平台设计

我们设计的大数据监控主要包括两部分，一是平台资源监控，一个是任务运行状态监控。

钉钉告警

监控 BI 展示

03 调度系统迁移

调度系统调研

在调度系统上，我们原来采用的是 Oozie，但是在使用过程中发现其缺点不可忽视，比如可视化的界面差；缺乏补数、重试功能；严重依赖当前集群版本，二开难度大；配置复杂、调度任务时出现死锁；不支持租户、权限，管控能力差。

于是我们进行了调度系统重新选型。在调研过程中，我们对比了主流的调度系统工具，并决定采用 Apache DolphinScheduler。

为什么选择 Apache DolphinScheduler ？

经过对比，我们发现 Apache DolphinScheduler 的以下特性非常符合我们的业务需求：

• 通过拖拽任务绘制工作流 DAG

• 任务支持动态暂停/停止/恢复操作

• 支持失败重试/告警、容错、补数等操作

• 支持全局参数及节点自定义参数设置

• 支持集群 HA，集群去中心化

• 支持运行历史树形/甘特图展示

• 丰富的任务类型支持

调度系统支撑的业务架构

我们使用 ApahceDolphinScheduler 的 1.3.8 版本，2 个 Master 节点和 7 个 Worker 节点，1 个 API 节点，日调度流程 200+，日调度任务 5000+，服务 20+ 业务线，处理 T+1 任务场景，组件主要使用到了 Shell、Spark、Hive、Sqoop、Datax、SeaTunnel(原 Waterdrop) 和 MR。

01 迁移方案 &流程

迁移方案上，我们采用边运行边迁移，循形渐进的方式，由易到难，按业务分批迁移，验证通过后老系统任务下线。

迁移效果

通过迁移前后对比，我们可以看到系统管理更加便捷，系统更稳定，开发也更高效了。

我们选择使用 Shell 节点作为项目代码的一部分，可以在 Git 上直接维护，将代码下载到服务器上使用。

02 调度系统监控

我们还自己开发了调度监控系统，特点是包含任务实例和任务类型，以及任务开始时间和结束时间，并对任务和 ID 进行关联，可以看到报错的语句。

03 调度系统存在的问题

因为我们使用的是原生的 1.3.8 版本，没有进行二开，但是任务多了以后发现存在以下问题：

1. 分布式锁

• Master 调度工作流时依赖分布式锁，导致调度工作流吞吐量难以提升，极端情况下调度可能出现高延迟；

2. Master 资源利用率低

• Master 创建大量线程池，导致线程上下文切换频繁，大量线程处于轮询数据库状态，线程利用率低；

3. 数据库压力大

• Master 通过轮询数据库来查询任务状态，任务数多的时候导致数据库压力大；

4. 各组件存在耦合情况

• 注册中心耦合 Zookeeper

• Worker 耦合任务，需要打入许多依赖 jar 包

04 下一步计划

• 升级到 2.0 架构 ，解决 1.3 架构存在的问题；

• 定制开发与公司的多个平台集成；

• 实现跨集群任务调用，测试和生产环境共用一套任务调度；

• 完善监控告警。

05 拥抱开源

后续，我们还计划参与到更多 Apache 开源项目中。

01 为什么参与开源？

1. 提升技术功底：学习源码里的优秀设计思想，比如疑难问题的解决思路，一些优秀的设计模式，整体提升自己的技术功底；

2. 深度掌握技术框架：源码看多了，对于一个新技术或框架的掌握速度会有大幅提升 ；

3. 快速定位线上问题：遇到线上问题，特别是框架源码里的问题(比如 bug)，能够快速定位；

4. 拥抱开源社区：参与到开源项目的研发，结识更多大牛，积累更多优质人脉看源码。

02 参与开源的方法

1. 先使用：先看官方文档快速掌握框架的基本使用；

2. 抓主线：找一个 demo 入手，顺藤摸瓜快速看一遍框架的主线源码，画出源码主流程图，切勿一开始就陷入源码的细枝末节，否则会把自己绕晕，凭经验猜；

3. 画图做笔记：总结框架的一些核心功能点，从这些功能点入手深入到源码的细节，边看源码边画源码走向图，并对关键源码的理解做笔记，把源码里的闪光点都记录下来，后续借鉴到工作项目中，理解能力强的可以直接看静态源码，也可以边看源码边 debug 源码执行过程，观察一些关键变量的值；

4. 整合总结：所有功能点的源码都分析完后，回到主流程图再梳理一遍，争取把自己画的所有图都在脑袋里做一个整合。

这就是我分享的全部内容，感谢聆听！