大數據存儲技術在張衡一號衛星數據服務中的應用

楊旭明, 王志,2, 李忠,2*, 黃建平, 楊百一, 陳朝陽,2

(1.防災科技學院應急管理學院, 廊坊 065201; 2.防災科技學院智能應急信息處理研究所, 廊坊 065201; 3.應急管理部國家自然災害防治研究院, 北京 100085)

“張衡一號”地震電磁衛星(以下簡稱ZH-1)的成功發射標志著中國已經成為世界上少數擁有在軌運行高精度地球物理場探測衛星的國家之一。ZH-1是中國地震立體觀測體系天基觀測平臺的首顆衛星,主要科學研究目標是通過獲取全球電磁場、電離層等離子體、高能粒子觀測數據,對中國及其周邊區域開展電離層動態實時監測和地震前兆跟蹤,彌補地面觀測的不足,探索開展全球7級、中國6級以上地震電磁信息研究,總結電離層擾動特征,開展試驗性質的地震短臨監測,進一步推進中國立體地震觀測體系建設,為國際合作研究提供電磁數據服務,為探索地震監測預測提供了新的技術手段[1]。

ZH-1自發射成功至今已在軌工作4年多,ZH-1衛星搭載8種科學載荷,包括感應式磁力儀、電場探測儀(electric field detector,EFD)、高精度磁強計、GNSS掩星接收機、等離子體分析儀、朗繆爾探針、高能粒子探測器和三頻信標發射機[1]。其中EFD載荷可采集全球范圍的電場數據,是產出數據量最多的載荷之一,每天記錄的數據量可達幾十千兆字節[2],目前累積數據量已經達到幾百太字節,其中不同頻段的波形數據和功率譜數據都是以HDF5文件格式存儲的,主要包括衛星軌道信息數據和載荷物理量數據。衛星軌道信息數據包括載荷名稱、數據類型編碼、軌道號、升降軌標識、采樣頻率、采樣時間、頻率范圍、起始/結束采樣時間;載荷物理量數據包括絕對時間、相對時間、地磁經緯度、地理經緯度、工作模式、功率譜頻率值、衛星軌道高度、功率譜頻率值、功率譜XYZ三分量、電場波形XYZ三分量等。由于EFD每個文件的數據量很大,文件存儲方式的數據查詢訪問效率很低,嚴重制約著后續針對衛星數據的應用和研究工作。為此,高鵬等[3]針對當前ZH-1衛星數據的文件儲存方式訪問效率極低的缺陷,提出了一種利用關系型數據庫存儲衛星數據的存儲方法,顯著提高了衛星數據的查詢訪問時間。然而,面對日益增長的海量衛星數據,基于關系型數據庫的存儲方法具有擴展性差、并發性能偏低、讀寫速度慢、成本高等缺點[4],依然制約著科研人員對數據的檢索訪問效率和實際研究進展。因此,如何解決關系型數據庫存儲面臨的瓶頸問題,并對衛星數據進行高效的存讀取是迫切需要解決的問題。

當前,大數據存儲技術作為處理海量數據的全新數據存儲與計算模式,已經被應用在了很多領域[5]。Jiang等[6]為解決大規模煤礦安全監控數據存儲在關系數據庫中時存儲效率低、查詢速度慢的問題,設計了一種基于HBase的存儲和檢索方法,使用該方法對實際煤礦數據的實驗結果表明,數據存儲和檢索效率顯著提高;張家偉[7]利用HBase數據庫的列存儲特性,從優化數據計算流程、HBase表設計、選取數據分類壓縮算法、搭建Hadoop和HBase環境、壓縮存儲電力數據等幾個步驟設計實現了基于電力數據的高壓縮率和快速存讀取的壓縮存儲系統;劉凱銘等[8]將基于Hadoop框架的大數據技術應用到油氣水井生產大數據的存儲和分析中,解決了海量數據在傳統關系數據庫上查詢效率低的問題,實現了多維數據的在線分析功能;單維鋒等[9]通過深入分析地震前兆時間序列數據的特點以及數據處理的業務需求,首次提出了基于OpenTSDB和HBase結合的優化存儲方案,通過測試分析了該方案在海量時空數據存儲中高效的讀寫和并發性能。

現根據ZH-1衛星空間電場數據科研工作的需求,分析現有存儲方法擴展性差、并發性能偏低、讀寫速度慢、成本高等不足,結合大數據存儲技術的高可擴展性、高并發讀寫性、高可用性等優勢,提出將ElasticSearch搜索引擎和HBase相結合的衛星大數據存儲方案,并以ZH-1衛星記錄的空間電場超低頻(ultra-low frequency,ULF)頻段數據為例,進行存儲實驗和對比測試,以驗證該方案在張衡一號衛星空間電場數據存儲中的高效性和適用性。

1 大數據存儲方案設計

HBase作為分布式存儲數據庫,優勢明顯,主要體現在其容量巨大、列存儲方式的低I/O吞吐量、多副本存儲的高可靠性、快寫入等性能方面[10]。但是HBase僅支持對RowKey的毫秒級高速檢索,而RowKey具有唯一性以及字符長度受限的缺陷,使得HBase對于多字段的組合查詢顯得力不從心。

ElasticSearch作為一個分布式可擴展的實時搜索引擎,能同時支持全文檢索和時序檢索場景,可以支持豐富的查詢需求[11]。但是,ElasticSearch的搜索引擎嚴重依賴于底層的 Filesystem Cache,每當數據查詢時,操作系統都會將磁盤文件里的數據自動緩存到 Filesystem Cache。因此在單獨面對海量數據時,如果把所有查詢字段和非查詢字段都寫入ElasticSearch中,不僅會大大增加ElasticSearch的內存管理成本,還會嚴重影響查詢效率。

因此,通過分析HBase和ElasticSearch的優勢和劣勢,提出將ElasticSearch搜索引擎與HBase各自優勢相結合的存儲方案(以下簡稱ES+HBase存儲方案),通過把海量數據存儲到HBase中,同時在ElasticSearch中建立查詢字段的索引字段,以進一步提升HBase檢索能力,實現對ZH-1衛星海量數據的多條件組合快速查詢。

1.1 基于ElasticSearch和HBase的存儲方案

基于ES+HBase的衛星大數據存儲方案的原理是將HBase表中涉及條件過濾的字段和RowKey作為索引字段在ElasticSearch中建立索引,通過在ElasticSearch中進行多條件組合查詢快速獲得符合過濾條件的RowKey值,最后在HBase中通過從ElasticSearch中獲取到的RowKey進行高速檢索,其原理如圖1所示。

圖1 基于ElasticSearch和HBase結合的存儲方案原理圖Fig.1 Schematic diagram of storage solutions based on ElasticSearch and HBase

由圖1可知,當用戶發起條件查詢請求時,先將請求信息發送給ElasticSearch主機,該主機根據查詢條件從索引字段中獲取相應RowKey值,并將RowKey值返回給用戶,用戶使用獲得的RowKey值去HBase中獲取相應數據集,即可完成整個查詢流程。

1.2 存儲模型設計

基于ES+HBase的衛星大數據存儲方案的存儲模型設計主要包括列族設計、RowKey設計、索引字段設計。RowKey是HBase中最重要的概念,是HBase數據表的唯一主鍵,它按照一定的字典順序存儲的字符串類型數據,并且其字段具有大小限制。另外,它還可以用來進行全表掃描或范圍掃描,這也是HBase訪問數據的方式之一[12]。RowKey設計的總原則是避免熱點現象,提高讀寫性能。

以2020年6月的ZH-1衛星空間電場探測儀的ULF頻段數據為例加以說明。

步驟1根據RowKey設計的長度原則、散列原則和唯一性原則,使用反轉HDF5文件中的時間(UTC_TIME)字段數據作為RowKey前綴,通過讀取HDF5文件名稱和內容中的衛星編號、載荷編碼、載荷序號、數據分級編碼、觀測對象編碼、接收站編碼、版本號組成RowKey,讓數據均衡分布在每個Region-Server,實現負載均衡,提高查詢效率,如圖2所示。

圖2 RowKey設計組成圖Fig.2 Design composition drawing of RowKey

在圖2中,以一個H5文件為例,通過編寫程序代碼,獲取文件中UTC_TIME字段值,進行反轉操作后作為RowKey前綴字段,軟件版本號(SOFTVERSION)屬性值作為RowKey后綴字段,同時提取文件名稱中的衛星編號01、載荷編號EFD、載荷序號1、數據分級編碼L02、觀測對象編碼A1以及接收站編碼000進行組合作為RowKey的中間字段。

步驟2創建包含時間、衛星編碼(SNUM)、探頭編碼、軌道號、軌道高度、升降軌標識、經度、緯度等列字段的列族CF1,包含電場波形XYZ3個分量數據的列族WAVE,以及包含功率譜XYZ3分量數據和頻點值的列族PSD。

步驟3把列族CF1中作為組合查詢條件的列字段和RowKey作為索引字段在ElasticSearch中建立索引。數據存儲模型如圖3所示。

圖3 數據存儲模型Fig.3 Data storage model

圖3中HBase的表名為ZH01_EFD_ULF,ElasticSearch的索引表名為zh01_efd_ulf,其中wave000表示列族WAVE中第一列的列名,psd000表示列族PSD中第一列的列名,WX0_WY0_WZ0表示將波形數據的XYZ三分量的第一個數據進行拼接,PX0_PY0_PZ0表示將功率譜數據的XYZ三分量的第一個數據進行拼接;HBase表中RowKey字段同步到ElasticSearch索引表中作為id字段,HBase表CF1列族中UTC_TIME、SNUM等字段分別在ElasticSearch索引表中創建對應的ES_CF1.UTC_TIME、ES_CF1.SNUM等字段。

2 實驗對比分析

由于文獻[3]通過關系型數據庫方法顯著提高了衛星數據的查詢訪問時間,因此在其基礎上,利用2020年6月的ZH-1空間電場探測儀的ULF頻段數據,通過搭建基于ES+HBase的大數據存儲方案的實驗平臺,與基于Mysql數據庫的關系型數據方法的查詢訪問效率進行對比分析。

2.1 實驗環境配置

搭建了由6臺主機組成的基于Hadoop架構的高可用集群、1臺ElasticSearch主機和1臺Mysql對比測試主機,所有主機的配置為:1個Intel(R) Xeon(R) E5-1620 V2 CPU(3.6 GHz,雙核),8 G內存,1塊4TSATA硬盤,Centos7操作系統和JDK1.8環境。在Hadoop集群相應節點上分別安裝Hadoop3.2.2、ZooKeeper3.6.2、HBase2.2.7軟件,在ElasticSearch主機上安裝ElasticSearch6.8.15軟件,同時在Mysql主機上安裝Mysql5.7數據庫系統。以上每個主機的角色分配情況如表1所示。

表1 ElasticSearch和HBase角色配置Table 1 ElasticSearch and HBase role configuration

2.2 實驗結果分析

實驗通過兩個角度對基于ES+HBase的大數據存儲方法、HBase RowKey查詢方法和Mysql數據

庫方法的查詢訪問效率進行比較。一個是不同存儲數據量基數下查詢相同數據量的效率對比測試;另一個是在相同存儲數據量基數下查詢不同數據量的效率對比測試。

2.2.1 不同存儲量的相同數據查詢效率比較

分別測試在700萬、1 500萬、3 000萬、6 000萬、1億條數據量基數下查詢200萬條數據時不同存儲方案的所用時間,實驗結果如圖4所示。

圖4 不同存儲基數下查詢200萬條數據耗時Fig.4 The time used to query 2 million pieces of data in different storage bases

由圖4可以看出,隨著數據庫中所存儲的數據總量的不斷增大,查詢相同數據時,Mysql數據庫方法的查詢時間持續增加,查詢效率明顯降低;而利用HBase的RowKey查詢的方法與基于ES+HBase存儲方案的查詢效率仍都維持在較高水平、變化很小,且兩者效率相近。

2.2.2 相同存儲量的不同數據查詢效率比較

在1億條數據量基數下分別查詢1萬、10萬、100萬、200萬、300萬5種不同數據量時不同存儲方案的所用時間,其結果如圖5所示。

圖5 1億條數據基數下查詢不同數據量耗時Fig.5 The time used to query different amounts of data in a data base of 100 million

由圖5可以看出,在相同存儲數據量基數下,隨著查詢數據量的不斷增大,Mysql數據庫方法查詢耗時增加明顯;而利用HBase的RowKey查詢的方法與基于ES+HBase存儲方案的查詢耗時增加較為緩慢、變化較小,且兩者效率相近。

通過對以上兩種方式的對比實驗進行分析可知,隨著衛星數據量的不斷增大,傳統Mysql關系型數據庫方法在查詢大數據量時的效率越來越低,而HBase通過RowKey查詢的效率仍維持在較好的狀態,優勢愈發明顯。同時,基于ES+HBase的衛星大數據存儲方案中雖然增加了ElasticSearch索引字段的查詢階段,但是該階段對整體查詢效率的影響是微乎其微的,其效率也非常好。因此,基于ES+HBase相結合的衛星大數據存儲方法不僅增強了HBase的多條件組合查詢的能力,滿足了科研人員對衛星數據的精準查詢需求,還繼承了HBase RowKey查詢方法的高效性,實現了對海量衛星數據的高效查詢訪問。

3 應用效果測試與分析

以ZH-1空間電場探測儀的ULF頻段數據為例,利用3.1節的實驗環境,測試基于ES+HBase相結合的衛星大數據存儲方法的查詢響應效果和在不同條件下檢索數據的應用效果。

3.1 響應時間測試

由于文獻[3]通過關系型數據庫方法顯著提高了衛星數據的查詢訪問時間,因此本實驗在其基礎上,將2019年11月—2020年12月共計14個月的ULF頻段數據存入數據庫中進行查詢響應時間測試,分別測試ES+HBase大數據存儲方法、關系型數據庫和文件存儲方法的響應時間,測試結果如表2所示。

表2 3種存儲方法查詢響應時間對比Table 2 Comparison of query response time of three storage methods

雖然本實驗的硬件環境比文獻[3]的實驗條件差,數據庫存儲量比文獻[3]測試數據量多,但是由表2測試結果可以看出,ES+HBase存儲方法的響應時間都要優于關系型數據庫和文件查詢,該方法的性能幾乎能達到關系型數據庫的1.5倍,是現有文件存儲方式的幾十倍,這種效率的提升增加了進行大規模電場數據應用的可行性,同時也說明了所構建的數據訪問平臺是高效的,基于ES和HBase的大數據存儲方法是可行的。

3.2 根據衛星軌道號繪制波形圖和功率譜圖

以軌道號13225為例。將軌道號13225和升降軌標識1作為查詢條件,檢索13225軌道夜側半軌電場波形數據和功率譜數據,約17 s即可繪制出如圖6所示的半軌電場波形圖,約23 s即可繪制出如圖7所示的功率譜圖。由此可知,存儲方法不僅具有在線數據分析功能,還大大提高了數據訪問效率,是文獻[3]關系型存儲方法的3倍以上。

圖6 13225_1電場波形圖Fig.6 13225_1 electric field waveform

圖7 13225_1電場功率譜圖Fig.7 13225_1 electric field power spectrum

圖6展示的是13225軌道夜側半軌電場波形三分量數據隨著時間、經緯度的變化。圖7展示的是13225軌道夜側半軌中不同經緯度、不同頻率下的電場功率譜三分量數據情況。

3.3 根據時間段和經緯度繪制衛星軌道分布圖

選擇2020年6月23日墨西哥瓦哈卡海岸近海7.8級地震(地理經度為-96.75°,地理緯度為16.15°)的震前15 d電場ULF頻段3分量波形數據進行研究。由于ZH-1的所有儀器設計為在緯度±65°的范圍內開機工作,重返周期為5 d[3],因此將15 d研究數據劃分為3個周期。同時考慮到衛星監測電場數據在白天易受到太陽和人類活動等因素干擾[13],將對ULF數據的搜索條件設置如下。

(1)將該震中區域地理經度加減15°,得到-111.75°～-81.75°區域范圍。

(2)地理緯度-65°～65°區域范圍。

(3)震前第三個周期即2020年6月19—23日。

(4)選擇夜側升軌。

在存儲中查詢該條件下的波形X分量數據,約120 s即可繪制出該條件下波形軌道數據的空間分布圖,該效率是文獻[3]存儲方法的3倍,如圖8所示。

圖8 震中附近X分量波形軌道數據空間分布圖Fig.8 Spatial distribution of X component waveform orbit data near the epicenter

圖8中顯示了2020年6月23日墨西哥瓦哈卡海岸近海7.8級地震震前5 d所有經過其震中附近矩形區域內衛星軌道波形數據空間分布情況。

4 結論

通過分析當前ZH-1衛星數據的現有存儲方案在擴展性、存讀取效率等方面的不足以及科研工作的需求,充分結合大數據存儲技術在海量數據高效存儲與讀取等方面的優勢,提出了基于ES+HBase的衛星大數據存儲方案。通過搭建基于所研究方案的大數據存儲實驗平臺,進行對比實驗和應用分析,得到以下結論。

(1)通過在ElasticSearch中建立索引字段的方法,基于ES+HBase的衛星大數據存儲方案繼承了HBase 本身RowKey查詢的高效性,實現了對海量衛星數據的高效查詢訪問;增強了HBase的多條件組合查詢的能力,滿足了科研人員對衛星數據的多條件組合查詢需求,為后續針對海量衛星數據進行的一系列科學研究工作提供高效的技術支撐。另外,該存儲方案具有橫向擴展性、高可用性和高并發性等特點,不僅解決了傳統關系型數據庫存儲方案的一系列瓶頸問題,還可以通過HBase的預分區、數據壓縮等高級功能進一步提高該方案的性能。

(2)實驗結果和實際應用效果分析表明,面對不斷增加的數據存儲需求時,基于ES+HBase的衛星大數據存儲方案的高效查詢訪問的優勢越來越明顯,查詢速度可以比關系型數據庫方案高出幾倍、幾十倍;同時該方案實現了對衛星空間電場ULF頻段數據的多條件組合的快速查詢。

由于涉及的實驗可能會由于環境配置比較低、數據量不足夠大等原因沒能更好地體現基于ES+HBase存儲方案的優勢,因此后續將會在該方案的基礎上,通過提高服務器配置、調優ES+HBase的性能參數等,對10 TB及以上的數據量存儲進行更深層次的實驗和實際應用分析,進一步證明基于ES+HBase大數據存儲方案在ZH-1衛星數據服務中的適用性。