Presto 0.297 Release 解读：从查询引擎到下一代 Lakehouse 执行层

一次从数据访问范式到数据执行范式的系统性迁移近期 Presto 0.297 版本发布参见官方 Release Notes其中围绕多项关键能力的持续演进已经开始呈现出一系列值得关注的变化迹象。作为 Presto 0.297 release shepherd本文尝试从系统演进的角度对近两个 release 版本0.296–0.297的关键能力做一次系统性解读。说明本文仅代表作者基于公开版本、社区讨论以及近期演进所做的个人观察与技术分析并不代表 Presto 社区官方路线图或任何社区组织的观点。在过去几年中围绕数据湖与分布式 SQL 引擎的竞争格局发生了显著变化。从最早的 MPP 查询引擎到以 Iceberg / Delta / Hudi 为代表的开放表格式再到向量数据与 AI workload 的兴起数据基础设施正在经历一轮深层次的重构。在这样的背景下Presto 在最近两个发布版本0.296–0.297中的一系列演进开始呈现出一种内在清晰但尚未被完整表达的方向从 SQL 查询引擎 走向 Lakehouse 执行层Lakehouse Execution Layer并在此基础上开始向 AI Data Infrastructure 方向演进。一、从 Hive 时代的最优查询引擎到 Lakehouse 时代的执行层Presto 早期的发展是建立在以 Hive 为核心的数据湖体系之上的。在这一阶段数据通常以文件形式存储元数据由 Hive Metastore 管理整体呈现出“schema-on-read”和弱一致性语义。在这样的架构下Presto 的核心价值体现在高性能的分布式 SQL 查询跨数据源的联邦查询能力对 Hive 生态的深度适配也正因如此Presto 在这一阶段成为 Hive 生态中最重要的查询引擎之一。从今天的视角来看这一阶段在数据修改能力与一致性语义等方面仍存在一定局限但这更多是由当时的数据访问范式所决定的。然而随着 Iceberg 等现代湖仓表格式的出现数据湖的基本抽象发生了根本变化数据从“文件集合”转变为“具备事务语义的表”引入 snapshot、schema evolution、branch/tag 等机制数据管理从“外部操作”转向“系统内建能力”在这一变化下执行引擎的角色也随之改变不仅需要读取数据还需要参与数据修改、管理以及一致性保障。最近两个版本中Presto 在 Iceberg 上的一系列投入正是对这一变化的回应。与其说是在“补齐能力”不如说是从以 Hive 为中心的查询引擎逐步演进为面向现代 Lakehouse Table Format 的执行层。二、从“读取能力”到“数据生命周期参与者”最近两个 Release 中围绕 Iceberg 的一系列能力演进并非彼此孤立而是共同覆盖了现代 Lakehouse 数据生命周期的多个关键环节支持 Iceberg V3从文件级读写扩展到行级变更与 change tracking 能力完整支持 MERGE补齐关键语义能力引入标准 SQL 交互式单表多语句事务snapshot isolation支持版本与元数据管理能力branch / tag / metadata 操作提供数据维护与优化能力如 rewrite_data_files这些能力的组合使 Presto 从“数据查询引擎”转变为“可以参与数据生命周期的执行引擎”这不仅意味着功能边界的扩展更意味着 Presto 开始承担现代 Lakehouse 中数据生命周期的执行职责。三、数据操作范式的选择Procedure vs SQL 扩展随着现代 Lakehouse 的发展执行引擎承担的数据操作已经不再局限于 SQL 查询而是逐渐扩展到数据维护、事务管理、版本管理以及表优化等更多操作型operation工作负载。围绕这些数据操作不同系统选择了不同的演进路径。一种路径例如通过 ALTER TABLE EXECUTE 等 SQL 扩展是将数据操作持续纳入 SQL 语法体系中。这种方式保持了 SQL 的一致性但在表达复杂操作时会逐渐受到语义约束并且容易随着数据操作不断丰富而演化为对 SQL 语义的过度扩展。Presto 则选择了另一条路径Distributed Procedure分布式过程调用。CALLsystem.rewrite_data_files(...)这一设计并不仅仅是接口形式上的区别更体现了两层架构上的考虑。将 数据操作Operation与 查询语义Query解耦诸如数据重写、文件合并、Snapshot 管理、Branch 管理等操作本质上更接近一个具备执行流程和状态管理能力的任务Job而不是一次 SQL 查询。Procedure 模型能够更加自然地承载这类多阶段、长生命周期的数据操作而无需不断扩展 SQL 查询语义。这一点在新兴场景中尤为重要例如特征工程与训练数据集构建embedding 数据刷新离线数据重排与优化多阶段数据处理流程这些场景本质上更接近“任务job”而不是“查询query”。维护 Engine 与 Connector 的职责边界随着 Iceberg、Delta、Hudi、Lance 等不同 Lakehouse Table Format 持续演进各 Connector 开始不断提供自身特有的数据管理能力。这些能力往往具有明显的 Connector-specific 语义并不天然具备跨 Connector 的统一抽象。如果持续通过 Engine 层 SQL 扩展来承载这些能力那么 SQL 将不得不不断吸收各 Connector 特有的语义与参数不仅增加 SQL 抽象本身的复杂度也容易模糊 Engine 与 Connector 之间的职责边界。相比之下Distributed Procedure 提供了一种更加自然的扩展模型Engine 提供统一的执行框架而各 Connector 则能够以 Procedure 的形式独立暴露自身的数据管理能力而无需首先将这些能力抽象为通用 SQL 语义。从这一角度来看Procedure 并不仅仅是一种调用接口更体现了一种更加符合 Lakehouse 演进方向的扩展方式Query 负责数据访问Procedure 负责复杂流程编排和特殊操作语义Engine 提供统一执行框架而 Connector 负责持续扩展各自的数据能力。四、事务能力从争议到现实需求关于查询引擎是否应该承担事务协调职责在不同的社区中一直存在不同的观点。一种观点强调查询引擎应尽量保持 stateless 和 query-oriented不应承担事务协调职责另一种观点则认为在数据湖场景下写操作与一致性已经成为核心需求执行引擎需要具备适当范围内的事务语义。在围绕交互式多语句事务的支持范围和语义边界长期缺乏清晰工程化定义与可行落地路径的背景下Presto 在 Iceberg 上实现了标准 SQL 语义下的交互式单表多语句事务明确了其工程化边界并提供了可落地的实现路径这实际上是对后者的回应。这一选择的意义不仅在于“实现事务本身”这一过程涉及复杂的事务语义建模、能力边界界定以及与既有执行体系的兼容性取舍更在于使执行引擎具备更加完整的数据修改与一致性管理能力从而能够参与更广泛的数据工作流开始进入数据生命周期的核心路径。随着数据湖逐渐承载更多生产数据这一能力的需求正在变得越来越现实。五、物化视图与优化器体系从执行优化到系统级决策能力除了数据操作能力Presto 在优化器与物化视图Materialized View方面的持续投入也体现出另一条重要主线predicate stitching查询谓词缝合incremental refresh增量更新cost-based rewrite多 MV 选择staleness 控制数据新鲜度管理这些能力分别作用于查询改写、物化视图维护与执行路径选择等不同层面并在组合之后使系统具备从多个候选执行方案中自动选择最优路径的能力。其目标是将系统从“更高效地执行用户给定的 SQL”演进为“自动选择更优执行路径”这代表着从传统执行引擎向具备系统级决策能力的 Lakehouse 执行平台进一步演化。六、执行引擎的长期演进JVM 与 Native 的分叉与并行在执行层面Presto 正在推进 Prestissimo基于 Velox的 Native C Execution 路线。相比传统 JVM 执行模型这一路线在理论上具备更高的性能上限向量化 / SIMD更好的硬件适配能力CPU / GPU更强的跨系统复用潜力Velox 作为可插拔、可复用的高性能分析执行库当前已有来自 GPU 生态的工程投入例如围绕 cuDF 和 GPU-based exchange 的相关工作持续出现在 Prestissimo / Velox 体系中这表明查询引擎正逐渐成为探索异构计算的重要执行载体。此外我们也观察到近期有厂商提交 RFC尝试将新的 Native Execution Backendbytedance/bolt引入 Presto 作为一种可选的 Velox 之外的 Native Worker 实现。这体现出 Native C backend 方向正处于快速演进阶段并在持续吸引多方工程投入。需要强调的是Native Execution 目前仍处于工程化推进阶段其长期价值仍需通过大规模生产实践来验证。但从长期来看这代表了一种不同于纯 JVM 体系的演进方向具备更高的天花板尤其是在 CPU GPU 异构计算环境中。七、面向 AI Workload 的探索Vector 与新型数据形态随着 AI workload 的兴起数据系统正在引入一类新的核心数据形态向量vector例如 embedding 表示。与传统结构化数据不同这类数据的典型操作不再局限于 filter / join / aggregation而是包括相似度搜索similarity search近似最近邻ANN, Approximate Nearest Neighbor向量索引的构建与更新在这一方向上Presto 在最新版本中开始进行初步探索支持向量索引vector index的内置创建与使用正在推进向量检索能力vector search的执行支持引入 LanceDB connector用于访问面向向量数据优化的存储系统这些能力目前仍处于早期阶段但其意义在于Presto 开始从传统关系型分析场景扩展为能够处理包括 vector data 在内的新型数据访问与计算模式的执行系统。进一步来看在向量检索能力、数据湖实时数据访问能力以及对外部 AI 应用接口和 Agent 工作流的潜在集成能力例如 MCP 等协议逐步演进的背景下RAGRetrieval-Augmented Generation这一当前主流的数据访问与推理模式正在出现新的实现路径。通过单条查询在执行引擎内部完成“向量召回 实时数据融合 推理输入构建”的一体化流程将原本分散在多个系统中的 RAG 执行路径收敛为统一的执行计划。在这一模式下向量检索通过 table function 融入查询计划数据湖表格式提供实时数据与一致性保障执行引擎负责多源数据融合与结果构建相比传统依赖多系统协同的方案这一路径将核心数据访问与结果构建尽可能收敛到执行层内部从而在延迟、数据新鲜度以及执行优化等方面具备潜在优势。需要指出的是在当前实现中向量索引的声明、构建与刷新主要通过 SQL 扩展语法来表达类似于 BigQuery 等系统的设计而并未直接采用 Procedure 执行模型。从设计上看这一选择具有其合理性向量索引本质上仍属于表数据结构的一部分使用声明式 SQL 进行定义更符合其“结构描述”的语义。但从更广义的 AI workload 视角来看Procedure 执行模型则更适合承载另一类任务这些场景如数据预处理、embedding 刷新、多阶段数据处理等本质上更接近“任务job”或“pipeline”而非单次查询。因此可以将两者理解为不同层次的分工SQL 扩展更适合表达“声明式的数据结构与索引定义”Procedure 更适合承载“过程化的数据处理与任务编排”从系统分层的角度看Presto 在 AI workflow 中将会主要处于数据准备层与控制面control plane用于支撑数据处理与流程编排而模型的推理与训练本身仍属于 AI 计算执行面execution plane通常由专用的模型推理与训练框架负责。因此Presto 当前并非试图用单一范式统一所有能力而是逐步形成一种“声明式SQL与过程化Procedure并存”的体系结构以适配不同类型的数据与计算需求。进一步来看这一方向也与前文提到的其他能力形成潜在协同Iceberg/LanceDB 等表格式可管理 embedding 数据及模型训练数据集的生命周期Procedure 可用于组织数据准备与处理流程Native executionVelox在未来可承载更高性能的向量计算从这一角度看向量能力并非孤立特性而是 Presto 向 AI Data Infrastructure 演进过程中与执行模型与数据湖能力协同演进的一条关键路径。八、竞争格局能力收敛与差异化演进综合上述变化可以看到当前数据系统竞争格局正在呈现出一种“收敛与差异化并存”的结构→ 短期能力收敛在 SQL、Iceberg、优化器、物化视图等传统能力上各主流系统之间正在快速收敛。→ 中长期路径差异化在以下关键方向上不同系统开始出现分化数据操作范式Procedure vs SQL 扩展执行引擎Native vs JVM新型 workloadVector / AI这些差异化不会立即改变系统竞争格局但将逐步影响系统的长期演进空间。在这样的竞争结构下Presto 当前的演进路径体现出一种“非对称演进模式”在已有能力上快速收敛SQL / Iceberg / Materialized View / Optimizer在关键方向上探索差异化路径Native / Distributed Procedure / Transaction / Vector / AI这意味着短期内持续具备参与主流 Lakehouse 平台竞争的能力中长期则在尝试争夺下一代数据基础设施中的关键技术制高点九、结语如前所述Presto 的这一系列演进并不是简单地扩展传统查询引擎的能力边界而是在完成一次面向新数据范式的迁移从 Hive 时代的数据访问层走向 Lakehouse 时代的数据执行层并在此基础上向 AI Data Infrastructure 方向演进。技术系统的演进很少通过一次发布完成而是通过一系列方向一致的迭代逐步收敛。最近两个版本所体现的不只是功能特性的增加而是一组相互关联的技术选择正在逐步形成一个新的系统定位。这一转型是否成功最终仍取决于工程成熟度、生产验证以及用户采用情况。但可以确定的是方向已经开始变得清晰而接下来的关键将是这些方向能否通过持续的工程化与生产实践真正转化为系统性的优势。作者王冬PrestoDB Committer | Presto Iceberg Code Owner | Presto 0.297 Release ShepherdGitHub: https://github.com/hantangwangdEmail : mingwbdgmail.com欢迎就相关技术问题与实践经验进行交流与探讨参考资料https://prestodb.io/docs/current/release/release-0.297.htmlhttps://prestodb.io/docs/current/release/release-0.296.htmlGithub Pages本文也同步发布于https://hantangwangd.github.io/zh/posts/2026-04-15-release0.297-deep-dive.html