共计 7334 个字符，预计需要花费 19 分钟才能阅读完成。
点亮 ⭐️ Star · 照亮开源之路
GitHub:https://github.com/apache/dol…
精彩回顾
近期，初灵科技的大数据开发工程师钟霈合在社区活动的线上 Meetup 上中，给大家分享了《基于 Apache DolphinScheduler 对千亿级数据的利用实际》主题演讲。
咱们对于千亿级数据量的数据同步需要 ，进行剖析和选型后，初灵科技最终决定应用 DolphinScheduler 进行任务调度， 同时须要周期性调度 DataX、SparkSQL 等形式进行海量数据迁徙。在日常大数据工作中，利用 DolphinScheduler 缩小日常运维工作量。
讲师介绍
钟霈合
初灵科技 大数据开发工程师
演讲纲要：
- 背景介绍
- 海量数据处理
- 利用场景
- 将来的布局
背景介绍
01 自研任务调度
咱们公司后期始终是用的自研的任务调度框架，随着这个调度畛域开源软件的倒退，涌现了很多像海豚调度这样十分优良的任务调度零碎，而咱们的需要曾经到了必须要引入新的任务调度零碎水平，来保障技术的更新迭代。
02 需要剖析
1、反对多租户的权限管制
咱们在日常工作中不止研发会进行工作的调度，其余的业务部门和厂商都可能会在 DS 上跑一些工作，如果没有多租户的权限管制的话，那整个集群应用起来都会十分的凌乱。
2、上手简略，反对可视化工作治理
上手简略 ，因为咱们团队外部在很多时候，开发会给到数仓 / 业务团队去应用，如果任务调度上手十分艰难，如果须要进行大量的配置或者编写代码，绝对老本就要高很多，置信在很多大数据团队都会存在这个需要，并且有些我的项目须要疾速迭代，所以对于选型的工具 必然是上手简略的。
3、反对对工作及节点状态进行监控
咱们对任务调度原生监控次要有两点需要，第一是 服务器的监控 ，能够间接通过任务调度 web 页面去看，第二是 任务调度的监控，针对工作是否胜利、执行工夫等相干数据和状态可能高深莫测。
4、反对较为不便的重跑、补数
咱们数据有实时、周期和离线三局部的，数据个性产生了这个需要，比方对于每 15 分钟或者每小时的数据工作，如果不能很好的反对重跑和补数的话，对咱们影响还是比拟大的。
5、反对高可用 HA、弹性扩容、故障容错
集群运维和故障治理方面也是须要反对的。
6、反对工夫参数
有时候须要基于工夫参数进行数据的 ETL 周期操作。
03 任务调度比照
Crontab
在 Unix 和类 Unix 零碎中周期性地执行指令或脚本，用来在 Linux 上间接执行脚本，但只能用来运行脚本。
不反对多租户权限治理、平台治理、散发执行等性能，在咱们公司中的利用是在一些特点服务器跑一些长期的脚本。
并且原生 Crontab 只反对分钟级别的调度，不反对重跑。
Rundeck
Rundeck 是一个基于 Java 和 Grails 的开源的运维自动化工具，提供了 Web 治理界面进行操作，同时提供命令行工具和 WebAPI 的访问控制形式。
像 Ansible 之类的工具一样，Rundeck 可能帮忙开发和运维人员更好地治理各个节点。
分为企业版和免费版，免费版对于咱们来说性能还是有点欠缺的。
Quartz
Quartz 是一款开源且丰盛个性的任务调度库，是基于 Java 实现的任务调度框架，可能集成与任何的 java 利用。
须要应用 Java 编程语言编写任务调度，这对于非研发团队而言，是无奈去推广应用的。
xxl-job
是一款国产开发的轻量级散布式调度工具，但性能比海豚调度少。
其不依赖于大数据组件，而是依赖于 MySQL，和海豚调度的依赖项是一样的。
Elastic-Job
是基于 Quartz 二次开发的弹性分布式任务调度零碎，初衷是面向高并发且简单的工作。
设计理念是无中心化的，通过 ZooKeeper 的选举机制选举出主服务器，如果主服务器挂了，会从新选举新的主服务器。
因而 elasticjob 具备良好的扩展性和可用性，然而应用和运维有肯定的复杂度。
Azkaban
Azkaban 也是一个轻量级的任务调度框架，但其毛病是可视化反对不好，工作必须通过打一个 zip 包来进行实现，不是很不便。
AirFlow
AirFlow 是用 Python 写的一款任务调度零碎，界面很高大上，但不符合中国人的应用习惯。
须要应用 Python 进行 DAG 图的绘制，无奈做到低代码任务调度。
Oozie
是集成在 Hadoop 中的大数据任务调度框架，其对工作的编写是须要通过 xml 语言进行的。
04 抉择 DolphinScheduler 的理由
1、部署简略，Master、Worker 各司其职，可线性扩大，不依赖于大数据集群
2、对工作及节点有直观的监控，失败还是胜利可能高深莫测
3、工作类型反对多，DAG 图决定了可视化配置及可视化工作血统
4、甘特图和版本控制，对于大量工作来说，十分好用
5、可能很好满足工作需要
大数据平台架构
数据流图
海量数据处理
01 数据需要
数据量：每天上千亿条
字段数：上百个字段，String 类型居多
数据流程：在数据仓库中进行加工，加工实现的数据 放入 CK，利用间接查问 CK 的数据
存储周期：21 天~60 天
查问响应：对于局部字段须要秒级响应
02 数据同步选型
Sqoop
Sqoop 是一款开源的工具，次要用于在 Hadoop(Hive)与传统的数据库 (mysql、postgresql…) 间进行数据的传递，在 DolphinScheduler 上也集成了 Sqoop 的任务调度，然而对于从 Hive 到 ClickHouse 的需要，Sqoop 是无奈反对的。
Flink
通过 DS 调度 Flink 工作进行或者间接构建一套以 Flink 为主的实时流计算框架，对于这个需要，不仅要搭建一套计算框架，还要加上 Kafka 做音讯队列，除此之外有减少额定的资源开销。
其次须要编写程序，这对于前面的运维团队是不不便的。
最初咱们次要的场景是离线，单比拟吞吐量的话，不如思考应用 Spark。
Spark&SparkSQL
在不思考环境及资源的状况下，Spark 的确是最优抉择，因为咱们的数据加工也是用的 SparkSQL，那当初的状况就是对于数据同步来说有两种形式去做。
第一种是加工进去的数据不长久化存储，间接通过网络 IO 往 ClickHouse 外面去写，这一种形式对于服务器资源的开销是最小的，然而其危险也是最大的，因为加工进去的数据不落盘，在数据同步或者是 ClickHouse 存储中发现异常，就必须要进行从新加工，然而上面 dws、dwd 的数据是 14 天清理一次，所以不落盘这种形式就须要再进行思考。
第二种形式是加工进去的数据放到 Hive 中，再应用 SparkSQL 进行同步，只是这种的话，须要消耗更多的 Yarn 资源量，所以在一期工程中，因为资源量的限度，咱们并没有应用 SparkSQL 来作为数据同步计划，然而在二期工程中，失去了扩容的集群是齐全足够的，咱们就将数据加工和数据同步全副更换为了 SparkSQL。
SeaTunnel
SeaTunnel 是 Spark 和 Flink 上做了一层包装，将本身的配置文件转换为 Spark 和 Flink 的工作在 Yarn 上跑，实现的话也是通过各种配置文件去做。
对于这个场景来说，SeaTunnel 须要消耗 Yarn 资源。
DataX
所以通过多方面的调研，最终抉择一期工程应用 DataX 来作为数据通过工具，并应用 DolphinScheduler 来进行周期调度。
03 ClickHouse 优化
在搞定数据加工和数据同步架构之后，就须要进行 ClickHouse 的优化。
写入本地表
在整个集群中最开始是用的 Nginx 负载平衡写，这个过程中咱们发现成果不现实，也尝试了用分布式表写，成果晋升也不显著，前面的话咱们的解决方案就是调整写入本地表，整个集群有多台设施，别离写到各个 CK 节点的本地表，而后查问的时候就查分布式表。
应用 MergeTree 表引擎家族
ClickHouse 的一大外围就是 MergeTree 表引擎，社区也是将基于 MergeTree 表引擎的优化作为一个重点工作。
咱们在 CK 中是应用的 ReplicatedMergeTree 作为数据表的本地表引擎，应用的 ReplicatedReplacingMergeTree 作为从 MySQL 迁徙过去的数据字典的表引擎。
二级索引优化
第一个的优化点是二级索引的优化，咱们把二级索引从 minmax 替换到了 bloom_filter，并将索引粒度更改到了 32768。
在二级索引方面的话咱们尝试过 minmax、intHash64、halfMD5、farmHash64 等，然而对于咱们的数据而言的话，要么就是查问慢，要么就是入数据慢，起初改为了 bloom_filter 之后写入才均衡了。
小文件优化
在数据加工后，呈现的小文件十分多，加工进去的小文件都是 5M 左右，所以在 SparkSQL 中增加了参数，从新加工的文件就是在 60M~100M 左右了。
set spark.sql.adaptive.enabled=true;
set spark.sql.adaptive.shuffle.targetPostShuffleInputSize=256000000;参数优化
CK 的优化参数十分多，除了根底的参数外，在二级索引调整为布隆过滤器后，写入 CK 的 parts 就比原来多了，在这个时候调整 CK 的 parts 参数，使其能够失常运行，然而这个参数会略微影响一下 CK 查问的性能，对于咱们来说，数据都放不进去，再查问也就没有用了。
parts_to_delay_insert：200000此外还能够增加 background\_pool\_size 参数（咱们没有用）。
Zookeeper 优化
对于 ClickHouse 多分片多正本集群模式来说，Zookeeper 是最大的性能瓶颈点。
在不改变源码的状况下，咱们做了如下的优化：
- 调整 MaxSessionTimeout 参数，加大 Zookeeper 会话最大超时工夫
- 在 Zookeeper 中将 dataLogDir、dataDir 目录拆散
- 独自部署一套 CK 集群专供 ClickHouse 应用，磁盘抉择超过 1T，而后给的是 SSD 盘
04 海量数据处理架构
一期技术架构
Hive 数仓架构——Hive——SparkSQL——DataX——DataX Web——DolphinScheduler——ClickHouse
二期架构 1
二期架构 2
05 数据同步操作
DataX 技术原理
DataX 是阿里巴巴开源的一个异构数据源离线同步工具，致力于实现包含关系型数据库(MySQL、Oracle 等)、HDFS、Hive、ODPS、HBase、FTP 等各种异构数据源之间稳固高效的数据同步性能。
DataX 在应用上比较简单，两局部 一个 Reader 和一个 Writer，在配置下面的话次要也是针对这两局部进行配置。
DataX 反对的插件十分多，除了官网曾经打进包外面间接能够应用的插件，还能够本人从 Github 下面下载源码进行 Maven 编译，像 ClickHouse、Starrocks 的 writer 插件都须要这么去做。
06 DataX 在 DS 中的利用
应用 DataX 须要在 dolphinscheduler_env.sh 文件中去指定 datax 的门路。
export DATAX\_HOME=${DATAX\_HOME:-/opt/module/datax}
之后 DataX 能够有三种形式去应用。
第一种形式的应用“自定义模板”，而后在自定义模板中去编写 DataX 的 json 语句：
第二种形式是通过 DS 自带的选型，而后编写 SQL 去应用 DataX，在 DS 中能够通过可视化界面配置的插件有_MySQL、PostgreSQL、ClickHouse、Oracle、SQLServer：_
第三种形式是在 DS 中建设 shell 工作，而后通过 shell 去调用部署在服务器上的 DataX 脚本，并且要把脚本放到 DS 的资源核心外面：
第一种形式对咱们来说是最不便也是适配性最强的形式，第二种和第三种的话就要依据状况去应用了。
07 DataX 的应用
在 DataX 外部对每个 Channel 会有严格的速度管制，分两种，一种是管制每秒同步的记录数，另外一种是每秒同步的字节数，默认的速度限制是 1MB/s，能够依据具体硬件状况设置这个 byte 速度或者 record 速度，个别设置 byte 速度。
咱们的 channel 的话是依据每个工作的数据量条数、大小进行屡次调优后得出的，这个要依据本人的数据状况进行适配，我的工作最大的一个数据量配置的是总的record 限速是 300M/s，单个 channel 的 record 限速是 10M/s。
{然而 channel 并不是越大越好，过分大反而会影响服务器的性能，会常常的报 GC，一报 GC 的话，性能就会降落。
个别咱们的服务器，配置了下面的参数后，一个工作没事，如果多个 DataX 工作同时在一台服务器上跑的话并且 JVM 设置得过小的话，个别 5 分钟会报一次 GC。
依据方才的调控，显著一个 DataX 工作中的 channel 数是增多了的，这就示意 占用的内存也会减少，因为 DataX 作为数据交换通道，在内存中会缓存较多的数据。
在 DataX 中会有一个 Buffer 作为长期的内存替换的缓存区，而且在 Reader 和 Writer 中，也会存在一些 Buffer 用来缓存数据，JVM 报 GC 的话次要也是在这下面报，所以咱们须要依据配置调整 JVM 的参数。
个别我的工作参数会用 DS 的参数进行管制，如下所示，个别设置为 4G~16G，这个的话得依据硬件的性能来决定。
$DATAX_HOME：/opt/beh/core/datax/pybin/datax.py –jvm=”-Xms8G -Xms8G” -p”-Da=1″
将内存和 CPU 调优做了之后，再往下就是对 Reader 和 Writer 的根底配置，比如说 HDFS 门路、Kerberos 相干、字段的映射关系、CK 的库表等等。
最初一部分就是咱们在应用的时候，发现即便对 CK 做了优化，还是会报 parts 过多的谬误，通过排查，DataX 的 ClickHouse Writer 是通过 JDBC 近程连贯到 ClickHouse 数据库，而后利用 ClickHouse 裸露的 insert 接口将数据 insert into 到 ClickHouse。依据 ClickHouse 个性，每一次的 insert into 都是一个 parts，所以不能一条数据就 insert 一次，必须大批量的插入 ClickHouse，这也是官网举荐的。
所以咱们对 DataX 的 batchSize 进行了优化，优化参数如下：
"batchSize": 100000, 利用场景
01 元数据备份
应用 DS 周期性备份 Hive 元数据、CDH 元数据、HDP 元数据、DS 本人的元数据，并将其上传到 HDFS 中进行保留。
02 任务调度
对 Shell、SparkSQL、Spark、DataX、Flink 等工作进行调度，目前的工作点次要是分为新加工作和老工作迁徙。
新加工作的话就是新我的项目的工作咱们会推动业务部门及其余研发核心将工作上到 DS 调度平台，老工作迁徙的话阻力比拟大，就是把之前的离线、流式和 shell 工作给迁徙到 DS 上，迁徙的过程中将一些老旧的 MR 代码改为 Spark 或者 Flink 后放到 DS 上来跑。
03 甘特图
04 数据清理
次要就是针对局部数据有寄存周期的，须要周期对 Hive、HDFS，还有一些服务器上的日志进行周期清理。
将来的布局
1、从某一个任务调度零碎往 DS 进行工作迁徙的工具，半自动化，帮忙推动 DS 的在调度畛域的利用。
2、DS 集群部署、降级工具，缩小运维工作量。
3、从定制化监控转变为插件式监控，从高代码到低代码的转变，时监控告警更加灵便，及早发现节点、工作流、数据库、工作等的问题。
4、二次开发，减少只读场景、回收站性能，增多判断条件及性能，资源批量上传等，助力大数据。
5、集成 API 网关性能，对协定适配、服务治理、限流熔断、认证受权、接口申请等进行一站式操作。
我的分享就到这里，感激！感兴趣的敌人能够进入社区跟我探讨，增加社区小助手即可拉入中国区用户组~
最初十分欢送大家退出 DolphinScheduler 小家庭，融入开源世界！
咱们激励任何模式的参加社区，最终成为 Committer 或 PMC，如：
- 将遇到的问题通过 GitHub 上 issue 的模式反馈进去。
- 答复他人遇到的 issue 问题。
- 帮忙欠缺文档。
- 帮忙我的项目减少测试用例。
- 为代码增加正文。
- 提交修复 Bug 或者 Feature 的 PR。
- 发表利用案例实际、调度流程剖析或者与调度相干的技术文章。
- 帮忙推广 DolphinScheduler，参加技术大会或者 meetup 的分享等。
欢送退出奉献的队伍，退出开源从提交第一个 PR 开始。
- 比方增加代码正文或找到带有”easy to fix”标记或一些非常简单的 issue(拼写错误等) 等等，先通过第一个简略的 PR 相熟提交流程。
注：奉献不仅仅限于 PR 哈，对促成我的项目倒退的都是奉献。
置信参加 DolphinScheduler，肯定会让您从开源中受害！
参加奉献
随着国内开源的迅猛崛起，Apache DolphinScheduler 社区迎来蓬勃发展，为了做更好用、易用的调度，真挚欢送酷爱开源的搭档退出到开源社区中来，为中国开源崛起献上一份本人的力量，让外乡开源走向寰球。
参加 DolphinScheduler 社区有十分多的参加奉献的形式，包含：
奉献第一个 PR(文档、代码) 咱们也心愿是简略的，第一个 PR 用于相熟提交的流程和社区合作以及感触社区的友好度。
社区汇总了以下适宜老手的问题列表：https://github.com/apache/dol…
非老手问题列表：https://github.com/apache/dol…
如何参加奉献链接：https://dolphinscheduler.apac…
来吧，DolphinScheduler 开源社区须要您的参加，为中国开源崛起添砖加瓦吧，哪怕只是小小的一块瓦，汇聚起来的力量也是微小的。
参加开源能够近距离与各路高手切磋，迅速晋升本人的技能，如果您想参加奉献，咱们有个贡献者种子孵化群，能够增加社区小助手微信(Leonard-ds)，手把手教会您(贡献者不分程度高下，有问必答，要害是有一颗违心奉献的心)。
增加小助手微信时请阐明想参加奉献。
来吧，开源社区十分期待您的参加。