轉載自： http://www.thebigdata.cn/HBase/35831.html
一些常見的HBase新手問題
-
什麼樣的數據適合用HBase來存儲？
-
既然HBase也是一個數據庫，能否用它將現有系統中昂貴的Oracle替換掉？
-
存放於HBase中的數據記錄，爲何不直接存放於HDFS之上？
-
能否直接使用HBase來存儲文件數據？
-
Region(HBase中的數據分片)遷移後，數據是否也會被遷移？
-
爲何基於Spark/Hive分析HBase數據時性能較差？
開篇
用慣了Oracle/MySQL的同學們，心目中的 數據表 ，應該是長成這樣的：
這種表結構規整，每一行都有固定的列構成，因此，非常適合結構化數據的存儲。但在NoSQL領域，數據表的模樣卻往往換成了另外一種"畫風"：
行由看似"雜亂無章"的列組成，行與行之間也無須遵循一致的定義，而這種定義恰好符合半結構化數據或非結構化數據的特點。本文所要講述的HBase，就屬於該派系的一個典型代表。這些"雜亂無章"的列所構成的多行數據，被稱之爲一個" 稀疏矩陣 "，而上圖中的每一個"黑塊塊"，在HBase中稱之爲一個KeyValue。
Apache HBase官方給出了這樣的定義：
Apache HBase™ is the hadoop database, a distributed , scalable , big data store .
即：Apache HBase是基於Hadoop構建的一個 分佈式 的、 可伸縮 的 海量數據存儲系統 。
HBase常被用來存放一些 海量的 (通常在TB級別以上) 結構比較簡單 的數據，如歷史訂單記錄，日誌數據，監控Metris數據等等，HBase提供了 簡單的基於Key值的快速查詢能力 。
HBase在國內市場已經取得了非常廣泛的應用，在搜索引擎中，也可以看出來，HBase在國內呈現出了逐年上升的勢態：
從Apache HBase所關聯的github項目的commits統計信息來看，也可以看出來該項目非常活躍：
( 需要說明的一點 ：HBase中的每一次commit，都已經過社區Commiter成員嚴格的Review，在commit之前，一個Patch可能已經被修改了幾十個版本)
令人欣喜的是，國內的開發者也積極參與到了HBase社區貢獻中，而且被社區接納了 多名PMC以及Committer成員 。
本文將以 一條數據在HBase中的“旅程” 爲線索，介紹HBase的核心概念與流程，幾乎每一部分都可以展開成一篇獨立的長文，但本文旨在讓讀者能夠快速的瞭解HBase的架構輪廓，所以很多特性/流程被被一言帶過，但這些特性在社區中往往經歷了漫長的開發過程。至於講什麼以及講到什麼程度，本文都做了艱難的取捨，在講解的過程中，將會穿插解答本文開始所提出的針對初學者的一些常見問題。
本文適用於HBase新手，而對於具備一定經驗的HBase開發人員，相信本文也可以提供一些有價值的參考。本文內容基於HBase 2.0 beta 2版本，對比於1.0甚至是更早期的版本，2.0出現了大量變化，下面這些問題的答案將揭示部分關鍵的變化（新手可以直接跳過這些問題）：
-
HBase meta Region在哪裏提供服務？
-
HBase是否可以保證 單行操作的原子性 ？
-
Region中寫WAL與寫MemStore的順序是怎樣的？
-
你是否遇到過Region長時間處於 RIT 的狀態？ 你認爲舊版本中Assignment Manager的主要問題是什麼？
-
在面對 Full GC 問題時，你嘗試做過哪些優化？
-
你是否深究過HBase Compaction帶來的“ 寫放大 ”有多嚴重？
-
HBase的RPC框架存在什麼問題？
-
導致 查詢時延毛刺 的原因有哪些？
本系列文章的 整體行文思路 如下：
-
介紹HBase數據模型
-
基於數據模型介紹HBase的適用場景
-
快速介紹集羣關鍵角色以及集羣部署建議
-
示例數據介紹
-
寫數據流程
-
讀數據流程
-
數據更新
-
負載均衡機制
-
HBase如何存儲小文件數據
這些內容將會被拆成幾篇文章。至於集羣服務故障的處理機制，集羣工具，周邊生態，性能調優以及最佳實踐等進階內容，暫不放在本系列文章範疇內。
約定
1. 本文範圍內針對一些關鍵特性/流程，使用了加粗以及加下劃線的方式做了強調，如" ProcedureV2 "。這些特性往往在本文中僅僅被粗淺提及，後續計劃以獨立的文章來介紹這些特性/流程。
2. 術語縮寫：對於一些進程/角色名稱，在本文範圍內可能通過縮寫形式來表述：
數據模型
RowKey
用來表示唯一一行記錄的 主鍵 ，HBase的數據是按照RowKey的 字典順序 進行全局排序的，所有的查詢都只能依賴於這一個排序維度。
通過下面一個例子來說明一下" 字典排序 "的原理：
RowKey列表{"abc", "a", "bdf", "cdf", "def"}按字典排序後的結果爲{"a", "abc", "bdf", "cdf", "defg"}
也就是說，當兩個RowKey進行排序時，先對比兩個RowKey的第一個字節，如果相同，則對比第二個字節，依次類推...如果在對比到第M個字節時，已經超出了其中一個RowKey的字節長度，那麼，短的RowKey要被排在另外一個RowKey的前面。
稀疏矩陣
參考了Bigtable，HBase中一個表的數據是按照稀疏矩陣的方式組織的，"開篇"部分給出了一張關於HBase數據表的 抽象圖 ，我們再結合下表來加深大家關於"稀疏矩陣"的印象：
看的出來： 每一行中，列的組成都是靈活的，行與行之間並不需要遵循相同的列定義 ， 也就是HBase數據表" schema-less "的特點。
Region
區別於Cassandra/DynamoDB的"Hash分區"設計，HBase中採用了"Range分區"，將Key的完整區間切割成一個個的"Key Range" ，每一個"Key Range"稱之爲一個Region。
也可以這麼理解：將HBase中擁有數億行的一個大表， 橫向切割 成一個個" 子表 "，這一個個" 子表 "就是 Region ：
Region是HBase中負載均衡的基本單元 ，當一個Region增長到一定大小以後，會自動分裂成兩個。
Column Family
如果將Region看成是一個表的 橫向切割 ，那麼，一個Region中的數據列的 縱向切割 ，稱之爲一個 Column Family 。每一個列，都必須歸屬於一個Column Family，這個歸屬關係是在寫數據時指定的，而不是建表時預先定義。
KeyValue
KeyValue的設計不是源自Bigtable，而是要追溯至論文"The log-structured merge-tree( LSM-Tree )"。每一行中的每一列數據，都被包裝成獨立的擁有 特定結構 的KeyValue，KeyValue中包含了豐富的自我描述信息:
看的出來，KeyValue是支撐"稀疏矩陣"設計的一個關鍵點：一些Key相同的任意數量的獨立KeyValue就可以構成一行數據。但這種設計帶來的一個顯而易見的缺點： 每一個KeyValue所攜帶的自我描述信息，會帶來顯著的數據膨脹 。
適用場景
在介紹完了HBase的數據模型以後，我們可以回答本文一開始的前兩個問題：
-
什麼樣的數據適合用HBase來存儲？
-
既然HBase也是一個數據庫，能否用它將現有系統中昂貴的Oracle替換掉？
HBase的數據模型比較簡單，數據按照RowKey排序存放，適合HBase存儲的數據，可以簡單總結如下：
-
以 實體 爲中心的數據
實體可以包括但不限於如下幾種：
描述這些實體的，可以有基礎屬性信息、實體關係(圖數據)、所發生的事件(如交易記錄、車輛軌跡點)等等。
-
自然人／賬戶／手機號／車輛相關數據
-
用戶畫像數據（含標籤類數據）
-
圖數據（關係類數據）
-
-
以 事件 爲中心的數據
-
監控數據
-
時序數據
-
實時位置類數據
-
消息/日誌類數據
-
上面所描述的這些數據，有的是 結構化數據 ，有的是 半結構化 或 非結構化數據 。HBase的“ 稀疏矩陣 ”設計，使其應對非結構化數據存儲時能夠得心應手，但在我們的實際用戶場景中， 結構化數據存儲依然佔據了比較重的比例 。由於HBase僅提供了基於RowKey的單維度索引能力，在應對一些具體的場景時，依然還需要基於HBase之上構建一些專業的能力，如：
-
OpenTSDB時序數據存儲，提供基於Metrics+時間+標籤的一些組合維度查詢與聚合能力
-
GeoMesa時空數據存儲，提供基於時間+空間範圍的索引能力
-
JanusGraph圖數據存儲，提供基於屬性、關係的圖索引能力
HBase擅長於存儲結構簡單的海量數據但索引能力有限，而Oracle等傳統關係型數據庫(RDBMS)能夠提供豐富的查詢能力，但卻疲於應對TB級別的海量數據存儲， HBase對傳統的RDBMS並不是取代關係，而是一種補充 。
HBase與HDFS
我們都知道HBase的數據是存儲於HDFS裏面的，相信大家也都有這麼的認知：
HBase是一個 分佈式數據庫 ，HDFS是一個 分佈式文件系統
理解了這一點，我們先來粗略回答本文已開始提出的其中兩個問題：
-
HBase中的數據爲何不直接存放於HDFS之上？
HBase中存儲的海量數據記錄，通常在幾百Bytes到KB級別，如果將這些數據直接存儲於HDFS之上，會導致大量的小文件產生，爲HDFS的元數據管理節點(NameNode)帶來沉重的壓力。
-
文件能否直接存儲於HBase裏面？
如果是幾MB的文件，其實也可以直接存儲於HBase裏面，我們暫且將這類文件稱之爲小文件，HBase提供了一個名爲MOB的特性來應對這類小文件的存儲。但如果是更大的文件，強烈不建議用HBase來存儲，關於這裏更多的原因，希望你在詳細讀完本系列文章所有內容之後能夠自己解答。
集羣角色
關於集羣環境，你可以使用國內外大數據廠商的平臺，如Cloudera，Hontonworks以及國內的華爲，都發行了自己的企業版大數據平臺，另外，華爲雲、阿里雲中也均推出了全託管式的HBase服務。
我們假設集羣環境已經Ready了，先來看一下集羣中的 關鍵角色 ：
相信大部分人對這些角色都已經有了一定程度的瞭解，我們快速的介紹一下各個角色在集羣中的 主要 職責：
-
ZooKeeper
在一個擁有多個節點的分佈式系統中，假設，只能有一個節點是主節點，如何快速的選舉出一個主節點而且讓所有的節點都認可這個主節點？這就是HBase集羣中存在的一個最基礎命題。
利用ZooKeeper就可以非常簡單的實現這類"仲裁"需求，ZooKeeper還提供了基礎的事件通知機制，所有的數據都以 ZNode的形式存在，它也稱得上是一個"微型數據庫"。
-
NameNode
HDFS作爲一個分佈式文件系統，自然需要文件目錄樹的 元數據 信息，另外，在HDFS中每一個文件都是按照Block存儲的，文件與Block的關聯也通過 元數據 信息來描述。NameNode提供了這些 元數據信息的存儲 。
-
DataNode
HDFS的數據存放節點。
-
RegionServer
HBase的 數據服務節點 。
-
Master
HBase的管理節點，通常在一個集羣中設置一個主Master，一個備Master，主備角色的"仲裁"由ZooKeeper實現。 Master 主要職責 ：
① 負責管理所有的RegionServer。
②建表/修改表/刪除表等DDL操作請求的服務端執行主體。
③管理所有的數據分片(Region)到RegionServer的分配。
④如果一個RegionServer宕機或進程故障，由Master負責將它原來所負責的Regions轉移到其它的RegionServer上繼續提供服務。
⑤Master自身也可以作爲一個RegionServer提供服務，該能力是可配置的。
集羣部署建議
如果基於物理機/虛擬機部署，通常建議：
1. RegionServer與DataNode聯合部署，RegionServer與DataNode按1:1比例設置。
這種部署的優勢在於，RegionServer中的數據文件可以存儲一個副本於本機的DataNode節點中，從而在讀取時可以利用HDFS中的" 短路徑讀取(Short Circuit) "來繞過網絡請求，降低讀取時延。
2. 管理節點獨立於數據節點部署
如果是基於物理機部署，每一臺物理機節點上可以設置幾個RegionServers/DataNodes來提升資源使用率。
也可以選擇基於容器來部署，如在HBaseCon Asia 2017大會知乎的演講主題中，就提到了知乎基於Kubernetes部署HBase服務的實踐。
對於公有云HBase服務而言，爲了降低總體擁有成本( TCO )，通常選擇" 計算與存儲物理分離"的方式，從架構上來說，可能導致平均時延略有下降，但可以藉助於共享存儲底層的IO優化來做一些"彌補"。
HBase集羣中的RegionServers可以按邏輯劃分爲多個Groups，一個表可以與一個指定的Group綁定，可以將RegionServer Group理解成將一個大的集羣劃分成了多個邏輯子集羣，藉此可以實現多租戶間的隔離，這就是HBase中的 RegionServer Group 特性。
示例數據
以我們日常生活都熟悉的手機通話記錄的存儲爲例，先簡單給出示例數據的字段定義：
如上定義與電信領域的通話記錄字段定義相去甚遠，本文力求簡潔，僅給出了最簡單的示例。如下是"虛構"的樣例數據：
在本文大部分內容中所涉及的一條數據，是上面加粗的最後一行" MSISDN1 "爲" 13400006666"這行記錄。
在本系列文章的流程圖中，我們將會使用一個 紅色的五角星 來表示該數據所在的位置。
寫數據之前：創建連接
Login
在啓用了安全特性的前提下，Login階段是爲了完成 用戶認證 (確定用戶的合法身份)，這是後續一切 安全訪問控制 的基礎。
當前Hadoop/HBase僅支持基於Kerberos的用戶認證，ZooKeeper除了Kerberos認證，還能支持簡單的用戶名/密碼認證，但都基於靜態的配置，無法動態新增用戶。如果要支持其它第三方認證，需要對現有的安全框架做出比較大的改動。
創建Connection
Connection可以理解爲一個HBase集羣連接的抽象，建議使用ConnectionFactory提供的工具方法來創建。因爲HBase當前提供了兩種連接模式：同步連接，異步連接，這兩種連接模式下所創建的Connection也是不同的。我們給出Conn ectionFactory中關於獲取這兩種連接的典型方法定義：
Connection中主要維護着 兩類共享的資源 ：
-
線程池
-
Socket連接
這些資源都是在真正使用的時候纔會被創建，因此，此時的連接還只是一個"虛擬連接"。
寫數據之前：創建數據表
DDL操作的抽象接口 - Admin
Admin定義了常規的DDL接口，列舉幾個典型的接口：
預設合理的數據分片 - Region
分片數量會給讀寫吞吐量帶來直接的影響，因此，建表時通常建議由用戶主動指定劃分 Region分割點 ，來設定Region的數量。
HBase中數據是按照RowKey的字典順序排列的，爲了能夠劃分出合理的Region分割點，需要依據如下幾點信息：
-
Key的組成結構
-
Key的數據分佈預估
如果不能基於Key的組成結構來預估數據分佈的話，可能會導致數據在Region間的分佈不均勻
-
讀寫併發度需求
依據讀寫併發度需求，設置合理的Region數量
爲表定義合理的Schema
既然HBase號稱"schema-less"的數據存儲系統，那何來的是"schema "？的確，在數據庫範式的支持上，HBase非常弱，這裏的"schema"，主要指如下一些信息的設置：
1. NameSpace 設置
2. Column Family的數量
3. 每一個Column Family中所關聯的一些 關鍵配置 ：
① Compression
HBase當前可以支持Snappy，GZ，LZO，LZ4，Bzip2以及ZSTD壓縮算法
② DataBlock Encoding
HBase針對自身的特殊數據模型所做的一種壓縮編碼
③ BloomFilter
可用來協助快速判斷一條記錄是否存在
④ TTL
指定數據的過期時間
⑤ StoragePolicy
指定Column Family的存儲策略，可選項有： "ALL_SSD"，"ONE_SSD"，"HOT"，"WARM"，"COLD"，"LAZY_PERSIST"
HBase中並不需要預先設置Column定義信息，這就是HBase schema less設計的核心。
Client發送建表請求到Master
建表的請求是通過RPC的方式由Client發送到Master:
-
RPC接口基於 Protocol Buffer 定義
-
建表相關的描述參數，也由 Protocol Buffer 進行定義及序列化
Client端側調用了Master服務的什麼接口，參數是什麼，這些信息都被通過RPC通信傳輸到Master側，Master再依據這些接口\參數描述信息決定要執行的操作。2.0版本中，HBase目前已經支持基於Netty的 異步RPC框架 。
關於HBase RPC框架
早期的HBase RPC框架，完全借鑑了Hadoop中的實現，那時，Netty項目尚不盛行。
Master側接收到Client側的建表請求以後，一些主要操作包括：
1. 生成每一個Region的描述信息對象HRegionInfo，這些描述信息包括：Region ID, Region名稱，Key範圍，表名稱等信息。
2. 生成每一個Region在HDFS中的文件目錄。
3. 將HRegionInfo信息寫入到記錄元數據的hbase:meta表中。
說明
meta表位於名爲"hbase"的namespace中，因此，它的全稱爲"hbase:meta"。 但在本系列文章範疇內，常將其縮寫爲"meta"。
整個過程中，新表的狀態也是記錄在hbase:meta表中的，而不用再存儲在ZooKeeper中。
如果建表執行了一半，Master進程故障，如何處理？這裏是由HBase自身提供的一個名爲 Procedure(V2) 的框架來保障操作的事務性的，備Master接管服務以後，將會繼續完成整個建表操作。
一個被創建成功的表，還可以被執行如下操作：
-
Disable 將所有的Region下線，該表暫停讀寫服務
-
Enable 將一個Disable過的表重新Enable，也就是上線所有的Region來正常提供讀寫服務
-
Alter 更改表或列族的描述信息
Master分配Regions
新創建的所有的Regions，通過 AssignmentManager 將這些Region按照輪詢(Round-Robin)的方式分配到每一個RegionServer中，具體的分配計劃是由 LoadBalancer 來提供的。
AssignmentManager負責所有Regions的分配/遷移操作，Master中有一個定時運行的線程，來檢查集羣中的Regions在各個RegionServer之間的負載是否是均衡的，如果不均衡，則通過LoadBalancer生成相應的Region遷移計劃，HBase中支持多種負載均衡算法，有最簡單的僅考慮各RegionServer上的 Regions數目 的負載均衡算法，有基於 遷移代價 的負載均衡算法，也有 數據本地化率優先 的負載均衡算法，因爲這一部分已經提供了插件化機制，用戶也可以自定義負載均衡算法。
總結
本文主要介紹瞭如下內容：
1. HBase項目概述，呈現了HBase社區的活躍度以及搜索引擎熱度等信息
2. HBase數據模型部分，講到了RowKey，稀疏矩陣，Region，Column Family，KeyValue等概念
3. 基於HBase的數據模型，介紹了HBase的適合場景（以 實體 / 事件 爲中心的簡單結構的數據）
4. 介紹了HBase與HDFS的關係
5. 介紹了集羣的關鍵角色：ZooKeeper, Master, RegionServer，NameNode, DataNode
6. 集羣部署建議
7. 給出了一些示例數據
8. 寫數據之前的準備工作：建立集羣連接，建表（建表時應該定義合理的Schema以及設置合理的Region數量），建表由Master處理，新創建的Regions由Region AssignmentManager負責分配到各個RegionServer。
下一篇文章將正式開始介紹 寫數據 的流程。