大卫小东（Sheldon）峡

Issue 概述先来看看提交这个 Issue 的作者是为什么想到这个点子的以及他初步的核心设计概念。??本 PR 实现了 Apache Gravitino 与 SeaTunnel 的集成将其作为非关系型连接器的外部元数据服务。通过 Gravitino 的 REST API 自动获取表结构和元数据SeaTunnel 用户无需再在连接器配置中手动定义冗长且复杂的 Schema 映射。背景目前Apache SeaTunnel 中的许多非关系型连接器如 Elasticsearch、向量数据库和数据湖引擎要求用户在作业配置中显式定义完整的列 Schema。这导致了以下问题配置繁琐且易错字段映射内容冗长极易发生人为错误。架构冗余不同作业之间存在大量重复的 Schema 定义。数据不一致风险实际存储层与 SeaTunnel 配置文件之间容易出现架构脱节。变更内容本 PR 增加了基于 Gravitino 的 Catalog 和 Schema 解析器使 SeaTunnel 能够通过 REST API 从 Gravitino 查询表定义。自动获取列名、数据类型及相关属性。直接根据 Gravitino 元数据构建 SeaTunnel 内部 Schema。针对受支持的连接器取消强制手动定义 schema { fields { ... } } 的要求。实现后用户只需在作业配置中指定 Gravitino Catalog 和相关的表引用即可。核心优势零手动映射非关系型数据源实现 Schema 自动对齐。单一事实来源确保表结构与中心化元数据仓库保持高度一致。提升可靠性显著提高配置的准确性降低长期维护成本。支持复杂类型通过统一元数据简化了对嵌套结构、JSON、向量等高级类型的处理。执行范围所有基于 Gravitino 的 Schema 解析和校验均在 SeaTunnel Engine 客户端完成即在作业提交前。这种设计确保了在作业预检阶段即可发现无效或不兼容的 Schema。运行时的任务仅接收经过验证和标准化的 Schema降低了执行失败的概率。影响这一更新极大地简化了非关系型连接器的作业设置。除了提升易用性它还为整个 SeaTunnel 生态系统在统一架构管理、架构演进以及高级数据类型支持方面奠定了技术框架。核心思路针对 FTP、S3、ES、MongoDB 等半结构化与非结构化数据源SeaTunnel 现支持通过 Gravitino REST API 自动解析表结构Schema。需要注意的是这并非要取代现有的显式配置而是一项完全向前兼容的可选新机制。解析优先级如下1. 显式配置Inline Schema永远优先只要连接器配置中包含了 schema 代码块SeaTunnel 就必须忽略 Gravitino直接以显式定义的 Schema 为准。FtpFile {path /tmp/seatunnel/sink/text# ... 其他基础配置 ...# 只要这里定义了就不会去查 Gravitinoschema {name stringage int}}2. 通过 env 全局配置 Gravitino推荐模式SeaTunnel 已在引擎层面集成了 Gravitino Metalake。在 env 中全局开启后所有非关系型数据源都能直接通过名称引用 Schema。env {metalake_enabled truemetalake_type gravitinometalake_url http://localhost:8090/api/metalakes/metalake_name/catalogs/}2.1 使用 schema_path 引用FtpFile {# ... 基础配置 ...schema_path catalog_name.ykw.test_table}2.2 使用 schema_url 引用FtpFile {# ... 基础配置 ...schema_url http://localhost:8090/api/metalakes/laowang_test/.../tables/all_type}3. 兜底逻辑读取操作系统环境变量如果在作业的 env 块中没有定义 GravitinoSeaTunnel 会尝试从操作系统环境变量中读取以下配置metalake_enabled | metalake_type | metalake_url其行为逻辑与第 2 节中的 env 配置完全一致。4. 在连接器层级单独配置 Gravitino如果全局没有配置元数据中心也可以在具体的连接器Connector内部直接定义 Gravitino。4.1 直接使用 schema_urlFtpFile {# ... 基础配置 ...metalake_type gravitinoschema_url http://localhost:8090/api/.../tables/all_type}4.2 组合使用 metalake_url 与 schema_pathFtpFile {# ... 基础配置 ...metalake_type gravitinometalake_url http://localhost:8090/api/metalakes/metalake_name/catalogs/schema_path catalog_name.ykw.test_table}5. 探测器定位 (Find detector)系统会根据 metalake_type 自动匹配并加载对应的 REST API HTTP 探测器。6. 映射与构建 CatalogTable探测器调用拼接好的 URL 获取响应体ResponseBody随后将其交给映射器Mapper进行类型匹配最终完成 CatalogTable 的构建。7. 流程图如下Issue 进展目前Apache SeaTunnel 项目核心贡献者对此提议给出了正面评价并将其添加到 Apache SeaTunnel Roadmap 中。Apache SeaTunnel PMC Member 对这个提议提出一些疑问比如这种集成属于哪一层级对多引擎兼容性的考量类型转换的准确性等并根据社区设计规范要求发起者提交一份正式的设计文档Design Document。提交者的回复非常具有建设性他通过 “客户端预处理”和“抽象 Catalog 接口” 这两个核心设计点有效地回应了社区对于系统耦合度和运行稳定性的担忧。赏堆一罢