OpenMetadata 如何启用物化推理并调度 RdfInferenceApp

OpenMetadata 如何启用物化推理并调度 RdfInferenceApp

【免费下载链接】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 实例已经接入了 Apache Jena Fuseki 图存储，但推理结果还停留在“查询时临时推导”的阶段，就需要启用物化推理（materialized inference）：让推理规则的输出持久化写入 Fuseki 中每个规则独立的命名图（named graph），并由RdfInferenceApp这个内置应用按调度周期把“变脏”的规则重新物化。完成本文后，你会得到一条可核对的路径：开启RDF_MATERIALIZED_INFERENCE_ENABLED→ 保持 asserted RDF 图重建最新 → 创建/校验推理规则 → 让RdfInferenceApp按 cron 调度或手动触发执行 → 通过推理状态 API 核对物化结果。

以下内容基于仓库内 生产环境 Fuseki 部署文档 的 “Inference” 与 “Scheduling” 章节、RDF 本地开发指南、API 参考 以及应用定义文件编写。

准备条件：带 Fuseki 的 RDF 环境

物化推理的前提是 RDF 本身已启用且 Fuseki 可用。本地开发最短路径是使用带 Fuseki 的启动脚本（默认后端为 MySQL）：

./docker/run_local_docker_rdf.sh -d mysql # PostgreSQL 后端： ./docker/run_local_docker_rdf.sh -d postgresql

该启动方式会同时拉起 OpenMetadata、后端数据库、搜索服务和 Fuseki（端口 3030，数据集openmetadata，管理口令admin）。如果只想单独起 Fuseki（例如 OpenMetadata 服务从 IDE 直接运行），文档给出的是：

docker compose -f docker/development/docker-compose.yml -f docker/development/docker-compose-fuseki.yml up -d fuseki

而后端为 PostgreSQL 时把docker-compose.yml换成docker-compose-postgres.yml。此时服务进程需要设置RDF_ENABLED=true等 RDF 环境变量（完整清单见 本地开发指南 的 “Configure IntelliJ Run Configuration” 一节），服务器配置模板位于 conf/openmetadata.yaml。

启动后按文档做两项验证：

# Fuseki 存活 curl -s http://localhost:3030/$/ping # 确认 OpenMetadata 侧 RDF 已启用 curl http://localhost:8585/api/v1/rdf/status # 文档给出的预期响应：{"enabled": true}

启用物化推理

生产文档对这一功能只给出一句话定位：“Materialized inference is the production path.” 对应操作是设置服务端环境变量：

RDF_MATERIALIZED_INFERENCE_ENABLED=true

在 conf/openmetadata.yaml 中，该项由materializedInferenceEnabled: ${RDF_MATERIALIZED_INFERENCE_ENABLED:-false}注入，默认false。启用后的行为（引自 生产部署文档）：

• 规则写入 Fuseki 中按规则持久化的命名图，而不是在 OpenMetadata JVM 内临时推导；
• 推理状态 API 会暴露每条规则的 dirty 状态、上次物化时间、三元组数量和错误详情。

注意区分另一条遗留路径：RDF_INFERENCE_ENABLED控制的是进程内（in-process）全图推理，受RDF_MAX_IN_MEMORY_INFERENCE_TRIPLES（默认100000）边界限制，文档明确建议保持默认边界，请求级遍历应改用 Fuseki 内的 SPARQL 1.1 property path 查询。物化推理与这两者互不替代。

保持 asserted RDF 重建最新

文档要求“keep the asserted RDF rebuild current”，即物化推理依赖底层 asserted 图是最新的。对应两个操作：

1. 全量重建。触发RdfIndexApp（本地开发指南 给出的示例命令，<admin-token>替换为管理账号 JWT）：

   curl -X POST \ -H "Authorization: Bearer <admin-token>" \ -H "Content-Type: application/json" \ -d '{"entities": [], "recreateIndex": true, "batchSize": 100}' \ http://localhost:8585/api/v1/apps/trigger/RdfIndexApp

2. 调度重建。文档推荐 RDF 重建的调度是周六午夜：

   RDF: 0 0 * * 6 Search: 30 0 * * 0

   两个任务分开是为了避免同时扫描元数据库互相拖垮；RDF 重建触发还带有跨应用准入保护，会检测是否有活跃的搜索重建并最多等待 30 分钟。

与推理相关的一个关键联动：当启用 Blue/Green Rebuild 后，数据集切换（promotion）会在同一事务里把所有已物化的推理规则标记为 dirty，使它们的输出可以随后被重建。也就是说，走蓝绿重建升级/重跑索引后，推理结果需要等RdfInferenceApp再跑一轮才是新的。

创建并校验推理规则

物化动作的操作对象是 durable 推理规则。API 参考 中 rdf 分组列出：

方法	路径	用途（引自 API 参考）
PUT	/v1/rdf/rules/{name}	Create or update an inference rule
POST	/v1/rdf/rules/validate	Validate a candidate inference rule without persisting it
GET	/v1/rdf/rules	List durable inference rules and materialization state
POST	/v1/rdf/rules/materialize	Materialize dirty inference rules inside Fuseki
DELETE	/v1/rdf/rules/{name}	Delete a custom inference rule and its materialized graph

建议先用POST /v1/rdf/rules/validate校验候选规则，再PUT /v1/rdf/rules/{name}持久化。规则一旦落库，其输出将由RdfInferenceApp物化到 Fuseki，而不是每次查询时重新计算。

调度 RdfInferenceApp

RdfInferenceApp是仓库自带的内部应用，定义见 应用种子数据 与应用市场定义：

• 显示名RDF Inference Materialization，实现类org.openmetadata.service.apps.bundles.rdf.RdfInferenceApp；
• 默认调度cronExpression: "*/5 * * * *"（每 5 分钟），scheduleType: "ScheduledOrManual"，即既可按调度运行也可手动触发；
• 应用配置项含force（默认false，见appConfiguration）；实现上还支持按ruleName只物化指定规则（见 RdfInferenceApp.java）；
• supportsInterrupt: false，运行中的实例不支持中断。

手动触发使用通用的应用触发接口（API 参考：POST /v1/apps/trigger/{name}，RdfIndexApp的触发示例见 本地开发指南）：

curl -X POST \ -H "Authorization: Bearer <admin-token>" \ http://localhost:8585/api/v1/apps/trigger/RdfInferenceApp

需要说明：默认force=false时应用只处理 dirty 规则；若服务端未启用物化推理（RDF_MATERIALIZED_INFERENCE_ENABLED未开启），应用执行结果为空（0 条规则），不会报错也不会产生物化——这是 应用实现 中的显式分支。

验证物化结果

按从近到远的顺序核对：

1. 应用运行记录。每次运行会写入 AppRunRecord：全部规则成功为COMPLETED，否则为FAILED并带 “N inference rule materializations failed” 的失败上下文（见 RdfInferenceApp.java 的completeRun/failRun）。

2. 推理状态 API。GET /v1/rdf/rules列出规则及其物化状态；生产文档明确该状态包括 dirty 标记、上次物化时间、三元组数量和错误详情。调度正常时，规则应不再停留在 dirty。

3. 手动兜底。若某规则长期未物化，可直接POST /v1/rdf/rules/materialize在 Fuseki 内物化所有 dirty 规则，绕开应用调度。

4. 消费侧验证。用带推理的完整血缘接口确认物化三元组可被查询：

   curl -s -H "Authorization: Bearer <token>" \ "http://localhost:8585/api/v1/rdf/inference/lineage/<entityId>"

   该接口（GET /v1/rdf/inference/lineage/{entityId}）用于获取含推理的完整血缘。若返回结果只含 asserted 关系而缺少预期的推导关系，回到第 1、2 步检查运行记录与 dirty 状态。

5. Fuseki 侧佐证。规则输出位于 Fuseki 的按规则命名图中；可结合 Fuseki 管理端点（/$/datasets等，见 生产部署文档 的 “Monitoring and failure diagnosis”）确认数据集与写入正常。

限制与注意事项

• RDF_ENABLED与RDF_MATERIALIZED_INFERENCE_ENABLED都是服务端读取的配置（默认均为false），改的是 conf/openmetadata.yaml 对应的环境变量注入，需要落实到 OpenMetadata 服务进程；只改 Fuseki 侧不会启用。
• 蓝绿重建切换后规则被标记为 dirty，物化输出要等下一次RdfInferenceApp运行才更新；升级场景下按 生产文档 要求，先应用 native 2.0.2 迁移并升级全部 pod。
• 物化推理是文档指定的生产路径；进程内推理（RDF_INFERENCE_ENABLED）是受三元组数边界保护的遗留路径，不要把二者当同一开关使用。
• 调度侧，RdfInferenceApp的每 5 分钟默认 cron 来自应用种子数据；如果你调整 RDF 重建窗口（如文档推荐的周六午夜重建），推理应用的调度可以按同样方式在应用配置里自定义——种子数据本身只声明了scheduleType: "ScheduledOrManual"与上述默认值，没有为推理应用指定额外的推荐时刻。

【免费下载链接】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