数据治理] OpenMetadata：面向数据与 AI 的开源【统一元数据】、上下文层平台、【数据治理平台】

0 序

OpenMetadata —— 由 Apache Hadoop /Atlas 与 Uber Databook 创始团队打造、以「开放上下文层（Open Context Layer）」为定位、拥有 130+ 原生连接器的一体化开源元数据管理与数据治理平台。

创始团队本身就是大数据、元数据管理的最核心开源项目成员，算是高起点的开源项目了。

两年前给科室做元数据、数据资产的开源工具调研时，就高度关注了此项目。当时 OpenMetadata 还远远没有现在的社区热度，其热度远逊色于 DataHub 等这些老项目。但两年时间过去，Github star 数从2024.02的3.7K涨到现在2026.09的15.7k，说明了几点：

企业的数据治理与管理（尤其是元数据、数据资产的管理），受到企业、及数据团队的高度重视。

OpenMetadata 已成为实质上的元数据管理、数据资产管理细分领域的Top1、事实标准。

逆袭式地干掉了诸多同类型的开源竞品项目，包括但不限于： Datahub / Apache Atlas / Amundsen / Marquez / ...。

1 概述: OpenMetadata

产品介绍

OpenMetadata 是一个开源的一体化元数据管理与数据治理平台，当前自我定位为「数据与 AI 的开放上下文层（Open Context Layer）」：将技术元数据、数据质量信号、血缘、所有权、使用情况、治理策略、业务术语、数据产品、数据契约与组织记忆（对话/决策/备注）统一汇聚到一个可查询的知识图谱（Knowledge Graph）中，让人与 AI 助手/智能体基于同一份受治理的上下文做出决策。
产品定位：开源、可自托管的统一元数据平台 / 数据目录（Data Catalog）+ 数据治理 + 可观测 + AI 上下文层，覆盖「数据发现 → 理解 → 信任 → 记忆 → 使用」全链路。
诞生的背景与原因：现代数据栈碎片化，元数据散落在数据库、数据仓库、BI 工具、管道、ML 系统中；团队往往需要拼凑多个工具才能完成目录、血缘、质量、治理，且缺乏统一的语义层。OpenMetadata 的核心理念是「元数据管理不应靠五套工具缝合」。
解决的核心问题：数据资产的统一发现与搜索；列级血缘与影响分析；开箱即用的数据质量；业务术语/治理策略的沉淀；以及为 LLM 与 AI 智能体提供「受治理的数据上下文与组织记忆」，使其能基于语义而非关键词理解、检索和操作企业数据。
团队背景：由 Apache Hadoop、Apache Atlas 的创始人及 Uber Databook / uMetadata 的核心成员创立；2021 年开源，2022 年起快速成长为增长最快的开源元数据项目。
URLs：
- 官网：https://open-metadata.org/
- GitHub 仓库：https://github.com/open-metadata/OpenMetadata
- 文档/部署指南：https://docs.getcollate.io/（商业公司 Collate 提供托管与支持）
- 许可证：Apache License 2.0

关键数字（官网口径）：15,000+ GitHub Stars · 450+ 代码贡献者 · 14,000+ 开源社区成员 · 4,000+ 企业级部署 · 200 万+ 数据资产（大型部署） · 130+ 原生数据连接器 · 18,969 commits。

发展历程

时间	里程碑
2018 年及以前	创始团队在 Uber 构建内部元数据系统 Databook / uMetadata，积累一线经验
2021 年	OpenMetadata 项目正式开源（Apache 2.0），由 Hadoop/Atlas 创始人与 Uber Databook 团队创立
2022 年	成为开源数据目录「三大巨头」（DataHub / Amundsen / OpenMetadata）中增长最快的项目，0.x 系列快速迭代
2023–2025 年	1.0 及 1.x 系列成熟：补齐数据质量、数据治理、血缘、数据契约、领域/数据产品、MCP 等能力；连接器扩充至 120+；GitHub Stars 从约 8,700 快速攀升至 15,000+
2026 年 8 月 24 日	发布 OpenMetadata 2.0（从 1.x 跨越至 2.0 主版本），进一步强化 AI 上下文层能力
2026 年至今	最新维护版进入 1.10.x → 2.x 双轨，聚焦连接器可靠性、MCP 工具整合、安全依赖清理与治理能力

注：GitHub 页面徽章展示的 V1.10.7-RELEASE 与官方宣布的 2.0 并存，2.0 为 2026 年 8 月 24 日跨主版本发布；1.10.x 为稳定维护系列。

主要功能

数据目录与发现（Cataloging & Discovery）：统一收录数据库、表、列、主题、仪表盘、图表、管道、API、搜索索引、ML 模型、存储资产等；支持自然语言搜索、语义搜索与高级筛选（Domain / Tier / Tag / Certification / Service 等）。
血缘与影响分析（Lineage & Impact）：表级与列级血缘、仪表盘/管道/指标/ML 模型血缘；支持查看上游/下游、编辑血缘、影响分析。
数据质量（Data Quality）：内置近 30 类表/列测试（新鲜度、行数、空值、唯一性、分布等），无代码测试构建器、测试套件、数据画像（Profiling）、质量看板、告警与事件/修复工作流。
数据治理（Data Governance）：领域（Domains）、数据产品（Data Products）、术语表（Glossary）、分类/标签（Classifications/Tags）、敏感数据识别、认证（Certification）、策略（Policies）、所有权（Ownership）、数据契约（Data Contracts）、数据血缘治理。
协作（Collaboration）：资产下的线程讨论、任务、备注、决策记录；将组织「部落知识」沉淀为可复用的组织记忆（Memory）。
AI 上下文层（AI Context）：MCP Server（首个企业级元数据 MCP 服务）、语义搜索、可被 LLM/智能体消费的统一知识图谱，支持嵌入（Embeddings）、提示词查询、仪表盘生成等；被 OpenAI 等用于构建内部 AI 数据智能体。
开放标准与生态（Open Standard）：基于 904 个 JSON Schema 的正式本体（Ontology），支持 W3C 系列（RDF、OWL、DCAT、Schema.org、OpenLineage、MCP 等）；130+ 原生连接器覆盖数据库、数仓、湖仓、BI、管道、消息、ML 系统。
开放 API / SDK：REST API、Java/Python/TypeScript SDK、Python 采集框架、Kubernetes Operator、事件与工作流引擎。

核心优势

一体化（All-in-One）：目录、血缘、质量、治理、协作、AI 上下文在单一平台内闭环，无需拼凑多套工具。
开箱即用的数据质量：内置数据质量测试与无代码测试构建器，是其他开源目录（DataHub/Amundsen/Atlas）在无外部工具时普遍缺失的能力。
架构简洁、运维较轻：MySQL/PostgreSQL + Elasticsearch/OpenSearch + Java 后端 + React UI + Python 采集，无图数据库、无 Kafka 强依赖，比 DataHub 更轻量。
连接器广度突出：130+ 原生连接器，覆盖 Unity Catalog、AWS Glue、Iceberg、Snowflake、BigQuery、Databricks、ClickHouse 等，另有 REST/API 通用接入。
列级血缘与影响分析：血缘能力业界领先，便于变更影响评估。
开放标准与 Schema-First 设计：以 904 个 JSON Schema 驱动 Java/Python/TS 代码生成，配合 W3C 标准，生态集成成本低。
面向 AI 的前瞻定位：率先提供企业级 MCP Server、语义搜索与 AI 记忆层，被 OpenAI（3500+ 员工 AI 数据智能体）、Carrefour Brazil 等采用。
开源社区活跃、增长最快：GitHub Stars 一年内近乎翻倍（约 8,700 → 15,235），Apache 2.0 协议友好。

主要短板

自运维成本不可忽略：开源版免除的是软件许可费，而非部署、升级、维护、治理的工程成本；对缺乏平台工程能力的小团队是一大负担。
连接器深度参差：「支持 100+ 连接器」不等于每个连接器的元数据覆盖深度都满足需求，选型时需逐一对齐目标系统的能力。
架构存在已知非不变量：Java 的 resources ↔ jdbi3 存在循环依赖；前端仍大面积直接引入 Ant Design（864 个文件 vs UI 核心组件 522 个），ui-core-components 迁移处于「进行中但停滞」状态。
大型部署需规划与专用资源：元数据规模大、并发高时，MySQL/ES 与采集管道需要专门资源与调优，初始部署需充分规划。
迁移版本管理与升级：多版本快速迭代（0.x → 1.x → 2.0），升级需谨慎处理 Schema 迁移（迁移仅追加不修改）。

局限性

数据治理深度：策略管理功能相对专注目录/质量/血缘，面向超大型企业的复杂合规策略编排能力弱于 DataHub 或商业平台。
不内置商业级 SLA/支持：开源版依赖社区，企业级支持、SLA 与高级治理功能需商业产品 Collate 提供。
图查询能力：采用关系型 + 搜索引擎而非原生图数据库，对极深的多跳血缘图遍历性能可能不及专用图存储。
特定环境适配：在 Hadoop 生态深度治理方面，老牌 Apache Atlas 更具针对性。

适用场景

现代云数据栈团队（Snowflake / BigQuery / Databricks / ClickHouse + BI + 管道）需要统一目录、血缘、质量与治理。
数据平台工程：建立数据资产清单（数据字典）、血缘图谱、数据质量门禁与告警。
数据治理与合规：敏感数据（PII）识别与分类、术语表、认证、数据契约、领域与数据产品。
AI/LLM 智能体上下文构建：为 AI 助手提供受治理的数据语义、血缘与组织记忆（RAG / AI 数据智能体）。
从「部落知识」到制度化：通过协作、备注、决策记录沉淀组织记忆，减少对资深员工的依赖。

平台	定位 / 哲学	血缘	数据质量	治理	协作	MCP/AI	备注
OpenMetadata	统一 All-in-One，现代 UI	表级+列级 ✅	内置（无代码）✅	✅	✅ 线程/任务	✅	增长最快，架构轻
DataHub	实时、事件驱动、分布式	表级+列级 ✅	有限	✅ 较强	有限	❌	图架构，重，企业支持 Acryl
Amundsen	Lyft 出品的轻量目录	有限	❌	有限	❌	❌	社区增长放缓，「三大」之一
Apache Atlas	Hadoop 原生、老牌治理	表级 ✅	❌	✅	✅	❌	深度绑定 Hadoop 生态，2015 起源
Collate	OpenMetadata 商业发行版	✅	✅	✅	✅	✅	提供托管、SLA、企业支持

发展趋势

开源社区活跃趋势：Star 数一年内从约 8,700 增至 15,235（近乎翻倍），代码贡献者 450+，commit 数近 1.9 万，Issues/PR 持续活跃；是「开源数据目录」赛道中增长最快、社区最活跃的项目之一。
Star / Fork 趋势：长期呈上升曲线，2026 年 8 月跨过 2.0 主版本成为重要增长节点；Fork 数随企业二次开发与集成需求同步增长（详见 GitHub 仓库 Insights）。
总结：OpenMetadata 正从「开源数据目录」向「AI 时代的数据上下文层」演进，通过 MCP、语义搜索、组织记忆与开放标准，成为 LLM 智能体与企业数据之间的受治理连接层，同时依托 130+ 连接器与轻量架构持续扩大开源版图。

2 工作原理与架构

概念术语

元数据（Metadata）：描述数据的数据（结构、血缘、所有权、质量、业务含义等）。
上下文层（Context Layer）：OpenMetadata 的新定位，把「数据是什么、意味着什么、谁拥有、如何被用、从哪里来、流到哪里、是否可信」等统一提供给人与 AI。
知识图谱（Knowledge Graph）：将资产、列、人、团队、质量、血缘、策略、记忆、契约、业务概念以关系（节点+边）连接的统一模型。
本体（Ontology）：定义表、仪表盘、ML 模型、血缘、所有权等实体的正式 Schema，支持 W3C 标准（RDF/OWL/DCAT/Schema.org）。
血缘（Lineage）：数据从源到目标的流动与依赖关系，分表级与列级。
连接器（Connector）：从外部系统采集元数据的插件，遵循 ServiceSpec 契约。
术语表（Glossary）/ 分类（Classification）：业务术语与标签/敏感分类体系。
数据契约（Data Contract）：数据生产者与消费者之间关于 Schema、语义与质量的正式约定。
数据产品（Data Product）/ 领域（Domain）：面向业务组织的资产分组与治理单元。
MCP（Model Context Protocol）：Anthropic 提出的智能体上下文协议，OpenMetadata 提供企业级 MCP Server。
Ingestion / Airflow：元数据采集框架及其调度执行器。

架构与运行原理

OpenMetadata 整体是一个「Schema-First」的多模块系统，核心由四大部分组成：

                    ┌──────────────────────────────────────────────┐
                    │                 React SPA (openmetadata-ui)   │
                    │         自然语言/语义搜索 · 资产浏览 · 治理 UI    │
                    └──────────────────────┬───────────────────────┘
                                           │ REST
┌──────────────────────────────────────────▼────────────────────────┐
│              Java 后端 (openmetadata-service, Dropwizard/JAX-RS)    │
│  资源层 resources/*Resource → 仓库 jdbi3/*Repository → DAO → SQL     │
│  事件层 events/ · 搜索层 search/ (ES/OS) · 治理 governance/ · 认证   │
└──────┬──────────────────────┬─────────────────────┬───────────────┘
       │                      │                     │
┌──────▼─────────┐   ┌────────▼─────────┐   ┌───────▼──────────────┐
│ MySQL / Postgres│   │ ES / OpenSearch │   │  Python 采集框架        │
│  元数据目录/仓库  │   │   搜索索引        │   │  ingestion/ (Airflow)  │
└────────────────┘   └──────────────────┘   │  130+ 连接器 → REST API │
                                            └────────────────────────┘
   ┌──────────────────────────────────────────────────────────────┐
   │  openmetadata-spec: 904 个 JSON Schema（源）                   │
   │   → jsonschema2pojo(Java) / datamodel-code-gen(Python)        │
   │   → quicktype(TypeScript) / ANTLR(FQN)   【Schema 单向生成代码】 │
   └──────────────────────────────────────────────────────────────┘

模块结构（Maven 12 个模块 + ingestion 树）：

模块	职责
`openmetadata-spec`	904 个 JSON Schema + 生成的 POJO，类型唯一事实源
`common`	共享工具类
`openmetadata-shaded-deps`	重定位的 ES/OS Java 客户端
`openmetadata-service`	核心后端：REST API、仓库、迁移、搜索、Apps
`openmetadata-sdk`	Java 客户端 SDK
`openmetadata-k8s-operator`	Kubernetes Operator（运行 OM 任务）
`openmetadata-mcp`	MCP Server（向智能体暴露 OM）
`openmetadata-integration-tests`	后端 API 集成测试
`openmetadata-ui-core-components`	规范化的 React 组件库
`openmetadata-ui`	React 单页应用（SPA）
`openmetadata-dist`	可分发服务端打包
`openmetadata-clients`	发布版客户端产物
`ingestion/`（非 Maven）	Python 采集框架 + 130+ 连接器，通过 REST API 写入

三条核心数据通路（Paths）：

Path A — API 请求（如 POST /v1/tables）：JAX-RS 资源 → jdbi3/*Repository（继承 EntityRepository）→ CollectionDAO/EntityDAO（129 个子 DAO）→ SQL 数据库；非 GET 响应同时扇出到变更事件层与搜索索引更新。
Path B — 采集运行（Ingestion）：Python 连接器（source/<type>/<name>/metadata.py）按 ServiceSpec 契约加载，通过 topology 产出实体，sink（metadata_rest.py）把实体 POST 到后端 REST API（即走 Path A）。采集由 Airflow 或 metadata CLI 触发。
Path C — 搜索查询：SPA 发起 → 后端 SearchResource → service/search/（294 文件）→ ES/OS（经 shaded 客户端）；索引在实体写入时由 *Index.java 增量构建，或由 reindex App 全量重建。

关键设计约束（Invariants）：

Schema-First：904 个 JSON Schema 是唯一事实源，通过 jsonschema2pojo / datamodel-code-generator / quicktype / ANTLR 单向生成 Java、Python、TypeScript 模型，反向编辑会在下次 make generate 被覆盖。
模块无环：12 个 Maven 模块构成有向无环、自顶向下的依赖图（0 环）。
连接器契约：每个连接器携带 service_spec.py 的 ServiceSpec 插件契约，约 98.9% 满足 create() + InvalidSourceException 约束。
迁移只增不删：迁移文件发布后不改写，变更以新版本追加。

已知架构弱点（非不变量，官方文档自述）：resources ↔ jdbi3 存在循环依赖；Ant Design 迁移 ui-core-components 停滞（antd 864 vs 封装组件 522 个文件）；生成类型大量被组件直接引用（1292 vs rest 93），缺少防腐层。

3 使用指南

详情参见: [元数据/数据治理] OpenMetadata 使用指南 - 博客园/千千寰宇

关键操作

接入数据源（Connector）：进入 UI → Services → 添加服务，选择对应连接器（Snowflake / BigQuery / Databricks / Postgres / ClickHouse 等 130+），填写连接信息并创建。
运行采集（Ingestion）：为服务创建 Ingestion Pipeline，配置采集范围（Schema、表、血缘、画像、质量、使用情况），由 Airflow 调度；也可用 metadata ingest -c <config> CLI 手动执行。
数据发现与搜索：使用顶部搜索框进行自然语言/语义搜索，按 Domain、Tier、Tag、Certification、Service 等筛选，查看资产详情（描述、列、血缘、质量、所有权）。
血缘与影响分析：在资产详情页查看上游/下游血缘（可切换列级），执行「查看影响 / 下载影响」评估变更风险，并支持手动编辑血缘。
数据质量：为表/列创建测试用例（无代码），组成测试套件，在数据质量看板查看结果与告警，并绑定事件/修复工作流。
治理与协作：创建 Domain、Data Product、Glossary、Classification（含敏感标签）、Certification、Data Contract；在资产下发起线程讨论与任务。
AI/MCP 消费：启用 MCP Server，使 LLM/智能体通过统一知识图谱进行语义检索与自动数据操作。
API/SDK：通过 REST API 或 Java/Python SDK 编程式读取/写入元数据，订阅变更事件。

Z FAQ for OpenMetadata

Q: OpenMetadata 与 DataHub 我应该怎么选？推荐 OpenMetadata(必读)

两者都是头部开源元数据平台。

选 OpenMetadata：你更看重血缘与影响分析、数据质量开箱即用、追求轻量运维、面向现代云栈、希望非技术用户易上手。

选 DataHub：元数据治理是组织结构性战略、偏好实时事件驱动/分布式、接受更重运维与图存储。详见「1 概述 · 同类竞品」对比表。

Q: OpenMetadata 是免费的吗？商用要钱吗？

代码以 Apache 2.0 协议开源，可免费下载、自托管、二次开发。企业级支持、SLA 与部分高级治理能力由商业公司 Collate（OpenMetadata 的发行商）提供付费服务。

Q: OpenMetadata 是否支持列级血缘？(必读)

支持。OpenMetadata 提供表级与列级血缘，并支持仪表盘、管道、指标、ML 模型的血缘及影响分析。

Q: 部署 OpenMetadata 需要哪些组件？资源要求高吗？

最小部署 = Server + 数据库（MySQL/Postgres）+ 搜索引擎（Elasticsearch/OpenSearch）+ 采集（Airflow）+ UI，用 Docker Compose 一键启动。官方建议 ≥8GB RAM；大型生产部署需为数据库、ES 与采集管道单独规划资源。

Q: OpenMetadata 如何与 AI/LLM 结合？

通过 MCP Server、语义搜索（Embeddings）、统一知识图谱与 REST API，LLM 与智能体可检索受治理的数据语义、血缘、所有权与组织记忆；OpenMetadata 已被 OpenAI 等用于构建内部 AI 数据智能体。

Q: 采集/连接器支持哪些系统？

130+ 原生连接器，覆盖数据库（Postgres、MySQL、SQL Server）、数仓/湖仓（Snowflake、BigQuery、Databricks、Redshift、ClickHouse、StarRocks）、BI（Power BI、Tableau、Grafana）、管道（Airflow、KafkaConnect、Spline）、消息（Kafka）、ML 与存储（Unity Catalog、AWS Glue、Iceberg）等；另支持 REST/OpenAPI 通用接入。

Q: 升级到新版本需要注意什么？

项目迭代快（0.x → 1.x → 2.0）。升级需关注 Schema 迁移（迁移只追加不改写）、连接器与 MCP 兼容性、数据库/ES 版本配套，建议先在测试环境验证再升级。

Q: 元数据能否以开放标准导出/集成？

可以。OpenMetadata 基于 904 个 JSON Schema 的正式本体，支持 W3C 标准（RDF、OWL、DCAT、Schema.org）及 OpenLineage、MCP 等，便于与外部系统互通。

Y 推荐文献

[Docker] Docker Compose 基础教程（概念/基础操作） - 博客园/千千寰宇

X 参考文献

posted @ 2026-09-23 15:06 千千寰宇阅读(15) 评论(0) 收藏举报

刷新页面返回顶部

千千寰宇

面向Data+AI转型的软件工程师，数智化转型实践者。【文章分类】【网络测验方法】【好物推荐】

[元数据/数据资产/数据治理] OpenMetadata：面向数据与 AI 的开源【统一元数据】、上下文层平台、【数据治理平台】

0 序

1 概述: OpenMetadata

产品介绍

发展历程

主要功能

核心优势

主要短板

局限性

适用场景

同类竞品

发展趋势

2 工作原理与架构

概念术语

架构与运行原理

3 使用指南

关键操作

Z FAQ for OpenMetadata

Q: OpenMetadata 与 DataHub 我应该怎么选？推荐 OpenMetadata(必读)

Q: OpenMetadata 是免费的吗？商用要钱吗？

Q: OpenMetadata 是否支持列级血缘？(必读)

Q: 部署 OpenMetadata 需要哪些组件？资源要求高吗？

Q: OpenMetadata 如何与 AI/LLM 结合？

Q: 采集/连接器支持哪些系统？

Q: 升级到新版本需要注意什么？

Q: 元数据能否以开放标准导出/集成？

Y 推荐文献

X 参考文献

公告

千千寰宇

面向Data+AI转型的软件工程师，数智化转型实践者。 【文章分类】 【网络测验方法】 【好物推荐】

[元数据/数据资产/数据治理] OpenMetadata：面向数据与 AI 的开源【统一元数据】、上下文层平台、【数据治理平台】

0 序

1 概述: OpenMetadata

产品介绍

发展历程

主要功能

核心优势

主要短板

局限性

适用场景

同类竞品

发展趋势

2 工作原理与架构

概念术语

架构与运行原理

3 使用指南

关键操作

Z FAQ for OpenMetadata

Q: OpenMetadata 与 DataHub 我应该怎么选？ 推荐 OpenMetadata(必读)

Q: OpenMetadata 是免费的吗？商用要钱吗？

Q: OpenMetadata 是否支持列级血缘？(必读)

Q: 部署 OpenMetadata 需要哪些组件？资源要求高吗？

Q: OpenMetadata 如何与 AI/LLM 结合？

Q: 采集/连接器支持哪些系统？

Q: 升级到新版本需要注意什么？

Q: 元数据能否以开放标准导出/集成？

Y 推荐文献

X 参考文献

公告

面向Data+AI转型的软件工程师，数智化转型实践者。【文章分类】【网络测验方法】【好物推荐】

Q: OpenMetadata 与 DataHub 我应该怎么选？推荐 OpenMetadata(必读)