简介《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 实时性与并发能力的双重压力传统数仓有个血泪经验T1 跑批。今天的数据明天才能看。但业务不等人实时看板要秒级更新风控要毫秒级响应。StarRocks 通过消费 Kafka 数据源实现秒级写入数据即导即用同时它的分区分桶存储加上 MPP 架构优化让小型查询不会过度消耗资源官方说法是合适规划下能支撑上万 QPS、数千用户同时分析。这背后的逻辑是数据按分区和分桶切好之后查询时能精准定位到需要扫描的那一小块而不是全表扫一遍。2.3 运维复杂度与成本的现实考量一套系统好不好用不光看跑得快不快还得看养起来累不累。StarRocks 的架构里只有 FEFrontend和 BEBackend两类进程不依赖任何外部组件部署和维护相对简单。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 级别数据量很小单机可承载实时性要求秒级写入、即导即用只做 T1 离线批处理查询并发数千用户、上万 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 数据仓库、该选哪种导入方式、该建什么模型。希望这份梳理帮到你白皮书里还有架构细节、导入方式对照表、社区版与企业版功能对比这些内容需要完整资料的话可以自行获取查阅。本文还有配套的精品资源点击获取
