摘 要：超大型天文觀測技術的出現不僅能夠讓研究人員觀測到新的天文現象，更能用于驗證已有物理模型的正確性。這些最新天文成果的發現是建立在海量天文數據的近乎實時產生、管理與分析的基礎上，因此給目前的數據管理系統帶來了新的挑戰。以我國自主研發的地基廣角相機陣（the ground-basedwide-angle camera array,GWAC）天文望遠鏡為例，15s的采樣和處理周期都處于短時標觀測領域的世界前列，但卻對數據管理系統提出了很多問題，包括多鏡頭并行輸出數據管理、實時瞬變源發現、當前觀測夜數據的秒級查詢、數據持久化和快速離線查詢等?；谏鲜鰡栴}，設計了分布式GWAC數據模擬生成器用于模擬真實GWAC數據產生場景，并基于產生的數據特性，提出一種兩級緩存架構，使用本地內存解決多鏡頭并行輸出、實時瞬變源發現，使用分布式共享內存實現秒級查詢。為了平衡持久化和查詢效率，設計一種星表簇結構將整個星表數據劃分后聚集存儲。根據天文需求特點，設計基于索引表的查詢引擎能從緩存和星表簇以較小的代價對星表數據查詢。通過實驗驗證，當前方案能夠滿足GWAC的需求。

關鍵詞：天文大數據管理；地基廣角相機陣；兩級緩存；星表簇；索引表。

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

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

目前在國際上，美國的SDSS望遠鏡的采樣周期是71.72s,每次采樣的數據處理周期是1個月。美國設計的LSST采樣周期是39s,每次采樣的數據處理周期是60s.中國設計的GWAC不同于其他天文觀測技術，由40臺廣角望遠鏡組成，單個觀測夜中，所有望遠鏡要求同步地每15s采樣一次，并于下一次采樣前將原始圖像數據轉化為星表數據，與此同時數據還要處于可查詢狀態，以支持短時標天文現象的發現。因此，無延遲的處理數據，對當前數據管理系統提出了新的挑戰。

傳統的關系型內存數據庫，如MonetDB[1],入庫時間變動過大，極容易引起下一次數據來到后上一次數據還未寫入完成，造成擁塞[2]而非關系型數據庫，如Kafka[3]+Hbase[4],實驗表明單個鏡頭一次產生的數據量寫入Kafka需要2.7s,不會造成數據擁塞，但寫入Hbase需要5min左右，并不能滿足實時查詢要求。

針對上述問題，本文提出一種兩級緩存架構方案以支持無擁塞承接每個采樣周期數據，且保證數據可查。結合GWAC背景，本文認為每個望遠鏡產生的數據之間相互獨立，因此設計每個望遠鏡由一臺服務器承接剛產生的數據，進行必要的處理后，如交叉認證（見1.2節），緩存入本地內存（一級緩存），并直接進行異常天文現象的識別。繼而，每臺服務器上的緩存管理器異步將一級緩存的數據寫入二級緩存。二級緩存使用分布式共享內存實現，如Rediscluster[5]可以看出，一級緩存的作用如下： 1）快速承接每個望遠鏡產生的數據；2）快速進行異常檢測；3）二級緩存故障后，保證數據的可靠性。兩級緩存架構可以實現多鏡頭并行輸出、異常天文現象發現、低延遲存儲和秒級查詢。

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

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

為了驗證上述方案的有效性，本文改寫單鏡頭版GWAC模擬數據生成器[6]為分布式GWAC模擬數據生成器，可用于模擬多個望遠鏡同步產生星表數據。作者在一個小型的原型系統上實現了整個數據產生、存儲和查詢過程并進行了實驗驗證。實驗結果表明，當前的設計方案能夠支撐GWAC系統日常的業務需求。

本文主要貢獻如下：

1）設計分布式GWAC模擬數據生成器，能夠更真實地模擬多個望遠鏡同步產生星表數據的應用場景；2）提出一種兩級緩存架構的數據管理方案，針對性地解決多鏡頭并行輸出、實時瞬變源發現和秒級查詢等問題；3）針對當前觀測夜星表數據持久化時間限制及離線查詢效率的相應要求，設計一種星表簇的存儲結構兼顧持久化與查詢性能；4）設計一種針對索引表和星表簇結構的查詢策略，能夠盡可能少地訪問持久化數據，或訪問持久化數據的部分子集以提高查詢效率。

本文首先介紹GWAC背景和面向星表數據管理的相關工作，然后重點介紹面向GWAC星表數據管理系統設計，最后給出系統驗證與分析結果。

1相關背景

1.1 GWAC相機陣介紹

我國興建中的地基廣角相機陣GWAC由40臺口徑為18cm的廣角望遠鏡組成，每臺望遠鏡配備4k×4k的電荷耦合器件（charge coupled device,CCD）探測器①。整個相機陣的天區覆蓋5 000平方度，時間采樣周期為15s.每個觀測夜對固定天區目標的持繼觀測長達10h.從觀測視場的大小和觀測時間的采樣頻度上，地面廣角相機陣在時域天文觀測中具有特殊的優勢。巨大的數據量和高速采樣率，對數據的管理和處理問題提出極大的挑戰。地面廣角相機陣的星表數據指標是：1）星表數據每幅圖像大約有1.7×105條記錄，整個相機陣在15s內共產生6.8×106（數據量約為1.3GB）條記錄，每晚約有2400×40=96000幅圖，大約需要2TB的存儲開銷；2）以10年為設計周期，GWAC總計將產生3~6PB量級的超大規模星表。