Presto 与 Doris 企业应用场景研究：一个「借灶炒菜」，一个「自建中央厨房」
同为 OLAP 赛道的明星项目，Presto 和 Doris 却代表了两种截然不同的企业数据架构路线。本文从真实企业场景出发，拆解两者的架构基因、适用边界与组合打法，给选型一个不模棱两可的答案。
一、先说结论：它们根本不是同一类物种
很多企业选型时的第一个错误，是把 Presto 和 Doris 放进同一张跑分表里比快慢。这就像拿「外卖平台」和「自建中央厨房」比出餐速度——它们解决的不是同一个问题。
一句话定性：
- Presto（含 Trino）是「查询引擎」：自己不存数据，靠 Connector 对接 Hive/S3/MySQL 等存储，强项是跨源联邦与即席分析。借灶炒菜，灶台是别人的。
- Doris 是「实时数仓」：自带存储引擎（列存 + 索引），数据要导进来，换来的是高并发、低延迟、可更新的全套数仓能力。自建中央厨房，从采购到出餐全包。
这个「存不存数据」的分野，决定了后面所有场景的适配差异。
二、架构基因对照
| 维度 | Presto/Trino | Apache Doris |
|---|---|---|
| 定位 | 联邦查询引擎（计算层） | MPP 实时分析型数据库（存算一体，3.0 起支持存算分离模式） |
| 数据形态 | 不存数据，Connector 现拉 | 数据导入自有存储（列存 + 排序键 + 倒排索引） |
| 执行模型 | 内存流水线，失败整体重跑 | MPP + Pipeline 向量化执行，支持落盘容错 |
| 写入能力 | 基本只读（INSERT 有限） | 支持实时更新（Unique Key）、流批一体导入（Kafka/Flink/Routine Load） |
| 并发能力 | 中低并发大查询 | 高并发短查询友好（数千 QPS 点查场景可扛） |
| 生态协议 | ANSI SQL + JDBC/BI 全兼容 | MySQL 协议兼容，BI 工具直连 |
| 运维形态 | 无状态计算集群 + 外部存储 | 有状态集群，3.0 存算分离模式后亦云原生化 |
注意 Doris 3.0 这个变量：它也支持了存算分离（数据放对象存储、计算节点弹性伸缩、缓存加速），还强化了湖仓一体能力（直接查 Hudi/Iceberg/Paimon）。也就是说，Doris 正在往 Presto 的领地伸手——但底色依然是「有存储、有索引、可更新」的数仓。
三、企业场景逐个拆
场景 1：跨源联邦查询 —— Presto 的主场
典型需求：数据散落在 Hive 数仓、MySQL 业务库、Kafka、S3 日志桶里，分析师要一条 SQL 把它们 JOIN 起来。
这是 Presto 的看家本领——为每种数据源装一个 Connector，查询计划里跨源 JOIN 是天然能力，数据不用搬家。企业里最贵的往往不是查询，而是为了查询把数据复制一遍的 ETL 管道，Presto 直接把这笔钱省了。
Doris 在这个场景的角色：它也支持外部 Catalog 查湖上数据，但跨源联邦的成熟度和连接器广度仍不如 Presto/Trino 生态。结论：联邦查询为主，Presto 优先。
场景 2：实时报表与大屏 —— Doris 的主场
典型需求：运营大屏秒级刷新、业务系统里嵌分析页面、成千上万用户同时点报表。
这类场景有三个 Presto 的致命点：高并发（Presto 的 Coordinator 调度为中等并发的大查询设计，扛不住数千 QPS）、低延迟稳定性（现拉远程数据，P99 延迟不稳）、面向应用的点查（按 ID 查明细，需要索引，Presto 没有）。
Doris 的解法是全套的：数据导入自有列存、倒排索引 + Bloom Filter 加速过滤、物化视图预聚合、MySQL 协议让应用直连——很多公司用它同时承载「实时数仓 + 报表服务 + 画像圈人」。结论：报表进生产系统、并发上千，选 Doris。
场景 3：日志分析 / ES 替代 —— Doris 的新战场
这是近两年国内企业落地 Doris 最猛的增量场景。ES 做日志检索的痛点很明确：存储成本随副本膨胀、聚合分析性能差、运维重。Doris 用倒排索引支撑全文检索 + 列存压缩（日志场景常见 5-10 倍压缩率）+ SQL 聚合分析，一套系统同时干「检索」和「分析」两件事。
Presto 在这个场景基本缺席——它不存数据，做不了「日志进来先落库再慢慢查」的事。结论：日志/可观测性场景，Doris（或 ClickHouse）的赛道，Presto 不参与。
场景 4：即席探索与数据科学 —— Presto 略优
分析师在 Jupyter/BI 工具里对 PB 级数据湖做开放式探索，查询模式完全不可预知。Presto 的优势是「不用提前建模」——数据躺在湖里就能查，不为未知查询做预建设。Doris 需要先把数据导入、设计好表模型才能发挥最佳性能，对「纯探索」多了一步前置成本。
但注意边界：如果探索的数据已经在 Doris 里，那直接用 Doris 即可。这个场景拼的不是引擎，是数据在哪。
场景 5：湖仓一体 —— 正在合流
两者都在往湖仓走：Presto/Trino 天然是「湖上查询层」；Doris 3.0 的多 Catalog 让它也能直接查 Iceberg/Hudi/Paimon。差异在取舍：
- Presto 查湖：零搬迁、零建模，但无索引加速，重查询慢；
- Doris 查湖：热数据可以物化进自有存储加速（湖仓加速层打法），冷数据原地查。
企业常见的务实组合：湖上全量数据用 Presto 兜底查询，高频访问的热表导入 Doris 建加速层——一个管广度，一个管性能。
四、选型决策：问自己四个问题
四个问题，依次回答：
- **数据要不要「搬进来」？**数据必须留在合规域/原地多引擎共享 → Presto；需要索引、更新、加速 → Doris。
- **查询是「人等结果」还是「应用等结果」？**分析师等大屏可以秒级 → 两者皆可；API 嵌业务系统、QPS 上千 → Doris。
- **有没有实时写入需求？**Kafka 流式进、分钟可见、行级更新 → Doris 的流批一体是标配能力，Presto 不是干这个的。
- **团队养得起几套系统？**Presto 无状态好养但依赖外部存储治理；Doris 有状态但单一系统覆盖场景多。小团队一个 Doris 往往比「Presto + 一堆存储组件」更省心。
五、组合拳：成年人的世界不做单选题
生产环境里最常见的不是二选一，而是分层：
| 层 | 职责 | 选型 |
|---|---|---|
| 数据湖（底座） | 全量明细、低成本存储 | HDFS/S3 + Iceberg/Hudi |
| 联邦层（广度） | 跨源 JOIN、长尾探索、兜底查询 | Presto/Trino |
| 加速层（性能） | 高频报表、实时大屏、API 服务 | Doris（从湖/ETL 导入热数据） |
| 加工层（生产） | 重 ETL、批流加工 | Spark/Flink |
一句话分工：**Presto 负责「任何数据都能查」，Doris 负责「关键查询查得快、扛得住」。**两者不冲突，冲突的是想把一个引擎用到所有场景的执念。
六、写在最后
Presto 和 Doris 的企业选型，本质上还是那道老题：你的数据在哪、谁在查、以什么频率查、能容忍多少延迟。
- 数据多源散落、以人的探索为主、不想搬数 → Presto/Trino；
- 数据需要统一管理、实时写入、高并发服务化 → Doris；
- 规模到了、场景杂了 → 分层组合，让每个引擎待在自己的甜蜜点。
引擎没有高下，位置才有对错。