0x00 背景
目前数仓业务方的实时需求大部分都通过clickhouse集群实现，为保证电商节业务方实时数据的稳定及时输出，需对clickhouse集群进行压力测试。这里先对sql查询进行测试。
现在clickhouse集群单机表和分布式表并存，单机表（目前主要在02机器上）通过机器内网ip加端口的形式进行查询，分布式表通过lb轮询分发到某一台机器进行查询。
0x01 测试环境
工具：
- locust：python开源的性能测试框架，通过官方jdbc内网连接查询
资源：
- clickhouse? 20.3.4?
- clickhouse-jdbc? 0.1.52
- 机器资源? 6台集群，3分片两副本，32C/256G/非SSD
- locust?0.14.6
0x02 测试计划
一.测试连接信息
| 表类型 | 表名 | 连接方式 | 连接用户 | 业务典型SQL1(逻辑简单，结果输出列较少，本地表单日查询耗时1秒内) | 业务典型SQL2（逻辑复杂，结果输出列较多，本地表单日查询耗时1-3秒） | 业务典型SQL2（逻辑复杂，结果输出列多，本地表单日查询耗时20秒以上） |
| 单机表 | pc_bubble.pc_bubble | 02机器 | rt | sql1 | sql2 | sql3 |
| 分布式表 | pc_bubble.pc_bubble_all | LB | rt | sql1 | sql2 | sql3 |
二.测试参数信息
| 查询sql | 查询日期 | 并发数/持续时间 |
| SQL1 | 近7天（轮询） | 40/5min |
| 60/5min | ||
| 80/5min | ||
| 100/5min | ||
| SQL2 | 近7天（轮询） | 10/5min |
| 20/5min | ||
| 40/5min | ||
| 60/5min | ||
| 80/5min | ||
| 100/5min | ||
| SQL3 | 近7天（轮询） | 10/5min |
| 20/5min | ||
| 40/10min | ||
| 60/10min | ||
| 70/10min |
0x03 测试数据
一、单机表
| 查询sql | 查询日期 | 并发数/持续时间?? | 请求总数 | 失败数(失败率)???????? | 响应均值（ms） | 响应最小值（ms） | 响应最大值（ms） | 响应中值（ms） | req/s |
| SQL1 | 近7天（轮询） | 40/5min???????????? | 10334 | 0 | 1159 | 593 | 2302 | 1200 | 34.33 |
| 60/5min | 15343 | 0 | 1171 | 621 | 2368 | 1200 | 50.97 | ||
| 80/5min | 16156 | 0 | 1481 | 302 | 2732 | 1500 | 53.67 | ||
| 100/5min | 17294 | 4552(26.32%)?? | 1694 | 1 | 3859 | 2200 | 57.48 | ||
| SQL2 | 近7天（轮询） | 10/5min | 4337 | 0 | 689 | 330 | 2401 | 660 | 14.41 |
| 20/5min | 5044 | 0 | 1161 | 273 | 2244 | 1200 | 16.77 | ||
| 40/5min | 5649 | 0 | 2113 | 896 | 4848 | 2100 | 18.77 | ||
| 60/5min | 4796 | 0 | 3704 | 519 | 6729 | 3600 | 15.93 | ||
| 80/5min | 4997 | 0 | 4747 | 935 | 10485 | 4600 | 16.6 | ||
| 100/5min | 17297 | 11360(65.68%) | 1706 | 2 | 9794 | 110 | 57.71 | ||
| SQL3 | 近7天（轮询) | 10/5min | 10 | 0 | 177073 | 165611 | 202541 | 170000 | 0.05 |
| 18/5min | 18 | 0 | 195050 | 186372 | 204972 | 193000 | 0.09 | ||
| 20/5min | 20 | 进程拒绝连接 |
二、分布式表
| 查询sql | 查询日期 | 并发数/持续时间 | 请求总数 | 失败数(失败率) | 响应均值? ?(ms) | 响应最小值? ??(ms) | 响应最大值 (ms) | 响应中值 (ms) | req/s |
| SQL1 | 近7天（轮询） | 40/5min | 92337 | 0 | 129 | 69 | 1788 | 120 | 306.78 |
| 60/5min | 116055 | 0 | 155 | 82 | 1141 | 150 | 385.57 | ||
| 80/5min | 124786 | 0 | 192 | 79 | 2125 | 180 | 414.56 | ||
| 100/5min | 42423 | 0 | 707 | 288 | 4320 | 660 | 140.94 | ||
| SQL2 | 近7天（轮询） | 10/5min | 10586 | 0 | 283 | 212 | 1031 | 280 | 35.17 |
| 20/5min | 29092 | 0 | 206 | 140 | 1346 | 200 | 96.65 | ||
| 40/5min | 20130 | 0 | 596 | 378 | 5943 | 570 | 66.88 | ||
| 60/5min | 59082 | 0 | 304 | 161 | 1627 | 290 | 196.29 | ||
| 80/5min | 34068 | 1 | 704 | 287 | 2683 | 670 | 113.18 | ||
| 100/5min | 23331 | 59（0.25%） | 1284 | 129 | 4621 | 1100 | 77.5 | ||
| SQL3 | 近7天（轮询) | 10/5min | 10 | 0 | 198199 | 51817 | 267899 | 217000 | 0.03 |
| 20/10min | 42 | 0 | 171876 | 47141 | 599066 | 91000 | 0.07 | ||
| 40/10min | 64 | 0 | 293820 | 40167 | 539507 | 296000 | 0.11 | ||
| 60/10min | 175 | 0 | 126770 | 30432 | 336863 | 81000 | 0.29 | ||
| 70/10min | 内存超过上限，部分机器连接失败 |
三、机器负载
?
0x04 结论
一、测试结论
- 对于clickhouse正常的查询sql（sql1及sql2），不管是单机表还是分布式表80个并发请求时系统响应时间未有明显下降，单机表能达到50+的qps，分布式表达到200+的qps。当并发数达到100时，请求出现不同情况的失败，但未导致进程异常。
- 对于clickhouse非正常的查询sql（以sql3为例。其未经过任何优化，sql中包含复杂的etl逻辑），单机表最大能承受15个左右的并发，分布式表最大能承受60个左右的并发，此时请求响应时间未有明显增加。当单机表并发达到20、分布式并发到70时，clickhouse进程直接宕掉。
- 压力测试过程中，机器主要压力在cpu和内存使用率上，个别时刻磁盘繁忙度也较高。测单机表时压力在02机器上，分布式表压力在02,03,04机器上，查看日志可知，这是因为这几台机器上有大量实时摄入的线程。
- 测试中发现，当有导入数据任务时，机器磁盘繁忙度会达到100%，对查询有明显影响，会延长返回时间。
二、优化点
- 采用聚合物化视图等方案对大数据量的pv,uv查询进行优化，常用函数如sumState/uniqState/bitmapGroup等。本次电商节已经对部分需求进行了优化，效果很好。
- etl清洗逻辑尽量在进入clickhouse之前就做好，只把结果表存入clickhouse进行查询。对于实时需求可以使用flink等方案进行。
- 对于压力测试中的机器压力，我们可以通过lb去除实时摄入机器、单机表分散到不同机器、不同机器quota调整（要慎重）等方式解决。
- 导入数据任务要避开业务方查询时间。
0x05 能否抗住电商节查询压力？？
目前用户查询clickhouse主要通过以下三种途径：
- 客户端连接查询，一般为开发人员，主要进行ddl操作，无压力。
- superset即席查询，一般为业务人员临时需求，qps较低，但应防止无脑sql查询，这一块可以通过quota解决。
- 报表系统定时任务查询，与开发沟通报表端?ch sql并发数与报表数相等（通过单报表多字段串行请求，多用户检查当前任务列表及缓存等方式），且报表端结果集有长达10分钟的缓存机制，与业务方沟通此次电商节报表数量在20左右，所以基本上到clickhouse的请求并发量很低。