運載火箭試驗大數(shù)據(jù)存儲架構(gòu)設(shè)計與應(yīng)用

連彥澤，李鵬程，趙 雷，司洪泉，陳旭東

運載火箭試驗大數(shù)據(jù)存儲架構(gòu)設(shè)計與應(yīng)用

連彥澤1，李鵬程2，趙 雷2，司洪泉1，陳旭東1

（1 中國運載火箭技術(shù)研究院 北京 100076 2 北京宇航系統(tǒng)工程研究所 北京 100076）

運載火箭試驗產(chǎn)生的數(shù)據(jù)量呈現(xiàn)出爆炸式增長，主要特點表現(xiàn)為數(shù)據(jù)種類多、數(shù)據(jù)密度大、數(shù)據(jù)持續(xù)時間長。傳統(tǒng)單機部署和基于關(guān)系型數(shù)據(jù)庫與文件的系統(tǒng)架構(gòu)的不足逐漸顯現(xiàn)，不同種類的數(shù)據(jù)不做區(qū)分存儲，存儲和查詢效率低，數(shù)據(jù)無備份，存在單點故障導(dǎo)致數(shù)據(jù)丟失的問題，無法滿足海量數(shù)據(jù)場景下的存儲計算業(yè)務(wù)需求。利用大數(shù)據(jù)技術(shù)思想，針對運載火箭存儲計算業(yè)務(wù)的需求，設(shè)計出一套運載火箭試驗大數(shù)據(jù)存儲架構(gòu)，并給出了各存儲組件的存儲模型設(shè)計方法。通過實際工程應(yīng)用表明：該架構(gòu)具備良好的可靠性、可擴展性和可維護性，是一種切實可行的大數(shù)據(jù)存儲架構(gòu)設(shè)計，能夠滿足運載火箭試驗數(shù)據(jù)的存儲計算等業(yè)務(wù)需求。

運載火箭；大數(shù)據(jù)；存儲架構(gòu)

引 言

隨著信息技術(shù)和網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，在數(shù)字化世界中產(chǎn)生的數(shù)據(jù)呈現(xiàn)爆炸式增長，各科技類企業(yè)需要存儲、處理及提供在線服務(wù)的數(shù)據(jù)越來越大。其中，谷歌公司的搜索引擎為了提供更好的服務(wù)，需要抓取并存儲全世界網(wǎng)站的所有網(wǎng)頁數(shù)據(jù)[1]，同時需要按照網(wǎng)頁之間的反向鏈接關(guān)系進行全量計算以確定網(wǎng)頁的排序結(jié)果，并提供能夠?qū)崟r響應(yīng)的在線搜索服務(wù)。為了解決存儲、計算和在線服務(wù)這三個核心需求，谷歌公司在2003年、2004年及2006年，分別發(fā)表了GFS[2]、MapReduce[3]和Bigtable[4]三篇論文。GFS解決了數(shù)據(jù)存儲的問題。作為支持上千個節(jié)點的分布式文件系統(tǒng)，可以很容易地實現(xiàn)所有需要的數(shù)據(jù)的存儲。MapReduce通過Map和Reduce函數(shù)對海量數(shù)據(jù)計算進行了一次抽象，使得不需要深入掌握分布式系統(tǒng)的開發(fā)與實現(xiàn)即可進行海量數(shù)據(jù)的并行處理。Bigtable使用GFS作為底層存儲，通過集群的分片調(diào)度算法解決了大集群、機械硬盤下的高性能隨機讀寫問題。正是受這三篇論文的影響，產(chǎn)生了開源的HDFS、MapReduce和HBase的大數(shù)據(jù)組件或框架[5]，使得大數(shù)據(jù)技術(shù)真正走向了普及。通過這些通用的技術(shù)框架和解決方案，越來越多的企業(yè)和工程師使用大數(shù)據(jù)技術(shù)有效地解決了各自面臨的問題，大數(shù)據(jù)技術(shù)也得到了快速的演進和發(fā)展。

大數(shù)據(jù)技術(shù)的核心理念主要有三點：大數(shù)據(jù)技術(shù)是一種能夠伸縮到一千臺服務(wù)器以上的分布式數(shù)據(jù)處理集群的技術(shù)[6]，正是因為這種集群的伸縮性，才能夠?qū)崿F(xiàn)PB級別的數(shù)據(jù)處理和應(yīng)用；集群是采用廉價的PC架構(gòu)搭建的，正是因為這種低廉的硬件成本[7]，才使得大數(shù)據(jù)技術(shù)能夠讓越來越多的人使用；把整個集群抽象為一臺計算機，通過各類大數(shù)據(jù)計算存儲框架的封裝和抽象，使得開發(fā)者像在一臺計算上開發(fā)自己的代碼，不用考慮分布式系統(tǒng)的可用性、數(shù)據(jù)一致性等問題[8]。

正是這三個核心技術(shù)理念，降低了大數(shù)據(jù)技術(shù)使用的門檻和難度，使得整個大數(shù)據(jù)技術(shù)生態(tài)繁榮發(fā)展[9]。在分布式計算領(lǐng)域，為了不斷優(yōu)化MapReduce的性能，產(chǎn)生了Spark[10]等分布式計算框架[11]。在分布式存儲領(lǐng)域，F(xiàn)acebook公司為了解決海量照片小文件存儲的問題，研發(fā)了Haystack分布式文件存儲系統(tǒng)，并發(fā)表了Finding a needle in Haystack[12]的論文。SeaweedFS正是基于論文的開源實現(xiàn)[13]，被阿里等多家公司采用。為了解決海量監(jiān)控數(shù)據(jù)及物聯(lián)網(wǎng)等時序類數(shù)據(jù)的存儲，產(chǎn)生了TiDB[14]、TDengine[15]等優(yōu)秀的開源時序數(shù)據(jù)庫產(chǎn)品，同時還產(chǎn)生了ClickHouse[16]等OLAP類的數(shù)據(jù)庫產(chǎn)品[17]。

上述的各類計算、存儲、分析類產(chǎn)品，均是基于大數(shù)據(jù)的核心技術(shù)理念開發(fā)出的分布式系統(tǒng)，得以承載越來越大的數(shù)據(jù)量和計算量。

在航天領(lǐng)域，數(shù)據(jù)是運載火箭試驗重要的分析對象和組成部分，數(shù)據(jù)的完整性與正確性是評估運載火箭“是否可用、是否好用”的重要依據(jù)與指標，也是使用人員進行判斷與決策的重要基礎(chǔ)。傳統(tǒng)存儲方式是基于關(guān)系型數(shù)據(jù)庫和文件進行存儲，將結(jié)構(gòu)化試驗數(shù)據(jù)，如總裝測試數(shù)據(jù)、模飛試驗數(shù)據(jù)、結(jié)構(gòu)強度試驗數(shù)據(jù)和環(huán)境試驗數(shù)據(jù)等存儲于關(guān)系型數(shù)據(jù)庫中，而非結(jié)構(gòu)化試驗數(shù)據(jù)或文件存儲于文件系統(tǒng)中。隨著運載火箭的不斷發(fā)展，運載火箭試驗產(chǎn)生的數(shù)據(jù)量呈現(xiàn)出爆炸式增長，傳統(tǒng)單機部署和基于關(guān)系型數(shù)據(jù)庫與文件的系統(tǒng)架構(gòu)已無法滿足海量數(shù)據(jù)存儲計算的業(yè)務(wù)需求。如何將種類繁多、數(shù)量越來越多的運載火箭試驗大數(shù)據(jù)通過一套大數(shù)據(jù)存儲架構(gòu)實現(xiàn)高效的存儲計算，同時具備良好的可靠性、可擴展性和可維護性，是運載火箭試驗數(shù)據(jù)存儲和應(yīng)用需要解決的核心問題。本文借鑒大數(shù)據(jù)的核心技術(shù)理念，整合應(yīng)用開源先進的大數(shù)據(jù)存儲、計算組件，設(shè)計數(shù)據(jù)模型，構(gòu)建一套滿足海量數(shù)據(jù)場景下存儲計算業(yè)務(wù)需求的運載火箭試驗大數(shù)據(jù)存儲架構(gòu)。

1 試驗數(shù)據(jù)分析

運載火箭的研制需要經(jīng)過設(shè)計、制造、試驗等多個階段后，才能形成最終產(chǎn)品并交付使用，其中試驗階段是整個研制過程的重要組成部分，試驗階段中產(chǎn)生的數(shù)據(jù)是火箭功能性能分析和評定最主要的依據(jù)[18]。運載火箭試驗數(shù)據(jù)是運載火箭研制過程中產(chǎn)生的重要數(shù)據(jù)資產(chǎn)，既包括文本、圖片、音頻、圖像、日志等非結(jié)構(gòu)化數(shù)據(jù)，也包括試驗數(shù)值結(jié)果等時序類的結(jié)構(gòu)化數(shù)據(jù)，試驗數(shù)據(jù)涉及的火箭型號多、試驗多，數(shù)據(jù)周期跨度大、數(shù)據(jù)價值高、數(shù)據(jù)量大。本文以若干個運載火箭型號、2.6萬余次試驗、328萬余個數(shù)據(jù)文件為研究對象，對數(shù)據(jù)文件的文件類型進行統(tǒng)計分析，詳見表1。

表1 文件類型分布

根據(jù)文件類型分布分析，可結(jié)構(gòu)化的txt、dat、bin文件類型的文件數(shù)量占比達到了總文件數(shù)量的65%，在架構(gòu)設(shè)計中需著重考慮、專門設(shè)計結(jié)構(gòu)化數(shù)據(jù)的存儲。對328萬余個運載火箭試驗數(shù)據(jù)文件的文件大小、數(shù)量分布情況進行統(tǒng)計，如圖1所示，橫坐標為文件大小，統(tǒng)計單位為1 MB，縱坐標為文件數(shù)量以10為底對數(shù)值。從分布圖可知，文件數(shù)量統(tǒng)計分布呈現(xiàn)隨文件大小增加而整體下降趨勢，且1 MB以下的文件數(shù)量呈現(xiàn)尖峰特點，在整體下降趨勢中存在個別峰值是由于試驗數(shù)據(jù)文件在生成或存儲時，試驗數(shù)據(jù)量相近或按固定大小的文件存儲導(dǎo)致的。

對運載火箭試驗數(shù)據(jù)文件大小的數(shù)據(jù)量分布情況進行統(tǒng)計，橫坐標為文件大小，縱坐標為數(shù)據(jù)量。從圖2可知，數(shù)據(jù)量集中在較大的文件范圍內(nèi)，1 785 MB左右的尖峰是由于該大小附近的文件不僅單文件數(shù)據(jù)量較大，由圖1可知其文件數(shù)量也較多，因此由單文件平均數(shù)據(jù)量乘以文件數(shù)量得出的數(shù)據(jù)量最高?？偨Y(jié)可知：運載火箭試驗數(shù)據(jù)的小文件占用存儲空間不大，但數(shù)量極多；大文件占用存儲空間極大，但數(shù)量較少。

圖1 文件數(shù)量隨文件大小的分布

圖2 數(shù)據(jù)量隨文件大小的分布

從運載火箭試驗數(shù)據(jù)中區(qū)分結(jié)構(gòu)化文件和非結(jié)構(gòu)化文件，分別繪制文件數(shù)量隨文件大小的分布、數(shù)據(jù)量隨文件大小的分布如圖3和圖4所示，橫坐標為文件大小，縱坐標為文件數(shù)量以10為底對數(shù)值或數(shù)據(jù)量，統(tǒng)計分布與不區(qū)分結(jié)構(gòu)化和非結(jié)構(gòu)化文件時的統(tǒng)計分布一致，小文件占用少但數(shù)量多、大文件占用多但數(shù)量少的結(jié)論依舊成立。

根據(jù)以上分析總結(jié)運載火箭試驗數(shù)據(jù)并結(jié)合實際工作情況，得出試驗數(shù)據(jù)特點如下：

① 試驗數(shù)據(jù)的來源廣泛，源于各型號、各類試驗、各階段流程；

② 試驗數(shù)據(jù)種類多樣，文件類型多，數(shù)據(jù)類型包括結(jié)構(gòu)化和非結(jié)構(gòu)化的多種數(shù)據(jù)類型；

③ 試驗數(shù)據(jù)量大，傳統(tǒng)單機或基于關(guān)系型數(shù)據(jù)庫、文件難以滿足數(shù)據(jù)存儲和查詢分析的需求；

圖3 結(jié)構(gòu)化（左）和非結(jié)構(gòu)化（右）文件的文件數(shù)量隨文件大小的分布

圖4 結(jié)構(gòu)化（左）和非結(jié)構(gòu)化（右）文件的數(shù)據(jù)量隨文件大小的分布

④ 試驗數(shù)據(jù)文件分布不均衡，結(jié)構(gòu)化數(shù)據(jù)多，非結(jié)構(gòu)化數(shù)據(jù)相對較少，小文件占用存儲空間少但文件數(shù)量巨大，大文件占用存儲空間大但文件數(shù)量極少；

⑤ 試驗數(shù)值結(jié)果等結(jié)構(gòu)化數(shù)據(jù)的數(shù)據(jù)量差異較大，數(shù)據(jù)采樣頻率不一，有的試驗有幾萬或者十幾萬條數(shù)據(jù)，有的試驗數(shù)據(jù)條數(shù)上億甚至十幾億，數(shù)據(jù)采樣頻率從50 Hz～500 Hz不等，涉及參數(shù)幾千個甚至上萬個，單試驗存儲的數(shù)據(jù)量最大約30 TB，單參數(shù)下存儲約15億條數(shù)據(jù)。

2 存儲架構(gòu)設(shè)計

目前在運載火箭領(lǐng)域，根據(jù)型號特點和數(shù)據(jù)特點的不同，開發(fā)了相應(yīng)的試驗數(shù)據(jù)系統(tǒng)，具備了一定的數(shù)據(jù)存儲和查詢分析的功能，但仍存在以下不足：

① 系統(tǒng)的通用性不足，試驗數(shù)據(jù)種類繁多，無統(tǒng)一的試驗數(shù)據(jù)系統(tǒng)以存儲所有類型的試驗數(shù)據(jù)，多為針對不同試驗類型的主要數(shù)據(jù)類型作了專門的設(shè)計；

② 系統(tǒng)穩(wěn)定性不夠，試驗數(shù)據(jù)系統(tǒng)多為單服務(wù)器部署，不支持集群部署，若節(jié)點宕機則可能導(dǎo)致正在錄入系統(tǒng)的數(shù)據(jù)丟失以及系統(tǒng)服務(wù)臨時癱瘓；

③ 系統(tǒng)的可擴展性不足，試驗數(shù)據(jù)系統(tǒng)的架構(gòu)設(shè)計多為基于關(guān)系型數(shù)據(jù)庫或基于文件，系統(tǒng)容量有限，不適用海量試驗數(shù)據(jù)的存儲需求[19]，系統(tǒng)難以通過增加硬件和存儲空間的方式進行擴展；

為解決運載火箭試驗數(shù)據(jù)類系統(tǒng)存在的上述問題，本文借鑒大數(shù)據(jù)技術(shù)的核心理念，通過整合大數(shù)據(jù)領(lǐng)域的數(shù)據(jù)存儲組件或產(chǎn)品，設(shè)計出一套滿足運載火箭試驗大數(shù)據(jù)存儲計算業(yè)務(wù)需求的存儲架構(gòu)。架構(gòu)設(shè)計要能滿足以下需求：

① 快速檢索需求，按照型號-試驗-文件的總體數(shù)據(jù)層次結(jié)構(gòu)進行存儲，能夠通過型號屬性、試驗屬性、文件屬性等條件對數(shù)據(jù)進行快速檢索；

② 結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)存儲需求，既能夠存儲結(jié)構(gòu)化數(shù)據(jù)，也能夠存儲非結(jié)構(gòu)化數(shù)據(jù)；

③ 小文件、大文件數(shù)據(jù)存儲需求，既能夠高效存儲與讀取數(shù)量極多的小文件，也能夠用于大文件的高效存取；

④ 高效存取需求，既能夠高效存儲與讀取數(shù)據(jù)條數(shù)達海量的結(jié)構(gòu)化數(shù)據(jù)，也能夠滿足條數(shù)不多的結(jié)構(gòu)化數(shù)據(jù)的高效存儲與讀?。?/p>

⑤ 穩(wěn)定性、可擴展性需求，存儲架構(gòu)應(yīng)具有良好的穩(wěn)定性與靈活的可擴展性，以分布式部署提供容錯、副本機制。

為滿足設(shè)計需求，首先需劃分文件大小的邊界，按照文件大小分別選用相應(yīng)的存儲產(chǎn)品。根據(jù)統(tǒng)計分析，運載火箭試驗大數(shù)據(jù)中以32 MB為劃分閾值時，閾值以下的小文件數(shù)量剛好占9成；用于存儲小文件的SeaweedFS雖然支持最大為128 MB的文件存儲，但在32 MB時讀寫速度最優(yōu)；HDFS存儲32 MB～64 MB的文件時雖然會有至少50%的塊空間浪費，但這個范圍的文件數(shù)量僅占1.8%，數(shù)據(jù)量僅占2%，實際影響并不大，因此選取32 MB為大小文件的劃分閾值。將數(shù)量占9成的32 MB以下的小文件存儲于適合小文件分布式存儲的SeaweedFS，將32 MB以上的大文件存儲于適合大文件存儲的HDFS，減輕HDFS約9成的存儲壓力和成本。

架構(gòu)設(shè)計如圖5所示。運載火箭試驗大數(shù)據(jù)經(jīng)數(shù)據(jù)采集和文件預(yù)處理后，按照單個文件大小區(qū)分存儲，將采集上傳的壓縮包和在共享存儲中解壓后的文件各存儲一份，超過32 MB的大文件存儲在HDFS中，小于32 MB的小文件存儲在SeaweedFS中；對于解壓后的結(jié)構(gòu)化文件，解析后按照試驗時長分別存儲，時間短的試驗數(shù)據(jù)存儲于分布式數(shù)據(jù)庫HBase中，時間長的試驗數(shù)據(jù)存儲于時序數(shù)據(jù)庫TDengine中；對于系統(tǒng)的狀態(tài)信息和運行過程中產(chǎn)生的數(shù)據(jù)或狀態(tài)信息等通過關(guān)系型數(shù)據(jù)庫如MySQL、Oracle、SQLserver等存儲，以上存儲產(chǎn)品中數(shù)據(jù)的存儲關(guān)系映射統(tǒng)一存儲于大數(shù)據(jù)全文檢索組件ElasticSearch中，以便快速檢索和定位查找。

圖5 架構(gòu)設(shè)計

架構(gòu)設(shè)計中涉及到的主要存儲組件選型決策如下：HDFS是Hadoop分布式文件系統(tǒng)，適合存儲海量的大文件，SeaweedFS是專門適用于海量小文件的分布式文件系統(tǒng)。針對運載火箭試驗數(shù)據(jù)里小文件眾多的實際情況，選用SeaweedFS來存儲小文件，減緩HDFS至少90%的文件存儲壓力；在解壓壓縮包過程中，采用共享對象存儲產(chǎn)品作為解壓空間，成本較低且容量動態(tài)伸縮靈活；對于結(jié)構(gòu)化的解析數(shù)據(jù)而言，短時試驗數(shù)據(jù)的表數(shù)量較少，約為2 000個，且數(shù)據(jù)量通常在千萬字節(jié)以內(nèi)，通過分布式數(shù)據(jù)庫HBase實現(xiàn)列式存儲和快捷查詢，且HBase較傳統(tǒng)關(guān)系型數(shù)據(jù)庫更優(yōu)。傳統(tǒng)關(guān)系型數(shù)據(jù)庫對于空值的存儲是占用空間的，而HBase采用列式存儲可以跳過空值存儲，節(jié)省了存儲資源，而試驗數(shù)據(jù)的表數(shù)量較多，單次試驗可達100張～300張參數(shù)表，百次試驗即可達上萬張參數(shù)表，且參數(shù)表下的數(shù)據(jù)量通常可達千萬字節(jié)以上。采用專用的時序數(shù)據(jù)庫TDengine存儲可以提供90%左右的高壓縮率和按時間段、時間點查詢的高效讀取服務(wù)，且能有效緩解HBase因表數(shù)量過多導(dǎo)致的性能不穩(wěn)定、存儲速度降低問題；對于數(shù)據(jù)量一般、并發(fā)較低的系統(tǒng)狀態(tài)信息和運行數(shù)據(jù)，采用關(guān)系型數(shù)據(jù)庫MySQL存儲，同時為提供快速、便捷的查詢服務(wù)，采用ElasticSearch負責(zé)數(shù)據(jù)、文件的元數(shù)據(jù)信息存儲，按單表1億條記錄橫向分表，提供實時全文檢索，如文件的存儲位置、表名、關(guān)系等。

3 數(shù)據(jù)模型設(shè)計

在運載火箭試驗大數(shù)據(jù)存儲架構(gòu)設(shè)計中，存儲是計算的前提，存儲的性能高低影響計算的性能優(yōu)劣，存儲的性能不僅受限于存儲的產(chǎn)品，也依賴于存儲數(shù)據(jù)在存儲產(chǎn)品上的建模。為滿足運載火箭試驗大數(shù)據(jù)的壓縮存儲和快速計算業(yè)務(wù)需求，對關(guān)鍵的存儲產(chǎn)品進行模型設(shè)計。

3.1 HDFS模型設(shè)計

HDFS是Google的GFS論文的實現(xiàn)，充分利用廉價的計算機節(jié)點提供高吞吐量的數(shù)據(jù)訪問，適合海量文件尤其是大文件的分布式存儲。HDFS模型設(shè)計的存儲定位分析如下：單個文件的元數(shù)據(jù)約200 B，按照NameNode節(jié)點內(nèi)存256 GB，則HDFS集群最多能容納13.7億個文件，而按照集群1 PB容量（目前容量為0.8 PB左右）、HDFS塊大小128 MB計算，HDFS集群最多能容納840萬個文件，取較小值容量為840萬個文件。而現(xiàn)階段運載火箭試驗數(shù)據(jù)已有220萬個文件，文件數(shù)量還在快速增長，若按冗余容量∶已用容量=5∶1計算，仍需擴容0.6 PB的集群容量，對應(yīng)存儲成本將額外花費60%。因此采用SeaweedFS和HDFS混合模式分布式存儲文件，兩者各司其職，SeaweedFS存儲小于32 MB的小文件，而HDFS專注存儲超過32 MB的大文件。HDFS的模型設(shè)計包括文件存儲目錄結(jié)構(gòu)，如圖6所示。

圖6 HDFS模型設(shè)計

文件存儲目錄結(jié)構(gòu)按照/datacenter/modelData創(chuàng)建數(shù)據(jù)存儲根目錄，在根目錄下按照“根目錄-文件”的層級關(guān)系存儲，被上傳的數(shù)據(jù)文件在壓縮包內(nèi)的相對路徑以鍵值對的映射關(guān)系存儲于ElasticSearch中。

其中，為方便查詢文件，實際存儲于HDFS的文件名格式為“文件名_文件ID_文件分片序號.文件類型后綴”，文件ID全局唯一，便于檢索特定文件；文件分片序號標識由于該文件對應(yīng)的原始試驗數(shù)據(jù)量過多而分裂的不同文件分片，具體如圖7所示。

圖7 HDFS文件名格式設(shè)計

3.2 SeaweedFS模型設(shè)計

SeaweedFS是Facebook的Haystack論文的實現(xiàn)，集群內(nèi)中央主服務(wù)器只管理文件卷，無需管理全部文件的元數(shù)據(jù)，而是由卷服務(wù)器管理，減輕了中央主服務(wù)器的并發(fā)壓力，適合海量小文件的分布式存儲，還能提供約12∶1的壓縮比，其模型設(shè)計主要包括文件存儲目錄結(jié)構(gòu)和卷配置，如圖8所示。

圖8 SeaweedFS模型設(shè)計

文件存儲目錄結(jié)構(gòu)按照/home/data/seaweedfs/seaweedfs_volume創(chuàng)建各個卷，在各卷下按照“volume-文件”的層級關(guān)系存儲，被上傳的數(shù)據(jù)文件在壓縮包內(nèi)的相對路徑以鍵值對的映射關(guān)系存儲于ElasticSearch中；根據(jù)服務(wù)器數(shù)量和性能，SeaweedFS在部署時采用分布式集群部署，每個節(jié)點創(chuàng)建3個服務(wù)實例，單節(jié)點平均創(chuàng)建10個卷。

3.3 TDengine模型設(shè)計

分布式時序數(shù)據(jù)庫TDengine的存儲結(jié)構(gòu)通常為：數(shù)據(jù)庫Database-超級表模板Stable-子表Table這三級?？紤]到跨庫查詢和存儲的不便，僅創(chuàng)建一個數(shù)據(jù)庫modeldata。由于運載火箭試驗數(shù)據(jù)的參數(shù)表的字段數(shù)量和字段類型各不相同，因此不創(chuàng)建超級表模板Stable，而是在數(shù)據(jù)庫下直接創(chuàng)建子表Table。子表名的格式為“ods_文件ID”，文件ID到原始結(jié)構(gòu)化文件的映射關(guān)系存儲于ElasticSearch中；給出子表的模型設(shè)計如圖9所示。ts為TDengine默認時間戳主鍵字段，最高支持納秒，滿足試驗數(shù)據(jù)的時間戳精度以毫秒為主的存儲需要，a0～a為參數(shù)表的所有字段名代號，字段名代號和原始字段的映射關(guān)系存儲于ElasticSearch中，通過字段名代號映射建表，不僅保障了數(shù)據(jù)安全和保密，而且適應(yīng)存儲格式不一的結(jié)構(gòu)化參數(shù)表；根據(jù)服務(wù)器數(shù)量和性能，分布式時序數(shù)據(jù)庫TDengine按照集群分布式部署，配置至少2個服務(wù)器節(jié)點部署為Mnode角色，提供高可用的數(shù)據(jù)元數(shù)據(jù)管理服務(wù)，所有節(jié)點均部署有Vnode角色，提供分布式數(shù)據(jù)存儲計算服務(wù)。

圖9 TDengine子表模型設(shè)計

3.4 HBase模型設(shè)計

3.4.1 列族模型設(shè)計

HBase存儲產(chǎn)品通過列族劃分數(shù)據(jù)的存儲和組織管理，每個列族支持包含多列，可實現(xiàn)靈活的數(shù)據(jù)存取。但當(dāng)某列族存儲數(shù)據(jù)達到落盤閾值時會觸發(fā)所在表的所有列族同時落盤，引發(fā)大量不必要的IO開銷，因此列族數(shù)量不宜過多，實際配置為2個列族，減少不必要的I/O開銷，提高寫入效率。列族模型設(shè)計示意圖如圖10所示，col_alldata列族中的列是對col_data列族的信息匯總，其中col_all記錄了個參數(shù)值的集合，col_no記錄了表中數(shù)據(jù)記錄的行序。

圖10 HBase列族模型設(shè)計

查詢業(yè)務(wù)通常為按列查詢某參數(shù)和查詢?nèi)繀?shù)，對于面向列族的HBase數(shù)據(jù)庫而言，更適合于按列查詢單個參數(shù)，查詢某行鍵Rowkey的全部參數(shù)值需遍歷所有列族的所有列，查詢次效率較低，改為查詢col_all列后，1次查詢即可完成全部參數(shù)的查詢業(yè)務(wù)。

3.4.2 行鍵模型設(shè)計

HBase采用Key-Value的鍵值對存儲模型，行鍵Rowkey是鍵值對存儲模型的Key，表示唯一行，用于構(gòu)建表中數(shù)據(jù)記錄的索引，行鍵模型的設(shè)計影響查詢的效率和應(yīng)用的便捷性。根據(jù)數(shù)據(jù)關(guān)聯(lián)、遍歷查詢、特定試驗查詢、特定文件查詢、數(shù)據(jù)記錄行過濾查詢等業(yè)務(wù)需要，按照一個試驗一張表，給出HBase表名設(shè)計和HBase表的行鍵模型設(shè)計，如圖11所示。表名格式為“ods_modelData_型號ID_試驗ID_data”，在查找特定型號或特定試驗的表時，可方便地通過遍歷表名獲取。

圖11 HBase表名設(shè)計

Rowkey格式為“Region分區(qū)編號_試驗ID_文件ID_數(shù)據(jù)記錄所處序號”，試驗ID和文件ID是全局唯一的，在查詢特定試驗或文件時、查詢特定數(shù)據(jù)記錄行時，無需查詢表中數(shù)值，只需遍歷行鍵Rowkey即可定位；在查詢某文件對應(yīng)的全部數(shù)據(jù)記錄時，配置Startkey和Endkey分別為“:”和“#”，即可快捷匹配查詢。

圖12 HBase行鍵模型設(shè)計

3.4.3 Region模型設(shè)計

Region是HBase中分布式存儲和負載均衡的最小單元，不同Region分布在不同的RegionServer節(jié)點上，每個Region包含多個列族。關(guān)于Region的數(shù)量，官方建議每個RegionServer節(jié)點最多創(chuàng)建10 GB×100個Region，通常系統(tǒng)部署在5臺～10臺RegionServer。按官方建議最多創(chuàng)建500個～1 000個Region，因此需合理設(shè)計Region，使得Region數(shù)量不要超過此最大值，根據(jù)實際物理機器數(shù)量和性能，最大值可延伸到10 000個Region左右。運載火箭試驗大數(shù)據(jù)不同于互聯(lián)網(wǎng)大數(shù)據(jù)，數(shù)據(jù)具有不穩(wěn)定性，數(shù)據(jù)量不定且差異很大，因此在Region模型設(shè)計時，按照一個試驗一張表，一張表兩個列族，不進行Region預(yù)分區(qū)，而是采用默認的分區(qū)機制，即一張表默認存于一個Region中，若該表數(shù)據(jù)量達到Region最大容量閾值，則由HBase自動分區(qū)為兩個或更多Region，以避免不必要的存儲占用和Region數(shù)量過多導(dǎo)致的HBase性能降低。相比傳統(tǒng)互聯(lián)網(wǎng)大數(shù)據(jù)按照表行號取余Region總數(shù)進行預(yù)分區(qū)的方式，Region數(shù)量減少了(Region總數(shù)－1)個，對于個試驗，共減少×(Region總數(shù)－1)個Region數(shù)量，明顯緩解HBase的存儲壓力。

3.5 ElasticSearch模型設(shè)計

ElasticSearch模型主要設(shè)計了四種映射關(guān)系，分別為ods_modeldata_dat、ods_modeldata_subdat、ods_modeldata_subdat_trial、ods_modeldata_meta，存儲的映射關(guān)系如下所示。

表2 ElasticSearch映射關(guān)系明細

4 應(yīng)用效果分析

4.1 部署模式

根據(jù)上述存儲架構(gòu)設(shè)計和模型設(shè)計，將系統(tǒng)部署于實際服務(wù)器集群中，服務(wù)器配置見表3，按照服務(wù)器角色、內(nèi)存、硬盤的配置差異，區(qū)分為3組，分別包含3個、21個、3個服務(wù)器節(jié)點。

表3 服務(wù)器配置

對系統(tǒng)架構(gòu)中涉及的存儲產(chǎn)品HDFS、SeaweedFS、HBase、TDengine、ElasticSearch的具體部署模式展開見表4～表8。

4.2 應(yīng)用效果分析

在以上軟硬件部署模式下，對幾種涉及到的存儲產(chǎn)品的應(yīng)用效果進行實測，得出以下結(jié)果。

HDFS和SeaweedFS存儲試驗數(shù)據(jù)的統(tǒng)計分布見表9，HDFS存儲的文件數(shù)量占比僅為8.4%，數(shù)據(jù)量占比為60.7%，與上述運載火箭試驗大數(shù)據(jù)特點分析的結(jié)果一致，即大文件數(shù)據(jù)量高但文件數(shù)量少，小文件的文件數(shù)量多但數(shù)據(jù)量少；同時以SeaweedFS集群的某存儲節(jié)點為例，存儲原始數(shù)據(jù)量為438.4 GB，實際占用86.2 GB，壓縮率為80.3%。隨著運載火箭試驗數(shù)據(jù)量的持續(xù)增長，小文件的空間占用需求增加，SeaweedFS能大大緩解存儲空間有限的問題。通過表9分析可知：運載火箭試驗大數(shù)據(jù)存儲架構(gòu)設(shè)計能夠有效解決由于文件數(shù)量過多導(dǎo)致Hadoop的NameNode存儲瓶頸的問題，又能解決SeaweedFS無法高效存儲大文件的問題，充分發(fā)揮兩個存儲組件的各自優(yōu)勢。

表4 HDFS部署模式

表5 SeaweedFS部署模式

表6 HBase部署模式

表7 TDengine部署模式

表8 ElasticSearch部署模式

表9 HDFS和SeaweedFS存儲統(tǒng)計分布

HBase的單表占用存儲空間的數(shù)量統(tǒng)計分布柱狀圖如圖13所示，橫坐標為表的存儲空間占用量，縱坐標為占用量對應(yīng)的表個數(shù)以10為底的對數(shù)值，可見單表占用的存儲空間分布較為均衡。根據(jù)統(tǒng)計，單表最大占用存儲空間610 GB，可見HBase支持大數(shù)據(jù)量單表和短時試驗數(shù)據(jù)表的存儲。

圖13 表數(shù)量隨表大小的分布

TDengine和HBase存儲試驗數(shù)據(jù)量的分布情況為HBase存儲數(shù)據(jù)量占比96.42%，TDengine存儲數(shù)據(jù)數(shù)據(jù)量占比3.58%，可見短時試驗數(shù)據(jù)占比較長時試驗數(shù)據(jù)更多，短期試驗的數(shù)據(jù)量約為長時試驗數(shù)據(jù)的10.3倍，TDengine解決了長時試驗數(shù)據(jù)的存儲和按時間查詢的問題，同時提供90%的壓縮率，極大緩解了服務(wù)器的存儲壓力。

綜上分析，本文貼合運載火箭試驗大數(shù)據(jù)的存儲計算業(yè)務(wù)的實際需求，梳理調(diào)研國內(nèi)外主流大數(shù)據(jù)組件和技術(shù)，針對不同的數(shù)據(jù)類型和不同的存儲產(chǎn)品特性，通過組合集成，給出了一種基于大數(shù)據(jù)技術(shù)的運載火箭試驗大數(shù)據(jù)存儲架構(gòu)。該系統(tǒng)架構(gòu)相較傳統(tǒng)基于關(guān)系型數(shù)據(jù)庫與文件的系統(tǒng)架構(gòu)具有以下效果：

①高性能。經(jīng)實際運行部署測試，該大數(shù)據(jù)存儲架構(gòu)滿足院級的運載火箭試驗大數(shù)據(jù)存儲計算業(yè)務(wù)需求。以院級運載火箭試驗大數(shù)據(jù)系統(tǒng)為例，數(shù)據(jù)采集服務(wù)器單節(jié)點能夠處理2 400個并發(fā)數(shù)據(jù)上傳請求，實際部署五節(jié)點支持每秒1.2萬次的并發(fā)請求；Seaweed- FS對小文件的存儲讀取性能優(yōu)，空間占用少，壓縮率高達80.3%；時序數(shù)據(jù)庫TDengine對試驗數(shù)據(jù)的存儲速度達每秒70萬點，存儲壓縮率達90%；HDFS、SeaweedFS、TDengine等存儲產(chǎn)品提供天然的數(shù)據(jù)同步和副本機制，為數(shù)據(jù)的可靠性提供了保證；傳統(tǒng)系統(tǒng)受限單機的磁盤讀寫、內(nèi)存緩存速度、CPU計算能力、CPU核數(shù)等資源瓶頸制約，且存在單點故障，可靠性低、性能一般。

②擴展性。ES單庫支持300億條數(shù)據(jù)的查詢，集群能夠支撐未來約十年的運載火箭試驗大數(shù)據(jù)的存儲需要，后續(xù)配合數(shù)據(jù)治理，在數(shù)據(jù)治理歸檔后數(shù)據(jù)文件的量也會縮減，減輕ES的負載量，提升系統(tǒng)未來的存儲查詢能力。此外，存儲架構(gòu)設(shè)計中HDFS、SeaweedFS、HBase、TDengine等存儲產(chǎn)品均支持集群部署，提供良好的存儲資源和計算資源彈性擴展；傳統(tǒng)系統(tǒng)僅支持單機部署，往往需要高性能的服務(wù)器作為系統(tǒng)運行環(huán)境，難以提供彈性資源擴展。

③穩(wěn)定性。該大數(shù)據(jù)存儲架構(gòu)具有良好的穩(wěn)定性，架構(gòu)設(shè)計中的各存儲組件以分布式部署提供容錯、副本機制，滿足三個副本的基本備份要求；克服了傳統(tǒng)試驗數(shù)據(jù)系統(tǒng)在單服務(wù)器部署模式下存在的單點故障問題，保障了系統(tǒng)服務(wù)的穩(wěn)定。

④通用性。滿足目前所有類型運載火箭試驗數(shù)據(jù)的統(tǒng)一存儲，并針對結(jié)構(gòu)化數(shù)據(jù)作了區(qū)分存儲；滿足目前工程應(yīng)用中對通過型號屬性、試驗屬性、文件屬性等條件過濾的常規(guī)檢索需求；滿足結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)存儲需求；滿足小文件、大文件數(shù)據(jù)的通用存儲需求。

5 結(jié)束語

遵循通用性、可靠性及可擴展性的原則，本文給出了基于大數(shù)據(jù)核心技術(shù)的運載火箭試驗大數(shù)據(jù)存儲架構(gòu)設(shè)計，首先從整體層面給出了系統(tǒng)的存儲架構(gòu)設(shè)計，接著分析了存儲架構(gòu)設(shè)計中涉及到的關(guān)鍵存儲產(chǎn)品選型和模型設(shè)計。相較傳統(tǒng)單機部署的基于關(guān)系型數(shù)據(jù)庫或文件的系統(tǒng)，本文提出的系統(tǒng)充分利用主流大數(shù)據(jù)技術(shù)和大數(shù)據(jù)組件，集成各組件的優(yōu)勢，針對存儲計算業(yè)務(wù)的實際需求，整合相應(yīng)的存儲組件，并給出了選型分析和存儲模型設(shè)計方法。通過實際工程應(yīng)用表明，該架構(gòu)是一種切實可行的大數(shù)據(jù)存儲架構(gòu)設(shè)計，能夠滿足運載火箭業(yè)務(wù)的需求。

[1] 楊露. 大數(shù)據(jù)平臺上的隱私保護及合規(guī)關(guān)鍵技術(shù)研究[D]. 成都: 四川大學(xué), 2021.

[2] GHEMAWAT S, GOBIOFF H, LEUNG S T. The Google file system[J]. Acm Sigops Operating Systems Review, 2003, 37(5): 29–43.

[3] DEAN J. MapReduce: Simplified data processing on large clusters[C]// Symposium on Operating System Design & Implementation, 2004.

[4] CHANG F, DEAN J, GHEMAWAT S, et al. Bigtable: A distributed storage system for structured data[C]//7th Symposium on Operating Systems Design and Implementation (OSDI '06), November 6-8, 2006, Seattle, WA, USA.

[5] 張維. 基于大數(shù)據(jù)技術(shù)的制造企業(yè)信息化平臺的設(shè)計與實現(xiàn)[D]. 西安: 西安理工大學(xué), 2021.

[6] 李梓楊. 大數(shù)據(jù)流式計算環(huán)境下的彈性資源調(diào)度策略研究[D]. 烏魯木齊: 新疆大學(xué), 2021.

[7] 李薇. 基于云計算的大數(shù)據(jù)處理技術(shù)探討[J]. 數(shù)字技術(shù)與應(yīng)用, 2017(8): 218–219.

LI Wei. Discussion on big data processing technology based on cloud computing[J]. Digital and Application, 2017(8): 218–219.

[8] 趙鵬, 朱祎蘭. 大數(shù)據(jù)技術(shù)綜述與發(fā)展展望[J]. 宇航總體技術(shù), 2022, 6(1): 55–60.

ZHAO Peng, ZHU Yilan. Overview and development prospect of big data technology[J]. Aerospace General Technology, 2022, 6(1): 55–60.

[9] 侯曉芳, 王歡, 李瑛. 一種基于HIVE和分布式集群的大量數(shù)據(jù)高效處理方法研究[J]. 中國電子科學(xué)研究院學(xué)報, 2018, 13(3): 315–320.

HOU Xiaofang, WANG Huan, LI Ying. Research on an efficient processing method of large amount of data based on HIVE and distributed cluster[J]. Journal of Chinese Academy of Electronic Sciences, 2018, 13(3): 315–320.

[10] 胡俊, 胡賢德, 程家興. 基于Spark的大數(shù)據(jù)混合計算模型[J]. 計算機系統(tǒng)應(yīng)用, 2015, 24(4): 214–218.

HU Jun, HU Xiande, CHENG Jiaxing. Big data hybrid computing model based on Spark[J]. Computer System Application, 2015, 24(4): 214–218.

[11] 周宇, 曹英楠, 王永超. 面向大數(shù)據(jù)的數(shù)據(jù)處理與分析算法綜述[J]. 南京航空航天大學(xué)學(xué)報, 2021, 53(5): 664–676.

ZHOU Yu, CAO Yingnan, WANG Yongchao. Overview of data processing and analysis algorithms for big data[J]. Journal of Nanjing University of Aeronautics and Astronautics, 2021, 53(5): 664–676.

[12] BEAVER D, KUMAR S, LI H C, et al. Finding a needle in haystack: Facebook's photo storage[C]//9th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2010, October 4-6, 2010, Vancouver, BC, Canada.

[13] 管登榮. 基于SeaweedFS的分布式文件管理系統(tǒng)的設(shè)計與實現(xiàn)[D]. 南京: 南京大學(xué), 2018.

[14] 陳辰. TiDB開源社區(qū)最佳實踐[J]. 軟件和集成電路, 2021(12): 56–57.

CHEN Chen. TiDB open source community best practices[J]. Software and Integrated Circuits, 2021(12): 56–57.

[15] 董雪, 高遠, 敖炳. 基于TDengine的智能電網(wǎng)監(jiān)控系統(tǒng)數(shù)據(jù)存儲方法研究[J]. 電氣應(yīng)用, 2021, 40(8): 68–74.

DONG Xue, GAO Yuan, AO Bing. Research on data storage method of smart grid monitoring system based on TDengine[J]. Electrical Applications, 2021, 40(8): 68–74.

[16] 張宇耀. 基于大數(shù)據(jù)的企業(yè)用戶數(shù)據(jù)分析平臺的設(shè)計與實現(xiàn)[D]. 北京: 北京交通大學(xué), 2019.

[17] 李亞臣. 基于ClickHouse的用戶事件分析系統(tǒng)的設(shè)計與實現(xiàn)[J]. 信息與電腦, 2021, 33(9): 87–90.

LI Yachen. Design and implementation of user event analysis system based on Clickhouse[J]. Information and Computer, 2021, 33(9): 87–90.

[18] 連彥澤, 何信華, 李鵬程, 等. IPL: 運載火箭測試數(shù)據(jù)自動判讀語言[J]. 遙測遙控, 2022, 43(2): 36–45.

LIAN Yanze, HE Xinhua, LI Pengcheng, et al. IPL: Automatic interpretation language for launch vehicle test data[J]. Journal of Telemetry, Tracking and Command, 2022, 43(2): 36–45.

[19] 何巍, 胡久輝, 趙婷, 等. 基于模型的運載火箭總體設(shè)計方法初探[J]. 導(dǎo)彈與航天運載技術(shù), 2021(1): 12–17, 32.

HE Wei, HU Jiuhui, ZHAO Ting, et al. Research on model based launch vehicle overall design[J]. Missile and Space Delivery Technology, 2021(1): 12–17, 32.

Architecture design and application of big data storage for launch vehicle test

LIAN Yanze1, LI Pengcheng2, ZHAO Lei2, SI Hongquan1, CHEN Xudong1

（1. China Academy of Launch Vehicle Technology, Beijing 100076,China;2. Beijing Institute of Astronautical Systems Engineering, Beijing 100076, China）

The amount of data produced by launch vehicle test shows an explosive growth, which is mainly characterized by complex data types, large data density and long time duration. The system architecture shortcomings of traditional stand-alone deployment based on relational database and file are gradually emerging. Different types of data stored together, low efficiency of writing and query, no backup of data, and single point of failure could not meet the needs of storage and computing business in the context of massive launch vehicle test data field. Using the idea of big data technology and aiming at the need of launch vehicle test data storage and computing, a set of big data storage architecture for massive launch vehicle test data is proposed, and the storage model design method of each storage component is designed. The practical engineering application effect shows that the architecture has good reliability, scalability and maintainability. It is a practical big data storage architecture, which could meet the launch vehicle test data business needs of storage and calculation.

Launch vehicle; Big data; Storage architecture

Website: ycyk.brit.com.cn Email: ycyk704@163.com

V557

A

CN11-1780(2022)06-0078-11

10.12347/j.ycyk.20220509002

連彥澤, 李鵬程, 趙雷, 等.運載火箭試驗大數(shù)據(jù)存儲架構(gòu)設(shè)計與應(yīng)用[J]. 遙測遙控, 2022, 43(6): 78–88.

10.12347/j.ycyk.20220509002

: LIAN Yanze, LI Pengcheng, ZHAO Lei, et al. Architecture design and application of big data storage for launch vehicle test[J]. Journal of Telemetry, Tracking and Command, 2022, 43(6): 78–88.

連彥澤（lianyz@email.cn）

2022-05-09

2022-06-02

連彥澤 1985年生，碩士，高級工程師，主要研究方向為航天數(shù)據(jù)分析與軟件工程。

李鵬程 1997年生，碩士，助理工程師，主要研究方向為運載火箭計算機輔助與設(shè)計。

趙 雷 1982年生，碩士，研究員，主要研究方向為運載火箭軟件系統(tǒng)。

司洪泉 1982年生，碩士，工程師，主要研究方向為航天領(lǐng)域信息化。

陳旭東 1979年生，碩士，高級工程師，主要研究方向為航天領(lǐng)域信息化。

(本文編輯：傅 杰)