1数据库入库和管理工具AutoDB
随着天文数据的日益增加，存储和管理天文数据变得非常重要，尤其在天文数据的归档和管理方面，占有举足轻重的地位。能够很好地管理海量的天文数据就相当于在后续的科学研究中成功了一大半。通过对天文数据管理方面知识的了解，经过一系列的研究与开发，最终开发了一个高效的天文数据自动入库管理工具AutoDB，旨在帮助天文学家提高工作效率，促进天文学研究的进展。
1.1AutoDB的设计思路与方法
在之前的裴彤等人的设计中，已经实现了天文数据的自动入库，该工具采用Python[11]语言编写，并且能够自动地添加pcode字段，建立HTM（HierarchicalTriangularMesh）[11]索引分区，便于以后的交叉认证工作。HTM是一种多层次的、递归的球面分割方法，可将天球分成多级的三角网络，每个网络都有一个pocde，利用HTM可以将一个大星表从逻辑上分割为多个小星表[11]，HTM分级算法采用C语言编写，充分地利用了C语言的高性能和Python语言的高开发效率。然而该程序仅支持底层数据库为MySQL，且只支持CSV格式的文件，且文件中的数据不能为空，若为空则会抛出错误，在使用方面具有一定的局限性。其HTM分区是对ra和dec进行计算产生pcode值来实现天空分区，同时使用pcode_htmN数据列来存储这些值，然后对其进行btree索引，方便后续的高效查询。首先，其计算的算法必须跟随着后续数据的复杂性进行优化，其次，先计算在存储势必有I/0性能限制，最后使用btree一维索引间接性的对赤经ra和赤纬dec索引，无法利用天文数据的空间性，且若想实现一定半径内的查询需要非常复杂的SQL语句。为了解决这些问题，我们仔细地阅读了裴彤等人的论文和程序代码[12]，在深入分析其原理的基础上，对自动入库管理工具进行了更加全面的完善和改进：（I）底层数据库同时支持MySQL和PostgreSQL；（II）针对PostgreSQL数据库，使用一种新类型Q3C索引，其直接与数据库进行交互，无其他I/0交互，直接对赤经ra和赤纬dec进行空间索引，并且提供简单的SQL语句来实现复杂的查询；（III）数据格式同时支持FITS格式和CSV格式；（IV）数据优化，若其中存在为空的数据项，数据项自动变为’9999’或者’NULL’，则入库时不会抛出错误。下面分别展开阐述。一、底层数据库架构工具的底层数据库是基于MySQL和PostgreSQL两种数据库开发的。这两种都是非常好的开源数据库，对于选择哪种数据库更好取决于哪种数据库更能满足用户的需求。之前采用的是MySQL数据库，然而由于数据量的增加，数据表格越来越庞大，一个表格甚至达到了几十亿行，对于表本身的容量远远地超过了物理内存的大小，甚至出现了连建索引也不能改善性能的情况，这样查询时间会将大大地延长，在此情况下非常有必要对数据进行分表管理，即将表拆分为一系列较小的、与之相关联的表来进行替代，通过对子表的数据查询，就相当于对整个表进行了查询操作。对基于MySQL数据库分表来说，取决于数据引擎(InnoDB)，不支持哈希分区表，而PostgreSQL数据库支持临时表、常规表以及范围和列表类型的分区表。而且PostgreSQL的表分区是通过表继承和规则系统完成的，所以可以实现更复杂的分区方式。且在索引方面，PostgreSQL支持B-树、哈希、R-树和Gist索引，MySQL取决于数据引擎，大多数为B-Tree索引。由于天文数据具有空间属性，位置坐标为（赤经ra，赤纬dec），其索引会是一个二维的。建立一个高效的索引非常重要，使用第三方扩展库如Q3C索引即是采用的二维索引，又如使用PGSphere中的GIST索引，会使数据的查询更加高效。所以在当数据量非常大的时候，或者需要使用到第三方库时，对于空间点索引时，采用Postgresql比采用MySQL要方便得多。但若数据量不是很大，对于亿行级以下的数据量，不需要采用第三方库去支持创建索引的数据，则是采用MySQL比较好。同时MySQL的性能方面要比PostgreSQL较为高效。面对种种数据管理的需求，我们增加PostgreSQL作为该入库工具的底层数据库是必要的，天文工作者可以根据自己的需求存储到不同的数据库中。二、Q3C索引庞大的数据储存在数据库中，若想能够准确高效的使用这些数据，必须对其数据创建索引，索引不仅能够加快数据的查询速度，而且会使数据的管理变得简单容易，可以大副提高系统的性能。当然索引的创建也不是越多越好，因为索引过多会随着数据量的增加而加大数据库的负荷，就起不到提高系统的性能的作用，反而会降低性能，所以索引的使用要准确得当。在本系统中，由于我们是对天文数据进行入库管理，天文数据的复杂性、空间性决定了普通的一维索引并不能很好地解决天文数据的查询管理要求，所以我们是用了一个全新Q3C(QuadTreeCube)对天空分区索引，其能够很好地对天文数据进行二维的空间索引，Q3C索引方案为开源项目运用于数据库PostgreSQL中，大家在使用的同时也可以随时进行修改，非常适用于学术研究，由于直接运用于数据库，使用者不需要书写任何算法，相比于HTM，首先需要对天文数据进行分区计算pcode值，然而分区计算算法需要由使用者编写，这样会无形地增加风险，同时也带来了复杂化。Q3C的产生是专门针对天文数据的，其目的性非常明确。虽然普通的索引如btree也能够用于天文数据，但是如果需要进行锥形查询，在不使用Q3C索引的前提下，其查询SQL语句会非常复杂，并且查询速度非常慢，而且也只能运用于数据量较少的情况下，数据过多极有可能导致内存不足而出现程序卡死现象，然而上面的问题对于Q3C索引来说都不存在，所以这种基于四叉树的空间索引Q3C就显得非常实用了。Q3C索引不仅能够提供天文数据特有的查询，而且也提供交叉认证功能，这对以后的数据处理来说，很大程度地简化了工作量，同时又容易使用，而且不论是在查询方面，还是交叉认证方面，Q3C会提供的简单的SQL语句就能够执行处理工作，而HTM方面则需要从数据库中提取数据，然后利用算法进行处理，当数据量非常大的时候，程序的性能就会受到影响。三、支持的数据文件格式入库管理工具同时支持两种类型的数据格式文件：CSV(Comma-SeparatedValues)格式文件和FITS(FlexibleImageTransportSystem)格式文件。CSV文件由任意数目的记录组成，记录间以某种换行符分隔；每条记录由字段组成，字段间的分隔符是其它字符或字符串，最常见的是逗号或制表符。FITS格式是天文学界常用的数据格式，它专门为在不同平台之间交换数据而设计。1988年的国际天文学联合会IAU（InternationalAstronomicalUnion）大会指定IAU的FITS工作组全权负责此格式的修订。FITS文件由文件头和数据组成。在文件头中存储有对该文件的描述，如观测目标、源的位置、观测时间、曝光时间等信息，同时也可以在文件头中注明观测时的视场、精度等，便于后期的数据管理和分析之用。文件头部分每行占80个字符，并以END结尾。FITS文件的容量大小通常比相同数据量的CSV文件小，在本地存储中占用硬盘容量小，且天文数据文件采用FITS格式存储的文件占大多数。针对FITS格式文件数据，我们开发了一个分析FITS文件头文件的工具，用来得到头文件中表格数据中的列名和每个列对应的数据格式，方便天文学家在使用入库工具时编写readme文件。在输入不同格式文件时，工具会自动地判断文件的格式选择相应的程序实现自动入库。四、存储数据的优化庞大的天文数据中有时难免会存在的超过数据库中最大数据存储大小的数据或者小于数据库中支持的最小数据，不过在数据库中可以自己定义数据类型来支持导入的数据，但这样便失去兼容性了，使得不同数据库之间数据的交换和融合变得很困难，而且在对于文件中的数据项为空的时候，存储到数据库中会产生一些错误，所以在入库之前很有必要先对数据进行优化。因为不符合要求的数据非常少，而且改变其大小不会影响到后续的数据分析环节，故在入库前，在程序中把超出数据库最大支持数据的记录数和小于数据库最小支持数据的记录数更改为数据库所支持最大和最小的数据记录数，同时对于文件中为空的数据项，程序会根据数据类型的不同，自动的填充‘9999’或‘NULL’字样，方便数据的录入和后续的计算分析。
1.2AutoDB流程图
在存储FITS格式文件的数据时，我们还专门开发了一个分析FITS文件头文件的小工具，方便天文学家存储时选择自己想要存储的数据列。在使用过程中，天文学家也不需要编写任何的代码，同时该工具有很好的易用性。根据不同的格式文件，有着不同的入库流程，下面给出了文本CSV文件和FITS文件的入库流程，如图1所示。
1.3AutoDB系统环境支持
AutoDB采用Python语言编写，推荐使用Linux操作系统。由于Python是跨平台型语言，若需要在WINDOWS系统中使用也非难事，需要安装Python，一般的Linux发行版本都会自带Python程序，同时也需要下列数据库系统（异地或本地均可）和第三方库作为支持：1)PostgreSQL(9.0+)：支持最新的SQL语法，更高的功能完整性。2)MySQL（5.1+）：性能非常的高效。3)Q3C（QuadTreeCube）：一种基于PostgreSQL数据库的新的天文数据的索引概念，提供海量天文数据的查询与融合。该工具中同时嵌入了一个很好的虚拟终端，用户可以根据虚拟终端的反馈，了解自己在使用过程中出现了哪些错误，从而纠正错误，使得程序完美地运行。
1.4AutoDB图形用户界面
AutoDB图形入库界面如2所示，用户可以选择入哪种数据库，入库的数据文件及数据的说明文件，创建HTM的级数，每次分次上传的记录数，赤经赤纬列要指出等。在这里，用户可以直接点击程序运行图形界面，也可以手动地在命令行中使用命令来运行图形界面，其图形界面和主程序是分开的，其协助用户按照各个参数，并收集起来，按照一定的规范得到收集的参数，供主程序使用。也就是说主程序不依赖于图形界面，用户也可以手动地编辑被指定的文件来运行主程序。FITS头文件分析工具会把FITS头中的数据输出到文件中，该文件名由用户定义，在FITSSOURCEFILE对应的一行中浏览添加FITS源文件，然后在FITSHEADFILE一行中输入想要创建FITS头文件名，界面如下图3所示。在使用入库工具时，用户需要编写readme文件供程序使用，其格式如下：第一行为各列列名（即数据库表中的列名字段，请参照MySQL/PostgreSQL对字段命名相关文档），以一个或者多个空行分隔；第二行与第一行相对应，为每列的数据类型（如：float、char、varchar、double、int，具体请参照MySQL/PostgreSQL数据类型相关文档[13]），同样是以一个或者多个空行分隔，内容中不能有引号，字段不能为空或NULL。同时在对FITS文件进行入库时，需要参照头分析工具得出的头文件以及格式转换文件编写readme文件。头文分析工具得到的头文件实例如图4所示，格式转换文件如图5所示。编写readme文件完毕后，即可使用自动入库工具进行数据的录入，数据库可以自己选择，数据库服务器可以是本地服务器或远程服务器。使用远程服务器时，应该保证远程服务器支持远程连接，否则将会报错。
2实验结果
2.1Q3C索引与非Q3C索引的查询性能比较
在使用索引的时候，我们最在意的是索引是否能够提高查询效率，对于具体选择哪种索引方式，要看哪种索引提高的性能更高些。为此我们做了如下的实验测试（在数据库命令行的形式下使用SQL语句进行查询的实验）。实验数据为Pan-STARRS数据，总共11,495,847个星表源数据。对比使用Q3C索引情况下和不使用Q3C索引（对ra与dec进行B-tree索引）的情况下，实现以赤经赤纬（5度,50度）为中心，查询半径在0.1度到0.9度变化范围内的锥形查询，比较随着提取结果源数目的增多上述两种方案的查询时间，其结果如图6和图7所示。我们从图7和图8中可以看出，随着查询半径的增大，符合查询条件的源数目也在不断增多，同时查询时间以近乎线性速度增长，说明查询元组数目越多，消耗的时间也就越多。还发现使用非Q3C索引的查询时间是使用Q3C索引时间的至少100多倍以上，可见Q3C索引方式的有效性。Q3C索引具有层次结构、平等区域、异维度分布等特性的天空分区方案，对天文数据的处理具有得天独厚的优势。特别是对于数据量大的情况下，我们非常有必要使用Q3C对数据索引，其表现不仅仅是数据查询速度的提高，对日后的交叉认证起到了打下了很好的基础。这也正是我们选择Q3C索引的原因。
2.2AutoDB工具的应用
AutoDB能够快速地将数据存储到相应的数据库中，上传数据的速度与本地机器硬件性能、数据库的配置以及数据库服务器的位置（本地或异地）、数据量的多少以及索引的复杂程度都有着直接或间接的关系。建议在使用过程中本地机器中不要运行太多的其他程序。我们使用的是SDSS部分数据进行的实验，总共有100,000,000行数据导入数据库中，测试平台使用的是两台计算机平台，一个是本地数据库平台和程序运行平台，另外一个是远程数据库运行平台，通过百兆以太网访问远程数据库平台。具体配置如表1所示。在实验过程中多次分别对本地和远程数据库进行了入库，在入库时将数据分割为100,000,00行，200,000,00行，400,000,00行，600,000,00行，800,000,00行，100,000,000行数据导入数据库中，得出实验结果，如表2所示。单从数据上传的速度来看，MySQL数据库的速度要优于PostgreSQL数据库。
3总结与展望
针对当前天文大数据的特点，我们致力于开发高效、易用的海量天文数据自动入库工具。考虑到天文数据的海量性、分布性等特点，我们分析了现有的入库工具的优缺点，总结了前人的设计成果，结合实际需求，应用了高效的Q3C索引方案，改进开发了一个更加高效的大型天文数据自动入库工具AutoDB，同时也参照了国际上SAADA工具的功能。该工具能够更好地协助天文工作者方便地存储、管理和处理数据。为后续研究工作中的数据融合、分析与挖掘做出了很好的铺垫，是海量异地异构多波段天文数据融合和挖掘工作的根本保障。AutoDB还有很多需要值得改进的地方，因为我们底层数据库的设计是基于MySQL和PostgreSQL，所以用户的数据库选择方面只能选择MySQL和PostgreSQL，这点对于用户来说就有点局限性。在自动入库的工作中，数据库的性能是一个不能忽视的方面，性能是否良好会直接影响CPU的利用率，所以非常有必要对数据库性能进行调优，在数据量非常大的时候，除了对数据表进行分表以外，也可以对数据库内存进行调整，来达到最适合当前CPU工作的状态内存容量，同时也可以安装一些数据库的监控工具和趋势预测软件，如vmstat、iosta、top、Munin等等，对数据库进行实时的监控，保证数据库在任何时刻都处于高效状态。在程序的编写方面，我们使用的是INSERT语句对文件的数据进行上传的，而没有使用更加高效的数据库自己所带的专有命令，如PostgreSQL的copy命令，这样势必会影响数据的插入速度和效率，由于专有命令没有一个接口程序去引用，这个我们会在后续的工作中进一步研究。参照SAADA工具的设计思路和优点，如SAADA工具支持大部分的关系数据库，SAADA不仅可以建数据库，而且可以收集不同的数据进行整合分析，同时能够将整理好的数据发布在web中真正地实现了数据的共享，下一步工作，我们也会根据需求进一步实现基于web服务，实现网页建库和网页查询，这样工具使用起来就会更加的方便，也会根据大家使用的情况反馈来进一步地加以改进和提高。当然一个设计好的工具永远不是尽善尽美的，结合不断变化的需求，工具也要随之调整，从而一步一步地健壮起来，这样才能够与时俱进，不断地促进天文学研究的发展。
作者：钟守波 韩波 张彦霞 赵永恒 何勃亮 单位：武汉大学国际软件学院 中科院光学天文重点实验室
