基于NGAS的多点观测数据存储与同步方法*

石聪明，邓 辉，戴 伟，卫守林，王 锋1,,4

(1. 昆明理工大学管理与经济学院，云南 昆明 650093；2. 广州大学天体物理中心/物理与电子工程学院，广东 广州 510006；3. 昆明理工大学云南省计算机技术应用重点实验室，云南 昆明 650500；4. 中国科学院云南天文台，云南 昆明 650011)

由中国、澳大利亚、南非、英国等国家共同参与建设的平方千米阵列望远镜是目前最大的天文实验装置，具有前所未有的灵敏度、巡天速度和视场[1-3]。SKA望远镜由分布在澳大利亚西部沙漠上的工作频率为50～350 MHz的低频螺旋对数天线和南非及南部非洲8个国家的工作频率为350 MHz～15 GHz的高频蝶形天线构成，总接收面积达1平方千米[4-5]。SKA将产生超海量的观测数据，在SKA-1阶段，每秒产生高达数十TB的原始数据，需要长期保存的科学数据每年新增50～300 PB；在SKA-2阶段，每年新增的科学数据将达到SKA-1阶段的100倍[3,6]。

为了应对当前面临的预算和数据量处理的限制等相关问题，SKA提出建设区域数据中心，实现数据的异地存储与归档，通过各国科学中心的建设推动科学研究工作的方案。这一目标的达成要求海量观测数据能够高速地从观测地(南非和澳大利亚)的数据中心同步传输、存储到区域数据中心，从当前的技术水平来看，这一需求具有非常大的挑战。

下一代归档存储系统是当前射电天文领域最为常用的一套成熟的观测结果归档软件，系统采用Python开发，功能丰富，具有高度的移植性。NGAS设计之初是为了解决欧洲南方天文台在20世纪末期面临的每天新增55 GB观测数据进行高效且低成本的数据归档、处理、检索及同步的问题[7]。在SKA先导默奇森宽场阵列(Murchison Widefield Array, MWA)中，NGAS被用于默奇森宽场阵列与美国麻省理工学院和新西兰惠灵顿维多利亚大学[8]间的数据同步，也被欧洲南方天文台用来归档管理产生的海量观测数据及同步存储到不同的站点[9-12]；阿塔卡马大型毫米波/亚毫米波阵列(ALMA)使用NGAS将收集的观测数据同步到美国、日本和德国的区域数据中心[11-12]。

然而，在面对SKA这一类具有更高时效性要求的数据同步与归档需求时，NGAS仍然面临着一些问题。远程数据同步效率是其中一个重要方面，根本原因在于NGAS在同步传输数据的过程中使用基于HTTP的方式，由于HTTP协议封装效率较低，导致整个数据传输性能较差。SKA-1的数据同步量相对较少，采用HTTP协议封装可以满足要求。随着SKA-2的建设，数据量呈指数增长，研究新的封装方法，提高效率就成为一种必然。

由于当前SKA正在设计评估阶段，部分需求还没有最终确定。因此，对于SKA数据归档和远程同步工作均在预研与测试阶段，本文正是在这方面开展的基础性工作。为提高远程数据同步性能，针对我国建设区域数据中心的需要，进一步研究了基于ZeroMQ的多点观测数据存储与同步方法。

1 NGAS的底层实现分析

NGAS的核心是一个多线程并发HTTP服务器，NGAS通过关系型数据库(RDBMS)管理归档文件的元数据、订阅者信息、磁盘信息等。NGAS[注]https://ngas.readthedocs.io/en/latest/index.html实现了STATUS，ONLINE，OFFLINE，ARCHIVE，SUBSCRIBE，UNSUBSCRIBE等20多个自定义命令，这些命令的主要功能是实现基本的数据归档与检索、服务器端数据压缩和过滤、自动镜像数据、磁盘跟踪、离线数据传输、数据一致性校验、数据订阅(数据存储与同步)等功能。

NGAS的数据同步传输功能是通过NGAS的数据订阅线程调度订阅者对应的数据发送线程，实现将数据从数据发布者同步传输给数据订阅者。数据发送线程的流程如图1。

图1 NGAS数据发送线程执行流程图Fig.1 A flowchart of data delivery

NGAS数据发布方将一个数据文件传输给数据订阅方需要经历如下过程：用HTTP协议封装数据文件，将封装好的数据文件发送出去，等待接收数据订阅方响应的成功存储数据文件的消息，处理下一数据文件。NGAS在同步传输数据过程中需要数据发布方等待接收数据订阅方反馈消息而导致整个数据传输性能较差，同时由于HTTP协议封装效率较低，也导致整个数据传输性能较差。

2 多点观测数据存储与同步方法的改进

针对NGAS中数据同步传输功能是基于HTTP实现的，本文提出一种基于零消息队列(ZeroMQ[13])改进NGAS中多点观测数据存储与同步的方法。该方法使用ZeroMQ中的PUB-SUB套接字组合实现高效快速的数据同步传输与存储。然而，PUB-SUB套接字的组合存在这些问题[注]http://zguide.zeromq.org/page:all：(1)订阅方崩溃导致订阅数据丢失；(2)订阅者取回消息很慢导致发布方的发布队列溢出而造成数据丢失；(3)网络超载导致数据丢失；(4)订阅方加入太迟错失了发布方已经发布的数据。

为了在改进方法实现的系统中解决PUB-SUB套接字组合带来的问题，加入近实时感知端口连接状态的机制规避发布方在没有订阅方连接的情况下发布数据，同时加入数据重发机制克服因为网络超载、订阅方崩溃等导致的数据丢失造成订阅方无法完全同步数据的问题。为了使基于改进方法实现的数据同步传输与存储子系统能够独立于NGAS运行，在子系统中加入了使用ZeroMQ中的DEALER与ROUTER实现的订阅与退订功能模块。

基于改进方法实现的系统主要包括如下子系统模块：数据发布端服务器(Pub-Server)、数据订阅端服务器(Sub-Server)、订阅者服务器(Subscriber-Server)、订阅者客服端(Subscriber-Client)。数据发布端服务器和数据订阅端服务器负责数据发布方与订阅方之间的数据同步传输与存储，如图2；订阅者服务器和订阅者客服端负责发布方与订阅方之间的消息订阅与退订，如图3。

2.1 数据发布端服务器与数据订阅端服务器设计与实现

数据发布端服务器主要负责启动数据发布端、数据同步传输、存储相关的守护线程，其执行流程如图4。数据发布端服务器主要包含如下功能模块：启动订阅者对应的发布数据守护线程、启动接收反馈消息的守护线程、启动处理反馈消息的守护线程、启动更新积压文件的守护线程、启动更新发布队列的守护线程、启动处理新增订阅者的守护线程、启动处理新增退订者的守护线程。数据订阅端服务器的功能与数据发布端服务器类似，只是处理对象不同。

数据发布端服务器与数据订阅端服务器之间的数据同步传输与存储中涉及两种消息：Pub_msg和Sub_msg，如图2。Pub_msg是数据发布方(Publisher)发布的消息，格式为SI_SP， PI_PP， BFR， BFD；Sub_msg是数据订阅方(Subscriber)发布的已成功接收与存储的反馈信息，格式为SI_SP， PI_PP， BFR。SI表示数据订阅方的IP；SP表示数据订阅方为某个数据发布方申请的用于发布反馈消息的固定端口；PI表示数据发布方的IP；PP表示数据发布方为某个数据订阅方申请预留的用于发布数据的固定端口；BFR由文件名、文件ID、文件版本、文件类型组成；BFD表示BFR对应的积压文件数据。

当数据发布端服务器上的近实时端口连接状态守护线程能检测到某个数据发布方的数据发布端口被数据订阅方连接时，触发该数据发布方对应的数据发布线程开始产生并发布Pub_msg；否则触发停止数据发布线程。同时，数据重发机制会在某个数据发布方发布某个数据文件超过一段时间仍未收到数据订阅方发布的已成功接收和存储的反馈信息时，将让数据发布方重新向数据订阅方发布该数据文件。

2.2 订阅者服务器与订阅者客服端设计与实现

订阅者服务器与订阅者客服端之间的异步通信模式如图3。订阅者服务器负责接收处理订阅消息(Sub-Msg)和退订消息(Unsub-Msg)，并将订阅成功消息(Sub-Msg-S)、订阅失败消息(Sub-Msg-F)或退订成功消息(Unsub-Msg-S)回复给对应的请求者，同时更新数据库中的相应订阅者记录。订阅者客服端负责向订阅者服务器发送订阅消息和退订消息，根据接收到的响应消息更新数据库中的相应发布者记录。其中订阅消息、退订消息、订阅成功消息、订阅失败消息、退订成功消息这5种消息的格式分别为：S_SI_SP_Datetime，U_SI_SP，SS_SI_SP_PI_PP，SF_SI_SP，US_SI_SP。同时，在订阅者客服端加入消息重发机制确保订阅者客服端能够成功订阅或者退订相应的数据发布者。

图2 数据发布端服务器与数据订阅端服务器之间的通信模式

Fig.2 Communication mode between Pub-Server and Sub-Server

图3 订阅者服务器与订阅者客服端之间的通信模式

Fig.3 Communication mode between Subscriber-Server and Subscriber-Client

图4 数据发布端服务器执行流程图
Fig.4 A flowchart of Pub-Server

3 实 验

3.1 实验环境

本文测试性能所用的硬件环境是1台型号为IW4200-10G的思腾合力GPU服务器，该服务器具有16个双核Intel©Xeon(R) CPU E5-2620 v4 @ 2.10 GHz处理器、256 GB R-ECC DDR4 内存、2个Intel©I350千兆网卡。软件环境为64位的Ubuntu 14.04 LTS，Python 2.7.6，MySQLdb 1.2.5，libzmq 4.2.5，pyzmq 17.1.2，MySQL 5.5.61。

由于NGAS能够处理的标准FITS文件必须包含自定义的关键字ARCFILE (ARCFILE=′NCU.2003-11-11T11: 11: 11.111′)，实验数据为MUSER-I的40万个已添加ARCFILE关键字的FITS文件，数据量约为75.102 GB(400 000 × 201 600 B)，存放在分配了250 GB内存的tmpfs(临时文件系统)中。

3.2 实验结果

基于ZeroMQ改进的多点观测数据存储与同步方法与NGAS中的数据存储与同步方法的实验结果性能对比如图5。订阅者使用基于ZeroMQ改进的数据存储与同步方法将40万个FITS文件完全同步传输与存储下来所耗费的时间约为333.834 s(约5.6 min)，使用NGAS中的数据存储与同步方法所耗费的时间约为13 330.998 s(约222.2 min)。NGAS中的数据存储与同步方法用时是基于ZeroMQ实现的数据存储与同步方法用时的39.933倍。

图5 同步性能对比
Fig.5 Synchronization performance comparison

3.3 讨 论

实验结果表明，基于ZeroMQ改进的NGAS的数据存储与同步方法在数据存储和同步方面性能明显优于NGAS的数据存储与同步方法，但是该方法也存在一些不足：

(1)由于基于ZeroMQ实现的NGAS数据发布端服务器要为每一个数据订阅者分配一个固定的端口和每个IP地址端口数为65 536的限制，造成其只能为有限数量的订阅者提供服务；

(2)基于ZeroMQ的NGAS多点观测数据存储与同步方法的系统存在订阅端服务器因为无法及时存储高速接收的订阅数据而导致内存不足，进而导致订阅端服务器被杀掉。在未来的工作中，将加入动态调整数据发布的机制优化数据的同步传输效率。

4 结束语

本文详细介绍了NGAS中的数据同步功能，讨论了基于ZeroMQ改进的NGAS多点观测数据存储与同步方法及基于该方法实现的系统，通过实验验证了基于ZeroMQ改进的NGAS多点观测数据存储与同步方法实现的系统在数据同步传输和存储效率方面性能明显优于NGAS中的数据存储与同步。下一步工作将在更加真实的实验环境中测试新方法的远程数据同步性能并进一步优化其性能。本文的工作对SKA区域数据中心与SKA天文台数据中心之间的数据同步传输和存储有较好的参考价值。

致谢：感谢国家天文台-阿里云天文大数据联合研究中心对本文工作的支持。