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

萬(wàn)　萌，吳　潮，Ying Zhang，徐　洋，魏建彥

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

?

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

萬(wàn)萌1,2,3，吳潮1，Ying Zhang3，徐洋1，魏建彥1

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

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

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

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

我國(guó)興建中的地面廣角相機(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è)觀(guān)測(cè)夜對(duì)固定天區(qū)目標(biāo)的持繼觀(guān)測(cè)長(zhǎng)達(dá)4～5 h。從觀(guān)測(cè)視場(chǎng)的大小和觀(guān)測(cè)時(shí)間的采樣頻度上，地面廣角相機(jī)陣在時(shí)域天文觀(guān)測(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ù)庫(kù)管理系統(tǒng)的要求：(1)快速的大數(shù)據(jù)入庫(kù)能力，所有相機(jī)陣15 s內(nèi)產(chǎn)生的觀(guān)測(cè)星表入庫(kù)時(shí)間控制在15 s以?xún)?nèi)，每個(gè)觀(guān)測(cè)夜的2 TB星表最晚完成入庫(kù)時(shí)間保證在下一個(gè)觀(guān)測(cè)夜開(kāi)始前；(2)在數(shù)據(jù)高速采集下能夠完成實(shí)時(shí)分析，面對(duì)持續(xù)不斷的高密度海量星表的快速關(guān)聯(lián)計(jì)算能力，即每個(gè)CCD每15 s產(chǎn)生的星表數(shù)據(jù)與參考星表相關(guān)聯(lián)形成光變曲線(xiàn)。

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

著名數(shù)據(jù)庫(kù)專(zhuān)家Jim Gray成功開(kāi)發(fā)了SDSS巡天數(shù)據(jù)庫(kù)管理系統(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ù)庫(kù)的SQL直接實(shí)現(xiàn)多維空間索引取代經(jīng)典的分層三角網(wǎng)格算法(Hierarchical Triangular Mesh, HTM)，從而減少數(shù)據(jù)的交互，速度得到提升。這就是大規(guī)模科學(xué)計(jì)算和數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)的原則：將計(jì)算帶到數(shù)據(jù)中來(lái)，而不是把數(shù)據(jù)放到計(jì)算中去的設(shè)計(jì)理念[5]。受這一思想的啟發(fā)，提出將地基廣角相機(jī)陣的數(shù)據(jù)處理和數(shù)據(jù)管理合成到一個(gè)數(shù)據(jù)庫(kù)平臺(tái)的設(shè)計(jì)思路。

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

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

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

大型射電望遠(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ù)庫(kù)曾被成功移植到MonetDB上[7]，并通過(guò)了對(duì)斯隆數(shù)字巡天項(xiàng)目中的SDSS BESTDR7近4 TB數(shù)據(jù)的管理測(cè)試。因此選取列存儲(chǔ)數(shù)據(jù)庫(kù)MonetDB作為系統(tǒng)的開(kāi)發(fā)平臺(tái)。

為研究和驗(yàn)證以上設(shè)計(jì)思路的可行性，根據(jù)地基廣角相機(jī)陣數(shù)據(jù)處理流程(如圖1)開(kāi)展了TPC-H基準(zhǔn)性能測(cè)試以驗(yàn)證其載入和分析能力，大數(shù)據(jù)加載速度的測(cè)試與研究。通過(guò)MonetDB的自定義函數(shù)接口功能測(cè)試實(shí)際自定義函數(shù)的開(kāi)發(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ù)庫(kù)平臺(tái)PostgreSQL及MySQL的差異。TPC-H是模擬決策支持類(lèi)應(yīng)用的一個(gè)測(cè)試集。天文數(shù)據(jù)庫(kù)日常提供的服務(wù)也屬于數(shù)據(jù)分析類(lèi)應(yīng)用，適合選擇TPC-H作為測(cè)試集。

TPC-H測(cè)試包括22條選擇查詢(xún)語(yǔ)句。測(cè)試流程為先用DBGEN工具產(chǎn)生測(cè)試數(shù)據(jù)，加載程序裝載數(shù)據(jù)到3種數(shù)據(jù)庫(kù)后，數(shù)據(jù)庫(kù)處于初始狀態(tài)，未進(jìn)行其他任何操作。此時(shí)將22條查詢(xún)順序執(zhí)行一遍，分別記錄3種數(shù)據(jù)庫(kù)22條查詢(xún)的總響應(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ì)比，具體代碼見(jiàn)*https://github.com/hlfwm/TPC-H?？梢钥闯?2條查詢(xún)總時(shí)間MonetDB消耗只有PostgreSQL的約1/15，MySQL的1/137，單條查詢(xún)提速至少3倍。造成查詢(xún)響應(yīng)時(shí)間存在較大差異的主要原因是TPC-H業(yè)務(wù)類(lèi)型是在線(xiàn)數(shù)據(jù)分析類(lèi)型，數(shù)據(jù)量大，查詢(xún)語(yǔ)句比重大，復(fù)雜的查詢(xún)多，符合適合列存儲(chǔ)數(shù)據(jù)庫(kù)的典型指標(biāo)。表的數(shù)據(jù)量越大，就越適合使用列存儲(chǔ)數(shù)據(jù)庫(kù)，尤其是當(dāng)查詢(xún)語(yǔ)句比重也很大時(shí)，則使用列查詢(xún)能顯著降低SQL語(yǔ)句查詢(xún)的時(shí)間。如果查詢(xún)?cè)L問(wèn)的列比，即所有查詢(xún)語(yǔ)句訪(fǎng)問(wèn)的列數(shù)和總列數(shù)的比例越小，越適合列存儲(chǔ)。這解釋了對(duì)于大表Lineitem上的連接、且查詢(xún)?cè)L問(wèn)列比低的查詢(xún)的Q18、Q19、Q21，MonetDB響應(yīng)速度領(lǐng)先數(shù)十倍的原因?？梢?jiàn)MonetDB列存儲(chǔ)數(shù)據(jù)庫(kù)在分析式查詢(xún)時(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è)床⒛苌晒庾兦€(xiàn)。進(jìn)行如下關(guān)鍵算法和功能的測(cè)試：大數(shù)據(jù)的加載能力；交叉認(rèn)證算法的實(shí)現(xiàn)；擴(kuò)展處理功能的開(kāi)發(fā)實(shí)現(xiàn)。

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

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

測(cè)試(1)的方法為通過(guò)仿真1 000個(gè)20列 × 20萬(wàn)行*實(shí)際情況每幅圖像產(chǎn)生15萬(wàn)條星表記錄，為進(jìn)行壓力測(cè)試，這里選取20萬(wàn)條記錄。類(lèi)似于實(shí)際觀(guān)測(cè)的星表數(shù)據(jù)，連續(xù)加載到被測(cè)試的數(shù)據(jù)庫(kù)中，分析加載速度的變化。測(cè)試平臺(tái)的軟硬件環(huán)境如圖3。測(cè)試的具體實(shí)現(xiàn)過(guò)程：對(duì)仿真的星表，使用大文件導(dǎo)入庫(kù)命令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ù)庫(kù)單表數(shù)據(jù)的增加，對(duì)注入的速度無(wú)明顯影響，平均每個(gè)星表文件數(shù)據(jù)的載入時(shí)間為0.94 s。而PostgresSQL則在載入500個(gè)星表文件后，速度明顯降低，平均載入速度為6.0 s。MonetDB沒(méi)有出現(xiàn)速率陡降現(xiàn)象，這與MonetDB是內(nèi)存數(shù)據(jù)庫(kù)相關(guān)，表現(xiàn)在磁盤(pán)存取、內(nèi)外存的數(shù)據(jù)傳遞、緩沖區(qū)管理、排隊(duì)等待及鎖的延遲方面均比磁盤(pán)數(shù)據(jù)庫(kù)快很多。(2)MonetDB每隔幾十個(gè)文件會(huì)有一個(gè)突跳點(diǎn)，加載時(shí)間突然提高至10 s左右。主要原因是由于MonetDB需要時(shí)間將數(shù)據(jù)寫(xiě)到磁盤(pán)，而導(dǎo)致的輸入輸出開(kāi)銷(xiāo)。這是在今后使用中需要解決的一個(gè)問(wèn)題，希望能通過(guò)提高數(shù)據(jù)寫(xiě)入硬盤(pán)的頻度來(lái)解決。

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

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

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

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è)春凸庾兦€(xiàn)生成的關(guān)鍵算法。交叉認(rèn)證問(wèn)題必須依靠有效的分區(qū)策略，通過(guò)將天區(qū)按赤緯進(jìn)行條帶分區(qū)，將天區(qū)劃分成一個(gè)個(gè)水平條帶，每個(gè)源有一個(gè)屬于自己的條帶屬性，交叉認(rèn)證前首先比較條帶屬性可以大大降低比較次數(shù)。條帶可集成到數(shù)據(jù)庫(kù)內(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)已建成安放于國(guó)家天文臺(tái)興隆觀(guān)測(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語(yǔ)句為

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萬(wàn)條記錄的星表進(jìn)行交叉認(rèn)證，所需時(shí)間大約為4.3 s。

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

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

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

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

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

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

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

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

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

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

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

(4) svom.c, svom.h為用戶(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ù)庫(kù)中該表存儲(chǔ)結(jié)構(gòu)的后面完成導(dǎo)入；

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

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

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

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

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

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

Fig.8　Distributed architecture of Database array

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

將交叉認(rèn)證的匹配情況分成4種，即多對(duì)多、一對(duì)多、一對(duì)一、無(wú)匹配。多對(duì)多：剪除“多對(duì)多”關(guān)聯(lián)以防止數(shù)據(jù)庫(kù)爆炸，簡(jiǎn)化成一對(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。無(wú)匹配：插入新的源到uniquecatalog，插入這些新的關(guān)聯(lián)到associatedsource，設(shè)置為type=4。判斷暫現(xiàn)源候選插入transient表。至此所有提取物處理完畢。

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

4討論與總結(jié)

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

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

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

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

參考文獻(xiàn)：

[1]徐洋, 吳潮, 萬(wàn)萌, 等. 用于光學(xué)瞬變?cè)此褜さ慕徊嬲J(rèn)證快速算法[J]. 天文研究與技術(shù)——國(guó)家天文臺(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)目：國(guó)家留學(xué)基金委員會(huì)中荷互換獎(jiǎng)學(xué)金項(xiàng)目；國(guó)家重點(diǎn)基礎(chǔ)研究發(fā)展計(jì)劃 (973計(jì)劃) (2014CB845800)；國(guó)家自然科學(xué)基金 (U1331202, 11533003, U1431108) 資助.

收稿日期：2015-10-13；

修訂日期：2015-11-12

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

中圖分類(lèi)號(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