starRocks

系统架构 | StarRocks

简介&使用场景

StarRocks是新一代急速全场景MPP（Massively Parallel Processing 大规模并行处理）数据库。StarRocks的愿景是能够让用户的数据分析变得更加简单和敏捷。用户无需经过复杂的预处理，就可以用StarRocks来支持多种数据分析场景的极速分析。

StarRockes架构简介，采用了全面向量化引擎，并配备全新设计的CBO（Cost Based Optimizer 基于成本的）优化器，查询速度（尤其是多表关联查询）远超同类产品。

StarRocks能很好地支持实时数据分析，并能实现对实时更新数据的搞笑查询。StarRocks还支持现代物化视图，进一步加速查询。

使用starRockets，用户可以灵活的构建大宽表，星形模型，雪花模型在内的各种模型。

StarRocks 兼容 MySQL 协议，支持标准 SQL 语法，易于对接使用，全系统无外部依赖，高可用，易于运维管理。StarRocks 还兼容多种主流 BI 产品，包括 Tableau、Power BI、FineBI 和 Smartbi。

模型

星型模型：是一种多为数据关系，它由一个事实表（fact Table）和一组维表（Dimension table）组成。每个维表都有一个维作为主键，所有这些维的主键合成事实表的主键。事实表的非主键称为事实（Fact），它们一般都是数值或其他可以进行计算的数据如下图

星型模型是一种非正规化的结构，多维数据的每一个维度都直接与事实表相连接，所以数据有一定冗余。

雪花模型：

当有一个或多个维表没有连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像是多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的围标进一步层次化，原有的各维度可能被扩展为小的事实表，形成一些局部的层次区域，这些被分解的表都连接到主维度表而不是事实表。

通过最大限度减少了数据存储量以及联合较小维度来改善查询的性能。雪花型结构去除了冗余。

1、查询性能角度来看

在OLTP-DW环节，由于雪花型要做多个表联接，性能会低于星型架构；但从DW-OLAP环节，由于雪花型架构更有利于度量值的聚合，因此性能要高于星型架构。

2、模型复杂度角度

星型架构更简单方便处理

3、层次结构角度

雪花型架构更加贴近OLTP系统的结构，比较符合业务逻辑，层次比较清晰。

4、存储角度

雪花型架构具有关系数据模型的所有优点，不会产生冗余数据，而相比之下星型架构会产生数据冗余。

根据项目经验，一般建议使用星型模型。因为在实际项目中，往往最关注的是查询性能问题，至于磁盘空间一般都不是问题。当然，在维度表数据量极大，需要节省存储空间的情况下，或者是业务逻辑比较复杂、必须要体现清晰的层次概念情况下，可以使用雪花型模型。

OLAP多维分析

利用StarRocks的MMP框架和向量化执行引擎，用户可以灵活的选择雪花模型，星型模型，宽表模型，或者预聚合模型。适用于灵活配置多维分析报表。业务场景包括

• 用户行为分析
• 用户画像、标签分析、圈人
• 高维业务指标报告
• 自助式报表平台
• 业务问题探查分析
• 跨主题业务分析
• 财务报表
• 系统监控分析

实时数据仓库

StarRocks设计和实现了Primary-Key模型，能够实时更新数据并急速查询，可以秒级别同步TP（Transation Processing）数据库的变化，构建实时数仓，业务场景包括。

• 电商大促数据分析
• 物流行业的运单分析
• 金融行业绩效分析、指标计算
• 直播质量分析
• 广告投放分析
• 管理驾驶舱
• 探针分析APM（Application Performance Management）

高并发查询

StarRocks 通过良好的数据分布特性，灵活的索引以及物化视图等特性，可以解决面向用户侧的分析场景，业务场景包括：

• 广告主报表分析
• 零售行业渠道人员分析
• SaaS 行业面向用户分析报表
• Dashboard 多页面分析

统一分析

• 通过使用一套系统解决多维分析、高并发查询、预计算、实时分析查询等场景，降低系统复杂度和多技术栈开发与维护成本。
• 使用 StarRocks 统一管理数据湖和数据仓库，将高并发和实时性要求很高的业务放在 StarRocks 中分析，也可以使用 External Catalog 和外部表进行数据湖上的分析。

系统架构

StarRocks系统分为FE（Frontend）、BE（BackEnd）或CN（Compute Node）俩类进程，方便部署与维护，节点可以在线水平扩展，元数据和业务数据都有副本机制，确保整个系统无单点。StarRcks提供MySQL协议接口，支持标准SQL语法。用户通过MYSQL客户端方便地查询和分析StarRocks中的数据。

随着StarRocks产品的不断演进，系统架构也从原先的存算一体进化到存算分离。

• 3.0 版本之前使用存算一体架构，BE 同时负责数据存储和计算，数据访问和分析都在本地进行，提供极速的查询分析体验。
• 3.0 版本开始引入存算分离架构，数据存储功能从原来的 BE 中抽离，BE 节点升级为无状态的 CN 节点。数据可持久存储在远端对象存储或 HDFS 上，CN 本地磁盘只用于缓存热数据来加速查询。存算分离架构下支持动态增删计算节点，实现秒级的扩缩容能力。

存算一体

节点

作为 MPP 数据库的典型代表，StarRocks 3.0 版本之前使用存算一体 (shared-nothing) 架构，BE 同时负责数据存储和计算，在查询时可以直接访问 BE 本地数据，进行本地计算，避免数据传输与拷贝，从而能够得到极速的查询分析性能。存算一体架构支持数据的多副本存储，提升了集群的高并发查询能力和数据可靠性。存算一体适用于追求极致查询性能的场景。

FE

FE 是 StarRocks 的前端节点，负责管理元数据、管理客户端连接、进行查询规划、查询调度等工作。每个 FE 节点都会在内存保留一份完整的元数据，这样每个 FE 节点都能够提供无差别的服务。

FE 有三种角色：Leader FE，Follower FE 和 Observer FE，区别如下。

BE

BE 是 StarRocks 的后端节点，负责数据存储和 SQL 计算等工作。

• 数据存储方面，BE 节点都是完全对等的。FE 按照一定策略将数据分配到对应的 BE 节点，BE 负责将导入数据写成对应的格式存储下来，并生成相关索引。
• 在执行 SQL 计算时，一条 SQL 语句首先会按照语义规划成逻辑执行单元，然后再按照数据的分布情况拆分成具体的物理执行单元。物理执行单元会在对应的 BE 节点上执行，这样可以实现本地计算，避免数据的传输与拷贝，从而得到极速的查询性能。

数据管理

StarRocks 使用列式存储，采用分区分桶机制进行数据管理。一张表可以被划分成多个分区，一个分区内的数据可以根据一列或者多列进行分桶，将数据切分成多个 Tablet。Tablet 是 StarRocks 中最小的数据管理单元。每个 Tablet 都会以多副本 (replica) 的形式存储在不同的 BE 节点中。用户可以自行指定 Tablet 的个数和大小，StarRocks 会管理好每个 Tablet 副本的分布信息。

下图展示了 StarRocks 的数据划分以及 Tablet 多副本机制。表按照日期划分为 4 个分区，第一个分区进一步切分成 4 个 Tablet。每个 Tablet 使用 3 副本进行备份，分布在 3 个不同的 BE 节点上。

在执行 SQL 语句时，StarRocks 可以对所有 Tablet 实现并发处理，从而充分利用多机、多核提供的计算能力。用户也可以将高并发请求压力分摊到多个物理节点，通过增加物理节点的方式来扩展系统的高并发能力。

StarRocks 支持 Tablet 多副本存储（默认三个），多副本能够保证数据存储的高可靠以及服务的高可用。在三副本下，一个节点的异常不会影响服务的可用性，集群的读写服务仍然能够正常进行。增加副本数还有助于提高系统的高并发查询能力。

在 BE 节点数量发生变化时 （比如扩缩容时），StarRocks 可以自动完成节点的增减，无需停止服务。节点变化会触发 Tablet 的自动迁移。当节点增加时，一部分 Tablet 会自动均衡到新增的节点，保证数据能够在集群内分布的更加均衡；当节点减少时，待下线机器上的 Tablet 会被自动均衡到其他节点，从而自动保证数据的副本数不变。管理员能够非常容易的实现弹性伸缩，无需手工进行数据的重分布。

存算一体架构的优势在于极速的查询性能，但也存在一些局限性：

• 成本高：需要使用三副本保证数据可靠性；随着用户存储数据量的增加，需要不断扩容存储资源，导致计算资源浪费。
• 架构复杂：存算一体架构需要维护多数据副本的一致性，增加了系统的复杂度。
• 弹性不够：存算一体模式下，扩缩容会触发数据重新平衡，弹性体验不佳。

存算分离

StarRocks存算分离技术在现在存算一体架构的基础逻辑上，将计算和存储进行解耦。在存算分离的新架构中，数据持久化存储在更为可靠和廉价的远程对象存储（比如S3）或HDFS上。CN本地磁盘只用于缓存热点数据来加速查询。在本地缓存命中的情况下，存算分离可以获得与存算一体架构相同的查询性能。存算分离架构下，用户可以动态增删计算节点，实现秒级的扩容。存算分离大大降低了数据存储成本和扩容成本，有助于实现资源隔离和计算资源的弹性伸缩。

与存算一体架构类似，存算分离同样拥有简洁的架构，整个系统依然只有FE和CN俩种服务进程，用户唯一额外提供的是后端对象存储。

节点介绍

存算分离架构下，FE的功能保持不变。BE原有的存储功能被剥离，数据存储从本地存储升级为共享存储。BE节点省纪委无状态的CN节点，只缓存热更新数据。CN会执行数据导入、查询计算、缓存数据管理等任务。

存储

目前，StarRocks 存算分离技术支持如下后端存储方式，用户可根据需求自由选择：

• 兼容 AWS S3 协议的对象存储系统（支持主流的对象存储系统如 AWS S3、Google GCP、阿里云 OSS、腾讯云 COS、百度云 BOS、华为云 OBS 以及 MinIO 等）
• Azure Blob Storage
• 传统数据中心部署的 HDFS

在数据格式上，StarRocks 存算分离数据文件与存算一体保持一致，各种索引技术在存算分离表中也同样适用，不同的是，描述数据文件的元数据（如 TabletMeta 等）被重新设计以更好地适应对象存储。

缓存

为了提升存算分离架构的查询性能，StarRocks 构建了分级的数据缓存体系，将最热的数据缓存在内存中，距离计算最近，次热数据则缓存在本地磁盘，冷数据位于对象存储，数据根据访问频率在三级存储中自由流动。

查询时，热数据通常会直接从缓存中命中，而冷数据则需要从对象存储中读取并填充至本地缓存，以加速后续访问。通过内存、本地磁盘、远端存储，StarRocks 存算分离构建了一个多层次的数据访问体系，用户可以指定数据冷热规则以更好地满足业务需求，让热数据靠近计算，真正实现高性能计算和低成本存储。

StarRocks 存算分离的统一缓存允许用户在建表时决定是否开启缓存。如果开启，数据写入时会同步写入本地磁盘以及后端对象存储，查询时，CN 节点会优先从本地磁盘读取数据，如果未命中，再从后端对象存储读取原始数据并同时缓存在本地磁盘。

同时，针对未被缓存的冷数据，StarRocks 也进行了针对性优化，可根据应用访问模式，利用数据预读技术、并行扫描技术等手段，减少对于后端对象存储的访问频次，提升查询性能。

产品特性

MPP分布式执行框架

StarRocks 采用 MPP (Massively Parallel Processing) 分布式执行框架。在 MPP 执行框架中，一条查询请求会被拆分成多个物理计算单元，在多机并行执行。每个执行节点拥有独享的资源（CPU、内存）。MPP 执行框架能够使得单个查询请求可以充分利用所有执行节点的资源，所以单个查询的性能可以随着集群的水平扩展而不断提升。

如上图所示，StarRocks 会将一个查询在逻辑上切分为多个逻辑执行单元（Query Fragment）。按照每个逻辑执行单元需要处理的计算量，每个逻辑执行单元会由一个或者多个物理执行单元来具体实现。物理执行单元是最小的调度单位。一个物理执行单元会被调度到集群某个 BE 上执行。一个逻辑执行单元可以包括一个或者多个执行算子，如图中的 Fragment 包括了 Scan，Project，Aggregate。每个物理执行单元只处理部分数据。由于每个逻辑执行单元处理的复杂度不一样，所以每个逻辑执行单元的并行度是不一样的，即，不同逻辑执行单元可以由不同数目的物理执行单元来具体执行，以提高资源使用率，提升查询速度。

与很多数据分析系统采用的 Scatter-Gather 分布式执行框架不同，MPP分布式执行框架可以利用更多的资源处理查询请求。在 Scatter-Gather 框架中，只有 Gather 节点能处理最后一级的汇总计算。而在 MPP 框架中，数据会被 Shuffle 到多个节点，并且由多个节点来完成最后的汇总计算。在复杂计算时（比如高基数 Group By，大表 Join 等操作），StarRocks 的 MPP 框架相对于 Scatter-Gather 模式的产品有明显的性能优势。

全向量化执行引擎

GPT4生成

向量化引擎在数据仓库中是指一种特定的数据处理技术，它通过在单个操作中同时处理数据集的多个值来提高查询性能。这种方法与传统的行式处理形成对比，后者在每个操作中只处理单个数据值。

向量化引擎的关键特点：

1. 批量处理：向量化引擎一次处理数据的一个“批次”而不是单个行或值。这意味着多个数据值可以在单个 CPU 指令周期内同时被处理，从而提高效率。
2. 内存利用优化：通过减少对 CPU 的调用次数和更有效地利用 CPU 缓存，向量化引擎可以显著提高内存使用效率。
3. 并行处理：向量化引擎通常结合使用多核处理器的能力，允许并行处理数据的不同部分，进一步提升性能。
4. 适用于列式存储：向量化引擎特别适用于列式存储格式的数据库，因为列式存储使得执行同一操作的数据值物理上彼此靠近，易于批量处理。

StarRocks通过实现全向量化引擎，充分发挥了CPU的处理能力。全面向量化引擎按照列式的方式组织和处理数据。StarRocks数据存储、内存中数据的组织方式，以及SQL算子的计算方式，都是列式实现的。按列的数据组织也会更加充分利用CPU的Cache，列计算会有更少虚函数调用以及更少分支判断从而获得更加充分的CPU指令流水。

另一方面，StarRocks 的全面向量化引擎通过向量化算法充分的利用 CPU 提供的 SIMD（Single Instruction Multiple Data 单指令多数据）指令。这样 StarRocks 可以用更少的指令数目，完成更多的数据操作。经过标准测试集的验证，StarRocks的全面向量化引擎可以将执行算子的性能，整体提升 3~10 倍。

除了使用向量化技术实现所有算子外，StarRocks 还在执行引擎中实现了其他的优化。比如 StarRocks 实现了 Operation on Encoded Data 的技术。对于字符串字段的操作，StarRocks 在无需解码情况下就可以直接基于编码字段完成算子执行，比如实现关联算子、聚合算子、表达式算子计算等。这可以极大的降低 SQL 在执行过程中的计算复杂度。通过这个优化手段，相关查询速度可以提升 2 倍以上。

存储计算分离

StarRocks 3.0 版本支持了全新的存算分离模式，实现了计算与存储的完全解耦、计算节点弹性扩缩容、高性能热数据缓存。存算分离模式下 StarRocks 具备灵活弹性、高性能、高可靠、低成本等特点。

存算分离模式下，存储与计算解耦，各自独立服务，独立扩缩容，解决了在存算一体模式下的计算与存储等比例扩缩容所带来的资源浪费问题。计算节点可以实现秒级的动态扩缩容，提升计算资源的利用率。

存储层利用对象存储近乎无限的容量，以及数据高可用的特性实现数据的海量存储和持久化。支持包括 AWS S3，Azure Blob Storage，Google Cloud Storage，阿里云 OSS，腾讯云 COS，火山引擎 TOS，华为云 OBS，以及各类兼容 S3 协议的对象存储，同时也支持 HDFS 存储。

部署模式上用户可以选择基于公有云、私有云、本地机房部署。StarRocks 存算分离也支持基于 Kubernetes 部署，并提供了相应的 Operator 方便用户自动化部署。

StarRocks 存算分离模式与存算一体模式功能保持一致，写入及热数据查询性能也与存算一体基本持平。用户在存储分离模式下也可以实现数据更新、数据湖分析、物化视图加速等多种场景。

CBO优化器

在多表关联查询场景下，仅靠优秀的执行引擎没有办法获得最极致的执行性能。因为这类场景下，不同执行计划的复杂度可能会相差几个数量级。查询中关联表的数目越大，可能的执行计划就越多，在众多的可能中选择一个最优的计划，这是一个 NP-Hard 的问题。只有优秀的查询优化器，才能选择出相对最优的查询计划，从而实现极致的多表分析性能。

StarRocks 从零设计并实现了一款全新的，基于代价的优化器 CBO（Cost Based Optimizer）。该优化器是 Cascades Like 的，在设计时，针对 StarRocks 的全面向量化执行引擎进行了深度定制，并进行了多项优化和创新。该优化器内部实现了公共表达式复用，相关子查询重写，Lateral Join，Join Reorder，Join 分布式执行策略选择，低基数字典优化等重要功能和优化。目前，该优化器已可以完整支持 TPC-DS 99 条 SQL 语句。

由于全新 CBO 的支持，StarRocks 能比同类产品更好地支持多表关联查询，特别是复杂的多表关联查询，让全面向量化引擎能够发挥极致的性能。

可以更新的列式存储引擎

StarRocks 实现了列式存储引擎，数据以按列的方式进行存储。通过这样的方式，相同类型的数据连续存放。一方面，数据可以使用更加高效的编码方式，获得更高的压缩比，降低存储成本。另一方面，也降低了系统读取数据的 I/O 总量，提升了查询性能。此外，在大部分 OLAP 场景中，查询只会涉及部分列。相对于行存，列存只需要读取部分列的数据，能够极大地降低磁盘 I/O 吞吐。

StarRocks 能够支持秒级的导入延迟，提供准实时的服务能力。StarRocks 的存储引擎在数据导入时能够保证每一次操作的 ACID。一个批次的导入数据生效是原子性的，要么全部导入成功，要么全部失败。并发进行的各个事务相互之间互不影响，对外提供 Snapshot Isolation 的事务隔离级别。

StarRocks 存储引擎不仅能够提供高效的 Partial Update 操作，也能高效处理 Upsert 类操作。使用 Delete-and-insert 的实现方式，通过主键索引快速过滤数据，避免读取时的 Sort 和 Merge 操作，同时还可以充分利用其他二级索引，在大量更新的场景下，仍然可以保证查询的极速性能。

智能物化视图

StarRocks 支持用户使用物化视图（materialized view）进行查询加速和数仓分层。不同于一些同类产品的物化视图需要手动和原表做数据同步，StarRocks 的物化视图可以自动根据原始表更新数据。只要原始表数据发生变更，物化视图的更新也同步完成，不需要额外的维护操作就可以保证物化视图能够维持与原表一致。不仅如此，物化视图的选择也是自动进行的。StarRocks 在进行查询规划时，如果有合适的物化视图能够加速查询，StarRocks 自动进行查询改写(query rewrite)，将查询自动定位到最适合的物化视图上进行查询加速。

StarRocks 的物化视图可以按需灵活创建和删除。用户可以在使用过程中视实际使用情况来判断是否需要创建或删除物化视图。StarRocks 会在后台自动完成物化视图的相关调整。

StarRocks 的物化视图可以替代传统的 ETL 建模流程，用户无需在上游应用处做数据转换，可以在使用物化视图时完成数据转换，简化了数据处理流程。

例如图中，最底层 ODS 的湖上数据可以通过 External Catalog MV 来构建 DWD 层的 normalized table；并且可以通过多表关联的物化视图来构建 DWS 层的宽表 (denormalized table)；最上层可以进一步构建实时的物化视图来支撑高并发的查询，提供更加优异的查询性能。

数据湖分享

StarRocks 不仅能高效的分析本地存储的数据，也可以作为计算引擎直接分析数据湖中的数据。用户可以通过 StarRocks 提供的 External Catalog，轻松查询存储在 Apache Hive、Apache Iceberg、Apache Hudi、Delta Lake 等数据湖上的数据，无需进行数据迁移。支持的存储系统包括 HDFS、S3、OSS，支持的文件格式包括 Parquet、ORC、CSV。

如上图所示，在数据湖分析场景中，StarRocks 主要负责数据的计算分析，而数据湖则主要负责数据的存储、组织和维护。使用数据湖的优势在于可以使用开放的存储格式和灵活多变的 schema 定义方式，可以让 BI/AI/Adhoc/报表等业务有统一的 single source of truth。而 StarRocks 作为数据湖的计算引擎，可以充分发挥向量化引擎和 CBO 的优势，大大提升了数据湖分析的性能。