任环宇，王 枫，范帝鑫

（1.中国科学院合肥物质科学研究院，合肥 230031；2.中国科学技术大学 研究生院科学岛分院，合肥 230026）

EAST[1]是我国设计建造的国际上第一个全超导托卡马克实验装置。随着EAST 实验的进一步展开，服务于EAST 的数据仓库存储的数据量越来越大，数据格式繁杂。 数据库源众多，数据仓库中的相机数据、实验数据、工程数据所对应的存储数据库也都不同，包括Mdsplus[2]、hdf5、视频文件、MySQL 等多种存储形式， 并且存储量已经达到100 TB 级别，数据仓库存储着丰富海量的数据。 EAST 实验装置每个系统采用独立的存储解决方案。 各个子系统的数据存储结构松散，缺少统一的资源目录。 这为装置整体的数据管理、数据运维、数据服务造成了很大的困难， 用户对数据仓库的资源概览也异常困难，极大加剧了用户使用相关数据的学习成本。

元数据是“描述数据”的数据[3]。 在核聚变工程领域，存在很多极有价值的元数据信息，例如信号元数据、存储元数据、放电实验摘要等。 将聚变实验装置的各类元数据有序的收集，建立统一的数据库能够形成整个聚变系统信息数据资源的准确视图，通过元数据的统一视图，缩短聚变相关科学实验数据清理周期、提高科学数据质量以便能系统性地管理科学数据中心项目中来自各子系统的海量数据的访问请求。 梳理各个子系统元数据之间的关系，建立信息数据标准完善对这些数据的解释、 定义，形成EAST 实验装置内部范围内一致、 统一的数据定义，并可以对这些实验数据来源、运作情况、变迁等进行跟踪分析提供重要的基础架构支撑。 目前该系统于2021年12月开发完成并已经在等离子体物理研究所托卡马克装置EAST 上验证并部署应用，并计划应用于下一代中国工程实验堆（CFERT）。

1 研究背景

国内已有相关研究包括EAST 实验数据检索系统[4]和统一数据访问接口方法的研究[5]。 前者的系统基于MySQL 的数据模型，对信号元数据进行建模和管理，后者系统聚焦于屏蔽底层数据格式，建立多源异构场景下的统一数据访问。

目前EAST 实验装置都是采取独立数据库直接访问数据的形式进行数据的获取，在多源异构聚变实验数据的环境下，建立面向元数据的统一的资源目录的设计和管理规范，对聚变实验等大科学实验装置的数据运维、数据服务有很大的工程意义。

2 系统设计

2.1 需求分析

基于EAST 实验装置的多源异构的场景下，需要数据库服务开发者构建统一的资源管理目录：

（一）配合统一数据访问接口UDA，建立起一整套的统一数据访问的服务体系。 通过资源目录查询数据的状态、获取数据的路径，然后通过UDA 去获取具体的实验数据。

（二）优化用户访问过程。 通过数据资源目录，用户能快速查看目标数据的状态。

系统需要提供合适的元数据存储解决方案，以Mdsplus 数据源为例，当前实验已经进行到100000+炮实验，系统需要针对其庞大的元数据提供快速的、毫秒级的元数据查询检索功能。

2.2 数据库选型

在数据库选型上，系统基于元数据的结构、典型的业务诉求，需要综合考虑以下几个方面。

EAST 实验装置本身的实验数据按照树形结构来存储，因此在数据库的选型中，需要围绕这种特殊的结构进行考察。 在多源异构场景下，系统需要有很强的可扩展性，丰富的API 支持，只读性。元数据一旦存入数据库中，基本用于查询，很少被更改。

面向文档数据库会将数据以文档的形式储存[6]。 每个文档都是自包含的数据单元，是一系列数据项的集合，以MongoDB 为代表。 基于它的弱模式结构， 不改变模式下就可以储存不同的度量方法及添加新的度量，这带来了极高的扩展性。 以MongoDB 为代表面向文档的NoSQL 数据库适用存储，为多语言提供了丰富的API。 MongoShell 也支持丰富的增删改查操作，其最大的特点是基于document（xml、json、bson 文件的封装）的存储格式，存储字典或者嵌套字典。 MongoDB 在存储、接口、数据格式、可扩展性这些元数据库所关注的方面有非常好的权衡。

综上所述，针对EAST 这类科学装置的数据资源目录管理，面向文档类型的NoSQL 在存储、接口、数据分析、扩展性、性能等方面有很好的平衡和适配。因此本系统最终选择MongoDB 为元数据库的底层数据库。

2.3 系统架构

整个元数据管理系统从采集元数据到提供给客户服务共分为4 层，最底层的是EAST 实验装置的多数据源，也是整个元数据的提取源头。 包括了存储实验数据的Mdsplus、MySQL 以及存储相机数据的数据库，系统架构如图1 所示。

图1 系统架构图Fig.1 System architecture

数据层包括实验放电监听模块、元数据提取模块等元数据后端的管理模块。 为了更好的元数据采集性能，这个模块中系统采用的技术路线主要是以更贴近底层语言的C++， 元数据库采用的是典型的NoSQL 类型的数据库MongoDB 以及MongoDB 为C++提供的调用接口。

在元数据服务层，系统通过调用元数据库提供的API，基于B/S 模式和spring MVC 的系统设计理念，使用springboot+MongoDB 的技术路线在后端封装元数据对外服务。

用户通过浏览器使用访问所提供的元数据查询、元数据统计得到的各种统计图、元数据监控等服务。 使用bootstrap 提供的JGrid 分页工具对松散灵活的树形层状元数据进行可视化展示， 使用Thymeleaf 作为模版引擎，将后台元数据相关的业务逻辑注入前端的模版中。

2.4 数据库设计

系统按照shot 为单位存储元数据。 基于炮号的反范式数据建模，在扩展性、查询性能充分借鉴关系型和非关系型数据模型的优势。 在实现上，基于MongoDB 的基本存储单元——文档以及基于array的文档嵌套，能够很容易地存储树形元数据。 具体的数据模型如图2 所示。

图2 元数据模型Fig.2 Meta data model

2.5 元数据管理平台

元数据提取模块会连接多源的数据库，并提取系统关注的元数据信息。 将元数据实时采集并按格式存储到元数据库中。

数据管理员通过元数据管理平台提供的状态巡检模块确保元数据库中的数据是准确的；通过统计数据更新模块持久化更新常用的统计表、索引信息，以此来优化访问性能；通过元数据库的日志来对元数据库中的数据进行监控和维护。

元数据提取模块监听到shot complete 事件之后，表明实验相关的数据已经采集完毕入库，实验装置正在为下一次放电实验做准备， 在这个间隙，系统基于mdsplus 提供的C++API 以及一系列访问数据库的tcl 命令，遍历Mdsplus 数据库的各个sub-Tree 并提取元数据。 系统的具体流程如图3 所示。

图3 系统流程Fig.3 System flow chart

3 系统实现

3.1 构建元数据库

基于Mdsplus 数据库提供的C++的event 类，开发监听模块。 使用Mdsplus 的currentShot 类获取事件后返回最大炮号，进行元数据提取。 提取完成之后，系统将涉及的统计的mongoShell 编写成json 文件，提取结束之后自动执行。 通过文档嵌套的实现方法，来模拟松散、可扩展的树形结构。 构建数据结构的伪代码流程如下所示。

3.2 数据库性能

测试在Centos7.9-64bit 的操作系统下进行，MongoDB 的版本号为v4.0.6。 测试数据量一共20000 shots，存储空间占用23.4 G，平均每炮实验下有5000～10000 不等的信号元数据。

数据库的查询主要分成两类。 一类是基于索引字段的点查询，精确到某个文档的数据。 一类是扫描全集元数据，对某个字段进行统计求和或者聚合分组。 性能测试结果如表1 所示。

表1 元数据库查询性能测试结果Tab.1 Metadata database performance test

3.3 统计数据更新

元数据库通过API 接口封装，为外部用户提供进一步的数据挖掘服务。 例如用户查询每个信号量的数据量计数，查询语句如下文所示。 查询的部分结果如图4 所示。

图4 信号名聚合统计结果Fig.4 Signal name aggregation statistics result

除此以外，还可以基于建立的元数据封装更多的跨炮间的数据统计、分析服务，这个功能弥补了原始多源异构数据仓库架构无法实现的功能。

3.4 资源目录设计

作为提供给用户使用的资源目录，前端设计得方便、 易用十分的重要。 本系统基于bootsrap 的JGrid 工具包，设计了三层的表结构目录来为用户呈现树状数据。 在一级资源目录中，如图5 所示，用户看到一个炮号的列表，这个列表主要包含炮号的索引、摘要索引，以及该炮的一系列元数据信息。

图5 元数据一级资源目录Fig.5 Metadata primary resource directory

用户点击炮号索引（即一级目录中的shot ID），进入到二级资源目录，如图6 所示，这一级目录将有关于该炮更详细的元数据信息以及统计信息。

图6 元数据二级目录Fig.6 Metadata secondary directory

用户点击信号名索引，进入第三级目录。 这一级目录是关于该炮下该信号名元数据的具体表单。如图7 所示，主要包括该信号的采集时间、采样频率、转换系数、零漂、放大倍数等信号元数据。

图7 三级资源目录Fig.7 Metadata tertiary directory

以上给出了一个聚变元数据库的展示框架，基于以炮存储的树状存储设计，这种展示结构和存储格式十分灵活。 即便关于炮号、关于信号增加了新的元数据，也可以方便地在对应层级的表单中添加对应的元数据字段，扩展起来十分方便。

4 结语

本文基于EAST 核聚变实验装置的元数据结构，创新地提出了按实验炮存储的反范式化的数据库设计方案， 基于MongoDB 创建了统一元数据库，并开发了相关的管理功能模块，同时集成了文献[7]中有关存储元数据的工作。 创建的统一的资源目录能够打破各个子系统之间的数据壁垒，为后续的跨实验之间的数据挖掘打下坚实基础，很好地完成了文章开头提出的需求。

本文在元数据模型的扩展性、查询性能、统计性能具有明显的优势。 100000 炮数据，平均响应时间在毫秒级， 证实了系统所用技术选型是合理、可用的。 并且能够和统一数据访问接口相互集成，提供一套完整的统一数据访问、检索服务。

未来需要继续与统一数据访问接口系统进行持续的集成，为EAST 实验装置提供方便可用的数据中台服务。