韓金池，郭建東，文歡，常雪姣，王欽松

（電子科技大學(xué)信息與軟件工程學(xué)院，四川 成都 611731）

熱力管道在工業(yè)生產(chǎn)和熱量傳輸中有著廣泛的使用，它通常用于運(yùn)送高溫高壓的蒸汽或流體介質(zhì)。由于管道在使用過(guò)程中會(huì)承受較大的膨脹力與沖擊力，一旦設(shè)計(jì)不當(dāng)，會(huì)產(chǎn)生管道破損，引發(fā)蒸汽，熱液體泄漏，甚至危及工廠人員的生命安全，因此，管道必須滿足應(yīng)力計(jì)算規(guī)范后才能投入使用。設(shè)計(jì)過(guò)程中，工程師需要憑借自身的經(jīng)驗(yàn)和復(fù)雜的數(shù)學(xué)計(jì)算，考慮管道材質(zhì)、不同工況下管道的受力分配、管道支吊架類型的設(shè)置等難題。管道節(jié)點(diǎn)的支吊架類型多樣，需要工程師長(zhǎng)年的設(shè)計(jì)經(jīng)驗(yàn)和復(fù)雜的矩陣計(jì)算才能得到最終的受力情況，成為了管道設(shè)計(jì)的難點(diǎn)之一。

Spark on YARN是結(jié)合了Spark與Hadoop的分布式架構(gòu)，它通過(guò)Hadoop的分布式文件平臺(tái)進(jìn)行資源管理，調(diào)度Spark進(jìn)行高效分布式計(jì)算。開(kāi)發(fā)人員可以在此架構(gòu)下編寫分布式計(jì)算程序，分配集群資源，提高運(yùn)算效率。MongoDB是可以分布式儲(chǔ)存的非關(guān)系數(shù)據(jù)庫(kù)，用于儲(chǔ)存文檔類型的非關(guān)系數(shù)據(jù)，并具有高擴(kuò)展性，支持動(dòng)態(tài)文檔的深度查詢。Spark官方提供了MongoDB的數(shù)據(jù)鏈接器，允許在分布式計(jì)算程序中向分布式數(shù)據(jù)庫(kù)中讀寫數(shù)據(jù)，為兩者的結(jié)合提供了可能，兩者都開(kāi)放了Python語(yǔ)言的API，這更提供了與TensorFlow等機(jī)器學(xué)習(xí)庫(kù)聯(lián)合運(yùn)用的條件。上述體系非常適合與構(gòu)建文檔類型數(shù)據(jù)的大數(shù)據(jù)平臺(tái)。

1 體系結(jié)構(gòu)

1．1 實(shí)驗(yàn)環(huán)境

此體系涉及多種軟件的協(xié)作運(yùn)用，需要選取合適的版本以保證服務(wù)于相同的Java-jdk文件。具體實(shí)驗(yàn)環(huán)境如下：

操作系統(tǒng)：Ubuntu-18.04

編程環(huán)境：jdk-9.1 python-3.5

應(yīng)用軟件：

Hadoop-2.7.7

Spark-2.1.1

MongoDB-4.0.1

1．2 體系結(jié)構(gòu)

圖 1中，HDFS是 Hadoop提供的分布式儲(chǔ)存平臺(tái)，在此體系中的作用是進(jìn)行資源管理，用于集群共享計(jì)算代碼、日志文件、JAR程序包等文件。HDFS平臺(tái)適合于文件儲(chǔ)存，但對(duì)于單條數(shù)據(jù)的查詢效率低下，難以勝任高度自定義化的數(shù)據(jù)分析查詢。非關(guān)系型數(shù)據(jù)庫(kù)MongoDB滿足分布式儲(chǔ)存，同時(shí)具備文檔類數(shù)據(jù)的自由查詢能力,因采用MongoDB進(jìn)行管道計(jì)算結(jié)果儲(chǔ)存。Hadoop本身具有MapReduce分布式計(jì)算能力，但Spark在內(nèi)存運(yùn)用方面更為高效，Hadoop相較之在資源管理方面又更為完善，因此采用Spark on Yarn的模式，用Hadoop的Yarn模塊進(jìn)行資源管理，調(diào)用Spark內(nèi)存使用規(guī)范進(jìn)行任務(wù)計(jì)算。

圖1 體系結(jié)構(gòu)圖

圖2 MongoDB分片儲(chǔ)存

以三臺(tái)機(jī)器為例，MongoDB分布式數(shù)據(jù)庫(kù)搭建如上。每臺(tái)機(jī)器有一個(gè)Mongos進(jìn)程作為數(shù)據(jù)讀寫入口，一個(gè)ConfigServer用于配置路由查找，保證各機(jī)器之間的地址聯(lián)系。同時(shí)每臺(tái)機(jī)器還復(fù)制了三分相同的數(shù)據(jù)分片，保證部分機(jī)器死機(jī)時(shí)，用戶依然能夠通過(guò)其他機(jī)器上的分片數(shù)據(jù)讀寫完整的數(shù)據(jù)，使得分布式集群可靠性更強(qiáng)。

2 實(shí)驗(yàn)方案

2．1 資源配置

采用5臺(tái)配置有Ubantu18.04操作系統(tǒng)的電腦進(jìn)行集群搭建，5臺(tái)電腦配置如下。

表1 集群配置表

機(jī)器的內(nèi)存和CPU核數(shù)是影響計(jì)算速率的主要條件。由于Hadoop的MapReduce運(yùn)算流程是一次性在集群中完成任務(wù)分發(fā)，任務(wù)完成的總時(shí)間受各種因素影響，需要在Hadoop與Spark中進(jìn)行相應(yīng)配置，保證任務(wù)的分發(fā)數(shù)量能充分利用機(jī)器資源，才可以達(dá)到最短的任務(wù)完成時(shí)間。

2．2 實(shí)驗(yàn)方案

Container是Hadoop里面的資源分配模塊，在任務(wù)進(jìn)行中，子機(jī)上Container的數(shù)量對(duì)應(yīng)投入于MapReduce的機(jī)器資源，其數(shù)量可在Spark on YARN的工作模式下由Spark的Num-Executors配置決定。

MapReduce分片數(shù)指分布式任務(wù)的子任務(wù)數(shù)量，可在程序代碼中進(jìn)行設(shè)置。

可變節(jié)點(diǎn)數(shù)是指管道配置文件中可選取多種型號(hào)支架的管道節(jié)點(diǎn)，此處設(shè)置每個(gè)變換節(jié)點(diǎn)都有2種型號(hào)支架可選擇，假設(shè)可變節(jié)點(diǎn)數(shù)為n，通過(guò)窮舉所有變換，共需計(jì)算2^n個(gè)文件。

以上三個(gè)都與任務(wù)完成時(shí)間密切相關(guān)，通過(guò)控制變量，可以根據(jù)以下實(shí)驗(yàn)方案表研究各個(gè)數(shù)據(jù)對(duì)運(yùn)算速率的影響特性。

表2 實(shí)驗(yàn)方案表

3 性能測(cè)試

3．1 測(cè)試 1

圖3 Container分布與運(yùn)算時(shí)間圖

參考圖3，在輸入文件相同的情況下，Container總數(shù)越多，運(yùn)算時(shí)間越快。圖中灰色條形柱代表Master，Host1-4分別有1,2,2,1,1個(gè)Container時(shí)候的運(yùn)算時(shí)間，除了MapReduce過(guò)程中Reduce部分使用的1個(gè)Container，Map運(yùn)算的Container共有6個(gè)，相較藍(lán)色條形柱（共13個(gè)Map運(yùn)算Container）速度要慢很多。實(shí)驗(yàn)驗(yàn)證了運(yùn)算時(shí)間與參與運(yùn)算的資源數(shù)量的反比關(guān)系。

3．2 測(cè)試 2

圖4 輸入文件變化與運(yùn)算時(shí)間圖

參考圖4，在Container分布相同的情況下，輸入文件的點(diǎn)數(shù)越多，運(yùn)算時(shí)間成指數(shù)級(jí)增加，符合運(yùn)算時(shí)間與變換文件的數(shù)量的對(duì)應(yīng)遞增關(guān)系。

3．3 測(cè)試 3

測(cè)試3在輸入文件為12節(jié)點(diǎn)（輸出文件為），各節(jié)點(diǎn)Container分布為1,2,2,1,1的情況下進(jìn)行。

圖5 Mp數(shù)量與運(yùn)算時(shí)間圖

參考圖5，在Mp數(shù)量低于Container總數(shù)的時(shí)候，增加Mp有助于提高速度，而在Mp數(shù)量高于Container時(shí)，增加Mp對(duì)運(yùn)算時(shí)間無(wú)正面影響?？赏茰y(cè)Mp分片數(shù)要契合Container資源數(shù)，才能最大化運(yùn)算效率。

3．4 測(cè)試結(jié)論

分布式計(jì)算的資源分配與機(jī)器性能的關(guān)系類似于排隊(duì)論的關(guān)系，如圖6。

在分配任務(wù)數(shù)固定的情況下，各電腦配置應(yīng)盡量相同，特別是內(nèi)存大小要與CPU性能匹配。由于任務(wù)一次性分發(fā)，在CPU性能好、內(nèi)存不足的情況下，高級(jí)CPU只計(jì)算了少量任務(wù)，浪費(fèi)了CPU資源；CPU性能差，但內(nèi)存充足的情況下，低性能CPU計(jì)算大量任務(wù)，會(huì)導(dǎo)致計(jì)算時(shí)間增大。

圖6 資源分配關(guān)系圖

同理，整個(gè)計(jì)算任務(wù)的完成時(shí)間也會(huì)因不同機(jī)器配置間的木桶效應(yīng)增長(zhǎng)，因此，各個(gè)電腦最好采取完全相同的內(nèi)存與CPU配置，以便大型集群的任務(wù)分配與管理。

4 未來(lái)展望

在工作流程方面，目前通過(guò)在節(jié)點(diǎn)變換中設(shè)置人為干預(yù)來(lái)減少需要計(jì)算的管道節(jié)點(diǎn)數(shù)量，減少系統(tǒng)的運(yùn)算總時(shí)間。未來(lái)可通過(guò)Python編程，引入機(jī)器學(xué)習(xí)來(lái)協(xié)助管道分析，實(shí)現(xiàn)對(duì)錯(cuò)誤設(shè)計(jì)方案的智能剔除。

在系統(tǒng)展示方面，目前主要以傳統(tǒng)的文本方式進(jìn)行管道設(shè)計(jì)與參數(shù)調(diào)整。未來(lái)可引入WebGL進(jìn)行網(wǎng)頁(yè)渲染，將管道設(shè)計(jì)文件投射為可視化的3D模型，用戶可以直接操作3D模型來(lái)管道設(shè)計(jì)文件進(jìn)行參數(shù)調(diào)整，實(shí)現(xiàn)傳統(tǒng)管道設(shè)計(jì)的3D可視化。

在集群架構(gòu)方面，目前用到的軟件相互孤立，需要對(duì)各個(gè)軟件進(jìn)行單獨(dú)安裝，造成了集群部署耗時(shí)耗力。未來(lái)可以通過(guò)Docker容器對(duì)平臺(tái)軟件進(jìn)行包裝，提高軟件的移植性，增強(qiáng)集群的伸縮性，方便集群新機(jī)的軟件部署。