执行计划的调度

BE
Backend 是 StarRocks 的后端节点 ， 负责数据存储以及 SQL 计算执行等工作 。
StarRocks 的 BE 节点都是完全对等的 ， FE 按照一定策略将数据分配到对应的 BE 节点 。 在数据导入时 ， 数据会直接写入到 BE 节点 ， 不会通过FE中转 ， BE 负责将导入数据写成对应的格式以及生成相关索引 。 在执行 SQL 计算时 ， 一条 SQL 语句首先会按照具体的语义规划成逻辑执行单元 ， 然后再按照数据的分布情况拆分成具体的物理执行单元 。 物理执行单元会在数据存储的节点上进行执行 ， 这样可以避免数据的传输与拷贝 ， 从而能够得到极致的查询性能 。
二、技术细节 StarRocks 为什么这么快
CBO 优化器

文章图片

一般 SQL 越复杂 ， Join 的表越多 ， 数据量越大 ， 查询优化器的意义就越大 ， 因为不同执行方式的性能差别可能有成百上千倍 。 StarRocks 优化器主要基于 Cascades 和 ORCA 论文实现 ， 并结合 StarRocks 执行器和调度器进行了深度定制 ， 优化和创新 。 完整支持了 TPC-DS 99 条 SQL ， 实现了公共表达式复用 ， 相关子查询重写 ， Lateral Join ，CTE 复用 ， Join Rorder ， Join 分布式执行策略选择 ， Runtime Filter 下推 ， 低基数字典优化 等重要功能和优化 。
CBO 优化器好坏的关键之一是 Cost 估计是否准确 ， 而 Cost 估计是否准确的关键点之一是统计信息是否收集及时 ， 准确 。StarRocks 目前支持表级别和列级别的统计信息 ， 支持自动收集和手动收集两种方式 ， 无论自动还是手动 ， 都支持全量和抽样收集两种方式 。
MPP 执行
MPP (massively parallel processing) 是大规模并行计算的简称 ， 核心做法是将查询 Plan 拆分成很多可以在单个节点上执行的计算实例 ， 然后多个节点并行执行 。每个节点不共享 CPU ， 内存, 磁盘资源 。 MPP 数据库的查询性能可以随着集群的水平扩展而不断提升 。

文章图片

如上图所示 ， StarRocks 会将一个查询在逻辑上切分为多个 Query Fragment(查询片段) ， 每个 Query Fragment 可以有一个或者多个 Fragment 执行实例 ， 每个Fragment 执行实例 会被调度到集群某个 BE 上执行 。如上图所示 ， 一个 Fragment 可以包括 一个 或者多个 Operator（执行算子） ， 图中的 Fragment 包括了 Scan, Filter, Aggregate 。 如上图所示 ， 每个 Fragment 可以有不同的并行度 。

文章图片

如上图所示 ， 多个 Fragment 之间会以 Pipeline 的方式在内存中并行执行 ， 而不是像批处理引擎那样 Stage By Stage 执行 。
如上图所示 ， Shuffle （数据重分布）操作是 MPP 数据库查询性能可以随着集群的水平扩展而不断提升的关键 ， 也是实现高基数聚合和大表 Join 的关键 。
向量化执行引擎

文章图片

随着数据库执行的瓶颈逐渐从 IO 转移到 CPU ， 为了充分发挥 CPU 的执行性能 ， StarRocks 基于向量化技术重新实现了整个执行引擎 。算子和表达式向量化执行的核心是批量按列执行 ， 批量执行 ， 相比与单行执行 ， 可以有更少的虚函数调用 ， 更少的分支判断；按列执行 ， 相比于按行执行 ， 对 CPU Cache 更友好 ， 更易于 SIMD 优化 。
向量化执行不仅仅是数据库所有算子的向量化和表达式的向量化 ， 而是一项巨大和复杂的性能优化工程 ， 包括数据在磁盘 ， 内存 ， 网络中的按列组织 ， 数据结构和算法的重新设计 ， 内存管理的重新设计 ， SIMD 指令优化 ， CPU Cache 优化 ， C++优化等 。 向量化执行相比之前的按行执行 ， 整体性能提升了5到10倍 。