从Clickhouse 到 Snowflake（二）： MPP 查询层

背景

进入 2021 年，伴随着 Snowflake 的成功，大大小小的创业公司不断创立，各种 OLAP 的开源产品层出不穷，Clickhouse 凭借优秀的性能在这其中脱颖而出，内部各种极致的优化，也被津津乐道，主要包括：

• 向量化思想，业界虽然很早就有向量化的理论，并且在各大公司的产品介绍中 LLVM、向量化、SIMD 这些光鲜的名词也屡见不鲜，但是 Clickhouse 第一次把向量化这项技术在一个系统中做到极致，并被广泛使用，通过一个工程实践证明了向量化在 OLAP 系统内靠谱、可行。
• 高质量的工程实现，数据库是一个系统工程，再好的理论也需要优秀的工程实现才能交付优秀的性能。Clickhouse 把工程实现做到了极致，比如大量的使用模板技术来减少分支预测；Processor 执行框架实现各个算子的异步执行，同时兼顾 CPU Cache 的命中率。相信每个看过 Clickhouse 源码的人都会感叹“原来还可以这么用！”。此外，Clickhouse 的编译依赖做的也非常棒，它把所有的依赖都以源码的形式引入到项目中从头编译，不需要用户下载任何其他第三方依赖，编译完之后是一个完整的、没有任何依赖的二进制库。

毫无疑问 Clickhouse 是一款追求性能极致的产品，但是在使用过程中我们发现它在功能和易用性上离通用的数仓（如 Vertica，Greenplum 等）还有一些差距，主要包括：

1. 功能不足，多表 Join 支持差，用户一般需要使用大宽表；复杂的聚合容易 OOM；缺少查询优化器的支持，用户需要手动调优；
2. 兼容性不好，对 SQL 标准兼容弱，缺少一些常见的 SQL 语法支持，比如没有 SQL 相关子查询，这样很多现有工具不能直接使用，比如业务原来基于 MySQL 做 BI 报表，如果想迁移到 Clickhouse 上，语法得改写，数据得重新建模。
3. 易用性差，查询分为本地表查询和分布式表查询，比如在 Colocate Join 下用户就需要使用本地表，不易用。

为了打造一个媲美 Snowflake 的云原生数仓，为 Clickhouse 增加一个功能强大的的分布式查询层是我们必须要迈过的一道坎。

架构设计

增强 Clickhouse 的分布式查询能力，主要考虑过以下两种方案：

• 方案一，改进现有的查询层，在现在查询层的基础上，增加更多的 SQL 语法支持来兼容 SQL 标准，嵌入实现一个查询优化器，完善现有的数据 Shuffle 逻辑等。这种方式可以复用 Clickhouse 当下优秀的计算能力，但是实现上想在不侵入 Clickhouse 源码的前提下改进扩充非常难，比如 Clickhouse 纯手工打造的 SQL 解析器，想增加一条 SQL 就需要改动很多模块。
• 方案二，实现一个全新的查询层，把 Clickhouse 完全当做单机引擎来用，查询层独立于 Clickhouse，这样分布式查询层可以单独发展，不至于跟 Clickhouse 社区割裂。

与 Clickhouse 社区协同发展是保持产品生命力的重要方式，所以我们选择了方案二，架构如下图所示：

• Ma