基于Storm的數字信號流式處理平臺的研究與實現

張 保，劉世穎，張華沖，顧 旭，于浩洋

(中國電子科技集團公司第五十四研究所，河北 石家莊 050081)

0 引言

近年來，現代無線通信和頻譜偵察監視領域中電磁環境日益復雜，新體制信號不斷涌現，對電子信息裝備平臺的高效集成、靈活擴展等方面提出了更高的要求；另一方面，為提升電子信息裝備的全空域、全時域和全頻域的多維快速感知能力，要求在線實時或離線處理的數據量越來越大。因此，把硬件作為無線通信的基本平臺，而把數據處理盡可能多地用軟件實現的基于軟件無線電技術的分布式并發處理的新型數字信號處理平臺[1-2]成為了研究熱點。

傳統的數字信號處理平臺中，通過配置大容量存儲，將數據采集存儲于磁盤之中，在處理時，采用將數據批量導出的方式進行離線處理。此種數字信號處理平臺的缺陷在于：① 隨著設備采集能力的提升，數據產生的速度遠高于數據處理的速度，對磁盤存儲能力的要求越來越高，系統設計的硬成本也隨之提升；② 數據離線處理的方式擁有較大的信息情報獲取延遲，而數據本身的價值也隨信息獲取時間的增長而逐步降低。為解決該問題，需建立一套流水線式的數字信號處理平臺[3-5]，能夠以較低的時延處理流式數據，在快速獲取信息情報的同時，減少非必要數據的存儲需求。

Storm[6-7]中間件是一個并行分布式數據流處理框架，適用于處理無邊界的數據流，被廣泛應用于各類數據流處理場景中，具備可擴展、高容錯、與編程語言無關等特性，可以與Kafka[8]、Zookeeper[9]等技術協同工作，構建一套完善的并行分布式數據流處理系統。本文在簡要介紹Storm原理的基礎上，提出了一種基于Storm的數字信號流式處理平臺：基于數字信號處理模塊的功能特性設計獨立的虛擬設備，基于不同體制信號的業務特性設計數字信號處理有向無環圖(DSP-DAG)，將DSP-DAG映射至Storm集群，實現采集數據的流式并行處理。實驗表明，該平臺具有集成效率高、運算速度快、可靠性高和擴展能力強等優點，優于傳統的數字信號處理平臺。

1 Storm分布式流處理框架

大數據具有4個公認的特性：體量(Volume)、速度(Velocity)、多樣性(Variety)和真實性(Veracity)。針對該特性，多種大數據處理工具應運而生，主要包括數據處理、數據傳輸和數據存儲3類。其中，數據處理存在批(Batch)處理和流(Stream)處理2種形式[10]，其模型對比如圖1所示。

圖1 批處理和流處理模型對比Fig.1 Comparison of batch processing and stream processing model

其中，批處理模式下，采集的數據需緩存入固定的數據池中，然后對數據進行分批，數據按既定批次進行處理；批處理的特性在于，所有數據處理流程全部完成之前，無法獲得最終結果。而流處理模式下[2]，數據在流入系統的同時執行處理，分別處理每個事件，該特性適合于持續地處理數據，同時要求這些數據能夠快速產生有效結論的應用場景。

現代無線電磁波通信偵察領域要求對采集數據的處理和感知提出了越來越高的要求，從數據采集、信號處理、變化感知到最終的結果存儲與展示，整個過程要求以盡可能低地延遲完成，為電子信息裝備的情報整編及時提供分析素材。這就要求以實時的流處理技術構建新型的數字信號處理平臺。

Storm集群架構如圖2所示，一個Storm集群包含2種類型的節點：主控結點(Master Node)和工作(Worker Node)結點。其中，主控結點只有一個，而工作結點可以有多個；一個主控結點運行一個守護進程Nimbus，而每個工作結點都分別運行一個守護進程Supervisor；每個工作結點可以運行一到多個工作進程，每個工作進程(Worker)可以擁有一個或多個執行器(Executor)。Nimbus圍繞集群發布代碼，將任務指派給工作節點，并同時監控異常狀態；每個Supervisor通過監聽Nimbus分配到工作結點上的任務去啟動或結束工作進程；每個執行器上運行一個或者多個所分配的計算任務(Task)。

圖2 Storm集群架構Fig.2 Storm cluster architecture

Storm拓撲結構如圖3所示，在Storm集群中運行的每個作業被表示為一個有向無環的拓撲圖(Topology)。其中，每個結點是一個組件，組件有2種類型：Spout組件是數據源，負責生產數據；Bolt組件封裝了數據處理邏輯，可以完成過濾、業務處理、連接運算、連接與訪問數據庫等任何操作。每個組件都含有一個或多個任務(Task)，任務是最小的處理單元。任務之間傳遞的消息由元組(Tuple)構成，是消息傳遞的基本單元；一個無界的元組序列構成流(Stream)。流分組(Stream Grouping)定義消息分發策略，決定了流/元組如何在Spout到Bolt或Bolt之間的任務間進行分發。

圖3 Storm拓撲結構Fig.3 Storm topology structure

Storm具備高度的容錯機制，提交拓撲到集群后，Storm會一直運行拓撲直至其被人為殺死。如果運行過程中某個工作進程發生故障，Supervisor檢測到故障后會嘗試在本機對其進行重啟；如果Nimbus或Supervisor守護進程故障，因其狀態可以保存，在將其重啟后不會對系統任務的運行產生任何影響；如果整個工作結點發生故障，Nimbus監測到錯誤后會以進程調度的方式將該結點上所有的任務轉移至其他可用的工作結點上重新運行。同時，Storm具備高可靠性機制，通過設計一組特殊的Acker任務，對于每個Spout消息元組，跟蹤其在拓撲內的有向無環圖，確保每個來自Spout的消息元組將被完全處理。

2 數字信號流式處理平臺設計

為實現電子信息裝備所采集的流式數據的快速處理，提出了一種基于Storm的數字信號流式處理平臺，與天線、射頻前端和數據采集設備共同構成高速數字信號處理系統，其整體架構如圖4所示。

圖4 高速數字信號處理系統架構Fig.4 Architecture of high speed digital signal processing system

其中，天線、射頻前端和數據采集設備作為采集數據流的生產者，產生的數據以流的形式流入數字信號流式處理平臺；而數字信號流式處理平臺作為采集數據流的消費者，基于虛擬設備技術和數字信號處理有向無環圖(DSP-DAG)構建Storm拓撲作業，由Nimbus和Supervisor守護進程進行調度，在Storm集群上運行；同時，Storm集群可為負載均衡、拓撲作業監控(UI)和數據持久化(DB)等技術提供支撐。

2.1 虛擬設備責任矩陣

廣義的虛擬設備(Virtual Device)是指利用數字計算機技術模擬實現示波器、溫控儀表、數據采集系統和數據信號處理系統等各種傳統設備的計算機系統都可稱為虛擬設備[11]，而本文所討論的虛擬設備是指利用通用計算機/服務器實現數據信號處理[12-15]。

本文提出的基于Storm的數字信號流式處理平臺中所處理的基本單元是由采集數據流構成的計算任務(Task)，而處理計算任務最小的執行單元是最基本的Spout/Bolt組件，即為進行封裝后的可完成獨立功能的軟式虛擬設備實例。

一個完整的數字信號處理流程囊括多種體制信號的處理方式以及各種體制信號的多個處理階段，本文提出的虛擬設備技術旨在依據數字信號處理流程中各功能模塊的獨立特性進行切分，劃分為具有不同功能的虛擬設備，再對各虛擬設備的輸入、輸出接口進行標準化設計與封裝，以構建Spout/Bolt組件。

依據不同體制(常規、突發和擴頻等)信號處理的業務特性可將數字信號處理流程在橫向上切分為常規信號處理、突發信號處理和擴頻信號處理等；依據信號處理階段的功能特性可將數字信號處理流程在縱向上切分為預處理、檢測、信道化、分析、解調、解碼和協議分析等[16]。

Storm平臺中任務之間以元組(Tuple)的形式傳遞消息，元組是一個命名的值列表，其字段所支持的類型包括基本類型、字符串或字符數組，均為較為簡單的對象類數據形式。而數字信號處理虛擬設備間所交互的內容除對象類數據外，還包括文件類數據和庫表類數據。為適應Storm平臺中消息的傳輸要求，需對虛擬設備的輸入、輸出接口進行標準化與封裝設計，如圖5所示，針對不同的數據采用如下3種不同的傳輸方法：

(1) 對象類數據：直接基于通信網絡的方式進行傳輸；

(2) 文件類數據：將文件在磁盤上的存儲路徑組織為對象類數據再基于通信網絡的方式進行傳輸；

(3) 庫表類數據：將庫表名稱及相應字段組織為對象類數據再基于通信網絡的方式進行傳輸。

2.2 DSP-DAG模型

一個流式計算作業及其所處理的一系列任務可以用有向無環圖(DAG)[17]表示，在Storm集群中稱之為拓撲(Topology)。為適應該處理模式，在構建數字信號處理責任矩陣的基礎上，提出了DSP-DAG模型，即可用于數字信號處理的有向無環圖。該模型采用如下構建方法：

(1) 基于不同體制信號處理的業務特性將其信號處理流程中所需的虛擬設備進行串接，構成虛擬設備作業鏈；

(2) 基于負責不同功能模塊的虛擬設備的性能特性為作業鏈中每個作業節點配置虛擬設備實例數量。

基于上述方法完成DSP-DAG模型的構建，某種體制信號DSP-DAG模型的示意如圖6所示。

圖6 某體制信號DSP-DAG模型示意Fig.6 Schematic diagram of DSP-DAG system signal model

流式數據在時間維度上可分解為連續的多個處理子任務，而DSP-DAG模型將各虛擬設備實例組織為流水線，各類虛擬設備并行地執行其對應階段的子任務，同類虛擬設備的不同實例并行地執行其相應階段的子任務，從而達到超標量流水線并行。流水線并行是指將不同的階段任務分配到不同的處理單元(如集群節點以及節點內多核等)上，各處理單元并行的執行階段任務，實現時間上的并行；而超標量流水線并行以空間換時間的方法實現多條流水線的并行[18-21]。

DSP-DAG模型可有效地對流式數據的處理進行并行加速，以圖6中某體制信號的處理為例，定義各階段處理時間如下：

tp：單個信號的預處理時間；td：單個信號的檢測時間；tc：單個信號的信道化時間；ta：單個信號的分析時間；tm：單個信號的解調時間；te：單個信號的解碼時間；to：單個信號的協議分析時間。

為方便進行性能對比，假設圖6為理想化配比模型，在信號處理各階段所產生的數據沒有堆積，即某處理階段在產生一批次數據時，其上一批次的數據已被下個處理階段消耗完畢。設Δt為耗時最長的虛擬設備處理每個子任務所需執行時間，則：

此時，DSP-DAG模型可等同視為度為4的超標量流水線，與度為1的常規單標量流水線對比如圖7所示。

采用串行模型執行時，n(設n=i×4，其中，i為正整數)個計算子任務的總執行時間為：

tSLE=tp+td+tc+ta+tm+te×n+to=11.5Δt,n=8。

采用DSP-DAG模型執行時間，n個計算子任務的總執行時間為：

而2種模型加速比為：

因此，DSP-DAG模型(度為4的超標量流水線)相對于傳統流水線的模式極限加速比為4倍。

基于以上分析，采用DSP-DAG模型可有效對流式數據的處理進行并行加速，且該模型與Storm拓撲能夠實現完美契合，發揮Storm平臺的優勢。

(a) 常規單標量流水線(度為1)

2.3 Storm平臺映射

依據Storm拓撲結構，在Storm集群中運行的每個作業被表示為一個有向無環的拓撲圖(Topology)。而拓撲由消息源Spout組件、處理邏輯Bolt組件，以及組件之間傳遞的消息由Stream/Tuple組成。

為實現DSP-DAG模型到Storm平臺的映射，本文將預處理虛擬設備定義為PreprocessSpout組件，將檢測、信道化、分析、解調、解碼和協議分析等虛擬設備分別定義為DetectBolt、ChannelBolt、AnalyzeBolt、DemodBolt、DecodeBolt、ProtocalBolt組件，將各虛擬設備的輸入、輸出封裝為標準的Stream/Tuple消息，并在構建拓撲時定義各組件并發的數量。DSP-DAG模型到Storm平臺的映射示意如圖8所示。

圖8 DSP-DAG與Storm平臺映射示意Fig.8 Diagram of DSP-DAG and Storm platform mapping

3 驗證與測試

3.1 實驗環境

本文實驗環境基于1臺曙光I620-G20服務器和2臺曙光W620-G20服務器，分別配置了2顆Intel Xeon 12核CPU(E5-2680 V3，2.5 GHz)，128 GB DDR3內存；其中，2臺曙光W620-G20服務器各配置了1顆NVIDIA Tesla K20 m GPU(2 496個CUDA Core，4 800 MB顯存)，用于實現部分應用性能的加速；服務器之間采用萬兆交換，數據存儲于1臺DS600磁盤陣列。

服務器安裝了中標麒麟v6.5操作系統，內置Storm應用環境及本實驗所需的其他依賴軟件庫，具體如下：

JDK版本：jdk.1.8.0_91

Maven版本：apache-maven-3.6.0

Storm版本：storm-1.2.3

Kafka版本：kafka-2.3.1-incubating-src

Zookeeper版本：zookeeper-3.5.6

Python版本：Python-2.7.3

CUDA版本：CUDA Toolkit V7.5

3.2 測試應用

本實驗選用常規體制衛星信號的自動普查應用進行測試，實驗進行3輪，數字信號處理的對象分別為1 000，2 000和3 000組采樣數據文件，數據中含頻分多址和時分多址信號，數字信號處理的目的是獲得信號的詳細特征參數和調制方式。其中，為方便實驗對比，每組數據文件采樣率fs為500 Ms/s，采樣深度為16 bit，采樣時長為8 ms，采集帶寬200 MHz；數據為仿真生成，每組數據中包含5個調制方式為BPSK的頻分多址信號(符號速率Rs均為10 Ms/s)和5個調制方式為QPSK的時分多址信號(符號速率Rs均為2 Ms/s)。

基于頻分和時分多址信號的處理的業務特性，將其處理過程設計為數據預處理、寬帶信號檢測、多信號分割、非均勻信道化、通信體制識別、FDMA信號特征參數估計和TDMA信號特征參數估計等7個虛擬設備，基于本文描述的DSP-DAG模型的構建方法，搭建本測試應用的數據信號處理拓撲圖，依據以下步驟，推算過程如表1所示，搭建本測試應用的數據信號處理拓撲圖如圖9所示，等同于度為68的超標量流水線。

圖9 常規體制衛星信號的自動普查拓撲圖Fig.9 Automatic general investigation topological graph of conventional system satellite signals

表1 常規體制衛星信號的自動普查拓撲圖構建過程表Tab.1 Automatic general investigation topological graph construction process table of conventional system satellite signals

注：3臺曙光服務器共計72核，可同時運行144線程，為保證服務器系統運行，分配每服務器2個線程用于系統的監控運行，即虛擬設備可用138線程，因此調整因子factor為：factor=∑vi/138；則每虛擬設備實例可用配置va為：va=vi/factor。

(1) 統計各虛擬設備單任務處理所需時長；均采用曙光W620-G20服務器進行多次測量取平均值；

(2) 統計各虛擬設備所有任務處理所需總時長；

(3) 計算理想配比條件下，各虛擬設備所需配置實例個數；

(4) 依據當前實際測試環境，基于可同時運行總線程數計算調整因子，計算虛擬設備可配置實例個數；

(5) 各虛擬設備可配置實例進行歸整計算。

3.3 測試結果與分析

測試結果如圖10所示。

圖10 常規體制衛星信號的自動普查任務處理性能對比圖Fig.10 Comparison chart of automatic general investigation task processing performance of conventional system satellite signals

實驗結果表明，采用DSP-DAG超標量流水線進行加速后，處理速度有了明顯提升，數據文件在1 000組以上時，相對常規單標量流水線處理方式性能提高了31倍以上。且隨著處理總任務量的提升加速比逐步提高，但加速比趨勢逐步降低，具體如圖11所示。

圖11 常規體制衛星信號的自動普查任務加速比趨勢圖Fig.11 Trend chart of acceleration ratio of automatic general investigation task for conventional system satellite signals

實驗結果表明，針對本應用設計的數據信號處理拓撲圖，可有效提升處理性能。但該拓撲圖采用度為68的超標量流水技術，理論加速比可達到68倍，鑒于測試結果加速比小于理論加速比的情況，分析原因包括兩方面內容：① 總任務量有限，隨著任務量的提升加速比會逐步提高，但會趨于一個平衡；② 處理線程的增加，增加了一定的通信開銷，在一定程度上阻礙了處理性能的提升，且大量線程對磁盤的并發讀寫也是影響性能的主要瓶頸。

4 結束語

在介紹流處理技術和Storm原理的基礎上，提出了一種基于Storm的數字信號流式處理平臺。結合不同體制信號處理的業務特性，及信號處理過程中各階段的功能特性，構建虛擬設備責任矩陣；基于超標量流水線并行原理，將各類虛擬設備串接處理某種體制信號的作業鏈，構建DSP-DAG模型；將虛擬設備映射為Storm平臺的Spout/Bolt組件，將DSP-DAG映射為Storm平臺的Topology，最終實現基于Storm的數字信號流式處理平臺。實驗結果表明，提出的DSP-DAG數字信號處理模型可有效提高應用的整體性能。

同時，在基于集群進行分布式計算時，集群中各節點間的互聯網絡以及磁盤等環境，均會對應用性能產生影響，因此，后續研究集群環境布設、處理線程間的通信效率和對磁盤的讀寫速率等對應用的并發改善仍具有重要的意義。