萬　萌，吳　潮，Ying Zhang，徐　洋，魏建彥

(1. 中國科學(xué)院國家天文臺(tái)，北京　100012；2. 中國科學(xué)院大學(xué)，北京　100049；3. 荷蘭國家數(shù)學(xué)與計(jì)算機(jī)科學(xué)研究中心，阿姆斯特丹　1098 XG)

?

GWAC海量星表數(shù)據(jù)處理的數(shù)據(jù)庫系統(tǒng)選型研究*1

萬萌1,2,3，吳潮1，Ying Zhang3，徐洋1，魏建彥1

(1. 中國科學(xué)院國家天文臺(tái)，北京100012；2. 中國科學(xué)院大學(xué)，北京100049；3. 荷蘭國家數(shù)學(xué)與計(jì)算機(jī)科學(xué)研究中心，阿姆斯特丹1098 XG)

摘要：為應(yīng)對(duì)我國的寬視場(chǎng)地基廣角相機(jī)陣在大數(shù)據(jù)管理和實(shí)時(shí)處理上帶來的挑戰(zhàn)，提出一種基于列存儲(chǔ)數(shù)據(jù)庫MonetDB的時(shí)序數(shù)據(jù)處理與管理系統(tǒng)設(shè)計(jì)方案。本方案充分利用MonetDB兼具數(shù)據(jù)處理和管理于一體的數(shù)據(jù)庫平臺(tái)特點(diǎn)，通過將交叉認(rèn)證等核心數(shù)據(jù)處理算法內(nèi)嵌于數(shù)據(jù)庫中，從而實(shí)現(xiàn)將 “計(jì)算帶到數(shù)據(jù)中” 的設(shè)計(jì)理念。同時(shí)，對(duì)本方案開展了多項(xiàng)關(guān)鍵技術(shù)的研究與測(cè)試：TPC-H基準(zhǔn)性能測(cè)試；大數(shù)據(jù)加載能力測(cè)試及優(yōu)化研究；基于MonetDB的Zone算法實(shí)現(xiàn)與測(cè)試；可定制函數(shù)開發(fā)功能的測(cè)試。初步的預(yù)研結(jié)果表明，列存儲(chǔ)切實(shí)可行，同時(shí)對(duì)本設(shè)計(jì)方案作詳細(xì)的介紹。提出的基于列存儲(chǔ)MonetDB數(shù)據(jù)庫設(shè)計(jì)的海量星表數(shù)據(jù)處理應(yīng)用方案，是高效的數(shù)據(jù)處理與管理為一體的天文數(shù)據(jù)庫解決方案。

關(guān)鍵詞：天文數(shù)據(jù)庫；架構(gòu)設(shè)計(jì)；MonetDB；實(shí)時(shí)分析；交叉認(rèn)證

現(xiàn)代天文觀測(cè)和數(shù)據(jù)處理技術(shù)的發(fā)展，使得時(shí)域天文觀測(cè)朝著更大的視場(chǎng)和更高的時(shí)間采樣率方向發(fā)展成為可能，也給現(xiàn)代時(shí)域天文觀測(cè)注入了新的活力，如超新星尤其是爆發(fā)早期超新星的發(fā)現(xiàn)，伽瑪暴光學(xué)余輝的快速響應(yīng)觀測(cè)，微引力透鏡事件的發(fā)現(xiàn)與后隨觀測(cè)等都得益于現(xiàn)代時(shí)域天文觀測(cè)和數(shù)據(jù)處理技術(shù)的發(fā)展。

我國興建中的地面廣角相機(jī)陣(Ground Wide Angle Camera, GWAC)，由36臺(tái)口徑為18 cm的廣角望遠(yuǎn)鏡組成，每臺(tái)望遠(yuǎn)鏡配備4 k × 4 k的CCD探測(cè)器。整個(gè)相機(jī)陣的天區(qū)覆蓋5 000平方度，時(shí)間采樣率為15 s。每個(gè)觀測(cè)夜對(duì)固定天區(qū)目標(biāo)的持繼觀測(cè)長達(dá)4～5 h。從觀測(cè)視場(chǎng)的大小和觀測(cè)時(shí)間的采樣頻度上，地面廣角相機(jī)陣在時(shí)域天文觀測(cè)中具有特殊的優(yōu)勢(shì)。巨大的數(shù)據(jù)量和高時(shí)間采樣率，對(duì)數(shù)據(jù)的管理和處理提出極大的挑戰(zhàn)。

地面廣角相機(jī)陣的星表數(shù)據(jù)指標(biāo)是：星表數(shù)據(jù)每幅圖像大約有1.5 × 105條記錄，整個(gè)相機(jī)陣在15 s內(nèi)共產(chǎn)生5.4 × 106條記錄，每晚約有2 400 × 36=86 400幅圖，大約2 TB。對(duì)數(shù)據(jù)庫管理系統(tǒng)的要求：(1)快速的大數(shù)據(jù)入庫能力，所有相機(jī)陣15 s內(nèi)產(chǎn)生的觀測(cè)星表入庫時(shí)間控制在15 s以內(nèi)，每個(gè)觀測(cè)夜的2 TB星表最晚完成入庫時(shí)間保證在下一個(gè)觀測(cè)夜開始前；(2)在數(shù)據(jù)高速采集下能夠完成實(shí)時(shí)分析，面對(duì)持續(xù)不斷的高密度海量星表的快速關(guān)聯(lián)計(jì)算能力，即每個(gè)CCD每15 s產(chǎn)生的星表數(shù)據(jù)與參考星表相關(guān)聯(lián)形成光變曲線。

對(duì)于地基廣角相機(jī)陣，最直接的數(shù)據(jù)庫管理和處理系統(tǒng)的設(shè)計(jì)方案是數(shù)據(jù)庫(僅為數(shù)據(jù)存儲(chǔ))+外圍的程序(完成快速的運(yùn)算)。文[1]通過對(duì)關(guān)鍵技術(shù)交叉認(rèn)證的研究開發(fā)了基于空間等經(jīng)緯網(wǎng)格的天區(qū)分區(qū)算法，使得交叉認(rèn)證計(jì)算實(shí)現(xiàn)了極大的提速；利用圖形處理器的平行計(jì)算優(yōu)勢(shì)，文[2]實(shí)現(xiàn)了圖形處理器加速圖像相減處理的方法；文[3]開發(fā)了利用圖形處理器加速天文中常用的點(diǎn)源提取程序SEXtractor；文[4]開發(fā)了基于圖形處理器的加速星表的交叉認(rèn)證算法，該方案的好處是思路直接，許多技術(shù)是成熟的，缺點(diǎn)是數(shù)據(jù)庫不斷與處圍程序交換，帶來不必要的輸入輸出時(shí)間損耗，多方程序組合缺少整體的優(yōu)化。

著名數(shù)據(jù)庫專家Jim Gray成功開發(fā)了SDSS巡天數(shù)據(jù)庫管理系統(tǒng)Skyserver，他提出了Zone算法*①http://research.microsoft.com/apps/pubs/default.aspx?id=64524②https://arxiv.org/ftp/cs/papers/0408/0408031.pdf，即利用數(shù)據(jù)庫的SQL直接實(shí)現(xiàn)多維空間索引取代經(jīng)典的分層三角網(wǎng)格算法(Hierarchical Triangular Mesh, HTM)，從而減少數(shù)據(jù)的交互，速度得到提升。這就是大規(guī)?？茖W(xué)計(jì)算和數(shù)據(jù)庫架構(gòu)設(shè)計(jì)的原則：將計(jì)算帶到數(shù)據(jù)中來，而不是把數(shù)據(jù)放到計(jì)算中去的設(shè)計(jì)理念[5]。受這一思想的啟發(fā)，提出將地基廣角相機(jī)陣的數(shù)據(jù)處理和數(shù)據(jù)管理合成到一個(gè)數(shù)據(jù)庫平臺(tái)的設(shè)計(jì)思路。

合適的數(shù)據(jù)庫平臺(tái)是實(shí)現(xiàn)這一設(shè)計(jì)思想的關(guān)鍵，因?yàn)閭鹘y(tǒng)的數(shù)據(jù)庫平臺(tái)不具備大數(shù)據(jù)快速處理的能力。LSST項(xiàng)目針對(duì)天文大數(shù)據(jù)的需求提出開發(fā)全新的數(shù)據(jù)庫SciDB，因?yàn)樘幱陂_發(fā)活躍期，SciDB的穩(wěn)定性和實(shí)用性還有待檢驗(yàn)。MonetDB是一款開源的內(nèi)存列存儲(chǔ)數(shù)據(jù)庫平臺(tái)*http://www.monetdb.org，具有內(nèi)部存儲(chǔ)模型按列分塊、占用存儲(chǔ)空間小、運(yùn)行時(shí)查詢優(yōu)化等優(yōu)勢(shì)。MonetDB底層物理存儲(chǔ)模型與傳統(tǒng)數(shù)據(jù)庫有非常顯著的不同，關(guān)系表經(jīng)過垂直切分，每一列存儲(chǔ)在一個(gè)單獨(dú)的(ID, value)鍵值對(duì)表中，稱作二元關(guān)系 表(Binary Association Table, BAT)。二元關(guān)系表左邊一列，叫做頭部，是對(duì)象ID(OID)；右側(cè)一列叫尾部，包含屬性的值。頭部和尾部分別用一個(gè)數(shù)組實(shí)現(xiàn)。使用列存儲(chǔ)數(shù)據(jù)庫的方式使得查詢語句的執(zhí)行只需要訪問用到的列。當(dāng)同一類型的屬性存在于連續(xù)內(nèi)存，可以獲得較高的壓縮比和緩存命中率。同時(shí)，MonetDB的內(nèi)核是建立在類 “array” 結(jié)構(gòu)上的可編程的關(guān)系代數(shù)機(jī)，這種友好的結(jié)構(gòu)能最大限度地利用硬件的性能實(shí)時(shí)響應(yīng)用戶的需求。而且，MonetDB執(zhí)行引擎中緩存敏感的數(shù)據(jù)結(jié)構(gòu)算法可以在運(yùn)行時(shí)優(yōu)化多級(jí)內(nèi)存系統(tǒng)。

可以看出，表的數(shù)據(jù)量越大，尤其是當(dāng)查詢語句比重越大，就越適合使用列存儲(chǔ)數(shù)據(jù)庫。因?yàn)槿绻麛?shù)據(jù)量很大，而查詢?cè)L問的列比很小，即所有查詢語句訪問的列數(shù)和總列數(shù)的比例越小，使用列查詢?cè)侥芙档蚐QL語句查詢時(shí)間，越適合使用列存儲(chǔ)。

綜上所述，MonetDB適合要求快速取回結(jié)果的海量數(shù)據(jù)分析型在線分析處理(Online Analytical Processing, OLAP)的應(yīng)用和存儲(chǔ)，這與地面廣角相機(jī)陣需要提供的查詢服務(wù)屬于同一類型，非常適合應(yīng)用于天文數(shù)據(jù)庫。

大型射電望遠(yuǎn)鏡巡天項(xiàng)目低頻陣列(Low-Frequency Array, LOFAR)利用MonetDB完成了數(shù)據(jù)處理系統(tǒng)TKP pipeline，其星表數(shù)據(jù)一年約為40 TB[6]；SDSS的SQL Server管理數(shù)據(jù)庫曾被成功移植到MonetDB上[7]，并通過了對(duì)斯隆數(shù)字巡天項(xiàng)目中的SDSS BESTDR7近4 TB數(shù)據(jù)的管理測(cè)試。因此選取列存儲(chǔ)數(shù)據(jù)庫MonetDB作為系統(tǒng)的開發(fā)平臺(tái)。

為研究和驗(yàn)證以上設(shè)計(jì)思路的可行性，根據(jù)地基廣角相機(jī)陣數(shù)據(jù)處理流程(如圖1)開展了TPC-H基準(zhǔn)性能測(cè)試以驗(yàn)證其載入和分析能力，大數(shù)據(jù)加載速度的測(cè)試與研究。通過MonetDB的自定義函數(shù)接口功能測(cè)試實(shí)際自定義函數(shù)的開發(fā)功能；核心算法交叉認(rèn)證條帶(Zone)算法在MonetDB上的實(shí)現(xiàn)與測(cè)試。最后，詳述了基于MonetDB的海量星表數(shù)據(jù)管理和處理的初步方案。

圖1地基廣角相機(jī)陣數(shù)據(jù)處理流程圖

Fig.1The flow chart of GWAC data processing

1TPC-H基準(zhǔn)測(cè)試與比較

為測(cè)試MonetDB的實(shí)際表現(xiàn)，進(jìn)行了TPC-H基準(zhǔn)測(cè)試并比較了與傳統(tǒng)數(shù)據(jù)庫平臺(tái)PostgreSQL及MySQL的差異。TPC-H是模擬決策支持類應(yīng)用的一個(gè)測(cè)試集。天文數(shù)據(jù)庫日常提供的服務(wù)也屬于數(shù)據(jù)分析類應(yīng)用，適合選擇TPC-H作為測(cè)試集。

TPC-H測(cè)試包括22條選擇查詢語句。測(cè)試流程為先用DBGEN工具產(chǎn)生測(cè)試數(shù)據(jù)，加載程序裝載數(shù)據(jù)到3種數(shù)據(jù)庫后，數(shù)據(jù)庫處于初始狀態(tài)，未進(jìn)行其他任何操作。此時(shí)將22條查詢順序執(zhí)行一遍，分別記錄3種數(shù)據(jù)庫22條查詢的總響應(yīng)時(shí)間。測(cè)試環(huán)境同上，MySQL版本為5.6.16。測(cè)試環(huán)境具體情況如表1。

圖2為MonetDB和PostgreSQL、MySQL的TPC-H SF=1(1 GB)數(shù)據(jù)量基準(zhǔn)性能測(cè)試結(jié)果對(duì)比，具體代碼見*https://github.com/hlfwm/TPC-H?？梢钥闯?2條查詢總時(shí)間MonetDB消耗只有PostgreSQL的約1/15，MySQL的1/137，單條查詢提速至少3倍。造成查詢響應(yīng)時(shí)間存在較大差異的主要原因是TPC-H業(yè)務(wù)類型是在線數(shù)據(jù)分析類型，數(shù)據(jù)量大，查詢語句比重大，復(fù)雜的查詢多，符合適合列存儲(chǔ)數(shù)據(jù)庫的典型指標(biāo)。表的數(shù)據(jù)量越大，就越適合使用列存儲(chǔ)數(shù)據(jù)庫，尤其是當(dāng)查詢語句比重也很大時(shí)，則使用列查詢能顯著降低SQL語句查詢的時(shí)間。如果查詢?cè)L問的列比，即所有查詢語句訪問的列數(shù)和總列數(shù)的比例越小，越適合列存儲(chǔ)。這解釋了對(duì)于大表Lineitem上的連接、且查詢?cè)L問列比低的查詢的Q18、Q19、Q21，MonetDB響應(yīng)速度領(lǐng)先數(shù)十倍的原因?？梢奙onetDB列存儲(chǔ)數(shù)據(jù)庫在分析式查詢時(shí)具有較強(qiáng)優(yōu)勢(shì)。MonetDB在TPC-H測(cè)試中的表現(xiàn)相對(duì)于MySQL和PostgreSQL具有明顯的優(yōu)勢(shì)，MySQL表現(xiàn)最差，而PostgresSQL居中。

表1　測(cè)試環(huán)境具體情況表

圖2MonetDB和PostgreSQL、MySQL TPC-H 1 G基準(zhǔn)測(cè)試

Fig.2Benchmark results of MonetDB, PostgreSQL, MySQL TPC-H 1G

2關(guān)鍵算法與功能分析測(cè)試

根據(jù)地基廣角相機(jī)陣數(shù)據(jù)處理需求，處理速度要求在15 s的采樣時(shí)間間隔內(nèi)完成數(shù)據(jù)的所有處理；功能上要求匹配出瞬變?cè)床⒛苌晒庾兦€。進(jìn)行如下關(guān)鍵算法和功能的測(cè)試：大數(shù)據(jù)的加載能力；交叉認(rèn)證算法的實(shí)現(xiàn)；擴(kuò)展處理功能的開發(fā)實(shí)現(xiàn)。

2.1大數(shù)據(jù)加載測(cè)試

大數(shù)據(jù)加載測(cè)試主要分為兩種情況。測(cè)試(1)：數(shù)據(jù)庫隨著加載數(shù)據(jù)量的增加對(duì)加載速度的影響；測(cè)試(2)：影響加載速度因素的測(cè)試分析。

測(cè)試(1)的方法為通過仿真1 000個(gè)20列 × 20萬行*實(shí)際情況每幅圖像產(chǎn)生15萬條星表記錄，為進(jìn)行壓力測(cè)試，這里選取20萬條記錄。類似于實(shí)際觀測(cè)的星表數(shù)據(jù)，連續(xù)加載到被測(cè)試的數(shù)據(jù)庫中，分析加載速度的變化。測(cè)試平臺(tái)的軟硬件環(huán)境如圖3。測(cè)試的具體實(shí)現(xiàn)過程：對(duì)仿真的星表，使用大文件導(dǎo)入庫命令COPY BINARY INTO：

COPY BINARY INTO tablename FROM(′path_to_file_0′, ′path_to_file_1..,′path_to_file_19′);

分別對(duì)MonetDB和PostgreSQL進(jìn)行加載能力的對(duì)比。圖3是對(duì)MonetDB進(jìn)行數(shù)據(jù)加載測(cè)試的結(jié)果，圖4是PostgresSQL的測(cè)試結(jié)果。對(duì)比兩圖得出如下結(jié)論：(1)MonetDB隨著數(shù)據(jù)庫單表數(shù)據(jù)的增加，對(duì)注入的速度無明顯影響，平均每個(gè)星表文件數(shù)據(jù)的載入時(shí)間為0.94 s。而PostgresSQL則在載入500個(gè)星表文件后，速度明顯降低，平均載入速度為6.0 s。MonetDB沒有出現(xiàn)速率陡降現(xiàn)象，這與MonetDB是內(nèi)存數(shù)據(jù)庫相關(guān)，表現(xiàn)在磁盤存取、內(nèi)外存的數(shù)據(jù)傳遞、緩沖區(qū)管理、排隊(duì)等待及鎖的延遲方面均比磁盤數(shù)據(jù)庫快很多。(2)MonetDB每隔幾十個(gè)文件會(huì)有一個(gè)突跳點(diǎn)，加載時(shí)間突然提高至10 s左右。主要原因是由于MonetDB需要時(shí)間將數(shù)據(jù)寫到磁盤，而導(dǎo)致的輸入輸出開銷。這是在今后使用中需要解決的一個(gè)問題，希望能通過提高數(shù)據(jù)寫入硬盤的頻度來解決。

測(cè)試(2)的目標(biāo)：對(duì)MonetDB進(jìn)行更大量星表數(shù)據(jù)的壓力加載測(cè)試，以測(cè)試在大數(shù)據(jù)下的數(shù)據(jù)加載性能。

圖3MonetDB單表數(shù)據(jù)加載測(cè)試

Fig.3Load test of MonetDB′s single table

圖4PostgreSQL單表數(shù)據(jù)加載測(cè)試

Fig.4Load test of PostgreSQL′s single table

測(cè)試方法：仿真星表86400個(gè)，每個(gè)星表約175,000行，包含22列屬性數(shù)據(jù)。每個(gè)列文件大小為1.4 M，數(shù)據(jù)量總共2.47 TB。按順序不斷往數(shù)據(jù)庫注入星表數(shù)據(jù)。

測(cè)試平臺(tái)：CPU: 2 sockets Intel Xeon CPU E5-2690 v2 @ 3.00 GHz. 40 processor；內(nèi)存: 8 × 16 GB；操作系統(tǒng): Scientific Linux release 6.5，Linux kernel: 2.6.32-358.el6.x86_64。

測(cè)試結(jié)果如圖5，載入速度基本是緩慢的線性變化。平均每個(gè)星表的載入時(shí)間1.75 s，總載入時(shí)間42 h。86400個(gè)星表相當(dāng)于36個(gè)CCD向一個(gè)數(shù)據(jù)表注入，所以實(shí)際使用應(yīng)比壓力測(cè)試的結(jié)果還要好。

在測(cè)試過程中還發(fā)現(xiàn)一個(gè)現(xiàn)象：MonetDB的數(shù)據(jù)載入速度與星表文件大小有一個(gè)反常的關(guān)系，16 MB星表文件的載入整體速度要比1.34 MB星表數(shù)據(jù)快2.5倍，具體關(guān)系見圖6。主要原因是較大的文件讀取單元可以更好地利用磁盤輸入輸出，從而提高了文件的載入速度。對(duì)于地面廣角相機(jī)陣，每個(gè)星表數(shù)據(jù)列文件約1～2 MB，因此，存在進(jìn)一步優(yōu)化的空間，在實(shí)際使用中需要通過調(diào)整MonetDB內(nèi)置參數(shù)對(duì)比進(jìn)行優(yōu)化。

圖5MonetDB 86400個(gè)二進(jìn)制星表，單表數(shù)據(jù)加載累加時(shí)間曲線

Fig.586400 binary catalogs of MonetDB, loading time curve of single table data

圖6MonetDB不同數(shù)據(jù)塊，10008個(gè)二進(jìn)制星表，單表數(shù)據(jù)加載速度測(cè)試

Fig.6Different MonetDB data block, 10008 binary catalogs, loading speed test of single table data

2.2交叉認(rèn)證算法的實(shí)現(xiàn)

交叉認(rèn)證是地面廣角相機(jī)陣巡天中搜索瞬變?cè)春凸庾兦€生成的關(guān)鍵算法。交叉認(rèn)證問題必須依靠有效的分區(qū)策略，通過將天區(qū)按赤緯進(jìn)行條帶分區(qū)，將天區(qū)劃分成一個(gè)個(gè)水平條帶，每個(gè)源有一個(gè)屬于自己的條帶屬性，交叉認(rèn)證前首先比較條帶屬性可以大大降低比較次數(shù)。條帶可集成到數(shù)據(jù)庫內(nèi)部，減少了數(shù)據(jù)輸入輸出的時(shí)間損耗。

表2是一個(gè)mini-GWAC*Mini-GWAC是地基廣角相機(jī)陣的前導(dǎo)項(xiàng)目，由12臺(tái)8 cm的大視場(chǎng)相機(jī)組成，現(xiàn)已建成安放于國家天文臺(tái)興隆觀測(cè)站。用到的實(shí)際星表案例，MonetDB在16 GB內(nèi)存的服務(wù)器上所作的20″半徑誤差內(nèi)交叉認(rèn)證的測(cè)試結(jié)果，條帶高度20″。測(cè)試環(huán)境為：Intel Core i7-2600K CPU Quad-Core @ 3.40 GHz, 8 M Cache, 4 GB內(nèi)存，Scientific Linux 6.4，linux kernel 2.6.32，MonetDB Jan2014版本和PostgreSQL 9.3.0版本。

使用的SQL語句為

select x0.id as id1, t0.id as id2 from extractedcatalog x0, template t0

where x0.zone between floor(t0.decl-0.0056) and floor(t0.decl+0.0056)--zone filter

and x0.decl between t0.decl-0.0056 and t0.decl+0.0056--dec filter

and 3600*DEGREES(2*ASIN(SQRT((x0.x-t0.x)*(x0.x-t0.x)+(x0.y-t0.y)*(x0.y-t0.y)

+(x0.z-t0.z)*(x0.z-t0.z))/2))<20; --accurate computation

表2測(cè)試結(jié)果表明，同樣使用條帶算法，MonetDB Jan2014比PostgreSQL加速比達(dá)17倍。同時(shí)，測(cè)試兩個(gè)具有17萬條記錄的星表進(jìn)行交叉認(rèn)證，所需時(shí)間大約為4.3 s。

2.3用戶自定義函數(shù)功能測(cè)試

MonetDB提供了用戶自定義函數(shù)(User Defined Functions, UDF)對(duì)外接口以利于擴(kuò)展內(nèi)核功能，用戶可以靈活地根據(jù)實(shí)際需要添加自定義函數(shù)。MonetDB裝配語言的多層架構(gòu)結(jié)構(gòu)如圖7。用戶自定義函數(shù)層首先被MAL解釋器識(shí)別(MonetDB Assembly Language，SQL語句解析成MAL，提供給內(nèi)核執(zhí)行)，然后由SQL 編譯器識(shí)別。為了大批量數(shù)據(jù)導(dǎo)入，開發(fā)了UDF Columncopy，直接將ASCII文件導(dǎo)入底層列存儲(chǔ)單元(Binary Association Table, BAT)。

表2MonetDB、PostgreSQL有無zone1.5萬 × 1.2萬條交叉認(rèn)證

Table 215k × 12k rows of cross-match MonetDB Postgres with/without zone

CatalogueA15218rowsCatalogueB12540rowsMatchedrows/條time/sMonetDBFeb2013版無zone12027302MonetDBFeb2013版+zone120274.2MonetDBJan2014版無zone12027238MonetDBJan2014版+zone120271.8PostgreSQL9.3.0版+zone1202730.8

圖7MonetDB架構(gòu)及與用戶定義函數(shù)的關(guān)系

Fig.7The architecture of MonetDB and its relationship with UDF

自定義函數(shù)Columncopy的實(shí)現(xiàn)過程如下(開發(fā)語言為C語言)：

(1) 81_svom.mal文件用于MonetDB服務(wù)器啟動(dòng)時(shí)自動(dòng)加載這個(gè)用戶自定義函數(shù)；

(2) 81_svom.sql文件向SQL函數(shù)列表加入columncopy函數(shù)簽名，也用于自動(dòng)加載；

(3) Makefile.ag向編譯器引入新模塊依賴的庫文件信息；

(4) svom.c, svom.h為用戶自定義函數(shù)實(shí)現(xiàn)文件；

函數(shù)解釋_append_bat(sql,t,cname,b)將結(jié)果BATb追加到表t某列后。BATnew(TYPE_void,TYPE_int,nr_rows);創(chuàng)建一個(gè)二元關(guān)系表。columncopy(tablename,columnname,columnrows,filename)SQL函數(shù),將文件filename里的column-rows行導(dǎo)入到tablename表的columnname列中。

(5) svom.mal定義MAL函數(shù)地址和對(duì)應(yīng)的SQL簽名的映射；

(6) columncopyUDF函數(shù)，將BAT結(jié)構(gòu)追加到數(shù)據(jù)庫中該表存儲(chǔ)結(jié)構(gòu)的后面完成導(dǎo)入；

(7) 用戶自定義函數(shù)與源代碼一同編譯，注冊(cè)成為數(shù)據(jù)庫服務(wù)器的內(nèi)置函數(shù)，調(diào)用方式：

sql>call columncopy (tablename, columnname, columnrows, filename)。

此次用戶自定義函數(shù)為今后復(fù)用設(shè)計(jì)其他用戶自定義函數(shù)，擴(kuò)展MonetDB服務(wù)器的能力打下了良好的基礎(chǔ)。

3初步設(shè)計(jì)方案

考慮每個(gè)相機(jī)的并列關(guān)系，每個(gè)相機(jī)對(duì)應(yīng)一個(gè)數(shù)據(jù)庫單元，36個(gè)數(shù)據(jù)庫單元最終由一臺(tái)控制服務(wù)器連接，控制服務(wù)器負(fù)責(zé)數(shù)據(jù)庫單元的添加和連接。這種設(shè)計(jì)的好處是數(shù)據(jù)庫單元只需負(fù)責(zé)自身CCD的存儲(chǔ)和計(jì)算，在物理上完成了數(shù)據(jù)表的分割。分布式數(shù)據(jù)庫架構(gòu)見圖8。分布式的數(shù)據(jù)庫各數(shù)據(jù)表的名稱和功能見表3。

圖8分布式數(shù)據(jù)庫陣列架構(gòu)

Fig.8　Distributed architecture of Database array

通過觀測(cè)目標(biāo)星表與模板星表的交叉認(rèn)證，如果能與模板星表匹配的則進(jìn)入時(shí)序測(cè)光通道進(jìn)行光變曲線的處理并進(jìn)行管理。如果從模板星表無法找到匹配星，則認(rèn)為是瞬變?cè)?候選體)。其中流量相對(duì)定標(biāo)的過程為：將交叉認(rèn)證匹配上的兩兩星對(duì)之間(觀測(cè)星與模板星匹配組)計(jì)算出流量比率，并取這一組的流量比率中值記為Rm，然后修正所有觀測(cè)星的星等計(jì)算公式為normag=-2.5log (flux·Rm)，其中normag為相對(duì)流量定標(biāo)后的觀測(cè)星表的星等；flux為觀測(cè)星的流量。相對(duì)流量定標(biāo)把測(cè)光星等都定標(biāo)到模板星表一致的水平，這樣光變曲線是一個(gè)有意義的相對(duì)光變量。所有瞬變?cè)炊即娣庞趖ransient，所有光變曲線存放于associatedsource。

將交叉認(rèn)證的匹配情況分成4種，即多對(duì)多、一對(duì)多、一對(duì)一、無匹配。多對(duì)多：剪除“多對(duì)多”關(guān)聯(lián)以防止數(shù)據(jù)庫爆炸，簡化成一對(duì)多關(guān)系，繼續(xù)處理。一對(duì)多：分配新的unique id給uniquecatalog表新插入的源，替代舊的uniqueid。新的一對(duì)多關(guān)聯(lián)插入associatedsource，設(shè)定為type=2；插入新unique id與舊targets id關(guān)聯(lián)，這是為給被取代的unique id新位置，標(biāo)記tpye=6。清空被一對(duì)多取代的原有分枝。一對(duì)一：插入tempuniquecatalog中的一對(duì)一關(guān)聯(lián)到associatedsource表中，標(biāo)記為type=3。無匹配：插入新的源到uniquecatalog，插入這些新的關(guān)聯(lián)到associatedsource，設(shè)置為type=4。判斷暫現(xiàn)源候選插入transient表。至此所有提取物處理完畢。

本系統(tǒng)通過以上設(shè)計(jì)完成地基廣角相機(jī)陣的數(shù)據(jù)處理和管理功能。具體的代碼開展與系統(tǒng)優(yōu)化及最后的測(cè)試，將是下一步工作的主要內(nèi)容。

4討論與總結(jié)

我國興建中的地基廣角相機(jī)陣面臨著大數(shù)據(jù)處理和管理的挑戰(zhàn)：每臺(tái)相機(jī)每15 s產(chǎn)生1.5 × 105條記錄，總相機(jī)數(shù)為36臺(tái)，并且要求實(shí)時(shí)處理和入庫管理。為應(yīng)對(duì)挑戰(zhàn)，提出一種充分利用數(shù)據(jù)庫兼具大數(shù)據(jù)管理和處理于一身的特點(diǎn)，基于MonetDB的大數(shù)據(jù)處理和管理的系統(tǒng)設(shè)計(jì)方案。本方案的計(jì)設(shè)特點(diǎn)是通過MonetDB自身具有大數(shù)據(jù)處理的特點(diǎn)，將核心數(shù)據(jù)處理功能內(nèi)嵌于數(shù)據(jù)庫內(nèi)，減少因數(shù)據(jù)管理和處理分屬于兩個(gè)系統(tǒng)所帶來的輸入輸出時(shí)間損耗。為驗(yàn)證MonetDB數(shù)據(jù)庫寬視場(chǎng)海量時(shí)序數(shù)據(jù)的處理與管理的可行性，開展多方的測(cè)試和預(yù)先研究。

預(yù)研階段主要通過了以下測(cè)試：(1)TPC-H基準(zhǔn)測(cè)試。本測(cè)試主要針對(duì)數(shù)據(jù)庫決策能力，測(cè)試結(jié)果表明：MonetDB具有明顯的表現(xiàn)優(yōu)勢(shì)，PostgreSQL次之，MySQL最差。(2)開展關(guān)鍵算法與功能測(cè)試。大數(shù)據(jù)加載能力測(cè)試表明，MonetDB相對(duì)于PostgreSQL具有明顯的優(yōu)勢(shì)。86400個(gè)星表相當(dāng)于96 h的時(shí)表數(shù)據(jù)，平均每個(gè)入庫時(shí)間為1.75 s。載入時(shí)間隨著載入數(shù)據(jù)量的增長緩慢線性增長。這個(gè)時(shí)間基本能滿足項(xiàng)目要求，但仍存在優(yōu)化的空間。研究發(fā)現(xiàn)星表文件的大小與載入速度有一個(gè)反常的關(guān)系，可以能過MonetDB的內(nèi)置函數(shù)進(jìn)行優(yōu)化。同時(shí)，將數(shù)據(jù)存儲(chǔ)表按不同觀測(cè)夜進(jìn)行分割，從而提高載入速度。交叉認(rèn)證Zone索引算法的實(shí)現(xiàn)與測(cè)試表明，MonetDB相對(duì)PostgresSQL具有更快的處理速度，每17萬條記錄認(rèn)證需要時(shí)間為4.3 s。通過調(diào)研和與MonetDB開發(fā)人員討論表明，通過調(diào)整MonetDB的內(nèi)置參數(shù)，能進(jìn)一步優(yōu)化交叉認(rèn)證的時(shí)間。并預(yù)期認(rèn)證每17萬條的記錄可以在小于1 s內(nèi)完成?；贛onetDB用戶自定義函數(shù)的接口，開發(fā)Columncopy批文件導(dǎo)入函數(shù)，表明MonetDB可以為以后的系統(tǒng)開發(fā)提供方便靈活的接口。

基于調(diào)研與測(cè)試結(jié)果，提出本方案的初步設(shè)計(jì)構(gòu)架。本方案主要完成兩大數(shù)據(jù)處理功能：瞬變?cè)吹膶?shí)時(shí)搜索和海量光變曲線的生成與管理。確立分布式數(shù)據(jù)庫的架構(gòu)方式，整個(gè)系統(tǒng)由36個(gè)并列的數(shù)據(jù)庫單元組成，每個(gè)數(shù)據(jù)庫單元對(duì)應(yīng)一個(gè)獨(dú)立望遠(yuǎn)鏡且功能相同。一個(gè)主控?cái)?shù)據(jù)庫單元管理各個(gè)數(shù)據(jù)庫單元。對(duì)單獨(dú)的數(shù)據(jù)庫單元設(shè)計(jì)了表單的結(jié)構(gòu)及相互關(guān)系。同時(shí)描述了相對(duì)流量定標(biāo)的實(shí)現(xiàn)過程。該設(shè)計(jì)方案從理論上分析是切實(shí)可行的，但實(shí)際開發(fā)與測(cè)試必須經(jīng)過大量的優(yōu)化及調(diào)試，這將是下一步工作的重點(diǎn)內(nèi)容。

總之，通過研究工作，找到一種可行的應(yīng)對(duì)地面廣角相機(jī)陣大數(shù)據(jù)挑戰(zhàn)的數(shù)據(jù)處理與管理為一體的系統(tǒng)設(shè)計(jì)方法，將為MonetDB在中國天文界的大數(shù)據(jù)處理和管理的應(yīng)用打下基礎(chǔ)。

參考文獻(xiàn)：

[1]徐洋, 吳潮, 萬萌, 等. 用于光學(xué)瞬變?cè)此褜さ慕徊嬲J(rèn)證快速算法[J]. 天文研究與技術(shù)——國家天文臺(tái)臺(tái)刊, 2013, 10(3): 273-282.

Xu Yang, Wu Chao, Wan Meng, et al. A fast cross-identification algorithm for searching optical transient sources[J]. Astronomical Research & Technology——Publications of National Astronomical Observatories of China, 2013, 10(3): 273-282.

[2]Zhao Y, Luo Q, Wang S, et al. Accelerating astronomical image subtraction on heterogeneous processors[C]// 2013 IEEE 9th International Conference on Escience. 2013: 70-77.

[3]Zhao B, Luo Q, Wu C. Parallelizing astronomical source extraction on the GPU[C]// 2013 IEEE 9th International Conference on Escience. 2013: 88-97.

[4]Wang S, Zhao Y, Luo Q, et al. Accelerating in-memory cross match of astronomical catalogs[C]// 2013 IEEE 9th International Conference on Escience. 2013: 326-333.

[5]Szalay A S, Blakeley J A. Gray′s laws: database-centric computing in science[M]. United States of America: Microsoft Research. 2009: 5-11.

[6]Scheers L H A. Transient and variable radio sources in the LOFAR sky: an architecture for a detection framework[D]. Amsterdam:University of Amsterdam, 2011.

[7]Ivanova M, Nes N, Goncalves R, et al. MonetDB/SQL Meets SkyServer: the challenges of a scientific database[C]// 19th International Conference onScientific and Statistical Database Management. 2007: 13.

*基金項(xiàng)目：國家留學(xué)基金委員會(huì)中荷互換獎(jiǎng)學(xué)金項(xiàng)目；國家重點(diǎn)基礎(chǔ)研究發(fā)展計(jì)劃 (973計(jì)劃) (2014CB845800)；國家自然科學(xué)基金 (U1331202, 11533003, U1431108) 資助.

收稿日期：2015-10-13；

修訂日期：2015-11-12

作者簡介：萬萌，女，碩士. 研究方向：天文數(shù)據(jù)庫系統(tǒng). Email: wanmeng@nao.cas.cn

中圖分類號(hào)：TP311

文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào):1672-7673(2016)03-0373-09

A Pre-research on GWAC Massive Catalog Data Storage and Processing System

Wan Meng1,2,3, Wu Chao1, Ying Zhang3, Xu Yang1, Wei Jianyan1

(1. National Astronomical Observatories, Chinese Academy of Sciences, Beijing 100012, China, Email: cwu@nao.cas.cn; 2. University of Chinese Academy of Sciences, Beijing 100049, China; 3. Centrum Wiskunde & Informatica, Amsterdam, 1098 XG)

Abstract:GWAC (Ground Wide Angle Camera) poses huge challenges in large-scale catalogue storage and real-time processing of quick search of transients among wide field-of-view time-series data. Firstly, this paper proposes a concept to employ databases′ functions such as fast data processing and parallelism, which will improve system performance and availability through the integration of data storage and computing platform. To understand the feasibility of Column-store MonetDB in vast catalogue management, we carry out a variety of pilot experiments on key technologies. We conduct TPC-H benchmark, data loading benchmark and optimization, and key algorithm testing of astronomical source association, all compared with the traditional row store database. Then, we use MonetDB to realize cross-match Zone algorithm. UDF function is developed for customizable data loading. Test results show that MonetDB database has a remarkable performance in big data management and it is efficient in real-time data processing: it has the ability to deal with 2.5T catalog data.In the end we propose a wide field of view massive time serial observation data processing solution using the in-memory column store database MonetDB. The experimental results confirm the feasibility of this scheme. The design plan of MonetDB-based massive catalogue data processing solution is an efficient astronomical database solution that combines data processing and data management.

Key words:Astronomical database; Architecture design; MonetDB; Real-time analysis; Source association

CN 53-1189/PISSN 1672-7673