摘要

向量瓦片體積小、生成效率高、支援動態互動，較傳統柵格瓦片有諸多優勢，是下一代網際網路地圖服務研究的重點。為了解決當前向量瓦片研究中處理速度慢，擴充套件性差等問題，本文利用平行計算框架Spark進行向量瓦片快速構建，通過自定義轉換函式，將原始向量資料GeoJson轉換成mvt瓦片集；對於生成的向量瓦片集，本文基於分散式記憶體檔案系統Alluxio設計一個瓦片儲存模型-VectorTileStore，模型以鍵值對進行資料儲存，瓦片元資料佔據前八個鍵值對，單個瓦片佔據一個鍵值對，在資料寫入的同時，基於鍵構建一個雜湊索引，用於快速訪問，模型相容海量瓦片的組織儲存，具有很強的擴充套件性。通過實驗結果表明，本文提出的向量瓦片並行構建演算法較單機構建演算法執行時間平均減少49.6%，分散式儲存模型VectorTileStore較傳統方案更適合海量向量瓦片儲存，存取時間效率更高。

關鍵字

向量瓦片；web地圖服務；並行處理；Spark；分散式儲存；Alluxio

1. 引言

內含多源地理空間資訊的網際網路地圖在諸多領域如林業、海洋、國土、交通、軍事等領域被廣泛運用，與此同時，高精度、覆蓋面大的空間資料爆炸式增長，地理空間大資料時代已經來臨 [1] 。在此背景下，如何快速高效地構建網際網路地圖服務是當前的研究重點與難點 [2] 。

柵格資料及向量資料是地理空間應用的兩種重要的基礎資料型別，與柵格資料相比，向量資料儲存空間小，使用靈活，製圖釋出後仍支援查詢更改操作，並且可以動態更改樣式。在許多地圖服務提供產商中，如谷歌地圖、百度地圖，採取了很多的方式方法來提升線上地圖的訪問效率，其中瓦片技術是最為有效的方法 [3] 。瓦片是指在網路地圖服務中進行地圖瀏覽、查詢、編輯、分析等操作時，對出現的地圖資料按照特定的方式進行預先切圖和儲存，以便在以後訪問同樣的地圖資料時不需要伺服器重新生成，從而提高資料的訪問效率 [4] 。

向量瓦片是將地圖中的向量圖層以瓦片的形式進行切分和儲存，與柵格瓦片相比，向量瓦片體積小、生成效率高、可動態互動、支援線上編輯與樣式的修改，這都是傳統柵格瓦片所不具備的特性 [5] 。隨著地理空間資料的增長，單機儲存、處理速度與網際網路快速響應需求間的矛盾愈加凸顯，將分散式儲存、平行計算等一系列大資料技術應用到空間資料處理成為大勢所趨，在當前研究中，大多數研究人員僅對柵格瓦片的並行構建和分散式儲存進行研究，劉義等 [6] 利用MapReduce進行批量柵格瓦片金字塔並行構建，提升了瓦片構建速度。赫高進等 [7]提出使用MPI的金字塔並行構建演算法,對構建遙感影像金字塔過程中的重取樣與I/O過程進行並行處理,大大縮短了遙感影像金字塔構建時間。Zhang等 [8] 、陳樺等 [9] 基於分散式檔案系統HDFS及分散式資料庫Hbase進行海量柵格瓦片的儲存，保證了大量併發使用者訪問的效能，提高了客戶端瀏覽地圖的速度。在向量瓦片研究方面，陳舉平等 [10] 介紹向量
瓦片地圖技術實現原理、資料標準，對向量瓦片的資料組織模型、資料編碼規則和地圖渲染引擎的關鍵技術進行闡述。張立強等 [11] 對向量地圖視覺化進行研究，提出了基於多核CPU及GPU的向量地圖快速視覺化的方法，在一定程度提升上了向量瓦片的顯示速度，但這種方法是利用專用硬體上進行加速，擴充套件性不強。金澄等 [12] 對向量資料抽稀進行研究，提出一種改進的Visvalingam演算法，解決了最小權重值查詢效率低下及線化簡前後拓撲一致性
保持等問題，為向量資料簡化提供了新方案。朱笑笑等 [13] 提出一種顧及要素空間分佈特徵的稠疏向量瓦片構建方法，使得同一層級向量瓦片間的資料量相對均衡，提升了向量瓦片的載入渲染效率，獲得了較好的使用者體驗，但該研究僅從資料分佈角度進行研究，當瓦片數量很大時，構建速度和儲存組織將成為挑戰。

從上述可見，和柵格瓦片相比，當前對於向量瓦片的研究大多還處在單機小資料量階段，對於向量瓦片的快速構建及分散式儲存研究較少，而向量瓦片較柵格瓦片有諸多優勢，在未來的應用及研究中，如何快速高效地組織海量向量瓦片必將是網際網路地圖服務及GIS技術研究的重中之重。由此，本文旨在加快向量資料的處理速度，提供更快的瓦片訪問介面，對向量瓦片的並行構建及分散式儲存進行研究，利用Spark並行處理框架對原始向量資料進行處理，快速構建向量瓦片mvt；對於產生的海量向量瓦片，提出一種基於記憶體分散式檔案系統的儲存模型-VectorTileStore，通過自定義元資料及瓦片的儲存順序，高效地組織向量資料，為網際網路地圖服務提供快速的資料訪問介面。

2. 向量瓦片解析

2.1 瓦片金字塔模型

瓦片是將特定空間範圍內的地圖資料在某一解析度或者比例尺下進行切分，形成若干行列的資料塊，這個資料塊就是瓦片。而瓦片資料模型要滿足使用者對於不同區域不同解析度比例尺的資料訪問，所以瓦片模型通常是一個金字塔層次模型，從最頂層（0層）到最底層（N層），解析度遞增，比例尺遞增。瓦片模型相鄰層級之間的比例尺和解析度關係為1:2（2:1），瓦片數量為1:4（4:1），瓦片大小在不同層次保持一致，這裡指的大小是瓦片在螢幕上的解析度，即瓦片的長×寬，而隨著層次的遞增，瓦片的比例尺遞增，單個瓦片表示的空間範圍遞減，相鄰層級的瓦片空間範圍關係為4:1（1:4）。以0-2級為例，如圖1所示，第0級只包含一張瓦片，第1級包含4塊瓦片，第2級包含16塊，瓦片編號為（層級，行，列）。由此可得到第N層級瓦片數量Tiles -N 如式（1）所示，其中N代表層級號。

當層數越來越多，整個向量瓦片就形成了一個層次金字塔式的模型，從第0層到第N層，單層表示的地理空間範圍不變，但是瓦片數量逐級遞增，所以解析度遞增，若第0級解析度為R，則第N級解析度R N 如式(2)所示。

2.2 GeoJson向量資料

向量瓦片是在特定資料塊上所有向量資料的集合，因此在介紹向量瓦片之前，需要對向量資料的組織結構進行了解，常見的向量資料組織儲存形式有Shapefile、GeoJson、TopoJson等，其中GeoJson基於 JavaScript 語法格式的地理空間資料交換格式，具有很強的通用性，被多數軟體平臺和GIS廠商支援，近年來成為向量資料組織格式的首選 [14] 。

GeoJson物件可以表示幾何圖形的位置資訊及其屬性值。GeoJson支援下面幾何型別：點、線、面、多點、多線、多面和幾何集合，一個完整的GeoJson資料結構是一個Json物件，在GeoJson裡，物件由鍵值對集合組成。對每個鍵值對來說，鍵總是字串，值要麼是字串、數字、物件、陣列，要麼是文字常量“True”、 “False”和“Null”中的一個。在GeoJson中，特定的鍵值對錶示特定的資訊，其中對於空間資料起支撐作用的有以下5個欄位：

Geometry: 該欄位對幾何向量進行描述，其中包含向量資料的型別和座標資訊；

Coordinates: 描述向量資料的位置資訊，以二維或三維座標點或陣列來標識；

Properties: 描述向量資料的屬性資訊，以一個Json物件標識；

CRS：向量資料的座標參考系統，位於層級結構最頂層，預設參考系為地理座標參考系WGS84

Bbox：表徵幾何物件的座標範圍，為一個2*n陣列，n為幾何物件的維數；

圖2為一個向量面的GeoJson結構，其中沒有定義CRS，使用預設的WGS84（epsg：4326）。

2.3 Mvt瓦片格式

向量瓦片表示投影在正方形區塊的向量資料，是對原始向量資料切分後的塊內表示。對於向量瓦片的組織，尚無統一標準，而MapBox公司制定的瓦片資料標準格式 mvt （MapBox Vector Tile）是目前較為通用的向量瓦片資料組織檔案格式 [15] ，許多GIS桌面平臺都支援mvt格式的向量瓦片。mvt採用Google Protocol Buffer （pbf）進行編碼，預設投影座標系為Web Mercator （epsg:3857），mvt檔案中不包含投影和空間範圍資訊，其假定解碼方已知投影資訊及編號方式，通過編號規則和圖層範圍即可獲取單塊瓦片的空間範圍。與GeoJson類似，mvt中也有相應的欄位來描述瓦片內的幾何向量資料。

（1）Layers：圖層，向量瓦片由一系列圖層組成，每個圖層必須包含一個Features幾何物件，Features的屬性值也以鍵值對形式（keys，values）儲存到圖層這一級下。圖層必須包含一個extent欄位，用來記錄瓦片的長和寬，而在mvt中，幾何物件的座標被轉化成以瓦片左上角為原點，瓦片寬為x軸，瓦片長為y軸的座標系下的座標點，也就是說幾何物件的座標記錄是其在瓦片內的相對位置，而不是真實的空間地理位置。

（2）Features：用來描述幾何物件的欄位，內部必須包含geometry欄位和type欄位。geometry欄位用來記錄幾何物件的塊內座標，type欄位來標識該幾何物件的型別，如點、線、面等。Features內部有兩個可選欄位：tags和id，tags欄位用於索引Lay-ers層次下的鍵值對，表示該幾何物件的屬性，值得注意的是，tags欄位總是成對出現，表示在keys和values的索引；id為幾何物件的識別符號，相對於其他幾何物件該欄位是唯一的。

圖3為一個圖層中只包含一個向量點的mvt瓦片結構，其中圖層名為“points”，圖層內僅包含一個幾何物件，幾何物件的座標、型別及屬性索引值儲存在Features欄位中，瓦片的長寬由extent標識，幾何物件的屬性值由keys及values儲存。可見mvt中不包含圖層空間範圍、座標參考系、瓦片編號等元資料，這些元資料將在第4節進行介紹。

3. 並行構建向量瓦片

這節將基於並行處理框架Spark，對原始向量資料GeoJson快速構建向量瓦片集mvt，生成向量瓦片金字塔模型。

3.1 Spark平行計算框架

Spark是由伯克利大學AMPlab於2009年提交的一個專案，現已是Apache軟體基金會下最活躍的開源專案之一 [16] 。簡單來說，Spark是用於大規模資料處理的統一分析引擎，通常執行在叢集之上，提供強大的平行計算能力。Spark 屬於廣為人知的Hadoop生態圈，可以對Hadoop下的資料來源進行讀取處理，Spark將中間結果儲存在記憶體中，不需要進行磁碟I/O，因此在進行多次資料計算迭代時，Spark具有更好的效能，由此 Spark 也被稱為繼 MapRe-duce後的下一代計算分析引擎。

彈性分散式資料集 RDD（Resilient DistributedDataset）是Spark的理論基石，是對分散式記憶體的抽象使用，它表示已被分割槽、只讀的、並提供一組豐富的操作方式來操作這些資料集合，操作型別主要分為3種：① 輸入操作，通過該操作構建分散式記憶體中的RDD，比如讀取輸入txt檔案；② 轉化操作，轉化操作是對資料進行處理的過程，將一個RDD通過自定義的方法轉化為另一個RDD，最典型的轉化操作是RDD的map對映操作；③ 行動操作，只有呼叫行動操作時才會觸發Spark作業的提交併返回相應的結果，之前的操作都被繪製成一幅有向無環圖，計算的時候按圖索驥，得到最優的運算路徑。

3.2 並行構建流程

由2.1節可知，原始資料GeoJson描述的是一個圖層上的全域性範圍內的向量資料，內部包含空間範圍，座標系等元資料資訊；而mvt表示的為某一區塊上的資料，記錄幾何物件的相對位置，不包含元資料，這兩種向量資料結構的預設參考座標系也不同。因此，從原始向量資料轉到向量瓦片，需要進行諸如座標系轉化、資料切分、網格塊計算、資料抽稀等等一系列複雜的過程，單機下生成大資料量的瓦片集將相當耗時，因此運用高效能運算技術進行
瓦片資料處理是很有必要的，本文采取的生成向量瓦片的演算法步驟如下：

（1）根據向量瓦片生成的層級數N和圖層資料的空間範圍[X min , Y min , X max , Y max ]（也就是GeoJson最
外層的Bbox），進行資料劃分和空間範圍的計算，對於第N層i行j列的瓦片，空間範圍Bbox-of-Tile(N,i, j)計算如下：

（2）對GeoJson進行預處理，將一個Feature（幾何物件）組織成一行，鍵值對用製表符分隔，這一步的目的是為了便於Spark並行讀取。

（3）將 GeoJson 的幾何物件座標（X, Y）（預設WGS84）轉換到mvt預設的座標系Web MercatorTransform[ ( ) X, Y WGS84→ ( ) X, Y Web-Mercator] （4）

（4）對於單個幾何物件（也就是一行資料），根據步驟（1）計算出來的瓦片空間範圍，判斷幾何物件在各層級的瓦片塊歸屬，若幾何物件跨越多塊瓦片，則將其切分為多個幾何子物件，劃歸到不同的瓦片塊，確定了幾何物件所屬的瓦片塊，以瓦片塊編號（層級，行號，列號）為鍵標識幾何物件。需要注意的是，在對幾何物件進行切分時，僅僅是對其位置座標資訊進行切分，其子物件的描述資訊如type、bbox、properties保持一致。

（5）將幾何物件的座標（經過步驟（3）的轉化，現在的座標系為web Mercator）轉換到塊內座標，若幾何物件所屬的瓦片Bbox為[x 1 , y 1 , x 2 , y 2 ]，瓦片的長寬為extent，座標點（x，y）轉換成塊內座標（xtile,ytile）如式（5）所示。

（6）同鍵幾何物件歸併，同鍵意味著位於同一層級下同一瓦片，將同一瓦片塊內的所有幾何物件合併就組成了瓦片資料；然而當瓦片層級很小時，如圖2的第0層，該層只有一塊瓦片，所有空間物件儲存在單張瓦片上，在維持相同瓦片解析度的前提下將會造成大量資料冗餘，同時影響資料的空間表達效果，因此，當瓦片層級小於某一級別時，在歸併的同時需要進行向量資料抽稀，簡化幾何物件，提升瓦片訪問效率，本文采取的抽稀演算法為Douglas-
Peucker演算法 [17] 。

（7）經歷歸併抽稀操作後，單塊瓦片中的幾何物件組成單條記錄，呼叫Spark行動操作，寫入mvt檔案。

依據上述的演算法步驟，利用Spark進行向量瓦片的並行構建，Spark並行構建演算法流程演算法1所示，在並行處理之前，需要將原始向量資料GeoJson預處理轉化成文字檔案txt，方便後續處理；在Spark進行並行構建瓦片的過程中，主要呼叫了 Map、MapToPair、MapValues、ReuceBykey 這 4 個轉換操作，通過自定義轉換處理函式，完成瓦片構建任務的各個步驟，其中後 2 種轉換操作僅針對鍵值對RDD；最後呼叫foreach行動操作，自定義輸出函式將生成的瓦片儲存到磁碟中。

4. 向量瓦片分散式儲存

由向量瓦片的結構和構建過程可見，原始向量資料生成向量瓦片，檔案數量成百上千倍增加，隨著空間資料量和資料處理任務的飛速增長，無疑將給單機儲存帶來巨大壓力。當前對於向量瓦片的分散式儲存研究較少，大多采用傳統的關係型資料庫進行瓦片資料儲存，如對於向量瓦片集及其元資料的組織，Mapbox 為其制定了關係型資料庫
SQLite下的儲存格式MBTiles [18] ，但隨著瓦片數量的增長，這種輕量級的關係型資料庫儲存方式必將受到挑戰。由此，本文基於記憶體分散式檔案系統Alluxio設計一個面向向量瓦片的儲存模型-Vector-TileStore，將圖層區域上所有的向量瓦片儲存在一個鍵值對結構中，相容瓦片生成過程中產生的元資料，將其合併到儲存模型中，為後續的向量資料處理奠定基礎。

4.1 記憶體分散式檔案系統Alluxio

Alluxio 是由 UC Berkeley AMPLab 實驗室於2013年開源的一個新專案，作為世界上首款以記憶體為中心的虛擬分散式儲存系統，它能夠統一資料訪問併成為連線計算框架和底層儲存系統的橋樑，應用程式只需要連線Alluxio便能夠訪問底層任意儲存系統中的資料，除此之外，Alluxio以記憶體為中心的架構使得資料訪問比現有的解決方案能快若干個數量級。本質上，Alluxio是個分散式的記憶體檔案系統，部署在計算平臺如Spark、Mapreduce之下以及存
儲平臺如HDFS、S3之上，通過全域性地隔離計算平臺與儲存平臺，它在減輕計算框架記憶體壓力的同時，也賦予了計算框架記憶體快速大量資料讀寫的能力。Alluxio把記憶體儲存的功能從Spark/MapReduce中分離出來，使Spark/MapReduce可以更專注計算的本身，以求通過更細的分工達到更高的執行效率 [19] 。

4.2 分散式儲存模型-VectorTileStore

在第3節並行構建瓦片生成的mvt瓦片檔案裡，並不包含圖層和瓦片的元資料，而這些元資料對於瓦片生成和後續的向量資料呼叫及處理不可或缺，因此在進行資料儲存時，除了生成的mvt瓦片，也需要考慮元資料。本文考慮的向量瓦片元資料主要有以下8個欄位：

Format：向量瓦片格式，mvt瓦片的編碼方式是pbf；

Bounds：向量瓦片資料集的範圍，標識整個向量圖層的空間範圍，所有層級的瓦片都在該範圍內，和GeoJson中的Bbox結構一致；

Center：向量圖層的中心點及預設顯示層級；

Minzoom：向量瓦片金字塔層級的最小級別，定義為0；

Maxzoom：向量瓦片金字塔層級的最大級別，依據需求進行定義，該值也就是上文所說的層級數N；

Description：描述欄位，用於描述瓦片集的來源或風格；

Version：向量瓦片的版本；

Attributes：向量圖層的屬性欄位，定義為一個Json，該欄位描述瓦片集中各個圖層的屬性資訊，包括圖層ID、圖層顯示的最大和最小層級（單一圖層的最大層級和最小層級和瓦片集的最大最小層級關係為（layer.minzoom>=Minzoom；layer.maxzoom<=Maxzoom））、圖層中幾何物件的屬性欄位及其型別。

這些元資料要麼是在原始資料中包含的，要麼是在瓦片構建過程中產生的。

本文基於Alluxio分散式檔案系統下的鍵值對檔案KeyValueStore [20] 進行向量瓦片的儲存，設計一個面向向量瓦片的分散式儲存模型-VectorTil-eStore。 Alluxio 下 有 一 個 原 生 的 鍵 值 對 文 件KeyValueStore，其包含兩個鍵值對結構，一個用於儲存資料，另一個作為索引，提供快速查詢資料介面，其索引是一個雜湊表，雜湊表中單個bucket與資料檔案中的單個鍵值對一一對應，記錄鍵的雜湊值及對應鍵值對在資料檔案的offset；基於此索引結構，只需給定鍵，通過雜湊演算法就能在記憶體中快速找到資料。Alluxio架構及內建的KeyValueStore結構如圖 4，Alluxio 採用了標準的 Master-Worker模式，執行中的Alluxio系統由一個Master和多個Worker構成，Alluxio Master用於管理全部檔案的元資料資訊，負責監控各個Alluxio Worker的狀態，支援ZooKeeper進行容錯，以Standby Master作為備份節點；Alluxio Worker為資料節點，管理本地的Ram-disk，是真正進行檔案資料儲存的節點，檔案資料以資料塊的形式儲存在各節點Ramdisk上；在Alluxio中，KeyValueStore被切分成多個數據塊，分佈在各個資料節點上進行儲存，如圖4中，KeyValueStore儲存在3個Worker節點上。

基於KeyValueStore，本文通過指定特定資料的儲存位置，將瓦片資料集儲存在鍵值對中，設計的儲存模型VectorTileStore如圖5所示，前8個鍵值對用於儲存向量瓦片元資料，對應上文列舉的8個元資料欄位，對於任何資料來源和各種層級的瓦片資料集，都擁有這部分資料，可以理解為檔案頭或者保留欄位；從第9個鍵值對開始，存放生成的向量瓦片mvt，一塊瓦片佔據一個鍵值對。模型鍵為 Int 型別，從1開始遞增，值為Text （String）型別存放瓦片資料或元資料字串，其中前八個鍵值對固定存放元資料，其鍵從1遞增到8，則瓦片編號（層號n，行號i，列號j）與鍵key的對應關係如（6）式，儲存的次序按瓦片層號、行號、列號由小到大排列，即優先儲存層級小的瓦片，而對同層級的瓦片來說，按行遍歷進行儲存。

5. 實驗結果與分析

5.1 實驗環境與實驗資料

本文使用5臺浪潮英信I8000刀鋒伺服器，其中一臺作為主節點,其餘4臺作為計算節點，節點主機配置為 Xeon E5-2620 v2 6 核 2.10GHz 處理器，32GB記憶體，200 GB 硬碟，採用Tenda TEG1024G千兆乙太網交換機連線，各節點安裝的是RedHat6.2，Linux核心版本為2.6.32，執行Spark-1.5.0、Hadoop-2.5.2及Alluxio-1.6.0，執行模式為Standalone模式，配置應用程式允許使用的核數（SPARK_WORK-ER_CORES）為節點所有核數，配置應用程式允許使用的記憶體（SPARK_WORKER_MEMORY）為8G，座標系轉換庫使用proj4-5.0.0；為了進行單機瓦片構建及儲存對比實驗，本文在主節點上安裝了SQLite-3.28.0，單機瓦片構建工具選取Mapbox的tippecanoe [21] 。

實驗資料選取開源平臺OpenStreetMap下的塞普勒斯、塞爾維亞、希臘、比利時、奧地利、荷蘭6個歐洲國家資料 [22] ，實驗資料集包含水系、鐵路、道路路網、建築物、土地利用等多個圖層，各國資料的圖層數、資料條目數（幾何物件數量）及檔案大小如表2所示。

5.2 向量瓦片構建對比實驗

該實驗對比單節點序列瓦片構建實驗，基於第3節提出的演算法進行向量瓦片的並行構建，實驗資料集為歐洲6個國家的資料，構建的瓦片金字塔從第0層至第9層共10層資料，考慮到資料傳輸效率及幾何保真，當瓦片層級小於5時，即從第4層開始資料抽稀，對向量點線面進行簡化。各國資料集下的瓦片數量及資料量如表3所示，記錄了各國資料集2種演算法執行時間（圖6），其中塞普勒斯記為Cy-pr，塞爾維亞記為Serb，希臘記為Gree，比利時記為
Belg，奧地利記為Aust，荷蘭記為Neth。

從圖6的實驗結果可見，本文提出的向量瓦片並行構建演算法在各個實驗資料集下，較單機序列構建演算法執行時間更少，演算法效率更高，特別隨著實驗資料量增大，二者時間效率差距越拉越大，這是由於Spark在完成任務初始化後，將資料分配給各個工作節點進行處理，各個節點分而治之，併發地完成任務，而單機構建始終處於“大包大攬”狀態，單節點完成資料讀取、處理、寫磁碟等一系列操作。

5.3 向量瓦片儲存對比實驗

5.3.1 寫入對比實驗

該實驗以 SQLite 下的瓦片儲存格式 MBTiles為對比實驗，基於第4節提出的分散式瓦片儲存模型VectorTileStore進行瓦片集的儲存，實驗資料集為5.2小節構建的向量瓦片集。將歐洲六國的瓦片集分別進行儲存，記錄兩種資料儲存格式的寫入時間，如圖7，從實驗結果可見，當瓦片集資料量較少時（如Cypr和Serb），MBTiles儲存格式寫入時間更少，當瓦片集資料量增長到一定數量，VectorTil-eStore寫入效率更高，消耗時間更少，較單機資料庫儲存有明顯的效能優勢；這是因為當資料量較少時，Alluxio主從節點通訊及任務初始化操作消耗的時間佔比更大，而SQLite是一個輕量級關係型資料庫，佔用資源很少，處理速度快，所以此時MBTiles的寫入效能更好，當資料達到一定量級後，頻繁進行資料寫入，此時記憶體儲存模型的優勢就體現出來，較資料庫的磁碟寫入更快，消耗時間更少。VectorTileStore是分散式儲存結構，資料儲存在多個節點上，當單機容量到達上限，該模型能更好地適配海量瓦片資料儲存。

5.3.2 讀取對比實驗

該實驗基於5.3.1節的瓦片資料儲存，對MB-Tiles和VectorTileStore進行資料讀取，進行2組實驗，第1組為單塊瓦片讀取實驗，記錄各國資料集下瓦片讀取時間，結果如圖8；第2組為併發讀取實驗，客戶端同時讀取10塊瓦片，記錄讀取時間（圖9）。從實驗結果可見，VectorTileStore讀取速度更快，消耗時間更少，特別在多工併發讀取時，Vec-torTileStore 的優勢更加明顯，這是因為 VectorTil-eStore將資料分散式儲存在叢集各個節點記憶體中，根據瓦片編號進行按序儲存，構建高效索引，當併發讀取資料時，MBTiles在單個節點啟動多個執行緒進行處理，而VectorTileStore將資料儲存在分散式叢集中，各個節點分別啟動讀取任務，節點間資源獨立，所以較單機讀取速度更快。

6. 結論與討論

在網際網路地圖服務領域，向量瓦片較柵格瓦片有諸多優勢，必將是下一代網際網路地圖研究的重點，本文針對向量瓦片快速構建及分散式儲存進行研究，得到以下結論：

（1）本文基於Spark的並行向量瓦片構建演算法較 tippecanoe 單機瓦片構建速度明顯提升，通過對比實驗表明，並行構建演算法執行時間平均減少49.6%。

（2）對於生成的向量瓦片集，本文提出的向量瓦片儲存模型VectorTileStore相容瓦片元資料，較MBTiles瓦片儲存格式更適配海量向量瓦片資料存取，時間效率更高。

（3）基於高效能運算技術開展向量瓦片相關研究是可行且有一定優勢的。

下一步的研究工作是基於當前研究，利用上層計算框架Spark/MapReduce與儲存模型互動，進行向量資料的並行分析處理如視覺化、向量查詢等。