天文学论文

您当前的位置:学术堂 > 物理论文 > 天文学论文 >

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

来源:计算机研究与发展 作者:杨晨;翁祖建;孟小峰;
发布于:2017-06-22 共11303字
  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%.
  

  G.  

  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和星表簇的查询效率

i  

  实验随机选取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

原文出处:杨晨,翁祖建,孟小峰,任玮,忻日辉,王春凯,都志辉,万萌,魏建彦. 天文大数据挑战与实时处理技术[J]. 计算机研究与发展,2017,(02):248-257
相关内容推荐
相关标签:
返回:天文学论文