張人愉，李景山

(1.中國科學院遙感與數(shù)字地球研究所，北京 100094；2.中國科學院大學，北京 100049)

0 引言

衛(wèi)星基帶數(shù)據(jù)的處理是衛(wèi)星地面處理系統(tǒng)的起始部分，負責衛(wèi)星下傳數(shù)據(jù)的幀同步、解擾、譯碼、解格式和解壓縮等步驟，為后續(xù)的產(chǎn)品生產(chǎn)提供基礎數(shù)據(jù)[1]?，F(xiàn)今隨著衛(wèi)星遙感技術(shù)和計算技術(shù)的不斷發(fā)展，每年都有大量遙感衛(wèi)星發(fā)射，衛(wèi)星遙感技術(shù)也向著高空間分辨率和高光譜分辨率的方向發(fā)展[2]。衛(wèi)星傳感器產(chǎn)生的遙感數(shù)據(jù)量不斷增大，星上數(shù)據(jù)的下傳碼速率也隨之不斷增大。如當前我國主流的高分辨衛(wèi)星高分1號、2號和資源三號1、2星等衛(wèi)星的數(shù)傳碼速率為雙通道450 Mbps，要實現(xiàn)實時的數(shù)據(jù)處理，即地面基帶數(shù)據(jù)處理系統(tǒng)要有900 Mbps以上的處理能力。對處理衛(wèi)星下傳數(shù)據(jù)的地面基帶數(shù)據(jù)處理系統(tǒng)而言，由于其處理過程需要的步驟較多，且解壓縮部分計算又過于復雜，這樣造成了系統(tǒng)設計的兩個主要難點，一是對設計出具有通用性和擴展性的處理系統(tǒng)提出了更高的要求，二是在處理速度上要達到實時快速處理必須設計高效的解壓縮處理策略。

針對衛(wèi)星地面基帶數(shù)據(jù)處理中的難點，已有人對此進行過一些探討設計，比較有代表性的如何芳等[3]介紹一種基于刀片式服務器的遙感衛(wèi)星基帶數(shù)據(jù)處理系統(tǒng)平臺，以建立滿足國內(nèi)遙感衛(wèi)星基帶數(shù)據(jù)處理系統(tǒng)的通用平臺為目標而確立。楊甲森等[4]針對衛(wèi)星地面應用系統(tǒng)支持多星多任務的運行控制需求，通過采用調(diào)度中心與處理程序集協(xié)同的工作方式，借鑒Hadoop MapReduce的框架設計思路，設計了衛(wèi)星基帶數(shù)據(jù)實時處理系統(tǒng)，且實踐表明在萬兆網(wǎng)鏈接的10臺計算機機群上，能實現(xiàn)對3個地面站接收的4顆衛(wèi)星的實時及事后2種模式的數(shù)據(jù)處理任務，處理的實時數(shù)據(jù)碼率優(yōu)于150 Mbit/s。劉莉[5]針對高速率衛(wèi)星遙感數(shù)據(jù)實時處理的要求，設計了一種衛(wèi)星遙感數(shù)據(jù)實時處理平臺，其平臺采用分層設計思想，自上而下分為表現(xiàn)與控制層、業(yè)務處理層、基礎服務層和應用支持層，結(jié)合消息傳遞接口(MPI)技術(shù)，構(gòu)建了分布式實時并行處理平臺框架。

雖然有不少關于遙感衛(wèi)星基帶數(shù)據(jù)處理系統(tǒng)的研究工作，不過在對系統(tǒng)的設計上大都較為宏觀，較少涉及內(nèi)部算法的具體細節(jié)。在系統(tǒng)的通用性和可擴展性設計上，有將基帶數(shù)據(jù)的每個處理過程獨立設計成小程序然后組合調(diào)用的模式，和將每個過程設計成動態(tài)庫調(diào)用的形式，較少研究外部配置文件能否實現(xiàn)通用性的文章，而外部配置的方式能最大程度實現(xiàn)代碼的重用，無須給每一個衛(wèi)星重新去實現(xiàn)單獨的小程序。在計算復雜的解壓縮的處理上，大多按虛擬信道號提取AOS(高級在軌系統(tǒng))幀中數(shù)據(jù)，然后按照有效載荷分發(fā)到不同計算節(jié)點上進行處理，這種方式存在計算資源浪費的問題，不同載荷數(shù)據(jù)處理按節(jié)點進行了分離，使得在處理一個載荷時，另外載荷的計算節(jié)點處于等待狀態(tài)，這不利于解壓縮的快速處理。而使用MPI+OpenMP結(jié)合的方式用于基帶數(shù)據(jù)的解壓縮則能解決上述計算資源浪費的問題，而且得益于MPI在分布式計算上的優(yōu)勢，在計算節(jié)點的擴展上也十分便利。

本文在研究和借鑒高性能遙感衛(wèi)星數(shù)據(jù)地面處理系統(tǒng)機群解決方案設計[6]的基礎上，設計并實現(xiàn)了通用的基于高性能機群的衛(wèi)星基帶數(shù)據(jù)并行處理算法。該算法在充分分析不同衛(wèi)星在各處理步驟中的差異性后，基于外部配置文件的方式和軟件設計模式的思想進行了通用性和可擴展性設計；同時針對計算復雜的解壓縮部分，在合理設計壓縮數(shù)據(jù)的劃分策略和并行處理策略的基礎上，實現(xiàn)了計算負載均衡的MPI+OpenMP的二級并行處理。

1 算法設計與實現(xiàn)

遙感衛(wèi)星基帶數(shù)據(jù)處理是以實時基帶數(shù)據(jù)碼流或事后基帶數(shù)據(jù)文件為處理對象，經(jīng)幀同步、解擾譯碼、AOS幀格式解析分包和解壓縮等處理，生成初級產(chǎn)品的過程。該過程如圖1所示。

圖1 遙感衛(wèi)星地面基帶數(shù)據(jù)處理流程

本文設計的通用遙感衛(wèi)星基帶數(shù)據(jù)二級并行處理算法在功能上具有如下指標：

①能配置輸入源為網(wǎng)絡或本地文件。

②能夠?qū)鶐?shù)據(jù)進行幀同步，準確提取幀同步字，對傳輸過程中出現(xiàn)的幀頭滑位等錯誤進行糾正。

③能夠?qū)⒓訑_的數(shù)據(jù)區(qū)域進行解擾，能配置擾碼起始狀態(tài)參數(shù)。

④對解擾后數(shù)據(jù)進行譯碼處理，能實現(xiàn)常見糾錯編碼如RS碼和LDPC碼的配置。

⑤對譯碼處理后的數(shù)據(jù)進行AOS幀格式解析，提取有效數(shù)據(jù)域，根據(jù)虛擬信道號進行數(shù)據(jù)分離。能通過配置AOS幀參數(shù)來實現(xiàn)不同衛(wèi)星的處理。

⑥對各信道數(shù)據(jù)進行快速解壓縮，能使用高性能計算技術(shù)最大程度地使用計算資源。

⑦拼接解壓縮后數(shù)據(jù)，解析相機輔助數(shù)據(jù)，生成特定格式產(chǎn)品。

1.1 總體設計

本文設計的算法重點主要體現(xiàn)在兩個方面，一個是通用性和可擴展性，一個是處理速度。這兩個方面在遙感衛(wèi)星基帶數(shù)據(jù)處理中是難點。當前衛(wèi)星數(shù)量不斷增加，各衛(wèi)星使用技術(shù)上存在差別，要實現(xiàn)通用和可擴展處理具有難度，而遙感衛(wèi)星下傳碼速率也不斷上升，對基帶數(shù)據(jù)處理的速度要求也越來越高，要實現(xiàn)快速實時的處理難度也很大。但是如果能解決這兩方面的問題，意義是重大的，解決通用性和可擴展性可以對新發(fā)射的衛(wèi)星進行快速部署處理，解決處理速度問題就可以應對未來下傳碼速率的不斷提高，實現(xiàn)遙感衛(wèi)星數(shù)據(jù)的實時處理，所以良好的通用性與可擴展性，和快速實時處理基帶數(shù)據(jù)就是本文算法想要達到的效果。

對于通用性和可擴展性的設計本文使用了外部配置和軟件模式相結(jié)合的方式。使用外部配置來達到通用處理的方式是最簡單方便的方式，因為該方式無需對程序代碼進行任何形式的修改即可實現(xiàn)新衛(wèi)星的擴展。某些不能通過外部配置實現(xiàn)擴展的，可以使用合理的軟件設計模式，使代碼最大程度上實現(xiàn)重用，同時對原有代碼的改動達到最小。本文在設計通用性和可擴展性方面，結(jié)合了資源三號1、2號星和高分1、2號衛(wèi)星的地面處理系統(tǒng)接口規(guī)范，對其中使用的技術(shù)、數(shù)據(jù)編排規(guī)范等進行了充分了解，總結(jié)出整個處理過程中能通過配置實現(xiàn)擴展的部分和需要編程解決擴展的部分，最大程度達到主流通用可擴展。

在處理速度方面，本算法選擇了MPI+OpenMP相結(jié)合的并行編程模型。當前并行編程模型中消息傳遞模型仍是大規(guī)模并行編程主流，MPI作為消息傳遞編程模型事實上的工業(yè)標準，設計方便分布式計算，具有程序性能高、擴展性好的特征[7]。OpenMP是面向共享存儲系統(tǒng)的主要并行編程模型和事實上的工業(yè)標準，它具有編程簡單、可移植性好等優(yōu)點[8]。本文算法使用MPI和OpenMP相結(jié)合的方式進行并行編程，能將二者的優(yōu)勢進行結(jié)合，MPI可以方便地進行計算節(jié)點間分布式計算編程，OpenMP方便節(jié)點內(nèi)部共享內(nèi)存并行計算。本文算法中選取基帶數(shù)據(jù)處理過程中計算量最大的解壓縮部分進行重點的兩級并行設計，對于其他處理步驟，由于計算量相對解壓縮而言小的多，所以只使用了線程級別的并行處理即可滿足處理的要求。

基于上面的設計原則和思路，本文算法的整體結(jié)構(gòu)設計如圖2所示。

圖2 算法整體結(jié)構(gòu)設計

1)在計算節(jié)點1上進行數(shù)據(jù)的接收、幀同步、解擾、譯碼和AOS幀格式解析操作，為使處理速度更快，數(shù)據(jù)的接收同步放在一個單獨的線程進行處理，解擾和譯碼通過OpenMP進行并行化處理，AOS幀格式解析和分包發(fā)送放在一個線程上處理，這3個部分之間通過2個線程安全的數(shù)據(jù)隊列進行數(shù)據(jù)傳遞，數(shù)據(jù)接收、幀同步和解擾譯碼形成一種生產(chǎn)者-消費者模式，同時解擾譯碼和AOS幀格式解析同樣形成生產(chǎn)者-消費者的模式。計算節(jié)點1上各虛擬通道的數(shù)據(jù)最終通過IB高速網(wǎng)絡發(fā)送到計算節(jié)點2。

2)在計算節(jié)點2上為每個虛擬信道數(shù)據(jù)的接收和解析壓縮塊開辟一個線程，解析得到的通用壓縮塊數(shù)據(jù)放入待解壓縮隊列中等待處理。計算復雜的解壓縮部分通過MPI進行多個節(jié)點間進程級別的并行計算，每次計算以計算節(jié)點的倍數(shù)個壓縮塊進行分配，保證計算任務的均衡分配，在節(jié)點的內(nèi)部通過OpenMP進行線程級別的并行處理。數(shù)據(jù)在解壓縮之后的拼接寫入放在一個單獨的線程進行處理。

3)在解壓縮計算節(jié)點上只實現(xiàn)單純的解壓縮功能，合理設計的通用解壓縮塊數(shù)據(jù)作為節(jié)點上處理的基本單位，而節(jié)點內(nèi)部可將通用解壓縮塊數(shù)據(jù)分為若干基本壓縮單元，利用OpenMP對基本壓縮單元進行并行處理，然后發(fā)送回計算節(jié)點2。

整個處理流程中的數(shù)據(jù)以一種類似流的方式在各個處理步驟間流動，在計算量大的步驟通過多線程技術(shù)和并行處理技術(shù)來增加計算資源，使之快速處理，使整個處理過程中各部分之間的等待時間盡可能的短，從而充分利用計算資源。如在解擾和譯碼部分計算量相對較大，本文算法通過OpenMP將其處理進行了并行化，并行使用的線程數(shù)目維護一個最小值和最大值，根據(jù)實際的處理情況線程在最大最小值之間浮動，實現(xiàn)動態(tài)的計算負載均衡，具體的線程增減策略通過對其前后的數(shù)據(jù)隊列大小進行監(jiān)控設置，當幀同步后的隊列處于較滿的時候，動態(tài)增加2個線程給解擾和譯碼部分，幀同步后隊列處于快空的時候，動態(tài)減少2個線程，但增減范圍都在最大最小值之間。計算量最大的解壓縮部分通過MPI+OpenMP的二級并行進行處理，該部分是整個處理系統(tǒng)中性能的關鍵點，具體的處理策略將在后面單獨進行說明。

1.2 算法通用性設計與實現(xiàn)

整個處理過程中通用性設計是本文一個重要探討的主題，整體設計思路是通過外部的配置文件加上內(nèi)部使用軟件設計模式思想實現(xiàn)。通用性設計的關鍵是對整個處理過程中的處理步驟在不同衛(wèi)星中的異同加以分析，合理設計配置文件參數(shù)，達到在不修改或極少修改原有代碼的基礎上實現(xiàn)新衛(wèi)星數(shù)據(jù)的處理。能通過配置文件配置的部分，主要是針對AOS幀格式解析，分析好AOS幀格式后基本能實現(xiàn)幀同步到AOS分包過程中的通用性設計；在使用軟件設計模式的部分，通過模板方法和工廠模式來實現(xiàn)，主要步驟在通用壓縮塊的解析、壓縮算法的選擇和最后拼接存檔部分。以下將就上面2種方式的具體細節(jié)設計和實現(xiàn)進行更詳細的說明。

1)通用AOS幀格式解析。在設計之初考慮到CCSDS高級在軌系統(tǒng)(AOS)標準已成為世界航天飛行器空間數(shù)據(jù)系統(tǒng)的新一代技術(shù)體系標準，并被絕大多數(shù)的空間組織和國家所采納[9]，我國現(xiàn)今的主流衛(wèi)星基本上都采用這一標準進行數(shù)傳系統(tǒng)的數(shù)據(jù)組織格式，如資源三號系列和高分系列衛(wèi)星都遵循該標準，所以本算法的通用性設計主要針對遵循CCSDS高級在軌系統(tǒng)標準的衛(wèi)星進行。一個典型的AOS幀數(shù)據(jù)格式如圖3所示。

信道編碼/加擾區(qū)/譯碼校驗區(qū)/CRC校驗區(qū)格式編排同步字VCDU主導頭版本號VCDU標識符航天器標識虛擬信道標識VCDU計數(shù)器信號域回放標識備用域VCDU插入?yún)^(qū)VCDU數(shù)據(jù)BPDU導頭BPDU位流數(shù)據(jù)區(qū)VCDU差錯控制域譯碼校驗符號域

圖3 AOS幀數(shù)據(jù)格式

從幀同步到AOS幀格式解析分包過程中，幀同步準確地提取遙感衛(wèi)星下行數(shù)據(jù)流中的幀同步字，獲取正確的幀結(jié)構(gòu)，而后的幾個步驟的處理都是以幀為基本單位進行處理，所以對幀結(jié)構(gòu)的通用化是實現(xiàn)這一部分通用化的關鍵。在圖3中描述的幀數(shù)據(jù)格式中，整個幀的數(shù)據(jù)以同步字起始，該同步字經(jīng)過一定的處理用于幀同步，加擾區(qū)的數(shù)據(jù)需要進行解擾操作，譯碼校驗區(qū)需要進行相應的譯碼處理，CRC校驗區(qū)要進行CRC校驗，在AOS幀格式解析分包處理中主要需要解析虛擬信道標識、VCDU計數(shù)器和VCDU數(shù)據(jù)單元，將對應虛擬信道中的BPDU位數(shù)據(jù)流進行提取，得到壓縮的圖像數(shù)據(jù)和輔助數(shù)據(jù)。通過分析AOS幀數(shù)據(jù)格式，本文設計了用于配置AOS幀格式的外部配置文件，該配置文件能描述AOS幀中的各項參數(shù)以及參數(shù)的位置。以下使用資源三號2星正視相機虛擬信道號的設置格式進行說明，AOS幀中的其他參數(shù)的設置具有類似結(jié)構(gòu)：

5

用于表示該參數(shù)在AOS幀數(shù)據(jù)中相對幀起始位置的偏移字節(jié)，是位比特掩碼，用于提取該參數(shù)在字節(jié)中的實際有效位，所有的參數(shù)提取都需要使用這2個參數(shù)進行基本定位。在虛擬信道的設置上可以根據(jù)具體衛(wèi)星設置不同數(shù)目的虛擬信道，即參數(shù)可以動態(tài)設置多個，標識了虛擬信道的名字，標識了使用十六進制表示虛擬信道的具體信道號。在程序內(nèi)部讀取使用時，在幀中定位到參數(shù)字節(jié)位置，使用掩碼與讀取的數(shù)據(jù)進行與操作，再與中的值進行對比即能得出該幀數(shù)據(jù)是否屬于該虛擬信道，遍歷所有虛擬信道號直到找到匹配的虛擬信道號，就將該幀的VCDU計數(shù)器和BPDU數(shù)據(jù)域提取出來放入對應虛擬信道的緩存中，準備根據(jù)VCDU計數(shù)器進行排序后將數(shù)據(jù)發(fā)送出去。

2)解壓縮的通用性設計。本文在解壓縮的通用性設計上主要使用軟件設計方法中模板方法和工廠模式方法，以及設置合理的通用數(shù)據(jù)結(jié)構(gòu)。模板方法模式通過定義抽象的函數(shù)接口，使子類可根據(jù)自身情況進行方法的實現(xiàn)，在使用時結(jié)合工廠模式能很好地達到易擴展的目的。在衛(wèi)星數(shù)據(jù)解壓縮的通用性設置上，將數(shù)據(jù)的具體解碼分為了3個層，1個是解碼器的抽象層，規(guī)定了解碼類需要實現(xiàn)的具體接口，然后是具體解碼器算法選擇層，該層實現(xiàn)具體的解碼算法，如資源三號即實現(xiàn)JPEGLS解碼算法，衛(wèi)星層主要用于具體衛(wèi)星的解碼算法選擇，不同衛(wèi)星即使在壓縮數(shù)據(jù)上使用相同的壓縮算法，但實際具體實現(xiàn)時具有一定的差異，衛(wèi)星層很好地解決了該問題。工廠模式通過衛(wèi)星標識選擇對應衛(wèi)星解碼器實例，新增衛(wèi)星時，通過實現(xiàn)具體衛(wèi)星層類，將衛(wèi)星加入工廠模式即可實現(xiàn)可擴展。通用解碼器類關系圖設計如圖4所示。

圖4 壓縮數(shù)據(jù)的解碼器類關系圖

模板方法和工廠方法的使用可使得解壓縮算法擴展性變得容易，當需要處理一個新衛(wèi)星的數(shù)據(jù)，只要實現(xiàn)該衛(wèi)星自己的解碼器接口，然后將新的衛(wèi)星解碼器加入工廠類即可。除了在解碼器的實現(xiàn)上使用了模板方法和工廠類，在解壓縮后的數(shù)據(jù)拼接和存儲上同樣使用了相同的思想，不同衛(wèi)星通過繼承拼接寫入基類實現(xiàn)自己的拼接邏輯，從而使拼接寫入具有易擴展性。

在整個解壓縮的通用性設計上通用的數(shù)據(jù)結(jié)構(gòu)同樣起著十分重要的作用，有了通用的解壓縮結(jié)構(gòu)，使得在解析AOS分包后的圖像數(shù)據(jù)和輔助數(shù)據(jù)上變得容易，同時解壓縮邏輯上也變得更加清晰，無需為不同的虛擬信道數(shù)據(jù)進行單獨的處理，所有數(shù)據(jù)放入同一個處理隊列中，非常便于進行分布式并行處理，且利于計算資源的負載均衡。在得出通用解壓縮數(shù)據(jù)結(jié)構(gòu)之前，需要分析一般衛(wèi)星壓縮數(shù)據(jù)和輔助數(shù)據(jù)的編排格式。本文通過分析資源三號1、2星和高分1、2號衛(wèi)星的壓縮數(shù)據(jù)和輔助數(shù)據(jù)編排格式，最后得出了通用的壓縮數(shù)據(jù)塊結(jié)構(gòu)。圖5為資源三號1星正視相機的數(shù)據(jù)編排格式。

圖5 資源三號1星正視相機壓縮數(shù)據(jù)編排格式

在分析資源和高分衛(wèi)星的過程中，發(fā)現(xiàn)所有這些衛(wèi)星在編排數(shù)據(jù)的時候基本使用一致的格式編排，數(shù)據(jù)劃分以幅為大單位，幅的下面分為塊，塊的下面分為輔助數(shù)據(jù)和小的壓縮單元。所以本算法設計了如圖6所示的通用壓縮數(shù)據(jù)塊結(jié)構(gòu)，用于放入解壓縮處理隊列中進行分布式并行解壓縮。

圖6 通用解壓縮塊數(shù)據(jù)結(jié)構(gòu)

通用壓縮塊數(shù)據(jù)結(jié)構(gòu)的設計解決了同一衛(wèi)星中不同虛擬信道數(shù)據(jù)必須分開處理的問題，現(xiàn)在所有虛擬通道的數(shù)據(jù)遵循該結(jié)構(gòu)進行解析就能無差別地放入解壓縮處理隊列。解壓縮處理完成后的數(shù)據(jù)同樣使用該結(jié)構(gòu)儲存，只是壓縮數(shù)據(jù)變?yōu)榱艘呀?jīng)解壓縮后的數(shù)據(jù)，進行拼接的時候能根據(jù)虛擬信道號放入不同的隊列，然后根據(jù)幅序號和塊序號拼接數(shù)據(jù)還原圖像。

1.3 并行解壓縮

數(shù)據(jù)解壓縮的過程在整個基帶數(shù)據(jù)處理中屬于計算最復雜的部分，也是本文算法的一個核心部分，通常一臺機器遠遠不能滿足快速解壓縮的要求，所以本算法使用多臺機器進行分布式計算，利用MPI進行計算節(jié)點間進程級別的并行，在計算節(jié)點內(nèi)部使用OpenMP進行線程級別的并行，整個并行解壓縮的流程如圖7所示。

圖7 MPI+OpenMP的并行解壓縮框架圖

從上一小節(jié)中可知，本文設計的通用壓縮塊數(shù)據(jù)結(jié)構(gòu)大大方便了解壓縮的分布式并行處理，本節(jié)說明的解壓縮并行處理算法就是以該通用壓縮塊數(shù)據(jù)結(jié)構(gòu)隊列為數(shù)據(jù)的輸入，經(jīng)過MPI將壓縮塊數(shù)據(jù)發(fā)送到各計算節(jié)點進行粗粒度的并行處理，在計算節(jié)點內(nèi)部，壓縮塊內(nèi)部的壓縮單元通過OpenMP在線程級別上進行細粒度的并行處理，處理完成的數(shù)據(jù)通過MPI重新發(fā)送回源節(jié)點，然后將數(shù)據(jù)以塊的方式放入拼接類，在拼接類中維護有多個隊列用于存放各虛擬信道數(shù)據(jù)，當數(shù)據(jù)隊列滿足拼接需求時，對數(shù)據(jù)進行拼接寫入。

本文的并行解壓縮算法在理論上具有計算資源接近0等待的優(yōu)點，只要前面步驟一直在處理數(shù)據(jù)，解壓縮隊列中就持續(xù)有數(shù)據(jù)進入，那么并行解壓縮就會持續(xù)進行，用于計算的節(jié)點就會全部處于計算運行狀態(tài)，直到解壓縮隊列為空。區(qū)別于將特定虛擬信道數(shù)據(jù)發(fā)送到特定節(jié)點進行處理的策略，一旦在某些時刻一些信道的數(shù)據(jù)較少，那么處理這些較少數(shù)據(jù)信道的節(jié)點會存在資源等待，從而出現(xiàn)計算資源的浪費。本算法設計的二級并行解壓縮很好地解決了這個問題。

2 實驗驗證分析

本文以資源三號1星在2017年5月30日由喀什站接收的軌道號為029922的2個通道的基帶數(shù)據(jù)作為實驗數(shù)據(jù)，算法處理程序運行在有5臺機器組成的機群服務器上，每臺服務器配置2顆4核的Intel Xeon E5620處理器和24 GB內(nèi)存，服務器之間通過帶寬20 Gbps的IB高速網(wǎng)絡連接，實驗數(shù)據(jù)存儲在服務器內(nèi)部署的lustre并行文件系統(tǒng)之上。實驗中共使用5個節(jié)點，1個節(jié)點用于幀同步到AOS幀格式解析，其余4個節(jié)點用于并行解壓縮和數(shù)據(jù)拼接寫入。將MPI并行進程數(shù)設置為4，OpenMP線程數(shù)設置為16，使計算資源最大化，得出測試結(jié)果如表1所示。

表1 資源三號1星解壓縮實驗測試結(jié)果

由實驗結(jié)果可知本文的處理算法具有較好的處理速度，滿足了資源三號1星雙通道450 Mbit/s下傳碼速率實時處理的要求，解壓縮輸出的數(shù)據(jù)率達到了4.8 Gbps。將輸出的解壓縮后圖像數(shù)據(jù)截取10 240行，得到圖像如圖8所示。

圖8 資源三號1星的解壓縮結(jié)果影像

在實驗中對并行解壓縮部分進行了并行加速比的測試，加速比S的定義如公式(1)[10]所示，為并行處理時間除以串行處理的時間。測試數(shù)據(jù)使用單通道1的數(shù)據(jù)進行，整個測試分為三個部分，一是測試MPI在節(jié)點間的并行加速比，二是測試OpenMP在節(jié)點內(nèi)部線程級別的加速比，三是將MPI和OpenMP結(jié)合起來測試加速效果。

(1)

首先對解壓縮進行了節(jié)點間MPI的并行實驗，實驗的過程中每次將節(jié)點數(shù)目遞增，節(jié)點內(nèi)部線程數(shù)目設置為1，來查看單純的MPI的并行處理的加速效果，實驗結(jié)果如表2所示。

表2 MPI并行實驗結(jié)果

從表2中可以看出，隨著節(jié)點數(shù)目的增加，解壓縮時間能明顯減少，通過計算并行加速比，能更加直觀地得出并行加速的效果，圖9展示了MPI并行加速比與理想加速比之間的差別。在實際中由于網(wǎng)絡帶寬等因素的影響，MPI并行處理的加速比不可能達到理想效果，不過本文實驗中由于節(jié)點數(shù)較少，MPI加速效果還是處于比較理想的狀態(tài)。

圖9 MPI節(jié)點間并行加速比

然后對OpenMP在節(jié)點內(nèi)部線程級別并行進行測試實驗，保持整個測試在一個節(jié)點上進行處理，依次改變節(jié)點內(nèi)線程的數(shù)目，得出的實驗結(jié)果如表3所示。

表3 OpenMP并行實驗結(jié)果

節(jié)點內(nèi)部的OpenMP實現(xiàn)線程級別的并行，從結(jié)果可以看出，隨著線程數(shù)量的增加解壓縮時間能明顯減少，通過計算并行加速比，可以得出圖10所示加速比結(jié)果圖。

圖10 OpenMP并行實驗加速比

在OpenMP的并行實驗中，加速比直線并沒有按照較理想的加速比進行增長，一是OpenMP在每次并行處理時需要進行一些線程的初始化工作，二是由于并行處理時不同基本壓縮單元的處理時間不一定相同，這會導致一些無法避免的線程等待，影響并行效果。而圖10中在線程數(shù)為6時出現(xiàn)加速比向下波動的情況，是由于資源三號的通用壓縮塊結(jié)構(gòu)由16個基本壓縮單元組成，當線程數(shù)能整除16時，并行能實現(xiàn)資源的負載均衡，一旦線程數(shù)不能整除16時，那么會存在一定的線程間等待，影響并行效果，這也為本文調(diào)優(yōu)OpenMP并行線程數(shù)目提供一些借鑒，即將OpenMP的并行線程數(shù)設置為能整除通用壓縮塊結(jié)構(gòu)中基本壓縮單元數(shù)目的值。

最后，將MPI和OpenMP進行結(jié)合進行實驗，保持每個計算節(jié)點內(nèi)部8個線程并行，而計算節(jié)點的數(shù)目不斷增加，最終得出表4所示結(jié)果。

表4 MPI+OpenMP并行實驗

為直觀分析加速效果，將實驗結(jié)果的并行加速比與理想線性加速比進行對比作圖，得出圖11所示結(jié)果。

圖11 MPI+OpenMP并行實驗結(jié)果

從并行加速比的結(jié)果圖中可知，當并行的CPU核數(shù)增加到一定程度時，并行加速比增長將趨于平緩。造成這個現(xiàn)象的原因有很多，如網(wǎng)絡傳輸速度和延遲、OpenMP的線程創(chuàng)建開銷、CPU的調(diào)度、數(shù)據(jù)的復制和并行處理的壓縮塊之間的差異等。本文另外做了個小實驗，通過屏蔽解壓縮的解碼計算過程，即直接將解碼后的數(shù)據(jù)填充0值，保證了相同大小的數(shù)據(jù)量，但沒有解碼的計算過程，來單純的看除并行解碼計算之外的耗時。在4個節(jié)點的情況下，不管單節(jié)點的線程取1到16的任何值，所需耗時都在80±2s，在4節(jié)點8線程解壓縮時，這部分的耗時占比達到了47%左右，而這部分耗時是很難通過增加計算節(jié)點和線程數(shù)來減少的，所以表現(xiàn)上就是解壓縮單純的解碼計算的時間隨著節(jié)點和線程數(shù)的增加而減少，但解碼之外的耗時的占比卻在持續(xù)增加，這導致了加速比會隨著節(jié)點和線程數(shù)的增加而慢慢趨于平緩。

本文對程序的通用性和擴展性同樣進行了實驗，選取了資源三號2號星2017年10月18日密云站接收的基帶數(shù)據(jù)，通過配置資源三號2號星的處理配置文件和編寫具體解碼器類(本實驗直接使用的資源三號1號星的解碼器，對通用性的驗證沒有影響)和拼接類，可實現(xiàn)對資源三號2號星數(shù)據(jù)的流程處理。

3 結(jié)束語

本文針對地面基帶數(shù)據(jù)處理中處理步驟較多、通用性設計困難以及解壓縮計算復雜的特點，設計并實現(xiàn)了一個具有良好通用性和擴展性的地面基帶數(shù)據(jù)二級并行處理算法。文章首先對遙感衛(wèi)星地面基帶數(shù)據(jù)處理系統(tǒng)的流程進行了介紹，設計了AOS幀通用的格式解析配置文件，實現(xiàn)了從幀同步到AOS幀格式分包的通用性處理，對解壓縮部分和拼接部分，通過模板方法和工廠模式以及設計通用解壓縮塊數(shù)據(jù)結(jié)構(gòu)的方式，實現(xiàn)了可擴展性設計；其次文章對計算最復雜的解壓縮部分設計了二級并行處理模型，實現(xiàn)了分布式并行處理，利用MPI進行節(jié)點間粗粒度的進程級別并行處理，利用OpenMP進行計算節(jié)點內(nèi)細粒度的線程級別并行處理，同時對計算資源的負載均衡進行良好的設計，保持在計算過程中具有極少的計算等待，避免了計算資源的浪費。算法的實驗結(jié)果表明，在以資源三號1星為基礎的程序上，配置資源三號2星的配置文件，然后實現(xiàn)資源三號2星的解碼器類和拼接寫入類即能實現(xiàn)資源三號2星的數(shù)據(jù)流程處理，說明算法的通用性和擴展性得到了驗證，在速度上利用5臺刀片服務器實現(xiàn)了資源三號1星的實時處理，說明算法具有較好的并行處理性能。下一步工作的重點是進一步驗證算法的通用性和可擴展性，實現(xiàn)更多衛(wèi)星的驗證處理工作，以期實現(xiàn)高分系列衛(wèi)星的快速實時處理。