基于HBase的數值預報產品存儲檢索應用

數值預報產品數據快速增長，傳統的關系型數據庫對其存儲和管理能力不足，查詢規模較大的歷史數據時效率較低。鑒于此，基于HBase設計了分布式的數據存儲模型，應用MapReduce將數值預報產品解碼信息存入HBase，并將解碼得到的要素GRIB文件寫入HDFS。因HBase對Rowkey的一級索引支持較好，而對多條件查詢支持不足，需輔助 Solr索引加以優化。HBase接收數據時自動觸發協處理器同步記錄到Solr，實現了HBase的二級索引。測試結果表明，最快入庫速度可達每秒16145條，數據檢索結果返回時效達到毫秒級，能夠滿足業務應用中對數值預報產品存儲和檢索時效的要求。

【關鍵詞】HBase MapReduce 要素GRIB文件 解碼日志文件 SolrCloud

氣象數據是氣象業務和科研工作的基礎。近年來氣象現代化業務發展迅速，氣象探觀測數據、各種氣象產品數據都呈快速增長之勢，數據種類不斷增加的同時，數據規模也隨著覆蓋范圍和精度的擴展、數據密度頻次的提高而越來越大，這些數據包括結構化的數據，如自動氣象站觀測數據等，也包括氣象衛星產品和氣象雷達產品等半結構化和非結構化數據。對于結構化的數據可以通過關系型數據庫進行分析、處理和計算，但對于海量的歷史數據，關系型數據庫存儲和檢索效率較低；對于數值預報產品等非結構化數據大多基于文件方式（如GRIB格式文件）存儲和處理。不斷增長的數據量使得關系型數據庫系統負載過于飽和，影響了系統服務的時效性和穩定性。中國氣象局CIMISS（全國綜合氣象信息共享平臺）[1-2]數據庫中存儲多種數值預報產品信息，每行記錄包含起報時間、預報時效、層次、預報要素代碼、區域代碼、單要素GRIB文件路徑等字段，而具體的GRIB文件存儲在GPFS集群文件系統中。為確保Oracle數據庫穩定運行，數值預報產品記錄保存3-6個月，并定時清除表空間。在業務和科研工作中，往往需要長時間序列的數值預報產品數據，并且要求實時檢索，因此考慮利用分布式 架構來解決海量氣象數據存儲檢索所面臨的問題。

在分布式存儲和計算技術中，Hadoop平臺具有高吞吐量、高并發、高容錯性、高可靠性、低成本、能擴展到云環境的優勢。目前基于Hadoop生態系統的氣象數據存儲檢索方案成為國內外研究熱點。李永生等[3]選用Hadoop與HBase相結合的方式設計數值預報產品服務平臺；陳東輝等[4] 詳細介紹了基于HBase 的氣象地面分鐘數據分布式存儲系統。本文選取HBase數據庫實現氣象數據文件的分布式存儲管理，并實現前端GRIB解碼入庫性能優化和后端數據檢索性能優化。實驗測試驗證了基于HBase 的數值預報產品存儲與檢索方案的可行性，為海量氣象數據的存儲和檢索服務提供一種優化思路。

1 數據存儲模型設計

1.1 HBase簡介

Apache Hadoop是一個分布式系統基礎架構，包括兩大核心：Hadoop分布式文件系統HDFS和MapReduce分布式編程模型[5]。HBase（Hadoop DataBase）作為Hadoop中的一個子項目，使用Zookeeper管理集群，運行在HDFS分布式文件系統之上，提供高可靠性、高性能、列存儲、可伸縮、實時讀寫的分布式數據庫，主要用來存儲非結構化和半結構化的松散數據。

Zookeeper 分布式服務框架是 Apache Hadoop的一個子項目，它主要是用來解決分布式應用中經常遇到的一些數據管理問題，如：統一命名服務、狀態同步服務、集群管理、分布式應用配置項的管理等。

1.2 數據存儲模型設計

研究方案將數值預報產品通過GRIB API解碼[6-7]后存儲在HBase中，不同的數值預報產品分開存儲在不同的實體數據表中，目前實際存儲了3大類數值預報產品，包括ECMWF（歐洲中期數值預報中心）發布的細網格（0.25? ×0.25?水平分辨率）的數值預報產品，JMA（日本氣象廳）發布的0.5? ×0.5?水平分辨率數值預報產品，高分辨率東北半球T639數值產品。數據表以行鍵、列族、數據的方式存儲數值產品的實體數據。數據表存儲內容說明如表1所示。

data：gribpath是解碼所得要素GRIB文件的在HDFS文件系統中的存儲路徑，GRIB包含的格點數據在Rest Web Service接口調用時作為二維數組返回。

選取表1中data：date、data：validtime和data：centre三列做數據模型展示，見表2。

行鍵的設計：

HBase中的行鍵（Rowkey）可以唯一標識一行記錄。根據HBase的優化原則[8]，Rowkey的長度易固定且不超過200Bytes，設計如下：AAAAATTT：yyyyMMdd：nnnmmmm：IIIIXJJJJ，AAAAA為5字母長度的英文縮寫，不足5位則在其后補“9”，代表數值預報產品的預報要素名稱；TTT 為預報時效；nnn表示高度層類型，mmm表示層次；IIII表示4位I方向增量，不足4位則前導置“0”；JJJJ表示4位J方向增量，不足4位則前導置0。

以ECMF數據表的行鍵為例：

TEMP9006：20160711：1000010：0250X0250

其含義是：對于溫度要素（temp），在2016 年7 月11日00：00 起報，預報時效為未來6h的預報場，預報層次為10hPa，I方向增量為0.25?，J方向增量為0.25?。

時間戳（Timestamp）：每條數據更新的歷史記錄，同一行鍵數據再次入庫會記錄不同的時間戳。

列族（Column Family）：每種數值預報產品的表結構基本相同，每張表只設一個列族data，其包含的列（Column Qualifier）有data：date、data：validtime、data：centre、data：gribpath等。HBase存儲的都是Byte數組。

2 基于Solr的二級索引設計

2.1 Solr簡介

Apache Solr是一種開源的、基于 Lucene的全文檢索引擎，支持XML、JSON 和python等常用輸出格式。而SolrCloud[9-10]是基于Solr和Zookeeper的分布式搜索方案，使用Zookeeper作為集群的配置信息中心。

2.2 SolrCloud的工作模式

SolrCloud中包含有多個Solr Instance，每個Solr Instance中包含多個Solr Core，Solr Core對應著一個可訪問的Solr索引資源Replica（復本），當Solr Client通過Collection訪問Solr集群時，便可以通過Shard分片找到對應的Replica，從而就可以訪問索引文檔了，如圖1所示。

在SolrCloud模式下，同一個集群里所有Core的配置是統一的，Core有Leader和Replication兩種角色，每個Core一定屬于一個Shard，Core在Shard中扮演Leader還是Replication由Zookeeper自動協調。

2.3 二級索引設計

HBase在存儲時，默認按照Rowkey進行排序（字典序）并通過Rowkey及其range來檢索數據，在HBase查詢的時候，有以下幾種方式：

（1）通過get方式，指定Rowkey獲取唯一一條記錄；

（2）通過scan方式，設置startRow和stopRow參數進行范圍匹配；

（3）全表掃描，即直接掃描整張表中所有行記錄。

HBase對Rowkey的一級索引支持較好，按Rowkey查詢的響應時間達到毫秒級。HBase內置Filter（過濾器）特性以支持多條件查詢的二級索引。但HBase的Filter是直接掃描記錄的，如果數據范圍很大，會導致查詢速度很慢。因此基于Solr來實現二級索引，滿足Rowkey之外的多要素數據檢索需求。

基于Solr的HBase多條件查詢原理：將HBase表中涉及條件過濾的字段和Rowkey在Solr中建立索引，通過Solr的多條件查詢快速獲得符合過濾條件的Rowkey值，再根據Rowkey從HBase中進行查詢，返回記錄集，如圖2所示。

設計SolrCloud索引的關鍵問題是合理的配置索引字段。Zookeeper統一管理XML格式的Solr索引字段描述文件文件：managed-schema，SolrCloud各實例（Instance）共享同一個managed-schema。具體配置如下：

……

[1] 2 [3] [4] 存入我的閱覽室

3.2 HBase協處理器

HBase的協處理器[12]（Coprocessor）分為兩類，Observer和EndPoint：Observer相當于關系型數據庫中的觸發器，EndPoint則相當于存儲過程。其中Observer的代碼部署在服務端，相當于對API調用的代理。選用RegionObserver觀察者接口（API），其提供客戶端的數據操縱事件鉤子：Get、Put、Delete、Scan等。

3.3 HBase協處理器向Solr寫索引

實時更新數據需要獲取到HBase的插入、更新和刪除操作：攔截put和delete操作，將其內容獲取出來，同步寫入Solr。HBase協處理器定義以及同步數據到Solr的主要代碼：

public class SolrIndexCoprocessorObserver extends BaseRegionObserver {

@Override

public void postPut（ObserverContext e， Put put， WALEdit edit， Durability durability） throws IOException {

String rowKey = Bytes.toString（put.getRow（））；

try {

Cell cellEdition = put.get（Bytes.toBytes（"data"）， Bytes.toBytes（"edition"））.get（0）；

String strEdition = new String（CellUtil.cloneValue（cellEdition））；

Cell cellDate = put.get（Bytes.toBytes（"data"）， Bytes.toBytes（"date"））.get（0）；

String strDate = new String（CellUtil.cloneValue（cellDate））；

……

SolrInputDocument doc = new SolrInputDocument（）；

doc.addField（"id"， rowKey）；

doc.addField（"edition"， strEdition）；

……

// 寫入緩沖

SolrWriter.addDocToCache（doc）；

}

Solr中的每條Document（SolrInputDocument對象）對應HBase表里的一條記錄。HBase記錄寫入SolrCloud的性能優化：默認情況下HBase每寫入一條數據就會觸發一次postPut，比較耗費網絡IO，因此先將Document緩存在List中并采用兩種方式批量提交：

（1）當緩存達到設定的閾值時立即提交到SolrCloud；

（2）定時提交。

最后需要通過HBase Shell為相關產品數據表添加協處理器。

5 性能測試

5.1 測試環境

（1）軟件及版本：

hadoop-2.6.0；

zookeeper-3.4.6；

solr 5.5.4，使用其自帶的Jetty服務端容器，云模式運行；

hbase-1.2.2；

GRIB API 1.12.3。

（2）硬件配置：

測試環境由4臺X86架構的服務器組成，操作系統均為64位CentOS 6.5。其中3臺服務器構建Hadoop、Zookeeper、HBase、Solr集群，1臺部署數值預報產品解碼入庫程序（Hadoop、HBase等客戶端程序）；

處理器：Intel Core i5-3470 3.20GHz；

磁盤：1TB，7.2K 600MB/s SATA III接口；

內存：16GB；

網絡環境為千兆局域網。

5.2 測試對象和方法

選取高分辨率東北半球T639數值產品及其解碼得到的要素GRIB文件為測試對象，均采用GRIB2編碼，其平均大小為約50MB。

5.2.1 HDFS寫入性能

T639數值產品共504個文件，共24.9GB，平均大小50.59 MB?？蛻舳顺绦蛘{用HDFS API的文件復制操作將T639數值產品文件寫入HDFS文件系統需要347秒，平均寫文件速度為73.48MB/s。

5.2.2 HBase入庫性能

解碼生成了504個解碼日志文件，共178920條記錄，耗時13s，平均寫入速度13725條/s；隨機抽取1000，2000，…，10000條記錄入庫，如圖4所示。測試結果表明：隨著入庫記錄數的增加，數據入庫性能總體平穩，最快寫入速度16145條/s。

5.2.3 索引完整性驗證

測試用例設計如表3。

在驗證Solr索引完整性上，分別對基于HBase Filter[15]的條件過濾查詢和SolrCloud索引查詢返回的記錄數對比，如表4所示。

表4中每個測試用例均做了3組對比，基于SolrCloud索引的查詢記錄數均和HBase Filter查詢的記錄數一致，說明索引完整可用。

5.2.4 HBase檢索性能

將表4中HBase Filter檢索換成CIMISS系統 Oracle數據庫查詢，且Oracle中T639數據表與HBase T639表均保留2000萬條記錄。考查表4中各測試用例中No.3列所需時間對比如表5所示。

由表5得出結論：無論是UC01、UC03按時間點查詢還是UC02中按時間范圍查詢，基于SolrCloud的查詢效率都高于Oracle SQL查詢；SolrCloud方式按時間點的查詢基本都在毫秒級返回結果。

6 結束語

本文針對關系型數據庫在數值預報產品數據的存儲及檢索效率低的問題，研究HBase分布式數據庫結合SolrCloud索引服務的數據存儲與檢索優化方案，設計了適合氣象業務應用的數值預報產品數據存儲模型，并建立Solr索引。關鍵技術是前端Map并行方式入庫、HBase協處理器同步記錄至SolrCloud。實驗測試驗證了該方案提高了存儲效率和檢索速度，能夠滿足業務中的時效性要求。

對于HBase 的參數調優、動態增加節點時HBase的擴展性能測試以及索引的更新維護將是下一步研究的工作。

參考文獻

[1]熊安元，趙芳，王穎等.全國綜合氣象信息共享系統的設計與實現[J].應用氣象學報，2015，26（04）：500-512.

[2]楊潤芝，馬強，李德泉等.內存轉發模型在CIMISS數據收發系統中的應用[J]. 應用氣象學報，2012，23（03）：377-384.

[3]李永生，曾沁，徐美紅等.基于Hadoop的數值預報產品服務平臺設計與實現[J].應用氣象學報，2015，26（01）：122-128.

[4]陳東輝，曾樂，梁中軍等.基于HBase 的氣象地面分鐘數據分布式存儲系統[J].計算機應用，2014，34（09）：2617-2621.

[5]（美）Tom White.Hadoop權威指南（第3版）[M].北京：清華大學出版社，2015：19-58.

[6]張藶，周崢嶸，劉媛媛.ECMWF GRIB API及其應用[A].中國氣象學會氣象通信與信息技術委員會暨國家氣象信息中心科技年會[C].2011年.

[7]李葳.NECP FNL資料解碼及數據格式轉換[J].氣象與減災研究，34（01）：64-68.

[8]（美）Lars George. HBase權威指南[M]. 北京：人民郵電出版社，2011：344-348.

[9]郝強，高占春.基于SolrCloud的網絡百科檢索服務的實現[J].軟件，2015，36（12）：103-107.

[10]付劍生，徐林龍，林文斌.分布式全網職位搜索引擎的研究與實現[J].計算機技術與發展，2015，25（05）：6-9.

[11]楊潤芝，沈文海，肖衛青等.基于MapReduce計算模型的氣象資料處理調優試驗[J].應用氣象學報，2014，25（05）：618-628.

[12]鄒敏昊.基于Lucene的HBase全文檢索功能的設計與實現[D].南京：南京大學，2013：30-65.

[13]李永生，曾沁，楊玉紅等.基于大數據技術的氣象算法并行化研究[J].計算機技術與發展，2016，26（09）：47-49.

[14]單劍鋒，馬德錦.常用Web服務技術研究[J].計算機技術與發展.2013，23（06）：253-257.

[15]張葉，許國艷，花青.基于HBase的矢量空間數據存儲與訪問優化[J].計算機應用，2015，35（11）：3102-3105.

作者簡介

王建榮（1981-），男，碩士學位。工程師。主研方向為分布式數據庫。

唐懷甌，高工。

金素文，高工。

作者單位

安徽省氣象信息中心 安徽省合肥市 230031