点亮 ⭐️ Star · 照亮开源之路

GitHub:https://github.com/apache/dol...

精彩回顾

近期，初灵科技的大数据开发工程师钟霈合在社区活动的线上 Meetup 上中，给大家分享了《基于 Apache DolphinScheduler 对千亿级数据的利用实际》主题演讲。

咱们对于千亿级数据量的数据同步需要，进行剖析和选型后，初灵科技最终决定应用DolphinScheduler进行任务调度，同时须要周期性调度 DataX、SparkSQL 等形式进行海量数据迁徙。在日常大数据工作中，利用DolphinScheduler缩小日常运维工作量。

讲师介绍

钟霈合

初灵科技 大数据开发工程师

演讲纲要：

  1. 背景介绍
  2. 海量数据处理
  3. 利用场景
  4. 将来的布局

背景介绍

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是最大的性能瓶颈点。

在不改变源码的状况下，咱们做了如下的优化：

  1. 调整MaxSessionTimeout参数，加大Zookeeper会话最大超时工夫
  2. 在Zookeeper中将dataLogDir、dataDir目录拆散
  3. 独自部署一套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) ，手把手教会您( 贡献者不分程度高下，有问必答，要害是有一颗违心奉献的心 )。

增加小助手微信时请阐明想参加奉献。

来吧，开源社区十分期待您的参加。