2. 中国科学院云南天文台, 云南 昆明 650011
2. Yunnan Observatories, Chinese Academy of Sciences, Kunming 650011, China
普适图像传输系统(Flexible Image Transport System,FITS)是天文数据管理的一种主要格式，数据文件头包含了丰富的描述数据的元信息。它是元数据的主要构成部分，也是天文数据检索和查询服务的主要依据。同时，在海量高速的太阳数据观测应用场景下，为了便于数据管理，最大化地提高存储性能，使用元数据和FITS数据文件分离的存储模式。这种模式能够提高数据构建索引和查询的效率，减少打开FITS文件获取元数据信息的资源开销。元数据和数据文件分布存储的模式在提高存储性能的同时也容易导致数据之间的不一致，主要包含两方面：存储了FITS元数据没有对应的FITS文件和存储了FITS文件没有对应的FITS元数据。这两类问题的结果都导致在查询数据时，无法正确访问某些FITS数据文件，从而造成数据的假丢失现象。这个问题在天文数据存储领域还没有相关文献对其进行细致的研究。
为了保证高速的数据存储，减少元数据和FITS数据文件之间的不一致性，研究了两类数据之间的关系，主要包括：(1)分析了高速太阳观测数据存储时，元数据和FITS文件数据分离存储时的一致性数据模型;(2)对高速的分离数据产生不一致状态进行分析并分类;(3)应用改进的两段提交协议来处理这种一致性问题，并对高速数据存储性能需求和一致性要求之间的关系进行了讨论。本文的研究也可为其他科学领域的数据存储系统中不同数据之间的一致性和数据同步提供参考。
1 相关工作 1.1 FITS文件头FITS头通常包含观测环境下望远镜配置、观测条件、观测者、日期时间、观测的实际环境参数等其他附加信息，这些数据可以被看成FITS文件和观测活动的元数据，是元数据信息的主要组成部分，因为它包含了描述数据结构和观测的信息[1]，它们被单独存储到元数据仓库。文[2]认为FITS文件头包含了重要的元数据信息，并研究了在分布式环境下如何高效提取FITS的头信息；文[3]讨论了FITS头中保存的信息可以满足大部分FITS数据文件查询检索的需求，设计了一个使用离线方式提取FITS头的系统。这些相关工作都没有对二者之间的一致性关系进行处理。
1.2 元数据天文可视化元数据没有统一的观测元数据标准，目前通常认为FITS头中包含了重要的元数据信息[1-2]。澳大利亚望远镜阵列(Australia Telescope Compact Array,ATCA)的数据存储使用元数据和数据分离的方式，元数据存储在关系型数据库中，数据则存储于文件服务器[4]。文[1]为欧洲南方天文台(European Southern Observatory,ESO）设计了FITS的元数据处理框架，由于观测的实时性需要，一些元数据要从FITS头中提取并存储到元数据库，用于构建查询服务[1]和数据挖掘[5]。数据溯源是科学活动中的重要工作，在FITS文件的FITS头中通过HISTORY和COMMENT两个关键字段可以回溯FITS文件的历史记录[6]。
1.3 一致性提交协议在具有分布式存储特征的系统中，为了达成数据副本之间的一致性，通常在数据提交前进行一致性协商确认，使用的相关协议主要有两段提交协议[7]、三段提交协议[8]、Paxos协议[9]等，这些协议在理论和实践中都已被成功应用[10-11]，但是主要用于底层系统之间的原子性应用和同步，对于在科学领域的高层应用较少。
2 一致性需求、不一致原因及状态分析 2.1 基于元数据的查询模式FITS元数据（或FITS头）和FITS数据文件分离的存储模式影响数据的查询方式，在基于元数据的查询时，应用程序先到元数据的存储库进行查询，得到查询结果后，再根据结果信息中包含的原始文件的引用信息去数据存储库获取原始数据文件。这种原始数据的获取，依赖元数据和数据文件之间的一致性关系，如果这种一致性关系不能保证，便不能通过元数据中的数据引用信息正确地获取数据文件，即根据元数据存储库建立的检索信息里找不到FITS文件，或者数据存储库中存在FITS文件，但是在元数据存储库中的检索信息没有对应的记录。所以，在这种存储模式下，要求元数据和数据之间能够保证一致性。
2.2 分离存储的一致性要求分离存储的元数据和数据之间的一致性满足实时数据检索和查询的需要。观测时，为了实时了解观测结果，掌握观测信息，根据当前的观测结果调整观测策略，要求应用系统能够实时反应已持久化存储的观测数据情况。通过元数据信息以及在元数据上构建的索引进行快速检索是有效提高实时性的手段，这就要求不同类型之间的数据具有严格的一致性对应关系。
2.3 不一致产生的原因元数据和数据分离存储时，二者之间不一致性主要来源于网络分区和主机失效等情况，这些情况主要由两方面原因造成：(1) 存储系统本身的原因，如网络通信故障，主机软、硬件故障，磁盘故障等；(2)由于太阳观测的实际观测计划改变，可能因为风速、天气等因素，即时调整观测状态，改变观测策略或者停止观测，人为影响了存储系统各分离存储部件之间的同步。
2.4 一致性提交协议在具有分布式存储特征的系统中，为了达成数据副本之间的一致性，通常在数据提交前进行一致性协商确认，使用的相关协议主要有两段提交协议[7]、三段提交协议[8]、Paxos协议[9]等，这些协议在理论和实践中都已被成功应用[10-11]，但是主要用于底层系统之间的原子性和同步，在科学领域的高层应用较少。
2.5 一致性基本状态FITS元数据与数据文件的不一致性表现为：在元数据存储库中，元数据记录中的关键字段与对应数据文件之间的关系丢失。对太阳进行观测时，常用的观测模式是放置一台前置采集服务器合成FITS文件，并分别即时推送元数据和数据文件到各自的存储库中，这种元数据和数据文件分开存储的模式被应用到太阳观测中，例如欧洲南方天文台[1]，分离存储模式见图 1。
|
| 图 1 元数据和数据存储时的分离存储模式以及FITS数据头作为元数据存储时和FITS文件数据不一致状态 Figure 1 The model of metadata and data in separated condition; states of inconsistency between FITS header and FITS Data |
FITS元数据存储时，普遍的存储方式是把元数据保存到关系型数据库中，以便能够满足数据查询的需要[3]。关系型数据库中表结构的字段域主要来自FITS头中的关键字域，在所有保存的字段域中，其中有一条关键的数据字段域，例如图 1中取名为 “Refer” 的字段，该域包含了对当前元数据记录对应的数据文件引用，当查询获取该数据后，再根据该条Refer指向进一步获取数据文件。这就出现了查询关系跨越不同的主机，可能因为系统故障的原因造成引用信息丢失的情况，文中把这种跨越网络在不同主机之间的引用关系分为4类：
(1) 正常状态：FITS文件元数据的引用信息和FITS文件之间存在严格的一致性对应；
(2) 空状态：元数据存储在元数据存储库中，但是未能通过其中的引用在数据存储库中找到对应的FITS数据文件；
(3) 孤立状态：数据文件在存储库中存在，但是未能在元数据存储库中找到对应的记录； (4)不匹配状态：数据存储时产生的不一致对应。
在这4种状态中，（2）、（3）、（4）属于不一致的情况；
下面章节主要针对这些情况进行详细分析。
2.6 两类状态的分布式存储分析文中2.1节提到的数据存储模式可以进一步抽象成如下图 2中(b)和(c)。图 2中的(a)是FITS元数据和FITS数据文件存储在同一主机上的情况；(b)和(c)是(a)存储模式的扩展，是在网络环境下的一种抽象表示，数据之间的不一致性较(a)更容易发生。文中主要以(b)和(c)的情况作为研究对象。在(b)和(c)中元数据被存储到元数据存储库（MS）中，FITS数据文件被存储到数据存储库(DS)中，数据存储库和元数据存储库是对物理上独立的一台或多台服务器的抽象。
|
| 图 2 元数据和数据分离存储时的两种不一致状态 Figure 2 Two states of inconsistency when the metadata and data are stored separately |
两类存储数据的分离增加了整个存储系统的复杂性，这两类数据之间可能因为存储介质、网络的异常导致数据存储之间的一致性问题，本文把存储介质和网络异常统一看成是前置机和元数据、数据服务器之间不能进行数据交换的情况。在此条件下，对于(b)和(c)两种情况，假设元数据存储库和数据存储库能够提供足够的存储带宽和数据读写速度支持前置采集服务器产生的数据流的存储，那么在元数据和原始数据发生异常的时候，导致前置采集服务器不能正确分辨元数据存储库和数据存储库的状态，这种异常情况在实际环境中描述如下：
(1) 如图 2中的(b)所示，在前置采集服务器要求进行数据（元数据和数据）存储时，与元数据存储库失去联系，但是与数据存储库之间的数据通信能够正常进行，在这种情况下，将丢失FITS元数据，由于没有丢失原始数据，元数据中FITS头的数据收集工作可以通过其他措施进行维护。
(2) 如图 2中的(c)所示，在前置采集服务器要求进行数据（元数据和数据）存储时，与数据存储库服务器出现数据通信异常，但是能够与元数据存储库服务器进行通信。这种情况发生时，存储元数据将没有意义。
根据观测数据的重要性，讨论(1)：在不进行任何一致性数据保障的情况下，假设某一CCD观测通道观测速率为 v (fps)，每帧数据大小为 φ (megabyte)，从某一时刻 τ 开始，前置采集服务器与元数据存储库之间的通信发生故障，经过 φ 秒后恢复，此时原始数据将存储 v × φ 张FITS图片，这些数据在元数据库中未能找到对应的记录，通过元数据进行实时数据查询时，就出现了数据假丢失的现象。
2.7 实例研究为了说明(1)的情况，以目前国内最大的太阳光学望远镜1 m红外太阳望远镜[12](New Vacuum Solar Telescope,NVST)的数据采集存储为例，1 m太阳望远镜采用多通道多波段的数据采集模式，各个通道按照预定的观测计划，在合适的观测条件下产生数据的速率见表 1。
| 通道 | 相机数 | 相机分辨率 | 平均速率/fps | 总速率/MBs-1 | 总数量/GB hr-1 |
| 可见光波段观测 | 1 | 4 008 × 2 672 | 5 | 105 | 378 |
| Hα成像观测 | 1 | 2 048 × 2 048 | 14.7 | 117.6 | 423.4 |
| 近红外观测 | 1 | 640 × 512 | 25 | 16 | 57.6 |
| 总量 | 44.7 | 238.6 | 859 |
①实际观测速率受观测条件制约
1 m太阳望远镜的存储系统的设计为了满足高性能存储目标，将采用元数据和原始数据分离的数据存储模式。实时数据观测监视系统中的实时数据查询模块基于元数据查询，由于意外故障（网络异常、存储异常、人为原因等）导致前置机与数据存储的元数据库不能通信而发生(1)的情况，经过 φ 秒恢复，那么按照表 1的数据存储速率，将产生如表 2的不一致数据文件。
| 通道数 | 1/s | |
| φ | v × φ | |
| 可见光波段观测 | 30 | 150 |
| Hα成像观测 | 30 | 421 |
| 近红外观测 | 30 | 750 |
| 合计 | 1 321 | |
通过表 2可以看出，因为30 s的短暂故障，系统将产生1 321个状态不一致的数据文件，在这种情况下，基于对元数据的实时查询和检索[3]就不能正确检索到这些数据文件，甚至可能影响正常的观测活动。
3 一致性解决方案 3.1 简单的一致性处理由于太阳观测的实时、高性能要求，可以使用消息传递来协商保持一致性 ，在不考虑FITS文件头和FITS数据分布存储副本的情况，通常保证一致性的做法主要有如图 3的4种方式，下面结合天文数据存储的特征，分析这4种方式的优缺点。
|
| 图 3 FITS文件在线存储使用消息传递保持一致性的几种模式 Figure 3 Several models of consistency guaranteed by message delivering in online FITS Storage |
(1) 模型(a)
使用异步非阻塞的方式存储FITS头和FITS文件，二者之间不存在一致性的协商手段，一致性建立在假设的基础上，主要依赖于主机的可靠性，所以一旦出现异常，二者之间的一致性难以保障。
(2) 模型(b)
FITS头的存储必须等到FITS数据存储后，并接收到FITS文件存储完成的消息后才能进行FITS头的存储，当FITS头存储完成后再通知数据存储进程，元数据存储完毕，就可以进行下一个FITS文件的存储。
该方式中 “Header” 和 “Data” 的位置可以互换，先存储FITS头的存储过程和先存储FITS文件类似。区别在于，先存储FITS文件，即使在FITS头不能安全保存到存储介质的情况下，仍然可以通过其他方式在事后对未进行标记的数据扫描提取FITS头信息弥补。这是一种较为安全的存储方式，但是实时性会受到影响。
(3) 模型(c)
FITS头和FITS文件按照异步非阻塞的方式进行，在二者存储后再进行通信确认一致。
(4) 模型(d)
该模型只存储FITS文件，待FITS文件持久化存储在数据存储库后，再提取FITS头部分，把它存储到元数据存储库中，这个模式是通常的离线存储方式。文[2]和文[3]中的离线收集文件头方式可以看成是该模式的特殊情况。
3.2 两段提交协议本文使用成熟的两段提交协议做数据服务之间的同步，文[13]提出了一种分布的数据服务器之间的同步方法。两段提交协议被认为是在分布式环境下，保证原子性事务和数据之间一致性的有效方案，能够容忍进程、网络和通信的失效[7]。
为了便于表述，把太阳观测数据存储时的各个参与部分按照两段提交的角色进行划分如图 4：前置采集服务器充当协调者(Coordinator)的角色，元数据存储库和数据存储库充当成员(Cohorts)的角色，三者之间通过两段提交协议协商是否对前置采集服务器发出的存储数据进行一致性确认，图 4是在数据存储系统的一个基本拓扑结构和角色划分。
|
| 图 4 两段提交协议应用到太阳数据存储中的角色划分 Figure 4 The roles of 2PC in the use of solar data storage |
该协议存在节点之间因为协商一致性而等待，以至于死锁导致系统的处理过程无法进行的情况，这就需要引入超时机制解决这些问题[14]。
3.3 两段提交协议的具体实现两段提交协议应用到高速太阳观测的环境下 ，由于高速数据存储性能的要求，在实际使用中没有达到协商一致的情况，尽量减少写日志操作，表 3（a）和表 3（b）是使用改进的两阶段提交协议[15]结合观测系统的存储应用算法描述，表 3（a）描述了协调者的工作流程，对应表 3（b）为参与者的工作流程。
| 协调者 | (Coordinator: FEC) |
| 1 | WAIT: |
| 2. | do until MS and DS ready then |
| 3. | | wait |
| 4. | end do |
| 5 | VOTE： |
| 6 | sent "VOTE" to MS、 DS |
| 7. | do until received response from MS、 DS then |
| 8 | | wait |
| 9 | end do |
| 10 | response1 = response from MS |
| 11 | response2 = response from DS |
| 12 | if response1 or response2 is "No" then goto EXCEPT |
| 13 | if time-out then goto EXCEPT |
| 14 | if all response is "YES" then |
| 15 | COMMIT: |
| 16 | | Write metadata and "Commit" to MS |
| 17 | | Write data and "Commit" to DS |
| 18 | EXCEPT: |
| 1 | else if time-out then |
| 2 | | ABORT: |
| 3 | else if response2 is "YES" then |
| 4 | | write logs |
| 5 | | sent "ABORT" to the Cohorts whose vote result is "YES" |
| 6 | else if response1 is "YES" then |
| 7 | | mark data |
| 8 | | write data to DS |
| 9 | | sent "ABORT" to the Cohorts(MS) whose vote result is "YES" |
| 10. | | sent "COMMIT" to the Cohorts(DS) whose vote result is "YES" |
| 11. | end if |
| 参与者 | (Cohorts: MS,DS) |
| 1 | do until received "VOTE" from the coordinator |
| 2 | | wait |
| 3 | end do |
| 4 | if ready then |
| 5 | | sent "YES" to Coordinator |
| 6 | | do until receive from decision from the coordinator |
| 7 | | | if time-out then |
| 8 | | | | ABORT |
| 9 | | | end if |
| 10 | | | if decision is "COMMIT" then |
| 11 | | | | Receive Data |
| 12 | | | else |
| 13 | | | | write logs |
| 14 | | | | ABORT |
| 15 | | | end if |
| 16 | | end do |
| 17 | else |
| 18 | | sent "NO" to the Coordinator |
| 19 | end if |
两段提交协议用于保证两类数据之间的一致性问题，为了兼顾实时的数据存储性能，合理选择超时时间能够减少引入该算法后对性能造成的影响，下面通过单缓冲数据存储的方式分析超时时间的选择。
假设CCD产生的速率为 ν (fps)，每帧FITS图像大小为 μ (MB)，在数据存储过程中使用了一个由 n 块内存区域构成的单缓冲池辅助数据读写，每块缓冲大小为了方便讨论，设定为FITS图像的大小为 μ (MB)，那么可供使用的缓冲池的容量大小为 S = n × μ (MB)，采集的数据填满其中一块缓冲的时间消耗为
|
(1) |
系统同时可以使用这个单缓冲的填充时间充当超时等待的时间，当第1张FITS图像存储时，缓冲中没有任何待存储数据，则该FITS图像可以等待的时间为 n × τ ，第2张FITS图像存储时，可以等待 (n-1) × τ ，以此类推，那么平均超时等待时间为
|
(2) |
通过上述分析，Δ这个时间界限就是两段提交算法中各参与部件间一致性的协商时间，如果时间大于这个值，将影响数据存储的性能，甚至丢失采集的数据。同样的分析方法可以应用在多缓冲情况下超时时间的设计中。
4 实验及讨论结合上文的讨论，为了验证两段提交协议在采集数据过程中的一致性要求，设计了一个原型系统验证其可行性。原型系统使用Java1.8，Rpc协议使用Thrft，元数据持久层使用MongoDB，所有的运行平台均在CentOS6.6上。根据上文分析，对不同采集速率的要求，在给定128 MB缓存的情况下，做了如下超时时间的理论参考，根据这个参考，设计的实验结果如表 4，一致性验证使用抽样的方法。
| ν /fps | μ /MB | S /MB | n | τ/s | Δ/s |
| 5 | 21 | 128 | 6.1 | 0.2 | 0.71 |
| 14.70 | 8.00 | 128 | 16 | 0.07 | 0.58 |
| 25.00 | 0.63 | 128 | 204.8 | 0.04 | 4.12 |
表 4中通过128 MB单缓存得到的各个系统参数，最终通过(2)式可以得出最佳的超时时间。表示在该时间内，两段提交协议可以协商是否保持一致的时间，如果不能在该时间内得到一致性结果，就把该次采集的文件标记为未一致。结合两段提交的实现，通过原型得到如表 5中重要过程的存储性能。可以看到数据服务器和元数据服务器的第一阶段投票时间为14 ms，这段时间对于数据存储的时间 T DS来说可以忽略不计，而近似于FITS头的存储时间 T MS，这主要由于测试使用的FITS头只有12个字段，时间主要用于部分数据的存储。
| μ /MB | VoteDS/ms | VoteMS/ms | TDS/ms |
| 21.00 | 7 | 7 | 8 092.09 |
| 8 | 7 | 7 | 46 844.82 |
| 0.63 | 7 | 7 | 141.91 |
可以看出超时时间两段提交过程中，等待一致性的时间远远小于超时时间[（ VoteDS+ VoteMS）/Δ]，只占2%、2.4%和0.3%，结合上文分析，超时时间的设置符合设计要求，另外给出了64 MB~512 MB之间的超时时间（表 6），可以看出在当前实验环境下，满足设计要求。
| μ /MB | S /MB | |||
| 64/MB | 128/MB | 256/MB | 512/MB | |
| 21 | 0.4 | 0.71 | 1.32 | 2.54 |
| 8 | 0.31 | 0.58 | 1.12 | 2.21 |
| 0.63 | 2.07 | 4.12 | 8.21 | 16.40 |
综上，通过原型系统的实际验证，从实验结果来看，引入两段提交协议的好处能够最大限度地保障天文观测数据存储中的不同数据的一致性，其协商的耗时对于数据存储来说几乎可以忽略不计，但在一定程度上，对于FITS头字段较少的元数据存储，需要考虑。另外超时时间的设置通过理论结合实验可以看出，其设置方式合理。
5 结束语FITS元数据和FITS文件数据的分离存储改变了数据的访问方式，在应用程序访问FITS文件时，首先从元数据库获取FITS数据文件的引用信息，然后再根据这些引用信息，从FITS数据服务器获得数据文件，这种数据存储模式在提高存储和查询性能的同时也带来了这两类数据之间的不一致性问题。在高速数据存储情况下，这个问题若不加以考虑，可能因为存储节点、网络等故障导致大量数据出现不一致的状态，造成FITS数据文件的假丢失现象。为了能够兼顾存储性能和数据之间的一致性，本文使用了两段提交协议来协商这种分布式存储下两类数据的一致性。使用FITS数据存储的缓冲时间做两段提交协议的协商超时时间，这样既可以协商两类数据之间的一致性关系，又能保证高速数据存储系统的存储性能。
| [1] | Vera I, Dobrzycki A, Vuong M H, et al. Centralized FITS metadata handling framework at ESO[C]//Astronomical Data Analysis Software and Systems XX. ASP Conference Proceedings. 2011:33-36. |
| [2] | Goodrich B D, Wampler S B, Hubbard J R. Gathering headers in a distributed environment[C]//Prcoeedings of SPIE. 2008. http://cn.bing.com/academic/profile?id=2027300275&encoded=0&v=paper_preview&mkt=zh-cn |
| [3] | 崔辰州, 李文, 于策, 等. FITS 数据文件的检索和访问[J]. 天文研究与技术，国家天文台台刊 , 2008 , 5 (2) : 116 –123 Cui Chenzhou, Li Wen, Yu Ce, et al. Search an location of FITS data files[J]. Astronomical Research&Technology，Publications of National Astronomical Observatories of China , 2008 , 5 (2) : 116 –123. |
| [4] | Murphy T, Lamb P, Owen C, et al. Data storage, processing, and visualization for the Australia telescope compact array[J]. Publications of the Astronomical Society of Australia , 2006 , 23 (1) : 25 –32. DOI: 10.1071/AS05033 |
| [5] | Blatnik M, Clegg A W, Beaudet C, et al. Mining the GBT metadata archive:statistics on radio frequency use, 2002-2010[C]//Bulletin of the American Astronomical Society. 2011. |
| [6] | Mann B. Some data derivation and provenance issues in astronomy[C]//Workshop on Data Derivation and Provenance. 2002. http://citeseerx.ist.psu.edu/showciting?cid=2928357 |
| [7] | Bernstein P A, Hadzilacos V, Goodman N. Concurrency control and recovery in database systems[M]. New York: Addison-Wesley. 1987. |
| [8] | Skeen D, Stonebraker M. A formal model of crash recovery in a distributed system[J]. IEEE Transactions on Software Engineering , 1983 . |
| [9] | Lamport L. The part-time parliament[J]. ACM Transactions on Computer Systems (TOCS) , 1998 , 16 (2) : 133 –169. DOI: 10.1145/279227.279229 |
| [10] | Bernstein P A, Newcomer E. Principles of transaction processing[M]. San Francisco: Morgan Kaufmann. 2009. |
| [11] | Weikum G, Vossen G. Transactional information systems:theory, algorithms, and the practice of concurrency control and recovery[M]. San Francisco: Morgan Kaufmann. 2001. |
| [12] | Liu Zhong, Xu Jun. 1-meter near-infrared solar telescope[C]//First Asia-Pacific Solar Physics Meeting ASI Conference Series. 2011:9-17. |
| [13] | 董立岩, 毛锐, 余宜诚, 等. 基于分布式多服务系统的数据同步方法[J]. 吉林大学学报:理学版 , 2011 , 49 (4) : 745 –749 Dong Liyan, Mao Rui, Yu Yicheng, et al. Synchronization method based on distributed multi-service system[J]. Journal of Jilin University:Science Edition , 2011 , 49 (4) : 745 –749. |
| [14] | 李光, 李性存. 分布式事务处理系统中超时值的一种计算方法[J]. 计算机学报 , 1990 , 13 (11) : 824 –830 Li Guang, Li Xincun. A method for estimating timeout value in distributed transaction processing system[J]. Chinese Journal of Computers , 1990 , 13 (11) : 824 –830. |
| [15] | 于红, 高艳萍, 郭连喜. 改进的两阶段提交协议[J]. 大连水产学院学报 , 2005 , 20 (4) : 335 –339 Yu Hong, Gao Yanping, Guo Lianxi. Improved two-phase commit protocol[J]. Journal of Dalian Fisheries University , 2005 , 20 (4) : 335 –339. |