基于HBase的數(shù)值預(yù)報(bào)產(chǎn)品存儲(chǔ)檢索應(yīng)用

數(shù)值預(yù)報(bào)產(chǎn)品數(shù)據(jù)快速增長(zhǎng)，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)對(duì)其存儲(chǔ)和管理能力不足，查詢規(guī)模較大的歷史數(shù)據(jù)時(shí)效率較低。鑒于此，基于HBase設(shè)計(jì)了分布式的數(shù)據(jù)存儲(chǔ)模型，應(yīng)用MapReduce將數(shù)值預(yù)報(bào)產(chǎn)品解碼信息存入HBase，并將解碼得到的要素GRIB文件寫入HDFS。因HBase對(duì)Rowkey的一級(jí)索引支持較好，而對(duì)多條件查詢支持不足，需輔助 Solr索引加以優(yōu)化。HBase接收數(shù)據(jù)時(shí)自動(dòng)觸發(fā)協(xié)處理器同步記錄到Solr，實(shí)現(xiàn)了HBase的二級(jí)索引。測(cè)試結(jié)果表明，最快入庫(kù)速度可達(dá)每秒16145條，數(shù)據(jù)檢索結(jié)果返回時(shí)效達(dá)到毫秒級(jí)，能夠滿足業(yè)務(wù)應(yīng)用中對(duì)數(shù)值預(yù)報(bào)產(chǎn)品存儲(chǔ)和檢索時(shí)效的要求。

【關(guān)鍵詞】HBase MapReduce 要素GRIB文件 解碼日志文件 SolrCloud

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

在分布式存儲(chǔ)和計(jì)算技術(shù)中，Hadoop平臺(tái)具有高吞吐量、高并發(fā)、高容錯(cuò)性、高可靠性、低成本、能擴(kuò)展到云環(huán)境的優(yōu)勢(shì)。目前基于Hadoop生態(tài)系統(tǒng)的氣象數(shù)據(jù)存儲(chǔ)檢索方案成為國(guó)內(nèi)外研究熱點(diǎn)。李永生等[3]選用Hadoop與HBase相結(jié)合的方式設(shè)計(jì)數(shù)值預(yù)報(bào)產(chǎn)品服務(wù)平臺(tái)；陳東輝等[4] 詳細(xì)介紹了基于HBase 的氣象地面分鐘數(shù)據(jù)分布式存儲(chǔ)系統(tǒng)。本文選取HBase數(shù)據(jù)庫(kù)實(shí)現(xiàn)氣象數(shù)據(jù)文件的分布式存儲(chǔ)管理，并實(shí)現(xiàn)前端GRIB解碼入庫(kù)性能優(yōu)化和后端數(shù)據(jù)檢索性能優(yōu)化。實(shí)驗(yàn)測(cè)試驗(yàn)證了基于HBase 的數(shù)值預(yù)報(bào)產(chǎn)品存儲(chǔ)與檢索方案的可行性，為海量氣象數(shù)據(jù)的存儲(chǔ)和檢索服務(wù)提供一種優(yōu)化思路。

1 數(shù)據(jù)存儲(chǔ)模型設(shè)計(jì)

1.1 HBase簡(jiǎn)介

Apache Hadoop是一個(gè)分布式系統(tǒng)基礎(chǔ)架構(gòu)，包括兩大核心：Hadoop分布式文件系統(tǒng)HDFS和MapReduce分布式編程模型[5]。HBase（Hadoop DataBase）作為Hadoop中的一個(gè)子項(xiàng)目，使用Zookeeper管理集群，運(yùn)行在HDFS分布式文件系統(tǒng)之上，提供高可靠性、高性能、列存儲(chǔ)、可伸縮、實(shí)時(shí)讀寫的分布式數(shù)據(jù)庫(kù)，主要用來(lái)存儲(chǔ)非結(jié)構(gòu)化和半結(jié)構(gòu)化的松散數(shù)據(jù)。

Zookeeper 分布式服務(wù)框架是 Apache Hadoop的一個(gè)子項(xiàng)目，它主要是用來(lái)解決分布式應(yīng)用中經(jīng)常遇到的一些數(shù)據(jù)管理問(wèn)題，如：統(tǒng)一命名服務(wù)、狀態(tài)同步服務(wù)、集群管理、分布式應(yīng)用配置項(xiàng)的管理等。

1.2 數(shù)據(jù)存儲(chǔ)模型設(shè)計(jì)

研究方案將數(shù)值預(yù)報(bào)產(chǎn)品通過(guò)GRIB API解碼[6-7]后存儲(chǔ)在HBase中，不同的數(shù)值預(yù)報(bào)產(chǎn)品分開(kāi)存儲(chǔ)在不同的實(shí)體數(shù)據(jù)表中，目前實(shí)際存儲(chǔ)了3大類數(shù)值預(yù)報(bào)產(chǎn)品，包括ECMWF（歐洲中期數(shù)值預(yù)報(bào)中心）發(fā)布的細(xì)網(wǎng)格（0.25? ×0.25?水平分辨率）的數(shù)值預(yù)報(bào)產(chǎn)品，JMA（日本氣象廳）發(fā)布的0.5? ×0.5?水平分辨率數(shù)值預(yù)報(bào)產(chǎn)品，高分辨率東北半球T639數(shù)值產(chǎn)品。數(shù)據(jù)表以行鍵、列族、數(shù)據(jù)的方式存儲(chǔ)數(shù)值產(chǎn)品的實(shí)體數(shù)據(jù)。數(shù)據(jù)表存儲(chǔ)內(nèi)容說(shuō)明如表1所示。

data：gribpath是解碼所得要素GRIB文件的在HDFS文件系統(tǒng)中的存儲(chǔ)路徑，GRIB包含的格點(diǎn)數(shù)據(jù)在Rest Web Service接口調(diào)用時(shí)作為二維數(shù)組返回。

選取表1中data：date、data：validtime和data：centre三列做數(shù)據(jù)模型展示，見(jiàn)表2。

行鍵的設(shè)計(jì)：

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

以ECMF數(shù)據(jù)表的行鍵為例：

TEMP9006：20160711：1000010：0250X0250

其含義是：對(duì)于溫度要素（temp），在2016 年7 月11日00：00 起報(bào)，預(yù)報(bào)時(shí)效為未來(lái)6h的預(yù)報(bào)場(chǎng)，預(yù)報(bào)層次為10hPa，I方向增量為0.25?，J方向增量為0.25?。

時(shí)間戳（Timestamp）：每條數(shù)據(jù)更新的歷史記錄，同一行鍵數(shù)據(jù)再次入庫(kù)會(huì)記錄不同的時(shí)間戳。

列族（Column Family）：每種數(shù)值預(yù)報(bào)產(chǎn)品的表結(jié)構(gòu)基本相同，每張表只設(shè)一個(gè)列族data，其包含的列（Column Qualifier）有data：date、data：validtime、data：centre、data：gribpath等。HBase存儲(chǔ)的都是Byte數(shù)組。

2 基于Solr的二級(jí)索引設(shè)計(jì)

2.1 Solr簡(jiǎn)介

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

2.2 SolrCloud的工作模式

SolrCloud中包含有多個(gè)Solr Instance，每個(gè)Solr Instance中包含多個(gè)Solr Core，Solr Core對(duì)應(yīng)著一個(gè)可訪問(wèn)的Solr索引資源Replica（復(fù)本），當(dāng)Solr Client通過(guò)Collection訪問(wèn)Solr集群時(shí)，便可以通過(guò)Shard分片找到對(duì)應(yīng)的Replica，從而就可以訪問(wèn)索引文檔了，如圖1所示。

在SolrCloud模式下，同一個(gè)集群里所有Core的配置是統(tǒng)一的，Core有Leader和Replication兩種角色，每個(gè)Core一定屬于一個(gè)Shard，Core在Shard中扮演Leader還是Replication由Zookeeper自動(dòng)協(xié)調(diào)。

2.3 二級(jí)索引設(shè)計(jì)

HBase在存儲(chǔ)時(shí)，默認(rèn)按照Rowkey進(jìn)行排序（字典序）并通過(guò)Rowkey及其range來(lái)檢索數(shù)據(jù)，在HBase查詢的時(shí)候，有以下幾種方式：

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

（2）通過(guò)scan方式，設(shè)置startRow和stopRow參數(shù)進(jìn)行范圍匹配；

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

HBase對(duì)Rowkey的一級(jí)索引支持較好，按Rowkey查詢的響應(yīng)時(shí)間達(dá)到毫秒級(jí)。HBase內(nèi)置Filter（過(guò)濾器）特性以支持多條件查詢的二級(jí)索引。但HBase的Filter是直接掃描記錄的，如果數(shù)據(jù)范圍很大，會(huì)導(dǎo)致查詢速度很慢。因此基于Solr來(lái)實(shí)現(xiàn)二級(jí)索引，滿足Rowkey之外的多要素?cái)?shù)據(jù)檢索需求。

基于Solr的HBase多條件查詢?cè)恚簩Base表中涉及條件過(guò)濾的字段和Rowkey在Solr中建立索引，通過(guò)Solr的多條件查詢快速獲得符合過(guò)濾條件的Rowkey值，再根據(jù)Rowkey從HBase中進(jìn)行查詢，返回記錄集，如圖2所示。

設(shè)計(jì)SolrCloud索引的關(guān)鍵問(wèn)題是合理的配置索引字段。Zookeeper統(tǒng)一管理XML格式的Solr索引字段描述文件文件：managed-schema，SolrCloud各實(shí)例（Instance）共享同一個(gè)managed-schema。具體配置如下：

……

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

3.2 HBase協(xié)處理器

HBase的協(xié)處理器[12]（Coprocessor）分為兩類，Observer和EndPoint：Observer相當(dāng)于關(guān)系型數(shù)據(jù)庫(kù)中的觸發(fā)器，EndPoint則相當(dāng)于存儲(chǔ)過(guò)程。其中Observer的代碼部署在服務(wù)端，相當(dāng)于對(duì)API調(diào)用的代理。選用RegionObserver觀察者接口（API），其提供客戶端的數(shù)據(jù)操縱事件鉤子：Get、Put、Delete、Scan等。

3.3 HBase協(xié)處理器向Solr寫索引

實(shí)時(shí)更新數(shù)據(jù)需要獲取到HBase的插入、更新和刪除操作：攔截put和delete操作，將其內(nèi)容獲取出來(lái)，同步寫入Solr。HBase協(xié)處理器定義以及同步數(shù)據(jù)到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對(duì)象）對(duì)應(yīng)HBase表里的一條記錄。HBase記錄寫入SolrCloud的性能優(yōu)化：默認(rèn)情況下HBase每寫入一條數(shù)據(jù)就會(huì)觸發(fā)一次postPut，比較耗費(fèi)網(wǎng)絡(luò)IO，因此先將Document緩存在List中并采用兩種方式批量提交：

（1）當(dāng)緩存達(dá)到設(shè)定的閾值時(shí)立即提交到SolrCloud；

（2）定時(shí)提交。

最后需要通過(guò)HBase Shell為相關(guān)產(chǎn)品數(shù)據(jù)表添加協(xié)處理器。

5 性能測(cè)試

5.1 測(cè)試環(huán)境

（1）軟件及版本：

hadoop-2.6.0；

zookeeper-3.4.6；

solr 5.5.4，使用其自帶的Jetty服務(wù)端容器，云模式運(yùn)行；

hbase-1.2.2；

GRIB API 1.12.3。

（2）硬件配置：

測(cè)試環(huán)境由4臺(tái)X86架構(gòu)的服務(wù)器組成，操作系統(tǒng)均為64位CentOS 6.5。其中3臺(tái)服務(wù)器構(gòu)建Hadoop、Zookeeper、HBase、Solr集群，1臺(tái)部署數(shù)值預(yù)報(bào)產(chǎn)品解碼入庫(kù)程序（Hadoop、HBase等客戶端程序）；

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

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

內(nèi)存：16GB；

網(wǎng)絡(luò)環(huán)境為千兆局域網(wǎng)。

5.2 測(cè)試對(duì)象和方法

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

5.2.1 HDFS寫入性能

T639數(shù)值產(chǎn)品共504個(gè)文件，共24.9GB，平均大小50.59 MB?？蛻舳顺绦蛘{(diào)用HDFS API的文件復(fù)制操作將T639數(shù)值產(chǎn)品文件寫入HDFS文件系統(tǒng)需要347秒，平均寫文件速度為73.48MB/s。

5.2.2 HBase入庫(kù)性能

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

5.2.3 索引完整性驗(yàn)證

測(cè)試用例設(shè)計(jì)如表3。

在驗(yàn)證Solr索引完整性上，分別對(duì)基于HBase Filter[15]的條件過(guò)濾查詢和SolrCloud索引查詢返回的記錄數(shù)對(duì)比，如表4所示。

表4中每個(gè)測(cè)試用例均做了3組對(duì)比，基于SolrCloud索引的查詢記錄數(shù)均和HBase Filter查詢的記錄數(shù)一致，說(shuō)明索引完整可用。

5.2.4 HBase檢索性能

將表4中HBase Filter檢索換成CIMISS系統(tǒng) Oracle數(shù)據(jù)庫(kù)查詢，且Oracle中T639數(shù)據(jù)表與HBase T639表均保留2000萬(wàn)條記錄?？疾楸?中各測(cè)試用例中No.3列所需時(shí)間對(duì)比如表5所示。

由表5得出結(jié)論：無(wú)論是UC01、UC03按時(shí)間點(diǎn)查詢還是UC02中按時(shí)間范圍查詢，基于SolrCloud的查詢效率都高于Oracle SQL查詢；SolrCloud方式按時(shí)間點(diǎn)的查詢基本都在毫秒級(jí)返回結(jié)果。

6 結(jié)束語(yǔ)

本文針對(duì)關(guān)系型數(shù)據(jù)庫(kù)在數(shù)值預(yù)報(bào)產(chǎn)品數(shù)據(jù)的存儲(chǔ)及檢索效率低的問(wèn)題，研究HBase分布式數(shù)據(jù)庫(kù)結(jié)合SolrCloud索引服務(wù)的數(shù)據(jù)存儲(chǔ)與檢索優(yōu)化方案，設(shè)計(jì)了適合氣象業(yè)務(wù)應(yīng)用的數(shù)值預(yù)報(bào)產(chǎn)品數(shù)據(jù)存儲(chǔ)模型，并建立Solr索引。關(guān)鍵技術(shù)是前端Map并行方式入庫(kù)、HBase協(xié)處理器同步記錄至SolrCloud。實(shí)驗(yàn)測(cè)試驗(yàn)證了該方案提高了存儲(chǔ)效率和檢索速度，能夠滿足業(yè)務(wù)中的時(shí)效性要求。

對(duì)于HBase 的參數(shù)調(diào)優(yōu)、動(dòng)態(tài)增加節(jié)點(diǎn)時(shí)HBase的擴(kuò)展性能測(cè)試以及索引的更新維護(hù)將是下一步研究的工作。

參考文獻(xiàn)

[1]熊安元，趙芳，王穎等.全國(guó)綜合氣象信息共享系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].應(yīng)用氣象學(xué)報(bào)，2015，26（04）：500-512.

[2]楊潤(rùn)芝，馬強(qiáng)，李德泉等.內(nèi)存轉(zhuǎn)發(fā)模型在CIMISS數(shù)據(jù)收發(fā)系統(tǒng)中的應(yīng)用[J]. 應(yīng)用氣象學(xué)報(bào)，2012，23（03）：377-384.

[3]李永生，曾沁，徐美紅等.基于Hadoop的數(shù)值預(yù)報(bào)產(chǎn)品服務(wù)平臺(tái)設(shè)計(jì)與實(shí)現(xiàn)[J].應(yīng)用氣象學(xué)報(bào)，2015，26（01）：122-128.

[4]陳東輝，曾樂(lè)，梁中軍等.基于HBase 的氣象地面分鐘數(shù)據(jù)分布式存儲(chǔ)系統(tǒng)[J].計(jì)算機(jī)應(yīng)用，2014，34（09）：2617-2621.

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

[6]張藶，周崢嶸，劉媛媛.ECMWF GRIB API及其應(yīng)用[A].中國(guó)氣象學(xué)會(huì)氣象通信與信息技術(shù)委員會(huì)暨國(guó)家氣象信息中心科技年會(huì)[C].2011年.

[7]李葳.NECP FNL資料解碼及數(shù)據(jù)格式轉(zhuǎn)換[J].氣象與減災(zāi)研究，34（01）：64-68.

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

[9]郝強(qiáng)，高占春.基于SolrCloud的網(wǎng)絡(luò)百科檢索服務(wù)的實(shí)現(xiàn)[J].軟件，2015，36（12）：103-107.

[10]付劍生，徐林龍，林文斌.分布式全網(wǎng)職位搜索引擎的研究與實(shí)現(xiàn)[J].計(jì)算機(jī)技術(shù)與發(fā)展，2015，25（05）：6-9.

[11]楊潤(rùn)芝，沈文海，肖衛(wèi)青等.基于MapReduce計(jì)算模型的氣象資料處理調(diào)優(yōu)試驗(yàn)[J].應(yīng)用氣象學(xué)報(bào)，2014，25（05）：618-628.

[12]鄒敏昊.基于Lucene的HBase全文檢索功能的設(shè)計(jì)與實(shí)現(xiàn)[D].南京：南京大學(xué)，2013：30-65.

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

[14]單劍鋒，馬德錦.常用Web服務(wù)技術(shù)研究[J].計(jì)算機(jī)技術(shù)與發(fā)展.2013，23（06）：253-257.

[15]張葉，許國(guó)艷，花青.基于HBase的矢量空間數(shù)據(jù)存儲(chǔ)與訪問(wèn)優(yōu)化[J].計(jì)算機(jī)應(yīng)用，2015，35（11）：3102-3105.

作者簡(jiǎn)介

王建榮（1981-），男，碩士學(xué)位。工程師。主研方向?yàn)榉植际綌?shù)據(jù)庫(kù)。

唐懷甌，高工。

金素文，高工。

作者單位

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