从 Hive 到 Presto：一个「快」字背后，是三次豪赌式的设计取舍

Tue, 04 Aug 2026 12:14:32 +0800

从 Hive 到 Presto：一个「快」字背后，是三次豪赌式的设计取舍

2012 年，Facebook 的工程师们受够了「跑个查询去喝杯咖啡」的日子。Presto 的诞生不是又一个 SQL 引擎的堆料，而是一连串清醒的放弃。本文用「舍与得」的视角，拆开 Presto 三项核心架构决策——以及它们各自的账单。

引言：大数据时代的「等待焦虑」

先讲一个老故事。

2012 年前后，任何在 Facebook 规模的数据仓库上工作过的人，都熟悉这种体验：你写了一段 SQL，想看看昨天某个功能的用户留存。提交给 Hive，底层翻译成 MapReduce，然后——

等。

第一个 Map 阶段读数据、算完、写磁盘；第二个 Reduce 阶段再读磁盘、算完、再写磁盘；三五个阶段下来，一个「简单的问题」要等十分钟到一小时。磁盘 I/O 像一道钝刀子，把「交互式分析」切成了「批处理作业」。工程师们甚至形成了独特的应对文化：提交查询，然后去开会、喝咖啡、改别的 bug——因为等待是确定会发生的。

问题出在哪？不是 Hadoop 不行，而是 MapReduce 的设计目标本来就不是交互式查询。它为容错而生：每个阶段的中间结果必须落盘，任何一台机器挂了，从磁盘上的中间结果重跑就行。这份「保险」在批处理场景物有所值，但对「我想马上知道答案」的分析师来说，是在为用不到的容错付全价。

Presto 的研发初衷就一句话：为交互式 SQL 查询专门造一台引擎，PB 级数据，秒级响应。

注意「专门」这个词。Presto 没有试图做一个「又能批处理、又能交互、又能点查」的全能选手——它从一开始就决定，为了快，该扔的就扔。下面是三次关键的「舍」。

取舍一：内存流水线——扔掉容错，换速度

舍：Task 级中间落盘与断点重试

MapReduce 的哲学是「每一步都存档」。Presto 反其道而行：查询被切成多个 Stage，Stage 内的算子组成流水线（Pipeline），数据以「页」（Page）为单位在算子间流动，全程驻留内存，中间结果不落盘。

伪代码对比一下两种执行模型：

# MapReduce 式：每个阶段落盘存档
for stage in stages:
 results = stage.run(input)
 write_to_disk(results) # ← 每一步都付磁盘 I/O 的钱
 checkpoint(results) # ← 为容错买单
# 下一阶段再 read_from_disk()

# Presto 式：内存流水线
pipeline = build_pipeline(scan, filter, agg, ...)
for page in source_pages: # 一页一页流过去
 yield pipeline.process(page) # 算子间直接传递，不落地

差别有多直观？MapReduce 的一次「阶段交接」= 一次序列化 + 一次磁盘写 + 一次磁盘读 + 一次反序列化。Presto 的阶段交接 = 一次内存中的数据页传递。磁盘 I/O 从执行路径里被整个删掉了，这正是秒级响应的物理基础。

存算分离 on FXIO 技术博客

从 Hive 到 Presto：一个「快」字背后，是三次豪赌式的设计取舍

从 Hive 到 Presto：一个「快」字背后，是三次豪赌式的设计取舍

引言：大数据时代的「等待焦虑」

取舍一：内存流水线——扔掉容错，换速度

舍：Task 级中间落盘与断点重试