关于大数据:大数据平台迁移实践-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. 整合总结：所有性能点的源码都剖析完后，回到主流程图再梳理一遍，争取把本人画的所有图都在脑袋里做一个整合。

这就是我分享的全部内容，感激凝听！