更多技术交流、求职机会、试用福利，欢迎关注 字节跳动数据平台微信公众号，回复【1】进入官方交流群
相信大家都对大名鼎鼎的ClickHouse有一定的了解了，它强大的数据分析性能让人印象深刻。但在字节大量生产使用中，发现了ClickHouse依然存在了一定的限制。例如：
- 缺少完整的upsert和delete操作
- 多表关联查询能力弱
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:52ae1c94-68c4-4958-bccb-55a304f4d4d2[En]
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:19a76efc-c353-4b60-8433-eb99324fa0cc
- 没有资源隔离能力
因此，我们决定将ClickHouse能力进行全方位加强，打造一款更强大的数据分析平台。本篇将详细介绍我们是如何加强ClickHouse多表关联查询能力。
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:debeaaa3-6459-4582-905a-c8357a7e41c2
[En]
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:cebcc86a-9e3f-4bf9-9443-ad0f043edc3b
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:77caacc7-873c-459d-a0fa-5b5410983c33
[En]
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:5161dc7e-d67a-4809-bbe2-2d2f996ae9c9
后面，基于预计算思想的cube建模方案被提出。通过将数据ETL加工后存储在cube中，保证领导和业务人员能够快速得到分析结果基础上，获得了一定的分析灵活性。不过由于维度固定，以及数据聚合后基本无法查询明细数据，依然无法满足Adhoc这类即席查询的场景需求。
近些年，以ClickHouse为代表的具备强大单表性能的查询引擎，带来了大宽表分析的风潮。所谓的大宽表，就是在数据加工的过程中，将多张表通过一些关联字段打平成一张宽表，通过一张表对外提供分析能力。基于ClickHouse单表性能支撑的大宽表模式，既能提升分析时效性又能提高数据查询和分析操作的灵活性，是目前非常流行的一种模式。
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:5e976bef-d146-4c0a-9736-aa45c6ce3cad
[En]
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:adfa1d86-b408-4854-a49d-39af6c7e9c78
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:da71f63f-14ef-4664-8138-d55387d0c922
[En]
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:1ec4bed8-9e72-4d3e-b477-db171d35abf2
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:35080605-500c-4cf0-a385-3073d09959eb
[En]
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:e0102b64-0d77-497e-aebb-68a3b15df029
刚才有提到，数据分析的发展历程可以看作是不断追求分析效率和分析灵活的过程，那么大宽表的下一个阶段呢？如果ClickHouse的多表关联查询能力足够强，是不是连”将数据打平成宽表”这个步骤也可以省略，只需要维护好对外服务的接口，任何业务人员的需求都现场直接关联查询就可以了呢？
ClickHouse 的执行模式相对比较简单，其基本查询模式分为 2 个阶段：
ByteHouse 进行多表关联的复杂查询时，采用分 Stage 的方式，替换目前 ClickHouse的2阶段执行方式。将一个复杂的 Query 按照数据交换情况切分成多个 Stage，Stage 和 Stage 之间通过 exchange 完成数据的交换，单个 Stage 内不存在数据交换。Stage 间的数据交换主要有以下三种形式：
- 按照单（多）个 key 进行 Shuffle
- 由 1 个或者多个节点汇聚到一个节点 (我们称为 gather)
- 同一份数据复制到多个节点(也称为 broadcast 或者说广播)
单个 Stage 执行会继续复用 ClickHouse 的底层的执行方式。
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:0de37950-3eec-46d0-8e31-75fd18b06901
[En]
[TencentCloudSDKException] code:FailedOperation.ServiceIsolate message:service is stopped due to arrears, please recharge your account in Tencent Cloud requestId:886440e5-aeb1-4142-9e3a-3edfdb5bfa66
根据数据的规模和分布，ByteHouse支持了多种关联查询的实现，目前已经支持的有：
Join 算子通常是 OLAP 引擎中最耗时的算子。如果想优化 Join 算子，可以有两种思路，一方面可以提升 Join 算子的性能，例如更好的 Hash Table 实现和 Hash 算法，以及更好的并行。另一方面可以尽可能减少参与 Join 计算的数据。
Runtime Filter 在一些场景特别是事实表 join 维度表的星型模型场景下会有比较大的效果。因为这种情况下通常事实表规模比较大，而大部分过滤条件都在维度表上，事实表可能要全量 join 维度表。Runtime Filter 的作用是通过在 Join 的 probe 端（就是左表）提前过滤掉那些不会命中 Join 的输入数据来大幅减少 Join 中的数据传输和计算，从而减少整体的执行时间。以下图为例，
以SSB 100G测试集为例，不把数据打成大宽表的情况下，分别使用 ClickHouse 22.2.3.1版本和ByteHouse 2.0.1版本，在相同硬件环境下进行测试。（无数据表示无法返回结果或超过60s）
可以看到大多数测试中，ClickHouse都会发生报错无法返回结果的情况，而ByteHouse能够稳定的在1s内跑出结果。
只看SSB的多表测试有些抽象，下面从两个具体的case来看一下优化后的效果:。
经过优化后，query 执行时间从17.210s降低至1.749s。
lineorder 是一张大表，通过 shuffle 可以将大表数据按照 join key shuffle 到每个 worker 节点，减少了右表构建的压力。
经优化后，query 执行时间从8.583s降低至4.464s。
所有的右表可同时开始数据读取和构建。为了和现有模式做对比，ByteHouse这里并没有开启 runtime filter，开启 runtime filter 后效果会更快。
经过多表关联查询能力的增强，ByteHouse能够更加全面的支撑各类业务，用户可以根据场景选择是否将数据打成大宽表，均能获得非常良好的分析体验。
之所以ByteHouse在多表关联场景表现如此出色，其中一大原因就是因为字节自研了查询优化器，弥补了社区ClickHouse的一大不足。
Original: https://www.cnblogs.com/bytedata/p/16612776.html
Author: 字节跳动数据平台
Title: 字节跳动基于ClickHouse优化实践之“多表关联查询”
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/561873/
转载文章受原作者版权保护。转载请注明原作者出处！