10分钟带你全面了解StarRocks

StarRocks 是一款极速全场景 MPP 企业级数据库产品，具备水平在线扩缩容，金融级高可用，兼容 MySQL 5.7 协议和 MySQL 生态，提供全面向量化引擎与多种数据源联邦查询等重要特性。StarRocks 致力于在全场景 OLAP 业务上为用户提供统一的解决方案，适用于对性能，实时性，并发能力和灵活性有较高要求的各类应用场景。接下来会从三个方面来剖析 StarRocks 的能力与特点：

• 首先我们先来看一下 StarRocks 是一款什么样的数据库，他的产品定位是什么样的，他处于大数据生态什么位置上
• 接下来我们详细的看一下 StarRocks 的功能与特性，了解一下为什么说 StarRocks 是一款全场景的 MPP 数据库
• 最后我们通过解读一些基准测试的性能报测试告，看一下 StarRocks 的性能优势如何

OLAP数仓挑战

随着越来越多的企业都使用数据驱动决策，数据的价值也被逐步释放。但随着数据量的增长，需求的不断迭代，原有的以 Hadoop 为核心的大数据生态，在性能、实效性、运维难度及灵活性等方面都难以满足企业的需求。OLAP 数据库面临着越来越多的挑战，很难有一种数据库能够适配大部分的业务。在这种情况下，我们一般会使用不同的数据库处理不同类型的业务，充分发挥每种分析型数据库的优势，比如说：

•对于 T+1 的报表业务，我们一般是将数据放在 Hive 中定时跑批完成

•对于高并发的分析类查询，我们会使用 Druid，缓解高峰时期大量用户集中使用给系统带来的查询压力

•对于像固定报表业务，我们预先知道了大部分的查询请求，将可以将数据打平成宽表的，放在 ClickHouse 中，充分发挥 ClickHouse 在单表查询的性能优势

•对于明细数据的查询或者全文检索的需求，我们可以使用 Elasticsearch 中，发挥倒排索引的优势

•对于多表关联的需求，我们可以通过 Presto 跨数据源完成多表的 join 操作

一方面，多种技术栈的堆叠确实能够解决我们的问题，另一方面这样的复杂架构也大大增加了开发与运维的成本。这也是 StarRocks 要解决的痛点问题，我们希望把简单的事情回归到简单，能够使用一种统一 OLAP 数据库完成大数据生态中分析层的构建。

StarRocks大数据生态定位

我们来深入看一下 StarRocks 在大数据生态的定位。

作为一款 MPP 架构的分析性数据库，StarRocks 能够支撑 PB 级别的数据量，拥有灵活的建模方式，可以通过向量化引擎、物化视图、位图索引、稀疏索引等优化手段构建极速统一的分析层数据存储系统。

在整体的大数据生态中：

•从数据源比如像 Oceanbase 这样的事务性数据库拉过来业务数据，然后通过CloudCanal 这样的数据采集工具写入到 StarRocks 中

•中间的一些 ETL 工作，我们可以放在计算引擎中，通过 Flink 或者 Spark 完成，StarRocks 也提供了相应的 Flink Connector 与 Spark Connector

•我们也可以采用 ELT 的模式，在数据加载到 StarRocks 之后，利用 StarRocks 的物化视图，实时 Join 的能力进行数据建模。在 StarRocks 中我们可以选择多种数据模型，比如说预聚合、宽表或者是灵活性比较高的星型/雪花模型

•同时借助于 iceberg、hive 外表的功能，我们打造一套湖仓一体的架构，Iceberg 或者Hive 中的有价值的数据可以流到 StarRocks 中，在 StarRocks 中进行关联查询；StarRocks 里面的隐藏价值数据，或者是价值不太高的数据，也可以流到 Iceberg 或者Hive 中，以低成本的方式长久保存数据，供未来数据挖掘使用。

在经过一系列的建模后，StarRocks 中的数据可以服务于多种业务，比如说报表业务，实时指标监控业务，智能分析业务，客圈圈选业务，自助 BI 业务。

重构企业数据基础设施

可以说，StarRocks 重构了企业数据基础设施，把复杂的多模分析结构变得简单⽽统⼀。

StarRocks 不依赖于某⼀种技术栈，⽽又能够兼容⼤数据平台的绝⼤部分技术栈：

• 在数据导⼊层⾯上，StarRock 可以拉取 HDFS、S3、OSS 中的数据，也可以导⼊平⾯ ⽂件，或者是消费 Kafka 中的增量数据

• 对于像 MySQL 或者 Oceanbase 这样的 TP 业务库，全量数据我们可以通过 dataX， sqoop 等⼯具进⾏同步，增量数据我们可以通过 canal 这样的 CDC ⼯具实时同步。

• 如果在同步的过程中，我们需要进⾏⼀些清洗或者数据转换操作，可以使⽤ Flink 或 者 Spark

• 此外 StarRocks 还⽀持外表联邦查询，可以拉取 Hive、MySQL、ES 以及 Iceberg 中的 数据，与 StarRocks 中的表进⾏关联，避免数据孤岛的存在

• 从顶层协议来看，StarRocks 兼容了 MySQL 协议，可以轻松平稳的对接多种开源或者 商业 BI ⼯具，⽐如说 Tableau，FineBI，SmartBI，Superset 等

StarRocks架构

StarRocks 整体上架构⽐较简单，有两层结构，黄⾊的是 FrontEnd 节点，蓝⾊的是 BackEnd 节点：

• FrontEnd 节点主要负责元数据的管理和客户端链接的管理，并且根据元数据信息进⾏ 查询的规划和查询的调度。从 MySQL 客户端发起的请求通过 FrontEnd 节点转化成分 布式的 AST，也就是我们所说的执⾏计划树，推送给对应的 BackEnd 节点。每⼀个 FrontEnd 节点都存储全量的元数据，通过类 Paxos 协议进⾏数据同步，这种多数派的 数据同步协议也保证了我们可以线上⽔平阔所容 FrontEnd 节点。

• BackEnd 节点主要负责数据存储及 SQL 的计算⼯作。FrontEnd 节点按照⼀定的策略 将数据分配给对应的 BackEnd 节点。在执⾏ SQL 计算时，⼀条 SQL 语句⾸先会按照 具体的语义规划成逻辑执⾏单元，然后再按照数据的分布情况拆分成具体的物理执⾏ 单元在 BackEnd 中进⾏计算。BackEnd 节点是完全对等的，数据通过 Qurom 协议进 ⾏同步。BackEnd 节点同样也⽀持在线⽔平阔缩容。

向量化引擎

StarRocks 执⾏器的⼀个重⼤的特性就是向量化引擎。通过向量化引擎，可以极⼤程度的提 ⾼查询性能。

作为⼀个列存数据库，StarRocks 的数据在 BackEnd 存储层是以列的形式组织的。 在没有做向量化引擎之前，数据以列的形式存储，但以⾏的形式被加载到内存中。⽐如说我 们要计算 A 列与 B 列的和，会以⾏的维度不停的调⽤ CPU 的加指令，循环迭代 A0 + B0， A1 + B1，A2 + B2。

有了向量化引擎之后，StarRocks 在将数据加载到内存中时，也是按照列的形式进⾏布局。 通过调⽤ CPU 的 SIMD 指令集，计算 A 列与 B 列相加，减少了连续的虚函数调⽤，避免 CPU 流⽔线被打断。

通过向量化引擎的加速，过滤操作⼤概有 5 倍左右的性能提升，聚合操作有 15 倍的性能提 升，关联操作有⼤概 3-4 倍的性能提升。

CBO：基于代价的优化器

CBO 也是一种非常重要的优化手段。CBO 是指基于代价的优化器。目前大部分的 MPP 计算 引擎都是使用 RBO 的模式，也就意味着我们在写 SQL 的时候，要手动的进行 SQL 的优 化，比如说大表与小表谁在前谁在后，WHERE 条件中那些谓词选择性高我们要放在前面， 在比如说，我们在开发中，可能会按照业务的逻辑写一些子查询，在优化的时候，我们可能 需要将这些子查询改写为反业务逻辑的多表关联操作。有了 CBO 优化器后，我们可以将繁 琐的优化操作交给 StarRocks，更多的精力放在 SQL 的业务逻辑上。

StarRocks CBO 目前实现了表达式重写，表达式复用，谓词下推，limit 下推等功能。我们做 了 SSB 10G 的基准性能测试，使用了 CBO 相较于没有使用 CBO，查询大概有三到五倍的性 能提升。

多种分布式Join方式
 

对于实时 Join 的支持是 StarRocks 的一个非常重要的功能。我们提供了不同的 Join 的类型， 比如说小表与大表关联，可以使用 broadcast join，将小表以广播的方式推到不同 server 的内 存中进行关联操作。大表与大表的关联，可以使用 shuffle join 的模式，这也是 MPP 数据库 独有的一种 join 的模式。将数据分割后重新分发到不同的 server 上，利用每一台机器的内存 与 CPU 资源进行计算。当然，在数据 shuffle 的过程中，会带来大量的 IO 开销与网络开 销，可能会影响到查询的性能。

此时可以人工的进行干预，选择 colocation join 的模式。比如我们在使用星型模型的时候， 预先就会计划好，事实表的 ID 列一定会与维度表的 ID 列进行关联，那么我们在数据导入的 过程中，可以人为的将两张表的 ID 列存储到同一台机器上，查询的时候就不需要进行数据 shuffle，直接在这台机器上进行 join 就可以，最大程度的减少了网络开销带来的性能影响。 通过 CBO 的优化，StarRocks 会根据表的统计信息自动选择出最为合适的 Join 类型。如果我 们对查询的性能有更高的要求，也可以手动的指定 colocation join 这种模式，进行特殊优化 的操作。

高并发查询

和大多数的 MPP 数据库不同，StarRocks 支持高并发查询。这得益于 StarRocks 对表的两级 分区管理。
首先我们会根据数据的业务属性对表进行分区，一般来说我们会将时间列作为分区键，这样 做可以优化根据时间，删除过期数据所带来的性能问题，也方便了冷热数据的分级存储。 分区的下一级是分桶，StarRocks 采用 Hash 算法对分区数据进行分片管理。在同一分区内， 分桶键的哈希值相同的数据被聚集到一起，形成一个子表，我们称之为 tablet。每一个 tablet 都以多副本的形式进行数据冗余存储。同时 tablet 也是做扩容缩容，failover 与 failback 的最小物理单位。

当表经过分区分桶后，数据的指向性有了显著的提高。如果分区分桶恰好可以有效的覆盖大 部分的查询条件的，那么就可以利用分区分桶剪裁，避免全表扫描。比如在这个例子中，我 们根据 date 列进行了分区操作，又根据 site id 列进行了分桶的操作。查询中，我们既使用 了 date 列，又使用了 site id 列进行条件过滤，通过 date 列的分区我们可能过滤了十几分之 一，再通过 site id 列分桶，又过滤了几十分之一的数据，两者相乘，扫描的数据量可能只是 全表的千分之一甚至万分之一，这样可以降低单个查询的资源消耗，从而实现业务的高并发 查询。在以往的案例中，我们经过分区分桶的操作，加上 StarRocks 的水平扩容的能力，可 以支撑万级别的并发量。

灵活数据建模方式
 

在 StarRocks 中提供多种不同的建模方式以支撑不同的业务类型。

• 当我们需要召回明细数据的时候，可以使用明细模型
  • 与 MySQL 相同，明细模型中用户插入的数据与表中存储的数据一一对应
  • 像在最上面的例子中，有多少条 insert 的 value 值，表中就新增多少行数据
  • 明细模型底层使用 LSM Tree 数据结构进行存储，我们都知道 LSM Tree 是一 个写友好的数据结构，在 StarRocks 数据存储层，选择了一个两层结构的 LSM Tree，减少了 compaction 对系统的压力，也减少了 write stall 的影响
• 如果我们需要对数据进行预聚合操作，可以使用聚合模型
  • 通过给 value 列添加聚合函数，比如说 sum、min、max、count，在数据导入的 时候，会根据主键完成数据的相应预聚合操作
  • 像上面的例子中，我们在创建表的时候给 pv 列指定了 sum 聚合，新插入的主 键为 (1, 100) 的行会与原表中 (1, 100) 的行进行合并，最后根据 pv 列上的 sum 函数进行聚合操作
  • 对于只需要汇总结果但不需要召回明细数据的场景，我们推荐使用聚合模型
• 如果数据需要频繁的更新，可以使用主键模型
  • 主键模型会根据表中的主键进行 upsert 操作，对于已有的主键做 update 操作， 更新 value 列，没有的主键做 insert 操作
  • 在上面的例子中，新写入的主键为 (1, 100) 的行会替换原表中 (1, 100) 的行
  • 主键模型使用 insert & delete 模式，相较于 merge on read 的更新策略，可以提 供更好的查询性能

智能物化视图功能
 

在数据建模的时候，我们除了可以使用 StarRocks 提供的明细模型、聚合模型以及主键模 型，也可以通过物化视图来构建数据模型。StarRocks 支持智能的物化视图，用户可以通过 创建物化视图的方式完成预聚合的操作。
我们可以说 StarRocks 的物化视图是一张透明的物化视图，这种透明表现在于两个方面:

• 从数据导入的角度来看，在基表导入数据时，物化视图自动的完成数据的汇聚，物化
  视图与基表保证强一致性数据同步，不需要手动刷新
• 从查询的角度看，在查询时，不需要显示的指定物化视图，在查询中使用基表，
  CBO 也可以将查询重写使用物化视图。在很多自助 BI 的场景，应用层使用 tableau 等报表工具通过拖拉拽的形式生成 SQL，我们无法通过改写 SQL 的方式进行优化， 此时我们可以创建一张物化视图， CBO 自动的将查询改写成使用物化视图语句，帮 助我们完成查询加速

实时能力

接下来我们来看一下 StarRocks 的实时能力。我们从数据摄入、数据更新、数据建模和数据 分析四个方面来剖析一下。

StarRocks 的实时数据摄入能力:

• StarRocks 可以直接订阅 Kafka 中的数据，数据在 Kafka 中微攒批，5-10s 一批进行数
  据同步，可以支撑十几万左右的 TPS
• 如果需要在数据摄入时完成 ETL 的工作，比如一些轻量级的清洗或者拼宽表操作，
  StarRocks 提供了具有 exactly once 的语义的 flink connector，可以将数据直接写入存
  储层，避免了在 FrontEnd 层产生导入瓶颈，相较于 JDBC connector 性能有明显优势
• 我们也可以使用 Flink CDC 直接捕获 TP 库的业务数据变更，简化数据链路

StarRocks 的实时数据更新能力:

• StarRocks 提供了基于 Delete & Insert 模式的主键模式，性能相比 Merge on Read 的更
  新模式提升了 3 倍多 StarRocks 的实时数据建模能力:
• 我们可以通过聚合模型完成实时的数据聚合统计
• 也可以通过 StarRocks 强大的实时多表关联能力支撑星型/雪花模型
• 物化视图的强一致性同步也能进一步加强 StarRocks 的建模能力

StarRocks 的实时数据分析能力:

• StarRocks 有多种性能优化手段，比如说稀疏索引、Bitmap 索引，分区分桶策略、智
  能物化视图
• 我们也可以使用 StarRocks 构建湖仓一体的架构，通过 Hive 外表、Iceberg 外表功能完成实时离线数据的统一融合

湖仓能力
 

我们都知道，在湖中数据按照原有的格式进行存储，不需要事先对数据进行结构化处理。数 据湖可以存储结构化数据，半结构化数据，非结构化数据和二进制数据。为了能够满足更多 用户对于极速分析数据的需求，同时让 StarRocks 强大的分析能力应用在更加广泛的数据集 上，StarRocks 社区联合阿里云开源大数据 OLAP 团队一起增强 StarRocks 的数据湖分析能 力。

在数据湖分析的场景中，StarRocks 主要负责数据的计算分析，而数据湖则主要负责数据的 存储、组织和维护。在 FE 节点中，不仅存储了 StarRocks 内部表的元数据，也存储了 Iceberg 外表的元数据，这样可以实现 StarRocks 与 Iceberg 的数据打通和自由流动。Iceberg 中的有价值的数据可以流到 StarRocks 中，可以在 StarRocks 中进行关联查询;StarRocks 里 面的具有隐藏价值数据，也可以流到 Iceberg 中，以低成本的方式进行长久数据存储，供未来数据挖掘使用。

SSB性能测试
 

Star schema benchmark(以下简称SSB)是学术界和工业界广泛使用的一个星型模型测试 集，通过这个测试集合可以方便的对比各种 OLAP 产品的基础性能指标。我们都知道， ClickHouse 在单表查询的性能上是非常优秀的，ClickHouse 官网也提供了 SSB 测试的性能 报告。Clickhouse 通过改写 SSB，将星型模型打平转化成宽表，改造成了一个单表测试 benchmark。我们也根据这种模型，进行了一个性能测试对比。

这个性能测试中，我们选取了 StarRocks、ClickHouse 与 Apache Druid，在 SSB 单表数据集 上进行对比，我们一起来看一下测试结果:

• 在 SSB 的 13 个查询上，ClickHouse 的整体查询时间是 StarRocks 的 1.7 倍，Apache Druid 的整体查询时间是 StarRocks 的 2.2 倍
• 在 StarRocks 启用 bitmap index 和 query cache 的情况下，性能更胜一筹，尤其在 Q2.2、Q2.3、Q3.3 上有显著提升。整体性能是 ClickHouse 的 2.2 倍，Apache Druid 的 2.9 倍
• 网站上提供了详细的测试报告具体操作流程以及结果，大家感兴趣的话也可以通过扫 码或者链接获取详细的文档。

TPC-H性能测试

刚才我们看了单表的 SSB 性能测试，接下来我们来看一下多表关联的测试情况。 在这个测试中我们和 Trino 做了性能的对比，Trnio 是我们熟知的 Presto SQL 的一个分支版 本。主要用于跨数据源多表关联查询。这个性能测试中，StarRocks 与 Trino 都查询同一份 Hive 数据，数据采用 ORC 格式存储，zlib 格式压缩。同时我们也基于这个测试添加了 StarRocks 查询 Hive 外表与直接查询 StarRocks 内部表的一个性能对比。

最终，StarRocks 本地存储查询总耗时为 21s，StarRocks Hive 外表查询总耗时 92s。Trino 查 询总耗时是 StarRocks 的三倍，在 307s 左右。

所以我们可以说，StarRocks 无论在单表查询上，还是多表关联查询上，都有非常大的性能 优势。

社区与支持

一个优秀的开源项目，离不开繁荣活跃的社区生态。StarRocks自2021年9月开放源码至今，已经有4.2k+ star，社区贡献者突破220+，如果大家对 StarRocks 的具体实现感兴趣，可以在 Github 上搜索 StarRocks，研究学习一下 StarRocks 的源码，也欢迎大家 followe StarRocks 项目，点一个star以表支持，大家如果在使用中有一些新的需求，可以在 Github 上提 Issue/PR，社区及时做出回复，或者加入Slack，与全球开发者进行交流讨论。

Slack：

https://join.slack.com/t/starrocks/shared_invite/zt-z5zxqr0k-U5lrTVlgypRIV8RbnCIAzg​join.slack.com/t/starrocks/shared_invite/zt-z5zxqr0k-U5lrTVlgypRIV8RbnCIAzg

Github：

GitHub - StarRocks/starrocks: StarRocks is a next-gen sub-second MPP database for full analytics scenarios, including multi-dimensional analytics, real-time analytics and ad-hoc query.​github.com/StarRocks/starrocks​编辑

公众号：StarRockslabs，关注加小助手，还可以加入社区交流群！