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其配置项与含义如下配置项UI 名称 / 配置 id说明Recreate RDF Store /recreateIndex索引前清空 RDF store。Blue/Green Rebuild只有在该项开启时才生效Blue/Green Rebuild /blueGreenRebuild把重建构建到一个空闲 dataset运行成功后才切换为服务 dataset查询始终看到旧图谱而不是半重建的图谱。代价是磁盘上约需要两倍 dataset 大小Minimum Success Ratio /minSuccessRatio允许 Blue/Green 重建被提升为服务 dataset 之前索引成功记录必须达到的比例。低于该值时旧 dataset 继续服务本次运行标记为失败。默认0.95Entities /entities需要重建的实体类型列表留空表示索引所有受支持的实体触发方式有两条按需触发直接启动该应用的一次运行。按需运行会绕过与 search 重建互斥的 admission guard文档说明这是“operator intent wins”日志中会有告警。计划任务文档推荐的 RDF 重建排期是每周六 00:00 一次全量 recreatecron 为0 0 * * 6search 索引默认排在周日 00:30避免两个全量扫描同时压数据库。cron 触发的 RDF 重建如果撞上正在进行的 search 重建会每 60 秒重查、最多等待 30 分钟仍不结束就以STOPPED状态结束并等下一个计划窗口。运行期间图谱如何保持可查询开启后一次 Blue/Green 重建的执行路径是协调器选出空闲的交替 datasetopenmetadata_a或openmetadata_b把选定的 dataset、rebuild generation 和 payload budget 持久化到 job 上所有 worker 使用这些不可变值。构建目标被清空、重新加载 ontology然后以 insert-only 方式灌入记录旧 dataset 在此期间不受任何影响。重建期间的 live 写入在接触 Fuseki 之前先提交一条 mutation journal 记录并在共享 SQL fence 下路由因此新写入不会丢失在旧快照里。构建完成后执行 promotion把 journal 回放进已完成快照原子地校验最终 watermark 并切换服务指针。每个 Pod 按指针路由切换之后没有轮询延迟。promotion 还会在同一事务中标记 materialized inference rules 为 dirty以便其输出随之重建。切换前会对目标 dataset 做一次 compactionBlue/Green 运行在 promotion 前 compact 目标而不是在服务 dataset 上 compact保证 live writer 一直只用着旧 dataset。相关的资源边界文档明确列出mutation journal 上限为 256 MiB 或 100,000 条 mutation构建 worker 持有 120 秒的 dataset lease每 30 秒续租用于隔离已失联的 workerjournal 回放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 \ querySELECT (COUNT(*) AS ?n) WHERE { GRAPH ?g { ?s ?p ?o } } \ http://localhost:3030/openmetadata/sparql \ -H Accept: application/sparql-resultsjson注意 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_TOKENadmin-or-bot-jwt ./scripts/rdf-reindex-benchmark.shdocs/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 的 datasetsuccess-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenMetadata 如何启用 Blue/Green Rebuild 让 RDF 全量重建期间图谱保持可查询
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其配置项与含义如下配置项UI 名称 / 配置 id说明Recreate RDF Store /recreateIndex索引前清空 RDF store。Blue/Green Rebuild只有在该项开启时才生效Blue/Green Rebuild /blueGreenRebuild把重建构建到一个空闲 dataset运行成功后才切换为服务 dataset查询始终看到旧图谱而不是半重建的图谱。代价是磁盘上约需要两倍 dataset 大小Minimum Success Ratio /minSuccessRatio允许 Blue/Green 重建被提升为服务 dataset 之前索引成功记录必须达到的比例。低于该值时旧 dataset 继续服务本次运行标记为失败。默认0.95Entities /entities需要重建的实体类型列表留空表示索引所有受支持的实体触发方式有两条按需触发直接启动该应用的一次运行。按需运行会绕过与 search 重建互斥的 admission guard文档说明这是“operator intent wins”日志中会有告警。计划任务文档推荐的 RDF 重建排期是每周六 00:00 一次全量 recreatecron 为0 0 * * 6search 索引默认排在周日 00:30避免两个全量扫描同时压数据库。cron 触发的 RDF 重建如果撞上正在进行的 search 重建会每 60 秒重查、最多等待 30 分钟仍不结束就以STOPPED状态结束并等下一个计划窗口。运行期间图谱如何保持可查询开启后一次 Blue/Green 重建的执行路径是协调器选出空闲的交替 datasetopenmetadata_a或openmetadata_b把选定的 dataset、rebuild generation 和 payload budget 持久化到 job 上所有 worker 使用这些不可变值。构建目标被清空、重新加载 ontology然后以 insert-only 方式灌入记录旧 dataset 在此期间不受任何影响。重建期间的 live 写入在接触 Fuseki 之前先提交一条 mutation journal 记录并在共享 SQL fence 下路由因此新写入不会丢失在旧快照里。构建完成后执行 promotion把 journal 回放进已完成快照原子地校验最终 watermark 并切换服务指针。每个 Pod 按指针路由切换之后没有轮询延迟。promotion 还会在同一事务中标记 materialized inference rules 为 dirty以便其输出随之重建。切换前会对目标 dataset 做一次 compactionBlue/Green 运行在 promotion 前 compact 目标而不是在服务 dataset 上 compact保证 live writer 一直只用着旧 dataset。相关的资源边界文档明确列出mutation journal 上限为 256 MiB 或 100,000 条 mutation构建 worker 持有 120 秒的 dataset lease每 30 秒续租用于隔离已失联的 workerjournal 回放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 \ querySELECT (COUNT(*) AS ?n) WHERE { GRAPH ?g { ?s ?p ?o } } \ http://localhost:3030/openmetadata/sparql \ -H Accept: application/sparql-resultsjson注意 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_TOKENadmin-or-bot-jwt ./scripts/rdf-reindex-benchmark.shdocs/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 的 datasetsuccess-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考