馮 冼,方 昆,文立恒,朱宏武
(1.湖南省氣象信息中心,湖南 長沙 410118;2.氣象防災減災湖南省重點實驗室,湖南 長沙 410118)
氣象現代化和信息化不斷推進,業(yè)務服務不斷拓展,各類氣象數據海量增長[1]。以湖南為例,目前各類觀測系統(tǒng)、CMACast和行業(yè)匯集的數據達400 GB/日。尤其是建設湖南省高分衛(wèi)星氣象應用中心后,增加了高分遙感衛(wèi)星資料,日處理數據量達TB級。如何進行海量氣象數據高速處理,為氣象預報預警、防災減災提供更及時、更高效的數據服務,其作用至關重要[2]。
近年來信息技術不斷發(fā)展,出現了Hadoop、HDFS、MapReduce等技術支撐海量數據處理,在氣象和其他行業(yè)普遍應用[3-5],但由于Hadoop基于文件批處理設計、MapReduce基于批處理模型編程,普遍存在響應不及時、處理延遲大等情況。為解決上述問題,信息行業(yè)提出了Storm分布式架構[6]以及Spring Cloud云架構[7]增強實時數據處理能力,采用Apache Kafka[8]作為流式數據處理消息中間件,剝離數據流程中的發(fā)送、處理、輸出環(huán)節(jié),因具備擴展能力強的特性在氣象和各行業(yè)廣泛應用[9-10]。
但隨著數據挖掘與分析應用的不斷深入,Kafka消息并發(fā)能力和數據吞吐性能有待進一步優(yōu)化的問題也逐漸表露出來,眾多學者也開展了改進Kafka性能的相關研究。Bunrong Leang等提出在大數據環(huán)境下基于分區(qū)和多線程的流媒體改進方法以提升Kafka性能[11],顏曉蓮等提出一種改進型Kafka Partition過載優(yōu)化算法緩解Partition過載問題[12],為解決氣象數據在Kafka中高效處理提供了借鑒。
為解決在有限基礎資源支撐下提升氣象數據并發(fā)處理性能的技術難點,該文提出了一種氣象數據在流轉和處理時所需耗費的基礎資源綜合權重計算方法,以及基于氣象數據綜合權重在Kafka中分區(qū)處理的最優(yōu)策略,極大提升了氣象數據并發(fā)處理效率。
權重計算法是一種常見的評價分析方法,在數據處理中得到廣泛應用[13-14]。在數據權重評價體系中,某一個權重的大小不僅取決于單位數值(或變量)大小,也取決于單位數值在一定時間的出現次數(即為頻率),因此也統(tǒng)稱為權數[15]。
常用的權重計算法包括主觀賦權法、客觀賦權法等類型。主觀賦權法主要通過專家和決策者意愿或經驗確定指標權值,其不足在于過分依賴專家意見。而客觀賦權法則通過數據相互之間的關聯性計算分類權重,其數學理論依據較強,應用也較為廣泛。
該文采用客觀賦權法中的熵權法[16](Entropy Weight Method,EWM)對氣象數據集中各類數據特征指標進行綜合計算,依據計算得出的信息熵確定其綜合權重,即為氣象信息系統(tǒng)處理某類氣象數據所需占用系統(tǒng)資源的相對比例。某類氣象數據權重值越高,處理時需占用的系統(tǒng)資源越多,則越容易對處理系統(tǒng)的性能造成較大的影響。
近年來隨著大數據挖掘分析的廣泛應用,基于MQ的傳統(tǒng)消息模式難以滿足海量數據實時傳輸處理需求,而流式消息處理中間件Kafka較好地適應了這種需求[17],氣象大數據云平臺[18]、氣象綜合業(yè)務監(jiān)控系統(tǒng)[19]以及湖南高分衛(wèi)星多源數據獲取管理平臺均采用Kafka作為消息中間件。
Kafka處理集群中包含Producer(消息生產者)、Broker(處理節(jié)點)、Consumer(消息消費者)等核心組件。其數據處理流程如圖1所示。
圖1 Kafka數據處理流程
一個Kafka集群可以設計多個Broker服務,每一個Producer以Thread(線程)方式通過PUSH方法將消息發(fā)送至相應的Broker。每一個Broker中又可分為多個Topic(消息主題),分組對消息進行管理。而Partition(消息分區(qū))則是Topic的物理組成,各類消息順序寫入一個或多個Partition中,通過一個或多個Consumer組成ConsumerGroup(消費者群組)以PULL方式順序讀取消息,從而達到讀寫速度O(1)的高性能。
從Kafka數據處理流程分析,可以通過以下方法提升氣象數據并發(fā)處理性能:一是將氣象數據按科學方法進行分區(qū),利用Kafka多Partition的方式提升并發(fā)處理性能;二是設計氣象數據在Kafka生產端的Producer實例池,通過多Thread并發(fā)的方式提升消息寫入性能;三是按業(yè)務需求將氣象數據服務端多個Consumer組合成Group,通過多Thread并發(fā)方式提升消息讀取性能。
依據上述氣象數據綜合權重計算和優(yōu)化Kafka并發(fā)處理性能的思路,設計氣象數據權重算法和分區(qū)策略,流程如圖2所示。
圖2 并發(fā)處理算法流程
首先選取具有代表性的氣象數據集,提取對氣象數據處理所耗費基礎資源相關性較大的關鍵特征,采用熵權法進行綜合權重計算。再以氣象數據關鍵特征綜合權重為分區(qū)處理依據,分別在Kafka中設計相應的Topic、Partition進行分區(qū)處理,并采用多Thread方式并行處理,提升氣象數據處理效率。
從湖南氣候特征分析,每年5月下旬至7月上旬為汛期關鍵時期[20],因此選取湖南省內2020年6月1日至6月30日的氣象數據作為實驗數據集,涵蓋天氣晴朗、陰雨、暴雨等復雜天氣過程。在數據服務需求方面考慮,選取氣象數據處理系統(tǒng)中最具代表性,在氣象預報預警和防災減災中應用廣泛、時效性要求高的數據,包括:國家站觀測數據、區(qū)域站觀測數據、雷達基數據、雷達PUP產品、衛(wèi)星云圖數據等,詳情如表1所示。
表1 氣象數據集詳情
氣象數據集中,國家站數據為BUFR格式傳輸落地所生成的二進制文件(BIN),包括氣溫、風向、風速、降水等觀測要素,傳輸間隔1分鐘;區(qū)域站數據為中心站生成的文本數據(TXT),包括二要素、四要素、六要素等不同類型站點,傳輸間隔5分鐘;雷達基數據為湖南省內11部多普勒天氣雷達標準格式數據(BZ2),傳輸間隔6分鐘;雷達PUP產品包括基本反射率、組合反射率、回波頂高等不同類型產品文件(BIN),傳輸間隔與雷達基數據一致;衛(wèi)星云圖數據選擇常用的FY-2G衛(wèi)星AWX文件,包含紅外、水汽、可見光等要素,傳輸間隔30分鐘。
從表1可以看出:氣象數據集包含數據名稱、數據類型、站點數量、傳輸間隔、文件數、數據量等多種特征指標,不同特征指標的量度差異大,同一特征指標的離散度較高,在數據處理層面,難以從單一特征指標得出科學處理方法。因此,該文采用熵權法計算所有氣象數據關鍵特征指標的綜合權重,再根據綜合權重進行分區(qū),結合Kafka特性提升氣象數據并發(fā)處理性能。
從計算機系統(tǒng)原理以及氣象數據處理流程分析,上述氣象數據集中,影響處理性能的關鍵特征指標為站點數、傳輸間隔、文件數、數據量,而數據名稱、數據類型等描述性信息對計算機系統(tǒng)運行性能不會產生影響。因此,在氣象數據權重算法中,提取站點數量、傳輸間隔、平均數據量(即數據量除以文件數)三個指標參與計算。為同化數據,將傳輸間隔(分鐘)轉化為傳輸頻率(次/小時),形成氣象數據關鍵特征量,如表2所示。
表2 氣象數據關鍵特征量詳情
進行權重計算前,首先要將表2中的氣象數據關鍵特征量進行Normalization(歸一化)處理[21],剔除不同種類氣象數據關鍵特征量的單位度量,將氣象數據關鍵特征量轉化為不包含量綱的純數值,便于進行不同類型或量級的特征量基于客觀權重的綜合評價綜合分析數據處理中常用的各類歸一化方法,Linear Normalization(線性歸一化)[22]在分析各數據變量權重時過分依賴兩個極端值;ZScore Normalization(零均值歸一化)[23]常用于信號處理,需要數據基于正態(tài)分布;Mean Normalization(均值歸一化)[24]采用平均值對數據特征進行縮放,減少數據之間的波動。
該文的目的是計算各類氣象數據關鍵特征量的綜合權重,從而分析其在數據流轉和處理等環(huán)節(jié)所消耗的基礎資源,因此采用Sum Normalization(總和歸一化)[25]方法,得出每一類氣象數據在整個數據處理系統(tǒng)流轉所需耗費系統(tǒng)資源的比例,其過程如下:
(1)通過公式(1)計算氣象數據關鍵特征量的Pij矩陣,用于后續(xù)權重分析。
(1)
式中,i代表氣象數據特征量序號,j代表氣象數據種類序號,n為氣象數據種類總量。經計算,得出上述氣象數據關鍵特征量Pij矩陣為:
(2)通過公式(2)計算每類氣象數據每個關鍵特征量的PijLn(Pij)矩陣Lij。
Lij=PijLn(Pij)
(2)
得出氣象數據關鍵特征量Lij矩陣如下:
(3)基于Lij矩陣,通過公式(3)逐個計算每類氣象數據每個關鍵特征量的信息熵Ej。
(3)
式中,n為氣象數據種類數量,K為常數,根據公式(4)進行計算。
(4)
本例中n=5,得出K值為0.621 334 935。經計算,得出氣象數據關鍵特征量的信息熵Ej,以及信息熵的冗余度(1-Ej)矩陣如下:
(4)通過公式(5)計算每一類氣象數據關鍵特征量在總量中所占的權重Wj。
(5)
計算得出氣象數據Wj矩陣如下:
(5)按公式(6),通過各特征量的權重系數Wj與每類數據對應的特征量相乘,最后按氣象數據類別分別進行求和,得出每類氣象數據的綜合權重值。
(6)
最終得出氣象數據集中各類數據關鍵特征量的綜合權重Sij,如表3所示。
表3 綜合權重
對表3進行分析,五類氣象數據綜合權重分布在三個區(qū)間:最高的區(qū)域站數據權重為1 735.96,最低的雷達PUP產品權重為11.70,五類數據權重均值為527.94。因此需要根據綜合權重合理分區(qū),通過多分區(qū)并行處理的方式減輕單類數據、單一流程占用系統(tǒng)資源過多導致數據堵塞的情況,提升整體數據處理性能,步驟如下:
(1)在Kafka中,為五類氣象數據分別設計一個Topic,便于應用端分類開展數據服務。
(2)依據Kafka數據處理原理,在每類氣象數據所分配的Topic中,最少應分配一個Partition。因此對于綜合權重較低的國家站數據、雷達PUP產品兩個Topic,直接采用單Partition進行分區(qū)。
(3)對于綜合權重最高區(qū)域站數據,其權重達到五類數據權重均值的3.29倍,是最低權重的148.37倍。合理配置其Partition,并優(yōu)化Thread數量,對Kafka集群整體性能至關重要。該文將設計實驗平臺對其不同Partition、Thread數量進行實驗,得出最佳策略。
(4)對權重處于中間區(qū)間的衛(wèi)星云圖、雷達基數據的分區(qū)策略,對比最高和最低分區(qū)數量分別設計。
為找出氣象數據分區(qū)最優(yōu)策略,參考氣象大數據云平臺架構,設計以Kafka為消息中間件的氣象數據處理實驗模型,分別從Producer消息寫入、Consumer消息讀取兩端,通過不同數量的Partition和Thread進行對比實驗,得出最優(yōu)解。
此模型在Kafka Cluster中設計了4個Broker進行分布式處理,模擬氣象大數據云平臺中數據流轉的實際狀況。在Producer端采用并發(fā)寫入設計,針對不同氣象數據輸入場景,分別模擬多個寫入Thread,測試不同Producer Thread數量對Kafka消息寫入性能的影響。在Consumer端則構建了多個Group,模擬多個氣象預報預警服務應用端并發(fā)提取消息的狀況,測試不同的Consumer Thread數量對Kafka消息讀取性能的影響。
支撐模型運行的基礎資源為4臺部署在湖南氣象虛擬化資源池中的虛擬服務器(CPU 8*2.2 GHz,RAM 32 GB),操作系統(tǒng)采用CentOS,部署Kafka作為消息中間件,采用Ngnix實現負載均衡,服務器之間依托1 000 Mbps內網互聯。
按照綜合權重計算結果,選取測試數據集中綜合權重最大的區(qū)域站數據作測試,包含AWS_FTM_PQC格式的文件總數338 640個,數據總量15 460.68 MB。直接采用Kafka本身提供的Producer-Perf-Test和Consumer-Perf-Test工具,分別進行消息寫入和消息讀取的并發(fā)性能測試,從而驗證氣象數據在不同Partition和Thread數量下的并發(fā)處理性能,包括MsgRate(消息并發(fā)量)和DataRate(數據吞吐量)。
3.2.1 Producer端多Partition并發(fā)實驗
首先測試區(qū)域站數據在不同Partition數量下的并發(fā)處理性能。測試方式為:在Producer端通過單Thread寫入測試數據,測試Kafka處理性能變化情況,實驗得出的Kafka消息并發(fā)量和數據吞吐量的性能變化曲線如圖3所示。
圖3 Producer端多Partition并發(fā)性能曲線
從圖3可知:在Producer端寫入消息過程中,隨著Kafka中Partition數量增長,其消息并發(fā)性能和數據吞吐量均隨之增長,在Partition數量為8時達到峰值,隨后其并發(fā)性能隨著Partition數量增長而下降。
實驗得出最優(yōu)Partition數值為8,為實驗平臺的Broker總數量的2倍,此時Kafka并發(fā)處理性能相比單Partition可提升至377.06%。
3.2.2 Producer端多Thread并發(fā)實驗
在實驗得出Producer端最優(yōu)Partition的情況下,進一步測試不同Thread數量對Kafka并發(fā)處理性能的影響,實驗得出的Kafka消息并發(fā)量和數據吞吐量的性能變化曲線如圖4所示。
圖4 Producer端多Thread并發(fā)性能曲線
對圖4進行分析:在Partition為8的情況下,隨著Kafka中Thread數量增長,其并發(fā)處理性能也隨之增長,在Thread數量為30的時候達到最優(yōu),隨后其并發(fā)性能隨著Thread數量增長而下降。
實驗得出最優(yōu)Thread數值為30,排除實驗誤差影響,與實驗平臺中單個Broker的CPU核心數32個一致,此時Kafka并發(fā)處理性能相比單Thread可提升至1 439.69%。
3.2.3 Consumer端多Partition并發(fā)實驗
參照前述Producer端測試過程,繼續(xù)測試Kafka在Consumer端的并發(fā)處理性能。測試方式為:模擬Consumer端從Kafka中讀取已存儲的區(qū)域觀測站測試數據,驗證不同Partition數量下的并發(fā)處理性能,實驗得出的Kafka消息并發(fā)量和數據吞吐量的性能變化曲線如圖5所示。
圖5 Consumer端多Partition并發(fā)性能曲線
通過圖5分析可知:在Consumer端單Thread情況下,Kafka并發(fā)處理性能隨著Partition數量的增長而提升,最優(yōu)Partition數量為8個,與Producer端實驗結論一致。此時Kafka并發(fā)處理性能相比單Partition可提升至350.73%。
3.2.4 Consumer端多Thread并發(fā)實驗
繼續(xù)測試Consumer端不同Thread數量對Kafka并發(fā)處理性能的影響,實驗得出的Kafka消息并發(fā)量和數據吞吐量的性能變化曲線如圖6所示。
圖6 Consumer端多Thread并發(fā)性能曲線
對圖6進行分析:在Consumer端Thread數量增長的情況下,Kafka并發(fā)處理性能有增長,但趨勢不明顯。Thread數量為10、30和50性能提升分別為104.26%、117.48%和122.68%,出現一定邊際效應。
根據實驗結果得出的Kafka最優(yōu)Partition和Thread數量,參照前述氣象數據分區(qū)思路,在所構建的實驗平臺基礎資源支撐條件下,設計五類氣象數據進行分區(qū)處理最優(yōu)策略,如圖7所示。
圖7 氣象數據分區(qū)策略
(1)為綜合權重最高區(qū)域站數據設置8個Partition,采用32個Thread并發(fā)處理,可達到最高處理性能。
(2)參照綜合權重對比,為衛(wèi)星云圖數據設置4個Partition,雷達基數據設置2個Partition,分別設置Thread數量為16和8。
(3)國家站數據和雷達PUP產品流轉處理時,對基礎資源的需求相對較小,分別設置為單Partition和單Thread。
該文的研究成果已應用于湖南高分衛(wèi)星多源數據獲取管理平臺。該平臺基于Spark分布式處理架構,以Kafka為數據處理核心,采用HAProxy以及Nginx實現負載均衡和反向代理,支撐海量氣象數據高負載處理。應用研究成果前,由于氣象觀測及高分遙感數據量大、傳輸頻次高,數據傳輸處理過程出現消息阻塞現象,嚴重影響實時氣象業(yè)務的連續(xù)性和可靠性。經數據分區(qū)和策略優(yōu)化后,平臺并發(fā)連接數峰值達到3 000次/分鐘,數據吞吐量峰值達到550 MB/分鐘,有效解決了消息堵塞現象。平臺運行狀況如圖8所示。
圖8 平臺并發(fā)性能
提出了采用熵權法綜合計算氣象數據多個關鍵特征量綜合權重的算法及流程,得出的綜合權重即為此類數據在氣象數據處理系統(tǒng)中流轉和處理時消耗系統(tǒng)資源所占的相對比重,并將綜合權重作為氣象數據分區(qū)處理的客觀依據,避免主觀因素造成分區(qū)不合理的情況在以Kafka為消息中間件的數據處理平臺中,根據基礎支撐資源狀況,合理設計Partition和Thread數量可以顯著提升并發(fā)處理性能。最優(yōu)Partition數量為數據處理平臺Broker總數量的2倍,最優(yōu)Thread數量與單個Broker的CPU核心數一致。以所構建的包含4個Broker實驗模型為例,在Kafka中Partition和Thread均最優(yōu)的情況下,消息寫入性能從一個Partition和一個Thread的0.69 MB/s提升至37.44 MB/s,提升至5 426.09%,消息讀取性能則從15.65 MB/s提升至67.34 MB/s,提升至430.29%。
基于權重的氣象數據分區(qū)算法和Kafka最優(yōu)處理策略在各類數據處理系統(tǒng)中具有較強的應用價值,但該文的思路及方法基于數據處理系統(tǒng)在設計時所采取的最優(yōu)策略,尚無法根據不同時間、不同季節(jié)對氣象數據需求的重點不同而動態(tài)調整資源配置。后續(xù)將結合人工智能技術,通過機器自動學習歷史數據處理狀況的周期性變化,在一定范圍內動態(tài)調整數據分區(qū)算法和Kafka配置策略,實現更高效的數據處理。