大数据架构系列：Clickhouse + Kafka 的方案组合

普通方案

如图1，是大家常见的一种用法，所有CH节点参与分发数据的原因是因为大家想把唯一Key相同的数据分发到同一个节点，好做一些SQL查询。

如图2，也是常见的一种做法，就是数据存储在哪个节点无所谓，一般只算SUM、COUNT等聚合函数。如果业务可以使用该方案，非常OK，基本上无需考虑新方案了。

a. 优点：

• 所有节点都消费Kakfa，消费能力强。
• 使用成本相对较低，用户自己搞定。
• 图2 方案 也是推荐方案的一种。

b. 缺点：

• 消费、写入、查询都在同一个节点，影响查询。
• 集群基础负载高，线程间的上下文切换多。
• 图1 方案受限于节点个数，如果节点超过100个，数据交换和MergeTree的小文件合并能吃掉你大部分CPU使用率。
• 图1 方案你如果还想用多副本，你的ZK会‘爆炸’，原地起飞。

优化方案

如图3，使用几个高性能消费Kafka数据，然后分发到所有其他节点，其他节点只有LocalTable的写压力。测试后发现几个高性能节点来消费数据是OK的。

如图4，在图3的基础上支持多副本，集群规模不是特别大的情况下，zk的压力还是扛的住的。

a. 优点

• 有点‘读写分离’的意思，查询集群的基础负载会小很多，有利于提供稳定的查询服务。
• 查询集群可以直接突破100个节点，容易水平扩展。
• 消费Kafka集群的节点个数也可以根据上游的数据量进行收缩，对数据写入影响较小。
• 节点的都在干自己擅长的事情，效率更高。
• 在数据Hash的情况下，可以支持多副本表，且节点和单副本不会差太多，主要还是看ZK。

b. 缺点

• 需要独立配置几台Kafka 消费节点。
• 如果数据不需要Hash的话，当前方案比图2确实多了一些网络传输，数据合并压力。

三、参数配置

四、结论

在需要使用数据Hash的场景时，我们推荐使用图3、图4方案，降低查询集群的压力，降低长期的运维成本。

参考社区PR：https://github.com/ClickHouse/ClickHouse/issues/26640