一種中尺度數(shù)值預(yù)報(bào)模式數(shù)據(jù)并行傳輸應(yīng)用研究

（重慶市氣象科學(xué)研究所，重慶 401147）

0 引言

目前中尺度數(shù)值預(yù)報(bào)模式是局部區(qū)域天氣預(yù)報(bào)業(yè)務(wù)系統(tǒng)中重要的組成部分，為天氣預(yù)報(bào)業(yè)務(wù)提供技術(shù)支撐。重慶中尺度數(shù)值預(yù)報(bào)模式是以WRF（Weather Research and Forecasting Model）為核心模塊開(kāi)發(fā)的一種數(shù)值天氣預(yù)報(bào)模式，是重慶精細(xì)化數(shù)值天氣預(yù)報(bào)系統(tǒng)的重要組成部分，為重慶本地區(qū)域復(fù)雜天氣變化過(guò)程預(yù)測(cè)預(yù)報(bào)提供依據(jù)和參考。重慶中尺度數(shù)值預(yù)報(bào)模式的運(yùn)行平臺(tái)是SGI Altix uv 1000系列大型機(jī)，該模式一天運(yùn)行2次（0012 UTC），預(yù)報(bào)時(shí)效96 h，該模式輸出可用的業(yè)務(wù)數(shù)據(jù)是NetCDF格式的平面二維（2 Dimension）數(shù)據(jù)，大小13 GB左右/次，一天數(shù)據(jù)量約26 GB。根據(jù)業(yè)務(wù)和科研需求，輸出的平面二維數(shù)據(jù)需及時(shí)傳輸?shù)綌?shù)據(jù)管理服務(wù)器上處理及歸檔，該數(shù)據(jù)管理服務(wù)器運(yùn)行了多種數(shù)據(jù)處理串行程序，數(shù)據(jù)交換頻次較高，但由于很多程序設(shè)計(jì)上的缺陷，仍有部分網(wǎng)絡(luò)帶寬資源和CPU核資源未被有效利用。目前，該類(lèi)型數(shù)據(jù)的傳輸工作是采用基于SCP技術(shù)的單核串行程序?qū)崿F(xiàn)，該程序能夠長(zhǎng)期穩(wěn)定運(yùn)行，傳輸單次中尺度模式數(shù)據(jù)實(shí)際耗時(shí)約2 h，傳輸延時(shí)長(zhǎng)，造成數(shù)據(jù)無(wú)法及時(shí)被氣象業(yè)務(wù)和科研人員參考和使用；且該程序也不能充分利用空閑的網(wǎng)絡(luò)帶寬和數(shù)據(jù)管理服務(wù)器資源。

因此，針對(duì)現(xiàn)有數(shù)據(jù)傳輸程序的缺點(diǎn)，本文設(shè)計(jì)開(kāi)發(fā)一種新的并行數(shù)據(jù)傳輸程序，并對(duì)數(shù)值天氣預(yù)報(bào)模式的數(shù)據(jù)有效分治劃分，在不影響數(shù)據(jù)管理服務(wù)器中其它數(shù)據(jù)傳輸和處理程序的實(shí)際環(huán)境下，實(shí)現(xiàn)一種可應(yīng)用業(yè)務(wù)的基于最佳數(shù)據(jù)分治策略的并行傳輸程序，有效提高中尺度數(shù)值預(yù)報(bào)模式數(shù)據(jù)的傳輸效率。

1 數(shù)據(jù)并行傳輸程序

1.1 并行傳輸網(wǎng)絡(luò)架構(gòu)

重慶中尺度數(shù)值預(yù)報(bào)模式的相關(guān)程序在以SGI大型機(jī)和曙光服務(wù)器節(jié)點(diǎn)所組成的高性能集群平臺(tái)上運(yùn)行；模式數(shù)據(jù)通過(guò)該集群千兆以太網(wǎng)絡(luò)傳輸?shù)綌?shù)據(jù)管理服務(wù)器（圖1），SGI大型機(jī)和數(shù)據(jù)管理服務(wù)器之間通過(guò)網(wǎng)絡(luò)交換機(jī)連接，工作模式為全雙工，網(wǎng)絡(luò)整體帶寬為1000Mbps。數(shù)據(jù)管理服務(wù)器是一臺(tái)曙光高性能服務(wù)器節(jié)點(diǎn)，管理約37種數(shù)值預(yù)報(bào)相關(guān)業(yè)務(wù)數(shù)據(jù)資料的傳輸和處理工作，也管理著科研用戶(hù)的天氣過(guò)程試驗(yàn)資料；服務(wù)器架構(gòu)是對(duì)稱(chēng)多處理器（Symmetrical Multi-Processing，SMP）[1-2]，具備16個(gè)處理器核（即CPU Core）。服務(wù)器節(jié)點(diǎn)之間基于基礎(chǔ)的TCP/IP協(xié)議實(shí)現(xiàn)數(shù)據(jù)傳輸交互。

圖1 并行傳輸網(wǎng)絡(luò)拓?fù)銯ig. 1 The network topology of parallel transmission

1.2 并行傳輸程序

基于現(xiàn)有有限的網(wǎng)絡(luò)和數(shù)據(jù)管理服務(wù)器資源，構(gòu)建的并行傳輸主程序按照預(yù)先設(shè)計(jì)的參數(shù)構(gòu)建一進(jìn)程池，該進(jìn)程池中每一進(jìn)程只占用一個(gè)處理器核，數(shù)據(jù)傳輸任務(wù)由主程序依次分配給進(jìn)程池中的進(jìn)程去執(zhí)行，進(jìn)程池中各個(gè)進(jìn)程間相互獨(dú)立，在執(zhí)行任務(wù)時(shí)它們之間沒(méi)有信息交互規(guī)程，是一種易并發(fā)執(zhí)行過(guò)程[3-4]；傳輸任務(wù)完成后的進(jìn)程處于空閑態(tài)并返回進(jìn)程池中，進(jìn)程池將空閑態(tài)的進(jìn)程信息反饋給主程序，主程序檢查傳輸任務(wù)列表，并將新的傳輸任務(wù)分配給空閑態(tài)的進(jìn)程執(zhí)行；當(dāng)任務(wù)列表中無(wú)數(shù)據(jù)傳輸任務(wù)，且所有傳輸任務(wù)的進(jìn)程都執(zhí)行完畢，進(jìn)程池將所有空閑態(tài)的進(jìn)程信息反饋給主程序，由主程序回收所有進(jìn)程并關(guān)閉進(jìn)程池。

該并行傳輸程序采用Python語(yǔ)言和Rsync同步技術(shù)[5-6]實(shí)現(xiàn)數(shù)據(jù)傳輸流程。Python是目前較流行的一種高級(jí)解釋型編程語(yǔ)言，運(yùn)行該語(yǔ)言編寫(xiě)的程序調(diào)試運(yùn)行的基礎(chǔ)是在相應(yīng)的操作系統(tǒng)平臺(tái)安裝的Python解釋器[7]；該語(yǔ)言擁有眾多開(kāi)源的軟件包，非常適合多領(lǐng)域的編程開(kāi)發(fā)和科研人員使用，本程序采用multiprocessing包[8]，通過(guò)multiprocessing.Pool函數(shù)構(gòu)建一個(gè)含有多個(gè)進(jìn)程的進(jìn)程池；Rsync是Linux系統(tǒng)中非常流行的數(shù)據(jù)同步傳輸和備份技術(shù)，擁有SSH（Secure SHELL）和C/S架構(gòu)兩種配置應(yīng)用方式，能實(shí)現(xiàn)數(shù)據(jù)的快速?gòu)?fù)制、遠(yuǎn)程復(fù)制、文件傳輸和安全文件傳輸?shù)裙δ埽约跋嗤钟蚓W(wǎng)內(nèi)多個(gè)服務(wù)器之間的數(shù)據(jù)快速傳輸及同步功能，Rsync使用一種遠(yuǎn)程更新協(xié)議，該遠(yuǎn)程更新協(xié)議采用一個(gè)有效的總和檢查搜索算法，該算法允許Rsync通過(guò)網(wǎng)絡(luò)鏈接僅傳輸兩端之間數(shù)據(jù)的不同部分，且可以壓縮和校驗(yàn)數(shù)據(jù)[5-6,9]；本程序的子功能模塊函數(shù)采用第一種配置應(yīng)用方式，即在兩臺(tái)服務(wù)器之間采用SSH協(xié)議[6]實(shí)現(xiàn)身份驗(yàn)證，身份驗(yàn)證通過(guò)后，調(diào)用Rsync實(shí)現(xiàn)服務(wù)器端到端的數(shù)據(jù)傳輸。

該并行傳輸主程序的流程（圖2）在啟動(dòng)初始化后，根據(jù)試驗(yàn)測(cè)試環(huán)境要求靈活配置處理器核數(shù)和劃分分治數(shù)據(jù)包大小。因每一進(jìn)程占用一個(gè)處理器核，配置處理器核數(shù)可理解為設(shè)置進(jìn)程池中進(jìn)程數(shù)目。從并行傳輸主程序的源碼可看出，在初始化和配置相關(guān)變量后，process_nn為處理器核數(shù)，dip_n為分治的數(shù)據(jù)包大小，主程序首先通過(guò)create_list 函數(shù)創(chuàng)建dip_n分治數(shù)據(jù)包大小的傳輸任務(wù)列表，接著通過(guò)Python的Pool函數(shù)創(chuàng)建一個(gè)進(jìn)程數(shù)為process_nn的進(jìn)程池；傳輸任務(wù)列表中任務(wù)由主程序分配給具體的進(jìn)程，此過(guò)程由apply_async函數(shù)完成。因數(shù)據(jù)管理服務(wù)器的處理器核資源有限，劃分分治后的數(shù)據(jù)傳輸任務(wù)數(shù)目均會(huì)大于進(jìn)程池中進(jìn)程數(shù)目，進(jìn)程池中進(jìn)程并發(fā)執(zhí)行后，具體執(zhí)行數(shù)據(jù)傳輸?shù)暮瘮?shù)是rsy_2d_list，在該函數(shù)中采用Rsync檢測(cè)和傳輸數(shù)值預(yù)報(bào)模式的輸出數(shù)據(jù)；主程序一直等待進(jìn)程池中出現(xiàn)空閑態(tài)進(jìn)程，若傳輸任務(wù)列表里仍有待執(zhí)行的任務(wù)，程序及時(shí)再將列表里的傳輸任務(wù)分配給進(jìn)程池中的空閑態(tài)進(jìn)程；并行傳輸主程序循環(huán)反復(fù)檢測(cè)傳輸任務(wù)列表和進(jìn)程池中進(jìn)程態(tài)，直至傳輸任務(wù)全部執(zhí)行且進(jìn)程池中進(jìn)程均為空閑態(tài)后，并行程序關(guān)閉進(jìn)程池和回收進(jìn)程資源，整體的傳輸程序流程結(jié)束。

圖2 并行傳輸主程序流程Fig. 2 Main program flow of the parallel transmission

#并行傳輸主程序的源碼

if __name__ == '__main__':

startt=int(time.time())

dip_n=sys.argv[1] # 設(shè)置模式2d數(shù)據(jù)分治數(shù)據(jù)包大小值

process_nn=sys.argv[2] # 設(shè)置并行程序的CPU資源數(shù)

nn=string.atoi(dip_n)

process_n=string.atoi(process_nn)

# filename存儲(chǔ)2d數(shù)據(jù)包含的氣象要素種類(lèi)，包含溫、壓、濕、風(fēng)以及降水等

list_result=create_list(filename,nn) # 根據(jù)分治數(shù)據(jù)包大小值，通過(guò)該函數(shù)將2d數(shù)據(jù)按照氣象要素種類(lèi)進(jìn)行劃分，劃分后返回一個(gè)列表對(duì)象，供下面使用

print list_result #輸出列表，檢查2d數(shù)據(jù)劃分是否準(zhǔn)確

log_file=log_rsync_data2d.log # 指定數(shù)據(jù)傳輸?shù)娜罩居涗浳募?/p>

len_result=len(list_result)-1 # 確定列表最后一個(gè)元素的下標(biāo)，作為任務(wù)分配終止邏輯判斷條件參數(shù)

pool=multiprocessing.Pool(processes=process_n) #利用python的multiprocessing創(chuàng)建進(jìn)程池，該進(jìn)程池包含了prpcess_n個(gè)進(jìn)程

print "start allocate processes to job "

while len_result >= 0: # 未到達(dá)劃分分治列表的最后時(shí)，循環(huán)向進(jìn)程池分配數(shù)據(jù)傳輸任務(wù)

print "----rsync_2d_list-----"

pool.apply_async(rsy_2d_list,(list_result[len_result],)) # 將劃分列表中的元素傳參給傳輸任務(wù)，將傳輸任務(wù)分配到進(jìn)程池中的一個(gè)進(jìn)程，并開(kāi)始啟動(dòng)進(jìn)程

len_result=len_result-1

print list_result[len_result]

pool.close() # 當(dāng)所有的數(shù)據(jù)傳輸任務(wù)進(jìn)程完成后，關(guān)閉進(jìn)程池

pool.join() # 釋放進(jìn)程池所占資源，回調(diào)到主程序中，繼續(xù)執(zhí)行主程序下面代碼

endtt=int(time.time())

print "sub processes done and exit "

print "total run: %d seconds "%(endtt-startt)

if os.path.isfile(log_file):

output_f=open(log_file,'a')

output_f.write("%d core %d elment%d "%(process_n,nn,endtt-startt)) # 計(jì)算并行的運(yùn)行時(shí)間，并將時(shí)間寫(xiě)入日志記錄中

output_f.close()

2 數(shù)據(jù)劃分與分析

數(shù)據(jù)及問(wèn)題的劃分分治在并行程序設(shè)計(jì)中占有重要地位，是并行程序開(kāi)發(fā)過(guò)程中首要解決的問(wèn)題[3]，合理的數(shù)據(jù)劃分分治將大幅提高并行程序的工作效率，本節(jié)重點(diǎn)開(kāi)展針對(duì)重慶中尺度數(shù)值預(yù)報(bào)模式數(shù)據(jù)劃分分治及對(duì)比分析。

2.1 劃分分治

重慶中尺度數(shù)值預(yù)報(bào)模式輸出的數(shù)據(jù)格式為NC格式二進(jìn)制的2d（2 dimension）數(shù)據(jù)文件，該模式一次輸出的數(shù)據(jù)量約13 GB，整體數(shù)據(jù)由18444左右個(gè)小文件組成，文件數(shù)量龐大而無(wú)序，每一小文件約700 K左右，表示不同時(shí)空分辨率下的一種氣象要素場(chǎng)（如溫、壓濕、風(fēng)、降水）數(shù)據(jù)，該數(shù)據(jù)共包含氣象要素場(chǎng)100多種，包含業(yè)務(wù)需求的兩種空間分辨率（27 km和3 km）的數(shù)據(jù)，27 km類(lèi)型的預(yù)報(bào)時(shí)間分辨率為3 h，3 km類(lèi)型的時(shí)間分辨率為1 h，因此，針對(duì)同一種氣象要素場(chǎng)，空間分辨率3 km的數(shù)據(jù)量要大于空間分辨率27 km的數(shù)據(jù)量。根據(jù)上述的數(shù)據(jù)特征，本文曾依照空間分辨率劃分?jǐn)?shù)據(jù)，劃分后的數(shù)據(jù)包粒度太粗，且3 km分辨率數(shù)據(jù)傳輸時(shí)間始終會(huì)大于27 km分辨率數(shù)據(jù)傳輸時(shí)間，實(shí)際并行程序時(shí)間以3 km分辨率傳輸時(shí)間為準(zhǔn)，程序整體運(yùn)行負(fù)載不均衡；按照文件總數(shù)進(jìn)行劃分，又無(wú)法快速識(shí)別業(yè)務(wù)上優(yōu)先級(jí)別高的氣象要素場(chǎng)數(shù)據(jù)是否完整可用。最終尋求將數(shù)據(jù)的氣象要素場(chǎng)種類(lèi)作為劃分的依據(jù)開(kāi)展數(shù)據(jù)的劃分分治。

數(shù)據(jù)分治劃分流程（圖3）和劃分程序源代碼詳細(xì)闡述了模式數(shù)據(jù)的劃分的過(guò)程。其中基礎(chǔ)的是獲取模式2d數(shù)據(jù)氣象要素場(chǎng)的類(lèi)型文件，此文件包含了傳輸?shù)哪Ｊ綌?shù)據(jù)的所有要素場(chǎng)名稱(chēng)。劃分分治的功能函數(shù)是create_list，該函數(shù)需設(shè)置兩個(gè)參數(shù)，模式數(shù)據(jù)的氣象要素場(chǎng)種類(lèi)文件參數(shù)filename和劃分分治的數(shù)據(jù)包大小參數(shù)n；在初始化列表變量后，讀取和處理氣象要素場(chǎng)類(lèi)型文件中的要素場(chǎng)，生成一個(gè)初始的列表存放在內(nèi)存，按照變量n值的大小，計(jì)算劃分分治數(shù)icount和分治后的余數(shù)rest_n，通過(guò)初始列表的下標(biāo)值nex_i和pre_i，盡可能均等劃分初始列表中的氣象要素場(chǎng)，并將劃分后的結(jié)果依次存儲(chǔ)于傳輸任務(wù)列表中，最后將劃分分治后的傳輸任務(wù)列表返回給主程序。

#數(shù)值模式數(shù)據(jù)劃分功能——?jiǎng)澐殖绦蛟创a

def create_list(filename,n):

# 初始化該程序中所要使用的變量。

L_re=[]

new_L_re=[]

new_L_re01=[]

if os.path.isfile(filename): # 判斷2d數(shù)據(jù)要素文件是否存在。filename提取和存儲(chǔ)模式2d數(shù)據(jù)包含的所有的氣象要素。

print "the file is exist "

圖3 數(shù)據(jù)劃分流程Fig. 3 The flow of data partition

# 讀取氣象要素的數(shù)據(jù)到內(nèi)存中，通過(guò)兩個(gè)循環(huán)將要素?cái)?shù)據(jù)有效存儲(chǔ)于初始列表中，去除異常字符，便于劃分操作

ffile=open(filename,'r')

for line in ffile:

line=line.strip(" ").split(",")

L_re.append(line)

ffile.close()

for list_e in L_re:

str_e=str(list_e).strip("[]").strip("''")

new_L_re.append(str_e)

icount=len(new_L_re)/n # 根據(jù)設(shè)置的劃分?jǐn)?shù)據(jù)包大小，確定劃分分治數(shù)

rest_n=len(new_L_re)%n # 劃分后，確定最后一項(xiàng)數(shù)據(jù)包大小

while icount > 0:

if rest_n == 0: # 當(dāng)余數(shù)為0時(shí)，2d數(shù)據(jù)會(huì)被均等劃分

nex_i=icount*n

pre_i=(icount-1)*n

new_L_re01.append(new_L_re[pre_i:nex_i])

if rest_n != 0: #當(dāng)余數(shù)不為0時(shí)，最后一項(xiàng)數(shù)據(jù)包大小值不等于n，而是rest_n,但rest_n只能小于n，所以整體不會(huì)延長(zhǎng)數(shù)據(jù)并行傳輸時(shí)間。

pre_i=icount*n

nex_i=pre_i+rest_n

new_L_re01.append(new_L_re[pre_i:nex_i])

rest_n=0

icount=icount-1

else:

print "the file not exist"

del L_re

del new_L_re

return new_L_re01 # 返回根據(jù)n劃分好的傳輸任務(wù)列表

依據(jù)模式數(shù)據(jù)氣象要素場(chǎng)的類(lèi)型，劃分原則為一方面劃分的數(shù)據(jù)包包含的氣象要素場(chǎng)類(lèi)型不能太多，避免數(shù)據(jù)包粒度變粗，影響傳輸程序執(zhí)行效率；另一方面盡可能實(shí)現(xiàn)均等劃分，確保傳輸并行程序負(fù)載均衡；基于上述原則本文將模式數(shù)據(jù)劃分為4種不同粗細(xì)粒度的分治數(shù)據(jù)包，形成4種數(shù)據(jù)分治策略（表1），其中分治數(shù)據(jù)包大小是指每個(gè)分治策略下分治數(shù)據(jù)包包含的氣象要素場(chǎng)類(lèi)型數(shù)目，劃分分治數(shù)是指每個(gè)分治策略下總共劃分多少個(gè)分治數(shù)據(jù)包，4種分治策略中最細(xì)粒度的是分治數(shù)據(jù)包含1種氣象要素場(chǎng)，最粗力度的分治數(shù)據(jù)包包含6種氣象要素場(chǎng)；下面將對(duì)比分析這4種不同數(shù)據(jù)分治策略在不同的處理器核數(shù)下的運(yùn)行趨勢(shì)。

表1 數(shù)據(jù)分治策略Table 1 The data partition strategy

串行單核的數(shù)值模式傳輸程序平均運(yùn)行時(shí)間約7810s，數(shù)據(jù)傳輸時(shí)間很長(zhǎng)，這主要是因?yàn)楝F(xiàn)有數(shù)據(jù)管理服務(wù)器從一個(gè)物理網(wǎng)絡(luò)接口每天傳輸交互約37種數(shù)值預(yù)報(bào)模式相關(guān)的數(shù)據(jù)，物理網(wǎng)絡(luò)接口負(fù)載過(guò)大的導(dǎo)致的，但網(wǎng)絡(luò)帶寬并沒(méi)有最大化的利用。本文將4種不同數(shù)據(jù)分治策略應(yīng)用到并行傳輸程序中，通過(guò)運(yùn)行時(shí)間、加速比和并行效率三種指標(biāo)對(duì)比分析，綜合選擇最佳分治策略；加速比（S）是衡量并行傳輸程序一個(gè)重要指標(biāo)，是指單核運(yùn)行時(shí)間（Ts）和多核并行運(yùn)行時(shí)間（Tp）的比值，該值越大表明并行運(yùn)行時(shí)間越短[2,10-11]；并行效率E是在加速比上的基礎(chǔ)上引入了每次并行使用的處理器核數(shù)n，實(shí)質(zhì)上是單核運(yùn)行時(shí)間和多核并行運(yùn)行時(shí)間乘以核數(shù)n的比值，再乘以100%，主要描述并行程序運(yùn)行過(guò)程中系統(tǒng)開(kāi)銷(xiāo)時(shí)間的占比[4,11]。

2.2 試驗(yàn)和對(duì)比分析

試驗(yàn)測(cè)試環(huán)境為實(shí)際的業(yè)務(wù)應(yīng)用環(huán)境，在不影響數(shù)據(jù)管理服務(wù)器其他數(shù)據(jù)傳輸交互業(yè)務(wù)的實(shí)際情況下，極大化的占用空閑態(tài)的處理器核資源和網(wǎng)絡(luò)帶寬。在實(shí)際應(yīng)用環(huán)境下測(cè)試，發(fā)現(xiàn)當(dāng)并發(fā)執(zhí)行進(jìn)程數(shù)超過(guò)8時(shí)，數(shù)據(jù)傳輸會(huì)出現(xiàn)大量丟包現(xiàn)象，進(jìn)程數(shù)設(shè)置超過(guò)10時(shí)，數(shù)據(jù)傳輸完全中斷失敗，這說(shuō)明進(jìn)程數(shù)設(shè)置為8以上的值時(shí)，便無(wú)服務(wù)器資源和網(wǎng)絡(luò)帶寬可供分配使用，且逐漸開(kāi)始占用其他數(shù)據(jù)傳輸處理程序的資源，所以為了實(shí)現(xiàn)業(yè)務(wù)應(yīng)用環(huán)境下本并行傳輸程序改善的實(shí)際效果，設(shè)置的進(jìn)程數(shù)的閾值為8。服務(wù)器節(jié)點(diǎn)操作系統(tǒng)均為SUSE 11 Linux x86_64，服務(wù)器節(jié)點(diǎn)均安裝Python，并實(shí)現(xiàn)了SSH身份驗(yàn)證，試驗(yàn)分為三種類(lèi)型，為了保證試驗(yàn)效果和試驗(yàn)數(shù)據(jù)的可信度，試驗(yàn)過(guò)程中處理器核數(shù)遞增間隔為2；對(duì)比分析過(guò)程中，各個(gè)指標(biāo)的對(duì)比分析圖中將離散試驗(yàn)數(shù)據(jù)用不同的類(lèi)型曲線(xiàn)連接，以便直觀展示各分治策略的變化趨勢(shì)。

不同數(shù)據(jù)分治策略下的并行運(yùn)行時(shí)間均優(yōu)于單核串行程序（圖4）。各分治策略隨著核數(shù)增加，并行運(yùn)行時(shí)間逐漸縮小，當(dāng)處理器核數(shù)從2到4時(shí)，運(yùn)行時(shí)間降幅較大，運(yùn)行時(shí)間差2000多秒，從4增至8時(shí)，并行運(yùn)行時(shí)間降幅度明顯縮小，時(shí)間差均在300 s左右，從各分治策略的轉(zhuǎn)折線(xiàn)可看出，核數(shù)的增加并不意味著運(yùn)行時(shí)間會(huì)以相同的速度減少，主要是隨著核數(shù)的增加，系統(tǒng)在分配任務(wù)的進(jìn)程數(shù)增多到一定程度，進(jìn)程間通信開(kāi)銷(xiāo)大幅度增長(zhǎng)，但系統(tǒng)總線(xiàn)只有一條，所以才導(dǎo)致并行運(yùn)行時(shí)間降低力度縮小，運(yùn)行效率開(kāi)始漸漸降低；分治策略1、2、4運(yùn)行時(shí)間趨勢(shì)一致且?guī)缀踔睾?，在超過(guò)4個(gè)處理器核后，趨勢(shì)線(xiàn)的斜率有明顯一致的變化。分治策略3有點(diǎn)不同，在處理器核數(shù)由2增至6時(shí)，趨勢(shì)線(xiàn)斜率變化相對(duì)而言變化不大，增至到8時(shí)，趨勢(shì)線(xiàn)斜率和其他策略保持一致，這說(shuō)明隨著核數(shù)增加，分治策略3的運(yùn)行時(shí)間降低力度明顯，且運(yùn)行時(shí)間開(kāi)始逐漸優(yōu)于其他分治策略。

圖4 數(shù)據(jù)分治策略運(yùn)行時(shí)間變化趨勢(shì)Fig. 4 The data partition strategies runtime versus number of cores

分治策略的加速比和并行時(shí)間變化趨勢(shì)有一定的關(guān)聯(lián)（圖5）。隨著處理器核數(shù)的增加，各分治策略下的加速比均呈現(xiàn)非線(xiàn)性的上升趨勢(shì)。從圖3中折線(xiàn)的斜率可看出，分治策略1、2、4的處理器核數(shù)從2增至4時(shí)，加速比變化幅度較大，數(shù)據(jù)傳輸效率提升效果明顯，核數(shù)從4增加到8時(shí)，加速比變化趨勢(shì)發(fā)生了轉(zhuǎn)折，加速比變化幅度相對(duì)減小；分治策略3的加速比變化趨勢(shì)有點(diǎn)不同，當(dāng)處理器核數(shù)增加到6時(shí)，加速比變化趨勢(shì)最大，核數(shù)從6增至8時(shí)，加速比趨勢(shì)趨于平緩；分治策略3使用處理器核數(shù)增加到4時(shí)，加速比值均低于其他分治策略，隨著處理器核數(shù)不斷增加，加速比值逐漸提高，并最終優(yōu)于其他分治策略，在超過(guò)4個(gè)處理器核數(shù)后，該分治策略對(duì)數(shù)據(jù)的傳輸效率改善效果最大。加速比趨勢(shì)變化和上述的并行運(yùn)行時(shí)間的趨勢(shì)變化類(lèi)似，說(shuō)明并行運(yùn)行時(shí)間變化趨勢(shì)決定加速比變化趨勢(shì)。

圖5 數(shù)據(jù)分治策略加速比變化趨勢(shì)Fig. 5 The data partition strategies acceleration ratio versus number of cores

最后，對(duì)比分析一下不同分治策略的并行效率（圖6），隨著處理器核數(shù)增加，分治策略的并行效率均呈現(xiàn)不同的下降趨勢(shì)。主要因?yàn)榧措S著處理器核數(shù)資源占用越來(lái)越多，進(jìn)程數(shù)越多，并行程序需耗費(fèi)更多系統(tǒng)開(kāi)銷(xiāo)時(shí)間來(lái)完成資源調(diào)度分配，導(dǎo)致數(shù)據(jù)并行傳輸處理時(shí)間所占比重降低；分治策略1、2、4呈現(xiàn)的趨勢(shì)較為一致，并行效率從90%左右逐漸降低至70%以下，且是非線(xiàn)性的變化趨勢(shì)，處理器核數(shù)增至4個(gè)以上時(shí)，并行效率降低明顯；而分治策略3卻呈現(xiàn)另外一種變化趨勢(shì)，它的并行效率雖然整體上也是逐漸降低，但在核數(shù)增至到6時(shí)，并行效率開(kāi)始大幅提升，這一點(diǎn)和其策略其它兩個(gè)指標(biāo)有一定的關(guān)聯(lián)，該分治策略前兩個(gè)指標(biāo)可以看出，當(dāng)核數(shù)從4增至6時(shí)，該分治策略發(fā)生較大變化，指標(biāo)值從最差變?yōu)樽罴眩到y(tǒng)開(kāi)銷(xiāo)時(shí)間占比相對(duì)于整體并行傳輸時(shí)間最低；從整體并行效率變化趨勢(shì)看，分治策略3并行化效率變化范圍控制在70%～85%，整體變化范圍比較穩(wěn)定，其他分治策略并行效率的變化范圍和降低力度相對(duì)較大。

圖6 數(shù)據(jù)分治策略并行效率變化趨勢(shì)Fig. 6 The data partition strategies parallel efficiency versus number of cores

為充分利用現(xiàn)有空閑網(wǎng)絡(luò)帶寬和服務(wù)器處理器核資源，實(shí)現(xiàn)數(shù)據(jù)傳輸運(yùn)行時(shí)間最短和并行傳輸程序穩(wěn)定和最佳并行效率，綜合對(duì)比上述并行運(yùn)行時(shí)間、加速比和并行效率三個(gè)指標(biāo)，分治策略3是并行數(shù)據(jù)傳輸應(yīng)用的最佳策略，基于該分治策略的并行傳輸程序能夠能將傳輸時(shí)間從7810 s縮小至1297 s，加速比高達(dá)6.02，網(wǎng)絡(luò)帶寬利用率提高了6倍左右，且并行效率維持在75%左右，數(shù)據(jù)管理服務(wù)器的處理器核利用率達(dá)到50%。

3 結(jié)論

以重慶中尺度數(shù)值天氣預(yù)報(bào)模式為例，中尺度數(shù)值預(yù)報(bào)模式的數(shù)據(jù)并行傳輸程序在現(xiàn)有網(wǎng)絡(luò)和計(jì)算機(jī)資源基礎(chǔ)上，采用Python和Rsync數(shù)據(jù)傳輸同步技術(shù)構(gòu)建和實(shí)現(xiàn)；根據(jù)模式數(shù)據(jù)的特征和實(shí)際業(yè)務(wù)應(yīng)用環(huán)境，將模式數(shù)據(jù)劃分為4種分治策略，對(duì)比分析4種不同的分治策略，綜合選擇最佳的數(shù)據(jù)分治策略，最終實(shí)現(xiàn)最優(yōu)的模式數(shù)據(jù)并行傳輸。最優(yōu)數(shù)據(jù)并行傳輸一方面極大減少模式數(shù)據(jù)并行傳輸時(shí)間，提高模式數(shù)據(jù)傳輸效率，另一方面也較充分利用數(shù)據(jù)管理服務(wù)器中空閑的處理器核和網(wǎng)絡(luò)帶寬，為中尺度數(shù)值預(yù)報(bào)模式海量數(shù)據(jù)高效率傳輸備份提供一種解決方案。但重慶精細(xì)化數(shù)值天氣預(yù)報(bào)系統(tǒng)不僅包含重慶中尺度數(shù)值預(yù)報(bào)模式，按照建設(shè)要求還將包含其他不同尺度多類(lèi)型數(shù)值天氣預(yù)報(bào)模式，傳輸?shù)臄?shù)據(jù)量也將大幅增大，未來(lái)將進(jìn)一步研究基于MPI的進(jìn)程組間無(wú)阻塞通信方式的更加通用的并行傳輸應(yīng)用技術(shù)，以滿(mǎn)足重慶精細(xì)化數(shù)值天氣預(yù)報(bào)系統(tǒng)的更大容量數(shù)據(jù)高效率傳輸需求。