基于Spark的遙感影像金字塔瓦片構(gòu)建

陜唐劍 鐘宏偉 李林輝 魏景琦 國露方

摘 要：隨著傳感器技術(shù)發(fā)展和大容量存儲設(shè)備價(jià)格的下降，遙感影像數(shù)據(jù)量飛速增長并達(dá)到海量存儲的程度，傳統(tǒng)的單機(jī)集中式存儲和檢索技術(shù)已經(jīng)不能滿足數(shù)據(jù)高效存儲和快速訪問的要求。本文在傳統(tǒng)的影像金字塔的構(gòu)建方法上，采用基于內(nèi)存計(jì)算的計(jì)算引擎Spark來構(gòu)建遙感影像金字塔并給出了算法的構(gòu)建過程，實(shí)現(xiàn)了基于Spark的遙感影像金字塔的并行構(gòu)建。實(shí)驗(yàn)表明，相對于傳統(tǒng)的遙感影像金字塔構(gòu)建，性能和計(jì)算效率都有較大提高。

關(guān)鍵詞：遙感影像;金字塔;Spark

文章編號：2095-2163（2019）04-0226-04 中圖分類號：TP751 文獻(xiàn)標(biāo)志碼：A

0 引 言

隨著信息獲取技術(shù)和遙感探測手段的發(fā)展，遙感影像數(shù)據(jù)日益多元化;數(shù)據(jù)量呈指數(shù)級增長，形成GB級、TB級數(shù)據(jù)的大規(guī)模集成態(tài)勢[1-2]。海量的遙感影像數(shù)據(jù)為資源調(diào)查、環(huán)境監(jiān)測提供了豐富的資料，但也需看到，由于數(shù)據(jù)量不斷增大，傳統(tǒng)的單機(jī)集中式存儲和檢索技術(shù)已經(jīng)難于滿足數(shù)據(jù)高效存儲的要求。越來越多的基于遙感數(shù)據(jù)的應(yīng)用不僅需要數(shù)據(jù)的高效存儲和管理，而且還需要將結(jié)果快速反饋顯示到終端上，這些都是目前遙感影像處理中的基礎(chǔ)研究問題[1]。

金字塔模型是實(shí)現(xiàn)海量遙感影像可視化的基礎(chǔ)[3]。如劉義等人[4]將傳統(tǒng)的MapReduce方法加以改進(jìn)，構(gòu)建了適合遙感影像金字塔模型的圖像存儲算法，較傳統(tǒng)單機(jī)構(gòu)建金字塔方法表現(xiàn)出較高的時間效率和較好可擴(kuò)展性;霍樹民[5]提出了一種基于MapReduce并行編程模型的影像金字塔并行構(gòu)建技術(shù)，相比單機(jī)串行方式，遙感影像建塔速度有明顯的提高。上述研究都采用了金字塔模型存儲遙感數(shù)據(jù)，有效提高海量遙感數(shù)據(jù)的存取效率，但構(gòu)建金字塔所用的時間仍然較長，而將其應(yīng)用在實(shí)際研發(fā)設(shè)計(jì)中，數(shù)據(jù)的可視化響應(yīng)較慢，遙感影像處理和顯示的效率也難以達(dá)到令人滿意的程度。因此，亟需對遙感影像數(shù)據(jù)的金字塔構(gòu)建方式做出改進(jìn)，使其性能得以提升，本次研究中即選用了目前較為流行的大數(shù)據(jù)處理技術(shù)。

同時，有研究表明，Spark是基于內(nèi)存的計(jì)算框架，運(yùn)用科學(xué)設(shè)計(jì)，使其對于多次迭代的數(shù)據(jù)處理，比Hadoop快很多倍。Spark的特點(diǎn)是可以把中間數(shù)據(jù)放在內(nèi)存，迭代效率高，而遙感影像的金字塔構(gòu)建過程，就需要多次迭代，并且還要依據(jù)本層的金字塔數(shù)據(jù)生成下一層的金字塔數(shù)據(jù)，但Spark本身卻并不具備對具有空間特點(diǎn)的遙感影像數(shù)據(jù)的處理能力。

綜上分析可知，本文在Spark現(xiàn)有框架基礎(chǔ)上，結(jié)合Spark和遙感影像金字塔構(gòu)建過程的特點(diǎn)，研發(fā)提出基于Spark遙感影像金字塔并行構(gòu)建模型，實(shí)現(xiàn)金字塔瓦片數(shù)據(jù)的分布式存儲，進(jìn)而有效縮短了遙感影像數(shù)據(jù)金字塔的構(gòu)建時間。對此擬做研究論述如下。

1 遙感影像數(shù)據(jù)金字塔存儲方法

遙感影像金字塔是地圖服務(wù)的基礎(chǔ)。地圖服務(wù)包含2方面的內(nèi)容，分別是：格網(wǎng)和編碼的選擇，遙感數(shù)據(jù)的組織和管理。研究后可推得闡釋解析如下。

1.1 全球剖分網(wǎng)格

地圖服務(wù)的指定操作區(qū)域都是矩形，建立遙感影像金字塔和編碼這些矩形的塊。假設(shè)遙感影像的原始分辨率為r0，像素矩陣大小為w×h，原始遙感影像經(jīng)過重采樣被分成了很多大小相等的圖像塊，在金字塔結(jié)構(gòu)中，稱之為瓦片。瓦片的大小為d×d像素，瓦片矩陣的大小為tr×tc。tr可由公式（1）計(jì)算得出：

假設(shè)latitude和longitude分別代表某點(diǎn)的經(jīng)度和緯度，則該點(diǎn)所在的level級的瓦片編碼的運(yùn)算可寫作如下數(shù)學(xué)形式：

1.2 金字塔結(jié)構(gòu)

拼接后的遙感圖像的大小超過300 MB，有時甚至超過10 GB或100 GB，金字塔結(jié)構(gòu)是海量遙感影像可視化的基礎(chǔ)[6]。金字塔的最低層是分辨率最高的，也就是原始圖像，數(shù)據(jù)量最大;隨著層數(shù)的增加，其分辨率逐漸降低，數(shù)據(jù)量也按比例減少。每一層影像金字塔都有其分辨率，當(dāng)在前端進(jìn)行圖像的放大、縮小、漫游時，后臺需計(jì)算出執(zhí)行該操作后所需的影像分辨率及在當(dāng)前視圖范圍內(nèi)會顯示的地理坐標(biāo)范圍，再根據(jù)這個分辨率去和已經(jīng)建好的影像金字塔分辨率匹配，選擇適合的分辨率的瓦片遙感數(shù)據(jù)，將其從后臺取出來顯示給用戶。采用金字塔模型存儲數(shù)據(jù)的優(yōu)點(diǎn)是，當(dāng)對數(shù)據(jù)進(jìn)行顯示操作時，不需要讀取全部原始數(shù)，只需選擇合適分辨率的數(shù)據(jù)進(jìn)行數(shù)據(jù)操作，這樣可以減少數(shù)據(jù)的I/O操作和網(wǎng)絡(luò)間的數(shù)據(jù)傳輸。

通常，影像金字塔的構(gòu)建方法有2種。一種是本身已有的多種分辨率的數(shù)據(jù)源直接構(gòu)建相應(yīng)分辨率的金字塔;另一種是只有原始圖像，而沒有其它低分辨率的圖像，通過已有的遙感數(shù)據(jù)利用重采樣的方式進(jìn)行逐層構(gòu)建。本文中采用的是第二種方法。

從原始影像數(shù)據(jù)中抽取數(shù)據(jù)構(gòu)建金字塔時，形成一個多分辨率層次。從金字塔的底層到頂層，分辨率越來越低，但是表示的范圍卻是一致的。而通過對低一層影像的重采樣建立了本層圖像，通過構(gòu)建不同層的圖像，最終建立了同一范圍、但不同分辨率的一系列圖像層。其中，底層分辨率最高，上層逐漸減少，圖像金字塔如圖1所示。

在金字塔中將原遙感影像數(shù)據(jù)作為最底層數(shù)據(jù)，記為0層，采用等分方式來劃定分塊，每一個數(shù)據(jù)塊稱為瓦片。在金字塔中，一個瓦片可由坐標(biāo)（level，row，col）提供唯一標(biāo)識。其中，level標(biāo)識瓦片所在影像金字塔的層數(shù)，row標(biāo)識瓦片所在的行，col標(biāo)識瓦片所在的列。通過前文設(shè)定，可以對瓦片數(shù)據(jù)進(jìn)行編碼。分層、分塊后所得的瓦片編碼如圖2所示。

對一幅2n×2n的遙感影像進(jìn)行金字塔內(nèi)瓦片數(shù)據(jù)構(gòu)建的過程是從原始影像數(shù)據(jù)開始，按照倍率是4進(jìn)行逐級采樣，接著將得到的遙感數(shù)據(jù)設(shè)定為2m×2m后，再進(jìn)行倍率是4的逐級采樣，由此得到的遙感影像的層數(shù)記為L，則L的數(shù)學(xué)公式可表示為：

采用上面的方法進(jìn)行分層后，可以計(jì)算求出瓦片的數(shù)量T為：

在此基礎(chǔ)上，可以推得計(jì)算瓦片數(shù)據(jù)的存儲空間比單獨(dú)存儲原圖像所超出的百分比的數(shù)學(xué)公式如下所示：

分析后可知，通過金字塔的構(gòu)建后，數(shù)據(jù)存儲所用的空間會比單獨(dú)存儲原數(shù)據(jù)多出三分之一，在大數(shù)據(jù)時代，大容量存儲設(shè)備的價(jià)格較為低廉，因此對于應(yīng)用而言，產(chǎn)生的影響可以忽略。對于瓦片數(shù)據(jù)的大小，沒有固定的劃分標(biāo)準(zhǔn)，在理論上可以按任意大小劃分，但在技術(shù)應(yīng)用層面上存在一些困難，如網(wǎng)絡(luò)傳輸、金字塔索引的構(gòu)建、I/O的效率。如果瓦片數(shù)據(jù)尺寸太大，導(dǎo)致瀏覽遙感影像數(shù)據(jù)時會有多余的數(shù)據(jù)加載到內(nèi)存;如果瓦片數(shù)據(jù)尺寸太小，瓦片的大小多會根據(jù)具體情況和多次實(shí)驗(yàn)來求得，從瓦片求取以及容易建立索引的角度出發(fā)，通常瓦片遵循如下規(guī)則：瓦片數(shù)據(jù)的大小是一樣大小的，瓦片按一定順序存儲。瓦片數(shù)據(jù)的大小在SDE中為128×128像素。在Oracle的GeoRaster中，瓦片數(shù)據(jù)的大小為256×256像素[7-8]，通過實(shí)驗(yàn)，本文中設(shè)置瓦片的大小為256×256像素。

2 基于Spark的遙感影像金字塔瓦片數(shù)據(jù)的并行構(gòu)建

使用Spark進(jìn)行遙感影像的構(gòu)建是基于傳統(tǒng)金字塔構(gòu)建的模型，并在Spark中利用算法將原始圖像通過重采樣，逐層生成瓦片數(shù)據(jù)，具體就是由下層數(shù)據(jù)生成上層數(shù)據(jù)，運(yùn)算產(chǎn)生的中間結(jié)果存于內(nèi)存，最終結(jié)果存入到HDFS中。每層構(gòu)建瓦片數(shù)據(jù)設(shè)定成一個獨(dú)立的任務(wù)，通過Spark在集群中實(shí)現(xiàn)構(gòu)建。根據(jù)Spark的特點(diǎn)，研究推得構(gòu)建生成瓦片數(shù)據(jù)的算法詳述如下。

（1）讀入遙感影像原數(shù)據(jù)，生成Level0層的瓦片數(shù)據(jù)。在研究中，將根據(jù)遙感影像的坐標(biāo)范圍和全球格網(wǎng)劃分方法，確定影像的范圍，再根據(jù)范圍使用公式（8）即可確定此遙感數(shù)據(jù)總共分為多少層。原始數(shù)據(jù)的分辨率不同，遙感數(shù)據(jù)的分層數(shù)也會不同。分辨率高的遙感數(shù)據(jù)所分的層數(shù)要高于分辨率低的遙感數(shù)據(jù)所分層數(shù)。

（2）對每層遙感數(shù)據(jù)進(jìn)行瓦片化的處理。通過對低層數(shù)據(jù)的重采樣，采用倍率為2的采樣得到瓦片數(shù)據(jù)，由上層遙感數(shù)據(jù)的坐標(biāo)可計(jì)算求出每個瓦片數(shù)據(jù)的坐標(biāo)，此過程使用Spark實(shí)現(xiàn)。傳統(tǒng)的大數(shù)據(jù)處理通常采用MapReduce進(jìn)行處理，Spark處理相比MapReduce處理的優(yōu)勢就在于瓦片數(shù)據(jù)的生成是通過rasterRdd計(jì)算得到的，在計(jì)算過程中得到的中間數(shù)據(jù)可以被緩存到內(nèi)存中，且比傳統(tǒng)的構(gòu)建時間要短，這是因?yàn)椴僮髟趦?nèi)存中，從內(nèi)存中就可以直接讀取中間數(shù)據(jù)，而不需要再從磁盤中讀取，這樣做可以減少從磁盤讀取數(shù)據(jù)的次數(shù)，縮短了影像計(jì)算處理的時間，提高了瓦片數(shù)據(jù)的構(gòu)建速度，提高了效率。

（3）瓦片數(shù)據(jù)的屬性確定。通過Spark計(jì)算得到的瓦片數(shù)據(jù)最終存儲到HDFS的各個節(jié)點(diǎn)中，每個瓦片數(shù)據(jù)都有各自的屬性，重點(diǎn)包括每個瓦片數(shù)據(jù)的坐標(biāo)信息、瓦片數(shù)據(jù)所存的具體位置、瓦片數(shù)據(jù)的偏移量。為了做到快速檢索，通常對同一層的瓦片數(shù)據(jù)建立索引，在本研究中則將這些特征存入Hbase中。

（4）瓦片數(shù)據(jù)可視化。通過前述步驟完成了瓦片數(shù)據(jù)的構(gòu)建，但要進(jìn)行可視化時，可以通過需要顯示的影像范圍確定需提取的是哪一層數(shù)據(jù)，再根據(jù)不同層的編碼值對瓦片來執(zhí)行分布式計(jì)算，通過 master 節(jié)點(diǎn)將具體的request分發(fā)到有相應(yīng)資源數(shù)據(jù)的計(jì)算節(jié)點(diǎn)上，計(jì)算節(jié)點(diǎn)通過索引參數(shù)較快地定位原數(shù)據(jù)，進(jìn)而將需要的數(shù)據(jù)返回給用戶。

由于Spark的特點(diǎn)，在對遙感數(shù)據(jù)進(jìn)行瓦片數(shù)據(jù)的構(gòu)建過程中，中間生成的影像數(shù)據(jù)，將會存入內(nèi)存中，進(jìn)而生成高層瓦片，中間處理過程中產(chǎn)生的無用數(shù)據(jù)則無需存入HDFS，減少了I/O操作，提升了構(gòu)建效率，與傳統(tǒng)的基于MapReduce模式的構(gòu)建方式相比，有較大優(yōu)勢。

3 實(shí)驗(yàn)結(jié)果及分析

實(shí)驗(yàn)環(huán)境配置為：Master，選用IBM System x3850 X5（Xeon E7-4807 6核1.87 GHz，16 GB內(nèi)存，500 GB硬盤）。Slave，選用4臺曙光I450-G10（Xeon E5-2407四核2.2 GHz，8 GB內(nèi)存，HDFS總?cè)萘?.34 GB）。通過Xen虛擬化為16個節(jié)點(diǎn)。采用Tenda TEG1 024 G 千兆以太網(wǎng)交換機(jī)連接。操作系統(tǒng)，選用Red Hat Enterprise Linux 6.2（內(nèi)核版本2.6.32），Hadoop版本選用2.5。

將金字塔構(gòu)建算法部署到面向Spark計(jì)算框架和面向 Hadoop MapReduce 計(jì)算框架下的分布式實(shí)驗(yàn)環(huán)境中，實(shí)驗(yàn)中的數(shù)據(jù)源和參數(shù)保持不變，同時保證計(jì)算節(jié)點(diǎn)的資源一致，實(shí)驗(yàn)的數(shù)據(jù)量大小為1 GB、10 GB，實(shí)驗(yàn)的結(jié)果如圖3所示。

通過實(shí)驗(yàn)結(jié)果表明，在數(shù)據(jù)量不大的情況下，Spark和傳統(tǒng)MapReduce的構(gòu)建金字塔數(shù)據(jù)所用時間相差不大，但隨著數(shù)據(jù)量的增大，Spark構(gòu)建金字塔數(shù)據(jù)的優(yōu)勢較為明顯，所用時間較少，因此使用Spark框架進(jìn)行海量遙感影像數(shù)據(jù)的金字塔構(gòu)建在時間上具有更好的效率。

4 結(jié)束語

由于傳統(tǒng)的單機(jī)集中式存儲和檢索技術(shù)已經(jīng)不能滿足數(shù)據(jù)高效存儲和快速訪問的要求，本文采用基于內(nèi)存計(jì)算的計(jì)算引擎Spark來構(gòu)建遙感影像金字塔并給出了算法的構(gòu)建過程，實(shí)現(xiàn)了基于Spark的遙感影像金字塔的并行構(gòu)建。性能和計(jì)算效率都有較大提高。

參考文獻(xiàn)

[1]李德仁，張良培，夏桂松. 遙感大數(shù)據(jù)自動分析與數(shù)據(jù)挖掘[J]. 測繪學(xué)報(bào)，2014，43（12）：1211-1216.

[2] 呂雪峰，程承旗，龔健雅，等. 海量遙感數(shù)據(jù)存儲管理技術(shù)綜述[J]. 中國科學(xué)：技術(shù)科學(xué)，2011，41（12）：1561-1573.

[3] 鄧雪清. 柵格型空間數(shù)據(jù)服務(wù)體系結(jié)構(gòu)與算法研究[J]. 測繪學(xué)報(bào)，2003，32（4）：362.

[4] 劉義， 陳犖， 景寧，等. 利用MapReduce進(jìn)行批量遙感影像瓦片金字塔構(gòu)建[J]. 武漢大學(xué)學(xué)報(bào)（信息科學(xué)版）， 2013， 38（3）：278-282.

[5] 霍樹民. 基于Hadoop的海量影像數(shù)據(jù)管理關(guān)鍵技術(shù)研究[D]. 長沙：國防科學(xué)技術(shù)大學(xué)， 2010.

[6] CHEN Shizhi， TIAN Yingli. Pyramid of spatial relations for scene-level land use classification[J]. IEEE Transactions on Geoscience & Remote Sensing， 2015，53（4）：1947-1957.

[7] LV Xuefeng， CHENG Chengqi， GONG Jianya， et al. Review of data storage and management technologies for massive remote sensing data[J]. Science China Technological Sciences， 2011，54（12）：3220-3232.

[8] LV Zhenhua， HU Yingjie， ZHONG Haidong， et al. Parallel K-means clustering of remote sensing images based on MapReduce[M]//WANG F L， GONG Z， LUO X， et al. Web information systems and mining. WISM 2010. Lecture Notes in Computer Science. Berlin/Heidelberg：Springer， 2010，6318：162-170.