记录黑客技术中优秀的内容,传播黑客文化,分享黑客技术精华

Global in在Clickhouse非分布式表查询中的使用

2021-04-28 15:07

Clickhouse在OLAP查询场景下有显著的性能优势,但Clickhouse在大表join查询的场景下,性能表现并不是很好,因此在实际业务场景需要多表计算时,往往是通过in+子查询的方式代替join查询,以提升查询性能。

笔者在最近的业务开发中,尝试用这种方式,性能却没有想象中那么好。分析Clickhouse的查询计划,发现子查询中的语句会多次执行,且性能开销主要来自于子查询的执行,因此总体上查询耗时很长。通过网上资料查询以及本地实验,最终在查询语句中用Global in代替in解决了子查询执行多次的问题。但在这个过程中,笔者发现网上几乎没有对该问题的解释,因此在这里记录一下,希望能对他人有所帮助。

一、发现问题

笔者最近的业务场景是人群包筛选,即根据用户的属性和行为筛选出满足特定人群画像的人。简单起见,可以把业务数据抽象成3张表(都是非分布式表),用户表user(用户及其社交账号表,社交账号指手机、微信账号等)、属性表user_attr(用户的属性,如性别、年龄等)、行为表user_action(用户参加过哪些活动)。

典型业务查询就可以用如下的SQL表示:

select distinct(sa_value) from user
where user_id in
(
select user_id from user_attr where age > 10
)
and user_id in
(
select user_id from user_action where action_name = '世界杯'
);

其中年龄大于10岁且参加过“世界杯”就是目标人群画像。实际业务场景会比这个查询复杂一些,可能会有更多的“user_id in xxx”条件(因为实际业务中属性和行为都可能分布在多个表中),但查询语句的模式不会变。

笔者信心满满的把这个查询语句丢到Clickhouse中,却发现,上述简单的查询却要执行2-3s,而单独执行内层的子查询只需要0.3-0.4s;多个条件的平铺倒是还好,只会增加一点点查询耗时,但业务场景复杂一点,用到多层嵌套的in+子查询时,查询耗时是随嵌套层数指数增加的。

下表是笔者使用测试数据,对同一张表写多层嵌套查询语句(每层的查询语句都是相同的)的测试结果,测试数据及查询结果都相同,可以看到每增加一层嵌套子查询,查询耗时基本要增加一倍。

子查询嵌套层数

查询耗时

1

26ms

2

35ms

3

63ms

4

104ms

5

191ms

6

369ms

7

742ms

8

1503ms

9

3214ms

二、问题分析及解决

Clickhouse是利用多核并行计算提升查询性能的,因此理论上在机器核心数足够的情况下,对于如下查询语句(A、B均表示某个子查询语句),A、B子查询是可以并行计算的,更多的子查询条件不会明显改变查询耗时。执行计划应该是子查询A和B都应分别计算一次,最后计算一次外层查询。但图一中该查询的查询日志显示,A、B子查询都被执行了2次

select distinct(sa_value) from user
where user_id in A and user id in B ......
图一 查询计划示意图

对于如下所示多层嵌套查询来说,理论上查询耗时应该是A、B、C单独执行耗时之和再加上最外层查询的耗时(因为需要先计算出子查询C的结果,将“user_id in C”当做一部分条件带入子查询B,然后计算出子查询B的结果,将“user_id in B”当做一部分条件带入子查询A,最后计算出子查询A,这3步是不能并行的)。执行计划应该是C、B、A依次执行一次,最后计算一次外层查询。但查看查询日志发现A被执行了2次、B被执行了4次、C被执行了8次。这也就解释了为什么多层嵌套查询的耗时会随层数指数增加。

select distinct(sa_value) from user
where user_id in
(
A and user_id in
(
B and user_id in C
)
)

而笔者的业务场景中查询比较耗时的部分就是子查询部分(过滤用户的属性和行为),因此子查询多次执行直接导致了查询耗时较大。

在网上找了很多博客和文档,都没有明确提及过这个问题。搜索子查询多次执行,搜到的文章都是说Clickhouse分布式表查询中,in子查询会被执行多次,可以用Global in代替in来避免多次执行[1]。但官网文档同时又说明对于非分布式表,请用in查询而不要用Global in。带着试一试的态度,我把上面的非分布式表查询也替换为Global in试了一下,结果查询耗时大幅降低(3s->0.8s),查询计划中子查询多次执行的情况也没有了,执行计划完全符合预期。

三、原因分析

为什么Clickhouse中in子查询会被执行多次呢?为什么Global in可以解决子查询执行多次的问题呢?在网上查了很多资料,最终github上Clickhouse的一个issue给了我思路[2]。

解释这个问题,要从Clickhouse MergeTree引擎的数据存储结构说起。MergeTree表由许多Data Part组成,Data Part在后台可以合并,形成新的Data Part;每个Data Part中的数据是按照主键排序存储的,并且主键有一个类似跳表的索引,依据跳表的key,将Data Part分为多个数据块(Granule),数据块就是MergeTree表中数据读取的最小单元。

接下来就要说到Clickhouse的prewhere查询和where查询了。Clickhouse执行where查询就是对数据做全表扫描,过滤掉不满足条件的行;而prewhere查询则可以利用分区信息和主键信息进行高效的分区修剪,在读取数据之前就依据分区和主键索引过滤掉无关的数据块,减少从磁盘读取的数据量,提升查询效率。需要注意的是,prewhere过滤之后的读取的数据块中包含满足条件的行,但并不是数据块中所有的行都满足查询条件。如图二所示,当查询条件为user_id=123时,左侧两个数据块都会被读取,但其中并不是每一行都满足user_id=123。

图二 prewhere阶段读取数据块示意

一般查询语句中只会写where查询,但在执行时,Clickhouse会根据条件里是否有分区键、主键等信息,将where查询优化成prewhere查询,提升整个查询的执行效率。

有了上面的知识背景,再来分析如下的查询语句:

select distinct(sa_value) from user where user_id in A

假设user_id在user表的主键中,“user_id in A”这个条件就会被默认优化成prewhere条件,即执行该查询时,第一步会用该条件过滤数据块,此时就需要子查询A的计算结果,这就是子查询A的第一次执行。在prewhere阶段之后,从磁盘中读取了所有满足条件的数据块,但并不是其中的每一行都满足“user_id in A”的条件,于是必须要执行where阶段的行扫描,精准过滤出哪些行满足“user_id in A”的条件,此时又需要子查询A的计算结果,于是子查询A被第二次执行。对于多层嵌套的in子查询也是同样的道理,如果带子查询的条件命中了外层查询表的主键,那么外层查询执行1次,子查询就要执行2次。

这并不是说Clickhouse的prewhere优化有bug,因为Clickhouse很难判断这种情况下是用prewhere执行比较好,还是直接用where执行比较好。例如,当user表很大,而A子查询执行的开销很小时,全表扫描user表中的数据开销远比多执行一次A子查询开销大,这时使用prewhere优化可以提升执行效率。而在笔者的应用场景中,是子查询A(用户属性表、行为表过滤)执行的开销较大,因此禁用掉prewhere优化可以带来性能的提升。

目前Clickhouse集群的optimize_move_to_prewhere参数可以控制是否使用prewhere优化,但它是一个全局设置,关掉该开关将使所有查询都无法使用prewhere优化。对于in子查询条件,将in替换为Global in可以使子查询先执行并将结果保存在临时表中,这种方式可以避免子查询多次执行,但同时该条件也就无法被优化为prewhere查询

参考文献

[1] Clickhouse官方文档,https://clickhouse.tech/docs/zh/sql-reference/operators/in/

[2] https://github.com/ClickHouse/ClickHouse/issues/13961

文章来源于互联网:Global in在Clickhouse非分布式表查询中的使用


知识来源: https://secvery.com/5646.html

阅读:111863 | 评论:0 | 标签:分布式

想收藏或者和大家分享这篇好文章→复制链接地址

“Global in在Clickhouse非分布式表查询中的使用”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

黑帝公告 📢

永久免费持续更新精选优质黑客技术文章Hackdig,帮你成为掌握黑客技术的英雄

广而告之 💖

标签云 ☁