ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

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

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_ENABLEDtrue等 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_ENABLEDtrue在 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 图是最新的。对应两个操作全量重建。触发RdfIndexApp本地开发指南 给出的示例命令admin-token替换为管理账号 JWTcurl -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调度重建。文档推荐 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 rulePOST/v1/rdf/rules/validateValidate a candidate inference rule without persisting itGET/v1/rdf/rulesList durable inference rules and materialization statePOST/v1/rdf/rules/materializeMaterialize dirty inference rules inside FusekiDELETE/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而不是每次查询时重新计算。调度 RdfInferenceAppRdfInferenceApp是仓库自带的内部应用定义见 应用种子数据 与应用市场定义显示名RDF Inference Materialization实现类org.openmetadata.service.apps.bundles.rdf.RdfInferenceApp默认调度cronExpression: */5 * * * *每 5 分钟scheduleType: ScheduledOrManual即既可按调度运行也可手动触发应用配置项含force默认false见appConfiguration实现上还支持按ruleName只物化指定规则见 RdfInferenceApp.javasupportsInterrupt: false运行中的实例不支持中断。手动触发使用通用的应用触发接口API 参考POST /v1/apps/trigger/{name}RdfIndexApp的触发示例见 本地开发指南curl -X POST \ -H Authorization: Bearer admin-token \ http://localhost:8585/api/v1/apps/trigger/RdfInferenceApp需要说明默认forcefalse时应用只处理 dirty 规则若服务端未启用物化推理RDF_MATERIALIZED_INFERENCE_ENABLED未开启应用执行结果为空0 条规则不会报错也不会产生物化——这是 应用实现 中的显式分支。验证物化结果按从近到远的顺序核对应用运行记录。每次运行会写入 AppRunRecord全部规则成功为COMPLETED否则为FAILED并带 “N inference rule materializations failed” 的失败上下文见 RdfInferenceApp.java 的completeRun/failRun。推理状态 API。GET /v1/rdf/rules列出规则及其物化状态生产文档明确该状态包括 dirty 标记、上次物化时间、三元组数量和错误详情。调度正常时规则应不再停留在 dirty。手动兜底。若某规则长期未物化可直接POST /v1/rdf/rules/materialize在 Fuseki 内物化所有 dirty 规则绕开应用调度。消费侧验证。用带推理的完整血缘接口确认物化三元组可被查询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 状态。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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表