楊玉紅,寇媛媛,喬文文
(廣東省氣象探測數(shù)據(jù)中心,廣東 廣州 510000)
近年來,隨著信息技術的飛速發(fā)展,各行各業(yè)信息化建設呈現(xiàn)出日新月異的發(fā)展景象,氣象行業(yè)更是如此[1-6]。信息化帶來海量數(shù)據(jù),既是一種機遇,也是一種挑戰(zhàn)。一方面,數(shù)據(jù)有長期保存的價值,必須存儲很多歷史數(shù)據(jù),另一方面實時數(shù)據(jù)也在不斷激增。如何提高資料的存儲與應用效率已是當前一個熱門話題與研究重點[7-10]。
NetCDF是一種可以對網(wǎng)格數(shù)據(jù)進行高效存儲、管理、獲取和分發(fā)等操作的數(shù)據(jù)格式。由于其靈活性,能夠傳輸海量的面向陣列(array-oriented)數(shù)據(jù),目前廣泛應用于大氣科學等諸多領域。例如,NCEP(美國國家環(huán)境預報中心)發(fā)布的再分析資料,NOAA的CDC(氣候數(shù)據(jù)中心)發(fā)布的海洋與大氣綜合數(shù)據(jù)集(COADS)均采用NetCDF作為標準。鑒于此,廣東省氣象探測數(shù)據(jù)中心近年來建立了“廣東省氣象格點資料服務平臺”,服務內(nèi)容之一即快速生成便于存儲、查詢、展示的NetCDF格式的數(shù)值預報產(chǎn)品,形成完整、有序、規(guī)范、高效的NetCDF產(chǎn)品庫,并提供給省內(nèi)外的用戶使用。
NetCDF數(shù)據(jù)集(文件名后綴為.nc)的格式不是固定的,是使用者根據(jù)需求自己定義的。一個NetCDF數(shù)據(jù)集包含維(dimensions)、變量(variables)和屬性(attributes)三種描述類型,每種類型都會被分配一個名字和一個ID,這些類型共同描述了一個數(shù)據(jù)集,NetCDF庫可以同時訪問多個數(shù)據(jù)集,用ID來識別不同數(shù)據(jù)集。變量存儲實際數(shù)據(jù),維給出了變量維度信息,屬性則給出了變量或數(shù)據(jù)集本身的輔助信息屬性,又可以分為適用于整個文件的全局屬性和適用于特定變量的局部屬性,全局屬性則描述了數(shù)據(jù)集的基本屬性以及數(shù)據(jù)集的來源。
在傳統(tǒng)的NetCDF3.5或更早期版本中,數(shù)據(jù)的存儲使用默認經(jīng)典格式(32位),這種只有32位的默認經(jīng)典格式只能寫入小于4 GB大小的文件,于是在NetCDF3.6中增加了一種采用64位的存儲格式,理論上文件大小的上限擴展到8 EB(260Bytes,1 GB=230Bytes)。在NetCDF4版本,第三種對性能顯著改進的二進制格式被引進,那就是HDF5。默認條件下,NetCDF4因向下兼容性需要,默認條件下使用32位經(jīng)典模式,如需使用64位模式以及HDF5格式,需要在創(chuàng)建文件時候進行參數(shù)設置。作為氣象數(shù)據(jù)主流存儲格式的NetCDF4[11-13],是Unidata和HDF Group合作的產(chǎn)物[14]。面對三種不同的文件格式,創(chuàng)建數(shù)據(jù)文件時候需仔細考慮選擇合適的數(shù)據(jù)格式。由于NetCDF4項目使用HDF5的存儲格式[15-16],使數(shù)據(jù)文件占用的空間大幅度降低。
文件一旦創(chuàng)建,其格式即固定。當打開存在的NetCDF文件,NetCDF庫透明檢測格式,并適應。然而,NetCDF數(shù)據(jù)庫在3.6版本以前不能識別64位模式,4.0版本之前不能讀取NetCDF4-HDF5文件。
近年來,廣東省氣象探測數(shù)據(jù)中心逐步建立氣象格點數(shù)據(jù)服務系統(tǒng)。該系統(tǒng)包含了數(shù)據(jù)解碼轉(zhuǎn)換子系統(tǒng)、數(shù)據(jù)存儲管理子系統(tǒng)、圖形產(chǎn)品生成子系統(tǒng)、數(shù)據(jù)服務子系統(tǒng)四大部分。其中數(shù)據(jù)解碼轉(zhuǎn)換子系統(tǒng)以氣象業(yè)務實際需要為出發(fā)點,在多途徑全面收集全序列的數(shù)值預報產(chǎn)品原始格式的數(shù)據(jù)文件的基礎上,實現(xiàn)全序列氣象數(shù)值預報產(chǎn)品原始格式解碼,實現(xiàn)數(shù)據(jù)的格式轉(zhuǎn)換,生成符合各類數(shù)值預報產(chǎn)品特征的NetCDF格式產(chǎn)品;數(shù)據(jù)存儲管理子系統(tǒng)將數(shù)據(jù)解碼轉(zhuǎn)換子系統(tǒng)生成的NetCDF產(chǎn)品重新組織實時存儲到相應的NetCDF產(chǎn)品庫中,形成統(tǒng)一規(guī)范的實時、歷史一體化NetCDF產(chǎn)品庫。圖形產(chǎn)品生成子系統(tǒng)則使用基于NCL(the NCAR command language) 編程語言,讀取NetCDF庫文件中的數(shù)據(jù),生成精度高、內(nèi)容展現(xiàn)豐富的數(shù)值預報圖形產(chǎn)品。數(shù)據(jù)服務子系統(tǒng)通過“廣東省實時歷史一體化數(shù)據(jù)接口服務平臺”將實時歷史數(shù)值預報產(chǎn)品對外提供服務,或通過文件調(diào)度方式對外提供服務。
目前氣象格點數(shù)據(jù)服務系統(tǒng)已經(jīng)完成,接入數(shù)值預報產(chǎn)品的原始格式有二進制數(shù)據(jù)格式、GRIB1格式、GRIB2格式,GRIB1與GRIB2混合編碼格式,以及中國氣象局下發(fā)的各種復雜壓縮格式等。接入的數(shù)值預報模式有歐洲大氣模式集合預報產(chǎn)品、歐洲大氣模式確定性預報產(chǎn)品、NCEP_GFS模式產(chǎn)品、GRAPES_TYM區(qū)域臺風數(shù)值預報產(chǎn)品、中國南海臺風精細模式、華南中尺度模式等。最高分辨率為1 km*1 km。對外服務的單位有廣東省氣象局各單位、廣東省各區(qū)縣氣象局、廣州民航、珠海民航等。實時對外提供服務的模式有30余個,每日生成的圖片數(shù)量30萬張,年生成NetCDF數(shù)據(jù)量為30 T左右。
隨著業(yè)務應用逐步深入以及數(shù)據(jù)量的逐年積累,系統(tǒng)計算資源和存儲資源面臨業(yè)務瓶頸。為了更好地適應業(yè)務的實際需求,希望借助NetCDF4的分塊與壓縮特性,提高系統(tǒng)的計算與存儲能力,優(yōu)化數(shù)值預報格點轉(zhuǎn)換平臺,使得平臺能夠更快更穩(wěn)定地對外提供服務。
“廣東省氣象格點數(shù)據(jù)服務系統(tǒng)”始建于2012年,系統(tǒng)建設選擇的NetCDF版本為3.6。為了提升系統(tǒng)的服務能力,2018年開始將系統(tǒng)的NetCDF版本逐步升級為4.5,全面提升系統(tǒng)的存儲能力與服務效率。
為了更好地研究NetCDF4的性能,選取了三個數(shù)據(jù)量較小、中等、較大的有代表性的模式進行分析,分別是在NetCDF4連續(xù)存儲的情況下月數(shù)據(jù)量為20.3 GB的歐洲中心32天數(shù)值預報(簡稱ECMWF_S4F)、525 GB的NCEP_GFS模式和958 GB的歐洲中心46天集合預報(簡稱ECMWF_ENSEXT)。三個模式在虛擬機平臺中的三臺不同的服務器中,且每個模式的連續(xù)、分塊以及壓縮程序均在同一服務器內(nèi)進行,模式參數(shù)如表1所示。
值得注意的是,文中所有的NetCDF月數(shù)據(jù)量在未特殊說明的前提下均為模式在NetCDF4連續(xù)存儲的情況下獲得的數(shù)據(jù)量,同時NetCDF4均指版本4.5。并且,GRIB格式至NetCDF格式的轉(zhuǎn)換指的是,將一個數(shù)值預報模式單時次所有GRIB數(shù)據(jù),根據(jù)要素進行分類存儲,得到的NetCDF文件個數(shù)為模式中要素的個數(shù),且為了數(shù)據(jù)的高效讀取使用,將一個月的單要素數(shù)據(jù)存在一個數(shù)據(jù)文件中。即ECMWF_S4F模式,一個月只生成7個NetCDF數(shù)據(jù)文件,NCEP_GFS模式一個月生成25個NetCDF數(shù)據(jù)文件,ECMWF_ENSEXT模式一個月生成24個NetCDF數(shù)據(jù)文件。這里一個月指的是自然月。
表1 三個數(shù)值預報模式信息
文中主要對NetCDF文件的創(chuàng)建與更新兩個核心過程做時間測算,關注NetCDF文件的寫入操作。其中對NetCDF文件創(chuàng)建的時間測量是使用C函數(shù)gettimeofday分別獲取NetCDF的API函數(shù)nc_create之前、nc_close之后的時間,取兩者差值,是指在NetCDF文件不存在的情況下,生成文件的耗時;其中對NetCDF文件寫數(shù)據(jù)的更新操作是使用gettimeofday分別獲取nc_open之前、nc_close之后的時間,取兩者差值,是指NetCDF文件已存在,將新的數(shù)據(jù)插入或者覆蓋原有數(shù)據(jù)文件的耗時。
為了對比模式在不同存儲方式下的實際運行時間,所有分析程序均在相同配置服務器上運行。服務器使用Linux虛擬機,內(nèi)核版本為Centos Linux release 7.1.1503,CPU為4個Intel(R) Xeon(R) CPU E7-4809,每個4核,共16核,主頻2.0 GHz,32 GB內(nèi)存,gcc版本為4.8.2。相同模式的不同分塊、壓縮策略,均在同一服務器上運行。
分塊存儲策略是針對連續(xù)存儲模式提出的非連續(xù)存儲模式。傳統(tǒng)的NetCDF模式采用連續(xù)的存儲模式,無論是在內(nèi)存還是外部存儲器上。比如某個數(shù)據(jù)只有data[5,7]兩個維度35個網(wǎng)格點,傳統(tǒng)模式在寫入數(shù)據(jù)時采用連續(xù)存儲,先存儲前7個數(shù)據(jù)(data[0,]),第8個數(shù)據(jù)在data[1,0],第15個數(shù)據(jù)在data[2,0],第22個與第29個數(shù)據(jù)分別為data[3,0]與data[4,0],從外部設備的角度來看這35個數(shù)據(jù)是串行存儲的。如果選擇將第1、第8、第15、第22與第29個數(shù)據(jù)分成一個組來存儲,則與第1個數(shù)據(jù)相鄰的數(shù)據(jù)不是第2個而是第8個,這就是非連續(xù)性存儲。舉例用的就是被稱為[5*1]的分塊策略,使用非連續(xù)存儲模式,必須引入一個分塊管理器去管理數(shù)據(jù),對用戶是透明的,這種額外開銷在不同業(yè)務中會呈現(xiàn)出不同的性能,同時也會帶來一個好處,可以使用多個并發(fā)線程去做IO操作。傳統(tǒng)的連續(xù)存儲在多線程并發(fā)時IO必須通過資源鎖機制來保證數(shù)據(jù)的完整性,一旦某個數(shù)據(jù)被鎖定,其他線程就不得不進行等待,直至該鎖解除為止,這就是傳統(tǒng)連續(xù)存儲的IO瓶頸。這就意味著如果某個業(yè)務數(shù)據(jù)的IO不是瓶頸,使用分塊策略或者不合適的分塊策略反而會大大增加業(yè)務的操作時長。因為分塊管理器要做好數(shù)據(jù)的切割與訪問控制,所以數(shù)據(jù)切得太細,訪問過于頻繁,都會使得分塊管理器無法發(fā)揮最大效用。選擇合適的分塊大小,就是為了更好地切割數(shù)據(jù),使得寫數(shù)據(jù)與讀數(shù)據(jù)的操作能夠最大限度地分離,這樣效率最高。
在NetCDF4的HDF5,選擇合適的分塊策略與壓縮系數(shù)會對程序的運行時間與數(shù)據(jù)文件大小有顯著的影響,這是傳統(tǒng)模式與64位模式不具備的。當業(yè)務處理的數(shù)據(jù)量變大,尤其在接近1 TB的時候,合適的分塊策略會讓程序運行的時長縮減為之前的約四十分之一1/40,但分塊策略也不總是會提升程序運行速度,在某些分塊策略下,程序運行的時長會變得難以容忍。對于某些業(yè)務數(shù)據(jù)特別大且對程序運行的時長寬容度比較高時,通過調(diào)整數(shù)據(jù)的壓縮系數(shù)可以使用時間換空間的原則,增加程序運行的時間,從而壓縮數(shù)據(jù)存儲空間,使得占用空間變成原來的約五百六十分之一1/560。因此針對業(yè)務的不同需求,通過調(diào)整NetCDF4的分塊策略與壓縮系數(shù)獲得最高的性能。
當NetCDF4程序啟用了HDF5模式后,可以通過調(diào)整chunk_size參數(shù)來設置分塊存儲策略。本節(jié)使用表1中三個數(shù)值預報模式,分析不同分塊策略創(chuàng)建與更新文件所需的時間。
對于ECMWF_S4F模式,文中共驗證了6種不同分塊策略創(chuàng)建文件和更新文件使用的時間,當經(jīng)度維度和緯度維度分塊數(shù)分別為1時,創(chuàng)建文件和更新文件速度非常慢,耗時非常長。圖1為ECMWF_S4F模式使用5種不同分塊策略創(chuàng)建文件使用的時間。
圖1 ECMWF_S4F模式不同分塊策略 創(chuàng)建文件時間對比
對于NCEP_GFS模式,文中共驗證了5種不同分塊策略創(chuàng)建文件和更新文件使用的時間。圖2為其中4種較慢分塊策略創(chuàng)建文件使用的時間。
對于ECMWF_ENSEXT模式,文中共驗證了4種不同分塊策略創(chuàng)建文件和更新文件使用的時間。圖3為4種不同分塊策略創(chuàng)建文件使用的時間。
圖3 ECMWF_ENSEXT模式不同分塊 策略創(chuàng)建文件時間對比
NetCDF4可通過HDF5庫選取不同的壓縮算法對數(shù)據(jù)進行無損壓縮,壓縮系數(shù)為1至9。常見的無損壓縮算法有GZIP、LZF等,其中GZIP算法具有中等速度高壓縮率,LZF算法具有快速但中等的壓縮率。
因為NetCDF4使用的是無損壓縮,不會對數(shù)據(jù)精度產(chǎn)生影響,更容易被用戶接受使用。使用數(shù)據(jù)壓縮的特性,可縮小文件大小,并縮短壓縮數(shù)據(jù)的數(shù)據(jù)傳輸時間。壓縮是在創(chuàng)建數(shù)組變量(數(shù)據(jù)集)時指定的。所有壓縮/解壓縮操作都由HDF5庫自動處理,對應用程序透明。
圖4~圖6為三種模式在壓縮系數(shù)為1至9時創(chuàng)建文件用時與文件大小。由圖5和圖6可見,在壓縮系數(shù)為1至3時,各模式創(chuàng)建文件用時相差不大,壓縮后的文件大小較為接近;壓縮系數(shù)為4至9時,創(chuàng)建文件用時基本不變,文件大小的變化也不明顯;而在壓縮系數(shù)為3、4之間,壓縮后的文件大小急劇減少,創(chuàng)建文件用時也急劇增加。。
圖4 ECMWF_S4F模式不同壓縮系數(shù) 創(chuàng)建文件用時與文件大小
圖5 NCEP_GFS模式不同壓縮系數(shù) 創(chuàng)建文件用時與文件大小
圖6 ECMWF_ENSEXT模式不同壓縮 系數(shù)創(chuàng)建文件用時與文件大小
綜上,結(jié)合表2可知,集合預報成員維度在數(shù)據(jù)量較大的模式ECMWF_ENSEXT中選取越大,耗時越長,在數(shù)據(jù)量較小的ECMWF_S4F模式中相反;預報時效維度在所有模式中顯示的規(guī)律是數(shù)值越大耗時越長;第三維度以及之后的維度顯示的規(guī)律是數(shù)值越小,耗時越長。因此,如果數(shù)據(jù)產(chǎn)品擁有多個維度(尤其是4個或4個以上的維度),對前三個維度選取合適的分塊參數(shù),會顯著提升程序的性能,在非前三個維度設置細粒度的分塊參數(shù)(尤其是選擇分塊參數(shù)為1的時候),程序的性能會顯著變差。
從研究結(jié)果可以看出,調(diào)整數(shù)據(jù)產(chǎn)品的前三個維度對程序的整體運行速度影響很大,但在參數(shù)的選擇上并未出現(xiàn)線性規(guī)律,需要使用者通過選取不同參數(shù)的分塊策略進行對比,獲得針對某個業(yè)務最合適的分塊策略。
表2 三個數(shù)值預報模式不同存儲策略創(chuàng)建、更新文件時間
表3 三個數(shù)值預報模式不同壓縮系數(shù)月文件數(shù)據(jù)量對比
由表3可知,壓縮系數(shù)1至3時,各模式壓縮后的文件大小基本一致,ECMWF_S4F模式的壓縮率最高,約為連續(xù)存儲方式的二千三百分之一1/2300,ECMWF_ENSEXT模式的壓縮率最小,約為連續(xù)存儲方式的一百六十分之一1/160;各模式在壓縮系數(shù)1至3時,程序用時差異不大;當壓縮系數(shù)選取4至9時,各模式壓縮后的文件大小也基本一致,ECMWF_S4F模式的壓縮率最高,約為連續(xù)存儲方式的八千二百分之一1/8200,ECMWF_ENSEXT模式的壓縮率最小,約為連續(xù)存儲方式的四百八十分之一1/480;各模式在壓縮系數(shù)4至9時,程序用時差異不大。而在壓縮系數(shù)3、4之間,壓縮后的文件大小急劇減小,程序用時急劇上升。
因此,在時間要求嚴格的環(huán)境下,建議選擇3或3以下的壓縮系數(shù),在空間要求嚴格的環(huán)境下,選擇4或4以上的壓縮系數(shù)。
從“廣東省氣象格點數(shù)據(jù)服務系統(tǒng)”出發(fā),介紹了NetCDF4在氣象格點數(shù)據(jù)服務系統(tǒng)中的應用,對比了同種數(shù)值預報模式使用不同分塊策略時創(chuàng)建與更新文件時間,對比了NetCDF4在不同壓縮系數(shù)時的性能,通過性能分析了解了NetCDF4的新特性,進行了性能調(diào)校,并在此基礎上總結(jié)出了NetCDF4的調(diào)優(yōu)策略。合適的調(diào)優(yōu)策略會顯著減少文件的創(chuàng)建(更新)時間,或提高文件的壓縮率,節(jié)省系統(tǒng)的存儲空間。
該研究結(jié)果為NetCDF4在數(shù)值預報業(yè)務中的全面使用奠定了基礎,為提高數(shù)值預報業(yè)務存儲效率提供了可靠的實踐依據(jù)。NetCDF4合理適當?shù)氖褂脤@著提高氣象格點數(shù)據(jù)服務系統(tǒng)的服務效率,也是未來幾年“廣東省氣象格點數(shù)據(jù)服務系統(tǒng)”的主要工作方向。