近期 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 方向演进。
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 中数据生命周期的执行职责。
随着现代 Lakehouse 的发展，执行引擎承担的数据操作已经不再局限于 SQL 查询，而是逐渐扩展到数据维护、事务管理、版本管理以及表优化等更多操作型（operation）工作负载。
围绕这些数据操作，不同系统选择了不同的演进路径。
一种路径（例如通过 ALTER TABLE EXECUTE 等 SQL 扩展）是将数据操作持续纳入 SQL 语法体系中。这种方式保持了 SQL 的一致性，但在表达复杂操作时会逐渐受到语义约束，并且容易随着数据操作不断丰富而演化为对 SQL 语义的过度扩展。
Presto 则选择了另一条路径：Distributed Procedure（分布式过程调用）。
CALL system.rewrite_data_files(...)
这一设计并不仅仅是接口形式上的区别，更体现了两层架构上的考虑。
诸如数据重写、文件合并、Snapshot 管理、Branch 管理等操作，本质上更接近一个具备执行流程和状态管理能力的任务（Job），而不是一次 SQL 查询。Procedure 模型能够更加自然地承载这类多阶段、长生命周期的数据操作，而无需不断扩展 SQL 查询语义。这一点在新兴场景中尤为重要，例如：
特征工程与训练数据集构建
embedding 数据刷新
离线数据重排与优化
多阶段数据处理流程
这些场景本质上更接近“任务（job）”，而不是“查询（query）”。
随着 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 执行平台进一步演化。
在执行层面，Presto 正在推进 Prestissimo（基于 Velox）的 Native C++ Execution 路线。
相比传统 JVM 执行模型，这一路线在理论上具备：
更高的性能上限（向量化 / SIMD）
更好的硬件适配能力（CPU / GPU）
更强的跨系统复用潜力（Velox 作为可插拔、可复用的高性能分析执行库）
当前，已有来自 GPU 生态的工程投入（例如围绕 cuDF 和 GPU-based exchange 的相关工作）持续出现在 Prestissimo / Velox 体系中，这表明查询引擎正逐渐成为探索异构计算的重要执行载体。此外，我们也观察到近期有厂商提交 RFC，尝试将新的 Native Execution Backend（bytedance/bolt）引入 Presto 作为一种可选的 Velox 之外的 Native Worker 实现。这体现出 Native C++ backend 方向正处于快速演进阶段，并在持续吸引多方工程投入。
需要强调的是，Native Execution 目前仍处于工程化推进阶段，其长期价值仍需通过大规模生产实践来验证。
但从长期来看，这代表了一种不同于纯 JVM 体系的演进方向，具备更高的天花板（尤其是在 CPU + GPU 异构计算环境中）。
随着 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 等协议）逐步演进的背景下，RAG（Retrieval-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 execution（Velox）在未来可承载更高性能的向量计算
从这一角度看，向量能力并非孤立特性，而是 Presto 向 AI Data Infrastructure 演进过程中，与执行模型与数据湖能力协同演进的一条关键路径。
综合上述变化，可以看到当前数据系统竞争格局正在呈现出一种“收敛与差异化并存”的结构：
在 SQL、Iceberg、优化器、物化视图等传统能力上，各主流系统之间正在快速收敛。
在以下关键方向上，不同系统开始出现分化：
数据操作范式（Procedure vs SQL 扩展）
执行引擎（Native vs JVM）
新型 workload（Vector / AI）
这些差异化不会立即改变系统竞争格局，但将逐步影响系统的长期演进空间。
在这样的竞争结构下，Presto 当前的演进路径体现出一种“非对称演进模式”：
在已有能力上快速收敛（SQL / Iceberg / Materialized View / Optimizer）
在关键方向上探索差异化路径（Native / Distributed Procedure / Transaction / Vector / AI）
这意味着：
短期内持续具备参与主流 Lakehouse 平台竞争的能力
中长期则在尝试争夺下一代数据基础设施中的关键技术制高点
如前所述，Presto 的这一系列演进，并不是简单地扩展传统查询引擎的能力边界，而是在完成一次面向新数据范式的迁移：
从 Hive 时代的数据访问层，走向 Lakehouse 时代的数据执行层，并在此基础上向 AI Data Infrastructure 方向演进。
技术系统的演进，很少通过一次发布完成，而是通过一系列方向一致的迭代逐步收敛。
最近两个版本所体现的，不只是功能特性的增加，而是：
一组相互关联的技术选择，正在逐步形成一个新的系统定位。
这一转型是否成功，最终仍取决于工程成熟度、生产验证以及用户采用情况。
但可以确定的是：
方向已经开始变得清晰，而接下来的关键，将是这些方向能否通过持续的工程化与生产实践，真正转化为系统性的优势。
本文基于作者当前的理解与实践经验整理而成，难免存在疏漏或值得进一步探讨之处。
如果您对文中的观点有不同看法，发现任何问题，或有相关实践经验，欢迎通过 GitHub Issue 与作者交流讨论。
期待与更多同行围绕数据基础设施相关技术展开交流，分享实践经验，共同学习、共同进步。