Doris
MPP 架构的实时数仓，FE 管元数据 BE 存数据
Doris 是百度开源的 MPP 分析数据库（StarRocks 也源于它）。FE 负责解析 SQL、规划执行，BE 负责存储和计算，查询被拆成多个 fragment 在所有 BE 上并行跑。相比 ClickHouse，它 join 更强、并发更高、导入更省心。
它解决什么问题
ClickHouse 做宽表分析很快，但业务方要的多表 join 和分析师写的复杂 SQL 经常跑不动；而且高并发点查撑不住，运维还得自己补一堆周边。
真实场景：典型场景：数仓 DWS 层建在 Doris 上，报表平台 200 个用户同时在线查不同维度，还要支持按主键更新维表。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
FE / BE
FE 管元数据、解析 SQL、调度；BE 存数据、干活
类比：FE 是调度中心，BE 是车间
看概念详情Tablet
表的水平分片，一个 Tablet 有多个副本，落在不同 BE 上
类比：一本书拆成若干册，每册复印三份分开放
看概念详情分区分桶
先按时间分区，再按哈希分桶，决定数据怎么切
类比：先按月份分柜子，再按编号分格子
看概念详情物化视图
预计算好的聚合结果，查询自动改写命中
类比：提前算好的汇总表，不用每次重新加
看概念详情MPP
一条查询拆到所有节点并行算，再汇总结果
类比：一百个人分头数钱，最后加起来
看概念详情数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
一条查询在 Doris 里是怎么并行跑完的
← 左右滑动查看完整流程图 →
客户端发来一条 SQL，FE 用 MySQL 协议接收，走标准解析流程。
提示：FE 只做规划和调度，真正的扫描、join、聚合全部下推到 BE 并行执行。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- MPP 并行 + 列存，多表 join 比 ClickHouse 稳
- 支持主键模型（Unique Key），能按主键 upsert，维表更新友好
- MySQL 协议，BI 工具和现有代码几乎零改造
- FE 高可用、副本自动均衡，运维比 ClickHouse 省心
- 单表极致扫描性能不如 ClickHouse（尤其宽表大聚合）
- 写入是批量导入模型，不适合高频单条事务写
- 版本迭代快，升级踩坑需要看 release notes
- 集群最小规模要 3 FE + 3 BE，小项目成本偏高
常见使用场景
每个场景都配一句「为什么用它」。
实时数仓 DWS 层
Flink 实时写入 Doris，报表直接查 DWS 宽表。
为什么用它：支持主键更新 + 高并发查询，指标能实时刷新。
统一报表平台
几百个用户同时查不同维度，用物化视图扛住重复聚合。
为什么用它：MPP 并行 + 物化视图透明改写，并发和延迟都稳。
湖仓查询加速
通过 External Catalog 直接查 Hive / Iceberg 表，把热数据落到 Doris 内表。
为什么用它：冷热分离，既省存储又能秒级响应。
同类对比
和同赛道的组件并排看，差异一目了然。
三者常常同时存在：Hive 存原始与明细、Doris 做实时报表、ClickHouse 扛大屏聚合。选型先问「查询长什么样、并发多少、要不要更新」，再比性能。
常见问题
上手第一个月最容易卡住的地方。
Q1Doris 和 ClickHouse 到底怎么选？
看查询形态：单表大宽表、极致聚合性能、数据量 TB 级以上，选 ClickHouse；多表 join、需要按主键更新、并发高（几十上百 QPS）、团队想要 MySQL 兼容，选 Doris。预算够的话两个都上也很常见。
Q2数据怎么导进去？
主流三种：Stream Load（HTTP 推，适合批量文件）、Routine Load（直接消费 Kafka，最常用）、Broker Load（从 HDFS/S3 拉）。实时场景一般 Flink 写 Kafka，Doris 用 Routine Load 消费。
Q3分区分桶怎么设计？
分区用时间字段（按天或按月），方便冷数据删除；分桶用高基数的查询字段（如 user_id），桶数建议是 BE 数量的整数倍。分桶字段选错会导致数据倾斜，一个 BE 忙死其他闲着。
Q4Doris 和 StarRocks 是什么关系？
同源。Doris 从百度 Palo 捐给 Apache，StarRocks 是原团队出来做的商业版分支，后来两家各自演进：StarRocks 在向量化、湖分析上更激进，Doris 生态和社区更开放。选型时按团队能拿到的支持来定。