大天区面积多目标光纤光谱天文望远镜(the Large Sky Area Multi-Object Fiber Spectroscopic Telescope, LAMOST, 又叫郭守敬望远镜)^[1]是一架新型的大视场兼备大口径望远镜。2017年6月，郭守敬望远镜圆满完成了为期5年的第1期光谱巡天任务，共获取了约900万条光谱数据，其中高质量光谱数(信噪比大于10)超过700万，同时获取了超过500万组恒星参数，远远超过了全世界光谱巡天项目获取的光谱数总和，为天文学家研究银河系及一般星系的形成与演化提供了重要的基础性数据。

郭守敬望远镜每夜上万颗天体的观测和数千兆字节的FITS^[2]文件构成了一个海量数据集合。为了高效地利用望远镜的观测能力，已经建成了一套完整的自动化观测、数据处理和存储的软件系统^[3]，其中主要包括巡天战略系统(Survey Strategy System, SSS)、观测控制系统(Observatory Control System, OCS)、二维光谱数据处理系统(2D, 2-Dimention spectrum analysis software)和一维光谱数据处理系统(1D, 1-Dimention spectrum analysis software)。如何有效地维护和管理巡天过程中产生的海量观测和光谱数据，并将这些数据和以上软件系统有机地融合起来是光谱数据处理系统要解决的首要问题之一。

借助于数据库系统对数据处理数据流进行整合和管理是一种行之有效的解决方案。国内外越来越多的望远镜巡天项目带来越来越多的海量数据存储和处理的客观要求，对数据库技术要求也越来越高。国外已经建立了成熟的数据服务网站，比如ADS, SDSS等，虽然它们都能够提供某方面的服务，比如数据交叉服务、数据可视化服务、数据下载服务等，但是它们都是在数据处理和发布之后的服务，专门针对天文数据处理整个过程中数据流的数据库系统还没有先例。这需要在充分了解数据处理流程及其过程中涉及的数据流情况的基础上，探索建立适合郭守敬望远镜数据流的数据库系统，同时能够融合光谱质量控制机制，协助数据存储、处理和发布。

1 数据处理流程分析

郭守敬望远镜已经独立建立了一系列数据处理软件，除了巡天战略系统、观测控制系统、二维光谱数据处理系统和一维光谱数据处理系统之外，数据质量控制还需要加入观测日志检查和人工光谱检查环节等。以下是望远镜数据处理过程中涉及的关键环节：

(1) 巡天战略系统：负责自动化制定观测计划，决定观测时间和安排观测流程，充分利用望远镜的观测能力，有效地组织巡天观测，缩短观测周期，提高观测效率。每个观测夜大概需要6~8个观测计划，每个观测计划大约有3 600个源。

(2) 每日观测日志入库：在每天观测完成后，结合人工复核，自动化入库各个观测天区实时的天气等状况，标记天区类型包括：科学观测与否、月相、数据是否有效等，后期的质量控制会根据标记选择不同的数据发布策略，比如对于无效数据将无法发布给用户。

(3) 二维数据处理软件(2D Pipeline)^[3-4]：二维光谱处理的对象是光谱的CCD图像，目标是将二维图像的流量抽取成一维光谱，并扣除本底流量、杂散光、宇宙线和天光的干扰，再利用定标灯进行波长定标，利用流量标准星进行相对流量定标，最后将同一个目标的多次曝光和红蓝端合并成最终的光谱，在此过程中还要进行例如平场改正等在内的其他改正。

(4) 一维光谱分析软件(1D Pipeline)^[5]：它的处理对象是二维数据处理输出的一维光谱，目的是对光谱进行分类，并测量天体的红移，然后对恒星进行细分类。最后，光谱分折软件生成的4个主要分类分别为STAR, GALAXY, QSO和UNKNOWN。

(5) 相关函数初始值(Correlation Funtion Initial, CFI)^[3]：为了提高LAMOST恒星参数测量软件(LAMOST Stellar Parameter pipeline, LASP)的收敛速度和结果的准确性，相关函数初始值测量首先生成一组大气参数的初值，作为后续进行精确大气参数测量的范围，然后由里昂大学光谱分析软件(University of Lyon Spectroscopic analysis Software, Ulyss)^[6]生成最终的大气参数测量值。

(6) LASP^{[3, 6]}：LAMOST恒星参数测量软件是完整的大气参数测量程序。它专门针对分类为AFGK型恒星且满足一定信噪比条件的光谱，用Ulyss程序自动测量给出他们的有效温度、表面重力、金属丰度和视向速度。

(7) 星系测量软件^[3]：星系和类星体的识别和红移的测量是一项艰巨的任务，受望远镜极限星等的影响，很多星系和类星体隐藏在低质量光谱中，因此一维光谱分析软件在处理星系和类星体的光谱时还有一定的缺陷。所以，在初始的一维光谱分析运行完之后，还需要一个额外的独立的用于星系识别及其红移测量的软件。

(8) 人工光谱检查：LAMOST系统数据流中包括两个人工检查环节，二维检查和一维检查，前者是为了发现定标星有无异常、数据有无杂散光等大批量的数据问题，后者是为了保证数据分类和红移的准确性。只要这两部分检查出现问题，就会反馈给二维或者一维数据处理软件进行重新处理，相当于数据流出现小循环。

(9) 星表整合：在数据检查完毕以及数据处理和参数测量等一系列工作完成之后，会根据多项判据整合出满足数据发布条件的几个星表，以备数据发布时与信息中心对接。星表整合环节和人工检查环节共同配合完成光谱质量控制过程。

(10) 发布数据打包：在星表整合完成之后，对于即将释放的光谱数据，需要根据数据发布要求重写FITS头，重新画缩略图，以备数据上线真正发布。

(11) 数据产品发布：按照数据发布要求的节点，将整合的星表以及打包的数据一并推送给信息中心，并完成相应的数据统计。

2 数据流设计与光谱质量控制要求

郭守敬望远镜数据处理流程复杂，涉及的环节众多，需要一个系统级的核心数据库将这些环节及其数据进行衔接。该数据库系统的用户包括望远镜巡天与数据部全体工作人员，重点是巡天战略系统、观测控制系统、二维数据处理系统以及一维数据处理系统的开发人员，通过访问该数据库可以实时获取所需数据，分析处理结果，从而改进程序的处理方法，最终使得望远镜的数据库能够达到以下目标：

(1) 对于天文学家选定的观测目标，该数据库系统存储了从巡天战略系统生成观测计划、观测控制系统获取观测图像、二维数据处理系统处理图像数据以及一维数据处理系统输出光谱产品各阶段的主要信息，以帮助天文学家追踪他们的数据，更高效地查询各个处理过程的中间结果，获取有用的光谱产品输出。

(2) 光谱处理软件面临软件版本的更新，这时需要对上一版本处理过的数据进行再次处理，该数据库系统可以帮助数据处理程序开发人员存储和管理关键数据、查询处理结果，进而通过分析和比较这些结果对程序和处理算法做出改进。

(3) 具有良好的可扩展性和兼容性，能够适应时刻变化的人工检查和数据处理流程，能够对原系统最小改动情况下实现新环节的系统级融合，提供高效的检索服务。

(4) 本数据库系统中一维数据处理结果数据库表与数据存储和发布部门进行对接，协助实现一套高效的数据发布系统。

光谱质量控制的目标是及时发现光谱质量问题，既包括由杂散光、天气、仪器等原因导致的成批问题光谱，又包括二维数据处理系统在处理过程中发生错误导致的光谱问题。然而，伴随着将要对国内外天文学家释放的光谱，还有一维数据处理系统对光谱分析的结果、分类红移等。对于低质量光谱，一维数据处理系统不能保证百分之百的正确率，所以也需要进行质量控制。望远镜系统数据流中包括两个人工检查环节，二维数据处理系统结果检查和一维数据处理系统结果检查，一方面需要结合核心数据库进行检查结果的写入和查询，另一方面也需结合网络技术将人工检查环节变得更加高效和方便。图 1为光谱质量控制具体的流程，它主要分为恒星和星系/类星体两条主线。

综上所述，质量控制要求达到以下目标：

(1) 二维数据处理系统结果检查：快速浏览光谱，及时发现问题并录入数据库。

(2) 一维数据处理系统结果检查：对河外光谱，逐条检查分类和红移的正确性，同时也检查选源为河外而光谱分类结果是恒星的光谱部分；对于特殊类型的恒星光谱，逐条检查分类和红移的正确性，结果也会入库。

(3) 实时掌握数据处理各个环节的处理进度：对原始数据来说就是原始数据推送情况、单次曝光缺失情况等；对各个软件来说就是处理进度、异常监控、系统负载等情况；对人工检查来说就是人工检查进度、任务分配等。

(4) 光谱产品追溯：对单个目标，可以给出它自选源、观测、软件处理结果、信噪比、质量控制标记、生命周期和生命结束原因等的查询；对于一个天区，可以提供光谱整体质量统计分析，各环节输入输出检查。从时间角度讲，最终可以对特定时间点提供光谱所处状态的查询。

(5) 数据流检查：各处理环节能够实时获取其输入输出结果，对数据库和文件系统及各个软件进行自检和交叉检验，保证数据生产过程的可靠性。

(6) 产品封装和上线：对光谱产品进行自动化包括FITS头重写和打包在内的封装过程，同时实现与网络中心进行数据库和数据的对接，为每季度和每个正式对外释放的数据提供一个便捷的数据库。

3 系统设计与实现

要一并完成以数据库为核心的数据流设计和光谱质量控制系统，采用MySQL + PHP + Apache的架构方案。开源关系型数据库MySQL提供数据流存储，Apache网页服务器端用PHP开发的光谱人工检查与结果反馈系统为日常的光谱检查工作平台。数据库和光谱检查平台一同完成光谱质量控制。以下是所用软件：

(1) PHP5：开源、跨平台、服务器端嵌入式动态网页开发脚本语言，具有数据库访问速度快、运行效率高、性能稳定等优点，完全支持SQL标准，可以兼容绝大多数的数据库系统；

(2) Apache：目前应用最广泛的网络服务器软件，它支持多种操作系统，功能强大且完全免费；

(3) MySQL：快速、多用户、多线程的SQL数据库服务器软件，它支持标准的SQL语句，支持多种平台，提供多种客户程序接口，适用于中等规模应用，完全开源。

3.1 数据流设计

建立望远镜数据处理系统离线数据库的目的是有效维护和管理数据处理过程中的数据流，在不同的数据处理阶段，不同的软件承担不同的职责：(1)巡天战略系统的目标是为巡天观测制定观测计划，根据一个大的巡天星表，结合观测时的约束条件，寻找最佳位置，分配目标到光纤。这时需要将必要的统计信息，比如导星数量、目标数量、成功分配数量、分配天光数量、标准星数量以及标准星信息存入数据库以便程序访问。同时，二维数据处理系统在处理过程中需要利用光纤分配的一些信息，也需要在观测计划生成的同时写入该数据库。(2)观测控制系统获取原始曝光图像之后不仅把数据打包以文件夹形式传回数据中心，而且要将每次曝光的信息，如曝光时间、曝光时长、光谱仪狭缝状态以及光谱仪温度等信息写入数据库，这样二维数据处理系统在处理过程中才能获得充足的信息。(3)二维数据处理系统每处理一批原始数据，不仅将处理的中间结果、最终结果存储在文件夹中，而且要将各个目标的描述信息，包括目标对应的光谱仪号、光纤号、观测计划、所用软件版本号、处理日期、信噪比、输出文件夹路径等信息记录在数据库中。(4)一维数据处理系统通过查询数据库中二维数据处理系统输出的信息表记录来处理一维光谱数据，最终将有价值的一维光谱信息写入数据库。星系分类程序通过读取数据库中一维数据处理系统的分类结果，将指定河外数据信息读出，待程序处理完毕将结果写入数据库，供人工检查阶段参考。(5)人工检查环节的检查结果要保存下来，在后期的星表整合过程中使用。

图 2为郭守敬望远镜数据流设计图。由数据库和文件系统将各个环节有机串联起来，每个处理环节都与文件系统或者数据库进行交互。通过查询数据库和文件可以实时掌握数据处理各个环节的处理进度，追溯光谱产品，协助完成光谱质量控制。而对于人工检查环节，单独开发了一套软件，可以在线检查光谱，所有信息记录在后台数据库中。

3.2 数据库设计

在郭守敬望远镜尚未正式建成之前，文[7]设计了基于MySQL/Linux的基本的数据库原型，文[8]在先导巡天阶段根据实际数据处理情况完成了望远镜的总体数据库设计和实现。本文在此基础上优化设计了望远镜正式的数据库系统。

该数据库系统由几个子数据库组成：日常数据处理数据库、成品数据库、光谱检查数据库。其中，日常数据处理数据库用于存放日常数据流中各个环节需要用到的信息；成品数据库用于存放整合好的可以对外释放的星表，而这里面又分为最初版和正式版两个数据库；光谱检查数据库用来存放光谱人工检查的相关信息和记录。整体的数据库结构示意图如图 3。

以下简要介绍各个数据库表的设计和结构：

*日常数据处理数据库：

(1) plan_info：天区信息表，包括日期、天区名称、视宁度、月相、是否科学天区标记等信息。一条记录对应一个天区。

(2) target_info：选源信息表，存储选源信息表，一个记录对应一根光纤。一个天区的集合对应巡天战略系统的相应观测计划。该表包括目标位置、目标类型、选源来源、星等等信息。

(3) obj_info：二维目标信息表，对应二维数据处理系统抽谱的信息，包括光纤标记编号、天区名称、光谱仪号、光纤号、曝光次数、数据版本、信噪比、抽谱完成存放路径、灯谱路径、平场路径等。

(4) spec_info：一维光谱信息表，对应一维数据处理系统光谱分析结果。包括二维目标编号、一维数据处理系统软件版本号、光谱分类、红移、红移误差、置信度、二维数据处理系统光谱存放路径等信息。

(5) param_info：待测参数的光谱信息表，包括满足测量大气参数的AFGK型恒星记录。提供一维光谱编号、一维光谱路径、参数测量标记、拉平光谱存放路径等信息。

(6) cfi_param：相关函数初始值测量程序结果表，包括相关函数初始值测量程序得到的初始大气参数值及误差。

(7) cfi_param_norm：用拉平后的光谱进行相关函数初始值测量的结果表，包括相关函数初始值测量程序得到的针对拉平光谱的初始大气参数值及误差。

(8) uly_param：Ulyss参数测量结果表，包括里昂大学光谱分析软件得到的精确大气参数测量结果值。

(9) uly_param_norm：用里昂大学光谱分析软件对拉平后的光谱进行参数测量的结果信息表，包括针对拉平后的光谱进行精确的大气参数测量结果值。

(10) extragalaxy_info：待测星系或类星体光谱信息表，包括满足星系测量模块条件的所有光谱记录。提供一维光谱编号、一维光谱路径、信噪比、选源来源等信息。

(11) GQ_info：星系测量结果信息表，包括所有星系模块测量的星系或者类星体的类型、细分类、红移、置信度等信息。

(12) GM_info：星系测量结果中的星系部分信息表，结构同GQ_info。

(13) QM_info：星系测量结果中的类星体部分信息表，结构同GQ_info。

(14) fail2d：二维光谱处理系统处理失败的光谱仪信息表，包括失败光谱仪的日期、光谱仪号、天区名称、失败原因、软件版本等信息。

(15) ccd_info：CCD状态信息表，包括CCD的编号和增益。

(16) mask_info：光纤标记定义表，包括编号、类型和含义。

(17) exposure：曝光信息表，记录每次曝光的日期、开始时间、结束时间、曝光类型、狭缝状态等信息。

值得注意的是，这里仅仅是相同版本处理软件对应的表，如果从二维开始软件升级了，就会有一系列新的表产生，这样不同版本之间也可以相互比较和分析。

*成品数据库：

(1) DR*数据库：每个DR都有自己的数据库，目前从DR1到DR5共5个。

总光谱星表：整合好的所有光谱星表，包括满足发布条件的部分，通过if_release字段是否为1可以卡出来。一条记录对应一条光谱，包括选源信息、位置信息、分类、红移在内的所有关于这颗源的信息，在数据发布时，按需卡出子集和所需字段交付给信息中心。

-A型恒星星表：整合好的A型星参数星表，包括每个DR所有A型星的线指数信息。

-M型恒星星表：整合好的M型星参数星表，包括每个DR所有M型星的分子带指数信息等。

-AFGK型恒星高质量光谱参数星表：整合好的高质量的AFGK型恒星大气参数星表，包括每个DR所有AFGK型恒星的有效温度、重力加速度、金属丰度、视向速度及其误差等信息。

-天区信息表：整合好的所有观测天区信息表，一条记录对应一个天区，包括中央星位置、视宁度、曝光时间等信息。

(2) DR*最初版数据库：每年都有最初版的数据于每个季度对外释放，所以每一年对应一个最初版数据库，截止到目前共有6个，即到DR6_ALPHA。而对于每个子数据库，他们包含的数据表及结构都是一样的。

-总光谱星表：结构同DR*数据库中的总光谱星表一致。

-AFGK型恒星高质量光谱参数星表：结构同DR*数据库中的AFGK型恒星高质量光谱参数星表一致。

-天区信息表：结构同DR*数据库中的天区信息表一致。

这里没有A型恒星及M型恒星星表是因为数据发布策略规定最初版数据只提供大气参数，不用测量线指数。

*光谱检查数据库：

(1) chk_login：记录加密后的用户名和密码信息。

(2) chk_member：记录用户信息、编号、部门、权限等。

(3) check_status：记录光谱检查状态、是否完成及完成量、百分比等。

(4) spec_check：记录需要人工检查的光谱的信息，比如FITS文件读取路径等。

(5) humanverify：记录人工检查结果，包括分类、红移、是否有特殊问题等。

(6) humanrecheck：记录人工复核结果，内容主要是分类和红移。

(7) 2dprob：记录用户反馈的原始数据问题，包括杂散光、负流量、天光等问题，这种情况下需要反馈给相关工作人员进行及时处理。

对于以上数据库的具体表字段设计，本文不一一赘述，在此仅展示光谱检查数据库的逻辑设计图，如图 4，具体表信息见上文光谱检查数据库介绍。

3.3 光谱检查与结果反馈系统实现

因为郭守敬望远镜可同时观测4 000个天体，每个观测夜能得到近3万条光谱，仪器效率的不均衡加上天气、视宁度的影响导致数据质量即信噪比降低，进而使得自动分类和测量参数的结果不正确。与此同时，也存在由于分类程序升级导致的同一批原始数据分类的结果不一致。为了保证每一条光谱的分类和测量信息的准确性，需要人工经验或者专家知识的介入，由于数据量大，逐条进行光谱人工检查是不切实际的，本软件就是为了最大程度地辅助专家进行自动化的光谱检查。通过该软件，专家可以凭借自己的专业知识对每条光谱标记出他认为正确的属性信息，对于因为观测原因导致的数据不可用情况也会予以反馈，所有信息记录在后台数据库中。

3.3.1 所用软件及技术

该软件是基于浏览器/服务器(Browser/Server, BS)模式的在线网页版的检查系统。服务器端需要用到的基本软件包括：

(1) MySQL——存储后台数据库数据。

(2) PHP——用于实现动态交互式网页。

(3) Python及相应的天文软件包和科学运算包——用于远程读取光谱数据的FITS文件。

(4) Apache——网页服务器。

(5) 一台内存32 G、硬盘2 T以上的高性能服务器——用于部署上述网页服务。

客户端只需要安装浏览器就可以登录查看。

3.3.2 功能设计与实现

该系统设计为3个光谱检查部分，如图 5，(1)星系或者类星体等比较容易错分的少量的光谱检查页面(图 5(a))；(2)恒星等比较不易出错的光谱检查页面(图 5(b))；(3)按照光谱仪进行二维预览检查的页面(图 5(c))。软件主要实现以下基本功能：

(1) 用户登录，密码验证。

(2) 光谱逐条查看和结果提交，这是针对星系和类星体等河外光谱数据，需要最大化展示光谱图像供专家查看，给出正确的分类和红移结果，页面上提供细分类单选按钮供用户选择。

(3) 光谱浏览查看和结果提交，针对恒星光谱数据，只需要成批地浏览查看，对其中有误分类或者红移结果进行纠正。所有图片以日期-天区-光谱仪号-光纤号升序排序，点击其中任一幅图像，可以自动获取该图对应的id，点击提交之后可以记录目前查看的进度。

(4) 按光谱仪成批检查原始数据或者二维数据处理是否有问题并标记，如果是原始数据问题将丢弃，如果是二维数据处理问题将标记自动反馈给相关人员进行重新处理。依次点击开始光纤号和结束光纤号文本框，然后点击图片，网页自动识别光纤起止编号。当用户录入问题描述并点击提交按钮之后，该起止编号的问题光纤就记录在数据库中。

(5) 时间节点提交功能，浏览查看页面中记录用户上次查看的最后位置，以便下次接着检查而无需从头查看，而且可以统计已经检查的数量，更好地掌握检查进度。

(6) 红移测量，根据谱线匹配测量(图 5(d))。该网页用Javascript控制光谱红移的增大和减小，实时展示光谱谱线的相应变化。

(7) 检查进度查询，可以查询某些时间段的数据检查进度(图 5(e))。

(8) 二维数据处理系统检查结果响应，相关处理人员查询某些日期的用户曾经反馈的问题，确认问题并在数据库中标记，直到查询结果空白表示没有任何问题(图 5(f))。

3.3.3 系统测试

将以上功能逐一单独测试，该软件系统能顺利完成快速SQL读写，以及光谱的逐条检查或是浏览检查、红移测量等功能。

将该系统做负载能力测试，500个用户同时访问，系统比较稳定。对于数据处理机房的32台刀片机以及20多个用户来说，这种稳定性和负载能力足够。相信以后如果对服务器和硬盘等各种硬件环境升级的情况下，性能会有更大提升。

4 总结与展望

本文针对郭守敬望远镜数据处理的特点，结合数据库技术和网络技术，设计了望远镜数据处理核心数据库和数据流，开发了一套光谱质量控制系统，第1次在兼顾光谱质量控制标准的同时，为大型望远镜后期数据处理提供了数据库和数据流基础模型。望远镜二期巡天已经开始，中分辨率数据越来越多，在后续工作中，将进一步研究中分辨率数据处理和发布需求，优化现有数据流和数据库，同时将质量控制扩展到中分辨率数据处理中。