ClickHouse-Benchmark基准测试实战：如何精准评估OLAP性能瓶颈

共计 1638 个字符，预计需要花费 5 分钟才能阅读完成。

背景痛点：为什么你的性能测试可能不准确

最近在帮团队优化 ClickHouse（简称 CH）集群时，发现很多性能测试存在以下典型问题：

• 数据失真：使用均匀分布的测试数据，而真实业务往往是 Zipf 分布（少数热点数据被频繁访问）
• 环境干扰：未隔离测试环境，后台 merge（合并）操作影响查询延迟
• 指标单一：只关注 QPS（每秒查询数），忽略内存驻留时间（Memory-Resident Time）等 OLAP 关键指标

举个真实案例：某次测试中，SSD 缓存未预热导致首次查询延迟高达 2 秒，而后续相同查询仅需 200ms。如果仅凭首次测试结果决策，会导致严重误判。

技术方案选型：Sysbench vs 自定义脚本

工具对比

核心方法论

1. 数据建模：
2. 使用 cityHash64() 函数生成倾斜分布的主键

3. 通过 Python 脚本模拟真实业务字段相关性

4. 压力控制：

   clickhouse-benchmark --concurrency 16 --delay 100 \
     --query "SELECT count() FROM hits WHERE UserID ='user123'"

5. --concurrency模拟并发用户数

6. --delay控制请求间隔（毫秒）

7. 指标采集：

8. 重点监控 system.merges 表中的 progress 字段
9. 通过 ASynchronousMetrics 追踪内存波动

代码实现关键片段

数据生成脚本（Python）

# 生成 Zipf 分布数据（行号 1 -10）from scipy.stats import zipf
import numpy as np

def generate_skewed_data(num_rows):
    # a= 2 表示强倾斜，值越小倾斜越明显
    zipf_dist = zipf.rvs(a=2, size=num_rows)
    return np.mod(zipf_dist, 10000)  # 限定值域

ClickHouse 配置优化（config.xml）

<!-- 关键参数调优（行号 15-20）-->
<merge_tree>
    <max_suspicious_broken_parts>5</max_suspicious_broken_parts>
    <parts_to_delay_insert>300</parts_to_delay_insert>
</merge_tree>

复杂查询示例

-- 包含 JOIN 和子查询的测试 SQL（行号 25-30）SELECT 
    u.Region,
    countDistinct(h.UserID) AS active_users
FROM hits h 
JOIN users u ON h.UserID = u.ID
WHERE h.EventDate >= today() - 7
GROUP BY u.Region
HAVING active_users > 1000

避坑指南：血泪经验总结

1. 环境隔离：
2. 避免在 K8s 等虚拟化环境运行关键测试

3. 测试前执行 SYSTEM DROP MARK CACHE 清除缓存

4. 日志影响：

5. 临时关闭query_log：

   SET log_queries = 0;

6. 测试目标明确：

7. 吞吐量测试：保持并发数稳定
8. 延迟测试：使用单线程避免干扰

验证结果展示

数据分布影响（相同硬件）

Merge 线程数调优

当 max_background_merges 从 4 增加到 8 时：
– 写入吞吐提升 42%
– 但查询延迟增长 15%（需要权衡）

延伸阅读

1. ClickHouse 官方基准测试白皮书
2. 《Designing Data-Intensive Applications》OLAP 章节
3. 论文《The Anatomy of a Large-Scale Hyperparameter Search Service》

通过这套方法，我们成功将某分析业务的查询 P99 延迟从 1.2s 降到 400ms。记住：好的基准测试不仅要会压测，更要懂业务！