本發(fā)明涉及hbase技術(shù)領(lǐng)域，尤其涉及一種基于solr的Hbase秒級(jí)查詢方案。

背景技術(shù)：

Solr是apache旗下基于lucene的一個(gè)完整的搜索服務(wù)。Solr主要包括兩部分核心組件：索引組件和搜索組件。索引組件用于將需要索引的數(shù)據(jù)在搜索程序中建立索引，而搜索組件用于響應(yīng)客戶端的請(qǐng)求來查詢索引。Solr是一個(gè)高性能，采用Java5開發(fā)，基于Lucene的全文搜索服務(wù)器。同時(shí)對(duì)其進(jìn)行了擴(kuò)展，提供了比Lucene更為豐富的查詢語(yǔ)言，同時(shí)實(shí)現(xiàn)了可配置、可擴(kuò)展并對(duì)查詢性能進(jìn)行了優(yōu)化，并且提供了一個(gè)完善的功能管理界面，是一款非常優(yōu)秀的全文搜索引擎。文檔通過Http利用XML加到一個(gè)搜索集合中。查詢?cè)摷弦彩峭ㄟ^http收到一個(gè)XML/JSON響應(yīng)來實(shí)現(xiàn)。它的主要特性包括：高效、靈活的緩存功能，垂直搜索功能，高亮顯示搜索結(jié)果，通過索引復(fù)制來提高可用性，提供一套強(qiáng)大Data Schema來定義字段，類型和設(shè)置文本分析，提供基于Web的管理界面等。

Hbase是Hadoop家族針對(duì)海量數(shù)據(jù)的分布式存儲(chǔ)方案，當(dāng)我們通過rowkey對(duì)存于Hbase中的海量數(shù)據(jù)進(jìn)行查詢時(shí)可以達(dá)到秒級(jí)的響應(yīng)，實(shí)現(xiàn)比較理想的用戶體驗(yàn)。但是，當(dāng)在比較復(fù)雜的場(chǎng)景下，如需要對(duì)數(shù)據(jù)做多條件查詢時(shí)，Hbase提供的解決方案都不是很理想。

針對(duì)多條件查詢，Hbase本身現(xiàn)階段有兩種比較主流的解決方案：

1、通過協(xié)處理器在插入數(shù)據(jù)時(shí)手動(dòng)建索引表

Hbase中的協(xié)處理器有兩種：Observer和Endpoint。Observer類似于關(guān)系型數(shù)據(jù)庫(kù)中的觸發(fā)器，Endpoint類似于關(guān)系型數(shù)據(jù)庫(kù)中的存儲(chǔ)過程。

我們?cè)诶脜f(xié)處理器建索引表時(shí)使用的是Observer，即在往Hbase表中插入數(shù)據(jù)時(shí)，加入Observer操作，讓每插入一條數(shù)據(jù)前都調(diào)用我們自定義的業(yè)務(wù)邏輯在索引表中生成需要索引字段的記錄。

這樣在我們針對(duì)Hbase進(jìn)行多條件查詢時(shí)，我們的查詢操作分成兩步：第一步首先根據(jù)查詢條件在索引表進(jìn)行查詢，查詢對(duì)應(yīng)結(jié)果的rowkey，第二步再根據(jù)rowkey去主表查詢我們需要的數(shù)據(jù)。

這種方案有幾個(gè)比較大的問題：

(1)協(xié)處理器很不穩(wěn)定

在現(xiàn)版本Hbase中，我們自己測(cè)試通過協(xié)處理器生成索引時(shí)，一旦在建立索引過程中代碼拋出異常，整個(gè)Hadoop集群都會(huì)掛掉。

(2)建索引會(huì)影響插入數(shù)據(jù)的速度

由于插入數(shù)據(jù)與建索引是一個(gè)同步的過程，所以建索引的操作會(huì)在很大程度上影響插入數(shù)據(jù)的速度。

(3)需要索引的字段必須在數(shù)據(jù)插入前確定，后期不能修改

插入數(shù)據(jù)同時(shí)建索引的另一個(gè)問題就是我們必須一次性確定好所有需要建立索引的字段，如果后期需要在一個(gè)新的字段上建立索引，之前已經(jīng)插入的數(shù)據(jù)是不會(huì)自動(dòng)再建立索引的。

(4)每個(gè)索引字段對(duì)應(yīng)一個(gè)索引表效率不高

為了后期使用索引時(shí)靈活，一般在建立索引表時(shí)會(huì)為每個(gè)單獨(dú)的字段都建立一個(gè)索引表。以字段value作為索引表的rowkey，以原表的rowkey作為索引表的字段。這種方式雖然會(huì)方便我們靈活的做多條件查詢，但同時(shí)會(huì)增加索引表的數(shù)量，同時(shí)當(dāng)單詞查詢的查詢條件比較多時(shí)，需要進(jìn)行多次的索引表查詢操作，對(duì)查詢的響應(yīng)也會(huì)有比較大的影響。

2、使用Hbase自帶的過濾器在服務(wù)端過濾

Hbase自帶很多種類的過濾器，同時(shí)我們也可以自定義自己的過濾器。當(dāng)我們?cè)诓樵兊臅r(shí)候使用過濾器，Hbase會(huì)在集群的服務(wù)端對(duì)查詢的結(jié)果數(shù)據(jù)按過濾器的邏輯進(jìn)行過濾。

但同樣，這種方案也有一個(gè)問題：過濾器依然需要掃描數(shù)據(jù)，效率低。

過濾器雖然是在服務(wù)端進(jìn)行過濾，但是依然需要將所有符合rowkey查詢條件的數(shù)據(jù)全部查詢出來，然后再在這些數(shù)據(jù)上進(jìn)行掃描，過濾掉不符合過濾條件的數(shù)據(jù)。這個(gè)過程在原始查詢數(shù)據(jù)量比較大時(shí)會(huì)占用很多服務(wù)端內(nèi)存，同時(shí)掃描時(shí)間也會(huì)很長(zhǎng)，光這一個(gè)過程的耗時(shí)就已經(jīng)不能達(dá)到秒級(jí)查詢的要求。

基于以上兩種方案都有某些特性不能滿足我們的需求，我們提出了一種基于solr的Hbase秒級(jí)查詢方案。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明的目的是為了解決現(xiàn)有技術(shù)中存在的缺點(diǎn)，而提出的一種基于solr的Hbase秒級(jí)查詢方案。

一種基于solr的Hbase秒級(jí)查詢方案，包括以下步驟：

步驟1、將原始數(shù)據(jù)插入Hbase列式數(shù)據(jù)庫(kù)中，保持Hbase原有方式，不需做其他任何更改；

步驟2、獲取原始數(shù)據(jù)并將原始數(shù)據(jù)以solr特有的文檔格式存入solr的服務(wù)端，在建立文檔之后solr會(huì)自動(dòng)對(duì)文檔進(jìn)行分析，完成分析后，solr以切分出的單詞作為key，以文檔作為value進(jìn)行倒排索引，即形成索引，定時(shí)調(diào)用MapReduce增量更新solr中建立的索引；

步驟3、查詢時(shí)，訪問solr服務(wù)端，在需要查詢的字段上單獨(dú)建立索引，查詢索引，從索引中獲取rowkey，再根據(jù)rowkey去Hbase列式數(shù)據(jù)庫(kù)中查詢，即生成所需要的結(jié)果數(shù)據(jù)。

優(yōu)選的，所述solr建立索引之后，會(huì)將索引壓縮存儲(chǔ)在solr服務(wù)端的磁盤中，同時(shí)會(huì)利用Map做部分的緩存。

優(yōu)選的，所述solr索引可以對(duì)分詞器進(jìn)行優(yōu)化，針對(duì)業(yè)務(wù)場(chǎng)景對(duì)分詞進(jìn)行定制化的優(yōu)化，提取出行業(yè)特殊用詞。

優(yōu)選的，所述solr自帶分頁(yè)功能，可以每次返回一頁(yè)數(shù)據(jù)的rowkey。

優(yōu)選的，所述sorl可與成熟的內(nèi)存數(shù)據(jù)庫(kù)相結(jié)合，直接將索引存在內(nèi)存數(shù)據(jù)庫(kù)中。

優(yōu)選的，所述solr建立索引的操作也可以放在Hbase的協(xié)處理器中執(zhí)行。

本發(fā)明提出的一種基于solr的Hbase秒級(jí)查詢方案，搜索速度快，準(zhǔn)確率高，通過solr和hbase相結(jié)合的技術(shù)，實(shí)現(xiàn)對(duì)海量數(shù)據(jù)的秒級(jí)檢索，solr自帶的分頁(yè)功能可以每次返回一頁(yè)數(shù)據(jù)的rowkey，由于每頁(yè)數(shù)據(jù)的數(shù)量極其有限，所以再基于該頁(yè)的rowkey去Hbase查詢時(shí)響應(yīng)速度非常快，可控制在毫秒級(jí)。

附圖說明

圖1為數(shù)據(jù)存儲(chǔ)流程圖；

圖2為數(shù)據(jù)查詢流程圖。

具體實(shí)施方式

下面結(jié)合具體實(shí)施例對(duì)本發(fā)明作進(jìn)一步解說。

參照?qǐng)D1-2，本發(fā)明提出的一種基于solr的Hbase秒級(jí)查詢方案，包括以下步驟：

步驟1、將原始數(shù)據(jù)插入Hbase列式數(shù)據(jù)庫(kù)中，保持Hbase原有方式，不需做其他任何更改；

步驟2、定時(shí)調(diào)用MapReduce增量更新solr中索引，先獲取插入Hbase列式數(shù)據(jù)庫(kù)中的原始數(shù)據(jù)并將原始數(shù)據(jù)以solr特有的文檔格式存入solr的服務(wù)器中，建立文檔之后solr會(huì)自動(dòng)對(duì)文檔進(jìn)行分析，這其中涉及對(duì)文檔中的內(nèi)容按特定的分詞技術(shù)進(jìn)行分詞，完成分詞后，solr以切分出的單詞作為key，以文檔作為value進(jìn)行倒排索引；

步驟3、查詢時(shí)，訪問solr服務(wù)端，在需要查詢的字段上單獨(dú)建立索引，建立索引之后，solr會(huì)將索引壓縮存儲(chǔ)在solr服務(wù)端的磁盤中，同時(shí)會(huì)利用Map做部分的緩存，查詢索引，從索引中獲取rowkey，solr自帶分頁(yè)功能，可以每次返回一頁(yè)數(shù)據(jù)的rowkey，再根據(jù)rowkey去Hbase列式數(shù)據(jù)庫(kù)中查詢，即生成所需要的結(jié)果數(shù)據(jù)。

本發(fā)明中solr建立索引的操作也可以放在Hbase的協(xié)處理器中執(zhí)行，sorl可與成熟的內(nèi)存數(shù)據(jù)庫(kù)相結(jié)合，直接將索引存在內(nèi)存數(shù)據(jù)庫(kù)中。

本發(fā)明提出的一種基于solr的Hbase秒級(jí)查詢方案，搜索速度快，準(zhǔn)確率高，通過solr和hbase相結(jié)合的技術(shù)，實(shí)現(xiàn)對(duì)海量數(shù)據(jù)的秒級(jí)檢索，solr自帶的分頁(yè)功能可以每次返回一頁(yè)數(shù)據(jù)的rowkey，由于每頁(yè)數(shù)據(jù)的數(shù)量極其有限，所以再基于該頁(yè)的rowkey去Hbase查詢時(shí)響應(yīng)速度非?？?，可控制在毫秒級(jí)。

以上所述，僅為本發(fā)明較佳的具體實(shí)施方式，但本發(fā)明的保護(hù)范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，根據(jù)本發(fā)明的技術(shù)方案及其發(fā)明構(gòu)思加以等同替換或改變，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。