调研时间：2026年6月 | 版本基准：StarRocks 3.x / Apache Kylin 5.x
一、概述
1.1 StarRocks
StarRocks 是新一代极速全场景 MPP（Massively Parallel Processing）数据库，原为 DorisDB，2021 年正式更名。其核心定位是实时数仓 + 湖仓一体，兼容 MySQL 协议，采用全向量化执行引擎 + CBO 优化器，查询性能（尤其多表关联）显著领先同类产品。
- 开源协议：Apache 2.0
- 开发语言：C++（BE）+ Java（FE）
- 最新版本：3.x（支持存算分离）
- 社区规模：GitHub 8K+ Stars，300+ 贡献者
- 典型用户：腾讯、携程、平安银行、京东物流、顺丰、理想汽车、去哪儿等
1.2 Apache Kylin
Apache Kylin 是开源分布式 MOLAP 分析引擎，2013 年由 eBay 中国研发中心开发，2015 年成为 Apache 顶级项目（首个由中国团队主导的 Apache 顶级项目）。核心思想是预计算 Cube + 空间换时间，通过将多维 Cube 预计算结果存储在 HBase/Parquet 中实现亚秒级查询。
- 开源协议：Apache 2.0
- 开发语言：Java
- 最新版本：5.x（使用 Spark + Parquet 替代 HBase）
- 社区规模：Apache 顶级项目，Kyligence 提供商业版
- 典型用户：美团、滴滴、携程、贝壳找房、腾讯、京东、百度等
二、架构对比
2.1 技术架构
| 维度 | StarRocks | Apache Kylin |
|---|---|---|
| OLAP 类型 | ROLAP（基于关系模型） | MOLAP（基于多维 Cube） |
| 核心架构 | MPP 分布式架构（FE + BE/CN） | Hadoop 生态架构（Query Server + Job Server + Metadata） |
| 存储引擎 | 自研列式存储引擎（支持实时更新） | HBase（v3.x）/ Parquet on HDFS（v4.x+） |
| 计算引擎 | 全向量化执行引擎 + Pipeline | Spark（构建+查询）/ MapReduce（早期） |
| 查询加速 | CBO 优化器 + 物化视图 + 智能索引 | 预计算 Cube + Cuboid 剪枝 + 维度字典 |
| 存算架构 | 存算一体（v2）/ 存算分离（v3+） | 存算分离（天然，计算依赖 Spark，存储依赖 HDFS/HBase） |
| 外部依赖 | 无外部依赖（自包含） | 依赖 Hadoop 生态（HDFS、Hive、Zookeeper、Spark） |
| 元数据存储 | FE 内部存储（基于 BDBJE） | HBase / RDBMS |
2.2 架构图对比
StarRocks 架构：
Kylin 架构：
三、核心特性对比
3.1 查询性能
| 维度 | StarRocks | Apache Kylin |
|---|---|---|
| 查询延迟 | 亚秒级（多数场景 < 1s） | 亚秒级（命中 Cube 时 < 1s） |
| 查询模式 | 即席查询为主，无需预定义 | 需预定义模型和 Cube，命中预计算结果时极快 |
| 多表 JOIN | 极强（CBO + 向量化 + Colocate Join） | 较弱（Cube 通常基于星型模型，复杂 JOIN 需建模时考虑） |
| 非预计算查询 | 原生支持，性能优异 | 不支持（未命中 Cube 的查询可能回退到 Spark，延迟高） |
| 聚合查询 | 高效（向量化 + 列式扫描） | 极快（直接读取预计算结果） |
| 精确去重 | 原生支持（主键模型） | 支持 Bitmap 精确去重 |
| 近似去重 | 支持 HLL / Bitmap | 支持 HyperLogLog |
关键差异：Kylin 在命中 Cube 的场景下查询性能极快（毫秒级），但灵活性不足——未命中预计算结果的查询要么无法执行，要么回退到 Spark 执行导致延迟剧增。StarRocks 不依赖预计算，所有查询均实时执行，性能一致且可预期。
3.2 数据模型
| 维度 | StarRocks | Apache Kylin |
|---|---|---|
| 支持模型 | 明细模型、聚合模型、更新模型、主键模型 | 星型模型、雪花模型 |
| 宽表支持 | 支持（最多 10000 列） | 不直接支持（需通过 Cube 建模间接实现） |
| 数据更新 | 支持 Upsert / Partial Update / 实时写入 | 主要批量构建 Cube，实时能力弱（分钟级） |
| Schema 变更 | 灵活（Lightning Schema Change） | 较复杂（需重建 Cube） |
| 明细查询 | 原生支持（明细模型） | 不擅长（Cube 聚合后丢失明细） |
3.3 数据摄入与时效性
| 维度 | StarRocks | Apache Kylin |
|---|---|---|
| 实时导入 | 秒级可见（Stream Load / Flink Connector） | 分钟级（Kafka 微批构建，3-5 分钟延迟） |
| 批量导入 | Broker Load / Routine Load / Spark Load | Hive 数据源 + Cube 构建（小时级） |
| CDC 同步 | 支持 Flink CDC / Debezium | 不原生支持 |
| 数据更新 | 主键模型支持实时 Upsert | 需重建 Cube Segment |
| 数据时效性 | 秒级 | 分钟级到小时级 |
| 导入方式 | 多样（Stream/Broker/Routine/Spark/Flink） | Hive 表 / Kafka 流 |
3.4 预计算与加速
| 维度 | StarRocks | Apache Kylin |
|---|---|---|
| 加速机制 | 物化视图（异步/同步） | Cube 预计算（核心机制） |
| 预计算粒度 | 按需定义物化视图，灵活 | 需穷举维度组合（2^N-1 个 Cuboid） |
| 存储膨胀 | 可控（仅物化视图增加存储） | 较大（Cube 可能是原始数据的数倍甚至 10+ 倍） |
| 自动路由 | CBO 自动识别物化视图并路由 | 自动路由到匹配的 Cuboid |
| 预计算成本 | 低（按需，仅定义需要的物化视图） | 高（Cube 构建耗时长，消耗大量计算资源） |
| 维度爆炸 | 无此问题 | 严重（维度超过 10 个时 Cube 膨胀急剧） |
3.5 可运维性
| 维度 | StarRocks | Apache Kylin |
|---|---|---|
| 部署复杂度 | 简单（FE + BE，无外部依赖） | 复杂（依赖 Hadoop 全套生态） |
| 运维成本 | 低 | 高（需运维 HDFS/Hive/ZK/Spark/HBase 等） |
| 弹性扩缩容 | 支持（存算分离模式下 CN 弹性伸缩） | 有限（依赖 Hadoop 集群扩容） |
| 监控告警 | 内置 Dashboard + Prometheus 集成 | 依赖外部监控系统 |
| 故障恢复 | 多副本自动恢复 | 依赖 Hadoop 生态的容错能力 |
| 升级难度 | 低（滚动升级） | 中高（需协调 Hadoop 各组件版本） |
四、适用场景分析
4.1 StarRocks 最佳场景
| 场景 | 说明 |
|---|---|
| 实时数仓 | 秒级数据摄入 + 即时查询，适合电商大促、物流运单、金融指标等实时监控 |
| 多维分析报表 | 灵活选择星型/雪花/宽表模型，支持即席分析 |
| 高并发查询 | 单集群可支撑数千并发查询，适合面向用户的报表系统 |
| 湖仓一体分析 | 直接查询 Hive/Iceberg/Hudi/Delta Lake 数据，无需数据搬迁 |
| 用户画像与圈人 | 支持 Bitmap 精确去重和交集运算 |
| 多表关联分析 | CBO + Colocate Join，多表关联性能远超同类 |
4.2 Kylin 最佳场景
| 场景 | 说明 |
|---|---|
| 固定维度报表 | 维度相对固定（10 个以内），查询模式可预测 |
| 超大规模数据聚合 | TB~PB 级数据预计算后查询，适合海量历史数据分析 |
| 高并发低延迟查询 | 命中 Cube 时毫秒级响应，CPU 消耗低，并发能力强 |
| Hadoop 生态深度融合 | 已有成熟 Hadoop 集群，数据主要在 Hive 中 |
| 传统 BI 报表 | 与 Tableau/PowerBI/Excel 深度集成，适合自助分析 |
4.3 不适用场景
| 场景 | StarRocks 不适用 | Kylin 不适用 |
|---|---|---|
| 明细数据查询 | 适合 | 不擅长（Cube 丢失明细） |
| 频繁 Schema 变更 | 灵活支持 | 困难（需重建 Cube） |
| 即席探索性分析 | 强项 | 不适合（无法命中预计算） |
| 实时数据更新 | 强项 | 不擅长（Cube 构建延迟大） |
| 维度多且变化 | 无影响 | 维度爆炸问题严重 |
| 小规模团队快速起步 | 简单易部署 | 依赖重，门槛高 |
五、性能基准参考
基于公开基准测试和社区实践的综合对比：
| 指标 | StarRocks | Kylin |
|---|---|---|
| 简单聚合查询（命中预计算） | 亚秒级 | 毫秒级 |
| 简单聚合查询（未命中预计算） | 亚秒级 | 需回退 Spark，秒级到分钟级 |
| 多表 JOIN（3-5 表） | 1-5 秒 | 需建模为 Cube，否则无法执行 |
| 即席查询 | 1-10 秒 | 可能无法执行或极慢 |
| 数据导入延迟 | 秒级 | 分钟到小时级 |
| 并发能力（QPS） | 数千到数万 | 数千（命中 Cube 时） |
| 存储效率 | 列式压缩，膨胀率低 | Cube 膨胀率 1x~10x+ |
六、选型决策矩阵
| 决策因素 | 推荐 StarRocks | 推荐 Kylin |
|---|---|---|
| 已有 Hadoop 生态 | 不作为主要考虑 | 强烈推荐 |
| 无 Hadoop 生态 | 强烈推荐 | 不推荐 |
| 查询模式固定、维度少 | 两者皆可 | 推荐（更极致性能） |
| 查询灵活多变 | 强烈推荐 | 不推荐 |
| 需要实时数据分析 | 强烈推荐 | 不推荐 |
| 需要明细+聚合混合查询 | 强烈推荐 | 不推荐 |
| 维度 > 10 个且变化 | 推荐 | 不推荐 |
| 团队规模小、运维能力弱 | 强烈推荐 | 不推荐 |
| 数据在 Hive 中、离线为主 | 两者皆可 | 推荐 |
| 需要湖仓一体 | 强烈推荐 | 不推荐 |
| 存储成本敏感 | 推荐（存算分离） | 一般（Cube 膨胀大） |
| 需要兼容 MySQL 协议 | 强烈推荐 | 不支持 |
| 精确去重需求多 | 推荐（主键模型） | 推荐（Bitmap） |
七、总结
StarRocks 优势
- 极速统一：ROLAP 架构，无需预计算即可实现亚秒级查询，查询性能一致可预期
- 实时能力：秒级数据摄入与查询，主键模型支持实时 Upsert
- 多表关联：CBO + 向量化 + Colocate Join，多表关联性能业界领先
- 架构简洁：无外部依赖，部署运维简单，存算分离弹性伸缩
- 湖仓一体：直接查询数据湖数据，无需数据搬迁
- MySQL 兼容：零学习成本迁移，广泛 BI 工具兼容
Kylin 优势
- 极致预计算：命中 Cube 时查询毫秒级，CPU 消耗极低
- 超高并发：查询仅读取预计算结果，可支撑极高并发
- Hadoop 融合：与 Hive/HDFS/Spark 深度集成，适合已有 Hadoop 体系的企业
- 低成本高吞吐：查询资源消耗低，同等硬件支撑更多查询
- 成熟生态：Apache 顶级项目，Kyligence 提供商业支持
核心结论
- 选 StarRocks：需要实时分析、灵活查询、多表关联、湖仓一体、快速落地、低运维成本
- 选 Kylin：已有成熟 Hadoop 生态、查询模式固定、维度较少、追求极致查询性能和超高并发
当前行业趋势：StarRocks 因实时能力、灵活性和低运维成本，正在成为更多企业统一 OLAP 引擎的首选。Kylin 在特定场景（固定维度报表、超大数据量预计算）仍有不可替代的优势，但适用场景在收窄。
 agent和组件)
