简介：《EMR StarRocks 白皮书》面向数据分析师、数据仓库工程师与架构选型人员，系统梳理新一代极速全场景 MPP 数据仓库 StarRocks 的产品全貌，帮助读者理解其如何支撑“极速统一”的数据分析新范式。白皮书从简洁的 FE/BE 架构切入，讲解元数据管理、查询规划与数据存储执行的分工，并展开全面向量化引擎、CBO 优化器、现代化物化视图、MySQL 协议兼容等技术特性，同时覆盖实时数仓、用户画像、实时风控、订单分析、自助 BI 等典型场景及数据迁移、湖仓一体、Flink 生态等模块。资源包共 1 个 PDF 文件，约 13.78MB，单文件即完整白皮书，便于通读与检索。已有 244 人学习，适合作为技术选型、方案汇报与团队内部分享的参考材料。
1. 到底什么是 MPP 数据仓库：从“一个人搬砖”到“一群人搬砖”说起
如果你在一家稍具规模的公司里做数据相关的工作，大概率听过“数据仓库”这个词。但很多人对它的理解停留在“存数据的地方”，这其实只说对了一半。真正让数据仓库有价值的，是它能在你点下“查询”按钮之后，用多快的速度把答案端到你面前。StarRocks 就是在这个“快”字上做文章的一款产品，官方给它的定位是“新一代极速全场景 MPP 数据仓库”。这里的关键词是 MPP，全称 Massively Parallel Processing，翻译过来叫大规模并行处理。
打个比方你就懂了。假设你要从一百万块砖里挑出红色的那些。一个人搬，得搬很久；但如果叫上一百个人，每人负责一小堆，同时开工，最后把各自挑出来的红砖汇总，时间就缩短了近百倍。MPP 就是这个思路：把一条查询任务拆散，分散到多台服务器上同时算，再把各自的结果拼起来。StarRocks 把这件事做得比较彻底，它的架构里没有“总包工头”式的单点瓶颈，数据分布在多个后端节点上，计算也跟着数据走，尽量不让数据来回搬运。
为什么值得搞懂这个概念？因为当你听到“实时看板”“用户画像”“实时风控”这些业务需求时，背后往往就是 MPP 数据仓库在撑着。理解了它，你就能判断一个系统到底适不适合你的场景，而不是被一堆名词绕晕。
2. 为什么需要 StarRocks：传统方案到底卡在哪
2.1 烟囱式架构带来的数据孤岛
很多公司早期做数据分析，是这么干的：业务库用 MySQL，日志丢到 HDFS，报表跑在 Hive 上，实时看板又接一套 Kafka 加流计算。每套系统各管一摊，像一根根烟囱竖在那里，彼此不通气。结果就是，你想把实时数据和离线数据关联起来看，得先写一堆 ETL 脚本把数据搬来搬去，搬完还不一定对得上。StarRocks 想解决的就是这个问题：用一套系统覆盖多种分析场景，减少数据搬运和预处理。它支持外表联邦查询，可以直接读 Hive、Iceberg、Hudi、MySQL、Elasticsearch 里的数据，不用先把所有数据都灌进来。
2.2 实时性与并发能力的双重压力
传统数仓有个血泪经验：T+1 跑批。今天的数据，明天才能看。但业务不等人，实时看板要秒级更新，风控要毫秒级响应。StarRocks 通过消费 Kafka 数据源实现秒级写入，数据即导即用；同时它的分区分桶存储加上 MPP 架构优化，让小型查询不会过度消耗资源，官方说法是合适规划下能支撑上万 QPS、数千用户同时分析。这背后的逻辑是：数据按分区和分桶切好之后，查询时能精准定位到需要扫描的那一小块，而不是全表扫一遍。
2.3 运维复杂度与成本的现实考量
一套系统好不好用，不光看跑得快不快，还得看养起来累不累。StarRocks 的架构里只有 FE（Frontend）和 BE（Backend）两类进程，不依赖任何外部组件，部署和维护相对简单。FE 负责元数据管理、连接管理、查询规划和调度，BE 负责数据存储和计算执行。FE 有 Follower 和 Observer 两种角色，Follower 通过类 Paxos 协议选主，Observer 只异步同步日志、扩展查询并发。BE 节点完全对等，数据多副本存储，节点故障时自动补齐副本。这种设计的好处是：扩容不用停服，节点宕机不影响整体集群稳定性，对运维来说少了很多半夜被叫起来的理由。
3. StarRocks 的核心机制：它凭什么跑得快
3.1 全面向量化引擎：让 CPU 一次多干点活
传统执行引擎大多是一次处理一个元组，CPU 大部分时间花在循环调用和函数跳转上，真正用于计算的比例不高。StarRocks 引入了全面向量化引擎，核心思想是一次处理一批数据，把多次迭代调用变成一次计算。它基于 SIMD 指令集做优化，同一条 CPU 指令可以处理多份数据。官方给出的数据是：条件过滤计算有 5.1 倍性能提升，聚合计算有 14.9 倍提升，关联计算有 3 到 4 倍提升。通俗地说，以前是逐个检查每块砖的颜色，现在是拿一把特制的尺子一次量一排。
3.2 CBO 优化器：把 SQL 调优的活交给机器
CBO 全称 Cost Based Optimizer，基于成本的优化器。和很多 MPP 引擎用的 RBO（基于规则的优化器）不同，CBO 不需要你预先规定好驱动表顺序、谓词条件顺序这些规则，它会根据统计信息自动判断哪种执行计划代价最低。StarRocks 的查询规划要经过 Parser、Analyzer、Transformer、SQL Rewriter、Tree Rewriter、Optimizer、FragmentBuilder 七个流程，其中 Tree Rewriter 阶段会做谓词下推、分区分桶裁剪、列裁剪等操作，Optimizer 阶段生成物理计划。在 TPC-H 1T 基准测试中，使用 CBO 的版本相比未使用的版本性能有 5 到 10 倍提升。这意味着很多以前需要资深工程师手动调的 SQL，现在优化器自己就处理了。
3.3 数据模型与分区分桶：存储层的前置设计
StarRocks 提供三种数据模型：明细模型（Duplicate Key）用于存储原始明细数据，插入什么就存什么；聚合模型（Aggregate Key）用于预聚合场景，主键重复时按指定聚合函数合并；主键模型（Primary Key）用于频繁更新场景，支持 UPSERT 操作，采用 Insert and Delete 模式，实时导入和查询性能更好。存储上采用两级分区：第一级 Range 分区按时间等区间切分，方便冷热数据分级和分区生命周期管理；第二级 Hash 分桶把数据打散成 Tablet，多副本冗余存储，是数据均衡和恢复的最小单位。分区分桶规划得好，查询时就能利用分区剪裁、分桶剪裁和前缀索引减少扫描量，这是高并发能力的根基。
4. 易混概念辨析：别把这几组词搞混了
4.1 MPP 与普通分布式数据库
容易混的点在于，两者都涉及多台机器。但普通分布式数据库可能只是把数据分散存，查询时仍然有中心节点协调，容易形成瓶颈。MPP 强调的是“并行计算”，任务被拆到各节点同时执行，各节点算完各自的部分再汇总。StarRocks 的 BE 节点完全对等，SQL 按数据分布拆成物理执行单元，在数据所在节点执行，避免传输和拷贝。区分方法很简单：看查询计划里有没有“并行分发”和“本地计算”的特征。
4.2 数据湖与数据仓库
数据湖按原始格式存数据，不需要事先结构化，能存结构化、半结构化、非结构化数据；数据仓库则偏向经过建模和组织的结构化数据。StarRocks 的定位是数据仓库，但它能作为数据湖的查询引擎，通过外表读取 Hive、Iceberg、Hudi 的数据。湖仓一体说的是两者配合：湖负责低成本存储，仓负责高性能计算。别把“能查数据湖”理解成“StarRocks 就是数据湖”，这是两回事。
4.3 物化视图与普通视图
普通视图只是一段保存下来的 SQL，查询时展开执行，不存实际数据。物化视图会把计算结果实际存下来，查询时可以直接命中，从而加速固定维度的聚合分析。StarRocks 支持现代化物化视图，能实现明细数据的上卷和下钻。容易混的地方是以为建了视图就变快了，其实普通视图不会，物化视图才会，但代价是占用存储并且需要刷新。
4.4 明细模型与主键模型
两者都存明细，区别在更新能力。明细模型插入的数据与表中存储一一对应，适合召回原始数据、更新不频繁的场景。主键模型支持 UPSERT，主键存在时更新、不存在时插入，适合数据频繁更新的场景。如果你拿明细模型去做频繁更新，会发现要么写不进去，要么得整批重刷，这就是选型翻车的高发区。
4.5 资源组与资源队列
资源组是 StarRocks 里做资源隔离的单位，包含 BE 节点的 CPU、内存配额，一个资源组可以绑定一个或多个分类器。分类器按用户名、角色、查询类型、来源 IP 四个条件匹配查询任务，匹配度最高的分类器生效。它和传统数据库里的资源队列不是一回事：资源组直接划分 BE 的计算资源，粒度更细，能实现大小查询隔离、ETL 和查询隔离、导入和查询隔离等场景。
5. 什么时候该用、什么时候别用：一份边界判断清单
5.1 适合上 StarRocks 的场景
从白皮书给出的场景方案来看，以下几类业务比较对口。固定报表和自助 BI：兼容 MySQL 协议和标准 SQL，主流 BI 工具接入性好，应用无需或少量修改代码即可从 MySQL 迁入。实时看板和实时风控：通过 Routine Load 消费 Kafka 增量数据，秒级写入，配合主键模型做实时更新。用户画像和订单分析：灵活建模支持星型、雪花、大宽表、预聚合，物化视图加速固定维度聚合。湖仓一体分析：用外表直接查 Hive、Iceberg、Hudi，避免全量搬迁。高并发查询：分区分桶规划合理加一定节点规模，可支撑上万 QPS。
5.2 需要谨慎评估的情况
如果你的数据量很小、并发很低，一套单机 MySQL 就能搞定，引入 MPP 集群反而增加运维负担。如果你的业务以复杂离线批处理为主、对实时性没要求，传统 Hive 加 Spark 的成熟链路可能更省心。如果你需要的是事务型强一致的 OLTP 能力，StarRocks 的定位是 OLAP 分析，别拿它当业务主库用。另外，分区分桶设计需要提前规划，建表时分区键和分桶键选得不合理，后期查询性能会打折扣，这不是产品的问题，是设计的问题。
5.3 一个具体的选型对照
| 判断维度 | 倾向使用 StarRocks | 倾向其他方案 |
|---|---|---|
| 数据量级 | 单集群可到数百节点、10PB 级别 | 数据量很小，单机可承载 |
| 实时性要求 | 秒级写入、即导即用 | 只做 T+1 离线批处理 |
| 查询并发 | 数千用户、上万 QPS | 少量分析师低频查询 |
| 数据源 | 多源联邦查询、湖仓一体 | 单一数据源、结构简单 |
| 更新频率 | 需要频繁 UPSERT | 只追加、不更新 |
| 运维投入 | 希望架构简洁、少外部依赖 | 已有成熟数仓团队和链路 |
5.4 选型时容易忽略的细节
有个踩坑点值得单独说：导入方式的选择。Stream Load 适合 10G 以下的平面文件，Broker Load 适合 10GB 到 1000GB 的 HDFS 或 S3 数据，Spark Load 适合几 TB 的初次全量迁移，Routine Load 适合 Kafka 流式导入，Insert Into 适合几百 MB 的轻量导入。选错导入方式，轻则慢，重则把集群资源打满。还有 Flink 生态里的 Exactly Once 语义，依赖 Flink 的 checkpoint 机制和 StarRocks 的 Label 机制配合，配置不对就会出现重复或丢失，这类问题排查起来相当费劲。
从那以后我每次评估一个分析型系统，都会先问三个问题：数据从哪来、要多快看到结果、有多少人同时查。这三个答案基本能框定该不该用 MPP 数据仓库、该选哪种导入方式、该建什么模型。希望这份梳理帮到你，白皮书里还有架构细节、导入方式对照表、社区版与企业版功能对比这些内容，需要完整资料的话可以自行获取查阅。
本文还有配套的精品资源，点击获取
