熱力管道應(yīng)力分布式計算系統(tǒng)研究

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

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

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

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

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

1．1 實驗環(huán)境

此體系涉及多種軟件的協(xié)作運用，需要選取合適的版本以保證服務(wù)于相同的Java-jdk文件。具體實驗環(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提供的分布式儲存平臺，在此體系中的作用是進行資源管理，用于集群共享計算代碼、日志文件、JAR程序包等文件。HDFS平臺適合于文件儲存，但對于單條數(shù)據(jù)的查詢效率低下，難以勝任高度自定義化的數(shù)據(jù)分析查詢。非關(guān)系型數(shù)據(jù)庫MongoDB滿足分布式儲存，同時具備文檔類數(shù)據(jù)的自由查詢能力,因采用MongoDB進行管道計算結(jié)果儲存。Hadoop本身具有MapReduce分布式計算能力，但Spark在內(nèi)存運用方面更為高效，Hadoop相較之在資源管理方面又更為完善，因此采用Spark on Yarn的模式，用Hadoop的Yarn模塊進行資源管理，調(diào)用Spark內(nèi)存使用規(guī)范進行任務(wù)計算。

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

圖2 MongoDB分片儲存

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

2 實驗方案

2．1 資源配置

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

表1 集群配置表

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

2．2 實驗方案

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

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

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

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

表2 實驗方案表

3 性能測試

3．1 測試 1

圖3 Container分布與運算時間圖

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

3．2 測試 2

圖4 輸入文件變化與運算時間圖

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

3．3 測試 3

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

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

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

3．4 測試結(jié)論

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

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

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

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

4 未來展望

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

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

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