1. HBase Connector介紹
數據虛擬化引擎openLooKeng中的HBase Connector支持訪問Apache HBase集羣並進行查詢和建立表的操做。用戶能夠在openLooKeng中建立表，並映射到HBase Cluster中已有的表，支持INSERT、SELECT和DELETE操做。html
—— 一個簡單的全表掃描的sql的執行，會經歷哪些階段：sql
首先該sql將要訪問的數據，必定是屬於某一個數據源的，那麼一個通用的Connector須要作哪些事情。Sql的解析是由openLooKeng自己完成的；接下來是生成執行計劃，在這個階段須要驗證用戶所訪問的表的合法性，那麼Connector則須要提供該功能（即元數據管理）；而後就到了任務調度階段，openLooKeng會將一個大任務劃分爲多個小任務，由多個worker分工完成，那麼Connector會提供split分割的接口，即SplitManager；Worker在收到任務以後，以分片爲最小單元進行數據加載，此時須要用到Connector中的PageSource/PageSink來完成數據的讀寫操做。因此在HBase Connector中咱們實現了這些關鍵模塊（SplitManager，HBaseClient，HetuMetastore）。性能優化
HBase Cluster的主要組件：ZooKeeper用來記錄一些元數據信息，Master用來處理用戶發過來的請求，RegionServer用來執行用戶請求並管理Region的分裂和合並。 
——HBase Connector數據流：微信
- 建表（HBase Connector支持兩種模式的建表）。 ① 直接關聯遠端HBase數據源上的表（即外表的形式） ② 在openLooKeng上建立一張HBase數據源不存在的新表
- 用戶發送一條查詢HBase數據的sql請求給Coordinator
- Coordinator收到請求後，從hetuMetastore中獲取table信息，以驗證用戶sql所訪問表和數據列的合法性
- Coordinator經過SplitManager獲取全部的分片信息，並生成執行計劃和任務，將任務下發到各個Worker上
- 每一個Worker會處理一部分的數據。Worker經過HBase Client來實現對HBase Cluster的數據讀寫交互
——使用openLooKeng訪問HBase集羣併發
配置說明：使用openLooKeng來訪問HBase集羣，咱們須要配置HBase的相關信息在Catalog中，主要是ZooKeeper的信息。建立並編輯etc/catalog/hbase.properties： 具體操做可參考：https://openlookeng.io/zh-cn/docs/docs/connector/hbase.html HBase Connector所支持的語法： HBase Connector基本上支持全部的SQL語句，包括建立、查詢、刪除模式，添加、刪除、修改表，插入數據，刪除行等。如下是一些示例： 算子下推支持：HBase鏈接器支持下推大部分運算符，如基於RowKey的點查詢、基於RowKey的範圍查詢等。此外，還支持這些謂詞條件以進行下推：=、>=、>、<、<=、!=、in、not in、between and。ide
2.HBase Connector性能分析
openLooKeng1.1.0版本並未對HBase Connector作過全方面的性能優化。 咱們先了解一下HBase讀取數據的機制。實際上，HBase Client首先會從ZooKeeper中獲取HBase表元數據所在的RegionServer，而後根據RowKey，找到數據所在的RegionServer，而後發送讀數據請求給RegionServer。 每一個RegionServer由多個Region構成，Region是存儲數據的最小單元。每一個Region裏面會維護必定範圍的key值。高併發
那麼先介紹一下咱們以前切片的作法：HBase Client調用API獲取數據所在的region信息。每一個region的start key和end key組成一個split。Split的個數即數據所分佈在的region的個數。性能
這種狀況下，咱們沒有利用到讀取Region的併發能力。咱們知道，分片數決定了任務的併發度，影響性能。因此從這個角度出發，須要提升數據讀取的併發度。那麼在openLooKeng 1.2.0版本中，咱們引入了一種新的數據切片方式以及支持訪問快照的模式。測試
3.HBase Connector性能優化
——優化點1（新的分片規則）優化
- 建表時指定分片切割規則，提高單表全表掃描性能 create table xxx() with(split_by_char='0~9,a~z,A~Z') split_by_char表示rowKey的第一個字符的範圍，爲分片切割的依據。 若RowKey的第一個字符由數字構成，則能夠根據不一樣的數字進行分片切割，提升查詢併發度。不一樣類型的符號用逗號隔開。若是設置不當，會致使查詢數據結果不完整，請根據RowKey的實際狀況進行配置。無特殊要求時，無需修改。默認狀況已包含全部的數字和字母。若rowKey爲漢字，則create table xxx() with(split_by_char='一~鋸')；另外，建表時會根據split_by_char指定預分區的splitKey，儘可能將數據分散到各個region，那樣在進行HBase讀寫時，對性能會有很好的改善。
- HBase Server支持使用startRow和endRow來獲取Scanner 好比，splitByChar爲0~2，咱們會生成一些鍵值對。鍵值對的個數將會小於一個常量（如20），因此須要首先計算每一個鍵值對的gap大小。 (startKey = 0, endKey = 0|),(startKey = 1, endKey = 1|),(startKey = 2, endKey = 2|) splitByChar爲0~9, a~z (startKey = 0, endKey = 1|),(startKey = 2, endKey = 3|)……(startKey = y, endKey = z|)
——優化點2（支持訪問快照模式）
- 可配置ClientSide模式來讀取數據,提高多併發查詢性能 ClientSide的工做機制是在HDFS上建立HBase表的Snapshot，記錄各個數據文件所在的Region地址，在讀取數據時，不須要通過HBase Region Server，而是直接訪問Region，這樣能夠在高併發降低低Region Server的壓力。 ——性能測試 HBase 3節點，openLooKeng 3節點，e_mp_day_read_52：10138492行，64列
HBase Shell對於操做千萬行的表作count操做時，性能會不好；HBase也有提供計算行數的jar包，這裏沒有進行測試。由於openLooKeng 1.2.0優化了count操做，只會去加載第一列，因此sql1的狀況下，Normal Scan和ClientSide方式性能差別不大。Sql2會獲取多列數據，當HBase Server成爲瓶頸時，ClientSide的優點就凸顯出來了。
固然，HBase的應用場景並不是是全表掃描，而應該是根據RowKey進行點查詢的場景。該場景下，openLooKeng HBase Connector會直接根據RowKey調用對應的API，高效獲取數據便可。openLooKeng 1.2.0在具有訪問HBase基本功能的前提下，優化了對於全表掃描的場景下的性能，openLooKeng 1.2.0 HBase Connector的全表掃描相比1.1.0版本，性能提高多倍。
若是您還想了解更多，歡迎關注 4月29日晚8:00 B站直播活動，與老師們互動探討相關的技術問題。
本文做者 | 塗盛霞
受權轉載 | 請聯繫openLooKeng小助手 （微信號：openLooKengoss）