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

文章出处来自：
https://cloud.tencent.com/developer/article/1801026
记录下，防丢失。

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

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

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

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

代码语言：txt
复制
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次。

代码语言：txt
复制
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次。这也就解释了为什么多层嵌套查询的耗时会随层数指数增加。

代码语言：txt
复制
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阶段读取数据块示意
图二 prewhere阶段读取数据块示意
一般查询语句中只会写where查询，但在执行时，Clickhouse会根据条件里是否有分区键、主键等信息，将where查询优化成prewhere查询，提升整个查询的执行效率。

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

代码语言：txt
复制
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查询。

欢迎使用Markdown编辑器

你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章，了解一下Markdown的基本语法知识。

新的改变

我们对Markdown编辑器进行了一些功能拓展与语法支持，除了标准的Markdown编辑器功能，我们增加了如下几点新功能，帮助你用它写博客：

1. 全新的界面设计 ，将会带来全新的写作体验；
2. 在创作中心设置你喜爱的代码高亮样式，Markdown 将代码片显示选择的高亮样式 进行展示；
3. 增加了 图片拖拽 功能，你可以将本地的图片直接拖拽到编辑区域直接展示；
4. 全新的 KaTeX数学公式 语法；
5. 增加了支持甘特图的mermaid语法¹ 功能；
6. 增加了 多屏幕编辑 Markdown文章功能；
7. 增加了 焦点写作模式、预览模式、简洁写作模式、左右区域同步滚轮设置 等功能，功能按钮位于编辑区域与预览区域中间；
8. 增加了 检查列表 功能。

功能快捷键

撤销：Ctrl/Command + Z
重做：Ctrl/Command + Y
加粗：Ctrl/Command + B
斜体：Ctrl/Command + I
标题：Ctrl/Command + Shift + H
无序列表：Ctrl/Command + Shift + U
有序列表：Ctrl/Command + Shift + O
检查列表：Ctrl/Command + Shift + C
插入代码：Ctrl/Command + Shift + K
插入链接：Ctrl/Command + Shift + L
插入图片：Ctrl/Command + Shift + G
查找：Ctrl/Command + F
替换：Ctrl/Command + G

合理的创建标题，有助于目录的生成

直接输入1次#，并按下space后，将生成1级标题。
输入2次#，并按下space后，将生成2级标题。
以此类推，我们支持6级标题。有助于使用TOC语法后生成一个完美的目录。

如何改变文本的样式

强调文本 强调文本

加粗文本 加粗文本

标记文本

删除文本

引用文本

H₂O is是液体。

2¹⁰ 运算结果是 1024.

插入链接与图片

链接: link.

图片:

带尺寸的图片:

居中的图片:

居中并且带尺寸的图片:

当然，我们为了让用户更加便捷，我们增加了图片拖拽功能。

如何插入一段漂亮的代码片

去博客设置页面，选择一款你喜欢的代码片高亮样式，下面展示同样高亮的 代码片.

// An highlighted block
var foo = 'bar';

生成一个适合你的列表

• 项目
  • 项目
    • 项目

1. 项目1
2. 项目2
3. 项目3

• 计划任务
• 完成任务

创建一个表格

一个简单的表格是这么创建的：

项目	Value
电脑	$1600
手机	$12
导管	$1

设定内容居中、居左、居右

使用:---------:居中
使用:----------居左
使用----------:居右

第一列	第二列	第三列
第一列文本居中	第二列文本居右	第三列文本居左

SmartyPants

SmartyPants将ASCII标点字符转换为“智能”印刷标点HTML实体。例如：

TYPE	ASCII	HTML
Single backticks	'Isn't this fun?'	‘Isn’t this fun?’
Quotes	"Isn't this fun?"	“Isn’t this fun?”
Dashes	-- is en-dash, --- is em-dash	– is en-dash, — is em-dash

创建一个自定义列表

Markdown

Text-to- HTML conversion tool

Authors

John

Luke

如何创建一个注脚

一个具有注脚的文本。²

注释也是必不可少的

Markdown将文本转换为 HTML。

KaTeX数学公式

您可以使用渲染LaTeX数学表达式 KaTeX:

Gamma公式展示 $\Gamma (n)=(n-1)!\forall n\in \mathbb{N}$ 是通过欧拉积分

$$\Gamma (z)={\int }_0^{\infty }{t}^{z-1}{e}^{-t}dt.$$

你可以找到更多关于的信息 LaTeX 数学表达式here.

新的甘特图功能，丰富你的文章

• 关于 甘特图 语法，参考 这儿,

UML 图表

可以使用UML图表进行渲染。 Mermaid. 例如下面产生的一个序列图：

这将产生一个流程图。:

• 关于 Mermaid 语法，参考 这儿,

FLowchart流程图

我们依旧会支持flowchart的流程图：

• 关于 Flowchart流程图 语法，参考 这儿.

导出与导入

导出

如果你想尝试使用此编辑器, 你可以在此篇文章任意编辑。当你完成了一篇文章的写作, 在上方工具栏找到 文章导出 ，生成一个.md文件或者.html文件进行本地保存。

导入

如果你想加载一篇你写过的.md文件，在上方工具栏可以选择导入功能进行对应扩展名的文件导入，
继续你的创作。

---

1. mermaid语法说明 ↩︎

2. 注脚的解释 ↩︎