百分点科技大数据技术团队：基于多Spark任务的ClickHouse数据同步方案实践

编者按：在数据大爆发的时代里，数据分析和应用领域对数据即查即得的需求越来越迫切，ClickHouse凭借无与伦比的查询速度脱颖而出，被广泛应用于众多领域和方案中，是优秀的OLAP代表者。但是实践应用中，尤其是需要代码操作时会遇到一定的性能问题，尤其在数据量大的情况下表现更为突出。本文针对实践场景中遇到的问题，结合Spark技术与集群资源对ClickHouse进行解剖和分析，并借助百分点科技在某数据中台项目中的案例，逐层分析并给出解决方案，文章偏向技术实践和应用，通用性较强。
一、概览
百分点科技是国内最早探索数据价值落地的公司之一，早在2017年，百分点大数据技术团队就开始深入探索和研究ClickHouse，并在国家级项目中得到最佳实践，获得客户一致好评。凭借雄厚的技术实力和成熟的解决方案，百分点科技已经完成上万家客户服务，依靠强大的团队力量、多年的项目实战经验和技术积累，在众多领域和行业沉淀出优秀的解决方案，并积累了夯实的实战经验。
在此引用早在2019年百分点大数据技术团队对CK的实践总结：
百分点科技使用规约：禁止采用CK分布式写入，通过本地表写入。
充分利用SparkStreaming的流量控制和反压机制。
在写入ClickHouse时合理控制时间频率。
文章 | 百分点大数据技术团队：ClickHouse国家级项目最佳实践
作为服务全球企业和政府的数据智能公司，百分点科技拥有成熟、完善的数据仓库理论和数据治理方案。本次某集团数据中台项目也同样运用本套解决方案，从不同系统中进行数据接入，历经ODS、DWD、DWS等各个层次的数据处理，最终产出完美型数据结果，并集中分布在DM集市层。其实数据集市层已经具备对外提供访问和数据呈现的能力，例如对接BI系统、对接WEB页面、对接上下系统交互、对接多个第三方系统检索、对接数据置换等。
但Hive受限于Hadopp生态圈，无法做到快速既查即得的效果，尤其这种结果型数据的使用，频繁的查询和调取，几乎不可能满足业界对Hive的期待，在数据仓库和数据应用方之间亟待需要一种既查即得、满足各种严格的高性能数据库系统。在众多OLAP领域，ClickHouse凭借其无与伦比的查询速度和诸多特性脱颖而出，成为了OLAP使用场景中优秀的代表者。
ClickHouse特性：
列式存储数据库，数据压缩；
关系型、支持SQL；
分布式并行计算，把单机性能压榨到极限；
高可用；数据量级在PB级别。
选择ClickHouse，就不能逾越各种数据的接入和各种介质的数据输出。从Hive到ClickHouse，从ClickHouse到其他存储介质的需求也常常存在。那么，如何做到彼此之间更好地衔接和更高效地传输，本文将作为专题进行详细讲解，希望能够跟大家一起讨论、学习和进步。
二、案例分析
可能有的同学会有疑问，使用CK查数据已经很快了，为啥还要需要这么折腾呢？
用过ClickHouse的同学们都清楚，CK分两种表，一种是分布式和一种是本地表，分布式表是做查询用的，本地表是做存储用的。一张本地表等同于一份数据的分片，通常一张表会分成多个本地表分布存储，从而达到海量存储和负责均衡的集群效应。写入ClickHouse的时候会按照一定的均衡方式，均匀地落在不同本地表中，假如100万数据需要写入CK，假如CK集群有三个主节点，则每个主节点的本地表会存33w左右，假如CK集群有四个节点，则每个节点存25w左右，以此类推。
为方便大家更好的思考和理解，后边会以三主三备的ClickHouse集群为案例进行讲解，首先先了解一下ck分布式表查询的过程图解：

图一：ClickHouse分布式表查询过程
如上图所示，在每个节点执行