0 HBase簡(jiǎn)介

HBase是一個(gè)構(gòu)建在HDFS之上，用于海量數(shù)據(jù)存儲(chǔ)分布式列存儲(chǔ)系統(tǒng)。

表的每行都是按照RowKey的字典序排序存儲(chǔ)
表的數(shù)據(jù)是按照RowKey區(qū)間進(jìn)行分割存儲(chǔ)成多個(gè)region

所以HBase主要適用下面這兩種常見場(chǎng)景：

適用于基于rowkey的單行數(shù)據(jù)快速隨機(jī)讀寫
適合基于rowkey前綴的范圍掃描

1 為什么需要二級(jí)索引

HBase的一級(jí)索引就是rowkey，我們僅僅能通過(guò)rowkey進(jìn)行檢索。假設(shè)我們相對(duì)Hbase里面列族的列列進(jìn)行一些組合查詢，就只能全表掃描了。表如果較大的話，代價(jià)是不可接受的，所以要提出二級(jí)索引的方案。

二級(jí)索引的思想：簡(jiǎn)單理解就是，根據(jù)列族的列的值，查出rowkey，再按照rowkey就能很快從hbase查詢出數(shù)據(jù)，我們需要構(gòu)建出根據(jù)列族的列的值，很快查出rowkey的方案。

2 常見的二級(jí)索引方案

MapReduce方案；
Coprocessor方案；
elasticsearch+hbase方案；
Solr+hbase方案；

2.1 MapReduce方案

IndexBuilder：利用MR的方式構(gòu)建Index 長(zhǎng)處：并發(fā)批量構(gòu)建Index 缺點(diǎn)：不能實(shí)時(shí)構(gòu)建Index

舉例： 原表：

row  1      f1:name  zhangsan
row  2      f1:name  lisi
row  3      f1:name  wangwu

索引表：

row     zhangsan    f1:id   1
row     lisi        f1:id   2
row     wangwu      f1:id   3

這種方式的思想是再構(gòu)建一張hbase表，列族的列這里的name作為索引表的rowkey，根據(jù)rowkey查詢出數(shù)據(jù)hbase是很快的，拿到id后，也就拿到了原表的rowkey了，因?yàn)樵幢淼膔owkey就是id，每次查詢一共需要查詢兩張表。

2.2 Coprocessor方案

有關(guān)協(xié)處理器的講解，Hbase官方文檔是最好的，這里大體說(shuō)一下它的作用與使用方法。

Coprocessor提供了一種機(jī)制可以讓開發(fā)者直接在RegionServer上運(yùn)行自定義代碼來(lái)管理數(shù)據(jù)。通常我們使用get或者scan來(lái)從Hbase中獲取數(shù)據(jù)，使用Filter過(guò)濾掉不需要的部分，最后在獲得的數(shù)據(jù)上執(zhí)行業(yè)務(wù)邏輯。但是當(dāng)數(shù)據(jù)量非常大的時(shí)候，這樣的方式就會(huì)在網(wǎng)絡(luò)層面上遇到瓶頸。客戶端也需要強(qiáng)大的計(jì)算能力和足夠大的內(nèi)存來(lái)處理這么多的數(shù)據(jù)，客戶端的壓力就會(huì)大大增加。但是如果使用Coprocessor，就可以將業(yè)務(wù)代碼封裝，并在RegionServer上運(yùn)行，也就是數(shù)據(jù)在哪里，我們就在哪里跑代碼，這樣就節(jié)省了很大的數(shù)據(jù)傳輸?shù)木W(wǎng)絡(luò)開銷。
Coprocessor有兩種：Observer和Endpoint EndPoint主要是做一些計(jì)算用的，比如計(jì)算一些平均值或者求和等等。而Observer的作用類似于傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的觸發(fā)器，在一些特定的操作之前或者之后觸發(fā)。學(xué)習(xí)過(guò)Spring的朋友肯定對(duì)AOP不陌生，想象一下AOP是怎么回事，就會(huì)很好的理解Observer了。Observer Coprocessor在一個(gè)特定的事件發(fā)生前或發(fā)生后觸發(fā)。在事件發(fā)生前觸發(fā)的Coprocessor需要重寫以pre作為前綴的方法，比如prePut。在事件發(fā)生后觸發(fā)的Coprocessor使用方法以post作為前綴，比如postPut。 Observer Coprocessor的使用場(chǎng)景如下： 2.1. 安全性：在執(zhí)行Get或Put操作前，通過(guò)preGet或prePut方法檢查是否允許該操作； 2.2. 引用完整性約束：HBase并不直接支持關(guān)系型數(shù)據(jù)庫(kù)中的引用完整性約束概念，即通常所說(shuō)的外鍵。但是我們可以使用Coprocessor增強(qiáng)這種約束。比如根據(jù)業(yè)務(wù)需要，我們每次寫入user表的同時(shí)也要向user_daily_attendance表中插入一條相應(yīng)的記錄，此時(shí)我們可以實(shí)現(xiàn)一個(gè)Coprocessor，在prePut方法中添加相應(yīng)的代碼實(shí)現(xiàn)這種業(yè)務(wù)需求。 2.3. 二級(jí)索引：可以使用Coprocessor來(lái)維持一個(gè)二級(jí)索引。正是我們需要的

索引設(shè)計(jì)思想

關(guān)鍵部分來(lái)了，既然Hbase并沒有提供二級(jí)索引，那如何實(shí)現(xiàn)呢？先看下面這張圖

我們的需求是找出滿足cf1:col2=c22這條記錄的cf1:col1的值，實(shí)現(xiàn)方法如圖，首先根據(jù)cf1:col2=c22查找到該記錄的行鍵，然后再通過(guò)行健找到對(duì)應(yīng)的cf1:col1的值。其中第二步是很容易實(shí)現(xiàn)的，因?yàn)镠base的行鍵是有索引的，那關(guān)鍵就是第一步，如何通過(guò)cf1:col2的值找到它對(duì)應(yīng)的行鍵。很容易想到建立cf1:col2的映射關(guān)系，即將它們提取出來(lái)單獨(dú)放在一張索引表中，原表的值作為索引表的行鍵，原表的行鍵作為索引表的值，這就是Hbase的倒排索引的思想。

雖然官方一直也沒提供內(nèi)置的支持二級(jí)索引的工具，不過(guò)業(yè)界也有些比較知名的基于Coprocessor的開源方案：

華為的hindex ：基于0.94版本，當(dāng)年剛出來(lái)的時(shí)候比較火，但是版本較舊，看GitHub項(xiàng)目地址最近這幾年就沒更新過(guò)。
Apache Phoenix：功能圍繞著SQL on hbase，支持和兼容多個(gè)hbase版本，二級(jí)索引只是其中一塊功能。二級(jí)索引的創(chuàng)建和管理直接有SQL語(yǔ)法支持，使用起來(lái)很簡(jiǎn)便，該項(xiàng)目目前社區(qū)活躍度和版本更新迭代情況都比較好。

ApachePhoenix在目前開源的方案中，是一個(gè)比較優(yōu)的選擇。主打SQL on HBase ，基于SQL能完成HBase的CRUD操作，支持JDBC協(xié)議。 Apache Phoenix在Hadoop生態(tài)里面位置：

Phoenix二級(jí)索引特點(diǎn)：

Covered Indexes(覆蓋索引) ：把關(guān)注的數(shù)據(jù)字段也附在索引表上，只需要通過(guò)索引表就能返回所要查詢的數(shù)據(jù)（列），所以索引的列必須包含所需查詢的列(SELECT的列和WHRER的列)。
Functional indexes(函數(shù)索引)：索引不局限于列，支持任意的表達(dá)式來(lái)創(chuàng)建索引。
Global indexes(全局索引)：適用于讀多寫少場(chǎng)景。通過(guò)維護(hù)全局索引表，所有的更新和寫操作都會(huì)引起索引的更新，寫入性能受到影響。在讀數(shù)據(jù)時(shí)，Phoenix SQL會(huì)基于索引字段，執(zhí)行快速查詢。
Local indexes(本地索引)：適用于寫多讀少場(chǎng)景。在數(shù)據(jù)寫入時(shí)，索引數(shù)據(jù)和表數(shù)據(jù)都會(huì)存儲(chǔ)在本地。在數(shù)據(jù)讀取時(shí)，由于無(wú)法預(yù)先確定region的位置，所以在讀取數(shù)據(jù)時(shí)需要檢查每個(gè)region（以找到索引數(shù)據(jù)），會(huì)帶來(lái)一定性能（網(wǎng)絡(luò)）開銷。

其他的在網(wǎng)上也很多自己基于Coprocessor實(shí)現(xiàn)二級(jí)索引的文章，大體都是遵循類似的思路：構(gòu)建一份“索引”的映射關(guān)系，存儲(chǔ)在另一張hbase表或者其他DB里面。

方案優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)： 基于Coprocessor的方案，從開發(fā)設(shè)計(jì)的角度看，把很多對(duì)二級(jí)索引管理的細(xì)節(jié)都封裝在的Coprocessor具體實(shí)現(xiàn)類里面，這些細(xì)節(jié)對(duì)外面讀寫的人是無(wú)感知的，簡(jiǎn)化了數(shù)據(jù)訪問者的使用。
缺點(diǎn)： 但是Coprocessor的方案入侵性比較強(qiáng)，增加了在Regionserver內(nèi)部需要運(yùn)行和維護(hù)二級(jí)索引關(guān)系表的代碼邏輯等，對(duì)Regionserver的性能會(huì)有一定影響。

2.3 elasticsearch+hbase方案

比如說(shuō)你現(xiàn)在有一行數(shù)據(jù)

id name age ….30 個(gè)字段

但是你現(xiàn)在搜索，只需要根據(jù) id name age 三個(gè)字段來(lái)搜索

如果你傻乎乎的往 es 里寫入一行數(shù)據(jù)所有的字段，就會(huì)導(dǎo)致說(shuō) 70% 的數(shù)據(jù)是不用來(lái)搜索的，結(jié)果硬是占據(jù)了 es 機(jī)器上的 filesystem cache 的空間，單挑數(shù)據(jù)的數(shù)據(jù)量越大，就會(huì)導(dǎo)致 filesystem cahce 能緩存的數(shù)據(jù)就越少

僅僅只是寫入 es 中要用來(lái)檢索的少數(shù)幾個(gè)字段就可以了，比如說(shuō)，就寫入 es id name age 三個(gè)字段就可以了，然后你可以把其他的字段數(shù)據(jù)存在 MySQL 里面，我們一般是建議用 es + hbase 的這么一個(gè)架構(gòu)。

hbase 的特點(diǎn)是適用于海量數(shù)據(jù)的在線存儲(chǔ)，就是對(duì) hbase 可以寫入海量數(shù)據(jù)，不要做復(fù)雜的搜索，就是做很簡(jiǎn)單的一些根據(jù) id 或者范圍進(jìn)行查詢的這么一個(gè)操作就可以了

從 es 中根據(jù) name 和 age 去搜索，拿到的結(jié)果可能就 20 個(gè) doc id，然后根據(jù) doc id 到 hbase 里去查詢每個(gè) doc id 對(duì)應(yīng)的完整的數(shù)據(jù)，給查出來(lái)，再返回給前端。

你最好是寫入 es 的數(shù)據(jù)小于等于，或者是略微大于 es 的 filesystem cache 的內(nèi)存容量

然后你從 es 檢索可能就花費(fèi) 20ms，然后再根據(jù) es 返回的 id 去 hbase 里查詢，查 20 條數(shù)據(jù)，可能也就耗費(fèi)個(gè) 30ms，可能你原來(lái)那么玩兒，1T 數(shù)據(jù)都放 es，會(huì)每次查詢都是 5 ~ 10 秒，現(xiàn)在可能性能就會(huì)很高，每次查詢就是 50ms。

四個(gè)字總結(jié)的話，我覺得就是“各司其職”，HBase 就用來(lái)存儲(chǔ)，ES 就用來(lái)做索引，況且目前的實(shí)際情況跟文章中說(shuō)的也很像，要查詢的字段就幾個(gè)，而其他的字段又很大又沒用，沒必要都丟到 ES 中，浪費(fèi)查詢效率

2.4 Solr+hbase方案

Solr是一個(gè)獨(dú)立的企業(yè)級(jí)搜索應(yīng)用server，它對(duì)并提供相似干Web-service的API接口。用戶能夠通過(guò)http請(qǐng)求，向搜索引擎server提交一定格式的XML文件，生成索引。也能夠通過(guò)Http Get操作提出查找請(qǐng)求，并得到XML格式的返回結(jié)果。

Solr是一個(gè)高性能。採(cǎi)用JAVA5開發(fā)。基干Lucene的全文搜索server。同一時(shí)候?qū)ζ溥M(jìn)行了擴(kuò)展。提供了比Lucene更為豐富的查詢語(yǔ)言，同一時(shí)候?qū)崿F(xiàn)了可配置、可擴(kuò)展并對(duì)查詢性能進(jìn)行了優(yōu)化，而且提供了一個(gè)完好的功能節(jié)理界面。是一款非常優(yōu)秀的全文搜索引擎。

HBase無(wú)可置疑擁有其優(yōu)勢(shì)，但其本身僅僅對(duì)rowkey支持毫秒級(jí)的高速檢索，對(duì)于多字段的組合查詢卻無(wú)能為力。基于Solr的HBase多條件查詢?cè)矸浅asy。將HBase表中涉及條件過(guò)濾的字段和rowkey在Solr中建立索引，通過(guò)Solr的多條件查詢高速獲得符合過(guò)濾條件的rowkey值，拿到這些rowkey之后在HBASE中通過(guò)指定rowkey進(jìn)行查詢。