孟祥海，王學(xué)志，趙江華，周小華

1.中國科學(xué)院計算機網(wǎng)絡(luò)信息中心，北京 100190

2.中國科學(xué)院大學(xué)，北京 100049

引 言

隨著遙感數(shù)據(jù)處理技術(shù)的不斷豐富和發(fā)展，遙感數(shù)據(jù)處理能力不斷增強，處理手段更加豐富，發(fā)展出較多成熟的遙感數(shù)據(jù)處理技術(shù)，例如,利用人工智能技術(shù)進行云雪檢測、利用rasterio訪問柵格數(shù)據(jù)等，充分發(fā)揮不同遙感數(shù)據(jù)處理技術(shù)的優(yōu)勢，提升遙感數(shù)據(jù)處理的效率和水平是研究遙感數(shù)據(jù)處理的關(guān)鍵。遙感數(shù)據(jù)處理涉及數(shù)據(jù)解譯、處理和專業(yè)應(yīng)用等，目標(biāo)為形成多源遙感基礎(chǔ)數(shù)據(jù)產(chǎn)品和專業(yè)數(shù)據(jù)產(chǎn)品?；谶b感數(shù)據(jù)（特別是高分辨率遙感影像數(shù)據(jù)）的信息提取技術(shù)獲取有效信息，可為專業(yè)應(yīng)用提供數(shù)據(jù)支撐，可應(yīng)用于土地遙感分析、植物遙感分析、水體和海洋遙感分析等領(lǐng)域。信息提取的前提是對遙感數(shù)據(jù)進行有效地組織、處理、計算和分析等操作。

作為連接遙感數(shù)據(jù)和專業(yè)應(yīng)用之間的媒介，遙感數(shù)據(jù)處理系統(tǒng)建設(shè)正臨著數(shù)據(jù)密集、計算密集、并發(fā)訪問密集、時空密集等實際應(yīng)用帶來的挑戰(zhàn)[1]。傳統(tǒng)單機處理的服務(wù)模式已不能滿足遙感大數(shù)據(jù)的處理需求，為此需要引入分布式系統(tǒng)對空間數(shù)據(jù)進行處理[2-4]，依托分布式處理技術(shù)提高處理遙感數(shù)據(jù)的規(guī)模和效率。

目前主流分布式計算框架Hadoop、Storm、Spark等在遙感數(shù)據(jù)處理方面均取得了較好的效果，根據(jù)數(shù)據(jù)的格式及內(nèi)容提供實時處理和離線批處理[5]。張嘉等基于HBase預(yù)分區(qū)優(yōu)化策略，結(jié)合MapReduce計算框架，構(gòu)建了空間數(shù)據(jù)分布式計算與分析的優(yōu)化流程[6]。宋峣等應(yīng)用Storm對現(xiàn)有系統(tǒng)進行并行優(yōu)化，設(shè)計了遙感數(shù)據(jù)流處理任務(wù)拓撲結(jié)構(gòu)[7]。劉歡等基于Spark并行框架進行MODIS遙感影像的海表溫度反演，影像處理效率大大提升[8]。然而，利用上述主流分布式計算框架對遙感數(shù)據(jù)進行分析處理需要用戶自己設(shè)計遙感數(shù)據(jù)處理算子，其影像數(shù)據(jù)切割、分析等操作需借助額外的專有框架實現(xiàn)，用戶操作復(fù)雜度較高。

針對上述問題，研究人員提出了眾多專門應(yīng)用于遙感數(shù)據(jù)處理的分布式系統(tǒng)架構(gòu)，如SpatialHadoop[9]、Hadoop-GIS[10]、GeoSpark[11]、LocationSpark[12]、Simaba[13]、pipsCloud[14]等。這些系統(tǒng)基于MapReduce和Spark分布式計算框架實現(xiàn)，無需借助額外的專有框架，提高了遙感數(shù)據(jù)處理的效率。然而，基于MapReduce和Spark計算框架進行遙感數(shù)據(jù)處理帶來性能提升的同時，也帶來了一定的局限性。

上述框架集成在通用平臺上，只能在特定開發(fā)環(huán)境，利用通用平臺API和存儲系統(tǒng)處理遙感數(shù)據(jù)，需要用戶學(xué)習(xí)使用通用平臺的API和技術(shù)，用戶使用復(fù)雜度高，對于輕量級的遙感處理任務(wù)(數(shù)據(jù)的簡單計算)來說遷移和使用代價較高。目前，用戶大多擁有處理遙感數(shù)據(jù)的程序或算法，待處理遙感數(shù)據(jù)存儲在特定存儲系統(tǒng)中，借助一個輕量級框架，在盡量不改變既有程序和存儲位置的基礎(chǔ)上實現(xiàn)遙感數(shù)據(jù)的高效處理成為用戶的需求。若基于MapReduce或Spark等通用計算框架進行遙感數(shù)據(jù)處理，其程序和算法需要根據(jù)通用平臺的API進行重構(gòu)，數(shù)據(jù)需要導(dǎo)入框架對應(yīng)的存儲系統(tǒng)，遷移代價較高。更換技術(shù)框架和存儲系統(tǒng)給簡單的處理任務(wù)帶了較大壓力。

實踐中針對既有成熟遙感數(shù)據(jù)處理技術(shù)只能單獨使用或在特定領(lǐng)域使用的問題，設(shè)計了一個新的交互環(huán)境。該環(huán)境支持既有成熟技術(shù)的綜合使用，提升了系統(tǒng)處理能力。此外，不同用戶需求不同，只提供特定的API接口或算法，難以滿足用戶個性化的處理需求。因此，設(shè)計一種遷移方便、操作簡單的開放交互方式，也是目前亟待解決的問題。

目前，依托通用平臺進行遙感數(shù)據(jù)處理的計算框架除遷移能力和操作復(fù)雜度受限制外，其調(diào)度端的可控性也是用戶關(guān)心的問題。通常，分布式計算框架執(zhí)行任務(wù)時，其他任務(wù)無法提交，需等待任務(wù)執(zhí)行完畢才可提交新的任務(wù)執(zhí)行，為用戶執(zhí)行緊急任務(wù)帶來了一定的困擾?，F(xiàn)有遙感數(shù)據(jù)處理系統(tǒng)一般將任務(wù)提交至集群，集群自動分配節(jié)點執(zhí)行任務(wù)，緊急處理任務(wù)仍需按其調(diào)度策略分配執(zhí)行，用戶對任務(wù)分配調(diào)度過程的控制力較低。因此，設(shè)計一個用戶可控的調(diào)度系統(tǒng)，保證緊急任務(wù)及時處理和負載均衡也是急需解決的問題。此外，遙感數(shù)據(jù)處理過程偶爾涉及處理全局?jǐn)?shù)據(jù)的操作，通用平臺的遙感數(shù)據(jù)處理一般基于內(nèi)存執(zhí)行分布式處理，若單景數(shù)據(jù)量較大，將全局?jǐn)?shù)據(jù)加載至內(nèi)存處理可能會造成內(nèi)存資源負載過重，從而降低系統(tǒng)的處理性能。

針對上述問題，本文提出了基于RS-UDF的輕量級遙感數(shù)據(jù)分布式調(diào)度框架DataboxMR。針對處理輕量級遙感任務(wù)時遷移能力低、用戶操作復(fù)雜度高等問題，本文提出了RS-UDF。RS-UDF是可封裝既有成熟遙感數(shù)據(jù)處理技術(shù)并將封裝單元提交至調(diào)度引擎執(zhí)行的交互環(huán)境，可在不改變用戶既有程序或數(shù)據(jù)存儲位置的情況下提交分布式任務(wù)。針對調(diào)度過程可控性低和遙感數(shù)據(jù)全局處理性能差等問題，系統(tǒng)設(shè)計了雙層調(diào)度引擎。雙層調(diào)度引擎支持遙感數(shù)據(jù)的高效調(diào)度，支持用戶指定節(jié)點執(zhí)行任務(wù)，支持故障恢復(fù)，可實現(xiàn)輕量化任務(wù)處理，相同條件下，消耗更少的系統(tǒng)資源。

1 遙感數(shù)據(jù)調(diào)度框架DataboxMR

1.1 系統(tǒng)概述

DataboxMR以穩(wěn)定高效地處理遙感數(shù)據(jù)為目標(biāo)，提供了一個支持已有成熟遙感處理技術(shù)、遷移方便、用戶使用復(fù)雜度低、調(diào)度過程可控的輕量級調(diào)度框架。如圖1所示，DataboxMR主要由RS-UDF、主調(diào)度器(Jobman)、分調(diào)度器(Taskman)和工作節(jié)點(Worker)四部分組成。其中，RS-UDF以函數(shù)為調(diào)度單元，實現(xiàn)分布式任務(wù)的封裝與提交，主調(diào)度器接收RS-UDF提交的任務(wù)并進行任務(wù)劃分和分發(fā)，分調(diào)度接收主調(diào)度器分配的子任務(wù)并分發(fā)給工作節(jié)點，工作節(jié)點負責(zé)實際的任務(wù)執(zhí)行。

圖1 DataboxMR框架Fig.1 DataboxMR framework

在這四部分中，RS-UDF和調(diào)度引擎(主調(diào)度器和分調(diào)度器)是支撐DataboxMR框架的核心模塊，RS-UDF實現(xiàn)對遙感處理邏輯的封裝，提供對外交互的環(huán)境和接口。調(diào)度引擎實現(xiàn)遙感處理任務(wù)的高效劃分、分配與處理，支持指定節(jié)點處理緊急任務(wù)，具備故障恢復(fù)能力。

1.2 遙感數(shù)據(jù)處理服務(wù)組件RS-UDF

UDF技術(shù)是用戶自定義函數(shù)的簡稱，一般表示自定義標(biāo)量函數(shù)、自定義聚合函數(shù)及自定義表函數(shù)三種自定義函數(shù)的集合，通常所說的UDF指用戶自定義標(biāo)量函數(shù)。RS-UDF受UDF啟發(fā)，將遙感數(shù)據(jù)處理技術(shù)融入UDF技術(shù)中，用以支持對現(xiàn)有遙感數(shù)據(jù)處理技術(shù)的擴展，實現(xiàn)靈活高效的二次開發(fā)。

RS-UDF是DataboxMR中面向遙感數(shù)據(jù)的用戶自定義服務(wù)組件，基于Python提供遷移方便、操作簡單的開發(fā)交互環(huán)境，側(cè)重與既有成熟技術(shù)（如numpy、rasterio、gdal等）結(jié)合，利用既有成熟技術(shù)設(shè)計業(yè)務(wù)邏輯。用戶已有程序或算法經(jīng)過簡單封裝，即可提交任務(wù)請求。當(dāng)用戶實現(xiàn)數(shù)據(jù)可視化、數(shù)據(jù)計算等簡單的處理任務(wù)時，無需根據(jù)通用平臺的API進行重構(gòu)，只需簡單修改已有程序，將其封裝成滿足RS-UDF要求的函數(shù)算子形式，通過服務(wù)接口提交調(diào)度引擎處理即可，用戶操作復(fù)雜度低，遷移代價小。此外，用戶可根據(jù)需求靈活設(shè)計遙感數(shù)據(jù)處理邏輯，直接引入已有成熟軟件包，充分保留UDF靈活開發(fā)的優(yōu)勢，從而保證用戶操作的靈活性。

1.2.1 基于RS-UDF處理遙感數(shù)據(jù)的內(nèi)部任務(wù)封裝過程

RS-UDF接收用戶任務(wù)后，內(nèi)部對任務(wù)進行進一步封裝處理。如圖2所示，用戶以函數(shù)為單元封裝好處理邏輯，將函數(shù)單元以參數(shù)形式提交至RSUDF接口，接收任務(wù)參數(shù)后，RS-UDF將任務(wù)調(diào)度服務(wù)器地址、客戶端地址注冊至etcd。檢測集群狀態(tài)、節(jié)點狀態(tài)等信息，驗證集群是否有空閑資源可以分布式處理遙感數(shù)據(jù)。若集群資源滿足處理遙感數(shù)據(jù)的要求，則將函數(shù)單元序列化為統(tǒng)一的JSON格式，將接口中其他參數(shù)轉(zhuǎn)碼為字節(jié)碼形式。將序列化和轉(zhuǎn)碼后的參數(shù)提交至DataboxMR-Engine進行分布式處理。RS-UDF根據(jù)用戶不同需求可提供不同的接口服務(wù)，同步任務(wù)若存在Reduce算子，則選用MapReduce接口，若只存在Map算子，則選擇map接口。異步任務(wù)調(diào)用過程同理，在實際應(yīng)用中，用戶可根據(jù)不同需求選擇不同接口服務(wù)。

圖2 RS-UDF任務(wù)封裝Fig.2 RS-UDF task package

上述客戶端地址、集群主調(diào)度器地址等注冊過程通過etcd服務(wù)器保障實現(xiàn)。etcd通過raft一致性協(xié)議保證集群的高可靠性，當(dāng)一個節(jié)點出現(xiàn)故障時，集群中其他節(jié)點的備份數(shù)據(jù)可保障任務(wù)的正常執(zhí)行。

1.2.2 RS-UDF用戶任務(wù)封裝實例

針對通用平臺遷移代價大、用戶使用復(fù)雜度高等問題，RS-UDF結(jié)合既有成熟遙感數(shù)據(jù)處理技術(shù)，在原有程序和算法的基礎(chǔ)上只需簡單封裝，即可提交調(diào)度引擎執(zhí)行分布式處理。此外，基于RS-UDF提交分布式任務(wù)時，對數(shù)據(jù)的存儲系統(tǒng)沒有特殊要求，可在不改變原有存儲系統(tǒng)的情況下處理數(shù)據(jù)。為了解RS-UDF用戶任務(wù)封裝過程，設(shè)計了圖3所示NDVI計算實例。

圖3 RS-UDF封裝實例Fig.3 RS-UDF package example

舉例：

如圖3所示，用戶在已有處理邏輯的基礎(chǔ)上，利用DataboxMR的分布式計算能力完成數(shù)據(jù)分析任務(wù)時，只需簡單修改既有程序（其中“+”表示增加的代碼，“-”表示刪除的代碼），修改為滿足RS-UDF要求的函數(shù)形式?；赗S-UDF封裝函數(shù)調(diào)度單元時，基本未改變用戶原有處理邏輯，有效避免了為實現(xiàn)輕量級任務(wù)而學(xué)習(xí)通用平臺API、進行大規(guī)模代碼修改、遷移等問題，用戶操作簡便，使用代價低。

1.3 調(diào)度引擎DataboxMR-Engine

調(diào)度引擎主要為遙感數(shù)據(jù)提供作業(yè)和計算任務(wù)的分層調(diào)度、任務(wù)處理等服務(wù)。分別從高效處理輕量級任務(wù)、用戶可控性及性能穩(wěn)定性方面入手，保證調(diào)度引擎的功能。作為調(diào)度系統(tǒng)的核心，DataboxMR-Engine除實現(xiàn)任務(wù)劃分及調(diào)度基本功能外，保證系統(tǒng)的高可靠性，實現(xiàn)對任務(wù)狀態(tài)的監(jiān)測、保障有效的容錯及恢復(fù)機制也是其必不可少的功能?；陔p層調(diào)度模式實現(xiàn)遙感數(shù)據(jù)的切分和分配，其處理過程可支持用戶指定節(jié)點處理遙感數(shù)據(jù)，保證靈活性的同時，可增加用戶對調(diào)度引擎的控制能力，可提升用戶處理緊急任務(wù)的能力和效率。同時，調(diào)度引擎支持故障恢復(fù)功能，基于核心數(shù)據(jù)結(jié)構(gòu)（雙端隊列和索引樹）和狀態(tài)機制實現(xiàn)，保證系統(tǒng)高可用和穩(wěn)定性的同時，可快速回收系統(tǒng)資源，保證系統(tǒng)可用資源充足，從而保證系統(tǒng)輕量化的特點。

1.3.1 遙感處理任務(wù)調(diào)度過程

雙層調(diào)度引擎由一個主調(diào)度器和多個分調(diào)度器組成。主調(diào)度器負責(zé)任務(wù)的劃分和分發(fā)，分調(diào)度器負責(zé)接收子任務(wù)并分發(fā)給工作節(jié)點。雙層調(diào)度模塊側(cè)重對遙感數(shù)據(jù)的高效調(diào)度和處理，通過雙端隊列和索引樹等數(shù)據(jù)結(jié)構(gòu)實現(xiàn)，具有指定節(jié)點優(yōu)先執(zhí)行、故障恢復(fù)的能力。其調(diào)度過程如圖4所示。

圖4 調(diào)度過程Fig.4 Scheduling process

任務(wù)接收和劃分：主調(diào)度器接收來自RS-UDF的任務(wù)二進制流，解析二進制流，將解析后任務(wù)加入任務(wù)字典，從字典中取出任務(wù)劃分并加入任務(wù)隊列。入隊順序根據(jù)優(yōu)先級參數(shù)確定，若優(yōu)先級參數(shù)為True，則將子任務(wù)分配至隊列首部，若未指定優(yōu)先級，則按順序加入至隊列尾部。

主調(diào)度器子任務(wù)分配：從任務(wù)隊列首部取出任務(wù)分配。當(dāng)任務(wù)指定優(yōu)先級時，高優(yōu)先級任務(wù)的任務(wù)信息被放入至數(shù)據(jù)庫，子任務(wù)信息不放入數(shù)據(jù)庫，放入內(nèi)存等待分配執(zhí)行。若任務(wù)未指定優(yōu)先級，任務(wù)和子任務(wù)信息均放入數(shù)據(jù)庫，不放于內(nèi)存，等高優(yōu)先級任務(wù)執(zhí)行完畢再執(zhí)行。

分調(diào)度器子任務(wù)分配：分調(diào)度器向主調(diào)度器請求批量子任務(wù)，主調(diào)度器根據(jù)分調(diào)度器的請求信息從任務(wù)隊列取出子任務(wù)分配給分調(diào)度器，分調(diào)度器將接收到的子任務(wù)加入至其自身維護的雙端隊列中，等待工作節(jié)點來主動拉取任務(wù)執(zhí)行。

任務(wù)執(zhí)行：工作節(jié)點從與其位于相同節(jié)點的分調(diào)度器隊列中主動拉取子任務(wù)到本地執(zhí)行。

1.3.2 基于隊列和索引樹的雙層調(diào)度結(jié)構(gòu)

如圖5所示，雙層調(diào)度引擎的核心數(shù)據(jù)結(jié)構(gòu)為任務(wù)隊列和索引樹。任務(wù)隊列負責(zé)維護待分配子任務(wù)。索引樹用于記錄子任務(wù)與分調(diào)度器或子任務(wù)與工作節(jié)點之間的映射關(guān)系。

圖5 隊列和索引執(zhí)行原理Fig.5 Queue and index execution principle

任務(wù)隊列基于雙端隊列實現(xiàn)，入隊時，當(dāng)未指定任務(wù)優(yōu)先級時，按順序?qū)澐趾笞尤蝿?wù)加入至隊列尾部，當(dāng)指定任務(wù)優(yōu)先級或重新執(zhí)行任務(wù)時，將子任務(wù)加入至隊列首部。分配時，從隊列首部取出任務(wù)分配執(zhí)行。

索引樹用于存儲任務(wù)、子任務(wù)和節(jié)點之間的分配關(guān)系，基于任務(wù)id、子任務(wù)id及節(jié)點地址實現(xiàn)映射。一級索引樹用于記錄任務(wù)、子任務(wù)和分調(diào)度器之間的映射關(guān)系，二級索引樹用于記錄子任務(wù)和工作節(jié)點地址之間的映射。

1.3.3 基于狀態(tài)機制的故障恢復(fù)

受限于網(wǎng)絡(luò)、硬件資源等情況，任務(wù)執(zhí)行過程中出現(xiàn)任務(wù)超時、任務(wù)執(zhí)行出錯等情況不可避免，如何實現(xiàn)高效的故障恢復(fù)是必須解決的一個問題。為保證任務(wù)執(zhí)行過程中的故障恢復(fù)能力，提升系統(tǒng)的可靠性，調(diào)度引擎提出了狀態(tài)機制。

狀態(tài)機制是指在調(diào)度過程中為每個階段的任務(wù)賦予相應(yīng)狀態(tài)，例如，任務(wù)分發(fā)后賦予已分配狀態(tài)，任務(wù)執(zhí)行成功賦予成功狀態(tài)。調(diào)度過程根據(jù)任務(wù)的狀態(tài)信息，執(zhí)行相應(yīng)的分配、拋棄等操作。

如圖6所示，任務(wù)在工作節(jié)點執(zhí)行時，分調(diào)度器通過心跳信息定時的獲取任務(wù)的執(zhí)行狀態(tài)，若任務(wù)出現(xiàn)超時或出錯，工作節(jié)點通過心跳信息將失敗任務(wù)信息反饋給上層分調(diào)度器。分調(diào)度器通過索引樹快速定位出錯子任務(wù)相應(yīng)信息、子任務(wù)id及與工作節(jié)點間的映射關(guān)系，將獲取到的錯誤子任務(wù)相關(guān)信息通過心跳信息反饋給主調(diào)度器。主調(diào)度器根據(jù)狀態(tài)信息首先從索引樹中獲取出錯的子任務(wù)id及任務(wù)id的映射信息，停止出錯任務(wù)相關(guān)的所有子任務(wù)的執(zhí)行，回收分配至這些任務(wù)中的資源，然后從任務(wù)字典重新取出任務(wù)并劃分為子任務(wù)，將子任務(wù)分配至雙端隊列的首部，等待重新分配，最終任務(wù)被重新分配至新的節(jié)點執(zhí)行成功，結(jié)束故障恢復(fù)過程。

圖6 故障恢復(fù)過程Fig.6 Failure recovery process

狀態(tài)機制結(jié)合調(diào)度引擎的隊列和索引樹數(shù)據(jù)結(jié)構(gòu)保障任務(wù)執(zhí)行的可靠性和穩(wěn)定性。調(diào)度引擎基于每秒一次的心跳信息獲取任務(wù)狀態(tài)，保證及時發(fā)現(xiàn)任務(wù)執(zhí)行故障并激活故障恢復(fù)機制，整個狀態(tài)恢復(fù)過程調(diào)度引擎自主完成，無需人工干預(yù)，對用戶透明。

1.3.4 可控、輕量化的調(diào)度引擎

通常，用戶希望通過管理調(diào)度引擎來提升任務(wù)處理過程的可控性。為滿足這一需求，系統(tǒng)內(nèi)部設(shè)計任務(wù)處理監(jiān)測模塊，通過狀態(tài)反饋機制、接受用戶指定節(jié)點執(zhí)行任務(wù)的方式實現(xiàn)。狀態(tài)反饋機制負責(zé)監(jiān)測并反饋任務(wù)執(zhí)行狀態(tài)。接受用戶指定執(zhí)行節(jié)點的服務(wù)可保證調(diào)度引擎可控的特性，指定節(jié)點執(zhí)行任務(wù)時，若指定節(jié)點未在執(zhí)行任務(wù)，可直接執(zhí)行用戶指定任務(wù)，若指定節(jié)點有任務(wù)執(zhí)行中，則需要等待當(dāng)前任務(wù)執(zhí)行完畢后執(zhí)行用戶任務(wù)。

此外，處理全局遙感數(shù)據(jù)時，可結(jié)合Zonal Operation運算的特點及其狀態(tài)機制提升資源的利用率和任務(wù)處理的效率。遙感數(shù)據(jù)的Zonal Operation運算，處理范圍通常為不規(guī)則但具有明確物理意義的單元，其輸入需包含指定區(qū)域的矢量范圍，調(diào)度引擎在計算時將矢量范圍掩膜包含的多個Tiles按數(shù)據(jù)量大小均衡的加載至各個節(jié)點執(zhí)行分布式處理。同時，基于狀態(tài)機制及時將分配至出錯任務(wù)的系統(tǒng)資源收回，保證系統(tǒng)資源的高效利用，從而保證系統(tǒng)輕量化處理的特點。

2 實驗

2.1 實驗設(shè)計

為驗證系統(tǒng)性能，基于Landsat8[15]數(shù)據(jù)集計算歸一化植被指數(shù)（Normalized Difference Vegetation Index, NDVI）。NDVI是一種利用綠色植物對紅光的低反射率和對近紅光的高反射率的光譜特征值計算的植被指數(shù)，可應(yīng)用于檢測植被生長狀態(tài)、植被覆蓋度等。NDVI值在-1至1之間，負值表示地面覆蓋為云、水、雪等，對可見光高反射；0表示有巖石或裸土等，近紅外光譜特征(NIR)和紅外光譜特征（Red）近似相等；正值表示有植被覆蓋，且隨覆蓋度增大而增大。其數(shù)學(xué)表達式為：實驗過程中對比DataboxMR和GeoTrellis計算NDVI時處理時間、CPU占用、內(nèi)存占用和網(wǎng)絡(luò)占用的性能差異。

基于DataboxMR處理遙感數(shù)據(jù)時，將Map函數(shù)、Reduce函數(shù)及數(shù)據(jù)提交至RS-UDF的服務(wù)接口。實驗中，DataboxMR引入gdal庫，基于gdal庫將影像數(shù)據(jù)讀取為矩陣，基于矩陣可分解的性質(zhì)，對矩陣進行切分，切分后數(shù)據(jù)塊作為DataboxMR分布式處理的基本單元，以List或者Tuple形式提交至服務(wù)接口，接收參數(shù)后接口將任務(wù)封裝并提交至調(diào)度引擎，調(diào)度引擎對任務(wù)執(zhí)行劃分和分配，將子任務(wù)下發(fā)至集群中各節(jié)點分別執(zhí)行遙感數(shù)據(jù)的NDVI計算，最后將各部分?jǐn)?shù)據(jù)計算結(jié)果匯總返回并寫入磁盤。

為使用內(nèi)存計算平臺Spark的分布式調(diào)度和計算能力執(zhí)行遙感數(shù)據(jù)處理任務(wù)，需引入開源框架GeoTrellis[16]進行分布式柵格數(shù)據(jù)處理。GeoTrellis是基于Spark環(huán)境處理遙感空間數(shù)據(jù)的框架，旨在支持網(wǎng)絡(luò)規(guī)模和集群規(guī)模的地理空間處理，可讀取、轉(zhuǎn)換、操作和寫入遙感數(shù)據(jù)，此外，GeoTrellis可對矢量數(shù)據(jù)進行地圖代數(shù)操作，可進行矢量數(shù)據(jù)和柵格數(shù)據(jù)的相互轉(zhuǎn)換操作。其主要實現(xiàn)了創(chuàng)建低延遲、可擴展的地理處理Web服務(wù)、在分布式體系結(jié)構(gòu)中運行，對大型遙感數(shù)據(jù)集進行快速批處理、采用多核架構(gòu)對遙感數(shù)據(jù)進行并行化處理等功能。綜上所述，GeoTrellis為Spark提供了功能豐富、處理高效的遙感數(shù)據(jù)處理庫，通過GeoTrellis與Spark共同組成的處理引擎執(zhí)行遙感數(shù)據(jù)處理操作，在提升處理效率的同時，也擴展了Spark的處理能力和范圍。因此，為了利用Spark基于內(nèi)存的分布式計算能力，對遙感數(shù)據(jù)進行高效處理。同時，也為了利用GeoTrellis強大的遙感數(shù)據(jù)處理能力，提出了開源框架GeoTrellis與Spark組成調(diào)度引擎進行遙感數(shù)據(jù)處理的方法?；贕eoTrellis處理遙感數(shù)據(jù)時將柵格數(shù)據(jù)分割為使用空間填充曲線索引的統(tǒng)一瓦片[17]。受GeoTrellis-Landsat-Tutorial[18]啟發(fā)，本實驗基于GeoTrellis對數(shù)據(jù)進行柵格化?；赟park環(huán)境實現(xiàn)遙感影像的分布式處理，首先需利用GeoTrellis將遙感影像切分為多個瓦片數(shù)據(jù)(實驗中為彈性分布式數(shù)據(jù)集（Resilient Distributed Dataset,RDD)，然后對瓦片數(shù)據(jù)進行一系列處理。其處理流程為讀取影像數(shù)據(jù)并將其轉(zhuǎn)化為RDD[(SpatialKey, MultibandTile)],然后基于轉(zhuǎn)化后RDD[(SpatialKey, MultibandTile)]執(zhí)行分布式計算，除計算NDVI外，基于RDD還可對遙感影像執(zhí)行多種分布式處理操作。實驗中，GeoTrellis涉及處理技術(shù)有：基于HadoopGeoTiffRDD方法將單波段影像讀取為RDD[(SpatilKey,Tile)],基于combine等方法將單波段影像合并為多波段形式，然后基于map算子設(shè)計處理邏輯，將合并成的多波段影像切分為瓦片并執(zhí)行計算，最后在Spark環(huán)境中以RDD為執(zhí)行單位進行分布式處理。Spark分布式環(huán)境下GeoTrellis執(zhí)行分布式處理的流程如圖7所示。

圖7 GeoTrellis計算NDVI過程Fig.7 GeoTrellis calculation process of NDVI

2.2 實驗環(huán)境與數(shù)據(jù)

實驗在由3個計算節(jié)點組成的集群上進行，每個計算節(jié)點中配置有4核CPU、8GB RAM和30GB 7200RPM的HDD，實驗環(huán)境如表1所示。

表1 實驗環(huán)境系統(tǒng)信息Table 1 Experimental environment system information

實驗數(shù)據(jù)基于Landsat8數(shù)據(jù)集，本實驗采用十景Landsat8數(shù)據(jù)集作為實驗數(shù)據(jù)，數(shù)據(jù)集及數(shù)據(jù)量如表2所示。

表2 數(shù)據(jù)集Table 2 Data set

2.3 實驗結(jié)果監(jiān)測

DataboxMR與GeoTrellis分別讀取并處理十景遙感影像，并將計算后的遙感數(shù)據(jù)寫入相應(yīng)的存儲系統(tǒng)。在該過程中，分別記錄分布式處理任務(wù)的消耗時間、CPU占用率、內(nèi)存占用率和網(wǎng)絡(luò)傳輸占用等性能指標(biāo)。時間消耗通過監(jiān)測Linux系統(tǒng)時間實現(xiàn)，后三者通過Ganglia監(jiān)測記錄。Ganglia是UC Berkely發(fā)起的開源項目，可對分布式集群的所有計算資源進行監(jiān)測，通過Web頁面顯示監(jiān)測結(jié)果。實驗過程中，通過為集群部署Ganglia的方式實時監(jiān)測集群處理任務(wù)時間段內(nèi)的系統(tǒng)資源(CPU占用率、內(nèi)存占用率、網(wǎng)絡(luò)負載)變化，并記錄反饋監(jiān)測結(jié)果。

2.3.1 計算時間

為驗證DataboxMR處理遙感影像數(shù)據(jù)的速度，相同實驗條件下，對相同數(shù)據(jù)集執(zhí)行NDVI計算，基于Linux的系統(tǒng)時間，對讀取遙感數(shù)據(jù)、分析遙感數(shù)據(jù)和寫遙感數(shù)據(jù)處理結(jié)果三個階段時間分別監(jiān)測記錄，各階段時間消耗情況如表3所示。

去噪模塊的核心在于將噪聲分類，通過不同的濾波器進行處理。均值濾波是對數(shù)據(jù)求均值，中值濾波采用分組排序：首先對列數(shù)據(jù)進行排序，之后對排序后的每行數(shù)據(jù)排序得到每行的中值，最后對每行數(shù)據(jù)的中值排序得到中值[5]。

表3 GeoTrellis與DataboxMR時間消耗Table 3 Time consumption of GeoTrellis and DataboxMR

表3表明，相同實驗條件下，對相同遙感數(shù)據(jù)執(zhí)行NDVI計算，DataboxMR讀寫磁盤數(shù)據(jù)的時間相較于GeoTrellis讀寫HDFS數(shù)據(jù)更快。由于最終處理數(shù)據(jù)為矩陣形式，因此處理過程消耗時間相近，差異較小。因此，由實驗結(jié)果可知DataboxMR的I/O速度較快。若將數(shù)據(jù)存于主流空間數(shù)據(jù)庫或?qū)ο蟠鎯ο到y(tǒng)，其讀寫性能可進一步提升。

2.3.2 CPU占用

為觀察DataboxMR執(zhí)行分布式計算時CPU占用變化，分別監(jiān)測集群整體和各節(jié)點的CPU占用變化。

圖8（左上）表明，GeoTrellis在Spark環(huán)境下執(zhí)行遙感影像分布式處理時，任務(wù)提交后，集群整體CPU占用率最高超過25%，普遍維持在15%~20%之間。DataboxMR的CPU占用率峰值在4%以下，普遍穩(wěn)定在3%~3.5%之間，GeoTrellis的占用面積(曲線與坐標(biāo)軸的積分)大于DataboxMR的面積。因此，分布式處理遙感數(shù)據(jù)時，DataboxMR比GeoTrellis占用更少的CPU資源。圖8（右上、左下、右下）表明，集群各節(jié)點CPU占用率均出現(xiàn)明顯變化，未出現(xiàn)明顯負載不均衡，未產(chǎn)生明顯數(shù)據(jù)傾斜，分布式任務(wù)執(zhí)行狀態(tài)正常。對比各節(jié)點CPU占用率變化可知，DataboxMR的CPU占用率明顯低于GeoTrellis的CPU占用率。綜上所述，DataboxMR進行遙感數(shù)據(jù)分布式處理時比GeoTrellis占用更少CPU資源。

圖8 CPU占用變化Fig.8 CPU usage changes

2.3.3 內(nèi)存占用

為驗證分布式處理過程中內(nèi)存占用變化情況，分別監(jiān)測處理過程中集群內(nèi)存變化和各節(jié)點內(nèi)存變化。圖9表示內(nèi)存使用時的占用變化，圖10表示剩余空閑內(nèi)存變化。

圖9 內(nèi)存占用變化Fig.9 Memory usage changes

圖10 空閑內(nèi)存變化Fig.10 Free memory changes

圖9(左上)表示GeoTrellis和DataboxMR處理相同任務(wù)時集群內(nèi)存使用變化。結(jié)果表明，前者處理時內(nèi)存占用面積(占用曲線與坐標(biāo)軸之間的積分)大于后者的面積。因此，可知前者處理任務(wù)時內(nèi)存占用更大。圖9（右上、左下、右下）表示集群各節(jié)點處理相同任務(wù)時內(nèi)存占用變化。結(jié)果表明，各節(jié)點前者面積均大于后者面積，說明處理任務(wù)時GeoTrellis各節(jié)點的內(nèi)存占用率大于DataboxMR。圖10(左上)表明，GeoTrellis提交分布式任務(wù)至Spark運行環(huán)境時，空閑內(nèi)存出現(xiàn)明顯減少，維持在2GB~4GB之間。提交分布式計算任務(wù)至DataboxMR時，空閑內(nèi)存資源變化較平緩，維持在5GB~6GB之間，前者平均空閑值小于后者。圖10(右上、左下、右下)表明，各節(jié)點執(zhí)行計算任務(wù)時空閑內(nèi)存均出現(xiàn)了明顯減少，但DataboxMR各節(jié)點的空閑內(nèi)存相較于GeoTrellis平均值更大，即相對空閑內(nèi)存更多。綜上所述，執(zhí)行遙感數(shù)據(jù)處理任務(wù)時，GeoTrellis消耗的內(nèi)存資源比DataboxMR更多。

2.3.4 網(wǎng)絡(luò)傳輸

為驗證網(wǎng)絡(luò)傳輸和通信效率，監(jiān)測網(wǎng)絡(luò)負載。圖11表示網(wǎng)絡(luò)輸入變化，圖12表示網(wǎng)絡(luò)輸出變化。

圖12 網(wǎng)絡(luò)輸出變化Fig.12 Network output changes

圖11-12(左上)表明，GeoTrellis處理遙感影像時，從HDFS讀寫數(shù)據(jù)將產(chǎn)生大量網(wǎng)絡(luò)傳輸開銷，最大輸入、輸出傳輸達到17.5MB/s左右。DataboxMR計算NDVI時，最大輸入、輸出傳輸峰值在5MB/s以下，后者的面積(輸入、輸出曲線與坐標(biāo)軸之間的積分)明顯小于前者，為前者的1/3左右，說明后者占用了更少的網(wǎng)絡(luò)資源。圖11-12(右上、左下、右下)表明，Spark集群中各節(jié)點從HDFS讀寫數(shù)據(jù)時輸入、輸出的網(wǎng)絡(luò)傳輸負載在6MB/s~10MB/s之間，網(wǎng)絡(luò)負載重，系統(tǒng)傳輸效率低。DataboxMR集群中各節(jié)點的輸入、輸出的網(wǎng)絡(luò)負載在3MB/s以下，數(shù)據(jù)傳輸?shù)木W(wǎng)絡(luò)開銷明顯低于GeoTrellis，網(wǎng)絡(luò)占用低，對系統(tǒng)的網(wǎng)絡(luò)性能影響小，網(wǎng)絡(luò)通信效率高。綜上所述，執(zhí)行遙感數(shù)據(jù)處理時，DataboxMR網(wǎng)絡(luò)傳輸開銷比GeoTrellis更低，通信代價更小，網(wǎng)絡(luò)傳輸效率和通信效率更高。

圖11 網(wǎng)絡(luò)輸入變化Fig.11 Network input changes

3 實驗結(jié)果分析

實驗從處理時間、CPU占用率、內(nèi)存占用率、網(wǎng)絡(luò)負載角度驗證了DataboxMR處理遙感數(shù)據(jù)的性能。對比DataboxMR與基于Spark計算框架的GeoTrellis的處理性能，實驗結(jié)果表明，前者的I/O時間、處理時間均比GeoTrellis少，處理輕量級任務(wù)的效率較高。前者處理任務(wù)時CPU占用率比后者低，前者平均剩余空閑內(nèi)存比后者高，即DataboxMR比GeoTrellis消耗更少的內(nèi)存資源。網(wǎng)絡(luò)傳輸從輸入占用和輸出占用兩方面進行分析，前者輸入、輸出均約為后者的1/3，因此，DataboxMR相比于GeoTrellis的網(wǎng)絡(luò)負載更低。綜上所述，DataboxMR處理輕量級遙感數(shù)據(jù)分析任務(wù)時，具有穩(wěn)定高效的特點，相同實驗條件下，占用更少的系統(tǒng)資源。

4 結(jié)論

將大數(shù)據(jù)技術(shù)與遙感數(shù)據(jù)處理技術(shù)深度融合是一個值得繼續(xù)探討的問題[19]。數(shù)據(jù)密集型科學(xué)需要高效的計算框架提高數(shù)據(jù)分析效率[20]，本文對目前遙感數(shù)據(jù)分布式處理面臨的一些挑戰(zhàn)做了詳細闡述并設(shè)法予以克服，設(shè)計并實現(xiàn)了一個輕量級的分布式調(diào)度框架（DataboxMR），從處理輕量級任務(wù)、方便遷移、支持已有技術(shù)擴展、提高用戶對調(diào)度系統(tǒng)的控制力等角度出發(fā)，設(shè)計實現(xiàn)了RS-UDF以及雙層調(diào)度引擎。最后，與開源框架GeoTrellis作對比實驗，分別計算遙感數(shù)據(jù)的NDVI，收集集群內(nèi)資源消耗情況，從不同角度對結(jié)果進行了分析。結(jié)果表明，DataboxMR不僅具有高效處理輕量級任務(wù)的能力，而且相同實驗條件下，比GeoTrellis消耗更少的時間和更少的CPU、內(nèi)存、網(wǎng)絡(luò)等系統(tǒng)資源，具有輕量高效的特點。

隨著云計算技術(shù)的發(fā)展，在線計算平臺得到了空前的發(fā)展，在線計算可根據(jù)用戶個性化需求高效處理任務(wù)。RS-UDF自定義函數(shù)算子的特點可滿足用戶個性化的開發(fā)需求，簡單封裝已有算法和程序執(zhí)行輕量級分布式任務(wù)的特性，為用戶提供了一個高效易用的開發(fā)環(huán)境。DataboxMR是在遙感影像數(shù)據(jù)處理領(lǐng)域的新技術(shù)，可應(yīng)對遙感大數(shù)據(jù)帶來的挑戰(zhàn)，可為遙感數(shù)據(jù)處理提供靈活、高效的服務(wù)，可應(yīng)用于在線計算領(lǐng)域，提供科學(xué)數(shù)據(jù)端的在線交互分析[21]。該框架除分布式處理遙感數(shù)據(jù)外，還可支持傳統(tǒng)數(shù)據(jù)的批處理以及人工智能算法的分布式訓(xùn)練等，為多種數(shù)據(jù)處理任務(wù)及應(yīng)用場景提供分布式算力支撐。目前該調(diào)度框架已開源，可通過https://gitee.com/gscloud_dbox/databox_pymapreduce地址訪問。

利益沖突聲明

所有作者聲明不存在利益沖突關(guān)系。