天文大數(shù)據(jù)挑戰(zhàn)與實(shí)時(shí)處理技術(shù)

楊 晨 翁祖建 孟小峰 任 瑋 忻日輝 王春凱 都志輝 萬 萌 魏建彥

1(中國人民大學(xué)信息學(xué)院 北京 100872)2(清華大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)系 北京 100084)3(中國科學(xué)院國家天文臺(tái) 北京 100012) (yang_chen@ruc.edu.cn)

天文大數(shù)據(jù)挑戰(zhàn)與實(shí)時(shí)處理技術(shù)

楊 晨1翁祖建1孟小峰1任 瑋1忻日輝1王春凱1都志輝2萬 萌3魏建彥3

1(中國人民大學(xué)信息學(xué)院 北京 100872)2(清華大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)系 北京 100084)3(中國科學(xué)院國家天文臺(tái) 北京 100012) (yang_chen@ruc.edu.cn)

超大型天文觀測技術(shù)的出現(xiàn)不僅能夠讓研究人員觀測到新的天文現(xiàn)象，更能用于驗(yàn)證已有物理模型的正確性.這些最新天文成果的發(fā)現(xiàn)是建立在海量天文數(shù)據(jù)的近乎實(shí)時(shí)產(chǎn)生、管理與分析的基礎(chǔ)上，因此給目前的數(shù)據(jù)管理系統(tǒng)帶來了新的挑戰(zhàn).以我國自主研發(fā)的地基廣角相機(jī)陣(the ground-based wide-angle camera array, GWAC)天文望遠(yuǎn)鏡為例，15 s的采樣和處理周期都處于短時(shí)標(biāo)觀測領(lǐng)域的世界前列，但卻對數(shù)據(jù)管理系統(tǒng)提出了很多問題,包括多鏡頭并行輸出數(shù)據(jù)管理、實(shí)時(shí)瞬變源發(fā)現(xiàn)、當(dāng)前觀測夜數(shù)據(jù)的秒級(jí)查詢、數(shù)據(jù)持久化和快速離線查詢等.基于上述問題，設(shè)計(jì)了分布式GWAC數(shù)據(jù)模擬生成器用于模擬真實(shí)GWAC數(shù)據(jù)產(chǎn)生場景，并基于產(chǎn)生的數(shù)據(jù)特性，提出一種兩級(jí)緩存架構(gòu)，使用本地內(nèi)存解決多鏡頭并行輸出、實(shí)時(shí)瞬變源發(fā)現(xiàn)，使用分布式共享內(nèi)存實(shí)現(xiàn)秒級(jí)查詢.為了平衡持久化和查詢效率，設(shè)計(jì)一種星表簇結(jié)構(gòu)將整個(gè)星表數(shù)據(jù)劃分后聚集存儲(chǔ).根據(jù)天文需求特點(diǎn)，設(shè)計(jì)基于索引表的查詢引擎能從緩存和星表簇以較小的代價(jià)對星表數(shù)據(jù)查詢.通過實(shí)驗(yàn)驗(yàn)證，當(dāng)前方案能夠滿足GWAC的需求.

天文大數(shù)據(jù)管理；地基廣角相機(jī)陣；兩級(jí)緩存；星表簇；索引表

隨著各種最新觀測技術(shù)的出現(xiàn)，天文領(lǐng)域迎來了信息爆炸的時(shí)代，而該時(shí)代的第一波浪潮就是天文大數(shù)據(jù)的管理.進(jìn)入21世紀(jì)，天文學(xué)已經(jīng)進(jìn)入了一個(gè)信息豐富的大數(shù)據(jù)時(shí)代，天文數(shù)據(jù)正在以TB量級(jí)甚至PB量級(jí)的速度快速增長.2000年斯隆數(shù)字巡天(Sloan digital sky survey, SDSS)項(xiàng)目啟動(dòng)時(shí)，位于新墨西哥州的望遠(yuǎn)鏡在短短幾周內(nèi)收集到的數(shù)據(jù)，已經(jīng)比天文學(xué)歷史上總共收集的數(shù)據(jù)還要多.到了2010年，信息檔案已經(jīng)高達(dá)1.4×242B.不過，預(yù)計(jì)2019年在智利投入使用的大型視場全景巡天望遠(yuǎn)鏡(large synoptic survey telescope, LSST)能在5 d之內(nèi)就獲得同樣多的信息.在我國，郭守敬望遠(yuǎn)鏡(the large sky area multi-object fiber spectroscopic telescope, LAMOST)和即將上線的地基廣角相機(jī)陣(the ground-based wide-angle camera array, GWAC)等巡天項(xiàng)目每天都要產(chǎn)生海量的天文數(shù)據(jù).

天文數(shù)據(jù)管理系統(tǒng)經(jīng)歷了從開始的基于文件系統(tǒng)的管理到目前基于關(guān)系數(shù)據(jù)庫管理的發(fā)展階段.早期限于觀測設(shè)備，天文領(lǐng)域數(shù)據(jù)量不大，可以以文件的方式管理天文數(shù)據(jù)，僅支持一些簡單的歸檔、排序和整理服務(wù).隨著觀測設(shè)備升級(jí)，文件系統(tǒng)已不能滿足當(dāng)前數(shù)據(jù)規(guī)模的管理工作，因此天文領(lǐng)域開始使用關(guān)系型數(shù)據(jù)庫管理數(shù)據(jù).此時(shí)，天文研究者開始要求數(shù)據(jù)庫能夠按天文需求條件查找查詢，并定制一些查詢.但在可期的將來，超大型天文設(shè)備短時(shí)間產(chǎn)生(TB級(jí))和累計(jì)下的數(shù)據(jù)量(PB或EB級(jí))將超過關(guān)系數(shù)據(jù)庫的管理能力，給當(dāng)前天文數(shù)據(jù)管理帶來巨大的挑戰(zhàn).

目前在國際上，美國的SDSS望遠(yuǎn)鏡的采樣周期是71.72 s，每次采樣的數(shù)據(jù)處理周期是1個(gè)月.美國設(shè)計(jì)的LSST采樣周期是39 s，每次采樣的數(shù)據(jù)處理周期是60 s.中國設(shè)計(jì)的GWAC不同于其他天文觀測技術(shù)，由40臺(tái)廣角望遠(yuǎn)鏡組成，單個(gè)觀測夜中，所有望遠(yuǎn)鏡要求同步地每15 s采樣一次，并于下一次采樣前將原始圖像數(shù)據(jù)轉(zhuǎn)化為星表數(shù)據(jù)，與此同時(shí)數(shù)據(jù)還要處于可查詢狀態(tài)，以支持短時(shí)標(biāo)天文現(xiàn)象的發(fā)現(xiàn).因此，無延遲的處理數(shù)據(jù)，對當(dāng)前數(shù)據(jù)管理系統(tǒng)提出了新的挑戰(zhàn).

傳統(tǒng)的關(guān)系型內(nèi)存數(shù)據(jù)庫，如MonetDB[1]，入庫時(shí)間變動(dòng)過大，極容易引起下一次數(shù)據(jù)來到后上一次數(shù)據(jù)還未寫入完成，造成擁塞[2].而非關(guān)系型數(shù)據(jù)庫，如Kafka[3]+Hbase[4]，實(shí)驗(yàn)表明單個(gè)鏡頭一次產(chǎn)生的數(shù)據(jù)量寫入Kafka需要2.7 s，不會(huì)造成數(shù)據(jù)擁塞，但寫入Hbase需要5 min左右，并不能滿足實(shí)時(shí)查詢要求.

針對上述問題，本文提出一種兩級(jí)緩存架構(gòu)方案以支持無擁塞承接每個(gè)采樣周期數(shù)據(jù)，且保證數(shù)據(jù)可查.結(jié)合GWAC背景，本文認(rèn)為每個(gè)望遠(yuǎn)鏡產(chǎn)生的數(shù)據(jù)之間相互獨(dú)立，因此設(shè)計(jì)每個(gè)望遠(yuǎn)鏡由一臺(tái)服務(wù)器承接剛產(chǎn)生的數(shù)據(jù)，進(jìn)行必要的處理后，如交叉認(rèn)證(見1.2節(jié))，緩存入本地內(nèi)存(一級(jí)緩存)，并直接進(jìn)行異常天文現(xiàn)象的識(shí)別.繼而，每臺(tái)服務(wù)器上的緩存管理器異步將一級(jí)緩存的數(shù)據(jù)寫入二級(jí)緩存.二級(jí)緩存使用分布式共享內(nèi)存實(shí)現(xiàn)，如Redis cluster[5].可以看出，一級(jí)緩存的作用如下：1)快速承接每個(gè)望遠(yuǎn)鏡產(chǎn)生的數(shù)據(jù)；2)快速進(jìn)行異常檢測；3)二級(jí)緩存故障后，保證數(shù)據(jù)的可靠性.兩級(jí)緩存架構(gòu)可以實(shí)現(xiàn)多鏡頭并行輸出、異常天文現(xiàn)象發(fā)現(xiàn)、低延遲存儲(chǔ)和秒級(jí)查詢.

由于不能事先確定異常天文現(xiàn)象的發(fā)生，但異常發(fā)生時(shí)仍需要實(shí)現(xiàn)相關(guān)瞬變源數(shù)據(jù)的快速查詢，以幫助天文研究人員快速定位重大科學(xué)發(fā)現(xiàn).因此，本文將當(dāng)前觀測夜的所有數(shù)據(jù)全部緩存入二級(jí)緩存.在白天時(shí)，對二級(jí)緩存數(shù)據(jù)進(jìn)行持久化操作.為了支持高效的離線天文數(shù)據(jù)分析并兼顧持久化效率，本文設(shè)計(jì)一種星表簇結(jié)構(gòu)作為持久化數(shù)據(jù)的存儲(chǔ)模式.簡單地說，通過一定的天文業(yè)務(wù)背景和策略，將二級(jí)緩存中的星表數(shù)據(jù)聚合后存入不同的物理文件中.這樣做的好處是：1)天文查詢的基本需求是對星亮度變化的查詢，不同星之間很少做關(guān)聯(lián)操作，因此將部分星聚集存儲(chǔ)，能保證只訪問整個(gè)數(shù)據(jù)集的部分，從而提高查詢效率；2)比起單顆星存儲(chǔ)而言，能有效降低管理整個(gè)數(shù)據(jù)集的開銷(如文件元數(shù)據(jù)和文件索引個(gè)數(shù)).

對于不同的數(shù)據(jù)源，如二級(jí)緩存和持久化數(shù)據(jù)，查詢引擎都必須支持且能聯(lián)合查詢.本文提出一種基于索引表的查詢策略以支持快速查詢.索引表除了記錄星名，還記錄星屬性不變的部分(如位置信息)和統(tǒng)計(jì)信息，并動(dòng)態(tài)更新.如果查詢請求不需要檢索隨時(shí)間變化數(shù)據(jù)，如位置信息，那么查詢索引表后直接返回；如需要隨時(shí)間變化數(shù)據(jù)，則查詢索引表獲取滿足條件星名集合，進(jìn)而使用星名集合從二級(jí)緩存或持久化數(shù)據(jù)查詢滿足條件的星表數(shù)據(jù).此時(shí)，星表簇結(jié)構(gòu)可以保證查詢引擎僅掃描持久化數(shù)據(jù)的某幾個(gè)小子集.

為了驗(yàn)證上述方案的有效性，本文改寫單鏡頭版GWAC模擬數(shù)據(jù)生成器[6]為分布式GWAC模擬數(shù)據(jù)生成器，可用于模擬多個(gè)望遠(yuǎn)鏡同步產(chǎn)生星表數(shù)據(jù).作者在一個(gè)小型的原型系統(tǒng)上實(shí)現(xiàn)了整個(gè)數(shù)據(jù)產(chǎn)生、存儲(chǔ)和查詢過程并進(jìn)行了實(shí)驗(yàn)驗(yàn)證.實(shí)驗(yàn)結(jié)果表明，當(dāng)前的設(shè)計(jì)方案能夠支撐GWAC系統(tǒng)日常的業(yè)務(wù)需求.

本文主要貢獻(xiàn)如下：

1) 設(shè)計(jì)分布式GWAC模擬數(shù)據(jù)生成器，能夠更真實(shí)地模擬多個(gè)望遠(yuǎn)鏡同步產(chǎn)生星表數(shù)據(jù)的應(yīng)用場景；

2) 提出一種兩級(jí)緩存架構(gòu)的數(shù)據(jù)管理方案，針對性地解決多鏡頭并行輸出、實(shí)時(shí)瞬變源發(fā)現(xiàn)和秒級(jí)查詢等問題；

3) 針對當(dāng)前觀測夜星表數(shù)據(jù)持久化時(shí)間限制及離線查詢效率的相應(yīng)要求，設(shè)計(jì)一種星表簇的存儲(chǔ)結(jié)構(gòu)兼顧持久化與查詢性能；

4) 設(shè)計(jì)一種針對索引表和星表簇結(jié)構(gòu)的查詢策略，能夠盡可能少地訪問持久化數(shù)據(jù)，或訪問持久化數(shù)據(jù)的部分子集以提高查詢效率.

本文首先介紹GWAC背景和面向星表數(shù)據(jù)管理的相關(guān)工作，然后重點(diǎn)介紹面向GWAC星表數(shù)據(jù)管理系統(tǒng)設(shè)計(jì)，最后給出系統(tǒng)驗(yàn)證與分析結(jié)果.

1 相關(guān)背景

1.1 GWAC相機(jī)陣介紹

我國興建中的地基廣角相機(jī)陣GWAC由40臺(tái)口徑為18 cm的廣角望遠(yuǎn)鏡組成，每臺(tái)望遠(yuǎn)鏡配備4 k×4 k的電荷耦合器件(charge coupled device, CCD)探測器①如無特別所指，本文將使用專業(yè)名詞CCD表示GWAC中的單個(gè)望遠(yuǎn)鏡..整個(gè)相機(jī)陣的天區(qū)覆蓋5 000平方度，時(shí)間采樣周期為15 s.每個(gè)觀測夜對固定天區(qū)目標(biāo)的持繼觀測長達(dá)10 h.從觀測視場的大小和觀測時(shí)間的采樣頻度上，地面廣角相機(jī)陣在時(shí)域天文觀測中具有特殊的優(yōu)勢.巨大的數(shù)據(jù)量和高速采樣率，對數(shù)據(jù)的管理和處理問題提出極大的挑戰(zhàn).地面廣角相機(jī)陣的星表數(shù)據(jù)指標(biāo)是：1)星表數(shù)據(jù)每幅圖像大約有1.7×105條記錄，整個(gè)相機(jī)陣在15 s內(nèi)共產(chǎn)生6.8×106(數(shù)據(jù)量約為1.3 GB)條記錄，每晚約有2400×40=96000幅圖，大約需要2 TB的存儲(chǔ)開銷；2)以10年為設(shè)計(jì)周期，GWAC總計(jì)將產(chǎn)生3～6 PB量級(jí)的超大規(guī)模星表.

1.2 GWAC天文數(shù)據(jù)處理流程

如圖1所示，GWAC相機(jī)陣將整個(gè)觀測天區(qū)劃分為40塊，每塊子天區(qū)由一個(gè)CCD負(fù)責(zé)采集數(shù)據(jù)，且所有CCD每15 s同步地產(chǎn)生一次數(shù)據(jù).采集到的原始數(shù)據(jù)為圖像，并經(jīng)由預(yù)處理、點(diǎn)源提取(把光學(xué)影像轉(zhuǎn)化為數(shù)字信號(hào)，形成星表數(shù)據(jù))和星表天測定標(biāo)(將一個(gè)星表中的星亮度校準(zhǔn)到天文領(lǐng)域通用的標(biāo)準(zhǔn)下)等天文處理過程，轉(zhuǎn)換為每顆星一行記錄的星表數(shù)據(jù).該星表數(shù)據(jù)對天文科研數(shù)據(jù)而言，最重要的2個(gè)屬性是星的亮度和相對應(yīng)的時(shí)間戳.根據(jù)瞬時(shí)星亮度或變化規(guī)律的異?？梢苑治鲈撔堑漠愖?，而該異變現(xiàn)象可以用于探知宇宙的變化和對已有物理模型的驗(yàn)證.根據(jù)長期星亮度的變化規(guī)律可繪制該星的光變曲線，以用于分析星的長時(shí)標(biāo)的變化周期，如發(fā)現(xiàn)流浪行星.

Fig. 1 Data processing workflow in GWAC圖1 GWAC天文數(shù)據(jù)處理過程示意圖

從實(shí)時(shí)角度來看，持續(xù)產(chǎn)生的星表數(shù)據(jù)主要有以下3個(gè)特征：

1) 多鏡頭并行輸出.雖然每個(gè)CCD最終產(chǎn)生的星表數(shù)據(jù)量不大，但是40個(gè)CCD每隔15 s就會(huì)產(chǎn)生規(guī)模龐大的數(shù)據(jù)量.這些數(shù)據(jù)需要及時(shí)存儲(chǔ)便于查詢.

2) 實(shí)時(shí)瞬變源發(fā)現(xiàn).異常天文現(xiàn)象稍縱即逝，為了給天文科研人員留出足夠的時(shí)間觀測異常星，要求整個(gè)數(shù)據(jù)處理系統(tǒng)能夠?qū)崟r(shí)捕獲異常星變化，并給予報(bào)警.

3) 秒級(jí)查詢.天文科研人員往往需要對瞬變源或疑似瞬變源的近期歷史數(shù)據(jù)快速查詢，以便綜合分析該天文現(xiàn)象.

上述需求對后臺(tái)的天文數(shù)據(jù)處理系統(tǒng)提出了巨大的挑戰(zhàn)，要求系統(tǒng)能夠快速響應(yīng)，尤其對于當(dāng)晚的星表數(shù)據(jù)而言要求能夠做到快存快取.

從持久化角度來看，GWAC所有的歷史數(shù)據(jù)都要進(jìn)行持久化操作，以便離線狀態(tài)下對星表數(shù)據(jù)進(jìn)行光變曲線規(guī)律的分析和一定的數(shù)據(jù)挖掘工作.雖然為離線過程，但也要求查詢過程要在合理的時(shí)間范圍給予響應(yīng).

對GWAC數(shù)據(jù)管理系統(tǒng)的要求可總結(jié)為：1)高數(shù)據(jù)吞吐能力，所有相機(jī)陣15 s內(nèi)產(chǎn)生的觀測星表可用于查詢的延遲時(shí)間控制在15 s以內(nèi)；2)在數(shù)據(jù)高速采集下能夠完成實(shí)時(shí)分析，面對持續(xù)不斷的高密度海量星表的快速關(guān)聯(lián)計(jì)算能力，即每個(gè)CCD每15 s產(chǎn)生的星表數(shù)據(jù)與模板星表相關(guān)聯(lián)(交叉認(rèn)證：將觀測的目標(biāo)星映射到模板星表的已知星的過程)形成光變曲線；3)每個(gè)觀測夜的2 TB星表最晚完成持久化時(shí)間保證在下一個(gè)觀測夜開始前；4)從長期存儲(chǔ)的角度而言，管理系統(tǒng)需要有極強(qiáng)的海量數(shù)據(jù)管理能力，至少要能滿足6PB數(shù)據(jù)的存儲(chǔ)和離線查詢能力.

1.3 天文數(shù)據(jù)管理系統(tǒng)的相關(guān)工作

目前國內(nèi)外天文數(shù)據(jù)庫的主要功能仍集中在電子化歸檔、搜索和下載等方面，且主要?dú)v經(jīng)3個(gè)階段[7].

1) 興起階段，此時(shí)的天文數(shù)據(jù)庫主要基于文件系統(tǒng)的數(shù)據(jù)存儲(chǔ).較為著名的有法國特斯拉斯堡的恒星數(shù)據(jù)中心CDS(centre de Données stellaires,即center for stellar data)的天文天體數(shù)據(jù)交互服務(wù)SIMBAD(set of identifications, measurements, and bibliography for astronomical data)，利用計(jì)算機(jī)管理天文數(shù)據(jù)，能夠?qū)?shù)據(jù)加以歸檔、排序和整理，并為全球星表提供交叉識(shí)別和文獻(xiàn)目錄檢索功能.

2) 關(guān)系數(shù)據(jù)庫實(shí)現(xiàn)天文數(shù)據(jù)管理階段，以提供星表服務(wù)的VizieR和SDSS為代表.到20世紀(jì)90年代末，SIMBAD服務(wù)已經(jīng)無法滿足更為復(fù)雜的查詢需求，CDS又開發(fā)了更為強(qiáng)大的VizieR系統(tǒng).VizieR底層依賴關(guān)系數(shù)據(jù)模型，支持基于ID和位置的搜索，且沒有最大搜索半徑的要求，具有較快的響應(yīng)速度，但搜索的定制程度較低.此外，另一個(gè)專業(yè)的天文數(shù)據(jù)管理服務(wù)為斯隆數(shù)字巡天SDSS自主開發(fā)的數(shù)據(jù)庫.SDSS的天文數(shù)據(jù)庫Skyserver[8]是基于微軟的SQL Server定制開發(fā)的，具有快速查詢、批量下載、SQL檢索和可視化圖形界面等特點(diǎn).這一階段的天文數(shù)據(jù)管理開始在數(shù)據(jù)庫的基礎(chǔ)上定制了各種天文數(shù)據(jù)的科學(xué)應(yīng)用，以滿足天文數(shù)據(jù)特殊的檢索需求.

3) 即將到來的超大天文數(shù)據(jù)庫階段，以美國大口徑全景巡天LSST和SKA(square kilometre array)為代表[2].一些新興的天文領(lǐng)域如伽瑪暴、超新星爆發(fā)對時(shí)域天文觀測的要求更加迫切，直接導(dǎo)致天文數(shù)據(jù)量的爆發(fā)式增長.美國LSST設(shè)計(jì)每15 s記錄3幅10億像素級(jí)的圖像，每晚收集的數(shù)據(jù)量大約15～30 TB，每3 d可巡天1次，預(yù)計(jì)2022年接受觀測任務(wù).澳大利亞SKA計(jì)劃每秒產(chǎn)生的數(shù)據(jù)量大于12 TB，一天產(chǎn)生的原始圖像為1 EB，預(yù)計(jì)從2020年開始第一階段的建設(shè).上述大型天文觀測項(xiàng)目已對當(dāng)前的數(shù)據(jù)管理框架產(chǎn)生了巨大的挑戰(zhàn)，高吞吐量、大規(guī)模存儲(chǔ)與快速的查找已成為了主要的問題.

值得一提的是，萬萌等人[9]已對當(dāng)前的GWAC數(shù)據(jù)管理場景進(jìn)行了一定的研究工作，并提出了基于MonetDB數(shù)據(jù)庫的管理方案.已開發(fā)出的GWAC數(shù)據(jù)生成器gwac_dbgen[6]能夠模擬一個(gè)CCD連續(xù)產(chǎn)生的真實(shí)數(shù)據(jù)格式和量級(jí).此外，基于該生成器的模擬數(shù)據(jù)使用SQL實(shí)現(xiàn)了MonetDB數(shù)據(jù)庫內(nèi)的交叉認(rèn)證算法以避免數(shù)據(jù)的移動(dòng).但當(dāng)累計(jì)數(shù)據(jù)規(guī)模較大時(shí)，MonetDB的擴(kuò)展性較差且入庫時(shí)間不夠穩(wěn)定.

2 面向GWAC的星表數(shù)據(jù)管理系統(tǒng)設(shè)計(jì)

結(jié)合GWAC天文大數(shù)據(jù)的特性和研究現(xiàn)狀，本文采用兩級(jí)緩存架構(gòu)和星表簇模型，建立一個(gè)高性能、可擴(kuò)展的面向GWAC的星表數(shù)據(jù)管理系統(tǒng).該系統(tǒng)能夠?qū)崿F(xiàn)在15 s內(nèi)存儲(chǔ)多鏡頭并行輸出的數(shù)據(jù)、瞬變源發(fā)現(xiàn)和提供秒級(jí)查詢服務(wù)，此外星表簇模型有利于平衡持久化時(shí)間與離線查詢效率.

如圖2所示，該系統(tǒng)中和數(shù)據(jù)管理相關(guān)的部件主要包括4個(gè)部分：一級(jí)緩存管理、二級(jí)緩存管理、數(shù)據(jù)持久化和查詢引擎.

Fig. 2 Architecture of GWAC data management system圖2 面向GWAC的星表數(shù)據(jù)管理系統(tǒng)架構(gòu)

Fig. 3 Distributed GWAC data generator圖3 分布式GWAC數(shù)據(jù)模擬生成器架構(gòu)

在文獻(xiàn)[9]中，所有CCD產(chǎn)生星表匯入同一個(gè)MonetDB數(shù)據(jù)庫后，再使用SQL對其進(jìn)行交叉認(rèn)證，從而產(chǎn)生一定的性能瓶頸.本文設(shè)計(jì)的GWAC星表數(shù)據(jù)管理系統(tǒng)為分布式結(jié)構(gòu)，一級(jí)緩存為分布式節(jié)點(diǎn)的本地內(nèi)存，二級(jí)緩存為分布式共享內(nèi)存.當(dāng)某CCD客戶端發(fā)送星表數(shù)據(jù)進(jìn)入系統(tǒng)后，系統(tǒng)會(huì)在某節(jié)點(diǎn)上創(chuàng)建對應(yīng)客戶端的接收端接收星表數(shù)據(jù)，直接進(jìn)行交叉認(rèn)證，然后將星表數(shù)據(jù)交由瞬變源發(fā)現(xiàn)模塊進(jìn)行異常檢測，最后每個(gè)CCD對應(yīng)的接收端將星表數(shù)據(jù)寫入分布式共享內(nèi)存中，供用戶實(shí)現(xiàn)高速查詢.設(shè)計(jì)一級(jí)緩存的目的是：1)不同CCD產(chǎn)生的星表數(shù)據(jù)是無共享的(shared-nothing)，因此處理就具備了并行性；2)瞬變源的發(fā)現(xiàn)與預(yù)警需要實(shí)時(shí)檢測，因此需要獲取數(shù)據(jù)后盡快在本地處理；3)為了保證分布式共享內(nèi)存故障后數(shù)據(jù)高可靠，需要使用本地內(nèi)存做緩存實(shí)現(xiàn)延時(shí)寫.設(shè)計(jì)二級(jí)緩存的目的是：1)天文研究者會(huì)在某顆星異常后，快速查詢其最近的光變曲線以快速定位科學(xué)發(fā)現(xiàn)，但事先并不知道哪顆星會(huì)異常，因此需要將一個(gè)觀測夜的數(shù)據(jù)緩存入分布式共享內(nèi)存中供研究者快速查詢；2)一級(jí)緩存容量是有限的，不足以承載一個(gè)CCD的整個(gè)觀測夜數(shù)據(jù).

在觀測夜結(jié)束后，將當(dāng)前觀測夜的數(shù)據(jù)持久化到硬盤.因?yàn)閷?shí)際需求決定了星之間沒有太多物理關(guān)聯(lián)，因此幾乎不做連接操作.介于此，既可以將所有的星存儲(chǔ)到一個(gè)物理表文件中，又可以將每個(gè)星單獨(dú)建表.單獨(dú)建表的開銷很高，但查詢單顆星的光變曲線的效率很高，反之亦然.本文設(shè)計(jì)一種星表簇存儲(chǔ)結(jié)構(gòu)將某些星聚合為大表，兼顧存儲(chǔ)與查詢.因?yàn)樾潜泶亟Y(jié)構(gòu)的存在，對星光變曲線的查詢，需要解析為對星表簇文件的搜索和查詢.

2.1 分布式GWAC數(shù)據(jù)模擬生成器

由于GWAC系統(tǒng)目前正在調(diào)試階段，并未上線.為了更為真實(shí)地模擬GWAC數(shù)據(jù)對系統(tǒng)的壓力測試，本文重寫了gwac_dbgen模擬器為gwac_dbgen_cluster，可以用于模擬多個(gè)CCD同步產(chǎn)生星表數(shù)據(jù)流，每個(gè)模擬的CCD以每15 s產(chǎn)生約17萬行星表數(shù)據(jù)的速度產(chǎn)生數(shù)據(jù)(為了盡量還原真實(shí)場景，每次產(chǎn)生的星表數(shù)據(jù)行數(shù)不一定相等)，每行數(shù)據(jù)23列.

如圖3所示，為了保證所有CCD產(chǎn)生數(shù)據(jù)的同步性，本文設(shè)計(jì)分布式GWAC數(shù)據(jù)模擬生成器為主從結(jié)構(gòu)，時(shí)鐘同步器由主節(jié)點(diǎn)控制.詳細(xì)來說，生成器分為主節(jié)點(diǎn)、模擬CCD(從節(jié)點(diǎn))、監(jiān)控端和客戶端等4部分組成：1)主節(jié)點(diǎn)負(fù)責(zé)整體時(shí)鐘同步、與客戶端交互、整體集群控制和監(jiān)控集群數(shù)據(jù)產(chǎn)生情況；2)模擬CCD負(fù)責(zé)產(chǎn)生星表數(shù)據(jù)，將數(shù)據(jù)發(fā)送一級(jí)緩存，并向主節(jié)點(diǎn)匯報(bào)當(dāng)次數(shù)據(jù)產(chǎn)生情況；3)監(jiān)控端負(fù)責(zé)開啟、關(guān)閉模擬CCD并監(jiān)控模擬CCD的性能情況向主節(jié)點(diǎn)匯報(bào)；4)客戶端用于控制整體集群狀態(tài)，目前設(shè)計(jì)的有addAbormalStarClient向某個(gè)模擬CCD加入異常星、getStatisticsDataClient獲取整個(gè)集群數(shù)據(jù)產(chǎn)生情況，并向UI節(jié)點(diǎn)輸出展示和stopClusterClient用于正?；驈?qiáng)制關(guān)閉集群所有服務(wù).

2.2 兩級(jí)緩存架構(gòu)

如圖4所示，每個(gè)CCD各自產(chǎn)生星表數(shù)據(jù)，通過各自的交叉認(rèn)證模塊匹配模板星表.隨后將認(rèn)證后的星表發(fā)送給一級(jí)緩存管理器，一般交叉認(rèn)證模板和緩存管理器在同一物理服務(wù)器上，通過命名管道完成數(shù)據(jù)交互.由于要實(shí)時(shí)進(jìn)行異常檢測，緩存管理器將整個(gè)星表拆分為若干塊，并行進(jìn)行異常檢測，如圖4中CCD 2的一級(jí)緩存.檢測完成后將星表寫入二級(jí)緩存，供天文科研人員快速查詢.綜上，本文使用各子CCD數(shù)據(jù)在本地處理的策略，將整個(gè)大星表數(shù)據(jù)分而治之，在一級(jí)緩存中進(jìn)一步拆分星表，進(jìn)行實(shí)時(shí)異常檢測和快速寫二級(jí)緩存.以上即可完成多鏡頭輸出數(shù)據(jù)不堆積，且實(shí)時(shí)進(jìn)行異常檢測的目的.

Fig. 4 Architecture of two-level cache圖4 兩級(jí)緩存架構(gòu)示意圖

本文使用Redis cluster作為二級(jí)緩存，Redis cluster是典型的KV(key-value)式緩存.從不同星的角度看，星表結(jié)構(gòu)本身就是一個(gè)典型的KV結(jié)構(gòu)，星名為key，隨后的屬性為value.從同一顆星的時(shí)間序列來看，可以用list結(jié)構(gòu)存儲(chǔ).因此，如圖4所示，隨時(shí)間累積的整個(gè)星表是一個(gè)典型的KV-list結(jié)構(gòu)，而Redis cluster支持該結(jié)構(gòu)，并通過優(yōu)化可以達(dá)到很好的性能.

Redis cluster是一個(gè)無中心的集群結(jié)構(gòu)，每個(gè)邏輯的Master節(jié)點(diǎn)，一般都會(huì)加入一個(gè)對應(yīng)的Slave節(jié)點(diǎn)備份其數(shù)據(jù)以提供讀服務(wù)，因此會(huì)形成很多的〈Master, Slave〉節(jié)點(diǎn)對.然而，若某節(jié)點(diǎn)對中Master或Slave故障后，雖然整個(gè)集群還可以工作，但會(huì)存在單點(diǎn)風(fēng)險(xiǎn).介于此，本文向整個(gè)Redis cluster再加入部分Slave節(jié)點(diǎn)作為整個(gè)集群的后備，以進(jìn)一步提高集群可用性.如圖4中，Slave 1和Slave 4都屬于Master 1節(jié)點(diǎn)的從節(jié)點(diǎn)，若Slave 2節(jié)點(diǎn)(Master 2節(jié)點(diǎn)的從節(jié)點(diǎn))故障，Slave 4節(jié)點(diǎn)會(huì)自動(dòng)遷移為Master 2的從節(jié)點(diǎn)，以預(yù)防潛在的單點(diǎn)風(fēng)險(xiǎn).需要注意的是，加入過多的后備Slave節(jié)點(diǎn)會(huì)提高網(wǎng)絡(luò)和內(nèi)存開銷，使整體性能下降.

本文并不認(rèn)為Redis cluster是可靠的，在Redis cluster故障后，恢復(fù)階段的寫操作會(huì)引起數(shù)據(jù)丟失.如圖4所示，在Redis cluster恢復(fù)階段，一級(jí)緩存管理器將未寫完的上一個(gè)15 s數(shù)據(jù)掛起實(shí)現(xiàn)延時(shí)存儲(chǔ)，以承接下一次15 s的星表數(shù)據(jù).該策略可以實(shí)現(xiàn)CCD產(chǎn)生數(shù)據(jù)的及時(shí)處理和數(shù)據(jù)的高可靠性.

2.3 持久化操作

二級(jí)緩存用于快速處理當(dāng)前觀測夜的數(shù)據(jù)，并不能用于持久化所有觀測夜的星表數(shù)據(jù).隨著當(dāng)前觀測夜結(jié)束，二級(jí)緩存上數(shù)據(jù)的“熱度”自然下降，需要持久化到速度更慢的硬盤上，為離線分析做準(zhǔn)備.

天文科研人員很大一部分的查詢需求是關(guān)注某顆星的光變曲線，因此最為理想的存儲(chǔ)方法是一顆星一張物理表.當(dāng)需要查詢光變曲線時(shí)，只需按星名找到該表，并按照給定的時(shí)間段掃描該表即可.但這種存儲(chǔ)方式的問題是小表太多，按照GWAC設(shè)計(jì)標(biāo)準(zhǔn)來說，40個(gè)CCD能發(fā)現(xiàn)680萬顆左右的星，也就對應(yīng)著680萬個(gè)小表.過多的小表的隨機(jī)寫和管理代價(jià)過高，有時(shí)候甚至導(dǎo)致整個(gè)白天的時(shí)間不足以完成持久化操作，導(dǎo)致數(shù)據(jù)堆積在二級(jí)緩存中.

如圖5所示，本文依托天文數(shù)據(jù)查詢的特征發(fā)現(xiàn)多數(shù)查詢會(huì)批量搜索某一范圍內(nèi)星的各類屬性，因此按照星之間的距離特征作為Hash函數(shù)，將鄰近星映射到同一個(gè)Hash桶內(nèi)，構(gòu)成星表簇.再考慮到不同星表簇的查詢熱度不同，因此不同的星表簇內(nèi)所聚合的星的個(gè)數(shù)不同.例如，越容易查詢到的星(異常星)，所在的星表簇越小，查詢就會(huì)越快，極端情況下會(huì)將單顆星作為一個(gè)星表簇.反之，查詢熱度不高的區(qū)域存儲(chǔ)為一個(gè)大的星表簇便于存儲(chǔ)，降低數(shù)據(jù)管理的開銷.

Fig. 5 Persistence of star tables圖5 星表數(shù)據(jù)持久化示意圖

實(shí)現(xiàn)上，本文使用Spark[10]和HDFS[11]實(shí)現(xiàn)持久化操作.在將星名映射到不同的Hash桶之后，使用Spark對每個(gè)Hash桶中的星批量從Redis cluster讀出，經(jīng)過Spark sql[12]的建表操作，壓縮后寫入HDFS.為提高寫性能，不同Hash桶的寫操作是可以并行執(zhí)行的.需要注意的是，同一個(gè)CCD的星表簇?cái)?shù)據(jù)需要寫入同一個(gè)CCD的目錄下，以便于快速檢索.從本質(zhì)上看，為了查找某顆星的光變曲線，需要經(jīng)過兩級(jí)檢索：1)確定該星所在的CCD;2)確定該星所在的星表簇.

2.4 查詢操作

基于星表簇的存儲(chǔ)方式，查詢操作并不能直接使用SQL完成，對于某些查詢而言需要做一定程度的解析.

查詢共分為2種類型:1)返回的結(jié)果不需要隨時(shí)間變化的屬性，如查詢某位置范圍內(nèi)所有出現(xiàn)的星名；2)返回的結(jié)果需要隨時(shí)間變化的屬性，如返回某顆星的光變曲線.通過收集天文查詢需求，本文發(fā)現(xiàn)天文學(xué)家雖然關(guān)注光變曲線，如圖6，但是鎖定查詢哪條光變曲線的操作往往集中在不變的屬性列上.如查詢某個(gè)范圍內(nèi)所有星的光變曲線，首先是查詢該范圍內(nèi)的所有星名，其次是查詢該星的光變曲線.因此，無論結(jié)果是否需要隨時(shí)間變化的屬性數(shù)據(jù)，都需要先查詢與時(shí)間無關(guān)的屬性數(shù)據(jù).

Fig. 6 Procedure of query operations圖6 查詢操作流程

如圖6所示，本文合并所有CCD交叉認(rèn)證時(shí)使用的模板表，并加入一些隨時(shí)間變化數(shù)據(jù)的統(tǒng)計(jì)列，如亮度均值、方差、最大值和最小值等，構(gòu)成一個(gè)邏輯上的索引表，因?yàn)樵摫砗苄。梢猿ｑv內(nèi)存.一個(gè)查詢請求到來后，先判斷結(jié)果的屬性列是否需要隨時(shí)間變化的屬性，如果不需要，查找索引表，直接返回；如果需要，查找索引表，找出滿足要求的星名，然后查找原始數(shù)據(jù).這樣做的好處是：1)對于結(jié)果不需要隨時(shí)間變化的數(shù)據(jù)，查找索引表能避免掃描原始星表數(shù)據(jù)，提高查找性能；2)對于結(jié)果需要隨時(shí)間變化的數(shù)據(jù)，查找索引表能最小化掃描原始星表數(shù)據(jù)的次數(shù)和范圍，以提高查找性能.

對于采用緩存架構(gòu)的本系統(tǒng)而言，原始星表數(shù)據(jù)存儲(chǔ)于二級(jí)緩存(Redis cluster)和硬盤(HDFS)上，查找條件有可能涉及到這2個(gè)數(shù)據(jù)源.因此，就查詢數(shù)據(jù)源而言，可分為以下3種策略對原始星表查詢.

1) 僅從二級(jí)緩存查詢.查找索引表找出滿足條件的星名集合；將該集合傳入Redis cluster查詢對應(yīng)星的全部屬性列；篩選符合條件的屬性列.

2) 僅從硬盤查詢.查找索引表找出滿足條件的星名集合；使用持久化的Hash函數(shù)將星名的結(jié)果集合映射到星表簇；對同一星表簇的星進(jìn)行批量查詢并篩選符合條件的屬性列；對于不同的星表簇可以并行查詢；最后合并不同星表簇的結(jié)果.

3) 從二級(jí)緩存和硬盤查詢.并行從2個(gè)數(shù)據(jù)源按照上述的策略查詢，最終將結(jié)果合并.

3 系統(tǒng)驗(yàn)證與分析

3.1 實(shí)驗(yàn)準(zhǔn)備

本文在Ubuntu 14.04,Hadoop 2.6.0,Spark 1.6.2和Redis 3.2.5平臺(tái)上建立了驗(yàn)證系統(tǒng)，采用10臺(tái)物理機(jī)構(gòu)建Hadoop,Spark,Redis cluster和分布式GWAC數(shù)據(jù)模擬生成器集群.對于Hadoop,Spark和分布式GWAC數(shù)據(jù)模擬生成器集群都使用相同的物理機(jī)作為主節(jié)點(diǎn)，剩下的9個(gè)物理機(jī)作為從節(jié)點(diǎn)(模擬9個(gè)CCD)，此外Spark使用standalone模式進(jìn)行資源管理.對于無中心結(jié)構(gòu)的Redis cluster，每個(gè)物理機(jī)上開啟4個(gè)Redis節(jié)點(diǎn)進(jìn)程，共40個(gè)節(jié)點(diǎn)，并且另加入8個(gè)Redis slave節(jié)點(diǎn)作為整個(gè)Redis集群的冗余備份.

整個(gè)物理集群為同構(gòu)環(huán)境，每臺(tái)物理機(jī)使用英特爾i7-4790處理器、32 GB DDR3-1600內(nèi)存和1塊500 GB 7200 SATA硬盤，節(jié)點(diǎn)之間采用萬兆以太網(wǎng)互聯(lián).

3.2 實(shí)驗(yàn)結(jié)果分析

為驗(yàn)證GWAC星表數(shù)據(jù)管理系統(tǒng)的有效性，實(shí)驗(yàn)開展了如下工作：1)分布式GWAC數(shù)據(jù)模擬生成實(shí)驗(yàn)；2)寫緩存效率；3)持久化效率；4)查詢效率.

1) 分布式GWAC數(shù)據(jù)模擬生成

由于產(chǎn)生的數(shù)據(jù)需要緩存進(jìn)Redis cluster中，因此本集群環(huán)境的內(nèi)存容量不可能容納當(dāng)前觀測夜的所有數(shù)據(jù)量(約3 TB).經(jīng)過測試，現(xiàn)有集群環(huán)境能模擬9個(gè)CCD同步拍攝300次(相當(dāng)于1.25 h)的整個(gè)過程.實(shí)驗(yàn)結(jié)果表明，模擬數(shù)據(jù)產(chǎn)生過程很穩(wěn)定，單個(gè)星表的產(chǎn)生時(shí)間約為3 s，低于真實(shí)CCD產(chǎn)生一副圖像需要的15 s，因此可以用來模擬GWAC數(shù)據(jù)產(chǎn)生過程.單個(gè)模擬星表的星個(gè)數(shù)在(175567，175675)之間不等，每個(gè)星表大約33 MB符合真實(shí)場景，300次共產(chǎn)生87 GB星表數(shù)據(jù).

2) 寫緩存效率

如圖7所示，9個(gè)CCD單次交叉驗(yàn)證且并行寫Redis cluster的時(shí)間維持在1.35 s以下，平均耗時(shí)1.08 s，在整個(gè)寫緩存過程中時(shí)間沒有出現(xiàn)顯著的抖動(dòng).因此，兩級(jí)緩存結(jié)構(gòu)的設(shè)計(jì)方案能夠滿足GWAC實(shí)際需求，各CCD產(chǎn)生的數(shù)據(jù)不會(huì)出現(xiàn)堆積現(xiàn)象.此外，9個(gè)CCD的星表數(shù)據(jù)寫入Redis cluster 300次共消耗內(nèi)存269 GB.消耗的內(nèi)存量大于總共產(chǎn)生的數(shù)據(jù)量，原因如下：①所有Master節(jié)點(diǎn)存儲(chǔ)原始數(shù)據(jù)，Slave節(jié)點(diǎn)備份產(chǎn)生的星表數(shù)據(jù)，總共需要消耗178 GB內(nèi)存空間(較產(chǎn)生的原始數(shù)據(jù)需要增加2列交叉認(rèn)證數(shù)據(jù)，因此實(shí)際存儲(chǔ)數(shù)據(jù)量大于2×87 GB=174 GB)；②另加入的8個(gè)Slave節(jié)點(diǎn)在集群正常工作時(shí)，作為某個(gè)Master節(jié)點(diǎn)的備份需要消耗36 GB內(nèi)存空間；③Redis cluster維護(hù)整個(gè)數(shù)據(jù)結(jié)構(gòu)，如指針、元數(shù)據(jù)等，需要消耗55 GB左右的內(nèi)存空間，約占所消耗總空間量的20%.

Fig. 7 Time consumed by cross match and writing to Redis圖7 交叉認(rèn)證和寫Redis cluster總時(shí)間的箱線圖

3) 持久化效率

本節(jié)實(shí)驗(yàn)對已寫入Redis cluster的9個(gè)CCD的星表數(shù)據(jù)進(jìn)行持久化操作，并測試效率.為了發(fā)現(xiàn)持久化時(shí)間和星表簇之間的關(guān)系，本文分別測試了如圖8橫坐標(biāo)所示的8種不同的星表簇個(gè)數(shù)，如90代表將9個(gè)CCD的星表數(shù)據(jù)劃分入90個(gè)星表簇中，其中一個(gè)CDD平均有10個(gè)星表簇.

如圖8所示，隨著星表簇的增多，持久化所需要的時(shí)間越來越長，主要原因是：①簇內(nèi)星表數(shù)據(jù)減少導(dǎo)致隨機(jī)寫的代價(jià)升高；②簇個(gè)數(shù)的增多導(dǎo)致創(chuàng)建簇的代價(jià)升高.上述現(xiàn)象導(dǎo)致星表簇個(gè)數(shù)和持久化時(shí)間的正相關(guān)關(guān)系.當(dāng)星表簇個(gè)數(shù)達(dá)到9 000時(shí)，持久化時(shí)間為7.9 h，繼續(xù)增加星表簇個(gè)數(shù)會(huì)導(dǎo)致持久化時(shí)間的繼續(xù)增長，過長的持久化時(shí)間已經(jīng)不能滿足白天進(jìn)行持久化的基本要求.介于此，本實(shí)驗(yàn)不再繼續(xù)增加星表簇個(gè)數(shù)，并認(rèn)為每個(gè)CCD的星表數(shù)據(jù)劃入1 000個(gè)星表簇是當(dāng)前實(shí)驗(yàn)集群能接受的最大值.當(dāng)星表簇個(gè)數(shù)在90～900之間時(shí)，持久化時(shí)間為11～52 min，該時(shí)間范圍是可容忍和接受的，因此下文將對上述已持久化好的星表簇進(jìn)行查詢，以評(píng)估查詢效率.

Fig. 8 Time consumed by the persistence of star tables sampled by 9 CCDs圖8 9個(gè)CCD星表數(shù)據(jù)持久化為不同數(shù)目的星表簇所需的時(shí)間

4) 查詢效率

Fig. 9 Time consumed by the query of 20 light curves under the different number of star clusters圖9 在不同的星表簇?cái)?shù)目下批量查詢20顆星的光變曲線所需的時(shí)間

本節(jié)實(shí)驗(yàn)實(shí)現(xiàn)2.4節(jié)的查詢策略，并測試對Redis cluster和星表簇的查詢效率.

實(shí)驗(yàn)隨機(jī)選取20個(gè)星名(對不同數(shù)量星表簇的測試都使用這20顆星)，并查詢這20顆星在1.25 h之間的光變曲線.當(dāng)查詢Redis cluster時(shí)，查詢時(shí)間維持在4～5 s之間.如圖9所示，當(dāng)查詢星表簇時(shí)，查詢時(shí)間也以秒為單位，且整體趨勢是隨著星表簇個(gè)數(shù)的增加，查詢所需時(shí)間越短.這種現(xiàn)象的主要原因是星表簇內(nèi)星的減少，導(dǎo)致每次讀取的數(shù)據(jù)量更少，掃描效率更高.

隨著星表簇個(gè)數(shù)的增加，持久化效率和查詢效率呈現(xiàn)不同的性質(zhì)，因此就實(shí)驗(yàn)結(jié)果而言本文認(rèn)為900個(gè)星表簇是較好的一個(gè)平衡點(diǎn).

4 結(jié) 論

針對GWAC天文大數(shù)據(jù)的特性和面向該類數(shù)據(jù)的管理挑戰(zhàn)，本文提出了一套有針對性的數(shù)據(jù)管理架構(gòu)和系統(tǒng)原型.其中包括：1)分布式GWAC模擬生成器；2)兩級(jí)緩存架構(gòu)；3)基于星表簇的存儲(chǔ)策略；4)基于索引表的查詢策略.通過實(shí)驗(yàn)驗(yàn)證，目前設(shè)計(jì)的原型系統(tǒng)能夠?qū)崿F(xiàn)實(shí)時(shí)存儲(chǔ)GWAC每個(gè)采樣周期的數(shù)據(jù)、實(shí)時(shí)瞬變源發(fā)現(xiàn)，秒級(jí)查詢響應(yīng)，持久化當(dāng)前觀測夜數(shù)據(jù)和快速的離線查詢.未來的挑戰(zhàn)主要在于提高查詢效率和減小管理持久化數(shù)據(jù)的代價(jià)，實(shí)現(xiàn)對星表簇拆分和合并操作.

[1]Boncz P, Grust T, Van Keulen M, et al. MonetDB/XQuery: A fast XQuery processor powered by a relational engine[C] //Proc of the 2006 ACM SIGMOD Int Conf on Management of Data. New York: ACM, 2006: 479-490

[2]Wan Meng. An application research of column store MonetDB databaseon GWAC large-scale astronomical data management[D]. Beijing: National Astronomical of Observatories, Chinese Academy of Sciences, 2016 (in Chinese)(萬萌. 列存儲(chǔ)MonetDB數(shù)據(jù)庫在GWAC海量天文數(shù)據(jù)管理的應(yīng)用研究[D]. 北京: 中國科學(xué)院國家天文臺(tái), 2016)

[3]Apache. Kafka[OL]. [2016-12-30]. http://kafka.apache.org/

[4]Apache. Hbase[OL]. [2016-12-30]. http://hbase.apache.org/

[5]Redislabs. Redis[OL]. [2016-12-30]. https://redis.io/

[6]Wan Meng. Gwac-dbgen[OL]. [2016-12-30]. https://github.com/wan-meng/gwac_dbgen

[7]Jian L I, Cui C Z, Bo-Liang H E, et al. Review and prospect of the astronomical database[J]. Progress in Astronomy, 2013, 31(1): 1-16

[8]SDSS. Skyserver[OL]. [2016-12-30]. http://skyserver.org/

[9]Wan Meng, Wu Chao, Wang Jing, et al. Column store for GWAC: A high-cadence, high-density, large-scale astronomical light curve pipeline and distributed shared-nothing database[J]. Publications of the Astronomical Society of the Pacific, 2016, 128(969): 114501-114516

[10]Zaharia M, Chowdhury M, Franklin M J, et al. Spark: Cluster computing with working sets[C] //Proc of USENIX Conf on Hot Topics in Cloud Computing. Berkeley, CA: USENIX Association, 2010: 1765-1773

[11]Apache. Hadoop[OL]. [2016-12-30]. https://hadoop.apache.org/

[12]Armbrust M, Xin R S, Lian C, et al. Spark sql: Relational data processing in spark[C] //Proc of the 2015 ACM SIGMOD Int Conf on Management of Data. New York: ACM, 2015: 1383-1394

Yang Chen, born in 1987. PhD candidate. His main research interests include science data management and performance bottleneck quantification.

Weng Zujian, born in 1992. Postgraduate student. His main research interests include data stream computing and energy efficient computing.

Meng Xiaofeng, born in 1964. PhD, professor at Renmin University of China. CCF fellow. His main research interests include data fusion and knowledge fusion, big data management for new hardware, big data real time and interactive analysis, and big data privacy management.

Ren Wei, born in 1990. PhD candidate. His main research interests include database theory, data storage, and software engineering.

Xin Rihui, born in 1993. Postgraduate student. His main research interests include science data management and performance bottleneck quantification.

Wang Chunkai, born in 1981. PhD candidate. His current research interests include data stream computing and distributed systems.

Du Zhihui, born in 1970. PhD, associate professor. Senior member of IEEE and CCF. His main research interests include high performance computing, cloud computing, energy efficient computing and big data analysis.

Wan Meng, born in 1983. PhD, engineer. Her main research interests include astronomical big-data architecture, column-store databases, and computing system analysis.

Wei Jianyan, born in 1965. PhD, researcher, PhD supervisor, the leading scientist of SVOM astronomical satellite. His main research interests include space astronomy, active galactic nuclei, gamma burst observation, etc.

Data Management Challenges and Real-Time Processing Technologies in Astronomy

Yang Chen1, Weng Zujian1, Meng Xiaofeng1, Ren Wei1, Xin Rihui1, Wang Chunkai1, Du Zhihui2,Wan Meng3and Wei Jianyan3

1(SchoolofInformation,RenminUniversityofChina,Beijing100872)2(DepartmentofComputerScienceandTechnology,TsinghuaUniversity,Beijing100084)3(NationalAstronomicalofObservatories,ChineseAcademyofSciences,Beijing100012)

In recent years, many large telescopes, which can produce petabytes or exabytes of data, have come out. These telescopes are not only beneficial to the find of new astronomical phenomena, but also the confirmation of existing astronomical physical models. However, the produced star tables are so large that the single database cannot manage them efficiently. Taking GWAC that has 40 cameras and is designed by China as an example, it can take high-resolution photos by 15 s and the database on it has to make star tables be queried out in 15 s. Moreover, the database has to process multi-camera data, find abnormal stars in real time, query their recent historical data very fast, persist and offline query star tables as fast as possible. Based on these problems, firstly, we design a distributed data generator to simulate the GWAC working process. Secondly, we address a two-level cache architecture which cannot only process multi-camera data and find abnormal stars in local memory, but also query star table in a distributed memory system. Thirdly, we address a storage format named star cluster, which can storage some stars into a physical file to trade off the efficiency of persistence and query. Last, our query engine based on an index table can query from the second cache and star cluster format. The experimental results show our distributed system prototype can satisfy the demand of GWAC in our server cluster.

astronomy big data management; the ground-based wide-angle camera array (GWAC); two-level cache; star cluster; index table

2017-01-06；

2017-01-09

國家重點(diǎn)研發(fā)計(jì)劃項(xiàng)目(2016YFB1000602) This work was supported by the National Key Research Program of China (2016YFB1000602).

孟小峰(xfmeng@ruc.edu.cn)

TP311.133.1