springboot 集成 Clickhouse 查询 clickhouse查询并发

转载

mob64ca13fc220d 2024-03-28 21:48:59

0x00 背景

目前数仓业务方的实时需求大部分都通过clickhouse集群实现，为保证电商节业务方实时数据的稳定及时输出，需对clickhouse集群进行压力测试。这里先对sql查询进行测试。

现在clickhouse集群单机表和分布式表并存，单机表（目前主要在02机器上）通过机器内网ip加端口的形式进行查询，分布式表通过lb轮询分发到某一台机器进行查询。

工具：

资源：

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

springboot 集成 Clickhouse 查询 clickhouse查询并发_大数据

对于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调整（要慎重）等方式解决。
导入数据任务要避开业务方查询时间。

目前用户查询clickhouse主要通过以下三种途径：

客户端连接查询，一般为开发人员，主要进行ddl操作，无压力。
superset即席查询，一般为业务人员临时需求，qps较低，但应防止无脑sql查询，这一块可以通过quota解决。
报表系统定时任务查询，与开发沟通报表端 ch sql并发数与报表数相等（通过单报表多字段串行请求，多用户检查当前任务列表及缓存等方式），且报表端结果集有长达10分钟的缓存机制，与业务方沟通此次电商节报表数量在20左右，所以基本上到clickhouse的请求并发量很低。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。