StarRocks的优势
StarRocks最初主要的优势是性能,当时在单表查询方面与性能标杆ClickHouse不相上下,而join优化特性使其在多表关联查询场景下的性能表现要远远优于ClickHouse,替换ClickHouse自然也就成了StarRocks的第一个目标。
而StarRocks的野心不止于此,后来又进一步发展了联邦查询功能,成为Presto的性能升级替代方案。与此同时,StarRocks优良的预计算特性让其成为Druid的一种替代选择。
为什么单表性能可以跟ClickHouse不相上下?
先看下测试数据
SSB Flat Table 性能测试
Star Schema Benchmark(以下简称 SSB)是学术界和工业界广泛使用的一个星型模型测试集(来源论文),通过这个测试集合可以方便的对比各种 OLAP 产品的基础性能指标。ClickHouse 通过改写 SSB,将星型模型打平转化成宽表 (flat table),改造成了一个单表测试 benchmark(参考链接)。本报告记录了 StarRocks、ClickHouse 和 Apache Druid 在 SSB 单表数据集上的性能对比结果,测试结论如下:
- 在标准测试数据集的 13 个查询上,StarRocks 整体查询性能是 ClickHouse 的 2.1 倍,Apache Druid 的 8.7 倍。
- StarRocks 启用 Bitmap Index 后整体查询性能是未启用的 1.3 倍,此时整体查询性能是 ClickHouse 的 2.8 倍,Apache Druid 的 11.4 倍。
Clickhouse原理
ClickHouse 是一个真正的列式数据库管理系统(DBMS)。
在 ClickHouse 中,数据始终是按列存储的,包括矢量(向量或列块)执行的过程。只要有可能,操作都是基于矢量进行分派的,而不是单个的值,这被称为«矢量化查询执行»(SIMD),它有利于降低实际的数据处理开销。
这个想法并不新鲜,其可以追溯到 APL 编程语言及其后代:A +、J、K 和 Q。矢量编程被大量用于科学数据处理中。即使在关系性数据库中,这个想法也不是什么新的东西:比如,矢量编程也被大量用于 Vectorwise 系统中。
通常有两种不同的加速查询处理的方法:矢量化查询执行和运行时代码生成。在后者中,动态地为每一类查询生成代码,消除了间接分派和动态分派。这两种方法中,并没有哪一种严格地比另一种好。运行时代码生成可以更好地将多个操作融合在一起,从而充分利用 CPU 执行单元和流水线。矢量化查询执行不是特别实用,因为它涉及必须写到缓存并读回的临时向量。如果 L2 缓存容纳不下临时数据,那么这将成为一个问题。但矢量化查询执行更容易利用 CPU 的 SIMD 功能。研究表明,将两种方法结合起来是更好的选择。ClickHouse 使用了矢量化查询执行,同时初步提供了有限的运行时动态代码生成。
StarRocks原理
StarRocks 整体上架构⽐较简单,有两层结构,黄⾊的是 FrontEnd 节点,蓝⾊的是 BackEnd 节点:
• FrontEnd 节点主要负责元数据的管理和客户端链接的管理,并且根据元数据信息进⾏ 查询的规划和查询的调度。从 MySQL 客户端发起的请求通过 FrontEnd 节点转化成分 布式的 AST,也就是我们所说的执⾏计划树,推送给对应的 BackEnd 节点。每⼀个 FrontEnd 节点都存储全量的元数据,通过类 Paxos 协议进⾏数据同步,这种多数派的 数据同步协议也保证了我们可以线上⽔平阔所容 FrontEnd 节点。
• BackEnd 节点主要负责数据存储及 SQL 的计算⼯作。FrontEnd 节点按照⼀定的策略 将数据分配给对应的 BackEnd 节点。在执⾏ SQL 计算时,⼀条 SQL 语句⾸先会按照 具体的语义规划成逻辑执⾏单元,然后再按照数据的分布情况拆分成具体的物理执⾏ 单元在 BackEnd 中进⾏计算。BackEnd 节点是完全对等的,数据通过 Qurom 协议进 ⾏同步。BackEnd 节点同样也⽀持在线⽔平阔缩容。
StarRocks 是通过 MPP 多机并行机制来充分利用多机的资源,通过 Pipeline 并行机制来充分利用单机上多核的资源,通过向量化执行来充分利用单核的资源,进而达到极致的查询性能。
向量化引擎
StarRocks 执⾏器的⼀个重⼤的特性就是向量化引擎。通过向量化引擎,可以极⼤程度的提⾼查询性能。
作为⼀个列存数据库,StarRocks 的数据在 BackEnd 存储层是以列的形式组织的。 在没有做向量化引擎之前,数据以列的形式存储,但以⾏的形式被加载到内存中。⽐如说我 们要计算 A 列与 B 列的和,会以⾏的维度不停的调⽤ CPU 的加指令,循环迭代 A0 + B0, A1 + B1,A2 + B2。
有了向量化引擎之后,StarRocks 在将数据加载到内存中时,也是按照列的形式进⾏布局。 通过调⽤ CPU 的 SIMD 指令集,计算 A 列与 B 列相加,减少了连续的虚函数调⽤,避免 CPU 流⽔线被打断。
通过向量化引擎的加速,过滤操作⼤概有 5 倍左右的性能提升,聚合操作有 15 倍的性能提升,关联操作有⼤概 3-4 倍的性能提升。
向量化执行
随着数据库执行的瓶颈逐渐从 IO 转移到 CPU,为了充分发挥 CPU 的执行性能,StarRocks 基于向量化技术重新实现了整个执行引擎,向量化执行引擎是为了充分利用单核 CPU 的能力。
向量化在实现上主要是算子和表达式的向量化,上图左边是算子向量化的示例,上图右边是表达式向量化的示例,算子和表达式向量化执行的核心是批量按列执行。相比于单行执行,批量执行可以有更少的虚函数调用,更少的分支判断;相比于按行执行,按列执行对 CPU Cache 更友好,更易于 SIMD 优化。
向量化执行不仅仅是数据库所有算子的向量化和表达式的向量化,而是一项巨大和复杂的性能优化工程,包括数据在磁盘、内存、网络中的按列组织,数据结构和算法的重新设计,内存管理的重新设计,SIMD 指令优化,CPU Cache 优化,C++ Level 优化等。经过努力,StarRocks 向量化执行引擎相比之前的按行执行,取得了整体 5 到 10 倍的性能提升。
一条SQL到执行经过了一系列的优化:
- 通过高效强大的 CBO 优化器生成最佳的分布式物理执行计划;
- 通过查询调度器选择合适的数据副本,并将分布式物理执行计划调度到合适的计算节点进行计算;
- 通过 MPP 分布式执行框架充分利用多机的资源,做到查询性能可以随着机器数量近似线性扩展;
- 通过 Pipeline 并行执行框架充分利用多核资源,做到查询性能可以随着机器核数近似线性扩展;
- 通过向量化执行引擎充分利用 CPU 单核资源,将单核执行性能做到极致。