ClickHouse万亿数据双中心的设计与实践

1 .ClickHouse万亿数据双中心的设计与实践 百分点 赵群（微信:5832842) 

2 . • 场景与挑战 CONTENTS OLAP引擎评估与相关测试分析 目 • • ClickHouse的2地双中心设计 录 • ClickHouse写入的稳定性设计 • ClickHouse的查询优化设计 • 最佳实践配置 

3 .场景与挑战 数据量：2000亿+/日 高峰：500WRow/s 延时：<30秒 熔断/限流 存储与处 2地双中心 查询 理 1TB常规查询<10s 查询/分析透明访问 1TB聚合查询(排序/分组） <5m 挑战 离线任务 

4 .OLAP引擎评估 业 务： 1、超大规模的单表查询/分析； 2、有一定的并发要求； 3、实时性要求； 1. PB级的数据存储 2. 高性能的查询/分析能力 ClickHouse Presto 3. 低延时写入及吞吐能力 HAWQ 4. 数据压缩 Druid 5. 跨中心能力 Elastic Search 

5 .OLAP引擎评估 

6 .ClickHouse的2地双中心设计 Nginx Grafana日志监控展现 SparkStreaming 查询入口 ClickHouse 日志表 分布式表 （配置文件） DC DC 日志本地表 日志本地表 Shard1 Shard2 日志本地表Shard1 日志本地表Shard2 Shard1 Shard2 Replication Replication DC1 数据 DC2 数据 客户端写入本地表 1. ClickHouse跨中心透明访问。性能影响：1/4 ～1/3 2. 禁止分布式写。 3. 经过设计Replication是有稳定保障的 4. Nginx负载均衡，路由分发，安全加固 5. 日志采集、展现、分析 

7 .ClickHouse磁盘Raid的选择 1、Raid5增加磁盘数据可靠性和读取能力 2、热备盘减少运维压力 3、控制写入，保障查询性能 Raid0 - >Raid5演进 /data1 Raid5数据恢复影响 本地表 Shard1 Raid5 /data1 单台物理机 

8 .相关测试分析 PageCache缓存对查询的影响 横向扩展对查询性能几乎无影响 数据预热对查询有数量级提升 可以基于单节点/分区评估查询性能 针对缓存更换条件同样生效 

9 .ClickHouse写入的稳定性设计 1、20W/s （35次）提交，并发50 2、10W/s(17次)提交，并发90 Raid 3、5W/s(8次)提交，并发90 确保业务命中在安全区域 1、平衡好合并速度和Part数量的关系，一定是需要相对均衡的。 2、Part数量，实际代表着提交频率，一定是稳定，且经过估算的。 3、ClickHouse的查询和写入共同受限于Query数限制，需要分配好配额。 4、禁止直接写入分布式表。 

10 .ClickHouse写入的稳定性设计 Kafka Topic Spark Time Windows MaxRatePerPatition Partition1 Executor Pull Executor 目标源 Partition2 Executor Partition3 1. 时间窗口保障持续稳定提交频率。（保障对ClickHouse写入的稳定） 2. SparkStreaming 微批处理（控制处理上限），利用反压机制，实现处理能力动态平衡。 3. Spark on Yarn 资源可控。 4. 以写入ClickHouse为例，目前一个Executor处理在30000/s 左右。 5. 假设我们需要一个满足300W/s的处理能力。 在源读取没有瓶颈的情况下，可以 Executor数 : 300 /3 = 100（个）。 

11 .ClickHouse的查询优化设计 Grafana日志监控展现 Nginx SparkStreaming 查询入口 ClickHouse 日志表 分布式表 （配置文件） 1、限制单条查询内存使用量和单节点查询内存使用量，预防节点Down机。 2、Query数量限制异常：控制好配额/连接池。 3、集群的Query日志，找出慢查询。我们直接通过Nginx收集了原始日志。 4、针对热数据进行查询预热。 

12 .最佳实践配置 

13 .ClikHouse的监控 服务、磁盘、负载 ClickHouse实时写入吞吐，查询监控 根据容量配置预警线 32392626428 2067962 

14 .用数据智能推动社会进步