OLAP

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