企业官网建设流程全解析

OpenMetadata 如何启用 Blue/Green Rebuild 让 RDF 全量重建期间图谱保持可查询

【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata

当你需要周期性地把 OpenMetadata 的 RDF 知识图谱全量重建一遍时，默认行为会让你在重建期间拿到不完整的查询结果：一次recreateIndex运行会先清空正在对外提供服务的 dataset，再重新灌入数据，直到运行结束前，所有 SPARQL 查询返回的都是部分结果——在大型 catalog 上这个窗口以小时计。启用 RDF 索引应用配置里的Blue/Green Rebuild（与Recreate RDF Store同时开启）后，重建会先构建到一个空闲的第二 dataset，构建成功后才切换服务指针，旧图谱在整个构建期间持续对外服务。

以下内容基于 docs/rdf-production-setup.md 和 RDF 索引应用的配置说明 RdfIndexApp.md 整理，适用于使用 Apache Jena Fuseki 作为 RDF 存储、且已升级到 2.0.2 迁移之后的部署。

启用前需要满足的条件

• 2.0.2 的 SQL 迁移与全量 Pod 升级。2.0.2 迁移会创建 live write 队列和共享投影健康表（MySQL 和 PostgreSQL 均有）。文档明确要求：先应用 2.0.2 native SQL 迁移、升级所有 OpenMetadata Pod，之后再启用 online rebuild——旧版本 Pod 不参与 mutation journal 和 routing fence。
• Fuseki 侧的 assembler 已声明三个 dataset。官方镜像（openmetadata-fuseki:6.2.0，由docker/rdf-store/构建）的 assembler 会在数据卷上自动声明openmetadata、openmetadata_a、openmetadata_b三个 dataset，并带有相同的tdb2:unionDefaultGraph与超时设置。如果你使用自定义 endpoint 名称，需要有对应的 base、_a、_b三套 assembler 声明。
• 磁盘空间按三份 dataset 规划。启用 Blue/Green Rebuild 时，持久卷至少要按3 datasets × live size × 2.5规划：两个完整 dataset 在磁盘上交替使用，TDB2 compaction 还会在删除旧数据前在旁边构建替换 dataset。构建会在固定的openmetadata_a和openmetadata_b之间交替，而最初的openmetadata目录在操作员主动退役之前仍然存在，所以峰值时可能出现三份 dataset 副本加 compaction 余量。规划参考值（文档中的容量表）：每 triple 按 150–250 字节估算 live TDB2 数据，例如 1000 万 triple 约 1.5–2.5 GB，建议 16 GB 起步的持久盘。
• 从旧版--loc启动方式升级来的部署，还需要先把 TDB2 文件移动到 assembler 期望的/fuseki-data/openmetadata位置（错误的位置不会报错，而是静默启动一个空 store），并用下面的 triple 计数命令在升级前后各验证一次。

在 RDF 索引应用中开启 Blue/Green Rebuild

在 OpenMetadata 的 Applications 页面找到RDF Knowledge Graph Indexing应用（文档中称 RDF Indexing application），其配置项与含义如下：

触发方式有两条：

• 按需触发：直接启动该应用的一次运行。按需运行会绕过与 search 重建互斥的 admission guard（文档说明这是“operator intent wins”，日志中会有告警）。
• 计划任务：文档推荐的 RDF 重建排期是每周六 00:00 一次全量 recreate，cron 为0 0 * * 6（search 索引默认排在周日 00:30，避免两个全量扫描同时压数据库）。cron 触发的 RDF 重建如果撞上正在进行的 search 重建，会每 60 秒重查、最多等待 30 分钟；仍不结束就以STOPPED状态结束并等下一个计划窗口。

运行期间图谱如何保持可查询

开启后一次 Blue/Green 重建的执行路径是：

1. 协调器选出空闲的交替 dataset（openmetadata_a或openmetadata_b），把选定的 dataset、rebuild generation 和 payload budget 持久化到 job 上，所有 worker 使用这些不可变值。
2. 构建目标被清空、重新加载 ontology，然后以 insert-only 方式灌入记录；旧 dataset 在此期间不受任何影响。
3. 重建期间的 live 写入在接触 Fuseki 之前先提交一条 mutation journal 记录，并在共享 SQL fence 下路由，因此新写入不会丢失在旧快照里。
4. 构建完成后执行 promotion：把 journal 回放进已完成快照，原子地校验最终 watermark 并切换服务指针。每个 Pod 按指针路由，切换之后没有轮询延迟。promotion 还会在同一事务中标记 materialized inference rules 为 dirty，以便其输出随之重建。
5. 切换前会对目标 dataset 做一次 compaction（Blue/Green 运行在 promotion 前 compact 目标，而不是在服务 dataset 上 compact），保证 live writer 一直只用着旧 dataset。

相关的资源边界（文档明确列出）：mutation journal 上限为 256 MiB 或 100,000 条 mutation；构建 worker 持有 120 秒的 dataset lease，每 30 秒续租，用于隔离已失联的 worker；journal 回放（catch-up）有 5 分钟预算。繁忙到超出这些上限的 catalog 需要选择一个更安静的重建窗口。

验证重建结果

• 运行记录：应用 run record 状态变为COMPLETED。成功提升时应用日志会记录Activated RDF dataset 'openmetadata_a' (… triples before live mutation replay)（dataset 名为实际被选中的交替 dataset）。
• triple 计数：用 SPARQL 查询统计服务 graph 的 triple 数，确认非空且符合预期。文档给出的命令（地址和凭据按你的部署替换，<password>为配置的 Fuseki 管理员密码，镜像自带默认凭据为admin/admin，生产环境应覆盖）：

curl -s -u admin:<password> --data-urlencode \ 'query=SELECT (COUNT(*) AS ?n) WHERE { GRAPH ?g { ?s ?p ?o } }' \ 'http://localhost:3030/openmetadata/sparql' \ -H 'Accept: application/sparql-results+json'

注意 URL 路径段指向的是具体 dataset。启用 Blue/Green 后服务指针可能指向openmetadata_a或openmetadata_b，验证时应查当前 active dataset 对应的 endpoint（文档建议升级或切换后“Verify counts against the active dataset”）。

• 逐条失败记录：每记录级失败持久化在rdf_index_failures表（每次运行开始时清空），可通过GET /v1/rdf/reindex/failures查询，或在 RDF 应用的 UI 里点击 “View Reindex Failures” 查看。
• 运行度量：Micrometer 指标rdf.index.job（整个运行时长，按 outcome 打标签）、rdf.fuseki.request（按操作和结果打标签的延迟）可用于观测。
• 端到端测量：scripts/rdf-reindex-benchmark.sh触发完整索引应用并输出 wall clock、records/second、失败数、最终 triple 数和 Fuseki 请求数：

# OM_TOKEN 替换为你的管理员或 bot JWT OM_TOKEN=<admin-or-bot-jwt> ./scripts/rdf-reindex-benchmark.sh

docs/rdf-scale-validation.md 记录了一次 200,000 表 / 2,000,000 lineage edge 目录的实测（仅供参考，不代表你的部署必得同样数值）：两次全量重建各处理 200,555 条记录且零失败，独立计数验证最终 26,952,284 条 triple；取消一次分布式重建后，服务指针保持在openmetadata_a不变、已服务图谱的计数不变，随后恢复运行把openmetadata_b提升为服务 dataset；重建期间通过认证 SPARQL API 发出的 2,624 条查询全部返回非空结果。

失败时的行为与磁盘回收

• 提升有两道闸门。健全性检查拒绝激活一条记录都没索引成功却报告 0 triple 的 dataset；success-ratio 闸门在重建丢失记录超过1 - minSuccessRatio时拒绝提升。两种情况下旧 dataset 都继续服务，运行以可见的失败结束，不会悄悄上线一个空图。
• journal 耗尽或无法捕获某条 mutation会令本次重建失败，但对应的 live 写入仍会照常打到正在服务的图谱上——可查询性不因重建失败而受损。
• Blue/Green 运行绝不回退为清空服务图谱。明确要求 Blue/Green 的重建不会降级为 in-place 清空。
• 失败或被停止的重建不会删除半成品 dataset：服务指针保持不变，半构建的 dataset 保留在磁盘上供检查，下一次重建复用该目标时会先清空。
• 不确定的 build 写入会把对应 generation 隔离（quarantine），防止迟到的请求污染马上被复用的目标。恢复方式：重启 Fuseki 终止未决请求后，管理员可按rebuildId从rdf_rebuild_state删除该失败行，下一次重建会清空目标；服务指针不受此恢复操作影响。
• 回收空闲 dataset 的磁盘：通过 Fuseki admin API 删除 dataset 只移除注册，不删除 TDB2 文件。要完全释放空闲 dataset 的空间，需要停掉 Fuseki，然后删除非 active 指针 dataset 的{FUSEKI_BASE}/databases/<dataset>_a|_b目录。该操作会删除数据，务必先确认该 dataset 不是当前 active 指针，并保留 active dataset 及其 compaction 所需的余量。

参考

• 生产部署全貌（容量规划、写吞吐调优、监控端点）：docs/rdf-production-setup.md
• 规模验证与 Blue/Green 实测数据：docs/rdf-scale-validation.md
• 索引应用配置项说明：RdfIndexApp.md
• 本地启动与 API 示例：docs/rdf-local-development.md

【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata