HPC数据FAIR化实战：基于本体与混合评估的语义增强路径

weixin_30267785

631人浏览 · 2026-05-22 16:55:35

weixin_30267785 · 2026-05-22 16:55:35 发布

1. 项目概述：当HPC数据集遇见FAIR原则

在咱们高性能计算这个圈子里，数据就是燃料。无论是训练一个预测计算负载的AI模型，还是分析一套模拟宇宙演化的仿真结果，数据的质量直接决定了研究的成败。但不知道你有没有遇到过这样的窘境：从某个合作者那里拿到一个数据集，压缩包名字叫 final_data_v2.zip ，里面一堆CSV文件，列名是 col1 、 col2 ，单位不明，采集条件不详，甚至连这个数据是来自CPU还是GPU的哪个测试都搞不清楚。想用？得先花上几天甚至几周时间去“考古”和“破译”。这就是典型的数据“黑箱”，它不可查找、难以理解、无法互操作、更别提重用了。

这正是FAIR原则要解决的痛点。FAIR不是一句空泛的口号，它是一套可执行、可评估的工程框架，旨在让数据像乐高积木一样，可以被任何人（和机器）轻松找到、理解、拼接和使用。对于HPC领域，数据规模大、来源复杂、生命周期长，FAIR化不是“锦上添花”，而是“雪中送炭”，是释放数据潜在价值、推动科学发现可重复性的必经之路。

然而，实现FAIR化绝非易事。它不是一个简单的“导出为CSV并上传”的动作。核心挑战在于 元数据 ——描述数据的数据。传统的元数据往往是自由文本，或者简单的键值对，缺乏统一的语义标准，导致机器无法理解。比如，一个字段叫“内存”，它的值“8”是指8GB、8MB还是8个内存通道？没有明确的语义标注，AI模型或分析脚本就无法正确解析。这就需要引入本体和 语义网技术 。

简单来说，你可以把本体想象成一张为特定领域（比如HPC）精心绘制的地图。这张地图上，所有重要的“地点”（概念）都被明确定义，比如“GPU内核”、“主机到设备传输”、“计算节点”。地图上还清晰地标明了“道路”（关系），比如“发生在...上”、“传输到...”、“属于...”。当我们用这张地图的术语（即本体中的类和属性）来标注我们的数据时，数据就获得了机器可读的“地址”和“导航信息”。而 JSON-LD ，就是一种非常友好的格式，它让我们能用熟悉的JSON语法，为数据贴上这些语义标签，从而将普通数据升级为“关联数据”，使其能够被网络上的其他智能体（如评估工具、搜索引擎）理解和链接。

本文要分享的，正是一个将这套理论落地的完整实践。我们将聚焦于一个具体的HPC数据集（例如一个用于预测GPU内存页错误的决策树模型及其训练数据），详细拆解如何运用HPC本体对其进行语义标注，并采用一种“自动化工具扫描+人工专家复核”的混合评估方法，一步步地将这个数据集的FAIR成熟度从及格线提升到优秀水平。无论你是数据生产者、管理者还是使用者，这套方法论都能为你提供一条清晰、可操作的FAIR化路径。

2. 核心思路：混合评估与语义增强的双轮驱动

为什么是“混合评估”？因为无论是纯自动化工具还是纯人工审核，在FAIR评估这件事上都有其明显的短板。纯自动化工具，比如F-UJI、FAIRshake，速度快、标准统一，能批量处理。但它们本质上是“规则检查器”，其评估能力完全依赖于预设的规则集和对数据存储平台（如Zenodo、Figshare）API的支持程度。这就导致了两个问题：一是 覆盖不全 ，很多需要领域知识判断的细微指标（如元数据是否“充分”描述了技术细节）无法被准确评估；二是**“误伤”或“漏报”**，工具可能因为平台API的局限性（比如Zenodo暂不支持嵌入特定的语义资源命名空间）而判定某项指标失败，但实际上数据本身已经符合FAIR原则的精神。

反过来，纯人工评估虽然灵活、深入，能够结合领域知识做出精准判断，但效率极低、主观性强、难以规模化，尤其不适合处理海量数据。因此，我们的核心思路是让机器和人工各司其职，形成闭环：先用自动化工具进行快速、全面的初筛，定位出明显的“硬伤”和工具能明确判断的问题；然后由领域专家对工具给出的“未通过”或“部分通过”项进行深度复核和解释，修正工具的误判，并补充工具无法评估的软性指标。

那么，如何从根本上提升数据质量，以通过更严格的评估呢？答案就是 基于本体的语义增强 。我们选择的武器是 HPC本体 。这个本体并非凭空创造，它是对HPC领域内核心实体、属性及其关系的标准化定义。例如，它明确定义了 hpc:hostToDeviceTransferSize 这个属性，用来表示从主机内存到设备内存的数据传输量，并且可以关联到QUDT（计量单位本体）来指明其单位是 KiloBYTE 。通过用这些标准化的术语来标注我们的数据，我们实际上是在为数据构建一个机器可理解的“用户手册”。

这套“混合评估+语义增强”的方法论，其优势在于它不仅是评估，更是 引导改进 。自动化评估报告会像一份“体检报告”，指出数据在FAIR各项指标上的得分和短板。我们根据这份报告，有针对性地使用HPC本体对元数据进行增补、修正和语义化升级。然后再次评估，验证改进效果，如此迭代，直至达到满意的FAIR成熟度。这个过程，将原本模糊的“让数据更FAIR”的目标，拆解成了一个个具体、可执行的技术任务。

3. 实操准备：工具、数据与本体的选择

在开始动手之前，我们需要准备好“弹药”。这套实践不依赖于某个特定的、封闭的商业平台，而是基于一系列开放标准和工具，具有很高的可移植性。

3.1 评估工具选型：F-UJI

在自动化评估侧，我们选择 F-UJI 工具。它是一个开源命令行工具/API服务，实现了RDA（研究数据联盟）FAIR数据成熟度模型中的核心指标。选择它的理由很充分：首先，它 权威且标准统一 ，直接对标国际社区共识的评估模型，结果有公信力；其次，它 支持对通过URL可访问的数据对象进行评估 ，这非常契合我们通常将数据发布在仓储平台（如Zenodo）的场景；最后，它提供 结构化的JSON输出 ，便于我们解析和集成到后续的改进流程中。你可以在GitHub上找到它的源码和Docker镜像，部署和使用起来相对 straightforward。

3.2 数据仓储平台：Zenodo

数据需要有个“家”，这个家本身最好也能支持FAIR。我们推荐使用 Zenodo 。它由CERN运营，提供永久标识符（DOI），支持丰富的元数据字段（作者、机构、许可证、关键词等），并且与GitHub等开发平台有很好的集成，可以自动为每次软件发布创建存档。虽然它在支持某些高级语义特性（如嵌入自定义RDF）上还有局限，但其在持久性、通用元数据支持和社区认可度方面的优势，使其成为科学数据共享的一个可靠起点。我们的案例数据就将托管在Zenodo上，并获取一个DOI。

3.3 语义增强核心：HPC本体

这是本次实践的技术核心。我们需要获取或构建一个适用于自己领域的本体。幸运的是，对于HPC领域，已经有研究团队提出了 HPC Ontology 。这个本体定义了HPC工作负载、硬件资源、性能指标、AI模型等相关的一系列概念。例如，它包含了 hpc:Benchmark （基准测试程序）、 hpc:CodeVariant （代码变体）、 hpc:GPUPageFault （GPU页错误）等类。我们的任务就是学习这个本体的结构，然后将我们数据集中的各项信息，映射到本体中对应的类和属性上。

3.4 数据格式：JSON-LD

我们需要一种格式来承载经过本体标注的数据。 JSON-LD 是理想选择。它完全兼容JSON，任何能解析JSON的程序都能读取它；同时，通过 @context 字段，它能将普通的JSON键值对关联到本体中的特定语义（IRI）。这意味着，我们既可以用Python的 json 库轻松处理它，又可以让语义网工具理解其深层含义。它是在保持实用性和拥抱语义网标准之间一个完美的平衡点。

准备好这些之后，我们的工作流就清晰了：1) 将原始数据集（如CSV、代码、模型文件）打包上传至Zenodo，获取DOI；2) 使用F-UJI对该DOI进行首次自动化FAIR评估，得到基线分数；3) 分析评估报告，识别短板；4) 使用HPC本体创建该数据集的、机器可读的丰富元数据，以JSON-LD格式发布；5) 将这份JSON-LD元数据与原始数据关联（例如，作为附加文件上传至Zenodo记录，或通过 seeAlso 链接）；6) 再次使用F-UJI评估，并结合人工判断，得到最终FAIR成熟度。

4. 实战演练：从“原始数据”到“FAIR数据”的蜕变

让我们跟随一个具体的例子，看看每一步是如何操作的。假设我们有一个名为“XPlacer”的数据集，它包含了一个用于预测GPU统一内存页面错误行为的决策树模型，以及生成该模型的训练数据（来自Rodinia基准测试套件）。

4.1 初始状态评估与问题诊断

首先，我们将XPlacer数据集（代码、数据文件、简易说明文档）打包，上传到Zenodo，设置好基本的描述性元数据（标题、作者、描述、许可证CC-BY 4.0等），并获得一个DOI，例如 10.5281/zenodo.1234567 。

接着，我们运行F-UJI对这个DOI进行首次评估：

java -jar fuji.jar --url https://doi.org/10.5281/zenodo.1234567 --output initial_fairness_report.json

评估结果（对应原文中的Fig. 4）会显示一个总体FAIR分数（可能只有50-60%）和每个指标的成熟度级别（初始、中级、高级）。报告会明确指出许多问题，例如：

F1（可查找） ：元数据中可能缺少明确的数据类型（ dataset ）和关键词。
A1（可访问） ：数据可通过DOI访问，这一项通常能通过。
I1（可互操作） ：这是重灾区。工具会报告元数据中 没有使用来自已知语义资源（如schema.org, Dublin Core）的命名空间 。因为Zenodo的元数据表单是自由文本或有限下拉菜单，无法直接嵌入RDF命名空间声明。
R1（可重用） ：元数据中 缺乏机器可读的、详细的溯源信息 （谁、在什么时候、如何创建了该数据）。同时，对于数据文件本身的技术属性（如文件格式、大小、编码）描述不足。

这份报告就是我们行动的“作战地图”。它告诉我们，要想提升FAIR分数，主攻方向是 “I”（互操作）和“R”（重用） ，而关键突破口在于 提供机器可理解的、丰富的语义化元数据 。

4.2 基于HPC本体的语义标注实践

针对评估发现的问题，我们开始为XPlacer数据集构建一份独立的、丰富的语义化元数据文档。我们选择使用HPC本体作为词汇表。

首先，我们需要定义JSON-LD的上下文（ @context ），将我们要用的缩写词关联到完整的本体IRI上：

{
  "@context": {
    "hpc": "http://example.org/hpc-ontology#",
    "prov": "http://www.w3.org/ns/prov#",
    "dc": "http://purl.org/dc/elements/1.1/",
    "schema": "https://schema.org/",
    "qudt": "http://qudt.org/schema/qudt/"
  },
  ...
}

这里， hpc 指向我们使用的HPC本体， prov 指向溯源本体， dc 指向都柏林核心， schema 指向schema.org， qudt 指向计量单位本体。

接着，我们开始描述数据集本身：

{
  "@id": "https://doi.org/10.5281/zenodo.1234567",
  "@type": ["schema:Dataset", "hpc:BenchmarkDataset"],
  "dc:title": "XPlacer: A Dataset for GPU Unified Memory Page Fault Prediction",
  "dc:creator": "HPC Research Team",
  "dc:description": "This dataset contains performance traces from Rodinia benchmarks and a decision tree model for predicting page faults under GPU Unified Memory.",
  "dc:license": "http://creativecommons.org/licenses/by/4.0/",
  "dc:created": "2023-10-27",
  "schema:distribution": {
    "@type": "schema:DataDownload",
    "schema:contentUrl": "https://zenodo.org/record/1234567/files/xplacer_data.zip",
    "schema:encodingFormat": "application/zip"
  }
}

这一步解决了F1（可查找）的部分问题，我们明确标注了资源类型是 schema:Dataset 和更具体的 hpc:BenchmarkDataset 。

然后，我们深入到数据内部，描述一条具体的性能追踪记录（对应原文Listing 1）：

{
  "@id": "http://example.org/test.csv#L1",
  "@type": "hpc:TableRow",
  "hpc:codeVariant": "111100",
  "hpc:allocatedDataSize": 8000000,
  "hpc:arrayID": "0",
  "hpc:commandLineOption": "graph1MW.6",
  "hpc:gpuPageFault": 5,
  "hpc:hostToDeviceTransferSize": {
    "@id": "_:Nbdd222a0d12a483d8f1a4cef274f18fc"
  }
},
{
  "@id": "_:Nbdd222a0d12a483d8f1a4cef274f18fc",
  "@type": "http://qudt.org/schema/qudt/QuantityValue",
  "http://qudt.org/schema/qudt/unit": {
    "@id": "http://qudt.org/vocab/unit/KiloBYTE"
  },
  "http://qudt.org/schema/qudt/value": {
    "@type": "http://www.w3.org/2001/XMLSchema#decimal",
    "@value": "7872.0"
  }
}

这段标注极具价值。它不仅仅记录了“主机到设备传输大小是7872”，而是精确地指出：这是一个 QuantityValue （量值），其数值是7872.0，单位是千字节（KiloBYTE）。机器读到这个，能毫无歧义地理解其含义。这直接提升了数据的 互操作性（I） 。

4.3 嵌入机器可读的溯源信息

针对“R1.2-01M：提供机器可读的溯源信息”这一要求，我们使用PROV-O本体来记录数据生成过程：

{
  "@id": "http://example.org/activity/training",
  "@type": "prov:Activity",
  "prov:startedAtTime": "2023-10-26T09:00:00Z",
  "prov:endedAtTime": "2023-10-26T12:00:00Z",
  "prov:used": {
    "@id": "http://example.org/rodinia-traces"
  },
  "prov:wasAssociatedWith": {
    "@id": "http://example.org/agent/script"
  },
  "prov:generated": {
    "@id": "http://example.org/model/decision_tree"
  }
}
{
  "@id": "http://example.org/agent/script",
  "@type": "prov:SoftwareAgent",
  "dc:title": "XPlacer Model Training Script (train.py)"
}

这里，我们定义了一个名为 training 的 Activity （活动），它使用了Rodinia追踪数据，由一个训练脚本（ SoftwareAgent ）执行，并生成了决策树模型。这样，数据的来龙去脉就被清晰地、机器可读地记录了下来。

4.4 关联与发布语义化元数据

现在，我们有了这份完整的JSON-LD元数据文件（例如 xplacer_metadata.jsonld ）。如何让它与原始数据关联呢？有两种主要方式：

作为附加文件上传 ：将 xplacer_metadata.jsonld 文件上传到Zenodo的同一记录中，作为数据集的一个组成部分。
通过链接关联 ：在Zenodo记录的元数据描述中，添加一个指向该JSON-LD文件稳定URL的链接（例如，使用 rdfs:seeAlso 关系）。虽然Zenodo界面可能不直接解析它，但F-UJI这样的评估工具会主动抓取和解析这个链接。

注意：这里有一个实践中的关键点。Zenodo等通用仓储平台目前对嵌入自定义RDFa或JSON-LD的支持有限。因此，我们采取“曲线救国”策略： 将符合FAIR原则的、丰富的语义化元数据作为独立资源创建和发布，并通过明确的链接使其与主数据对象关联 。评估工具能够识别这种关联并据此进行评估。

完成以上所有语义增强步骤后，我们再次运行F-UJI进行评估。这一次，评估工具不仅能读到Zenodo提供的基础元数据，还能通过我们提供的链接，获取到那份富含语义的JSON-LD文件。结果（对应原文Fig. 5）显示，FAIR总分从初始的较低水平提升到了 83.0% 。更重要的是，在“可互操作（I）”和“可重用（R）”的多个细分指标上，成熟度都达到了“高级”。

5. 混合评估中的关键问题与人工裁决

自动化工具很棒，但它并非万能。在我们的实践中，就遇到了几处需要人工专家介入进行裁决的情况，这也是“混合评估”中“混合”二字的精髓所在。

5.1 工具误判：平台限制 vs. 数据本质

F-UJI报告指出，指标 “FsF-I1-02M：要求对象的元数据中包含已知语义资源的命名空间” 未满足。工具的逻辑是：它检查数据宿主平台（Zenodo）提供的元数据中是否直接包含了如 schema.org 这样的命名空间声明。由于Zenodo当前的表单界面不支持用户直接插入此类RDF声明，因此工具判定失败。

人工裁决 ：我们检查了自己创建的JSON-LD文件，其中明确通过 @context 包含了 schema 、 dc 、 prov 等命名空间。这份文件通过 seeAlso 链接与数据关联，是可被机器访问的独立元数据资源。因此， 从数据对象本身来看，它已经满足了“元数据包含已知语义资源命名空间”的要求 。工具的失败判定是由于其评估逻辑过度依赖于宿主平台API的返回结果，而未能充分考虑到通过关联链接提供的扩展元数据。我们将其手动标记为“通过”。

5.2 实现局限：工具与平台的双重约束

另一个指标 “FsF-R1-01MD：要求提供数据文件技术属性的元数据” 被F-UJI报告为“部分满足”。经过调查，我们发现这背后有双重原因：一方面，F-UJI工具可能期望从平台API的某个特定字段获取文件格式、大小、创建时间等详细信息；另一方面，Zenodo的API在返回文件级别的技术元数据时可能不够精细或完整。

人工裁决 ：在我们的JSON-LD元数据中，我们使用 schema:encodingFormat 和 schema:contentSize 等属性明确描述了数据文件的格式（ZIP）和大小。同时，原始数据包内的文件也自有其属性。因此， 数据文件的技术属性是存在的，并且是机器可读的 。此处的“部分满足”更多是工具实现与平台API交互的缝隙所致。我们结合自身提供的语义元数据，判定该指标为“完全满足”。

5.3 语义深度与社区标准

评估也揭示了一些更深层次的问题，这指向了未来努力的方向。例如，在“可互操作（I）”方面，指标 “RDA-I3-01D/RDA-I3-02D：数据包含（合格的）对其他数据的引用” 得分较低。我们的HPC本体虽然描述了数据自身的属性，但尚未系统性地建立与外部标准数据集、相关论文或其他权威资源的关联。

分析与对策 ：这并非错误，而是体现了FAIR化的不同阶段。我们将其标记为“实施中”。下一步，我们可以在本体中增加诸如 cito:citesAsDataSource （引用作为数据源）等属性，将XPlacer数据集与Rodinia基准测试套件的官方描述、相关研究论文的DOI进行关联。这需要本体本身的进化，也是我们持续改进HPC本体的动力。

实操心得 ：混合评估的核心价值在于， 自动化工具告诉我们“哪里可能有问题”，而人工智慧判断“这是否真的是问题，以及问题的根源是什么” 。永远不要盲目相信工具的初始评分。务必仔细阅读评估报告的细节，理解每一条失败或警告背后的原因。很多时候，你需要扮演一个“翻译官”和“仲裁者”的角色，在工具的机械规则和数据的实际语义内涵之间架起桥梁。记录下这些裁决理由，本身也是宝贵的元数据，可供其他评估者参考。

6. 总结与展望：构建HPC领域的FAIR数据生态

通过这个完整的案例，我们实践了一条从原始HPC数据集出发，通过 语义标注（HPC本体+JSON-LD） 和 混合评估（F-UJI自动化+人工复核） 将其系统化提升为FAIR数据的具体路径。最终83%的FAIR分数不仅是一个数字，更代表了该数据集在可发现性、可访问性、尤其是机器可理解的互操作性和清晰授权的可重用性上达到了一个较高的成熟度。

回顾整个过程，有几点关键经验值得分享：

本体是桥梁 ：选择一个或构建一个适合你领域的本体，是将人类知识转化为机器可操作语义的关键。HPC本体是一个良好的起点，但你可能需要根据具体子领域（如计算流体力学、分子动力学）进行扩展。
JSON-LD是实用载体 ：它降低了语义网技术的使用门槛。从输出简单的JSON开始，逐步添加 @context 和 @type ，你会发现为数据增加语义层并没有想象中那么复杂。
评估是为了改进 ：不要害怕初始的低分。FAIR评估报告是一份最好的“待办事项清单”。它精准地指出了元数据的薄弱环节，让改进工作有的放矢。
混合策略是必须 ：完全依赖自动化评估在现阶段不现实，尤其是在涉及领域知识和复杂语义判断时。人工的洞察力不可或缺。

当然，这项工作远未结束。HPC本体本身还需要不断完善，以提供更丰富的、指向其他标准资源的“合格引用”。评估流程也可以进一步优化，例如将一些常见的人工裁决规则（如“如果存在独立的、符合要求的JSON-LD文件，则视指标I1-02M为通过”）脚本化，融入自动化评估的前后处理环节。

展望未来，更大的挑战和机遇在于 AI模型的FAIR化 。一个训练好的模型文件（如PyTorch的 .pt 文件）本身也是一个“数据黑箱”。它的架构、超参数、训练数据分布、性能指标等，都需要用丰富的、机器可读的元数据来描述。我们可以借鉴本文的方法，为ML模型定义专用的元数据模式（或扩展HPC本体），描述其 hasHyperParameter 、 trainedOn 、 hasAccuracy 等属性，并将这些元数据与模型文件一同发布。最终，我们的目标是构建一个从FAIR数据到FAIR模型，再到FAIR工作流的完整可信计算链条，让高性能计算领域的每一次实验、每一份数据、每一个模型都能被更好地理解、重复和构建 upon，真正驱动科学发现的加速。这条路很长，但每一步都算数，而今天分享的实践，正是坚实的第一步。