汪湜如果你的业务库已经从几十 GB 涨到了几百 GB，报表平台拉一次数据要等半分钟，BI 页面偶尔还会因为一个慢查询把线上 MySQL 拖到 CPU 打满——那你大概率已经在网上反复比较过 Doris、ClickHouse、StarRocks 到底应该选哪一个。我这套选型落地过程打算分两篇来写，本文是第一篇，只讲前半截：为什么最终选了 Apache Doris + Apache Superset 这套开源组合，以及如何用最低的硬件成本，把实时数仓和可视化层完整串联起来。
这篇内容偏实战，适合正在做数据平台选型、又要自己动手搭建报表系统的同学参考。第二篇会专门讲 Doris 查询优化、物化视图、权限隔离，以及 Superset 企业级图表和大屏的深度配置。
1. 这套组合解决的是“BI 慢”还是“数仓重”的问题
1.1 传统方案的三类典型痛点
先说我遇到的实际场景。业务底层是 MySQL，订单表、支付流水表单表过亿，多表关联时 MySQL 的索引优势基本失效。当时报表组最常干的事情是从 MySQL 拉全量数据到 Excel，或者在 BI 工具里直连 MySQL 跑大查询。数据库 DBA 几乎每周都要处理一次慢查询告警。
传统方案通常有三类解法，但各有各的难受：
- 直连 MySQL：简单，但不敢上复杂查询，报表并发稍高就把业务库拖垮；
- 离线数仓：用 Hive + Spark 做 T+1，开发链路长、组件多，一个人运维不过来；
- 商业 BI + 独立数仓一体机：好用，但 License 费用对小团队来说非常劝退。
这个阶段的核心矛盾不是“不会写 SQL”，而是缺少一个“能扛住查询压力的中间层”。数据量到了百 GB 级，MySQL 的查询计算和存储引擎已经不太适合做分析负载了。
1.2 为什么不是 ClickHouse，而是 Doris
很多人第一反应是 ClickHouse，我也在选型时认真测过。ClickHouse 的列式存储和向量化执行确实快，但它在“实时更新”这个场景上有天然短板：虽然 24.x 版本开始有 ReplacingMergeTree 轻量删除和更新，但合并行为是异步的，你很难保证刚写入主键覆盖后立刻查到的是新值，而且高频更新会造成后台 merge 压力，需要投入额外精力做分区裁剪和合并调优。
Apache Doris 在我这个场景里更顺手，核心原因有三点：
第一，Doris 原生支持 Unique Key 模型，写入时按主键自动去重，读时返回最新版本，实时覆盖更新是开箱即用的能力；第二，Routine Load 能直接消费 Kafka，不需要额外部署一套 Stream 处理框架，链路短、组件少；第三，Doris 兼容 MySQL 协议，团队迁移成本低，什么 join、group by、窗口函数都能直接跑。
| 对比项 | Apache Doris | ClickHouse | 直连 MySQL |
|---|---|---|---|
| 实时 Upsert | 原生 Unique Key | 需依赖 ReplacingMergeTree 异步合并 | 天然支持但扛不住分析查询 |
| 实时链路 | 内建 Routine Load 直接消费 Kafka | 需自建 Kafka Engine 或用第三方同步组件 | 无 |
| MySQL 协议兼容 | 兼容，应用迁移成本低 | 不兼容，需要专用客户端 | 本身就是 MySQL |
| 运维复杂度 | FE + BE 两个角色 | ClickHouse 集群 + ZK（或 ClickHouse Keeper） | 最低 |
| 扩展成本 | 加 BE 节点即可水平扩展 | 需要手工处理分片权重 | 分库分表困难 |
1.3 什么场景不适合这套组合
Doris + Superset 不是银弹。如果你要做的是全文检索，Doris 的倒排索引虽然新版在增强，但和 Elasticsearch 比仍有差距；如果你需要事务型 OLTP，Doris 完全没有事务和行级锁能力；如果只是给老板看周报月报，T+1 就够，那直接做成定时快照更省心。
这套组合真正擅长的是：大量明细数据、持续写入、需要秒级可见、要求报表查询并发稳定的在线分析场景。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 容量规划与数据链路：先想清楚再动手
2.1 整体数据流设计
部署之前先把技术选型确认掉，第一条链路就是：
业务库 MySQL → Canal 监听 Binlog 解析变更 → 写入 Kafka Topic → Doris 通过 Routine Load 消费 Kafka → Superset 连接 Doris 做图表展示
为什么不用 Flink CDC？因为这套平台的第一诉求是“低开销”。Cana