StarRocks 核心原理

• 写时标记删除（Merge-on-Write）原理
• 与 MOR 模型的查询差异
• 实时更新场景的收益与代价

StarRocks 主键模型（Primary Key 表）采用 Merge-on-Write 语义：写入新数据时通过持久化主键索引（Persistent Index，索引存磁盘并有内存缓存）定位旧版本，同时写入新行并标记旧行删除，查询时只读最新版本，无需在查询期合并多个版本。相比 MOR（如 Doris Unique 早期实现），主键模型的查询延迟稳定、不受版本数影响，实时高频 upsert 后数据立即可见。

优势：实时更新（订单状态、用户余额等）场景写入即查询正确；支持部分列更新与条件更新；高并发点查与报表查询性能稳定。代价：每次写入需要定位并标记旧行，有额外的索引查询与删除标记开销，写入放大略高于纯追加；持久化主键索引占用一定磁盘与内存。选择：更新不频繁且查询少用主键的用 Unique/Duplicate，高频实时更新加高并发查询用主键模型。

优势核心是"写时标记删除、读时无合并"，回答对比 MOR 讲清查询收益与写入代价，并给出适用边界。

• CBO 的优化能力
• 同步与异步物化视图的差异
• 高并发支撑的机制组合

StarRocks 的 CBO 基于 Cascades 优化框架，由统计信息（行数、NDV、直方图）驱动，支持复杂 Join 重排、谓词下推、Runtime Filter 生成与物化视图改写，为复杂查询生成低代价执行计划，是高并发查询性能的基石。物化视图分两类：同步物化视图在基表导入时同步维护，数据实时一致，但增加写入开销，适合小表高频查询；异步物化视图由后台任务按间隔或事件刷新，支持多表 Join 与复杂聚合，写入无额外负担，但数据有延迟。

高并发支撑：物化视图把高频聚合预计算，查询改写命中后扫描小数据，降低 CPU 与 IO；配合分区裁剪、结果缓存、查询队列与资源组隔离，支撑大量并发报表查询。实践需权衡命中率、刷新延迟与存储成本。

CBO 保"计划优"，物化视图保"数据小"，两者协同支撑高并发，回答分两块展开并讲清同步/异步差异。

• 四种模型的语义定义
• 更新语义的差异
• 按场景选型

Duplicate 明细模型：保留所有导入行，无去重无聚合，适合日志、事实明细；Aggregate 聚合模型：按聚合键预聚合（SUM/MAX/REPLACE 等），适合统计汇总表；Unique 唯一键模型：按主键去重，后写入覆盖旧值（upsert），适合订单、用户等可变数据；Primary 主键模型：写时标记删除（Merge-on-Write），实时更新后查询免合并，支持部分列更新，适合高频实时更新加高并发查询。

更新语义差异：Duplicate 纯追加；Aggregate 按聚合方式合并；Unique/Primary 按主键覆盖，Primary 查询无合并开销且支持部分列更新、条件更新。选型：明细日志选 Duplicate，统计汇总选 Aggregate，一般更新选 Unique，高频实时更新与查询敏感选 Primary。

四种模型覆盖"无去重、预聚合、去重、高性能去重"的谱系，回答按模型语义与更新差异展开，并给出选型结论。

• 主键模型实现差异
• CBO 优化器差异
• 生态与适用场景

两者同源于 MPP 架构（FE/BE、分区分桶、副本与 Compaction 机制类似），核心差异在引擎细节：主键模型上，StarRocks 主键模型写时标记删除、查询免合并，Doris Unique 模型（MOR）查询需合并版本，高频实时更新加高并发查询场景 StarRocks 更优；优化器上，StarRocks CBO 基于 Cascades 框架、统计能力（直方图等）更强，复杂多表 Join 与子查询的优化更好；生态上，Doris 由 Apache 社区驱动，StarRocks 商业与云托管支持更成熟。

适用场景：高频实时更新加复杂分析选 StarRocks；偏好 Apache 开源生态、固定报表为主选 Doris；两者性能定位接近，选型应结合主键模型需求、查询复杂度、社区与商业支持综合评估。

差异集中在"主键模型实现"与"优化器"两个技术点，回答聚焦这两点再落到选型建议。

• External Catalog 的元数据映射机制
• 查询下推能力
• 湖仓一体的实践模式

External Catalog 把外部数据源（Hive/Iceberg/Hudi/Delta Lake）映射为逻辑库表，无需导入即可查询：StarRocks 对接外部元数据服务（HMS/Glue）获取表结构并缓存，查询时直接扫描外部文件（Parquet/ORC 等），支持分区裁剪、谓词下推与列裁剪到外部数据源，减少数据传输。数据仍留在湖上，实现"仓湖统一查询"。

性能保障：大查询走 MPP 并行扫描外部文件，可配合物化视图缓存高频结果；支持 Insert Into 把外部数据导入内部表（入仓加速），形成"湖上明细 + 仓内加速"的湖仓一体实践。注意：外部查询延迟高于内部表，冷数据访问依赖对象存储带宽，高频查询应物化入仓。

External Catalog 是"元数据映射 + 外部扫描 + 下推"，回答讲清机制、性能手段与湖仓一体的实践模式。

• 两级索引与物化视图的协同
• 与 Doris 的物化视图差异
• 主键模型对查询路径的影响

StarRocks 存储同样列式组织：Short Key Index（前缀索引）定位起始行，Zone Map（每个数据块的 min/max）裁剪不满足谓词的数据块，两级索引减少扫描量；物化视图做预聚合，查询改写命中后扫描小数据。协同链路：前缀索引定起点 → Zone Map 裁块 → 物化视图减量，逐层收窄扫描范围。

与 Doris 的差异：两者都有前缀索引与 ZoneMap，差异主要在物化视图能力与主键模型：StarRocks 支持同步与异步物化视图，多表 Join 与复杂聚合的改写能力更强；Doris 以 Rollup 加单表物化视图为主。主键模型差异影响更新场景的查询路径（StarRocks 写时删除、查询免合并）。

加速链条一致（索引裁量 + 物化减量），差异点落在物化视图能力与主键模型，回答对比要具体到机制。

• 持久化主键索引的定位机制
• 写入放大与查询性能的权衡
• 按场景选型

Unique 模型按主键去重但采用 Merge-on-Read：写入纯追加，查询时合并多版本取最新，写入放大小但查询随版本增多变慢；主键模型用持久化主键索引（Persistent Index，索引存磁盘并有内存缓存）定位旧版本，写入时标记删除加写新行（Merge-on-Write），查询只读最新版本，延迟稳定。

权衡：主键模型每次写入需定位并标记旧行，有索引查询与删除标记开销，写入放大略高、写路径更重；但高频实时更新加高并发点查/报表场景查询收益明显，且支持部分列更新减少重写量。选择：更新不频繁且查询对延迟不敏感用 Unique；高频 upsert 加查询性能敏感用主键模型；同时监控主键索引空间与内存占用。

差异本质是"读时合并 vs 写时标记"，回答按写入代价与查询收益的权衡展开，并给出选型边界。

• CBO 的计划优化职责
• MPP 的分布并行机制
• 向量化与动态过滤的执行加速

CBO（Cascades 框架）基于统计信息生成执行计划：选择 Join 顺序与策略（Broadcast/Shuffle/Colocate/Bucket Shuffle）、生成 Runtime Filter、改写物化视图；MPP 把计划分布到多个 BE 并行执行，支持本地 Join（Colocate/Bucket）减少网络 Shuffle；向量化执行按批处理列数据，利用 SIMD 指令加速扫描、过滤、哈希与聚合。

配合机制：CBO 定计划 → MPP 定分布与并行 → 向量化执行计算，执行期 Runtime/Dynamic Filter 动态裁剪数据，Pipeline 调度提升并发。三者共同决定"计划优、分布均、执行快"，是 StarRocks 复杂查询高性能的基础。

与 Doris 类似的三层配合结构，回答突出 CBO 强度、本地 Join 与动态过滤，体现层次配合。

• 三种导入方式与幂等事务
• 主键 upsert 与部分列更新
• 实时链路实践

Stream Load：同步 HTTP 导入，适合高频小批量实时数据与 Flink sink；Routine Load：常驻任务自动消费 Kafka 导入，自动管理消费位点；Broker Load：批量文件导入。三者均支持 label 幂等与事务语义，配合 Flink 两阶段提交可实现端到端 Exactly-Once。

主键 upsert：导入数据按主键写入，存在则更新（标记删除旧行加写新行），支持部分列更新（仅更新指定列）与条件更新（按版本号条件覆盖）。实时链路实践：Kafka → Flink（清洗加工）→ StarRocks 主键表，秒级可见，支撑实时指标与在线服务；监控导入延迟、label 失败率与主键表 Compaction。

导入 = 通道 + 幂等语义，实时更新 = 主键 upsert + 部分列更新，回答分两层并给出链路实践。

• 分区裁剪与分桶分布的职责
• 分桶数与并行度的关系
• 对导入的影响与调优

分区按时间等维度切分，查询谓词命中时分区裁剪，只扫描相关分区，直接决定查询扫描量；分桶按分桶键哈希分布数据，决定并行度与本地 Join 能力（Colocate、Bucket Shuffle），分桶数建议取 BE 数的整数倍：过大会增加元数据与调度开销，过小并行度不足。分桶键应选高基数列且查询等值条件常用列。

对导入的影响：数据按分区桶分布写入，分桶数过多产生过多小文件与导入调度开销，分桶键低基数造成数据倾斜；查询侧分区裁剪减少扫描量，分桶影响并行度与 Join 本地化。实践：时间分区加高基数业务键分桶，定期评估桶数据分布与查询并行度，动态调整。

分区管"裁剪"，分桶管"分布与并行"，回答分别讲清对查询与导入的影响及调优要点。

• 向量化执行的批处理原理
• SIMD 指令的加速对象
• 性能收益与边界

向量化执行按列批处理：算子间以数据块（Batch）传递，避免逐行解释与虚函数调用；SIMD（单指令多数据）让 CPU 一次处理多个元素，加速位图运算、比较、哈希与聚合等操作，配合列式存储提升内存带宽利用。扫描、过滤、聚合与 Join 的 CPU 效率大幅提升。

影响与边界：复杂分析查询可数倍提升吞吐；前提是列式存储与批处理管道，依赖 CPU 指令集（如 AVX2）；当瓶颈在 IO、网络或数据量大到无法缓存时，向量化收益有限。回答要说明"向量化解决 CPU 瓶颈，不解决 IO 瓶颈"。

向量化是"批处理 + 列式 + SIMD"的组合，回答讲清原理、收益与适用边界，避免夸大其作用。

• 统计信息与直方图的作用
• 复杂 Join 的计划空间
• 与 Doris 的优化器差异

StarRocks CBO 基于 Cascades 优化框架，依赖统计信息（行数、NDV、直方图）与代价模型：支持多表 Join 重排、谓词下推、Runtime Filter 生成与物化视图改写，可枚举更大的计划空间，对复杂多表 Join、子查询与 CTE 的优化更精细；统计信息需定期收集（analyze），过时统计会导致计划偏差，可用 Hint 修正。

与 Doris 差异：Doris CBO 同样支持 Join 重排与 Runtime Filter，但 StarRocks 的统计感知（直方图、高基数列）与复杂查询优化能力更强；Doris 的 Rollup 预聚合体系在固定报表场景成熟。运维要点：定期 analyze、监控计划变化与 Join 策略选择。

差异在优化框架与统计能力，回答讲清机制差异与运维要点（analyze），并落到复杂 Join 场景的选型影响。

• 主键模型的实现差异
• 优化器的能力差异
• 对选型的影响

主键模型：Doris Unique 模型采用 MOR（查询合并版本），StarRocks 主键模型采用写时标记删除（MOW），查询免合并、支持部分列更新与条件更新，高频实时更新场景查询性能更稳定。优化器：StarRocks 基于 Cascades 的 CBO 统计能力更强（直方图等），复杂多表 Join 优化更好；Doris CBO 成熟且 Rollup 预聚合体系在固定报表场景有优势。

对选型的影响：高频实时更新加高并发查询、复杂分析选 StarRocks；固定报表为主、偏好 Apache 社区生态选 Doris；两者性能定位接近，最终按更新频率、查询复杂度、团队与生态综合决策。

两大差异即本题两个考察点，回答对比后落到选型建议，避免只罗列特性。

• 资源组的路由与限制
• 查询隔离与高峰保护
• 多租户配额实践

资源组（Resource Group）按标签、用户或查询属性把查询路由到不同组，每组可限制 CPU、内存与并发数，实现查询隔离：大查询与在线查询分资源组，避免互相拖垮；支持队列与优先级调度，超配额查询排队或拒绝，保护集群稳定。

多租户实践：按业务线划分资源组与权限，设置并发与内存配额，在线报表组低延迟高优先级、离线大查询组限并发，监控各组使用率并动态调整配额。回答强调"隔离保障互不影响，配额保障公平可控"。

资源组 = 按租户/场景隔离 + 配额约束，回答讲清机制与典型的多租户配置实践。

• 同步与异步的实时性与开销
• 查询改写命中条件
• 选择权衡

同步物化视图在基表导入时同步维护，数据实时一致，但增加写入开销，适合基表更新不频繁、查询高频的小表；异步物化视图由后台任务按间隔或事件刷新，支持多表 Join 与复杂聚合，写入无额外负担，但数据有延迟。选择权衡：同步保实时性、异步保写入性能，按数据新鲜度 SLA 决定。

查询改写：优化器识别查询与物化视图匹配（维度、聚合函数、谓词为物化对象子集）自动改写，命中即查小数据；需监控命中率、刷新耗时与存储，及时移除低效物化视图。

同步/异步 = 实时性与写入开销的权衡，改写是收益来源，回答按此展开并给出管理要点。

• 查询缓存与结果缓存的原理
• 分区级失效机制
• 适用场景与权衡

查询缓存与结果缓存复用相同查询的结果：相同 SQL 直接返回缓存结果，避免重复计算；StarRocks 支持分区级缓存，缓存与分区绑定，数据变更时自动失效对应分区，保证缓存一致性。适合高频重复的固定报表与低延迟查询。

适用与权衡：高频固定 SQL 收益大；大结果集、数据实时性要求极高（缓存引入延迟）或参数化极多的 Ad-hoc 查询不适合缓存；需配置缓存上限与 TTL，监控命中率评估收益。

缓存 = 结果复用，核心是失效策略（分区级）与适用边界，回答讲清机制、一致性与权衡。

• 同步/异步的选择依据
• 查询改写的典型场景
• 管理与监控

选择依据：需要实时一致且基表更新不频繁选同步；数据量大、聚合复杂、允许分钟级延迟选异步；多表 Join 的物化视图只能异步（同步支持受限）；异步刷新频率按新鲜度 SLA 设置。改写场景：固定维度聚合报表、KPI 看板、多表预 Join 宽表等高频查询。

改写命中条件：查询的维度、聚合函数与谓词为物化对象子集，可自动推导；管理上监控命中率、刷新耗时与存储成本，移除低效物化视图，防止存储放大。

选择 = 实时性 SLA × 写入开销 × 复杂度，改写场景 = 高频聚合与预 Join，回答给决策依据与管理要点。