HBase實操 | 使用Phoenix在CDH的HBase建立二級索引

HBase · 發表 2018-11-16 13:53:25

摘要： 1.文件編寫目的對於HBase而言，如果想精確地定位到某行記錄，唯一的辦法是通過rowkey來查詢。如果不通過rowkey來查詢資料，就必須逐行地比較每一列的值，即全表掃瞄。對於較大的表，全表掃描的代價是不可接受的。但是，很多情況下，需要從多個角度查詢資料。例如，在定位某個人的時候...

1.文件編寫目的

對於HBase而言，如果想精確地定位到某行記錄，唯一的辦法是通過rowkey來查詢。如果不通過rowkey來查詢資料，就必須逐行地比較每一列的值，即全表掃瞄。對於較大的表，全表掃描的代價是不可接受的。

但是，很多情況下，需要從多個角度查詢資料。例如，在定位某個人的時候，可以通過姓名、身份證號、學籍號等不同的角度來查詢，要想把這麼多角度的資料都放到rowkey中幾乎不可能(業務的靈活性不允許，對rowkey長度的要求也不允許)。

所以，需要secondary index來完成這件事。secondary index的原理很簡單，即通過索引表來實現，但是如果自己維護的話則會麻煩一些。在很早的版本中，Phoenix就已經提供了對HBase secondary index的支援。

Fayson在前面的文章《Cloudera Labs中的Phoenix》和《如何在CDH中使用Phoenix》中介紹了Cloudera Labs中的Phoenix，以及如何在CDH5.11.2中安裝和使用Phoenix4.7。本文Fayson主要介紹如何在CDH中使用Phoenix在HBase上建立二級索引。

內容概述：

1.建表與資料準備

2.啟用Kafka的Sentry賦權

3.Kafka的賦權測試

4.總結

測試環境：

1.CM5.14.3/CDH5.14.2

2.Phoenix4.7.0

3.作業系統版本為Redhat7.4

4.採用root使用者進行操作

5.叢集未啟用Kerberos

2.建表與資料準備

1.首先確保你的CDH叢集已經安裝Phoenix的Parcel，安裝過程省略，具體可以參考《如何在CDH中使用Phoenix》。

2.準備一個測試csv檔案用來匯入Phoenix的表中，Fayson這裡準備一個1.2GB，995W行，11個欄位的資料檔案。

3.連線到Phoenix的終端，在Phoenix中建表hbase_test

4.將準備好的csv檔案put到HDFS，然後通過Phoenix自帶的bulkload工具將準備好的csv檔案批量匯入到Phoenix的表中。

5.在Phoenix和hbase shell中分別查詢確認資料入庫成功。

3.Covered Indexes(覆蓋索引)

1.使用覆蓋索引獲取資料的過程中，內部不需要再去HBase的原表獲取資料，查詢需要返回的列都會被儲存在索引中。要想達到這種效果，你的select的列，where的列都需要在索引中出現。舉個例子，如果你的SQL語句是select s2 from hbase_test where s6='13505503576'，要最大化查詢效率和速度最快，可以建立覆蓋索引。

提示要對HBase進行一些配置才能執行該語句。

2.將以下配置增加到hbase-site.xml，通過Cloudera Manager搜尋HBase服務的“hbase-site.xml 的 HBase 服務高階配置程式碼段（安全閥）”。

儲存更改，然後重啟HBase。

3.在執行建立覆蓋索引之前，我們先執行2個查詢語句方便後面跟建立索引後的查詢時間進行對比。

4.再次執行建立覆蓋索引的語句

5.再次執行上面2個查詢語句。

發現都是毫秒級返回，而之前2個查詢都是需要30幾秒。

6.我們再來具體看看建立覆蓋索引的語句。

4.Functional Indexes(函式索引)

函式索引從從Phoenix4.3版本就有，這種索引的內容不侷限於列，還能在表示式上建立索引。如果你使用的表示式正好就是索引的話，資料也可以直接從這個索引獲取，而不需要從資料庫獲取。

1.在建立函式索引時，我們先執行兩個查詢語句好方便與建立索引以後的效能進行對比。

2.建立函式索引

3.再次執行前面的查詢語句進行比較

如果查詢項包含substr(s7,1,10)，則查詢時間在毫秒級，而之前需要30多秒。如果查詢項不包含substr(s7,1,10)，則跟不建索引時是一樣的。如果想讓第一個查詢語句走索引，我們可以在建立索引時採用INCLUDE(S7)來實現。

5.Global Indexes(全域性索引)

全域性索引適合那些讀多寫少的場景。如果使用全域性索引，讀資料基本不損耗效能，所有的效能損耗都來源於寫資料。資料表的新增、刪除和修改都會更新相關的索引表（資料刪除了，索引表中的資料也會刪除；資料增加了，索引表的資料也會增加）。而查詢資料的時候，Phoenix會通過索引表來快速低損耗的獲取資料。預設情況下，如果你的查詢語句中沒有索引相關的列的時候，Phoenix不會使用索引。

6.Local Indexes(本地索引)

本地索引適合那些寫多讀少，或者儲存空間有限的場景。和全域性索引一樣，Phoenix也會在查詢的時候自動選擇是否使用本地索引。本地索引之所以是本地，只要是因為索引資料和真實資料儲存在同一臺機器上，這樣做主要是為了避免網路資料傳輸的開銷。如果你的查詢條件沒有完全覆蓋索引列，本地索引還是可以生效。因為無法提前確定資料在哪個Region上，所以在讀資料的時候，還需要檢查每個Region上的資料而帶來一些效能損耗。

1.先刪除之前建立的函式索引INDEX2_HBASE_TEST。

可以發現這2個查詢語句返回時間都在毫秒級，而如果不建立索引，查詢時間為35S以上。

7.總結

Phoenix的二級索引主要有兩種，即全域性索引和本地索引。全域性索引適合那些讀多寫少的場景。如果使用全域性索引，讀資料基本不損耗效能，所有的效能損耗都來源於寫資料。本地索引適合那些寫多讀少，或者儲存空間有限的場景。

索引定義完之後，一般來說，Phoenix會判定使用哪個索引更加有效。但是，全域性索引必須是查詢語句中所有列都包含在全域性索引中，它才會生效。舉個例子，下面是建立索引的語句：

上例就不會用到索引my_index。因為s2並沒有包含在索引中。所以使用全域性索引，必須要所有的列都包含在索引中。那麼怎樣才能使用索引呢？有三種方法。

1.建立索引時使用覆蓋索引

這種索引會把s2加到索引表裡面，同時s2也會隨著原資料表中的變化而變化。這種方式很明顯的缺點是索引表的大小較大，然後就是全域性索引不適合寫特別多的情況。

這個查詢效果具體可以參考第三章

2.使用類似於Oracle的Hint，強制索引。

如果不帶hint，查詢時間為35s，帶了hint強制使用索引後查詢時間為0.099秒。

查詢引擎會使用index1_hbase_test這個索引，由於它會發現索引表中沒有s5資料，所以每一行它都會去原資料表中獲取s5的值。這個強制索引只有在你認為索引有比較好的選擇性的時候才是好的選擇，也就是說s6等於13505503576的行數不多。不然的話，使用Phoenix預設的全表掃描的效能也許會更好。

3.建立本地索引