实现上,本文使用Spark[10]和HDFS[11]实现持久化操作。在将星名映射到不同的Hash桶之后,使用Spark对 每 个Hash桶 中 的 星 批 量 从Rediscluster读出,经过Spark sql[12]的建表操作,压缩后写入HDFS.为提高写性能,不同Hash桶的写操作是可以并行执行的。需要注意的是,同一个CCD的星表簇数据需要写入同一个CCD的目录下,以便于快速检索。从本质上看,为了查找某颗星的光变曲线,需要经过两级检索:1)确定该星所在的CCD;2)确定该星所在的星表簇2.4查询操作基于星表簇的存储方式,查询操作并不能直接使用SQL完成,对于某些查询而言需要做一定程度的解析。
查询共分为2种类型:1)返回的结果不需要随时间变化的属性,如查询某位置范围内所有出现的星名;2)返回的结果需要随时间变化的属性,如返回某颗星的光变曲线。通过收集天文查询需求,本文发现天文学家虽然关注光变曲线,如图6,但是锁定查询哪条光变曲线的操作往往集中在不变的属性列上。如查询某个范围内所有星的光变曲线,首先是查询该范围内的所有星名,其次是查询该星的光变曲线。因此,无论结果是否需要随时间变化的属性数据,都需要先查询与时间无关的属性数据。
如图6所示,本文合并所有CCD交叉认证时使用的模板表,并加入一些随时间变化数据的统计列,如亮度均值、方差、最大值和最小值等,构成一个逻辑上的索引表,因为该表很小,可以常驻内存。一个查询请求到来后,先判断结果的属性列是否需要随时间变化的属性,如果不需要,查找索引表,直接返回;如果需要,查找索引表,找出满足要求的星名,然后查找原始数据。这样做的好处是:1)对于结果不需要随时间变化的数据,查找索引表能避免扫描原始星表数据,提高查找性能;2)对于结果需要随时间变化的数据,查找索引表能最小化扫描原始星表数据的次数和范围,以提高查找性能。
对于采用缓存架构的本系统而言,原始星表数据存储于二级缓存(Redis cluster)和硬盘(HDFS)上,查找条件有可能涉及到这2个数据源。因此,就查询数据源而言,可分为以下3种策略对原始星表查询。
1)仅从二级缓存查询。查找索引表找出满足条件的星名集合;将该集合传入Redis cluster查询对应星的全部属性列;筛选符合条件的属性列。
2)仅从硬盘查询。查找索引表找出满足条件的星名集合;使用持久化的Hash函数将星名的结果集合映射到星表簇;对同一星表簇的星进行批量查询并筛选符合条件的属性列;对于不同的星表簇可以并行查询;最后合并不同星表簇的结果。
3)从二级缓存和硬盘查询。并行从2个数据源按照上述的策略查询,最终将结果合并。
3系统验证与分析
3.1实验准备
本文在Ubuntu 14.04,Hadoop 2.6.0,Spark1.6.2和Redis 3.2.5平台上建立了验证系统,采用10台物理机构建Hadoop,Spark,Redis cluster和分布式GWAC数据模拟生成器集群。对于Hadoop,Spark和分布式GWAC数据模拟生成器集群都使用相同的物理机作为主节点,剩下的9个物理机作为从 节 点 (模 拟9个CCD),此 外Spark使 用standalone模式进行资源管理。对于无中心结构的Redis cluster,每个物理机上开启4个Redis节点进程,共40个节点,并且另加入8个Redis slave节点作为整个Redis集群的冗余备份。
整个物理集群为同构环境,每台物理机使用英特尔i7-4790处理器、32GB DDR3-1600内存和1块500GB 7200SATA硬盘,节点之间采用万兆以太网互联。
着时域天文观测对超长时序、多站点多设备协调观测需求的增长, 全自动、无人值守联合观测成为光学天文观测发展的趋势之一.观测系统调度管理作为其中的重要组成。...
随着时域天文观测对超长时序、多站点多设备协调观测需求的增长, 全自动、无人值守联合观测成为光学天文观测发展的趋势之一.观测系统调度管理作为其中的重要组成, 在提高观测效率。...