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是最大的性能瓶颈点 。
在不改动源码的情况下，我们做了如下的优化：
