面向地基广角相机阵星表数据管理系统的设计与验证(5)

　　3.2实验结果分析

　　为验证GWAC星表数据管理系统的有效性，实验开展了如下工作：1）分布式GWAC数据模拟生成实验；2）写缓存效率；3）持久化效率；4）查询效率。
　　
　　1）分布式GWAC数据模拟生成由于产生的数据需要缓存进Redis cluster中，因此本集群环境的内存容量不可能容纳当前观测夜的所有数据量（约3TB）。经过测试，现有集群环境能模拟9个CCD同步拍摄300次（相当于1.25h）的整个过程。实验结果表明，模拟数据产生过程很稳定，单个星表的产生时间约为3s,低于真实CCD产生一副图像需要的15s,因此可以用来模拟GWAC数据产生过程。单个模拟星表的星个数在（175567,175675）之间不等，每个星表大约33MB符合真实场景，300次共产生87GB星表数据。
　　
　　2）写缓存效率如图7所示，9个CCD单次交叉验证且并行写Redis cluster的时间维持在1.35s以下，平均耗时1.08s,在整个写缓存过程中时间没有出现显着的抖动。因 此，两级 缓存结构的设计方案能够满足GWAC实际需求，各CCD产生的数据不会出现堆积现 象。此 外，9个CCD的 星 表 数 据 写 入Rediscluster 300次共消耗内存269GB.消耗的内存量大于总共产生的数据量，原因如下：①所有Master节点存储原始数据，Slave节点备份产生的星表数据，总共需要消耗178GB内存空间（较产生的原始数据需要增加2列交叉认证数据，因此实际存储数据量大于2×87GB=174GB）；②另加入的8个Slave节点在集群正常工作时，作为某个Master节点的备份需要消耗36GB内存空间；③Redis cluster维护整个数据结构，如指针、元数据等，需要消耗55GB左右的内存空间，约占所消耗总空间量的20%.
　　

　　　　

　　3）持久化效率本节实验对已写入Redis cluster的9个CCD的星表数据进行持久化操作，并测试效率。为了发现持久化时间和星表簇之间的关系，本文分别测试了如图8横坐标所示的8种不同的星表簇个数，如90代表将9个CCD的星表数据划分入90个星表簇中，其中一个CDD平均有10个星表簇。
　　
　　如图8所示，随着星表簇的增多，持久化所需要的时间越来越长，主要原因是：①簇内星表数据减少导致随机写的代价升高；②簇个数的增多导致创建簇的代价升高。上述现象导致星表簇个数和持久化时间的正相关关系。当星表簇个数达到9 000时，持久化时间为7.9h,继续增加星表簇个数会导致持久化时间的继续增长，过长的持久化时间已经不能满足白天进行持久化的基本要求。介于此，本实验不再继续增加星表簇个数，并认为每个CCD的星表数据划入1 000个星表簇是当前实验集群能接受的最大值。当星表簇个数在90~900之间时，持久化时间为11~52min,该时间范围是可容忍和接受的，因此下文将对上述已持久化好的星表簇进行查询，以评估查询效率。
　　

　　

　　
　　4）查询效率

    本节实验实现2.4节的查询策略，并测试对Redis cluster和星表簇的查询效率

　　

　　实验随机选取20个星名（对不同数量星表簇的测试都使用这20颗星），并查询这20颗星在1.25h之间的光变曲线.当查询Redis cluster时，查询时间维持在4~5s之间.如图9所示，当查询星表簇时，查询时间也以秒为单位，且整体趋势是随着星表簇个数的增加，查询所需时间越短.这种现象的主要原因是星表簇内星的减少，导致每次读取的数据量更少，扫描效率更高.
　　
    随着星表簇个数的增加，持久化效率和查询效率呈现不同的性质，因此就实验结果而言本文认为900个星表簇是较好的一个平衡点.
　　
　　4结论

    针对GWAC天文大数据的特性和面向该类数据的管理挑战，本文提出了一套有针对性的数据管理架构和系统原型.其中包括：1）分布式GWAC模拟生成器；2）两级缓存架构；3）基于星表簇的存储策略；4）基于索引表的查询策略.通过实验验证，目前设计的原型系统能够实现实时存储GWAC每个采样周期的数据、实时瞬变源发现，秒级查询响应，持久化当前观测夜数据和快速的离线查询.未来的挑战主要在于提高查询效率和减小管理持久化数据的代价，实现对星表簇拆分和合并操作.
　　
　　参 考 文 献

　　[1]Boncz P,Grust T,Van Keulen M,et al.MonetDB?XQuery:A fast XQuery processor powered by a relational engine[C]??Proc of the 2006ACM SIGMOD Int Conf on Managementof Data.New York:ACM,2006:479-490
　　[2]Wan Meng. An application research of column storeMonetDB databaseon GWAC large-scale astronomical datamanagement[D]. Beijing:National Astronomical ofObservatories,Chinese Academy of Sciences,2016（inChinese）（万萌。列存储MonetDB数据库在GWAC海量天文数据管理的应用研究[D]北京：中国科学院国家天文台，2016）
　　[3]Apache.Kafka[OL][2016-12-30].http:??kafka.apache.org?
　　[4]Apache.Hbase[OL].[2016-12-30].http:??hbase.apache.org?
　　[5]Redislabs.Redis[OL].[2016-12-30].https:??redis.io?
　　[6]Wan Meng.Gwac-dbgen[OL].[2016-12-30].https:??github.com?wan-meng?gwac_dbgen
　　[7]Jian L I,Cui C Z,Bo-Liang H E,et al.Review and prospectof the astronomical database[J].Progress in Astronomy,2013,31（1）：1-16
　　[8]SDSS.Skyserver[OL].[2016-12-30].http:??skyserver.org?
　　[9]Wan Meng,Wu Chao,Wang Jing,et al.Column store forGWAC:A high-cadence,high-density,large-scale astronomicallight curve pipeline and distributed shared-nothing database[J].Publications of the Astronomical Society of the Pacific,2016,128（969）：114501-114516
　　[10]Zaharia M,Chowdhury M,Franklin M J,et al.Spark:Cluster computing with working sets[C]??Proc of USENIXConf on Hot Topics in Cloud Computing.Berkeley,CA:USENIX Association,2010:1765-1773
　　[11]Apache. Hadoop[OL].[2016-12-30].https:??hadoop.apache.org?
　　[12]Armbrust M,Xin R S,Lian C,et al.Spark sql:Relationaldata processing in spark[C]??Proc of the 2015 ACMSIGMOD Int Conf onManagement of Data.New York:ACM,2015:1383-1394