高性能瓦片數(shù)據(jù)存儲與發(fā)布應(yīng)用技術(shù)研究

王 偉，姚曉婧，蔣許峰，陳 靜，劉 爍

（1.天津職業(yè)技術(shù)師范大學(xué)信息技術(shù)工程學(xué)院，天津 300222；2.中國科學(xué)院大學(xué)空天信息研究院，北京 110101）

地圖瓦片緩存技術(shù)是廣泛應(yīng)用于WEBGIS 系統(tǒng)建設(shè)的核心技術(shù)之一。通過將地圖數(shù)據(jù)在服務(wù)器上預(yù)先渲染生成尺寸相同的圖片（瓦片），避免了瀏覽器每一次地圖請求都在后端動態(tài)生成圖片。瓦片緩存技術(shù)顯著提高了地圖顯示效率，極大地增強(qiáng)了圖形瀏覽的用戶體驗(yàn)。依據(jù)瓦片分割方案，瓦片數(shù)據(jù)在數(shù)量上按縮放等級呈金字塔結(jié)構(gòu)，且具有單個文件小、文件數(shù)量多、整體數(shù)據(jù)量大等特點(diǎn)。使用簡單的磁盤存儲方法會造成嚴(yán)重磁盤碎片化、IO 讀寫性能下降、數(shù)據(jù)易損壞以及難于管理維護(hù)等問題。同時，存儲在磁盤上的不同瓦片數(shù)據(jù)，需要使用ArcgisServer 或其他地理信息服務(wù)器軟件，以地圖服務(wù)的形式對每一數(shù)據(jù)集對外發(fā)布應(yīng)用。隨著不同版本、批次、類別瓦片數(shù)據(jù)集的增多，必然要在服務(wù)器上創(chuàng)建更多的服務(wù)進(jìn)程，進(jìn)而急劇消耗服務(wù)器CPU 及內(nèi)存資源，最終造成服務(wù)器癱瘓。針對時空多序列海量瓦片緩存數(shù)據(jù)的存儲、管理與發(fā)布應(yīng)用問題，亟需一種經(jīng)濟(jì)實(shí)用、可橫向擴(kuò)展、高性能存儲并能夠無縫對接前端發(fā)布應(yīng)用的解決方案。

近年來，基于HBase 數(shù)據(jù)庫具有開源、橫向可擴(kuò)展、高性能等特性，國內(nèi)外很多學(xué)者提出使用HBase作為海量瓦片數(shù)據(jù)的存儲載體，用來解決瓦片數(shù)據(jù)在存儲管理上的諸多問題。宋關(guān)福等[1-3]指出，大數(shù)據(jù)平臺是未來GIS 空間數(shù)據(jù)存儲與應(yīng)用的發(fā)展方向，并給出了運(yùn)用大數(shù)據(jù)平臺存儲遙感數(shù)據(jù)的模型和方法。針對一般磁盤存儲方案無法對海量地圖瓦片進(jìn)行有效存儲和管理的問題，喻凱等[4-6]提出在Hadoop、Hbase的數(shù)據(jù)存儲環(huán)境中保存遙感影像切片數(shù)據(jù)，通過引入Hilbert 曲線，將二維空間數(shù)據(jù)映射成一維連續(xù)索引，進(jìn)而有效提高數(shù)據(jù)存儲與檢索效率的技術(shù)方案。針對瓦片金字塔結(jié)構(gòu)以及生成方法等問題，郭寧等[7]作了深入研究，并提出一種多層級自適應(yīng)的瓦片生成方法，優(yōu)化了可視化引擎，實(shí)現(xiàn)了大規(guī)模柵格數(shù)據(jù)瓦片金字塔的快速構(gòu)建。方金云等[8]根據(jù)空間查詢特性和Spark 分布式內(nèi)存計(jì)算模型，設(shè)計(jì)了HBase 分布式存儲、分布式空間索引、Spark 分布式內(nèi)存計(jì)算框架的空間區(qū)域查詢算法和Spark Streaming 的空間查詢算法，提供實(shí)時在線空間查詢服務(wù)。王乃生等[9]為解決天地圖建設(shè)和更新過程中遇到的電子地圖瓦片數(shù)據(jù)的版本管理、共享訪問、存儲擴(kuò)容限制等方面的問題，基于NoSQL 數(shù)據(jù)庫MongoDB 的存儲結(jié)構(gòu)設(shè)計(jì)并實(shí)現(xiàn)了一種時態(tài)地圖瓦片數(shù)據(jù)存儲模型。李紹俊等[10]提出基于內(nèi)存數(shù)據(jù)庫和No-SQL 數(shù)據(jù)庫的空間大數(shù)據(jù)分布式存儲與綜合處理策略，用以解決大數(shù)據(jù)存儲與管理方面面臨的復(fù)雜問題。上述研究均從瓦片數(shù)據(jù)特性的角度出發(fā)，深入研究了瓦片數(shù)據(jù)生成、數(shù)據(jù)存儲及運(yùn)用Hilber 曲線提升查詢效率等技術(shù)，普適性地實(shí)現(xiàn)瓦片數(shù)據(jù)在大數(shù)據(jù)平臺上的存儲與查詢效率的提高。但就WebGIS 系統(tǒng)中應(yīng)用的瓦片數(shù)據(jù)而言，用戶在前端對某一縮放級別地圖進(jìn)行瀏覽時，前端框架具有能夠?yàn)槊恳粔K瓦片產(chǎn)生唯一編號的特性。通過將這一編號直接映射到鍵值數(shù)據(jù)庫上的行鍵上，并發(fā)調(diào)用瓦片，就可最大化地發(fā)揮NoSQL 數(shù)據(jù)庫在已知鍵值查詢效率最高的特性，從而簡化數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)，提高數(shù)據(jù)獲取效率，實(shí)現(xiàn)應(yīng)用與數(shù)據(jù)的完美統(tǒng)一。

本文從WebGIS 在前端調(diào)用瓦片數(shù)據(jù)的原理出發(fā)，針對海量瓦片數(shù)據(jù)存儲及一體化顯示功能所面臨的文件碎片化、不易管理、發(fā)布應(yīng)用依賴商用平臺軟件等諸多問題，運(yùn)用NoSql 數(shù)據(jù)庫鍵值關(guān)系（keyvaluepair）結(jié)構(gòu)，開展了瓦片數(shù)據(jù)在Hadoop、HBase 大數(shù)據(jù)平臺上的存儲模型設(shè)計(jì)。充分利用鍵值數(shù)據(jù)庫行鍵索引的高效性以及RESTful 接口的通用性，實(shí)現(xiàn)了瓦片數(shù)據(jù)在Openlayers 開源前端可視化地圖引擎中的高效加載。

1 瓦片數(shù)據(jù)生成

基于NoSql 數(shù)據(jù)庫瓦片存儲模型研發(fā)的關(guān)鍵，在于對瓦片數(shù)據(jù)的特點(diǎn)有比較清晰的認(rèn)識。目前，不論是主流商用GIS 平臺，還是開源GIS 軟件產(chǎn)品，所使用的緩存瓦片數(shù)據(jù)雖然存儲格式稍有不同，但一般均采用四叉樹算法進(jìn)行分層切割，各層切割后的瓦片數(shù)量呈金字塔型。

1.1 TMS瓦片生成算法

瓦片地圖服務(wù)（tile map service，TMS）是廣泛應(yīng)用于WebGIS 開發(fā)的技術(shù)規(guī)范，由開源地理空間基金會（open source geospatial foundation，OGC）開發(fā)，在瓦片緩存技術(shù)中具有極高的影響力[11-12]。本文以WGS84 標(biāo)準(zhǔn)TMS 瓦片為例，詳細(xì)講述TMS 瓦片生成及在磁盤的存儲格式。TMS 瓦片切割算法可由如下偽代碼表述

在上述算法描述中，以投影后的平面地圖左下角為原點(diǎn)，經(jīng)度方向?yàn)闄M軸，緯度方向?yàn)榭v軸建立平面直角坐標(biāo)系，通過三重循環(huán)來實(shí)現(xiàn)瓦片數(shù)據(jù)的切割。按照TMS 切割算法生成的標(biāo)準(zhǔn)瓦片數(shù)據(jù)，根目錄下的第一級目錄為縮放級別zoom；第二級目錄是沿經(jīng)度方向切割的列數(shù)，從原點(diǎn)開始由小到大編號；第三級是切割瓦片的文件名稱，從原點(diǎn)開始沿緯度方向由小到大按序編號。因此，切割的瓦片可由縮放級別、橫向列號和縱向行號來組合位移確定，TMS 瓦片金字塔模型如圖1 所示。其他主流GIS 平臺，如ArcGIS、Supermap等，雖然在瓦片存儲時文件夾及文件的命名規(guī)則稍有不同，但存儲結(jié)構(gòu)與TMS 基本相同，數(shù)據(jù)結(jié)構(gòu)具有一致性。

圖1 TMS 瓦片金字塔模型

1.2 瓦片編號與空間坐標(biāo)關(guān)系

當(dāng)前，一般的做法是將切割出來的瓦片直接存儲在磁盤上，并以樹狀結(jié)構(gòu)來組織。某一地區(qū)某一版本的空間數(shù)據(jù)在一定的瓦片切割算法下生成瓦片數(shù)據(jù)，這些數(shù)據(jù)被保存在一個目錄下（樹根）。在該目錄下，同一縮放級別的瓦片被放在以縮放級別命名的文件夾里；在任一縮放級別下面，將不同列的瓦片分別存放在以列號命名的文件夾內(nèi)；列文件夾內(nèi)直接保存該列內(nèi)以行號命名的瓦片文件。瓦片文件的磁盤存儲結(jié)構(gòu)如圖2 所示。

圖2 WGS84 標(biāo)準(zhǔn)TMS 瓦片磁盤存儲格式

2 瓦片數(shù)據(jù)NoSql 存儲模型

NoSQL 數(shù)據(jù)庫的出現(xiàn)，為海量瓦片數(shù)據(jù)存儲模型的設(shè)計(jì)與實(shí)現(xiàn)，提供了一種全新的思路。NoSQL 不僅指SQL，其為結(jié)構(gòu)化、半結(jié)構(gòu)化以及非結(jié)構(gòu)化數(shù)據(jù)的存儲和檢索提供了一種機(jī)制[13]。NoSQL 數(shù)據(jù)庫包括簡單的結(jié)構(gòu)設(shè)計(jì)、更簡單的機(jī)器集群水平擴(kuò)展和更精細(xì)的可用性控制[14]。通過使用簡單的Key-Value 結(jié)構(gòu)，NoSQL 數(shù)據(jù)庫能夠?qū)崿F(xiàn)對具有確定Key 值數(shù)據(jù)的快速提取。NoSQL 數(shù)據(jù)庫在設(shè)計(jì)上的優(yōu)勢，非常適合海量瓦片數(shù)據(jù)的存儲。

2.1 瓦片數(shù)據(jù)集元數(shù)據(jù)

在使用大數(shù)據(jù)平臺存儲瓦片數(shù)據(jù)時，通過將包含數(shù)據(jù)分類、版本、瓦片切片方案、空間坐標(biāo)引用等信息的元數(shù)據(jù)一齊保存在大數(shù)據(jù)平臺中，能夠確保瓦片元數(shù)據(jù)與瓦片數(shù)據(jù)在數(shù)據(jù)存儲介質(zhì)上的一致。瓦片元數(shù)據(jù)結(jié)構(gòu)用JSON 數(shù)據(jù)結(jié)構(gòu)表示為

在項(xiàng)目建設(shè)中，使用HBase 數(shù)據(jù)庫保存瓦片數(shù)據(jù)，并在瓦片入庫之前同步瓦片元數(shù)據(jù)，做到了元數(shù)據(jù)與數(shù)據(jù)本體同源一致。

2.2 NoSQL存儲結(jié)構(gòu)

HBase 是基于HDFS 的分布式NoSQL 數(shù)據(jù)庫，由Apache 基金會開發(fā)、基于BigTable 算法的開源軟件產(chǎn)品，在處理非結(jié)構(gòu)化數(shù)據(jù)方面具有較強(qiáng)優(yōu)勢[15]。HBase數(shù)據(jù)庫的設(shè)計(jì)包括行鍵（RowKey）設(shè)計(jì)和列族（Column Family）設(shè)計(jì)2 部分。行鍵是不可分割的字節(jié)數(shù)組，在大表中按字典排序由低到高存儲，是瓦片數(shù)據(jù)唯一的索引。為了提高用戶瓦片數(shù)據(jù)隨機(jī)查詢讀取效率，避免單個節(jié)點(diǎn)過熱，數(shù)據(jù)庫的設(shè)計(jì)采用高表方案，即每一行數(shù)據(jù)中僅保留一個列族，列族內(nèi)僅有一列，用于存儲二進(jìn)制瓦片數(shù)據(jù)的base64 編碼[16-17]?；诖耍瑢?shù)據(jù)庫的設(shè)計(jì)主要體現(xiàn)在行鍵的設(shè)計(jì)上。

行鍵是不可分割的字節(jié)數(shù)組，在表中按照字典排序由低到高存儲，是唯一的索引，決定了數(shù)據(jù)的處理性能。瓦片數(shù)據(jù)存儲包含瓦片元數(shù)據(jù)以及瓦片路徑信息2 部分，行鍵結(jié)構(gòu)結(jié)果如圖3 所示。

圖3 行鍵結(jié)構(gòu)

元數(shù)據(jù)包括瓦片數(shù)據(jù)的類別、標(biāo)題、版本、數(shù)據(jù)來源等描述字段，通過將這些描述信息按序組合即可得到瓦片數(shù)據(jù)元數(shù)據(jù)描述字符串。由于描述字符串長度較長且長短不一，需要使用MD5 算法獲取描述字符串的32 位數(shù)字摘要值，并作為行鍵的頭部。瓦片路徑信息是指某一瓦片的縮放級別、列編碼及行編碼的組合。對于圖2 中的瓦片3.jpg 文件，瓦片路徑可以表述為“203.jpg”。由于TMS 并未使用等長編碼，故瓦片路徑字段的長度會有不同。

3 技術(shù)架構(gòu)

為了解決瓦片數(shù)據(jù)在存儲、管理方面的諸多問題，綜合考慮前端發(fā)布技術(shù)，設(shè)計(jì)集數(shù)據(jù)存儲、管理與前端應(yīng)用于一體的技術(shù)框架。

3.1 設(shè)計(jì)要求

基于瓦片數(shù)據(jù)的特點(diǎn)，面向瓦片數(shù)據(jù)存儲與發(fā)布的數(shù)據(jù)平臺應(yīng)該滿足：①數(shù)據(jù)存儲橫向可擴(kuò)展，解決海量數(shù)據(jù)存儲的問題；②支持瓦片元數(shù)據(jù)存儲，易于管理；③前端能夠高效獲取瓦片，并在前端系統(tǒng)中直接調(diào)用。

3.2 瓦片數(shù)據(jù)存儲與應(yīng)用技術(shù)框架

在私有云計(jì)算環(huán)境下，部署Hadoop 高可用大數(shù)據(jù)運(yùn)行環(huán)境，搭建HDFS 分布式文件系統(tǒng)，并在此基礎(chǔ)上安裝實(shí)時、分布式、高維數(shù)據(jù)庫HBase。利用HBaseREST Server，實(shí)現(xiàn)瓦片數(shù)據(jù)、瓦片元數(shù)據(jù)入庫、前端可視化組件對瓦片的動態(tài)調(diào)用。瓦片數(shù)據(jù)存儲技術(shù)框架如圖4 所示。

圖4 基于HBase 的瓦片數(shù)據(jù)存取技術(shù)框架

3.2.1 RESTful接口

REST（representational state transfer）描述了一個架構(gòu)樣式的網(wǎng)絡(luò)系統(tǒng)，當(dāng)前被廣泛應(yīng)用于webGIS 系統(tǒng)開發(fā)[18-19]。利用HBase REST Server 提供的數(shù)據(jù)存取接口，可方便地實(shí)現(xiàn)瓦片數(shù)據(jù)入庫與讀取。接口描述如表1 所示。

表1 數(shù)據(jù)存取接口

通過遍歷磁盤上的瓦片文件，并將瓦片圖片轉(zhuǎn)換為Base-64 編碼，調(diào)用REST 接口后，即可完成瓦片數(shù)據(jù)的入庫操作。

3.2.2 Openlayers前端發(fā)布

HBase 數(shù)據(jù)庫提供的RESTServerAPI 為前端應(yīng)用的開發(fā)提供了豐富的接口。基于這些接口，可以開發(fā)更加高效的、不需要任何商用GIS 服務(wù)軟件產(chǎn)品的前端瓦片緩存數(shù)據(jù)應(yīng)用。運(yùn)用Openlayers 前端JS 組件開發(fā)基于HBase 的發(fā)布軟件業(yè)務(wù)流程如圖5 所示。

圖5 瓦片數(shù)據(jù)存儲與應(yīng)用一體化

（1）創(chuàng)建數(shù)據(jù)源

在Openlayers 中，可以使用ol.source.XYZ 組件實(shí)現(xiàn)瓦片數(shù)據(jù)源的構(gòu)建。在該類的構(gòu)造函數(shù)中，可以通過在傳入?yún)?shù)中定義屬性tileUrlFunction 的回調(diào)函數(shù)，實(shí)現(xiàn)在HBase 中存儲瓦片的準(zhǔn)確命中。核心代碼為

4 應(yīng)用實(shí)踐與性能分析

4.1 性能分析

為了驗(yàn)證本文所述技術(shù)框架的實(shí)際工作性能，使用VirtualBox（6.1）搭建虛擬實(shí)驗(yàn)環(huán)境，在同等硬件環(huán)境下，針對商用平臺ArcgisServer（10.3）及本文所述技術(shù)框架在IO 性能、CPU 占用、內(nèi)存消耗等方面進(jìn)行全面比較分析。

4.1.1 物理環(huán)境

在Dell Precession 5510 工作站上，搭建虛擬實(shí)驗(yàn)環(huán)境。為了能更合理、準(zhǔn)確地比較2 種技術(shù)方案的性能差別，2 套技術(shù)方案分配的硬件資源應(yīng)一致。ArcGIS Server 部署在單節(jié)點(diǎn)主機(jī)上，Hadoop & Hbase集群則部署在由5 個單節(jié)點(diǎn)主機(jī)組成的集群上，分配的硬件資源與單節(jié)點(diǎn)主機(jī)相當(dāng)。具體硬件資源分配情況如表2 所示。

表2 實(shí)驗(yàn)硬件資源配置

4.1.2 服務(wù)器響應(yīng)

由于ArcGISServer 部署在單節(jié)點(diǎn)主機(jī)上，而Hadoop&Hbase 集群運(yùn)行在多個節(jié)點(diǎn)服務(wù)器上，所以很難直接獲取磁盤的IO 性能。為此，針對地圖任一視域加載的瓦片數(shù)據(jù)，分別使用經(jīng)過緩存的ArcgisImageServer 和通過HBaseRESTServer API 直接調(diào)用2 種不同技術(shù)方案，對服務(wù)器性能表現(xiàn)作比較分析，從而間接獲取2種技術(shù)方案的IO 性能評價。

等待時間（time to first byte，TTFB）是衡量應(yīng)用程序服務(wù)器性能的重要指標(biāo)之一，其是發(fā)出頁面請求（request）到接收到應(yīng)答（response）數(shù)據(jù)第1 個字節(jié)所花費(fèi)的ms 數(shù)。利用Chrome 瀏覽器開發(fā)者模式，分別獲得2 種技術(shù)方案下，同一地圖視域下20 個瓦片請求的TTFB。為了便于比較分析，以瓦片編號作為橫軸，獲取瓦片的TTFB 為縱軸，分別繪制HBase、Arcgis Server 2 種技術(shù)方案下的用時曲線，如圖6 所示。

圖6 不同技術(shù)方案下的服務(wù)器性能測試

從圖6 可以看出，與基于ArcGIS Server 的技術(shù)框架相比，運(yùn)用HBase REST Server 實(shí)現(xiàn)瓦片數(shù)據(jù)的發(fā)布功能，具有服務(wù)響應(yīng)速度快、性能表現(xiàn)穩(wěn)定高效的突出優(yōu)點(diǎn)，具有非常明顯的IO 性能優(yōu)勢。

為了最大限度接近服務(wù)器性能表現(xiàn)的真值，分別對HBase、ArcGIS Tiled Image Server 2 種數(shù)據(jù)源下的地圖頁面作3 次刷新操作，對同一瓦片提取3 組TTFB 數(shù)據(jù)，并使用平均值作為獲取該瓦片的最終TTFB 數(shù)值，測量結(jié)果如表3 所示。

表3 不同技術(shù)方案下的TTFB 數(shù)據(jù)

4.1.3 資源占用情況

為了科學(xué)地比較分析2 種技術(shù)方案下的資源占用情況，在實(shí)驗(yàn)環(huán)境下將ArcGIS Server 和Hadoop&Hbase集群均部署在CentOS（7.9）操作系統(tǒng)上，各個節(jié)點(diǎn)服務(wù)器部署運(yùn)行的應(yīng)用進(jìn)程/角色如表4 所示。

表4 資源占用

對于ArcgisServer，系統(tǒng)會加載多個Command 命令名稱為arcsoc 的應(yīng)用進(jìn)程。隨著在GIS 服務(wù)器上發(fā)布服務(wù)數(shù)量增多，這些進(jìn)程的數(shù)量也會相應(yīng)增多；對于Hadoop & Hbase 集群，在namenode 上固定運(yùn)行Namenode、HMaster、DFSZKFailoverController 3 個進(jìn)程，在datanode 上 固 定 運(yùn) 行Datanode、HRegionServer、JournalNode、QuorumPeer-Main 4 個進(jìn)程。

分別在Arcgis Server 服務(wù)器、Hadoop & Hbase 集群的Namenode、Datanode 上運(yùn)行top 命令，查看2 種技術(shù)方案下的CPU 占用、內(nèi)存消耗情況，運(yùn)行結(jié)果分別如圖7、圖8 和圖9 所示。

圖7 ArcGIS Server CPU 占用及內(nèi)存消耗

圖8 Namenode 節(jié)點(diǎn)CPU 占用及內(nèi)存消耗

圖9 Datanode 節(jié)點(diǎn)CPU 占用及內(nèi)存消耗

從圖7、圖8 和圖9 的測試結(jié)果中可以看出，相比于Arcgis Server 服務(wù)器，Hadoop& Hbase 單節(jié)點(diǎn)占用CPU 及消耗的內(nèi)存較少。同時，Hadoop&Hbase 集群運(yùn)行應(yīng)用進(jìn)程固定，不隨發(fā)布數(shù)據(jù)量的增加而增加；而ArcGISServer 則隨發(fā)布服務(wù)器的增多，不斷增加arcsoc 進(jìn)程，由于內(nèi)存數(shù)量的限制，不能無限制地發(fā)布瓦片地圖服務(wù)。

4.2 應(yīng)用實(shí)踐

本文所述的技術(shù)平臺直接應(yīng)用于“中新天津生態(tài)城GIS 服務(wù)平臺”的開發(fā)建設(shè)。在私有云計(jì)算環(huán)境下部署高可用性（high available，HA）Hadoop 集群環(huán)境，并在此基礎(chǔ)上安裝HBase 數(shù)據(jù)庫。在HBase 數(shù)據(jù)庫中保存了生態(tài)城從2010 年開始各個月份的行政圖、高清影像圖以及部分傾斜攝影、街景數(shù)據(jù)。利用HBase 的REST Server API，實(shí)現(xiàn)了瓦片數(shù)據(jù)在前端的直接快速渲染。

5 結(jié) 語

本文提出的面向Hadoop、HBase 的地圖瓦片數(shù)據(jù)存儲框架技術(shù)，綜合運(yùn)用了Hadoop 集群的橫向可擴(kuò)展、高可用性，開源經(jīng)濟(jì)性，以及基于key-value 存儲結(jié)構(gòu)的HBase 數(shù)據(jù)庫對于確定key 值提取數(shù)據(jù)的高效性，為海量瓦片數(shù)據(jù)的存儲和管理提供了全新開源解決方案。同時，框架技術(shù)基于HBase REST Server API，實(shí)現(xiàn)了瓦片數(shù)據(jù)在前端組件Openlayers 上的無縫加載，徹底解除了瓦片數(shù)據(jù)發(fā)布應(yīng)用中對商用GIS 軟件平臺的依賴，極大地降低了軟件開發(fā)成本。HBase 作為開源NoSQL 數(shù)據(jù)庫成熟軟件產(chǎn)品，廣泛應(yīng)用于各類非結(jié)構(gòu)化數(shù)據(jù)的存儲。在空間大數(shù)據(jù)存儲及應(yīng)用領(lǐng)域，不僅能夠?qū)崿F(xiàn)本文所述的瓦片數(shù)據(jù)存儲，對于矢量空間數(shù)據(jù)在HBase 中的存儲也值得深入研究。