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

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

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

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

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

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

引 言

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

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

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

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

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

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

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

表1 文件類型分布

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

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

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

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

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

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

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

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

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

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

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

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

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

2 存儲(chǔ)架構(gòu)設(shè)計(jì)

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

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

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

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

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

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

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

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

④ 高效存取需求，既能夠高效存儲(chǔ)與讀取數(shù)據(jù)條數(shù)達(dá)海量的結(jié)構(gòu)化數(shù)據(jù)，也能夠滿足條數(shù)不多的結(jié)構(gòu)化數(shù)據(jù)的高效存儲(chǔ)與讀取；

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

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

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

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

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

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

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

3.1 HDFS模型設(shè)計(jì)

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

圖6 HDFS模型設(shè)計(jì)

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

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

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

3.2 SeaweedFS模型設(shè)計(jì)

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

圖8 SeaweedFS模型設(shè)計(jì)

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

3.3 TDengine模型設(shè)計(jì)

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

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

3.4 HBase模型設(shè)計(jì)

3.4.1 列族模型設(shè)計(jì)

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

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

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

3.4.2 行鍵模型設(shè)計(jì)

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

圖11 HBase表名設(shè)計(jì)

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

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

3.4.3 Region模型設(shè)計(jì)

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

3.5 ElasticSearch模型設(shè)計(jì)

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

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

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

4.1 部署模式

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

表3 服務(wù)器配置

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

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

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

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

表4 HDFS部署模式

表5 SeaweedFS部署模式

表6 HBase部署模式

表7 TDengine部署模式

表8 ElasticSearch部署模式

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

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

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

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

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

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

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

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

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

5 結(jié)束語

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

[1] 楊露. 大數(shù)據(jù)平臺(tái)上的隱私保護(hù)及合規(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è)信息化平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)[D]. 西安: 西安理工大學(xué), 2021.

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

[7] 李薇. 基于云計(jì)算的大數(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]. 中國(guó)電子科學(xué)研究院學(xué)報(bào), 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ì)算模型[J]. 計(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é)報(bào), 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è)計(jì)與實(shí)現(xiàn)[D]. 南京: 南京大學(xué), 2018.

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

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

[15] 董雪, 高遠(yuǎn), 敖炳. 基于TDengine的智能電網(wǎng)監(jiān)控系統(tǒng)數(shù)據(jù)存儲(chǔ)方法研究[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ù)分析平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)[D]. 北京: 北京交通大學(xué), 2019.

[17] 李亞臣. 基于ClickHouse的用戶事件分析系統(tǒng)的設(shè)計(jì)與實(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: 運(yùn)載火箭測(cè)試數(shù)據(jù)自動(dòng)判讀語言[J]. 遙測(cè)遙控, 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] 何巍, 胡久輝, 趙婷, 等. 基于模型的運(yùn)載火箭總體設(shè)計(jì)方法初探[J]. 導(dǎo)彈與航天運(yùn)載技術(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

連彥澤, 李鵬程, 趙雷, 等.運(yùn)載火箭試驗(yàn)大數(shù)據(jù)存儲(chǔ)架構(gòu)設(shè)計(jì)與應(yīng)用[J]. 遙測(cè)遙控, 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年生，碩士，高級(jí)工程師，主要研究方向?yàn)楹教鞌?shù)據(jù)分析與軟件工程。

李鵬程 1997年生，碩士，助理工程師，主要研究方向?yàn)檫\(yùn)載火箭計(jì)算機(jī)輔助與設(shè)計(jì)。

趙 雷 1982年生，碩士，研究員，主要研究方向?yàn)檫\(yùn)載火箭軟件系統(tǒng)。

司洪泉 1982年生，碩士，工程師，主要研究方向?yàn)楹教祛I(lǐng)域信息化。

陳旭東 1979年生，碩士，高級(jí)工程師，主要研究方向?yàn)楹教祛I(lǐng)域信息化。

(本文編輯：傅 杰)