遙感大數據的基礎設施：集成、管理與按需服務

李國慶 黃震春

2 (清華大學計算機科學與技術系 北京 100084) (ligq@radi.ac.cn)

遙感大數據的基礎設施：集成、管理與按需服務

李國慶1黃震春2

2(清華大學計算機科學與技術系 北京 100084) (ligq@radi.ac.cn)

隨著遙感技術的不斷進步，遙感數據的數據量越來越大，種類越來越多，分布越來越分散，遙感應用的復雜程度和個性化程度也不斷提高，遙感正在走向大數據時代.而目前遙感數據基礎設施在容量、可擴展性、易用性和性能等方面都難以滿足遙感應用的需求，成為了遙感科學與工程從獲取到最終產品這個流程中的瓶頸.為此，首先從遙感數據的本質出發，討論了遙感數據基礎設施應當具備的分布、異構、時空連續和按需數據處理等特性，并依據遙感數據基礎設施的基本服務單元、分布性、時空連續性和按需處理支持能力將遙感數據基礎設施分成6類.其次，針對這6類遙感數據基礎設施展現出的特性，設計了實現這些基礎設施可以采用的體系結構，并指出了其中實現的技術難點和解決思路.最后，就遙感數據基礎設施設計和實現過程中涉及到的數據收集與整合、數據組織與管理、數據服務接口、按需數據處理等方面的技術方案進行了深入的討論.在這些技術的支持下，遙感數據基礎設施能夠做到分布化、智能化和平臺化，支持遙感科學的合作研究和工程上的協同應用.

數據基礎設施；遙感大數據；按需處理；數據集成；數據管理

隨著遙感技術的不斷發展進步，新的遙感衛星不斷發射，新的傳感器不斷投入使用，遙感數據的時空分辨率越來越高，遙感數據的種類和數量也在不斷增加.例如，2015年歐空局(Europe Space Agency, ESA)存檔的遙感數據量就已經達到了1.5PB，而且這個數字還在不斷增加.與此同時，計算能力的不斷提升使得全球范圍的復雜模擬已經成為可能.這種數據和計算能力上的雙重進步為遙感科學的發展提供了更好的條件，也為遙感科學基于“第四范式”進行基于大數據分析的研究提供了可能[1].

大數據，指無法在一定時間范圍內用常規軟件工具進行獲取、管理和分析處理的數據集合，其主要特點可以用5V來描述，包括Volume(數據量巨大)、Velocity(高速積累)、Variety(種類多樣)、Value(價值密度低)、Veracity(數據質量難以保證)[2].這些特性大多數能夠在遙感數據中得到體現[3].首先，在數據量巨大之外，各種歷史和技術原因導致遙感數據還具有非常明顯的異構特性：不同傳感器、不同衛星平臺、不同數據格式、不同存檔結構等.同時，遙感數據經常需要被高速處理，尤其是那些諸如災害預警和響應、全球制圖、高分辨率實時反演這樣的實時或準實時遙感應用.所以，遙感數據被認為是一種比較典型的大數據，遙感數據分析應用也被視為一種大數據應用，解決遙感數據的收集、整理、管理、存儲、分析、處理、分發等過程中所遇到的一系列技術難題，為地學研究工作者提供遙感大數據的管理與按需處理服務，對于基于遙感數據的地學研究具有非常重要的意義.

隨著遙感數據在種類和數量上的不斷增加，以及遙感應用場景的不斷復雜化和個性化，遙感數據基礎設施在存儲容量、訪問時間、可擴展性、數據安全性、數據服務質量等方面面臨著巨大的挑戰.一方面，在傳統的政府主導的公益應用中，數據時空分辨率的不斷提高帶來了數據量和計算量的急劇增加，面向國家、區域和國際的環境變化、社會、經濟等重大問題以及面向災害和災難等嚴重突發事件的各種遙感數據應用不斷給遙感數據存儲服務系統提出更高的要求.衛星、無人機、地面傳感器的觀測能力也已經達到PB量級，基本具備了逐日的米級觀測的能力.在這種情況下，以集中式離線和準在線方式進行遙感數據存儲與服務的傳統數據基礎設施已經遠遠無法滿足當前與未來遙感數據存儲、共享與應用的高速、海量、安全、穩定和合理成本等要求.數據基礎設施已經成為遙感數據應用這個木桶中的低木板.

另一方面，在地理信息系統和定位導航等技術逐漸商業化公眾化之后，遙感數據觀測與服務也正在從政府主導的公益應用向公眾與商業機構主導的商業與公眾應用擴展.商業與公眾應用逐漸成為遙感數據觀測與服務的主要用戶.以Google為例，2004年收購Keyhole公司并推出了谷歌地球(Google Earth)，2008年收購了ImageAmerica并開始啟動專用衛星系列的發射，2014年收購了微小衛星云廠商SkyBox，形成了自己強大的全球亞米級高分辨觀測能力.除此之外，一些具有強烈個性化色彩的遙感數據觀測應用也不斷出現，例如，期貨公司通過沙特儲油罐連續圖像的反演來估算沙特的石油產量進而估計歐佩克的產量,從而為期貨貿易提供指導，通過衛星影像跟蹤進出富士康的貨車數量來估算Apple產品產量和半導體市場價格等.

以Google為代表的業界巨頭們的一系列動作代表了公眾和商業機構拓展遙感數據應用市場的決心，同時也預示著遙感數據基礎設施將必須為適應這些商業與公眾應用的需求而做出相應的變化.除了和公益應用類似的高速、海量、安全、穩定和合理成本等要求之外，商業與公眾應用的多樣化特性也給遙感數據基礎設施提出了具有強烈個性化色彩的多樣化的遙感數據存儲服務需求，傳統的以收集數據為主要目標的、離線低速和手段單一的數據基礎設施遠遠無法滿足公眾的遙感數據處理需求對數據存儲和管理的更高更個性化的要求.地球觀測的公眾化不僅在工程層面對于地球觀測的傳感器、平臺、通訊、地面單元和應用模式提出了巨大的挑戰，也在科學層面對地球觀測的基本理論和模型提出了新目標，進而在管理層面對于地球觀測的政策、管理和可持續發展模式都提出了新的問題.遙感數據基礎設施必須針對這些挑戰從遙感數據的認識、組織、管理、存儲、分發、處理等諸多方面予以回應.

針對這些挑戰，學術界和業界已經在數據的組織、管理與服務等方面做出了一些努力，開放地理空間協會(Open Geospatial Consortium, OGC)在數據管理與服務方面的系列標準就是這些努力中影響比較大的一個.Web Coverage Service,Web Feature Service,Web Map Service,Catalogue Service,Web Map Tile Service,OpenSearch Geo等組成了通過HTTP實現數據共享和服務的一組標準化共享協議，用以支持不同組織不同類型的空間觀測數據的有序共享和發布[4].世界上最主要的對地觀測政府間合作組織地球預測組織(Group on Earth Observations, GEO)在其2005—2015十年規劃中所建立的Global Earth Observation System of Systems (GEOSS)試圖通過在多個機構組成的聯邦內部制定或采用標準的協議進行觀測數據與模型數據的共享服務與訪問，并通過Clearinghouse、Registries、處理服務、工作流等實現數據之間的有機協調，將聯邦內部各機構所提供的數據組織到一起，形成全局數據視圖，最終達到協同解決科學與現實問題的目標[5].目前，GEOSS的數據基礎設施已經支持了災害、全球變化、水、農業、能源等9個領域的應用.

除此之外，在不斷發展的信息科學技術的推動下，網格、云等各種現代分布式計算的研究成果也不斷被應用到遙感數據基礎設施之中.例如，Cossu等人在ESA的網格項目支持下建立的用于高速遙感數據共享與處理的機遇網格的遙感數據服務環境G-POD[6]，GEO的基于網格的數據共享的探索與實踐[7]，Li等人在空間信息網格(SIG)的支持下建立的跨組織共享和分發空間數據的新型數據服務系統[8]，Huang在網格和數據密集型計算技術支持下基于按需數據服務和元數據適配器構建全局統一視圖的新型遙感數據基礎設施的探索[9].隨著云計算技術的不斷發展，云存儲和MapReduce計算模型等的成熟，雖然云計算在性能和安全性等方面還存在一些不足[10]，但其優秀的并行處理能力和可管理特性使得云計算技術在遙感數據管理方面得到越來越多的應用.其中最有代表性的事件當屬NASA 將其部分數據服務轉移到亞馬遜的AWS 平臺之上，并結合亞馬遜提供的計算資源和工作流管理工具建立了NASA NEX 平臺[11]，用來提供數據服務、高性能計算服務和科學工作流支持.

但是，目前的遙感數據基礎設施研究大多數還處于將已有的遙感數據通過標準的接口進行共享和分發的階段，其解決的問題是如何將已有的已經按照傳統的離線、低速的管理模式進行存檔和管理的數據以標準化的方式進行共享，并沒有涉及到提高數據存儲能力、降低數據訪問時間、提高數據服務質量等遙感數據基礎設施迫切需要解決的技術問題，對于個性化、高維度、時空連續的數據服務需求所需要的對遙感數據在組織理論和管理方法上的變革更是沒有涉及.

本文首先從遙感數據的本質出發，討論了地學科學研究對遙感數據集成與服務的需求，并根據所提供服務能力的不同對遙感數據基礎設施予以分類；然后，針對各種不同類型的遙感數據基礎設施，本文給出了可行的體系結構，并針對服務實現過程中會遇到的一系列問題給出了解決方案；最后，本文還對遙感數據基礎設施的未來發展提出了展望.

1 遙感數據與遙感數據基礎設施

Fig. 1 Classical storage and management of remotesensing data圖1 傳統的遙感數據存儲與管理方法

在傳統的遙感數據基礎設施(或者稱為遙感數據服務)中，數據被認為是一些互相孤立的實體，這些實體使用元數據說明其空間位置、描述時間、光譜、波段、專題等特性，并以一定的格式(一般以文件的形式)存儲、分發和處理，如圖1所示.在使用時，應用通常通過某種接口對存儲在空間機構的元數據進行查詢，在已有的數據中找到合適的數據集并篩選出需要的數據實體，再經過一個數據準備階段之后，將按照一定格式打包的空間數據下載到本地，供下一步的處理和可視化工作使用.

這種遙感數據的存儲與管理體系簡單、實用、易于實現，是當前遙感數據存儲與管理最常見的方法.但是，這種存儲與管理體系存在著很多弱點，比如不能反映遙感數據的本質、只能簡單地將已有的數據予以共享而無法實現數據的按需服務、從不同數據中心獲取數據可能需要使用不同的接口、數據的訪問時延比較長等.

從本質上來講，各種遙感數據都是客觀世界的映像，反映了客觀世界中某時空區間內的某種特性.因此，遙感數據應當具有用來表征空間(位置)、時間和被觀測特性的3類維度.空間包括3個維度，用來標識數據反映的客觀世界的位置，時間有1個維度，用來說明數據反映的客觀世界的某個特定時刻(或時間區間)，被觀測特性可以包括傳感器類型、波段類型、專題類型等多個可能的維度，這些特性可能具有一定的相關性，需要在分析其相關性的基礎上最終歸納為幾個確定的維度.

對于某個確定的時間、確定的空間位置和確定的被觀測特性，客觀世界一定有一個確定的值與之對應.例如，在2016年2月12日北京時間2:10:10(確定的時間)，我的辦公室窗外(確定的位置：40°00′08.0″N，116°20′01.4″E,60m.a.s.l)的氣溫(確定的被觀測特性)是2.1℃(一個確定的值)，窗前是一片落葉的樹木(地表分類這個被觀測特性為某個確定值).

在確定了空間、時間和被觀測特性3類維度之后，客觀世界就能夠被映射到由這3類維度組成的一個連續的高維數據空間之中，這個高維數據空間中的每一個點都對應于客觀世界某位置某時間某被觀測特性的觀測值.通過在這個高維連續數據空間中的各個維度定位，我們就可以尋找到需要的對客觀世界的觀測結果.這個過程可以由一個多元函數來表示：

f(latitude,longitude,altitude,time,characteri-stics)→value.

例如，我們前面給出的例子就可以表示為：

f(40.0022,116.3336,60,1455214210000,“temperature”)→2.1.

既然遙感數據的本質是這樣一個多元函數，那么針對這個函數最常見的2個操作getValue和findArea就應該是遙感數據服務的基本操作.其中，getValue用來根據指定的特定時間、位置和被觀測特性取得一個確定的整數、浮點數或者字符串等數據類型的觀測值.其函數原型可以描述為：

valuegetValue(pos,time,characteristics);

或者批量讀取觀測值以取得更好的服務性能：

valueArraygetValues(area,timeSpan,charac-teristicsList);

反之，從指定的空間區域中查找符合某種條件(例如地表氣溫高于零度)的子區域也是非常常用的一個操作：

areafindArea(area,condition).

不考慮服務性能，getValue和findArea兩個操作足以滿足各種遙感應用對數據基礎設施的需求.在這2個操作中，getValue更加適用于柵格數據，而findArea更加適用于矢量數據.

總的來講，遙感數據基礎設施面臨著如下3種主要挑戰：

1) 分布與異構.遙感數據通常由遍布全球的各個空間機構所擁有和保存，這些數據在數據格式、管理方法、訪問方法和數據政策等方面體現出明顯的異構性.考慮到遙感數據通常具有非常大的數據量，通過廣域網傳輸遙感數據將帶來非常大額時間開銷，所以將這些分布于全球不同空間機構的異構遙感數據組織在一起成為一個有機的整體并提供數據服務將是一件非常復雜的事情.

Fig. 2 Available data fragment in the high dimensionaldata space圖2 高維遙感數據空間中的已有數據碎片

2) 數據缺失.理想情況下，遙感數據應當覆蓋全球任何時間、任何地點和任何觀測特性.但是對全球任何時間、任何地點和任何觀測特性進行觀測并將得到的遙感數據存儲起來和提供服務是不現實的，也是沒有必要的.從數據空間來看，從各種傳感器和遙感數據分析模型得到的遙感數據實際上只是高維的遙感數據空間中的一些碎片(如圖2所示)，理想的遙感數據基礎設施應當能夠通過插值或反演等數據處理的手段以這些數據碎片為基礎重建出整個數據空間中的所有數據，從而達到彌補缺失數據的目的.

但是，這種重建也受到很多限制.首先，由于插值和反演等遙感數據處理算法的缺乏，并不是所有的缺失數據都能夠通過插值或反演等遙感數據算法得到重建.其次，由于插值和反演等遙感數據處理無論在處理模型上還是在處理精度上都存在不確定性，通過插值和反演等數據處理得到重建的缺失數據可能在精度和準確程度上有著一定的不足.最后，插值和反演算法需要的巨大計算量也對遙感數據基礎設施提出了更高的計算能力需求.

3) 服務效率.由于遙感數據的數據量大，處理方法多樣且復雜，遙感數據基礎設施對于高性能、高吞吐率和低成本的要求非常迫切.同時，越來越多的全球范圍的數據共享、覆蓋全球范圍的遙感應用以及跨越地域和組織的協同研究使得高帶寬和低時延的遙感數據傳輸也顯得非常重要.

在目前遙感數據的使用模式中，遙感數據的處理通常是在用戶所在的遙感數據處理工作站上使用用戶提供的處理程序完成的，這就需要將原始的遙感數據從數據提供者通過廣域網傳輸到用戶的遙感數據處理工作站上.由于遙感數據的數據量通常比較大，通過廣域網絡傳輸遙感數據所需要的時間也比較長，這就帶來了一些額外的時間開銷.因此，在遙感數據提供者一端提供按需處理的能力，允許用戶將他們的數據處理模型提交到服務端運行，直接得到他們需要的處理結果，對于減少額外的數據傳輸開銷，提高工作效率有著很大的意義.

除此之外，遙感數據基礎設施還面臨著一系列其他挑戰，如服務性能、可管理性和數據質量控制等.其中，數據質量管理對遙感數據基礎設施非常重要.遙感數據基礎設施中的數據質量問題可以被簡化地視為服務所提供的數據與被觀測實體實際數據之間的差異，它可能來自于傳感器的誤差、數據處理過程中的人為失誤或者計算模型帶來的系統誤差等.用戶反饋與數據溯源是被用來解決數據質量問題的常用手段.根據用戶對數據基礎設施所提供數據的主觀評價，數據基礎設施可以根據對原始數據和數據處理模型進行溯源，并更進一步對于存儲的數據和處理模型的可信性和可靠性進行進一步的評價.

作為一種通過虛擬化實現動態可伸縮的大規模計算資源、存儲、平臺、軟件的管理并通過因特網為用戶提供服務的技術手段[12]，云計算可以被認為是一種解決服務性能和可管理性的可行方案.同時，指令級并行、線程級并行、集群計算、分布式計算等各種高性能計算方面的技術，以及高性能網絡傳輸方面的研究成果都能夠被用于提高遙感數據基礎設施的性能.

總結起來，理想的遙感數據基礎設施應當具有如下特征：1)以有語義特征(如波段、區域)的遙感數據對象而不是原始的遙感數據文件為基本服務對象；2)將分布異構的遙感數據集成到一起并提供統一的服務接口；3)支持通過插值或反演等方法生成缺失的遙感數據；4)實現按需的遙感數據處理以支持用戶上載其數據處理模型在數據端按需處理遙感數據.根據遙感數據基礎設施的基本服務單元、分布性、時空連續性、按需處理服務能力等特性，遙感數據基礎設施可以被分為6類，如表1所示：

Table 1 Classes of Remote Sensing Data Infrastructures表1 遙感數據基礎設施的分類

由于實現簡單，第Ⅰ類遙感數據基礎設施是目前最為常見的集中式遙感數據服務.這類遙感數據服務通常只能以景或條帶為單位提供存儲在一個單一的存儲系統(文件系統或數據庫)中的遙感數據，這些遙感數據被用戶以其原始的影像文件的形式下載使用.而第Ⅱ類遙感數據基礎設施目前存在少量可用的實例(如“綜合定量遙感產品服務規范與運營系統”中的“分布式衛星數據服務系統”).它們在第Ⅰ類的基礎上增加了分布性和異構性，允許將多個地理上分布的異構遙感數據源通過一系列的中間件整合為一個整體提供服務，但其服務基本單元依舊是以景或條帶為單位的原始的影像文件.

第Ⅲ～Ⅵ類遙感數據基礎設施通過遙感數據的剖分與拼接，試圖實現更加本質化的遙感數據服務接口，即以遙感數據對象(如波段、Bounding Box等)為基本服務單元，根據用戶的需求將預先剖分好的數據拼接為用戶需要的遙感數據對象，并返回給用戶.目前有一些基于地理信息系統(geographic information system, GIS)的遙感數據服務實例可以被視為第Ⅲ類遙感數據基礎設施，OGC的WCS和WFS是這些服務常見的服務接口.其余幾類遙感數據基礎設施由于其復雜性目前尚無廣泛使用的實例.其中，第Ⅳ類遙感數據基礎設施在第Ⅲ類的基礎上增加了分布和異構特性，第Ⅴ類則以差值和反演等方法在第Ⅳ類的基礎上增加了對遙感數據基礎設施的時空連續性的支持，第Ⅵ類基礎設施則通過對遙感數據數據分析處理模型的統一描述與調度在第Ⅴ類基礎設施的基礎上增加了對按需服務的支持，允許用戶將其處理分析模型上傳到服務平臺對遙感數據進行處理并得到處理結果，是我們所期待的理想的遙感數據基礎設施.OGC的WCPS(Web coverage process service)定義了一系列用于對Coverage進行按需處理服務的WCS擴展[13]，為實現第Ⅴ類和第Ⅵ類基礎設施進行了一些非常有益的探索.

2 體系結構設計

由于復雜程度的不同，不同類型的遙感數據基礎設施需要不同的體系結構設計.對于第Ⅰ類遙感數據基礎設施來講，圖3所示的體系結構就足以滿足要求.在該體系結構中，用于說明遙感數據獲取時間、覆蓋范圍、衛星與傳感器等特性的元數據被存儲在數據庫中，用戶可以通過一個圖形用戶界面或者基于Web的用戶界面對這些元數據進行查詢，根據諸如覆蓋范圍、獲取時間、衛星與傳感器名等條件找到合適的遙感影像，并通過HTTP或FTP等協議以文件的形式下載這些遙感影像用于進一步的分析處理.

Fig. 3 Architecture for data infrastructures in class Ⅰ圖3 第Ⅰ類遙感數據基礎設施的體系結構

在這個過程中，第Ⅰ類遙感數據基礎設施會為用戶提供諸如query(area,timeSpan,characteristicsList)和access(dataID)的API用于遙感影像數據的查詢與下載.其中，query用于從元數據庫中根據數據覆蓋范圍、獲取時間、觀測特性(衛星、傳感器、觀測主題)等條件查詢元數據，并將查找到的元數據返回給用戶以供選擇.在用戶得到這些返回結果之后，即可從中選取合適的數據，使用其數據ID作為參數調用access，啟動數據獲取過程，請求數據源準備對應的影像數據并將其以HTTP或FTP服務的形式提供下載.

圖4中所展示的2種體系結構都可以將圖3所示的第Ⅰ類遙感數據基礎設施增加分布和異構特性，從而形成第Ⅱ類遙感數據基礎設施.由于遙感數據文件數據量巨大，數據傳輸的時間開銷比較大，所以遙感數據文件通常被用戶直接下載以避免多次數據傳輸帶來額外的開銷.

Fig. 4 Architecture for data infrastructures in class Ⅱ圖4 第Ⅱ類遙感數據基礎設施的體系結構

分布式的遙感數據基礎設施主要解決的是元數據的收集、整理、組織和集成服務問題.根據元數據集成方式的不同，第Ⅱ類數據基礎設施可以有“在線”和“離線”2種實現方式.“離線”方式周期性地從數據提供者將元數據收集到一起，形成一個定期更新的中央元數據庫(這個中央元數據可能是分布可擴展的)，并依靠此中央元數據庫為用戶提供元數據的查詢服務(圖4(a)).“離線”方式服務性能較高，但元數據的定時收集使得數據基礎設施在數據提供者的元數據修改時會出現部分的元數據不一致.例如，在元數據被收集之前，數據提供者最新獲取的遙感影像數據無法被用戶查詢使用.

與之相反，“在線”方式并不保存和維護中央元數據庫，而是通過“在線”翻譯和轉發用戶對元數據的查詢請求和數據源的查詢結果的方式來形成一個虛擬的中央元數據庫，從而達到將分布式異構數據組織到一起提供一站式服務的目的(圖4(b)).“在線”方式不會出現“離線”方式有可能出現的元數據不一致的現象，但是由于用戶的每次查詢請求都會被轉發到所有數據源，查詢的效率較低，對數據源的壓力也比較大.

考慮到遙感數據一旦存檔就不應當再被修改和刪除的特性，“在線”方式和“離線”方式可以被結合起來使用，通過“離線”方式中周期性更新的中央元數據庫來提供高性能的查詢服務，并減少對數據源的查詢請求；同時對于那些尚未得到收集的元數據以“在線”的方式進行實時的轉發，以保證元數據查詢結果的全局一致.

無論“離線”方式還是“在線”方式，第Ⅱ類遙感數據基礎設施通常提供和第Ⅰ類遙感數據基礎設施類似的query()和access()等API用于遙感影像數據的查詢與下載.由于各遙感數據源通常使用不同的協議提供其元數據的查詢服務，所以第Ⅱ類數據基礎設施必須使用諸如元數據適配器等方式將這些遙感數據源之間的異構性予以消除，以達到一站式服務的目的.

在第Ⅰ類和第Ⅱ類數據基礎設施中，遙感數據以原始的影像文件的形式存儲和提供服務.在這種情況下，獲取某特定區域或波段的遙感數據就必須要經過2步：1)從遙感數據基礎設施中找到并下載包含指定區域的遙感影像文件;2)從下載的遙感影像文件中抽取出需要的區域或者波段的數據.這時，第1步下載到的數據中就存在無用的部分，也就是說出現了冗余的數據傳輸.例如，在運行全球干旱指數分析時，只有Band2,Band6和BandState三個波段被用于NDVI算法分析，這就意味著下載的MOD09數據的13個波段中超過34的數據是無用的.這種無用的數據傳輸帶來了額外的網絡傳輸開銷，降低了遙感數據處理過程的效率.

為了避免第Ⅰ類和第Ⅱ類數據基礎設施中這種額外開銷，其他幾類數據基礎設施不再使用原始的影像文件作為基本的數據服務單元，而是直接給用戶提供合適的遙感數據對象(如某個區域某個傳感器的遙感數據).為了達到此目的，這些遙感數據基礎設施首先必須針對不同的分辨率(如10 km、1 km、100 m等)定義一套網格分劃體系，將整個地球劃分為一系列的基本網格.原始的遙感數據將根據定義的分劃體系被分割為一系列分片數據，并存儲在數據庫或文件系統中.當用戶發起服務請求時，這些分片數據將被根據用戶給定的需求拼接，形成遙感數據對象交給用戶.

為了達到以遙感數據對象為基本服務單元的目的，第Ⅲ類和第Ⅳ類遙感數據基礎設施應當采用圖5所示的基本體系結構.原始的遙感數據應當按照基本網格分割為分片數據后再存儲，這就使得數據分割和數據拼接成為第Ⅲ類及以上的遙感數據基礎設施必須具備的功能.

Fig. 5 Architecture for data infrastructures in class Ⅲ and Ⅳ圖5 第Ⅲ類和第Ⅳ類遙感數據基礎設施的體系結構

由于其數據地理上的分布性，第Ⅳ類遙感數據基礎設施中數據分割和拼接的實現要比第Ⅲ類基礎設施復雜.首先，數據的分割要在原始數據存儲的節點“附近”進行，從而避免大量原始數據通過相對來講帶寬較低延遲較高的廣域網絡傳輸，提高數據分割的效率；其次，數據基礎設施必須從各個分布于廣域網上的不同存儲節點收集分片數據，這種跨越廣域網的數據收集會給數據基礎設施帶來額外的數據傳輸開銷.因此，在第Ⅳ類遙感數據基礎設施中，如何對分片數據進行合理的冗余復制和存儲優化，以使得遙感數據基礎設施在使用這些分片數據時能夠在比較“近”的存儲節點上獲得，從而減少分片數據傳輸所需要的時間開銷，將是對提高基礎設施的數據服務性能非常有意義的一個問題.

另外，第Ⅲ類及以上的遙感數據基礎設施應當在提供的API上也與第Ⅰ類和第Ⅱ類基礎設施有所不同.由于第Ⅲ類及以上的遙感數據基礎設施以遙感數據對象為基本服務單元，那么這些服務提供第1節中所列出的getValue()和findArea()這些操作作為其編程接口就顯得非常自然了.在這些編程接口的支持下，用戶(或客戶端)可以根據覆蓋范圍、數據采集時間、觀測要素等條件直接獲得需要的數據.和第Ⅰ、Ⅱ類服務所提供的查詢-獲取-下載的服務方式相比，這種服務方式更加簡潔、方便，同時也避免了冗余數據傳輸帶來的額外開銷.

和前幾類服務相比，第Ⅴ和第Ⅵ類基礎設施更加依賴于高性能按需計算.在第Ⅴ類基礎設施中，當用戶發起的數據請求由于數據缺失而無法完成服務時，數據基礎設施不再是簡單地返回一個代表“數據不存在”的說明信息，而是試圖找到合適的相關數據，通過預先部署好的插值或反演算法從這些存在的相關數據中將用戶需要的數據重建出來，并返回給用戶,如圖6所示：

Fig. 6 Architecture for data infrastructures in class Ⅴ圖6 第Ⅴ類遙感數據基礎設施的體系結構

由于將任何時間任何地點任何觀測目標的數據一律予以存儲是不可能的，也是沒有必要的，因此，遙感數據基礎設施中的數據缺失問題也是不可避免的，第Ⅴ類數據基礎設施中對缺失數據的重建對于遙感數據基礎設施的使用者來講有著非常重要的意義.這種對缺失數據的重建則依賴于那些預先部署好的插值或反演算法，算法越豐富和精確，數據基礎設施對確實數據的填補能力也越強，填補得到的數據也越準確.

在填補缺失數據的同時，第Ⅴ類數據基礎設施的數據重建也會帶來一系列其他問題.首先是數據的可信性.由于數據插值和反演算法不可避免地存在各種系統誤差，這些算法得到的數據和客觀世界的真實數據不可避免地存在差異.為了使用戶能夠更加準確地了解這些差異，方便用戶對數據質量進行更加精細的控制，第Ⅴ類數據基礎設施必須為用戶提供詳細的數據溯源信息，包括原始數據的來源和插值反演算法的實現方法等.在這個過程中，數據溯源模型(data provenance models)可以被用于對數據的可信性和質量進行跟蹤.

另外，插值和反演算法一般計算量都比較大，對于計算資源的要求也比較高，這就使得第Ⅴ類數據基礎設施通常需要比較強大的計算資源支持.與之類似，對插值和反演算法的優化對于降低插值和反演帶來的開銷、提高數據服務效率也會有一定的幫助.另外，更好的調度算法可以尋找距離已有數據更“近”、性能更高的節點進行數據插值或反演處理，從而降低數據傳輸和處理的時間開銷，達到提高數據基礎設施整體性能的目的.

更進一步，當數據基礎設施中配置了大量的通用計算資源，而且允許用戶將遙感數據分析模型以源代碼等形式上傳到這些計算節點上時，用戶就可以直接在這些計算節點上根據需要對遙感數據基礎設施中存儲的數據進行處理，并將計算結果展示給用戶.在這種情況下，用戶就無需再將原始數據下載到本地的工作站進行數據處理，從而避免了大量的原始數據在網絡上傳輸所帶來的時間開銷.這就是提供按需數據處理能力的第Ⅵ類數據基礎設施.配合一定的數據分析模型管理服務，用戶可以使用第Ⅵ類數據基礎設施提供的數據服務能力和數據處理能力，根據其需求靈活地處理各種數據，開發各種遙感應用，實現科學和工程目標.

3 實 現

遙感數據基礎設施的實現依賴于一系列關鍵技術上的突破，例如數據組織與管理、數據收集與整合、按需數據處理等.

3.1 數據基礎設施中的數據收集與整合

在數據基礎設施中，為了提供一站式的遙感數據服務，來自不同空間機構的異構遙感數據，至少其元數據必須被收集到一起并加以整合.由于不同空間機構提供遙感數據及其元數據的方式不同，收集這些數據與元數據的方法也隨之不同，如使用FTP，HTTP或其他網絡協議下載元數據文件，對元數據庫進行復制，使用預定義的網絡協議對元數據進行查詢，通過網絡爬蟲從空間機構提供的Web站點爬取元數據等.

在這些方法中，使用FTP、HTTP或其他網絡協議下載元數據文件通常需要對元數據文件進行進一步的解析和整理，而且獲得這些元數據文件的難度也比較大；元數據庫的復制通常受限于數據政策而無法實現；使用網絡爬蟲爬取元數據的技術難度較大，而且容易對空間機構的網站造成比較大的壓力.所以，使用預定義的網絡協議對元數據進行查詢和獲取是一種比較靈活、常用和有效的方法.

由于Web的普遍使用，基于HTTP協議的請求-響應模式在網絡應用中非常流行.元數據查詢與獲取的協議也通常基于HTTP和請求-響應模式，以SOAP或RESTful Web服務的形式實現.這些協議通常包括查詢和獲取2類功能.其中，查詢功能根據給定條件查詢元數據庫，并將查詢結果以預先定義的格式予以返回.由于其可擴展性和靈活性，查詢結果通常基于XML或JSON來定義.查詢和獲取通常使用異步訪問模型，例如一個基于SOAP的元數據查詢協議可能包括如下3個分別用來啟動一個查詢、獲取查詢結果和關閉一個查詢的操作：

啟動查詢:Stringquery(Stringrequest);

獲取結果:StringgetDescriptions(StringqueryID,intsize);

關閉查詢:voidcloseQuery(StringqueryID).

在這些元數據查詢操作里，query接收一個查詢條件字符串request，解析這個查詢條件，啟動一個新的查詢，并將查詢的ID作為響應立即返回給用戶.查詢成功啟動后，getDescriptions使用這個查詢ID作為參數，以XML串的形式讀取滿足條件的“下size個元數據項”，直到所有元數據都被讀取或者使用closeQuery關閉查詢為止.

query的參數request以XML格式組織描述，例如一個用于查詢Landsat7衛星、ETM+傳感器、覆蓋北京地區(115.7°E～117.4°E,39.4°N～41.6°N)、采集于2010年最后10 d的查詢串應當如圖7所示.

如圖7所示，參數request主要包括3類條件:第1類是以operator,attr和value三個元素組成的“簡單比較”條件，用于對衛星名、傳感器名、觀測時間、影像云量等觀測參數進行相等、不等、大于、小于、相似于等簡單比較;第2類是以包含一組經緯度最大最小值的bbox元素的“覆蓋范圍邊界”條件，用于對遙感數據的覆蓋范圍進行查詢;第3類條件為“邏輯復合條件”，它使用AND,OR和NOT等邏輯運算連接包括其他“邏輯復合條件”在內的多個條件組成復雜的查詢條件，以滿足用戶多樣化的查詢需求.

Fig. 7 Example for XML description of query conditions

圖7 查詢條件的XML描述示例

query會啟動一個新的查詢并將這個查詢的queryID返回，這個queryID可以被用于調用getDescriptions，以從前向后依次遍歷的方式返回查找到的元數據(如圖8所示)，也可以用于調用closeQuery關閉查詢以釋放查詢占用的系統資源.

Fig. 8 Example for XML description of query results

圖8 查詢結果的XML描述示例

除了查詢之外，基于SOAP同樣也可以定義一個由啟動獲取過程、讀取獲取結果和結束獲取過程3個操作組成的基于XML的異步遙感數據獲取協議：

啟動獲取過程:Stringaccess(StringdataID);

讀取結果:StringgetResult(StringaccessID);

結束獲取:voidcloseAccess(StringaccessID);

這組異步協議用來請求數據提供者根據給定的數據ID準備數據并使該數據上線，允許用戶下載.數據ID通常情況下來自于前述查找協議返回的元數據.當access被調用時，數據源將啟動一個過程，找到用戶需要的數據，在必要時將數據打包并復制到用戶可以下載的區域.同時，access為獲取過程分配一個accessID，這個accessID可以在調用getResult和closeAccess時作為參數.當getResult被調用時，根據數據準備情況的不同，會有不同的結果XML串被返回,如圖9所示:

Fig. 9 Examples for XML description of access results

圖9 getResult的返回結果XML串示例

根據數據準備情況的不同，結果XML串會包含取值為“RUNNING”、“ERROR”或者“OK”的state元素.圖9(a)中所示的“RUNNING”狀態代表數據尚未準備完成，圖9(b)所示的“ERROR”狀態代表數據準備過程中出現了異常，以至于無法提供數據下載，異常原因在caused元素中描述.如果數據準備完成，圖9(c)所示的結果字符串將被返回，其中一組url元素用于指出不同用途的數據對應的下載地址.最后，當數據下載完成后，用戶應當調用closeAccess關閉獲取過程，允許數據源對該獲取過程中使用到的一些資源進行釋放，如釋放數據庫連接、刪除臨時文件等.

3.2 數據組織與管理

遙感數據通常由元數據和影像數據兩部分組成.元數據是用來描述諸如覆蓋范圍、創建時間、數據類型、格式、用途等詳細信息的文本，通常被存儲在數據文件或數據庫中.不幸的是，不同來源不同衛星的遙感數據其元數據的格式和內容相差很大.這些截然不同的元數據描述給元數據的統一組織和存儲帶來了不小的麻煩，定義一種靈活的、可擴展的元數據描述方法成為組織和存儲元數據的必要前提.從靈活性和可擴展性出發，基于鍵值對的文檔是一種能夠更加靈活方便地描述遙感數據的覆蓋范圍、采集時間和衛星傳感器等觀測特性的組織方案.不同種類和來源的遙感數據可以具有不同名稱的鍵值，鍵值的數據類型也可以不同(例如一個字符串、一個數、其他的文檔，或者字符串、數和文檔的列表等).XML和JSON是比較常用的2種元數據傳輸和交換的格式，例如，MODIS數據的元數據可以以JSON和XML格式分別描述如圖10所示：

Fig. 10 Format examples for meta-data exchange

圖10 元數據傳輸與交換格式

在存儲方面，由于元數據的結構過于復雜和靈活，使用對數據結構要求嚴格的傳統關系型數據庫存儲這些元數據顯得有些力不從心.因此，從靈活性和兼容性出發，元數據存儲經常使用NoSQL數據庫進行存儲，例如類似MongoDB的文檔數據庫或者類似Apache Cassandra的鍵值對存儲系統.而且，很多NoSQL數據庫采用分布式的基本體系結構，其存儲規模的水平可擴展性對于存儲數據量巨大的元數據有著明顯的優勢.但是，NoSQL數據庫的數據查詢能力通常較弱，尤其是對于復雜查詢的支持能力不足.為此，我們通常要通過額外建立倒排表或者結構化索引等方式來提升元數據的查詢能力，而這些都會給元數據存儲的實現帶來額外的難度和開銷.

另一種可行的解決方案就是混合使用關系型數據庫和NoSQL數據庫.由于元數據中通常只有少量比較“通用”的域被用于數據查詢，比如衛星名、傳感器名、數據覆蓋范圍、采集時間等，我們可以將這些數據從元數據中提取出來并存儲在關系型數據庫中用于查詢，而元數據的主體依舊保存在NoSQL數據庫中以保證其靈活性.這時，關系型數據庫作為一個“索引數據庫”來使用.

在圖11所示的解決方案中，數據ID、可查詢的域以及一個到NoSQL數據庫的引用指針被保存在分布式數據庫中，同時建立完善的數據索引以提高數據查詢的效率.數據基礎設施可以首先從關系數據庫中根據條件查詢到一組數據ID和到NoSQL數據庫的引用指針，再根據這些引用指針(通常是NoSQL數據庫中的數據ID)從NoSQL數據庫中迅速讀出元數據的全部內容，從而達到快速查詢的目的.

Fig. 11 Hybrid meta-data storage圖11 結合關系數據庫與NoSQL數據庫的元數據存儲方案

另一方面，作為遙感數據主體的影像數據有矢量和柵格2種不同的數據模型.柵格數據是按網格單元的行與列排列、具有不同取值的陣列數據，它使用大小相等、分布均勻、緊密相連的像元(網格單元)陣列來表示空間地物或現象分布的數據組織.柵格數據易于實現，算法簡單，易于擴充、修改，直觀性強，是遙感影像數據常用的表示模型.但是，由于柵格數據需要針對每個網格單元給出觀測值，其數據量比較大，通常以文件的形式存儲在文件系統之中.另外，為了提高柵格數據的訪問效率，一種面向柵格數據的數據管理系統Array DBMS近年來也受到了一定程度的重視.

與柵格數據相反，矢量數據使用點、線、矩形、多邊形、圓和弧線等圖形來描述一個地理實體的空間分布.矢量數據通常結構緊湊、數據量比較小，除了以文件的形式存儲在文件系統之外，還經常以編碼的字符串或BLOB(二進制大對象)的形式存儲在關系數據庫或NoSQL數據庫中.無論矢量數據還是柵格數據，無論這些數據以文件的形式被存儲在文件系統中還是以數據對象的形式存儲在數據庫中，遙感影像數據通常被賦予一個唯一ID，這個ID被用來將影像數據與元數據關聯在一起.

從數據的安全性和高效訪問出發，遙感數據基礎設施可以將元數據和影像數據復制多份并將其存儲在地理上分布的多個不同的存儲節點中，從而避免存儲節點的故障帶來的數據丟失.另一方面，多個不同拷貝也使得遙感數據可以就近訪問，減少傳輸遙感數據所需要的時間；同時多個不同拷貝也可以有效地分散遙感數據查詢與獲取給存儲節點帶來的壓力，提高數據訪問的效率.與此同時，遙感數據基礎設施還可以建設在一些具有良好的可擴展性和伸縮性的分布式存儲系統之上，諸如分布式文件系統、云存儲系統、分布式數據庫等都可以為遙感數據基礎設施提供性能更好、擴展性更強、開銷更低的存儲基礎.

3.3 數據服務接口

從本質上來說，遙感數據基礎設施的最基本任務是根據用戶給出的時間、空間、觀測特性等條件，找到符合其需求的遙感數據并提供給用戶.所以，數據服務最基本的接口應當是用來根據給定的時間、空間位置和觀測特性返回確切觀測值(整數、浮點數、字符串或者空值等)的getValue，猝發返回一個時間范圍和空間區域(多數情況下是一個矩形)內大量數據以提高服務性能的getValues，以及在指定時間、指定區域內尋找某項或某幾項觀測值符合指定條件的子區域的findArea.這些服務功能接口的原型可以表示如下：

valuegetValue(position,time,characteristics);

valueArraygetValues(area,timeSpan,char-acteristicsList);

areafindArea(area,conditions).

在這些功能接口中，position應當是一個用經緯度等方式描述的確定地點；time是一個確定的時間，timeSpan是由開始時間和結束時間所指定的一段時間間隔；characteristics用來指明觀測特性(如衛星、傳感器、波段等)，characteristicsList則是觀測特性的一個列表；area是感興趣的區域，通常用多邊形甚至矩形來描述；conditions是一個復雜的條件選項，其結構和功能與3.1節中query的request參數相仿.

很明顯，前述幾種服務功能是建立在以遙感數據對象為基本服務單元這個前提下的，而以影像文件為基本服務單元的第I類和第Ⅱ類數據基礎設施就無法提供這些服務功能接口.對于第I類和第Ⅱ類數據基礎設施，其基本服務功能應當圍繞影像數據文件的查找和獲取來提供.因此，用來查詢可用遙感數據的query和用來獲取遙感數據文件以供下載的access應當是第I類和第Ⅱ類數據基礎設施最基本的服務功能.這些服務功能接口的原型可以表示為：

MetaDataListquery(conditions);

AccessResultaccess(dataID).

其中，conditions為條件選項，MetaDataList是以元數據列表形式描述的查詢結果；dataID是從元數據中分離出來的數據唯一ID，AccessResult則用來描述數據獲取得到的結果，包括數據能否下載、哪些用途的數據能夠從哪個URL下載等.除此之外，遙感數據基礎設施還有可能提供諸如根據給定條件統計數據的條目數和數據量等更多的附加功能以方便用戶的使用.

在Web的基礎上，基于XML,SOAP,WSDL,UDDI等一系列標準協議，Web服務由于其出色的平臺無關性、自描述性、可擴展性和靈活性而被廣泛使用于基于Internet的軟件服務，成為目前面向服務的體系結構(service oriented architecture, SOA)最常見的實現方式.使用Web服務技術來提供服務也是遙感數據基礎設施一種比較理想的實現方案.但是，比較復雜的協議，XML解析與驗證等過程也給基于SOAP的Web服務帶來一系列的額外開銷，在一定程度上影響了服務的效率.為此，輕量級的RESTful服務也經常被用來提供高性能的遙感數據服務.

REST即REpresentational State Transfer，是一種互聯網服務的架構原則.RESTful服務將Web服務視為可以由其 URL 唯一標識的資源，使用不同的HTTP方法(如GET,POST,PUT和DELETE)來表示對資源的不同操作(如讀取、新建、修改和刪除).和Web服務明確使用XML作為其編碼基礎不同，RESTful服務可以使用任何表示層編碼協議，如XML,JSON或者普通文本，這就使得RESTful服務的實現更加靈活.RESTful服務的編程模型簡單，諸如JSON等輕量級編碼方案的使用也減少了序列化和反序列化過程的復雜性，提高了服務效率.

Fig. 13 Workflow for on-demand remote sensing data analysis圖13 按需數據處理支持下的遙感數據分析過程

一個RESTful的遙感數據服務可能基于HTTP GET方法提供其getValue操作接口，讀取用戶給出的時間、位置和觀測特性信息，并返回一個諸如17或者226.0這樣的觀測值.例如，一個讀取TERRA衛星、MODIS傳感器、2號波段指定地理位置和時間的觀測數值的HTTP GET命令可能會是：

在某些時候，遙感數據查詢或獲取的操作可能需要比較長的時間，容易引起客戶端程序的阻塞.為此，遙感數據基礎設施也可以將其接口操作以異步化的形式提供.比如，以輪詢方式異步化的遙感影像文件獲取操作可能會將操作access分為3個異步的操作：啟動一個獲取過程的startAccess，讀取獲取結果的getAccessResult和關閉獲取過程的closeAccess.這3個操作分別使用HTTP方法POST,GET和DELETE來調用.基于SOAP的Web服務也可以提供類似的異步化操作接口，以方便用戶的異步服務調用.

3.4 按需數據處理

當前的遙感數據基礎設施普遍停留在簡單地將已有的存檔數據按照原樣提供出來的初級階段，用戶必須將服務所提供的數據通過網絡下載到本地以供繼續分析處理之用.由于這個下載過程通常要通過相對低帶寬、高時延的廣域網，遙感數據的下載通常需要比較長的時間(如圖12所示).

Fig. 12 Classical workflow for remote sensing data analysis圖12 傳統遙感數據分析過程

在大多數情況下，遙感數據處理模型的輸出結果在數據量上要遠遠小于這些處理模型的輸入數據，這就使得“就近計算”成為一種提高遙感數據分析處理效率的有效手段.所謂“就近計算”，就是在遙感數據基礎設施中部署具有比較強大計算能力的計算資源，并且使這些計算資源和遙感數據之間具有高帶寬、低時延的高性能網絡連接(大多數情況下是計算資源和數據資源位于同一個高速局域網之中).這樣，用戶就可以將其處理遙感數據所使用的遙感數據分析模型推送到數據基礎設施所提供的計算節點上按需地部署運行，再將數據量相對比較小的輸出結果通過廣域網返回給用戶(如圖13所示).

遙感數據的按需數據處理將對數據的處理計算從用戶的本地工作站轉移到了遙感數據基礎設施所提供的計算節點之上，一方面可以有效地利用遙感數據基礎設施提供的高性能計算資源對數據進行高速處理，另一方面可以避免海量的原始遙感數據在低帶寬、高時延的廣域網上的反復傳輸，對于提高遙感數據的處理速度有著非常明顯的效果.同時，按需數據處理也能夠給遙感數據基礎設施提供集成的數據處理能力，對于通過數據的插值和反演等操作實現時空無縫化的數據服務非常有利.但是，由于遙感數據分析模型的部署和運行可能依賴于不同的軟硬件環境，如硬件平臺、操作系統、編譯器、支持庫等，這就給遙感數據分析模型的按需部署和運行帶來了一些困難.

隨著虛擬化技術的不斷發展，虛擬機的運行效率不斷提高，其部署和管理也越來越方便，這就給使用虛擬機支持遙感數據分析模型的按需部署和運行提供了一種工程上可行的解決方案.數據基礎設施中的按需數據處理支持模塊可以為用戶提供一系列安裝了基本環境的虛擬機鏡像，用戶可以在這些虛擬機鏡像的基礎上按照其要求進行定制，使之滿足用戶的遙感數據分析模型的部署與運行需求.由于用戶可以在系統提供的基本環境虛擬機鏡像基礎之上進行深度定制，此方案對于遙感數據分析模型的匹配程度非常高，理論上可以支持任何遙感數據分析模型的部署和運行.

龐大的虛擬機鏡像無論在存儲還是在傳輸上對于按需數據處理的實現都是一個不小的負擔.雖然可以通過增量傳輸和存儲以及容器技術等方法來減少傳輸和存儲過程中的冗余，提高系統鏡像傳輸和存儲的效率，但是這種為了靈活性而付出的代價依舊不可小視.另外，基于虛擬機的遙感數據分析模型的種類繁多，運行方法多樣，對這些數據分析模型進行描述和進一步的流程組合將會非常困難.相比起來，基于模型描述的按需數據處理技術就能夠在一定程度上解決這些問題.

限制遙感數據分析模型部署和運行的主要難點在于如何為遙感數據分析模型提供合適的運行時環境.如果能夠有一套標準規范能夠將遙感數據分析模型所使用的運行時環境加以規范描述，從而使得這些運行時環境能夠準確地被復現，對運行時環境的描述就可以被遙感數據分析模型攜帶著上傳到按需數據處理系統中，指導按需數據處理系統選擇和構建合適的運行時環境部署和運行遙感數據分析模型.更進一步，如果遙感數據分析模型能夠被以一套規范的形式予以描述，那么遵照此規范構建的高性能并行運行時環境就可以支持這些遙感數據分析模型的高效運行.而且，規范化的描述也將有利于遙感數據分析模型的遷移、共享和流程化運行.

基于XML和JSON語言的強大描述能力，運行時環境的描述可以基于XML或JSON來規范.例如，一個“安裝有Windows 10 64bits操作系統、Visual Studio 2010編程環境的單機”的環境需求可以用圖14所示JSON或XML文檔描述.

Fig. 14 Examples for runtime environment description

圖14 運行時環境描述的示例

由于按需數據處理帶來的一系列好處，目前已經出現了一些相關的研究.例如OGC的WCPS就試圖定義一種協議無關的處理語言以實現對多維覆蓋的按需抽取、處理和分析[13].另外，論文[14]也試圖將遙感數據處理所需要的工具從用戶所在的工作站遷移到數據提供者一端，以提高數據處理流程的速度.但是這些研究基本上還是處在解決單個問題的階段，并沒有針對遙感數據分析模型的按需部署與應用問題做全景式的分析與探索.

為了驗證按需數據處理為遙感數據基礎設施帶來的性能增益，我們建立了一個簡單的原型系統,并在該原型系統上以基于歸一化水指數NDWI[15]的干旱檢測為典型應用進行了性能測試.該原型系統運行在2臺以千兆位以太網連接的桌面型服務器上，每臺服務器配有一個i5-4570@3.20 GHz CPU,16 GB存儲器和4 TB硬盤.這2臺桌面型服務器中的一臺用來模擬提供按需數據處理功能的數據基礎設施服務端，另一臺用來模擬用戶端的工作站.

Fig. 15 Performance test results of on-demand processing圖15 按需數據處理的性能測試

在該原型系統中，數據處理模型被以Java字節碼的形式描述，并被按需地部署到一個具有JDK和HDF運行庫的64位Windows環境之中，按需數據處理的運行時環境描述采用XML格式.其描述如下：

我們使用從2000—2010年這11年間的4 d中覆蓋h27v05和h27v06的MOD09數據共88個HDF格式的遙感數據作為測試數據，測試數據總量為約6.43 GB，作為處理結果的AWI文件數據總量約483 MB.

根據我們在多個典型網絡環境下進行遙感影像數據下載的測試，通過Internet進行遙感影像下載的數據傳輸率通常在1～10 MBs之間，因此我們使用軟件將數據傳輸帶寬分別限制在1 MBs，4 MBs，10 MBs，以及不做限制(此時的數據傳輸帶寬上限應當是硬件限制的1 Gbps，即125 MBs)進行性能測試.在不同數據傳輸帶寬限制下的性能測試結果如圖15所示，其中Classical表示傳統的數據處理流程，ODP表示按需數據處理.在圖15中，柱狀圖為不同處理方法各步驟所消耗的時間(左上右下斜線部分為數據傳輸與模型部署時間，右上左下斜線部分為模型運行時間)，折線圖為不同處理方法的運行效率(定義為模型運行時間占總時間的百分比).

從圖15中可以看出，無論網絡帶寬高達1 Gbps還是低至1 MBs，按需數據處理都能表現出相對于傳統數據處理方法更明顯的性能增益，數據處理總時間明顯縮短，處理效率明顯提高.和傳統的數據處理方式相比，按需數據處理所需要的總處理時間縮短了60%～90%，而且這種性能增益在低帶寬的網絡環境下顯得更加明顯.

按需數據處理對于遙感數據基礎設施來講具有非常重要的意義.首先，正如本文實驗所證明，按需數據處理將數據的處理過程從用戶端移動到了數據服務端，避免大量原始影像數據通過廣域網絡傳輸帶來的網絡開銷，提高遙感處理的整體效率.其次，分布式的數據基礎設施可以通過對遙感數據分析模型的有效調度，使這些分析模型在盡可能接近數據的高性能計算資源上運行，這種“就近計算”的調度能夠有效地提高遙感數據分析模型的運行效率.最后，更加重要的是，在用戶將遙感數據分析模型推送到遙感數據基礎設施中之后，用戶可以依照其意愿將這些分析模型與其他用戶共享，將來自不同機構的分析模型組織在一起，更好地支持遙感數據的分析和研究.在這種情況下，遙感數據基礎設施就能夠更好地為遙感科學研究和工程應用提供PaaS(platform-as-a-service)和SaaS(software-as-a-service)服務.在這個基礎設施提供的各種基本環境、數據、工具、庫等的支持下，用戶可以方便地開發和共享遙感數據分析模型，實現合作研究和協同應用.

4 總 結

隨著遙感數據量的不斷增加、遙感應用在規模上的不斷擴大和實現上的不斷復雜化多樣化、以及跨地域跨組織合作研究需求的不斷增加，遙感科學與工程應用對于大數據時代的遙感數據基礎設施在地域分布性、可擴展性、可用性、易用性和性能表現等方面的要求越來越高.傳統的遙感數據基礎設施大多數以影像文件為基本服務單元，只能將單一機構的存檔數據通過Web界面等方式提供給用戶查詢和下載，在服務效率和易用性等方面遠遠不能滿足不斷發展的遙感科學與工程應用的需求.

從本質上來講，遙感數據是對客觀世界的數值化反映，是一個由時間、空間和觀測特性所組成的高維數據空間.對于確定的時間、空間和觀測特性，遙感數據應當有確定的取值.相應地，遙感數據基礎設施應當以形式化、規范化的訪問接口，為遙感應用提供以getValues和findArea為代表的數據服務操作，允許用戶根據遙感數據的高維空間各維度的數值直接得到相應的觀測值，或者根據給定的條件在遙感數據的高維空間中確定符合條件的子空間.這樣的遙感數據基礎設施會更加本質和易用.

根據遙感數據基礎設施的基本服務單元、分布性、數據的時空連續性和按需處理支持，本文將遙感數據基礎設施分成了6類，并從系統構造的角度，討論了構建這6類遙感數據基礎設施所應采用的體系結構，指出了各類型遙感數據基礎設施實現的關鍵問題.在此基礎上，本文還就各類遙感數據基礎設施在構建過程中需要考慮的數據收集與整合、數據組織與管理、數據服務接口、按需數據處理等方面的實現方案進行了深入的討論.在這些技術的支持下，遙感數據基礎設施能夠做到分布化、智能化和平臺化，達到數據與處理“存算一體”的目標，并在此基礎上實現遙感數據分析模型的共享和流程化，支持基于大數據的遙感科學合作研究和工程上的協同工作.

[1]Hey T, Tansley S, Tolle K. The Fourth Paradigm: Data-Intensive Scientific Discovery[M]. Redmond, WA: Microsoft Corporation. 2009: 252

[2]Demchenko Y, Grosso P, De Laat C, et al. Addressing big data issues in scientific data infrastructure [C] //Proc of 2013 Int Conf on Collaboration Technologies and Systems (CTS). Piscataway, NJ: IEEE, 2013: 48-55

[3]Ma Yan, Wu H, Wang L, et al. Remote sensing big data computing: Challenges and opportunities[J]. Future Generation Computer Systems, 2015, 51(2015): 47-60

[4]Open Geospatial Consortium (OGC). OGC?Standards and Supporting Documents[OL]. [2016-10-02]. http://www.opengeospatial.org/standards

[5]GEO. GEOSS Core Architecture Implementation Report [OL]. [2016-10-02]. http://portal.opengeospatial.org/files/?artifact_id=24315

[6]Cossu R, Bally P, Colin O, et al. ESA grid processing on demand for fast access to earth observation data and rapid mapping of flood events[G]. Munich, Germany: European Geosciences Union General Assembly. 2008

[7]Sekiguchi S, Tanaka Y, Kojima I, et al. Design principles and IT overviews of the GEO grid[J]. IEEE Systems Journal, 2008, 2(3): 374-389

[8]Li G, Liu D, Huang Z, et al. Spatial data service models in grid environment[C] //Proc of the Int Symp on Parallel and Distributed Processing and Applications. Berlin: Springer, 2006: 598-602

[9]Huang Z C. On-demand data service for the next generation spatial data infrastructure[C] //Proc of the 5th Int Conf on Semantics, Knowledge and Grid. Piscataway, NJ: IEEE, 2009: 286-289

[10]Iosup A, Ostermann S, Yigitbasi M N, et al. Performance analysis of cloud computing services for many-tasks scientific computing[J]. IEEE Trans on Parallel and Distributed Systems, 2011, 22(6): 931-45

[11]NASA. NASA NEX[OL]. [2015-02-28]. http://aws.amazon.com/cn/nasa/nex/ [2015-02-28]

[12]Foster I, Zhao Y, Raicu I, et al. Cloud computing and grid computing 360-degree compared[C] //Proc of 2008 Grid Computing Environments Workshop. Piscataway, NJ: IEEE, 2008: 1-10

[13]Baumann P. The OGC Web coverage processing service (WCPS) standard[J]. Geoinformatica, 2010, 14(4): 447-479

[14]Davis B N, Werpy J, Friesz A, et al. Interactive access to LP DAAC satellite data archives through a combination of open-source and custom middleware Web services[J]. IEEE Geoscience and Remote Sensing Magazine, 2015, 3(4): 8-20

[15]Gao B C. NDWI—A normalized difference water index for remote sensing of vegetation liquid water from space[J]. Remote sensing of environment, 1996, 58(3): 257-266

Li Guoqing, born in 1968. PhD, professor and PhD supervisor. Senior member of CCF. His main research interests include high performance geocomputation, spatial data infrastructure, and digital earth.

Huang Zhenchun, born in 1975. PhD, associate professor. His main research interests include remote sensing data processing, high performance computing, and distributed computing.

Data Infrastructure for Remote Sensing Big Data: Integration, Management and On-Demand Service

Li Guoqing1and Huang Zhenchun2

1(InstituteofRemoteSensingandDigitalEarth,ChineseAcademyofSciences,Beijing100094)2(DepartmentofComputerScienceandTechnology,TsinghuaUniversity,Beijing100084)

The increasing growth of remote sensing data and geoscience research pushes earth sciences strongly and poses great challenges to data infrastructures for remote sensing big data, including the collection, storage, management, analysis and delivery. The de-fact remote sensing data infrastructures become bottleneck of the workflows for remote sensing data analysis because of their capability, scalability and performance. In this paper, data infrastructures for remote sensing big data are catalogued into 6 classes based on the features such as basic service unit, distributivity, heterogeneous, space-time continuation and on-demand processing. Then, architectures are designed for all the 6 classes of data infrastructures, and some implementation technologies such as data collection and integration, data storage and management, data service interface, and on-demand data processing, are discussed. With the architecture designs and implementation technologies, data infrastructures for remote sensing big data will provide PaaS (platform-as-a-service) and SaaS(software-as-a-service) services for developing much more remote sensing data analysis applications. With continuously growing data, tools and libraries in the infrastructures, users can easily develop analysis models to process remote sensing big data, create new applications based on these models, and exchange their knowledge each other by sharing models.

data infrastructure; remote sensing big data; on-demand processing; data integration; data management

2016-11-15；

2016-12-27

國家重點研發計劃項目(2016YFB0501504); 海南省重大科技計劃項目(ZDKJ2016021) This work was supported by the National Key Research and Development Program of China (2016YFB0501504), and the Grant of Hainan Provincial Department of Science and Technology (ZDKJ2016021).

黃震春(huangzc@tsinghua.edu.cn)

TP315