揭秘字节跳动解决ClickHouse复杂查询问题的技术方案 _ClickHouse

导读：ClickHouse已经成为行业主流且热门的开源引擎。随着业务数据量扩大，场景覆盖变广泛，在复杂query场景下，ClickHouse容易存在查询异常问题，影响业务正常推进。本次主要分享字节跳动如何解决ClickHouse复杂查询问题，并详细解读技术实现细节，目前该能力已经通过火山引擎ByteHouse面向开发者输出。
全文将围绕以下几方面展开：

项目背景
技术方案
优化与诊断
效果及展望

01
项目背景
1. ClickHouse执行模式
ClickHouse 的执行模式相对比较简单，和Druid、ES 类似，其基本查询模式分为两个阶段：

文章插图

第一阶段，Coordinator 收到查询后将请求发送给对应的 worker 节点；
第二阶段，Coordinator 收到各个 worker 节点的结果后汇聚起来处理后返回。
以下面的SQL为例：
Select name from student_distribute where id = 5
①当 Coordinator 收到请求后，由于student_distribute是一个分布式表，因此需要将sql 改写为对local表查询，并转发请求给每一个shard的worker；
②Worker收到请求后查询本地的local表数据，返回结果给coordinator；
③Coordinator汇总每一个shard的数据并把结果返回给client 。
Select name from student_local where id = 5
第二阶段执行的模式能够高效地支持很多常见场景，比如常见的针对大宽表的各类查询，但是随着业务场景的复杂化，也存在以下三点问题：
其一，第一阶段返回的数据比较多且第二阶段的计算比较复杂时，对于Coordinator的压力会比较大，容易成为query的瓶颈，且shard越多可能计算越慢，瓶颈越大。例如一些重计算的agg算子count distinct 。如果我们使用hash表去重时，第二阶段需要在coordinator单机上merge各个worker的hash表，计算量很重且不能并行；又比如说group by基数比较大或者window计算。
其二，join是SQL的重要场景。由于不支持Shuffle操作，对于Join来说右表必须是全量数据。无论是普通Join还是Global Join，当Join的右表比较大时都放到内存里容易OOM，而Spill到磁盘虽然解决内存问题，可能会因为有磁盘 io和序列化计算的开销影响性能。特别是当Join为最常见的Hash Join 时，右表如果是大表构建也比较慢。虽然社区最近也做了一些右表构建的优化，通过单机按照 join key split 来达到并行构建hash table 。但是额外的代价是左右表都增加了一次 split 操作。
其三，对于复杂查询（如多表 Join、嵌套多个子查询、window function等）的支持并不友好，由于不能通过shuffle来分散数据，生成的pipeline在一些case下不能充分并行，难以充分发挥集群的全部资源。
2. 其他MMP数据库
目前主流的MPP数据库基本都支持Stage执行的方式。以Presto为例，如下图所示，一个两表join的agg sql可拆分为5个 Stage 。

文章插图

其中 Stage3、Stage4分别对应左右表数据读取，Stage2完成两表Join和partial agg 计算，Stage1完成final agg计算，Stage0收集Stage1的数据后汇总和输出。在这个过程中，Stage 3、4、2、1可以在多个节点上并行执行，单个复杂的query被拆分成若干Stage，从而实现了Stage之间，不同worker的数据传输。
3. 业务背景和目标
随着业务复杂程度提高，业务并不希望所有的数据都通过etl 产生大宽表；复杂查询（特别是多轮分布式 Join和比较多的agg）的需求越来越强烈，而整体的数据量又在不断增长。在集群资源有限的情况下，我们希望能够充分利用机器资源，基于ClickHouse 高效地支持复杂查询。
ByteHouse是字节跳动研发同学基于开源ClickHouse 进行了深度优化和改造的版本，提供海量数据上更强的查询服务和数据写入性能，支持多种应用场景。如图所示，ByteHouse在内部多个场景如行为分析、画像分析、智能营销分析、App 日志分析上得到充分的验证和使用，并在多个方面进行了增强，具备特有的能力。