前两天在刷朋友圈,看到一个视频号链接,说有个云数仓,比ClickHouse 还快3倍。我就点进去看了,原来是 SelectDB  公司的“为数而生,因云而新” SelectDB 产品发布会。这个发布会上 SelectDB 发布了云数仓产品SelectDB Cloud
这个视频里面的测试结果显示,在单表聚合场景下,SelectDB Cloud 的性能是  ClickHouse 的3.4倍。我看了整个视频,包括测试相关的部分。
这个测试是在 SelectDB Cloud 上选了3台 medium 套餐,也就是单节点16 core vcpu,64G内存。然后在相同的环境下对其他的产品也进行了测试。测试的具体结果如下图所示;
ClickHouse 本身就是以单表查询闻名于世的大数据引擎。ClickHouse 为什么能够做到单表查询这么快,从技术的角度来说,大体上有这么三个方面的原因。
首先,ClickHouse 的查询引擎是一个经典的 MPP 架构。MPP 架构的好处是可以充分利用多节点的并行。如果实现得好,也可以充分利用节点内的多核并行。可以这样说,如果一个数仓不用 MPP 架构实现的话,今天这个竞争激烈的环境下,这个数仓完全没有竞争性。在上图中,连单表聚合查询最慢的 Presto,也是一个经典的 MPP 架构引擎。
其次,ClickHouse 的查询引擎,参考和继承了 MonetDB/X100 的实现,用的是向量化的执行引擎。MonetDB/X100 的创始人Marcin Zukowski,当然也是大名鼎鼎的,不但 PhD 一毕业就创立了 Vectorwise  公司,并成功卖给了Ingres。后来,他更是成为了云数仓领导者 Snowflake 的创始人之一。
向量化执行引擎就是 Marcin Zukowski 在 PhD 期间发明并壮大的,在 ClickHouse 这里又得到了进一步的提升。ClickHouse 对很多 operator 的向量化引擎的实现,大量使用 SMID 指令,同时结合了列式内存的布局,算子的性能提高非常的显著。
最后,ClickHouse 在数据的存储上采用了列式的 MergeTree 存储方式。这也使得数据的编码,压缩和处理都可以很高效。ClickHouse 也和 Redshift 或者 Snowflake 一样,给自己的 MergeTree 提供了不同的索引结构,比如说 inverted index 索引,bloom filter 索引等。
这些技术的结合,成就了 ClickHouse 在单表查询领域世界赫赫有名的地位。也让 ClickHouse 这个后起之秀,在大数据开源项目中一骑绝尘。
SelectDB Cloud 能够领先 ClickHouse 3.4倍的单表查询性能,是非常不容易的。这一定和产品的实现有密切的关系。
产品发布会的视频里提到 SelectDB Cloud 的技术实现。和ClickHouse 一样,SelectDB Cloud 的查询引擎,使用的是 MPP 架构,不但实现了多节点的并行,也很好的实现了节点内的多核并行。
SelectDB Cloud 在数据处理的时候,也采用了列式内存布局和向量化计算框架。这些技术大幅度减少了虚函数的调用,提高了 cache 的命中率。SelectDB Cloud 在向量化计算框架中也大量使用 SMID 指令提升了算子的性能数十倍。
SelectDB Cloud 在数据存储上采用的也是流行的列式存储。但是我不知道是不是类似Merge-Tree的结构。同时,SelectDB Cloud 在列式存储上支持多种索引结构,比如 sorted short key 索引,智能 zonemap 索引,bloom filter 索引,inverted index 索引等。这些索引可以有效的对数据进行剪枝,大大加速数据扫描。
总之我们可以看到,SelectDB Cloud 具备了 ClickHouse 在架构上的所有优势,并进行了改进。我想这是 SelectDB Cloud 能够在 ClickHouse 最擅长的领域击败 ClickHouse 的原因吧。
进一步的研究还可以发现,在分析型数据库性能测试排行榜 ClickBench 中,SelectDB 排名第一。这说明 SelectDB Cloud 确实是性能非常的优越。
虽然说,ClickHouse 是以单表查询性能闻名的产品。但是,业界也有共识,ClickHouse 这款产品的缺点同样很明显。在多表关联的查询下,ClickHouse 的性能非常的难看。

造成 ClickHouse 多表关联查询性能难看的原因有很多。我们说两个最主要的。
首先是ClickHouse的优化器只有 RBO 没有 CBO,这就使得 ClickHouse 没办法实现高效率的 join reordering,对 join 的支持就很差。
其次,ClickHouse 在执行引擎层面没有实现分布式系统join最关键的 distributed shuffle 的操作。所以它在执行层面也无法支持对 join 的高效率执行。
从这两个角度来看,云数仓比如 Snowflake 或者 Redshift 的性能在多表关联查询场景下,都会比 ClickHouse 好很多。

那么,SelectDB Cloud 在多表关联查询下的表现到底是更像 ClickHouse 呢,还是更像 Redshift 和 Snowflake 呢?这个发布会告诉我们,是后者。

SelectDB Cloud 不但宽表的查询速度很有优势,在多表关联场景下优势也同样非常的明显。
根据在同样的测试环境下对 TPC-H 的 sf100 测试发现,SelectDB Cloud 是主流友商云数仓 Redshift 的1.5倍,Snowflake 的2.5倍。至于 ClickHouse,SelectDB Cloud 是它的49倍。
一方面,SelectDB Cloud 在优化器的实现上采用了 RBO 和 CBO 相结合的办法, RBO 完成常量折叠,公共表达式提取,列裁剪,算子合并,谓词下推等优化。CBO 基于 cascade 框架,结合相关的统计信息和代价模型,完成 join reordering, CTE 优化,runtime filter 等相关的优化。
另外一方面,SelectDB Cloud在对多表关联查询的 join 操作上实现了对多张大表的分布式 shuffle join 的支持,同时还能支持数据的 colocate join 和 bucket shuffle join 的优化。这些实现大幅度减少了数据传输,提高了 join 的性能。
此外,SelectDB Cloud 还支持类似 runtime filter 等 adapative query execution 技术,结合运行状态来动态调整执行,来达到最佳的性能。
除了上述的所有技术以外,物化视图技术,是加速数据查询的一个非常有效的办法。通过事先计算好需要查询的结果,物化视图可以让复杂的查询执行的非常的快。SelectDB Cloud 也实现了对物化视图的支持。
如果单独来看,SelectDB Cloud 里所采用的技术,很多都是在其他产品里面也采用的。比如说 MPP 技术是通行的数仓架构。比如说 ClickHouse 也采用了列存和向量化执行引擎。又比如说,Redshift 和 Snowflake 都实现了 CBO。
但是,能够把所有的这些技术都实现好,并融合在一起,这是需要技术团队的技术水平的。并非每个产品都可以全面的高效率的实现所有技术的。比如说 ClickHouse 的向量化引擎做的很好,但是查询优化器就不行了。Redshift有 CBO,但是它的向量化引擎显然没有 ClickHouse 有名。
但是 SelectDB Cloud 做到了无论是在单表查询,还是在多表关联查询的时候,都能够表现出优异的性能,这就非常的不容易了。所以,SelectDB Cloud 这款产品,还是相当的牛逼的。
当然,性能只是一方面,一款产品能不能成功,还取决于很多其他方面。
SelectDB Cloud 不仅仅性能很优越,性价比也非常的有竞争力。SelectDB Cloud 作为一个云数仓,不仅仅实现了存储和计算分离的架构,还基于云原生技术,实现了计算节点的弹性缩容和扩容。系统可以根据用户的实际负荷,进行扩缩容。这些为 SelectDB Cloud 带来了非常低的使用成本。SelectDB Cloud 的成本是用户私有部署的1/2到1/5。
从用户使用的角度来看,SelectDB Cloud 选择了拥抱 MySQL 生态,兼容 MySQL 的连接协议。所以任何可以支持  MySQL的连接协议的方式都可以连接到 SelectDB Cloud,包括但不限于 MySQL Client, JDBC,DBeaver。这让使用 SelectDB Cloud 的门槛非常的低。
SelectDB Cloud 还提供了强大的管理控制台和各种各样的数据导入方式,包括为 Spark,Flink,Kafka等大数据工具都提供了接口,这些都给 SelectDB Cloud 的用户提供了非常丰富的管理和使用功能。
从运营角度来看,SelectDB Cloud 采取的策略和主流云数
厂商 Snowflake 一样的云中策略。简单来说,就是在主流的公有云提供商那里都提供服务。这样用户就不用担心自己被绑定在某一个特定的公有云厂商那里
SelectDB Cloud 目前已经上线了阿里云、腾讯云、华为云、亚马逊云科技 AWS 等主流云平台。用户无论是用哪家公有云提供者,都可以使用 SelectDB Cloud。
综上所述,SelectDB Cloud 是一款非常有竞争力的云数仓,值得大家去尝试。
继续阅读
阅读原文