数据目录联邦

事实核验截至：2026年10月4日。 厂商功能和兼容范围会更新；文中注明的文档更新日和产品里程碑按各来源原文表述。

在企业数据平台中，数据目录通常记录数据库、模式、表、列、分区、数据位置及表格式元数据。多个分析系统并存时，同一份表数据可能仍由某个外部目录管理，而各团队希望在另一个查询平台中发现并使用它。数据目录联邦（Catalog Federation）通常指把外部目录连接到分析平台，使本地用户能通过外部表或联邦目录访问这些表，而不必先把底层表文件整体复制进新平台。它是数据目录和分析平台的一类能力名称，并非跨厂商完全统一的协议或产品定义。

常见实现中，源目录仍提供表的结构和位置等信息；目标平台建立连接、读取或同步相关元数据，并创建本地可见的外部目录对象；计算引擎再依据元数据访问对象存储中的文件。采用 Iceberg 等开放表格式的表，还可能依赖快照和清单等元数据，供引擎确定一张表当前包含哪些文件。Apache Iceberg 规范 由此形成控制面与数据面的分工：目录回答“表是什么、文件在哪里”，存储层保存数据文件，查询引擎负责执行扫描和计算。查询结果、请求和读出的数据仍会经过网络传送，因此“无需迁移底层表文件”不等于没有数据移动或通信成本。

目录联邦与查询联邦都能让一个平台查询外部数据，却通常采用不同路径。查询联邦一般连接外部数据库，通过 JDBC 等接口向该数据库推送查询或部分运算，数据源数据库和发起方计算资源可能共同参与执行；目录联邦则从外部目录解析表定义和存储位置，再由当前分析引擎直接读取对象存储中的表文件。Databricks 将这两种路径列作 Lakehouse Federation 的不同选项：其文档将查询联邦描述为通过 JDBC 推送查询，将目录联邦描述为直接访问对象存储上的外部表；具体来源能使用哪一种仍取决于连接器与表类型。Databricks：连接外部数据库和目录

目录联邦也不同于常见的目录采集或元数据同步任务。以 AWS Glue crawler 为例，crawler 会扫描数据存储、推断格式与结构，并将生成或更新的表定义写入 Glue Data Catalog；这是采集和登记元数据的过程。AWS Glue：使用 crawler 填充 Data Catalog 联邦功能则面向另一个目录中的既有表，目标系统保留指向源目录和外部数据位置的关联，在访问时查找、更新或缓存元数据，并由受支持的引擎访问表数据。两者并非互斥：联邦实现也可能在目标目录登记外部表、刷新元数据，甚至组合采集或复制机制；差别在于表定义的权威来源、更新方式以及查询时的数据访问路径，而不只是“有没有复制一份元数据”。

典型架构包含五类组件：源目录与表格式；存放文件的对象存储；用来连接、识别表和获取元数据的联邦服务或目录适配器；执行 SQL、Spark 作业或分析任务的计算引擎；以及负责身份、授权和审计的治理服务。管理员要配置目录连接、网络路径、身份凭据或角色、存储凭据，并决定哪些外部命名空间、表和路径能被发现及访问。使用者经本地目录检索表、提交查询；引擎获取当前表元数据、计算文件范围并读取存储对象，治理层按实现执行访问检查并记录审计信息。

“访问受治理”并不表示源系统的全部权限或语义会自动复制到目标系统。某些产品由本地目录实施表级授权，同时仍要求源目录连接身份拥有相应读取权，并要求目标引擎对文件位置具备存储访问权限；有的实现还限制可访问路径以防源目录中被改写的表位置越权。AWS Glue 的远端 Iceberg 目录联邦（由 Lake Formation 授权）通过 Glue Data Catalog 与远程目录发现表，并为 Amazon S3 表数据提供授权和范围受限的凭据；AWS 文档列出对联邦 Iceberg 表实施行、列、单元格权限的能力，但各引擎对权限粒度和写入的执行支持仍须查看适用矩阵。AWS Lake Formation：授权与功能说明 AWS Lake Formation：按服务查看权限支持 这些是 AWS 对应实现的机制，不应推定所有目录联邦都具备相同权限模型。

身份与存储访问常需分开设计：目录连接使用的服务身份可以读取表的结构和位置，但引擎还必须按目标表位置获得实际文件访问权。机构需决定用源端身份、目标端角色还是短期委派凭据，以及身份如何映射到本地用户。路径白名单、存储桶策略、加密密钥访问、网络端点和审计记录应一并核对。若目录元数据允许表所有者变更文件路径，却没有相同的存储访问边界，授权规则可能覆盖不到实际数据对象。因此，管理员应核验目录端、分析平台和对象存储三处权限的一致性，并在配置更改后检查谁能看到表、谁能读取文件、由哪个身份执行查询。

“目录联邦”描述的是一类连接和访问模式，实际支持什么目录、表格式、引擎、云区域和身份方式必须逐一核对。例如，截至其 2026年9月29日更新的 AWS 版文档，Databricks Unity Catalog 目录联邦列有旧版 Databricks Hive metastore、外部 Hive metastore、AWS Glue、Salesforce Data 360、Snowflake、Palantir Foundry 和 Workday Data Connect 等来源；这份列表说明的是该 Databricks 实现当前列出的来源，不代表其他平台都能连接这些服务。Databricks：什么是目录联邦（更新于2026年9月29日）

AWS Glue 的远端 Iceberg 目录联邦（由 Lake Formation 授权）针对远端目录管理、存放在 Amazon S3 上的 Apache Iceberg 表：Glue 获取表元数据，由支持的 AWS 分析引擎等直接读取 S3 文件；AWS 文档还列出每次 REST API 调用的 Iceberg 表元数据大小上限为 5 MB。AWS Lake Formation：功能与限制 AWS 于 2025年11月24日宣布该 AWS Glue 功能达到正式可用（GA），公告称当时在提供 Glue 与 Lake Formation 的 AWS 商业区域可用，并说明其集成支持 Iceberg REST 规范的目录实现。AWS：2025年11月24日正式可用公告 这只是 AWS 的发布日期和产品范围，不是目录联邦概念的诞生日，也不能推及任意 Iceberg REST 目录、文件格式或云环境。

写入尤其需要按具体目录和表格式查明。只读外部目录可把数据发现和查询与源端写入分开，但对有跨引擎写入需求的组织，这可能需要另设写入路径，并明确由哪个目录负责提交、并发冲突怎样处理。Snowflake 的 catalog-linked database 支持按配置创建外部 Iceberg 表；ALLOWED_WRITE_OPERATIONS 可设为 NONE（只读）或 ALL（可写），SQL 文档列出的默认值为 ALL，实际写入仍以目录实现、身份与存储权限等条件为前提。Databricks 的文档则说明其联邦目录通常允许读取，而内部旧版 Hive metastore 有读写例外。Databricks：什么是目录联邦 对 Snowflake 可写 catalog-linked database 中的表执行 DROP 时，表条目会从 Snowflake 和远端目录移除；默认不请求删除底层数据与元数据文件。只有执行 PURGE 或设置 PURGE_ON_DROP_TABLE 才向远端目录转发清除意图，是否实际删文件由目录实现决定；AWS Glue 不遵从该 purge 标志，因此仍保留底层表文件。Snowflake：外部管理 Iceberg 表的写入与删除 这类差异说明，不能从“联邦”概念本身推断写入权限，更不能假设删除、表属性变化或快照提交会在多个目录间以相同方式传播。

名称近似的能力未必是同一产品类别。Snowflake 的 catalog-linked database 将一个 Snowflake 数据库连接到外部 Iceberg REST catalog，自动发现命名空间和 Iceberg 表并使之可在 Snowflake 中查询；默认按 30 秒间隔轮询目录，也能配置刷新间隔。官方 SQL 文档给出 NONE（只读）和 ALL（可写）两种操作权限选项，默认值为 ALL，并注明 Snowflake 不会同步远端目录中针对用户或角色的访问控制。Snowflake：catalog-linked database Snowflake：CREATE DATABASE（catalog-linked） 相关计费需区分操作：自动表发现、创建/删除模式和删除表计入 Cloud Services 消耗，但只有每日 Cloud Services 消耗超过当天 warehouse 用量 10% 时才收费；Iceberg 自动元数据刷新由 Snowpipe 执行，费用显示在 Snowpipe 账单项下，但不收取该功能的 Snowpipe file charges；通过自动刷新在 catalog-linked database 中创建表计入计算用量；SELECT 查询则需要 warehouse compute。Snowflake：自动刷新 Iceberg 表的计费 Snowflake：catalog-linked database 使用量 Snowflake：仓库概览 因此，它可与目录联邦作比较，或视为相邻的目录链接模式，但不应据名称将其与其他厂商功能视为同一种实现。反向跨平台的示例是 Databricks 访问 Snowflake 管理的 Iceberg 表：Databricks 文档把符合条件的 Iceberg 表归为目录联邦，而非 Iceberg 表或不满足直接存储访问条件的表则使用查询联邦。Databricks：启用 Snowflake 目录联邦（更新于2026年9月22日）

企业常在渐进式平台迁移、混合分析环境、跨团队复用数据，以及多个引擎读取同一份 Iceberg 或其他受支持开放表数据时考虑目录联邦。它能避免为了“让另一个引擎看见表”而必然先建一份完整的数据副本；也可能让集中目录、审计或访问流程变得更清晰。Databricks 将逐步迁移到 Unity Catalog、并长期保留一部分外部目录数据作为常见用途。Databricks：什么是目录联邦 是否采用仍应由现有存储、数据新鲜度、查询模式、治理责任和迁移安排共同决定。

联邦不会自动保证策略可移植、跨引擎写入安全或功能等价，也不必然改善性能或降低总成本。格式版本、表元数据结构、目录 API、身份提供者、凭据委派、对象存储授权、区域与云网络、加密方式、目标引擎功能以及源目录的刷新语义都可能影响可用性和结果。只读、受限格式、缺少凭据委派、命名差异、快照兼容或网络边界都可能成为约束；个别产品把不符合直读条件的表转交给查询联邦，也不代表所有产品都会这样回退。查询仍要消耗引擎计算、存储请求和网络流量；若跨区或跨云访问，还须核实延迟、出口费用、并发限制和故障责任。写入能力尤其不能从“联邦”二字推断：外部目录只读、指定产品可写、仅部分表支持写入，均可能并存。

目录同步频率同样不应被解释为全局实时一致。Databricks 对其外部 Hive 目录说明可在查询时更新元数据，而绕过 Databricks Runtime 的外部引擎访问可能需要人工或定期刷新；Snowflake 的链接数据库按配置轮询远端目录，默认间隔为 30 秒；AWS 文档描述在查询访问时发现最新表信息。Databricks：刷新联邦目录元数据 Snowflake：链接数据库同步与查询 这些行为说明不同产品对目录发现与表状态更新的处理方式不同，具体陈旧窗口还取决于缓存、引擎和访问路径。

部署前宜用代表性表和查询逐项验证：源目录对表与快照的权威性、元数据刷新频率、读写及并发提交边界；目标引擎支持的目录 API、表格式版本和 SQL 操作；跨系统的身份映射、最小权限、存储路径约束及审计记录；目录不可用、授权过期、文件改址或刷新失败时的行为；以及按数据读取位置核算的计算、请求和传输成本。只有在这些条件明确后，“保持数据就地”才能转化为可维护的企业访问路径。