Presto 与 Doris 企业应用场景研究：一个「借灶炒菜」，一个「自建中央厨房」

Tue, 04 Aug 2026 19:30:15 +0800

同为 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 的领地伸手——但底色依然是「有存储、有索引、可更新」的数仓。