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

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

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

Doris 导致 Zuul OOM 排查

Fri, 12 Dec 2025 00:00:00 +0000

引言

在开发者的潜意识里，LIMIT 关键字就是 SQL 查询的安全带。我们通常认为，只要加了 LIMIT，无论表多大，数据库都只会吐出少量数据，内存就是安全的。

然而，最近的一次线上 OOM（内存溢出）事故狠狠地打破了这个认知。一个看似人畜无害的 UNION ALL + LIMIT 组合，竟然避开了doris 的优化器的下推机制，引发了生产环境的连锁崩溃。

本文记录了这次在受限环境下，如何抽丝剥茧定位 Bug 的过程。

一、高峰期的“幽灵”崩溃

环境背景：

部署方式 Kubernetes
网关： Springboot + zuul
服务： Spring Boot + MyBatis
db： Apache Doris
报错服务： 网关
java版本： jdk8, g1
权限： 无root权限,只能查看基本日志

网关pod报错关键日志

netflix.zuul.exception.ZuulException: Filter threw Exception
postModifyResponseBodyFilter.run
...
Caused by: java.lang.OutOfMemoryError: Java heap space

报错日志关键字: oom

二、真相误判：GC 的烟雾弹

面对 OOM，作为 Java 开发者的第一直觉往往是：“是不是流量太大，垃圾回收（GC）跟不上了？” 查看存活期间的 JVM 监控，发现 Old Gen（老年代）增长迅速。当时的判断是：CMS 回收器产生内存碎片，导致大对象分配失败。

Doris on FXIO 技术博客

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

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

一、先说结论：它们根本不是同一类物种

二、架构基因对照

Doris 导致 Zuul OOM 排查

引言

一、高峰期的“幽灵”崩溃

二、 真相误判：GC 的烟雾弹

二、真相误判：GC 的烟雾弹