从 Data Access 到 Capability Provider关于联邦查询引擎演进的一些思考引言长期以来业界对联邦查询引擎Federated Query Engine的认知大多停留在一个经典定义上“统一访问多个异构数据源的分布式 SQL 查询层”。无论是 PrestoDB、Trino还是早期联邦数据库系统其核心价值通常被概括为如下几点统一 SQL 接口屏蔽不同系统之间的数据访问差异统一元数据视图多数据源连接能力将分散在不同系统中的数据组织为统一的逻辑空间统一计算层在查询引擎中完成跨系统计算在这样的定位下Connector 层的职责也被自然界定为Storage Adapter Layer即Schema MappingData AccessPredicate PushdownSplit Enumeration本质上Connector 更多承担的是一个面向异构数据源的数据访问适配层Data Access Adapter的角色。然而现代数据基础设施的演进正在悄然改变这一格局。Lakehouse 表格式、AI Native 数据格式、向量数据库、分布式缓存系统、特征平台与数据编排系统等等这些技术方向正逐渐成为数据平台的核心组件。它们带来的不仅仅是新的数据来源更是新的语义、新的能力和新的优化机会。最近在阅读代码、Review PR并参与 Presto 生态中 Iceberg、Lance 等 Connector 的开发过程中我逐渐注意到一个有意思的现象Connector 的职责似乎正在发生一些值得关注的变化。Connector 正在变得越来越厚。其正在从传统的数据访问适配层逐渐演化为能力提供层Capability Provider LayerFederated Query Engine 也开始具备越来越强的能力聚合与编排能力并逐渐承担起一种本文暂且称其为能力聚合层(Capability Aggregation Layer) 的角色。这不是对原有架构的否定而是对其职责的自然延伸。接下来我们将从 PrestoDB 的视角出发梳理这一演化的技术背景、已有基础与未来可能的方向。声明本文并非试图定义或限定 Federated Query Engine 的演进方向也不代表任何社区或项目的官方立场而只是记录自己在参与相关项目过程中形成的一些观察与思考。一、从传统定位到新背景下的挑战Federated Engine 的能力边界正在扩展1.1 传统定位统一访问异构数据的 SQL 层传统联邦查询系统的核心目标可以归结为一个简单的问题如何在统一 SQL 语义下高效查询多个异构数据源围绕这一目标Connector 的职责通常包括如何获取 metadata如何读写数据如何下推 predicate 和 projection由此衍生出的典型能力包括Predicate PushdownProjection PushdownPartition PruningSplit Generation这些能力虽然重要但本质上仍然归属于同一个范畴Access Semantics——即如何访问数据。在这一阶段Connector 的价值主要体现在连接与适配它屏蔽了底层数据源的差异向上层呈现统一的关系型视图。至于这些数据源本身是否具备更丰富的语义或能力并不在传统联邦引擎的关注范围内。1.2 根本变化Lakehouse 与 AI Data Infra 带来的新语义然而近年来数据系统和表格式的能力边界正在显著扩展。以 Apache Iceberg 为代表的 Lakehouse 表格式使得数据管理层开始具备越来越丰富的语义Snapshot SemanticsTransaction SemanticsMetadata GraphPartition EvolutionDelete SemanticsFine-grained Metadata Indexing与此同时AI Data Infra 的兴起又引入了全新的数据形态与访问模式EmbeddingVector IndexANN RetrievalAI Dataset ManagementMultimodal Metadata图像、视频、音频等这些变化共同反映出一个趋势Connector 所面对的已经不再只是文件或表而是具备丰富语义的数据系统与数据格式。1.3 正在发生的演进当 Connector 开始超越传统边界从我观察到的一些实践来看联邦查询引擎的职责似乎也正在随之演进。它不再仅仅满足于读取某个 Iceberg、Hive 或 Lance 表而是开始利用 Snapshot 进行增量计算利用 Metadata 进行查询优化利用 Partition Evolution 实现透明演化利用表级语义进行 Materialized View 的改写与维护利用 Vector Index 进行 AI-native 检索这意味着Connector 已经开始向 Query Planner / Optimizer / Execution 暴露越来越多的能力。其角色已经超出了传统意义上的 Data Access Adapter。当越来越多的数据系统能力通过 Connector 暴露给 Query Planner、Optimizer 与 Execution 层时Federated Query Engine 所能够利用和编排的能力边界也随之扩展。它开始不仅负责统一访问数据也开始承担不同数据系统能力的协调、聚合与利用——这也正是本文后续章节希望深入探讨的核心方向。二、从 Data Access 到 CapabilityConnector 的新角色在 Presto 的现有生态中我们已经能够观察到若干 Connectors 开始展现出超越传统数据访问适配边界的能力。它们不再单纯地向引擎暴露查询访问的基础能力而是开始向整个系统提供其底层数据系统或存储格式所特有的执行语义与优化机会。尤为关键的是其中一部分能力具备泛化的可能性。当然并非所有 Connector 特性都具备泛化价值。只有那些对多种数据源具有普遍意义、能够在抽象层面被统一表达和复用的高级执行语义才真正值得也具备被泛化的条件。一旦此类能力由某个 Connector 提供Presto 生态中所有 Connectors 所管理的数据与系统都将有可能共享这一能力。以 Alluxio、Iceberg、Lance 为例这三个 Connector 分别代表了三种不同方向的 Capability Provider。2.1 Alluxio缓存能力的泛化Alluxio 的传统定位是分布式缓存层Distributed Cache Layer。但从 Federated Engine 的视角来看它提供的并不仅仅是某个存储系统的缓存加速而是一组可以被查询执行层直接利用的基础设施能力Data LocalityDistributed CacheRemote IO Acceleration这些能力本质上解决的是如何更加高效地访问远端数据。因此它们并不依赖具体的数据格式或者数据源。无论底层数据来自HiveIcebergPostgreSQLObject Storage只要查询通过 Federated Engine 执行都可以受益于 Alluxio 提供的缓存与数据局部性能力。这些能力的意义已经超越了为某个特定存储系统提供缓存的范畴而是演变为“整个查询执行层的 IO 能力增强”。换言之Alluxio Connector 将分布式缓存作为一种可泛化的系统能力附加在任何后端数据源之上。2.2 IcebergData Management Capability 高阶语义的泛化Apache Iceberg 已经不再仅仅是一个开放表格式Open Table Format。随着现代 Lakehouse 架构的发展以 Iceberg 为代表的数据表格式逐渐具备更加丰富的数据管理语义Snapshot-based SemanticsTransaction SemanticsMetadata GraphPartition EvolutionDelete SemanticsFine-grained Metadata Indexing这些语义的价值已不再局限于数据读取层面而是开始扩展到查询规划Query Planning增量计算Incremental Computation数据维护Data Maintenance表演进管理Table Evolution Management数据一致性管理Consistency Management换句话说Iceberg 提供的不只是Access to Table Data而是Access to Data Management Semantics例如在 Materialized View 场景中Iceberg 所提供的价值并不仅仅是存储物化视图结果而是作为 Materialized View 的统一状态管理层State Management Layer为物化视图维护提供了一组关键的数据管理语义Snapshot 与 Metadata 提供版本化的视图状态管理能力Schema Evolution 与 Partition Evolution 提供透明的数据演化能力Atomic Commit 与 Snapshot Isolation 提供一致性的刷新发布语义Fine-grained Metadata Indexing 提供高效的查询访问能力这些能力共同解决了 Materialized View 最核心的一系列问题如何维护视图状态的一致性与可见性如何尽可能的利用变化数据的信息以较低代价维护视图最新状态如何支持视图数据的持续演化与长期维护如何提供面向查询优化的高效访问路径因此Presto 不再需要依赖底层数据源自身提供 Materialized View 能力而是可以利用 Iceberg 作为统一的 Materialized View 状态管理层上游数据可以来自 Hive、PostgreSQL、MySQL 或对象存储Materialized View 的实际数据、版本状态以及生命周期管理统一由 Iceberg 承担增量刷新、查询改写以及 Predicate Stitching 等高级优化能力则由 Presto Federated Engine 统一提供这些能力的本质在于Iceberg Connector 具备了为整个 Presto Federation 提供统一 Materialized View 状态管理能力的基础而 Presto Engine 则负责将这一能力进一步扩展为跨 Connector 的高级物化视图语义。无论底层数据来自 Hive、PostgreSQL 还是对象存储只要通过 Presto 进行查询都有可能共享这一能力所带来的优化收益。2.3 LanceAI Workload 高阶语义的泛化Lance 代表了 AI Data Infra 方向的新范式。Lance 提供的不只是列式存储Columnar Storage更包括Vector IndexANN RetrievalEmbedding-aware AccessAI Dataset Management多模态数据原生存储基于这些能力Lance Connector 正在展现出另一个重要的泛化方向为整个 Presto 生态中的 AI Workload 提供统一的高阶语义支持。具体而言Lance Connector 具备了向整个 Federated Engine 提供以下几类 AI-native Capability向量存储与检索能力无论原始数据来自哪个 Connector都可以通过 Lance 构建和维护统一的向量存储、向量索引以及 ANN 检索能力AI 数据集管理能力训练集、验证集、特征工程中间结果以及采样数据都可以作为版本化的物化资产统一维护多模态数据组织能力来自文本、图像、音频以及视频等不同模态的数据可以被统一管理、索引与检索例如在 AI Retrieval 场景中原始数据可以来自 Hive、Iceberg、PostgreSQL 或对象存储Embedding 与 Vector Index 则统一由 Lance 管理向量检索、ANN Search 以及 Retrieval Planning则由 Presto Federated Engine 统一编排与执行这些能力的本质在于Lance Connector 不再只是向 Federated Engine 暴露数据访问接口而是开始向整个 Presto Federation 提供统一的 AI Retrieval 与 AI Dataset Management 能力。原始数据的管理仍然由各 Source Connector 负责而 Embedding、Vector Index 以及 AI Dataset State 则由 Lance 统一维护。Presto Engine 则负责将这些能力进一步组合与编排最终形成跨 Connector 的 AI Workload 高阶语义。后续章节我们会进一步看到诸如 Distributed Procedure 与 Table Function 等机制正在使这些能力逐渐成为 Federated Execution Graph 中的一等公民。这三种泛化方向分别作用于查询执行的不同层次Alluxio 增强的是 IO 基础设施层Iceberg 拓展的是数据语义管理层而 Lance 则面向 AI 工作负载层。三者互不重叠、互为补充共同勾勒出 Federated Engine 能力演进的完整图景。它们共同指向一个明确的趋势在 Lakehouse 与 AI Data Infra 持续深化的背景下Connector 作为能力提供者的角色将变得越来越突出也越来越不可替代。Connector 不再仅仅是适配不同数据源的访问协议而是开始成为整个 Presto 生态中高级执行语义的载体与放大器。从这个意义上讲Federated Engine 所联邦的对象也正在从单纯的 Data Source 本身逐渐扩展到 Data Capability。三、Presto 近期实践中的一些演化迹象上述关于 Capability Federation 的讨论并不仅仅来源于理论推演。事实上PrestoDB 近年来的一系列架构演化也能够为这一思路提供一些有趣的实践参考。在我看来以下几个方向的发展共同体现出一个值得关注的趋势Distributed ProcedureTable FunctionConnector OptimizerPredicate StitchingIncremental MV RefreshMetadata-aware Rewrite这些能力共同反映出一种变化Connector 已经不仅仅只是回答如何读取数据而是开始定义如何向整个 Federated Engine 暴露自身的 specialized capability。3.1 Distributed Procedure能力暴露的天然接口Distributed Procedure 的意义并不仅仅是支持分布式 Procedure 调用。更重要的是它开始允许 Connector 以一种语义更加简洁、更加自然的方式向整个 Federated Engine 暴露自身特有能力。传统 Connector API 更多描述How to access data而 Distributed Procedure 可以更自然的表达What operations this connector can provide未来Connector 或许可以更加自然地通过 Distributed Procedure 暴露自身能力例如Connector可暴露的能力Iceberg ConnectorMV Refresh、Metadata Optimization、Data Optimization、Snapshot MaintenanceLance ConnectorVector Index Build、Embedding Materialization、ANN MaintenanceAlluxio ConnectorCache Warmup、Cache Cleanup、Locality Optimization这意味着 Connector 的能力不再隐藏在内部实现中而是可以被引擎统一调用。在这一视角下Federated Engine 正逐渐从 Unified Query Engine 演化为 Unified Capability Execution Platform。3.2 Table FunctionSpecialized Retrieval 进入统一执行计划Table Function 的价值也远不止于SQL 扩展语法。其真正重要的地方在于它允许非传统关系操作以一种自然方式进入统一 Query Plan。过去特殊计算通常位于 SQL 引擎之外。例如向量搜索服务推荐系统特征检索系统而 Table Function 使这些能力能够进入 Federated Execution Graph例如Vector RetrievalANN SearchEmbedding Retrieval未来可以参与优化参与 Join Planning参与 Predicate Pushdown参与统一调度执行这意味着AI-native Retrieval 正在真正成为 Federated Execution Graph 的一等公民而不再是一个独立于 SQL 引擎之外的附加组件。3.3 Connector Optimizer优化能力的联邦化传统 Query Engine 中Optimizer 通常属于 Centralized Engine Intelligence——优化逻辑集中在引擎核心由它来理解所有数据源的特性。然而随着数据格式及数据系统能力不断增强Iceberg MetadataVector IndexCache LocalityAI-native SemanticsEngine Core 已经越来越难完全理解所有底层系统特性。如果 Capability Provider 能够定义自身能力却无法参与能力选择与执行路径决策那么 Federated Capability 将无法真正实现最优组合。Connector Optimizer 或许正是这一趋势在 Optimizer 层面的体现。Connector Optimizer 的核心价值在于将 Specialized System 的 Optimization Intelligence 引入统一 Optimizer。也就是说未来的 Optimizer 可能会越来越像 Federated Optimization Intelligence而不再只是 Single-engine Optimizer。每个 Connector 都可以贡献自己对底层数据系统最优访问路径的理解由联邦优化器统一协调与决策。3.4 Materialized ViewCapability Federation 的典型实例Presto 在 Materialized View 能力上的演化已经具体体现了 Capability Federation 的典型特征。传统数据库中Materialized View 通常是存储系统内部能力其依赖于MV Metadata ManagementRefresh strategyQuery RewriteOptimization这些能力往往紧耦合于单一数据源系统难以跨系统复用。但在 Presto 的近期演进中基于 Federated Capability Composition分工正在发生变化组件提供的能力Apache IcebergMV State Management、MV storage Management、Atomic PublicationSource ConnectorsBase Table Access、Change Awareness、Incremental Read SemanticsPrestoPredicate Stitching、Incremental Refresh Algorithm、CBO-based Rewrite Selection、Federated Query Planning于是Materialized View 不再属于单一系统而成为多个组件能力组合后的结果。查询阶段Presto 基于 CBO 自动选择执行路径全表查询MV RewritePredicate Stitching并结合实时查询条件动态调整执行计划。刷新阶段Iceberg 作为 Materialized View 的状态管理基础设施提供Snapshot MetadataMetadata GraphAtomic CommitSnapshot IsolationPresto 则负责Change Detection借助 Source Connectors 的增量感知能力Incremental Refresh PlanningRefresh Execution两者结合共同实现Incremental RefreshFine-grained MaintenanceConsistent View Publication最终形成的是一种面向整个 Presto Federation 的、泛化的、更细粒度控制的 Materialized View 能力。核心启示这一案例的真正重要之处在于MV 能力已经不再紧耦合于单一存储系统而开始成为 Federated Engine Specialized Metadata System 共同组合出的平台能力。沿着这一思路来看Federated Engine 所联邦的对象似乎已经开始从 Data Source 本身逐渐扩展到 Data Capability。四、一个更加直观的例子迁移能力而非迁移数据为了更直观地理解 Capability Federation 的价值不妨考虑一个典型的企业数据平台演进场景。4.1 初始状态能力孤立的异构系统企业内部通常已经存在大量异构数据系统Hive 数据湖PostgreSQL 业务数据库Oracle 数仓对象存储中的 Parquet 数据集这些系统往往长期稳定运行并承担着各自明确的职责。然而在传统模式下这些系统彼此之间处于能力隔离、元数据隔离、查询能力隔离的状态。每个系统只能提供自身固有的能力跨系统的能力复用几乎不存在。如果企业希望进一步获得分布式缓存加速物化视图维护与自动查询改写向量检索能力AI Dataset 管理能力通常意味着数据迁移、平台重建以及业务改造。不仅成本高昂而且建设周期长、业务风险高。4.2 新的模式能力附着数据不动在 Federated Engine Capability Provider 的架构中可以呈现出一种不同的数据平台演进方式。企业无需迁移现有业务数据而可以通过逐步引入新的 Capability Provider便能够让现有数据逐渐附着上新的能力。第一步引入统一 Federated Engine首先引入统一的 Federated Engine例如 PrestoDB作为整个企业的数据访问与执行层。此时Hive 仍然是 HivePostgreSQL 仍然是 PostgreSQLOracle 仍然是 Oracle原有系统的职责、边界以及运行模式均无需改变。变化的仅仅是企业开始拥有一个统一的 Federated Engine 作为整个企业数据的联邦查询层及数据能力的组合层Capability Composition Layer。第二步引入 Alluxio —— 获得统一的 IO 加速能力随后引入 Alluxio 作为统一的数据缓存与加速层。Alluxio 提供Distributed CacheData LocalityRemote IO Acceleration于是原本存储在 Hive、对象存储、HDFS 中的数据即使完全保留在原位置也开始共享统一的数据缓存与局部性优化能力。原始数据仍然由各 Source Connector 管理而缓存状态与数据局部性则由 Alluxio 统一维护。IO Optimization 开始从某个存储系统的内部能力演化为整个 Federated Engine 的共享能力。第三步引入 Iceberg —— 获得统一的数据管理能力接着引入 Iceberg 作为统一的数据管理能力提供者。Iceberg 提供Snapshot MetadataTransaction SemanticsMetadata GraphFine-grained Metadata Indexing这些能力使得 Presto 开始具备构建跨系统数据管理能力的基础例如Materialized View State ManagementIncremental RefreshQuery RewriteMetadata-aware Optimization此时原始数据仍然来自 Hive、PostgreSQL、Oracle 或对象存储Materialized View 的状态管理则统一由 Iceberg 承担查询改写、谓词缝合、增量刷新以及优化决策则由 Presto Federated Engine 负责完成这意味着Materialized View 不再必须绑定于某个单独的数据系统而开始呈现出一种由 Federated Engine 与底层数据管理系统共同提供的平台能力。第四步引入 Lance —— 获得统一的 AI Data Management 能力最后引入 Lance 作为统一的 AI Data Management Layer。Lance 提供Vector StorageVector IndexANN Retrieval InfrastructureAI Dataset ManagementMultimodal Asset Management于是原始数据仍然保留在 Hive、PostgreSQL 或对象存储中Embedding、Vector Index 以及 AI Dataset State 则统一由 Lance 维护Retrieval Planning、ANN Execution 以及 Federated Optimization则由 Presto Engine 统一编排在这样的能力组合方式下即使原始数据从未迁移整个系统仍然有机会获得如下的 AI-native 能力Vector RetrievalSemantic SearchRAG RetrievalAI Dataset Lifecycle Management这意味着AI Capability 有望成为整个 Federated Engine 的共享能力而不再专门属于某个独立的 AI 数据平台或 AI 表格式。4.3 核心启示能力开始变得可迁移这个例子的核心价值并不在于引入了多少新的组件而是企业建设数据平台的方式开始发生变化传统模式Capability Federation能力绑定于特定存储系统能力作为可插拔的服务层附着于数据之上获取新能力需要迁移数据获取新能力更多依赖新增 Capability Provider平台建设是替换式的平台建设是增量式的数据与能力强耦合数据与能力逐渐解耦数据集中化能力联邦化能力附着于数据而非绑定于某一种数据系统——这正是 Capability Federation 架构在工程实践中的核心体现。在这种模式下企业建设数据平台的方式也开始发生变化平台演进的重点或许将逐渐从持续建设新的数据系统转向持续为现有数据系统附着新的能力。五、为什么 Capability Federation 可能成为一种重要路线5.1 Unified Platform 与 Capability Federation在讨论 Capability Federation 时一个自然的问题是为什么不直接构建一个统一平台将所有能力都内建到同一个系统之中事实上这也是当前许多主流商业数据平台所采用的路线。典型代表包括 Databricks、Snowflake 以及 BigQuery。这些系统的核心思路并非联邦化能力组合而是将存储、元数据、优化器、执行引擎以及上层能力统一纳入同一个平台之中。从工程角度来看这一路线在某些方面具有明显优势更强的一致性更统一的用户体验更大的全局优化空间更清晰的系统边界因此Capability Federation 并不意味着 Unified Platform 的失败。相反这两种路线实际上是在尝试解决同一个问题如何让越来越复杂的数据能力被更加高效地利用。区别仅在于Unified Platform 更倾向于吸收能力Capability AbsorptionCapability Federation 更倾向于组合能力Capability Composition5.2 Specialized Capability Explosion过去很多年中数据平台建设几乎始终围绕着同一个目标展开Data Unification。其核心思想是将数据迁移到统一的平台中再统一进行治理、分析与计算。这一思路背后的基本假设是只有数据集中能力才能集中。然而随着 Lakehouse、AI Workload 以及多模态数据的发展一个新的变化正在逐渐出现越来越多的数据能力开始从传统数据库内部独立出来并演化为专门的数据系统。例如Open Table FormatMetadata CatalogDistributed CacheVector DatabaseFeature StoreAI-native Table Format与此同时这些系统之间的差异也正在从简单的数据存储差异逐渐演化为语义能力差异。例如Iceberg 更关注SnapshotTransactionBranchMetadata Graph而 Lance 更关注Vector IndexANN RetrievalEmbedding Dataset两者所关注的问题域已经存在明显差异。这意味着如果统一平台希望同时支持所有能力并做到与专业系统同样优秀其复杂度将急剧增加。于是一个新的问题开始变得越来越重要是否一定要将数据迁移并集中才能获得新的能力在这种背景下一种新的思路开始逐渐浮现Capability Unification。其关注的重点不再仅仅是Where is the data?而是What capability does the system provide?How can these capabilities be exposed?How can these capabilities be composed?换句话说系统所追求的目标不再是强制统一存储、统一格式以及统一平台而是统一能力的暴露方式、统一能力的组合机制以及统一能力的利用路径。在这一模式下数据仍然可以保留在最适合自身 workload 的系统之中而 Federated Engine 则负责发现、组合并利用这些分散在不同系统中的 specialized capabilities从而将原本孤立的系统能力逐渐演化为整个数据平台的共享能力。5.3 两种路线的长期共存未来很长时间内这两条路线很可能长期共存。Unified Platform 路线在以下场景中仍然具有显著优势强一致性与事务保障要求极高的核心业务场景追求极致用户体验与开箱即用能力的场景技术栈高度统一的组织Capability Federation 路线则更适合已经存在大量异构系统的企业环境希望渐进式演进而非推倒重来的场景希望组合不同专业系统最佳能力的复杂场景因此Capability Federation 更适合作为一种趋势观察而非必然结论。未来很长时间内两条路线大概率会长期共存并根据不同约束条件各得其所。六、为什么这一趋势对 Presto 尤其重要Presto 从诞生之初就天然具备Federation-first Architecture。其核心设计目标从一开始就不是 Single-storage Coupled Engine。而是多数据源多 Connector多系统协作因此当 Connector 从 Storage Adapter 演化为 Capability Provider 时Presto 的 Federation Architecture 将天然获得新的战略意义。它不需要像许多统一平台那样重新设计系统边界。因为聚合异构系统本来就是 Presto 的原始设计目标。如果未来越来越多的数据系统开始向外暴露 specialized capability那么 Presto 天然具备成为这些能力统一入口与统一编排层的基础条件。从这个意义上讲Presto 的 Federation-first Architecture或许正在获得新的时代语义。结语从 Query Federation 到 Capability Federation过去很多年中Federated Engine 所联邦的对象始终是 Data Source。因此Connector 的职责被定义为Access to Data。然而随着越来越多的数据系统开始提供丰富的数据语义与 specialized capability联邦引擎未来所关注的对象可能已经不再只是数据本身而是越来越多具备独立能力与语义的表格式及数据系统。Connector 的价值不再只是如何读取数据。其正在变得越来越厚开始逐渐演化为如何将底层系统擅长的能力释放出来。如果这一趋势持续发展那么未来 Federated Engine 的核心竞争力可能越来越取决于吸收新能力的效率组合新能力的能力利用新能力的深度当然Capability Federation 并不意味着所有问题都已经有答案。能力发现、能力编排、能力选择以及统一优化等问题未来仍然存在大量值得探索的空间。但这些问题更多属于工程实现层面的挑战而非方向层面的障碍。如果说传统 Federated Engine 主要围绕 Data Source 构建抽象通过 Connector 实现对不同数据系统的统一访问那么 Capability Federation 则是在这一基础之上的进一步演进Data Source 仍然是核心能力来源之一但引擎关注的对象不再局限于数据访问本身而是进一步扩展到数据系统所提供的更丰富能力包括事务与版本管理、增量计算、元数据智能、查询优化、数据维护、向量检索、语义搜索以及 AI 数据管理能力。因此围绕 Capability 的暴露、组合与利用将很可能成为下一阶段数据基础设施演进的重要主题。而这也许正是 Lakehouse 与 AI Data Infra 时代Federated Engine 的下一次战略机会所在。作者王冬PrestoDB Committer | Presto Iceberg Code OwnerGitHub: https://github.com/hantangwangdEmail: mingwbdgmail.com欢迎就相关技术问题与实践经验进行交流与探讨Github Pages本文也同步发布于https://hantangwangd.github.io/zh/posts/2026-07-08-capability-federation.html