摘 要：超大型天文观测技术的出现不仅能够让研究人员观测到新的天文现象，更能用于验证已有物理模型的正确性。这些最新天文成果的发现是建立在海量天文数据的近乎实时产生、管理与分析的基础上，因此给目前的数据管理系统带来了新的挑战。以我国自主研发的地基广角相机阵（the ground-basedwide-angle camera array,GWAC）天文望远镜为例，15s的采样和处理周期都处于短时标观测领域的世界前列，但却对数据管理系统提出了很多问题，包括多镜头并行输出数据管理、实时瞬变源发现、当前观测夜数据的秒级查询、数据持久化和快速离线查询等。基于上述问题，设计了分布式GWAC数据模拟生成器用于模拟真实GWAC数据产生场景，并基于产生的数据特性，提出一种两级缓存架构，使用本地内存解决多镜头并行输出、实时瞬变源发现，使用分布式共享内存实现秒级查询。为了平衡持久化和查询效率，设计一种星表簇结构将整个星表数据划分后聚集存储。根据天文需求特点，设计基于索引表的查询引擎能从缓存和星表簇以较小的代价对星表数据查询。通过实验验证，当前方案能够满足GWAC的需求。
关键词：天文大数据管理；地基广角相机阵；两级缓存；星表簇；索引表。
随着各种最新观测技术的出现，天文领域迎来了信息爆炸的时代，而该时代的第一波浪潮就是天文大数据的管理。进入21世纪，天文学已经进入了一个信息丰富的大数据时代，天文数据正在以TB量级甚至PB量级的速度快速增长。2000年斯隆数字巡天（Sloan digital sky survey,SDSS）项目启动时，位于新墨西哥州的望远镜在短短几周内收集到的数据，已经比天文学历史上总共收集的数据还要多。到了2010年，信息档案已经高达1.4×242B.不过，预计2019年在智利投入使用的大型视场全景巡天望远镜（large synoptic survey telescope,LSST）能在5d之内就获得同样多的信息。在我国，郭守敬望远镜（the large sky area multi-object fiber spectroscopictelescope,LAMOST）和即将上线的地基广角相机阵（the ground-based wide-angle camera array,GWAC）等巡天项目每天都要产生海量的天文数据。
天文数据管理系统经历了从开始的基于文件系统的管理到目前基于关系数据库管理的发展阶段。早期限于观测设备，天文领域数据量不大，可以以文件的方式管理天文数据，仅支持一些简单的归档、排序和整理服务。随着观测设备升级，文件系统已不能满足当前数据规模的管理工作，因此天文领域开始使用关系型数据库管理数据。此时，天文研究者开始要求数据库能够按天文需求条件查找查询，并定制一些查询。但在可期的将来，超大型天文设备短时间产生（TB级）和累计下的数据量（PB或EB级）将超过关系数据库的管理能力，给当前天文数据管理带来巨大的挑战。
目前在国际上，美国的SDSS望远镜的采样周期是71.72s,每次采样的数据处理周期是1个月。美国设计的LSST采样周期是39s,每次采样的数据处理周期是60s.中国设计的GWAC不同于其他天文观测技术，由40台广角望远镜组成，单个观测夜中，所有望远镜要求同步地每15s采样一次，并于下一次采样前将原始图像数据转化为星表数据，与此同时数据还要处于可查询状态，以支持短时标天文现象的发现。因此，无延迟的处理数据，对当前数据管理系统提出了新的挑战。
传统的关系型内存数据库，如MonetDB[1],入库时间变动过大，极容易引起下一次数据来到后上一次数据还未写入完成，造成拥塞[2]而非关系型数据库，如Kafka[3]+Hbase[4],实验表明单个镜头一次产生的数据量写入Kafka需要2.7s,不会造成数据拥塞，但写入Hbase需要5min左右，并不能满足实时查询要求。
针对上述问题，本文提出一种两级缓存架构方案以支持无拥塞承接每个采样周期数据，且保证数据可查。结合GWAC背景，本文认为每个望远镜产生的数据之间相互独立，因此设计每个望远镜由一台服务器承接刚产生的数据，进行必要的处理后，如交叉认证（见1.2节），缓存入本地内存（一级缓存），并直接进行异常天文现象的识别。继而，每台服务器上的缓存管理器异步将一级缓存的数据写入二级缓存。二级缓存使用分布式共享内存实现，如Rediscluster[5]可以看出，一级缓存的作用如下： 1）快速承接每个望远镜产生的数据；2）快速进行异常检测；3）二级缓存故障后，保证数据的可靠性。两级缓存架构可以实现多镜头并行输出、异常天文现象发现、低延迟存储和秒级查询。
由于不能事先确定异常天文现象的发生，但异常发生时仍需要实现相关瞬变源数据的快速查询，以帮助天文研究人员快速定位重大科学发现。因此，本文将当前观测夜的所有数据全部缓存入二级缓存。在白天时，对二级缓存数据进行持久化操作。为了支持高效的离线天文数据分析并兼顾持久化效率。本文设计一种星表簇结构作为持久化数据的存储模式。简单地说，通过一定的天文业务背景和策略，将二级缓存中的星表数据聚合后存入不同的物理文件中。这样做的好处是：1）天文查询的基本需求是对星亮度变化的查询，不同星之间很少做关联操作，因此将部分星聚集存储，能保证只访问整个数据集的部分，从而提高查询效率；2）比起单颗星存储而言，能有效降低管理整个数据集的开销（如文件元数据和文件索引个数）。
对于不同的数据源，如二级缓存和持久化数据，查询引擎都必须支持且能联合查询。本文提出一种基于索引表的查询策略以支持快速查询。索引表除了记录星名，还记录星属性不变的部分（如位置信息）和统计信息，并动态更新。如果查询请求不需要检索随时间变化数据，如位置信息，那么查询索引表后直接返回；如需要随时间变化数据，则查询索引表获取满足条件星名集合，进而使用星名集合从二级缓存或持久化数据查询满足条件的星表数据。此时，星表簇结构可以保证查询引擎仅扫描持久化数据的某几个小子集。
为了验证上述方案的有效性，本文改写单镜头版GWAC模拟数据生成器[6]为分布式GWAC模拟数据生成器，可用于模拟多个望远镜同步产生星表数据。作者在一个小型的原型系统上实现了整个数据产生、存储和查询过程并进行了实验验证。实验结果表明，当前的设计方案能够支撑GWAC系统日常的业务需求。
本文主要贡献如下：
1）设计分布式GWAC模拟数据生成器，能够更真实地模拟多个望远镜同步产生星表数据的应用场景；2）提出一种两级缓存架构的数据管理方案，针对性地解决多镜头并行输出、实时瞬变源发现和秒级查询等问题；3）针对当前观测夜星表数据持久化时间限制及离线查询效率的相应要求，设计一种星表簇的存储结构兼顾持久化与查询性能；4）设计一种针对索引表和星表簇结构的查询策略，能够尽可能少地访问持久化数据，或访问持久化数据的部分子集以提高查询效率。
本文首先介绍GWAC背景和面向星表数据管理的相关工作，然后重点介绍面向GWAC星表数据管理系统设计，最后给出系统验证与分析结果。
1相关背景
1.1 GWAC相机阵介绍
我国兴建中的地基广角相机阵GWAC由40台口径为18cm的广角望远镜组成，每台望远镜配备4k×4k的电荷耦合器件（charge coupled device,CCD）探测器①。整个相机阵的天区覆盖5 000平方度，时间采样周期为15s.每个观测夜对固定天区目标的持继观测长达10h.从观测视场的大小和观测时间的采样频度上，地面广角相机阵在时域天文观测中具有特殊的优势。巨大的数据量和高速采样率，对数据的管理和处理问题提出极大的挑战。地面广角相机阵的星表数据指标是：1）星表数据每幅图像大约有1.7×105条记录，整个相机阵在15s内共产生6.8×106（数据量约为1.3GB）条记录，每晚约有2400×40=96000幅图，大约需要2TB的存储开销；2）以10年为设计周期，GWAC总计将产生3~6PB量级的超大规模星表。
