企业官网建设流程全解析

OpenMetadata Fuseki 磁盘占用在重建后持续增长怎么排查

【免费下载链接】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 知识图谱（远端 Apache Jena Fuseki + TDB2 数据集，仓库自带的openmetadata-fuseki:6.2.0镜像，数据都落在容器内/fuseki-data卷上），会发现每次跑完 RDF 全量重建（recreateIndex/ blue-green rebuild）之后，数据卷的磁盘占用比上一次更大，甚至远大于按存活三元组数估算出来的值。docs/rdf-production-setup.md 明确说明：这是 TDB2 的存储模型和重建流程共同造成的——CLEAR ALL本身不回收磁盘，只有 compaction 才回收；重建过程中新旧数据集并存。该文档同时给出了可执行的排查路径：先估算合理容量上限，再核对 compaction 是否真的执行过，然后手动 compact、核对数据卷里各目录的占用，最后确认卷本身是否 undersize。

本文对应这条排查路径。适用环境：仓库提供的 Fuseki 镜像（docker/rdf-store/构建）、Docker Compose 或 Kubernetes 部署；排查只需要对 Fuseki 管理端点（默认3030端口）发 HTTP 请求，以及查看数据卷所在宿主路径。

排查起点：数据卷在哪里

先确认你盯的是正确的存储位置，两处部署的数据卷分别是：

• Docker Compose（RDF 本地栈）：卷名fuseki-tdb2-data，挂载到/fuseki-data，见 docker/development/docker-compose-fuseki.yml。
• Kubernetes：PVCfuseki-data-pvc，挂载到同一路径，见 docker/rdf-store/kubernetes/fuseki-deployment.yaml。

后续所有“磁盘占用”指这个卷（PVC）的用量，而不是宿主机其他盘。

第一步：估算“合理上限”，区分正常增长与异常增长

文档给出的容量基准：

• OpenMetadata 图谱的规划区间是每条三元组 150–250 字节（compaction 余量之前），并建议“对自己的 catalog 实际测量后再定卷大小”，这个每字节数只是粗略起点。
• 卷大小下限：启用 blue/green 重建时按至少3 datasets × live size × 2.5规划（两个完整数据集在盘上交替，且 TDB2 compaction 会在删除旧一代之前先构建一份替代数据集）；未启用 blue/green 时按live × 2.5覆盖 compaction 与 journal 余量。
• 文档同时提醒：一个未经 compaction、带有多次重建 churn 的存储，可以比存活三元组数量暗示的大小大一整个数量级——所以“比上次大”本身不等于异常，先和上限对比。

先量出存活三元组数（文档在升级 runbook 中用同一条查询验证数据存活，这里用于估算 live size）：

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

<password>替换为你的FUSEKI_ADMIN_PASSWORD实际值（开发栈默认admin，见 docker/development/docker-compose-fuseki.yml）。把条数乘 150–250 字节得到 live data 量级，再套上面的公式得到磁盘合理上限。如果实际占用明显低于上限，问题往往在“compaction 没执行成功”而不是无限增长；如果反复触碰上限，按 Kubernetes 清单 的注释扩容——注意该清单里写的是>= 2 datasets x live size x 2.5，而 docs/rdf-production-setup.md 对 blue/green 场景给出的是3 datasets × live size × 2.5，两者出处不同，blue/green 启用时以生产文档的更保守口径为准。

别忘了 live size 之外还有独立于 TDB2 的占用：每个数据集各有一个持久 Lucene 全文索引（lucene、lucene_a、lucene_b，索引rdfs:label、dcterms:description和 OpenMetadata 的name属性，见 docker/rdf-store/config.ttl），文档要求把这些索引计入磁盘容量规划并纳入备份。

第二步：核对 compaction 是否真的执行过

OpenMetadata 会在 recreate 运行清空数据集后、以及记录索引完成后各请求一次 Fuseki compaction；blue/green 运行在 promotion 前 compact 目标数据集，in-place 运行在报告完成后 compact。但文档明确：compaction 是 best-effort 的，索引运行即使磁盘回收失败也可能成功。因此“重建成功”不等于“磁盘被回收了”。

文档列出的磁盘增长成因有三类：小事务累积、compaction 失败或被跳过、以及 compaction 完成之前卷就已经写满。另外注意一个反直觉点：TDB2 在 insert-only 写入时也会复制索引页，清空并 compact 一个空目标不会回收其后续重建期间产生的废弃页——所以重建期间磁盘处于峰值是预期行为，回收要等 compaction 跑完。

用 Fuseki 管理端点核对任务状态（<password>同上替换）：

# compaction 等异步管理任务（active 与已完成） curl -s -u admin:<password> 'http://localhost:3030/$/tasks' # 数据集与操作统计 curl -s -u admin:<password> 'http://localhost:3030/$/stats'

/$/tasks用来判断上次重建触发的 compaction 是否在执行中、已完成还是缺失。/$/metrics是 Prometheus 格式指标（生产应抓取；自带shiro.ini中该端点需要 basic auth，用专门的 Fuseki 凭据配置抓取）。OpenMetadata 侧文档同样要求把“persistent-volume usage”列入监控项。

第三步：手动触发 compaction 并验证回收

确认任务缺失或任务完成后磁盘未回落时，手动 compact（文档原文命令，<password>替换为实际管理员密码）：

curl -u admin:<password> -X POST \ 'http://localhost:3030/$/compact/openmetadata?deleteOld=true'

执行前必须满足的前提：数据卷要同时放得下旧数据集和替代数据集——TDB2 是先构建替代副本、再删旧一代。卷已接近写满时 compact 只会失败或加剧问题，此时先扩容或清理，不要反复重试。

两个使用注意点：

• Fuseki 返回一个异步任务标识符，进度回/$/tasks查；不要把它当成同步操作。
• 示例 URL 中的openmetadata是三个 assembler 数据集之一（另两个是openmetadata_a/openmetadata_b）；blue/green 场景下先确认 active 指针（SQL 中的rdf_active_dataset行）指向哪个数据集，再对对应数据集名发 compact 请求。

验证方式：compact 任务完成后，数据卷占用应明显回落。文档给出的测量参考（docs/rdf-scale-validation.md，20 万表 / 200 万血缘边目录）：重建期间 Fuseki 分配磁盘峰值 50.731 GiB，本地重建加 compaction 之后为 10.665 GiB——这是该工作负载的实测值，不是你应该达到的固定目标，但量级关系（峰值可达压缩后数倍）可以用来判断你的占用是否落在预期范围内。

第四步：确认数据卷里到底是谁占着空间

/fuseki-data下的构成（数据集与索引声明见 docker/rdf-store/config.ttl）：

文档给出的三个与“持续增长”直接相关的事实：

1. blue/green promotion 之后，上一个数据集会保留到下一次重建复用它；在运维手动退役原始openmetadata目录之前，要预留最多三份数据集副本加 compaction 余量的空间。
2. 通过 Fuseki admin API 删除数据集只移除注册，不删除 TDB2 文件——删了数据集但磁盘不降，是设计使然。
3. 空闲数据集的磁盘要彻底回收，文档给出的操作是：停止 Fuseki，然后移除非 active 指针那个数据集的{FUSEKI_BASE}/databases/<dataset>_a|_b目录。这是破坏性操作：它永久删除该数据集的存储文件，只能对确认非 active 的数据集执行，且必须在 Fuseki 停止后进行；执行前用rdf_active_datasetSQL 行核对 active 指针，并保留该目录的备份。

卷本身 undersize 时的处理

如果 compaction 正常、目录构成也正常，但占用反复逼近上限，就是卷规划问题：

• 自带 K8s 清单中的10GiPVC 是开发默认值，文档明确说不是生产建议；生产按第一步的公式规划，并要求 SSD 级存储——TDB2 写事务受 journal 限制，网络 HDD 存储类是慢写入的常见原因。
• 以文档的 20 万表目录为测量示例：应按观测到的峰值（50.731 GiB）加数据库存储加空余 headroom 规划，而不是按压缩后的图大小规划；该次运行全程保留了至少 17.913 GiB 的宿主空闲磁盘。
• 扩容后重跑一次重建并观察 compact 后的稳态占用，即可确认规划值是否足够。

排查边界

• compaction 失败与“持续增长”互为因果时（卷在 compaction 完成前写满），必须先解决空间问题，compaction 才可能成功；文档没有提供“先删队列行让状态变绿”之类的捷径——对应的是 SQL 队列场景，但对磁盘同理：不要绕过 compaction 直接清文件。
• 重建运行仍在进行时磁盘处于峰值属正常，先等运行结束再判断。
• 本文不覆盖CLEAR ALL与启动布局问题（错误的tdb2:location会静默启动一个空存储）等场景，那属于数据丢失排查，见 docs/rdf-production-setup.md 的升级 runbook。

下一步

容量调整后，仓库提供两个脚本对真实栈做核对：

# 冒烟测试 RDF 服务，任一检查失败则非零退出 ./docker/docker-compose-quickstart/test-rdf-services.sh # 测量一次完整重建：wall-clock、records/second、失败数、重建后的三元组数 OM_TOKEN=<admin-or-bot-jwt> ./scripts/rdf-reindex-benchmark.sh

OM_TOKEN替换为你的 admin 或 bot JWT。前者确认服务可用，后者在重建后给出三元组总数，可与第一步的 COUNT 查询交叉验证数据完整性。

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