挑战海量数据：基于Apache DolphinScheduler对千亿级数据应用实践( 二 ) _生活百科

需要使用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左右了。