数仓选型之 StarRocks

基于全场景MPP（Massively Parallel Processing）数据仓库选型

❝

目前市面上有2种数据库既能满足海量数据的存储，也能实现快速分析，那便是以StartRocks和ClickHouse为代表的全场景MPP数据库。 以下就针对这两种数据库选型做个对比.

❞

ClickHouse 有以下的优点：

• 配置丰富，只依赖与 Zookeeper
• 线性可扩展性，可以通过添加服务器扩展集群
• 容错性高，不同分片间采用异步多主复制
• 单表性能极佳，采用向量计算，支持采样和近似计算等优化手段
• 功能强大支持多种表引擎

StarRocks 有以下优点：

• 针对不同的复杂场景支持高并发的join查询能力
• 不依赖于大数据生态，同时外表的联邦（join）查询可以兼容大数据生态
• 提供多种不同的模型，支持不同维度的数据建模
• 支持在线弹性扩缩容，可以自动负载均衡
• 支持高并发分析查询
• 实时性好，支持数据秒级写入
• 兼容 MySQL 5.7 协议和 MySQL 生态

StarRocks 与 ClickHouse 的功能对比

StarRocks 与 ClickHouse 有很多相似之处，比如说两者都可以提供极致的性能，也都不依赖于 Hadoop 生态，底层存储分片都提供了主主的复制高可用机制。但功能、性能与使用场景上也有差异。「ClickHouse 在更适用与大宽表的场景」，业务可通过数据清洗聚合生成大款表，以大宽表的形式写入ClickHouse。「ClickHouse 虽然提供了 join 的语义，但使用上对大表关联的能力支撑较弱，复杂的关联查询经常会引起 OOM」。一般我们可以考虑在 ETL 的过程中就将事实表与维度表打平成宽表，避免在 ClickHouse 中进行复杂的查询。StarRocks 对于 join 的能力更强，可以建立星型或者雪花模型应对维度数据的变更。StarRocks 中提供了三种不同类型的 join：

• 当小表与大表关联时，可以使用 boardcast join，小表会以广播的形式加载到不同节点的内存中
• 当大表与大表关联式，可以使用 shuffle join，两张表值相同的数据会 shuffle 到相同的机器上
• 为了避免 shuffle 带来的网络与 I/O 的开销，也可以在创建表示就将需要关联的数据存储在同一个 colocation group 中，使用 colocation join

高并发支撑

ClickHouse 对高并发的支撑 为了更深维度的挖掘数据的价值，就需要引入更多的分析师从不同的维度进行数据勘察。更多的使用者同时也带来了更高的 QPS 要求。对于互联网，金融等行业，几万员工，几十万员工很常见，高峰时期并发量在几千也并不少见。随着互联网化和场景化的趋势，业务逐渐向以用户为中心转型，分析的重点也从原有的宏观分析变成了用户维度的细粒度分析。传统的 MPP 数据库由于所有的节点都要参与运算，所以一个集群的并发能力与一个节点的并发能力相差无几。如果一定要提高并发量，可以考虑增加副本数的方式，但同时也增加了 RPC 的交互，对性能和物理成本的影响巨大。 在 ClickHouse 中，我们一般不建议做高并发的业务查询，对于三副本的集群，通常会将 QPS 控制在 100 以下。ClickHouse 对高并发的业务并不友好，即使一个查询，也会用服务器一半的 CPU 去查询。一般来说，没有什么有效的手段可以直接提高 ClickHouse 的并发量，只能考虑通过将结果集写入 MySQL 中增加查询的并发度。

StarRocks 对高并发的支撑 相较于 ClickHouse，StarRocks 可以支撑数千用户同时进行分析查询，在部分场景下，高并发能力能够达到万级。StarRocks 在数据存储层，采用先分区再分桶的策略，增加了数据的指向性，利用前缀索引可以快读对数据进行过滤和查找，减少磁盘的 I/O 操作，提升查询性能。

数据的高频变更

ClickHouse 中的数据更新 在 OLAP 数据库中，可变数据（Mutable data）通常是不受欢迎的。ClickHouse 也是如此。早期的版本中并不支持 UPDATE 和 DELETE 操作。在 1.15 版本后，Clickhouse 提供了 MUTATION 操作（通过 ALTER TABLE 语句）来实现数据的更新、删除，但这是一种“较重”的操作，它与标准 SQL 语法中的 UPDATE、DELETE 不同，是异步执行的，对于批量数据不频繁的更新或删除比较有用。除了 MUTATION 操作，Clickhouse 还可以通过 CollapsingMergeTree、VersionedCollapsingMergeTree、ReplacingMergeTree 结合具体业务数据结构来实现数据的更新、删除，这三种方式都通过 INSERT 语句插入最新的数据，新数据会“抵消”或“替换”掉老数据，但是“抵消”或“替换”都是发生在数据文件后台 Merge 时，也就是说，在 Merge 之前，新数据和老数据会同时存在。 针对与不同的业务场景，ClickHouse 提供了不同的业务引擎来进行数据变更。 对于离线业务，可以考虑增量和全量两种方案： 增量同步方案中，使用 ReplacingMergeTree 引擎，先用 Spark 将上游数据同步到 Hive，再由 Spark 消费 Hive 中的增量数据写入到 ClickHouse 中。由于只同步增量数据，对下游的压力较小。需要确保维度数据基本不变。 全量同步方案中，使用 MergeTree 引擎，通过 Spark 将上游数据定时同步到 Hive 中，truncate ClickHouse 中的表，随后使用 Spark 消费 Hive 近几天的数据一起写入到 ClickHouse 中。由于是全量数据导入，对下游压力较大，但无需考虑维度变化的问题。 对于实时业务，可以采用 VersionedCollapsingMergeTree 和 ReplacingMergeTree 两种引擎： 使用 VersionedCollapsingMergeTree 引擎，先通过 Spark 将上游数据一次性同步到 ClickHouse 中，在通过 Kafka 消费增量数据，实时同步到 ClickHouse 中。但因为引入了 MQ，需要保证 exectly once 语义，实时和离线数据连接点存在无法折叠现象。 使用 ReplacingMergeTree 引擎替换 VersionedCollapsingMergeTree 引擎，先通过 Spark 将上游存量数据一次性同步到 ClickHouse 中，在通过 MQ 将实时数据同步到 ReplacingMergeTree 引擎中，相比 VersionedCollapsingMergeTree 要更简单，且离线和实时数据连接点不存在异常。但此种方案无法保重没有重复数据。

StarRocks 中的数据更新 相较于 ClickHouse，StarRocks 对于数据更新的操作更加简单。 StarRocks 中提供了多种模型适配了更新操作，明细召回操作，聚合操作等业务需求。更新模型可以按照主键进行 UPDATE/DELETE 操作，通过存储和索引的优化可以在并发更新的同时高效的查询。在某些电商场景中，订单的状态需要频繁的更新，每天更新的订单量可能上亿。通过更新模型，可以很好的适配实时更新的需求。

集群的维护

相比于单实例的数据库，任何一款分布式数据库维护的成本都要成倍的增长。一方面是节点增多，发生故障的几率变高。对于这种情况，我们需要一套良好的自动 failover 机制。另一方便随着数据量的增长，要能做到在线弹性扩缩容，保证集群的稳定性与可用性。 ClickHouse 中的节点扩容与重分布 与一般的分布式数据库或者 Hadoop 生态不同，HDFS 可以根据集群节点的增减自动的通过 balance 来调节数据均衡。但是 ClickHouse 集群不能自动感知集群拓扑的变化，所以就不能自动 balance 数据。当集群数据较大时，新增集群节点可能会给数据负载均衡带来极大的运维成本。 一般来说，新增集群节点我们通常有三种方案：

1. 如果业务允许，可以给集群中的表设置 TTL，长时间保留的数据会逐渐被清理到，新增的数据会自动选择新节点，最后会达到负载均衡。
2. 在集群中建立临时表，将原表中的数据复制到临时表，再删除原表。当数据量较大时，或者表的数量过多时，维护成本较高。同时无法应对实时数据变更。
3. 通过配置权重的方式，将新写入的数据引导到新的节点。权重维护成本较高。 无论上述的哪一种方案，从时间成本，硬件资源，实时性等方面考虑，ClickHouse 都不是非常适合在线做节点扩缩容及数据充分布。同时，由于 ClickHouse 中无法做到自动探测节点拓扑变化，我们可能需要再 CMDB 中写入一套数据重分布的逻辑。所以我们需要尽可能的提前预估好数据量及节点的数量。

StarRocks 中的在线弹性扩缩容 与 HDFS 一样，当 StarRocks 集群感知到集群拓扑发生变化的时候，可以做到在线的弹性扩缩容。避免了增加节点对业务的侵入。 StarRocks 中的数据采用先分区再分桶的机制进行存储。数据分桶后，会根据分桶键做 hash 运算，结果一致的数据被划分到同一数据分片中，我们称之为 tablet。Tablet 是 StarRocks 中数据冗余的最小单位，通常我们会默认数据以三副本的形式存储，节点中通过 Quorum 协议进行复制。当某个节点发生宕机时，在其他可用的节点上会自动补齐丢失的 tablet，做到无感知的 failover。 在新增节点时，也会有 FE 自动的进行调度，将已有节点中的 tablet 自动的调度到扩容的节点上，做到自动的数据片均衡。为了避免 tablet 迁移时对业务的性能影响，可以尽量选择在业务低峰期进行节点的扩缩容，或者可以动态调整调度参数，通过参数控制 tablet 调度的速度，尽可能的减少对业务的影响。

性能测试

测试环境

测试数据

|表名| 行数| 说明| | ------------ | ------------ | |lineorder| 6 亿| SSB 商品订单表| |customer |300万| SSB 客户表| |part |140 万| SSB 零部件表| |supplier |20 万| SSB 供应商表| |dates| 2556 |日期表| |lineorder_flat| 6 亿 |SSB 打平后的宽表|

starocks在企业中的应用

携程 x StarRocks：高效支持高并发查询，大幅降低人力和硬件成本（https://xie.infoq.cn/article/5ac3cf88ab2edbf3309f5d97e） 美团餐饮 SaaS 基于 StarRocks 构建商家数据中台的探索（https://xie.infoq.cn/article/603efacfc2c3a23de834dda75） StarRocks 在同程旅行的实践（https://xie.infoq.cn/article/bfde7469869f7bf33ca6c4a13） StarRocks 企业行｜走进 58 同城，探索极速统一 3.0 时代的企业实践（https://xie.infoq.cn/article/9d563631176b7a16e64d2a5ec） 性能全面飙升！StarRocks 在贝壳找房的极速统一实践（https://xie.infoq.cn/article/a8b530e2eec49ee30fafc6ae1） 腾讯游戏 ：我们如何基于 StarRocks 构建云原生数仓（https://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2651128799&idx=2&sn=71446e6d8cfff1444bc1d71962a09f3d&chksm=bdb8fb8c8acf729a2df8d817cedd9e032cb57e803b8a5312e4aed1ce18201871b1002a3c07e9&scene=27#wechat_redirect） 平安银行携手 StarRocks 荣获 2022 金融业数字化转型突出贡献奖（https://xie.infoq.cn/article/9dd4d272a334195b56ff69e1e）

其他数仓对比

什么是 StarRocks

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

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

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

使用 StarRocks，用户可以灵活构建包括大宽表、星型模型、雪花模型在内的各类模型。

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

适用场景

StarRocks 可以满足企业级用户的多种分析需求，包括 OLAP (Online Analytical Processing) 多维分析、定制报表、实时数据分析和 Ad-hoc 数据分析等。

OLAP 多维分析

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

• 用户行为分析

• 用户画像、标签分析、圈人

• 高维业务指标报表

• 自助式报表平台

• 业务问题探查分析

• 跨主题业务分析

• 财务报表

• 系统监控分析

实时数据仓库

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

电商大促数据分析

物流行业的运单分析

金融行业绩效分析、指标计算

直播质量分析

广告投放分析

管理驾驶舱

探针分析APM（Application Performance Management）

高并发查询

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

广告主报表分析

零售行业渠道人员分析

SaaS 行业面向用户分析报表

Dashboard 多页面分析

统一分析

通过使用一套系统解决多维分析、高并发查询、预计算、实时分析查询等场景，降低系统复杂度和多技术栈开发与维护成本。

使用 StarRocks 统一管理数据湖和数据仓库，将高并发和实时性要求很高的业务放在 StarRocks 中分析，也可以使用 External Catalog 和外部表进行数据湖上的分析。

产品特性

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 模式的产品有明显的性能优势。