本期與大家分享的是，小北精心整理的Hbase學習筆記，希望對大家能有幫助，喜歡就給點鼓勵吧，記得三連哦！歡迎各位大佬評論區指教討論！

💜🧡💛制作不易，各位大佬們給點鼓勵！
🧡💛💚點贊👍 ? 收藏? ? 關注?
💛💚💙歡迎各位大佬指教，一鍵三連走起！

🧡HBase總結圖解
🧡一、HBase基礎部分
💜1、HBase簡介
💜2、Hbase的系統架構
💜3、HBase的資料模型
💜4、HBase的特點
💜5、HBase的RowKey
💜6、HBase的列簇和列
💜7、HBase的時間戳
💜8、HBase的Cell單元格
💜9、HBase的HLog(WAL log)
💜10、HBase的 Region分裂策略
💜11、HBase的Compaction操作
💜12、HBase的讀寫流程
🧡二、HBase Shell
🧡三、HBase 的過濾器
💜1、過濾器
💜2、過濾器的作用
💜3、比較過濾器
💚比較運算子
💚常見的六大比較過濾器
💜4、專用過濾器
💜5、Bloom Filter 布隆過濾器
💚Bloom Filter 作業原理
💚Bloom Filter 在HBase中的應用
🧡四、HBase的高可用
🧡五、HBase框架及讀寫流程
🧡六、MapReduce讀寫HBase
🧡七、HBase調優
💜1、Pre-Creating Regions（預磁區）
💜2、預磁區實作步驟
💜3、HBase的Rowkey設計
💚rowkey長度原則
💚rowkey散列原則
💚rowkey唯一原則
💚熱點問題，及解決方法
💚其它的一些調優建議
💜4、HBase In Memory
💜5、HBase Max Version
💜6、HBase Compact & Split
💜7、HBase BulkLoading
🧡八、HBase Phoenix

HBase總結圖解

點我回傳目錄

一、HBase基礎部分

點我回傳目錄

在學習HBase之前我們要先了解下Hadoop的生態系統，認識HBase在Hadoop生態系統中的職責：

1、HBase簡介

點我回傳目錄

• HBase – 是Hadoop Database，是一個高可靠性、高性能、面向列、可伸縮、實時讀寫的分布式資料庫

• HBase利用Hadoop HDFS作為其檔案存盤系統，利用Hadoop MapReduce來處理HBase中的海量資料，利用Zookeeper作為其分布式協同服務

• HBase主要用來存盤非結構化和半結構化的松散資料（列式存盤 NoSQL 資料庫）

2、Hbase的系統架構

點我回傳目錄

HMaster的職責：

1. 為Region server分配region
2. 負責Region server的負載均衡
3. 發現失效的Region server并重新分配其上的region
4. 管理用戶對table的增刪改操作

HRegionServer的職責：

1. Region server維護region，處理對這些region的IO請求
2. Region server負責切分在運行程序中變得過大的region

Region的功能：

HBase會自動地把表水平劃分成多個區域(Region)，每個Region會保存一個表里面某段連續的資料；每個表一開始只有一個Region，隨著資料的不斷插入表中，Region會不斷地增大，當增大到一個閥值的時候，Region就會等分為兩個新的Region（裂變），這樣，當table中的行不斷增多，就會有越來越多的Region，這樣一張完整的表被保存在多個Regionserver 上，

Memstore 與 storefile的功能：

一個Region由多個store組成，而一個store對應一個CF（列族）store包括位于記憶體中的memstore和位于磁盤的storefile，寫操作會先寫入memstore，當memstore中的資料達到某個閾值，HRegionServer會啟動flashcache行程寫入storefile，每次寫入形成單獨的一個storefile，當storefile檔案的數量增長到一定閾值后，系統會進行合并（minor、major compaction），在合并程序中會進行版本合并和洗掉作業（majar），形成更大的storefile，當一個region所有storefile的大小和數量超過一定閾值后，會把當前的region分割為兩個，并由HMaster分配到相應的regionserver服務器，以實作負載均衡，而客戶端檢索資料，會先在memstore找，若找不到會再去找storefile，

3、HBase的資料模型

點我回傳目錄

HRegion是HBase中分布式存盤和負載均衡的最小單元， 而，最小單元就表示不同的HRegion可以分布在不同的 HRegion server上， HRegion由一個或者多個Store組成，每個store保存一個columns family，每個Strore又由一個memStore和0至多個StoreFile組成，如：StoreFile以HFile格式保存在HDFS上，

4、HBase的特點

點我回傳目錄

1. 存盤的資料量大：一個表可以有上億行，上百萬列，
2. 面向列：面向串列（簇）的存盤和權限控制，列（簇）獨立檢索，
3. 稀疏：對于為空（NULL）的列，并不占用存盤空間，因此，表可以設計的非常稀疏，
4. 無模式：每一行都有一個可以排序的主鍵和任意多的列，列可以根據需要動態地增加，同一張表中不同的行可以有截然不同的列，
5. 資料多版本：每個單元中的資料可以有多個版本，默認情況下，版本號自動分配， 版本號就是單元格插入時的時間戳，
6. 資料型別單一：HBase中的資料都是位元組陣列，沒有型別，

5、HBase的RowKey

點我回傳目錄

• 唯一標識一行資料
• 可以通過RowKey獲取一行資料
• 按照字典順序排序的，
• Rowkey只能存盤64k的位元組資料 10-100byte

6、HBase的列簇和列

點我回傳目錄

• 列簇是屬于表的Schema的一部分，在建表的時候必須指定至少一個Columns Family（列簇）
• HBase中的列歸屬于某一個列簇
• HBase在儲存、權限控制、版本控制都是在列簇層面上進行
• 一個列簇對應一個store
• 列名以列族作為前綴，每個“列族”都可以有多個列成員(column)；如course:a, course:b, 新的列族成員（列）可以隨后按需、動態加入，
• HBase把同一列族里面的資料存盤在同一目錄下，由幾個檔案保存，

7、HBase的時間戳

點我回傳目錄

• HBase的時間戳就是一直提到的版本的概念，每條資料插入的時候都會記錄插入時間（時間戳，64位整型），時間戳可以由HBase(在資料寫入時自動)賦值，此時時間戳是精確到毫秒的當前系統時間，時間戳也可以由客戶顯式賦值，如果應用程式要避免資料版本沖突，就必須自己生成具有唯一性的時間戳，
• 如果有多個版本，會按照時間戳的倒序（時間戳越大，表示資料越新）儲存資料，在獲取的時候，如果不指定版本，那么會默認最新一條的資料
• 如果設定了TTL（Time to Live），那么HBase將會根據TTL以及資料的時間戳去洗掉過期的資料

8、HBase的Cell單元格

點我回傳目錄

• Cell 是由 {row key，column(=< family> + < label>)，version} 唯一確定的 單元，
• Cell 中的資料是沒有型別的，全部是位元組碼形式存盤，單元格的內容是未決議的位元組陣列，
• Cell 由行和列的坐標交叉決定，
• 單元格是有版本的，

9、HBase的HLog(WAL log)

點我回傳目錄

• HLog檔案就是一個普通的Hadoop Sequence File，Sequence File 的Key是HLogKey物件，HLogKey中記錄了寫入資料的歸屬資訊，除了table和region名字外，同時還包括 sequence number和timestamp，timestamp是”寫入時間”，sequence number的起始值為0，或者是最近一次存入檔案系統中sequence number，
• HLog SequeceFile的Value是HBase的KeyValue物件，即對應HFile中的KeyValue，

10、HBase的 Region分裂策略

點我回傳目錄

region中存盤的是一張表的資料，當region中的資料條數過多的時候，會直接影響查詢效率，當region過大的時候，region會被拆分為兩個region，HMaster會將分裂的region分配到不同的regionserver上，這樣可以讓請求分散到不同的RegionServer上，以達到負載均衡 , 這也是Hbase的一個優點 ，

• ConstantSizeRegionSplitPolicy策略

  0.94版本前，HBase region的默認切分策略

  當region中最大的store大小超過某個閾值(hbase.hregion.max.filesize=10G)之后就會觸發切分，一個region等分為2個region，

  但是在生產線上這種切分策略卻有相當大的弊端（切分策略對于大表和小表沒有明顯的區分）：

  • 閾值(hbase.hregion.max.filesize)設定較大對大表比較友好，但是小表就有可能不會觸發分裂，極端情況下可能就1個，形成熱點，這對業務來說并不是什么好事，
  • 如果設定較小則對小表友好，但一個大表就會在整個集群產生大量的region，這對于集群的管理、資源使用、failover來說都不是一件好事，

• IncreasingToUpperBoundRegionSplitPolicy策略

  0.94版本~2.0版本默認切分策略

  ? 總體看和ConstantSizeRegionSplitPolicy思路相同，一個region中最大的store大小大于設定閾值就會觸發切分，
  但是這個閾值并不像ConstantSizeRegionSplitPolicy是一個固定的值，而是會在一定條件下不斷調整，調整規則和region所屬表在當前regionserver上的region個數有關系.

  region split閾值的計算公式是：

  • 設regioncount：是region所屬表在當前regionserver上的region的個數

  • 閾值 = regioncount^3 * 128M * 2，當然閾值并不會無限增長，最大不超過MaxRegionFileSize（10G),當region中最大的store的大小達到該閾值的時候進行region split

  例如：

  • 第一次split閾值 = 1^3 * 256 = 256MB
  • 第二次split閾值 = 2^3 * 256 = 2048MB
  • 第三次split閾值 = 3^3 * 256 = 6912MB
  • 第四次split閾值 = 4^3 * 256 = 16384MB > 10GB，因此取較小的值10GB
  • 后面每次split的size都是10GB了

  特點

  • 相比ConstantSizeRegionSplitPolicy，可以自適應大表、小表；
  • 在集群規模比較大的情況下，對大表的表現比較優秀
  • 對小表不友好，小表可能產生大量的小region，分散在各regionserver上
  • 小表達不到多次切分條件，導致每個split都很小，所以分散在各個regionServer上

• SteppingSplitPolicy策略

  2.0版本默認切分策略

  ? 相比 IncreasingToUpperBoundRegionSplitPolicy 簡單了一些
  ? region切分的閾值依然和待分裂region所屬表在當前regionserver上的region個數有關系

  • 如果region個數等于1，切分閾值為flush size 128M * 2
  • 否則為MaxRegionFileSize，

  這種切分策略對于大集群中的大表、小表會比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不會再產生大量的小region，而是適可而止，

• KeyPrefixRegionSplitPolicy策略

  根據rowKey的前綴對資料進行磁區，這里是指定rowKey的前多少位作為前綴，比如rowKey都是16位的，指定前5位是前綴，那么前5位相同的rowKey在相同的region中，

• DelimitedKeyPrefixRegionSplitPolicy策略

  保證相同前綴的資料在同一個region中，例如rowKey的格式為：userid_eventtype_eventid，指定的delimiter為 _ ，則split的的時候會確保userid相同的資料在同一個region中，
  按照分隔符進行切分，而KeyPrefixRegionSplitPolicy是按照指定位數切分，

• BusyRegionSplitPolicy策略

  按照一定的策略判斷Region是不是Busy狀態，如果是即進行切分

  如果你的系統常常會出現熱點Region，而你對性能有很高的追求，那么這種策略可能會比較適合你，它會通過拆分熱點Region來緩解熱點Region的壓力，但是根據熱點來拆分Region也會帶來很多不確定性因素，因為你也不知道下一個被拆分的Region是哪個，

• DisabledRegionSplitPolicy策略

  不啟用自動拆分, 需要指定手動拆分

11、HBase的Compaction操作

點我回傳目錄

Minor Compaction：

• 指選取一些小的、相鄰的StoreFile將他們合并成一個更大的StoreFile，在這個程序中不會處理已經Deleted或Expired的Cell，一次 Minor Compaction 的結果是更少并且更大的StoreFile，

Major Compaction：

• 指將所有的StoreFile合并成一個StoreFile，這個程序會清理三類沒有意義的資料：被洗掉的資料、TTL過期資料、版本號超過設定版本號的資料，另外，一般情況下，major compaction時間會持續比較長，整個程序會消耗大量系統資源，對上層業務有比較大的影響，因此線上業務都會將關閉自動觸發major compaction功能，改為手動在業務低峰期觸發，

深入理解 HBase Compaction 機制，好文決議：https://cloud.tencent.com/developer/article/1488439

12、HBase的讀寫流程

點我回傳目錄

二、HBase Shell

點我回傳目錄

語法1：創建表
create <table>, {NAME => <family>, VERSIONS => <VERSIONS>}
# 創建一個User表，并且有一個info列族 
create 'User','info'

語法2：查看所有表
list

語法3：查看表詳情
describe 'User'

語法4：表修改
# 洗掉指定的列族
alter 'User', 'delete' => 'info'
#增加新的列族
alter 'User', NAME => 'info'

語法5：插入資料
put <table>,<rowkey>,<family:column>,<value>
#例如：
put 'User', 'row1', 'info:name', 'xiaoming'
put 'User', 'row2', 'info:age', '18'
put 'User', 'row3', 'info:sex', 'man'

語法6：根據rowKey查詢某個記錄
get <table>,<rowkey>,[<family:column>,....]
#例如：
get 'User', 'row2'

語法7：查詢所有記錄
scan <table>, {COLUMNS => [ <family:column>,.... ], LIMIT => num}
#掃描所有記錄
scan 'User'
#掃描前2條
scan 'User', {LIMIT => 2}
#范圍查詢 STARTROW(開始rowkey) ENDROW(結束rowkey) 
scan 'User', {STARTROW => 'row2'}
scan 'User', {STARTROW => 'row2', ENDROW => 'row2'}
scan 'User', {STARTROW => 'row2', ENDROW => 'row3'}
#另外，還可以添加TIMERANGE和FITLER等高級功能
#STARTROW,ENDROW必須大寫，否則報錯;查詢結果不包含等于ENDROW的結果集


語法8：統計表記錄數
count <table>, {INTERVAL => intervalNum, CACHE => cacheNum}
#INTERVAL設定多少行顯示一次及對應的rowkey，默認1000；
#CACHE每次去取的快取區大小，默認是10，調整該引數可提高查詢速度

語法9：洗掉
#洗掉列
delete 'User', 'row1', 'info:age'
#指定rowkey洗掉
deleteall 'User', 'row2'
#洗掉表中所有資料
truncate 'User'

語法10：表管理
#禁用表
disable 'User'
#啟用表
enable 'User'
#測驗表是否存在
exists 'User'
#洗掉表，洗掉前，必須先disable禁用表
disable 'User'
drop 'User'

三、HBase 的過濾器

1、過濾器

點我回傳目錄

HBase 的基本 API，包括增、刪、改、查等，其中的增、刪都是相對簡單的操作，與傳統的 RDBMS 相比，這里的查詢操作略顯蒼白，只能根據特性的行鍵進行查詢（Get）或者根據行鍵的范圍來查詢（Scan），但是HBase 不僅提供了這些簡單的查詢，同時還提供了更加高級的過濾器（Filter）來查詢，

2、過濾器的作用

點我回傳目錄

• 過濾器的作用是在服務端判斷資料是否滿足條件，然后只將滿足條件的資料回傳給客戶端
• 過濾器的型別很多，但是可以分為兩大類：
  • 比較過濾器：可應用于rowkey、列簇、列、列值過濾器
  • 專用過濾器：只能適用于特定的過濾器

3、比較過濾器

點我回傳目錄

過濾器可以根據列族、列、版本等更多的條件來對資料進行過濾，基于 HBase 本身提供的三維有序（行鍵，列，版本有序），這些過濾器可以高效地完成查詢過濾的任務，帶有過濾器條件的 RPC 查詢請求會把過濾器分發到各個 RegionServer（這是一個服務端過濾器），這樣也可以降低網路傳輸的壓力，而，使用過濾器至少需要兩類引數：一類是抽象的運算子，另一類是比較器

比較運算子

HBase 提供了列舉型別的變數來表示這些抽象的運算子：

LESS  ： 小于
LESS_OR_EQUAL   ： 小于等于
EQUAL  ： 等于
NOT_EQUAL：不等于
GREATER_OR_EQUAL ： 大于等于
GREATER： 大于
NO_OP ; 不比較，排除所有

常見的六大比較過濾器

點我回傳目錄

BinaryComparator

二進制比較器，按位元組索引順序比較指定位元組陣列，采用Bytes.compareTo(byte[])

BinaryPrefixComparator

前綴二進制比較器，與二進制比較器不同的是，只比較前綴是否相同，

NullComparator

判斷給定的是否為空

BitComparator

按位比較

RegexStringComparator

提供一個正則的比較器，僅支持 EQUAL 和非EQUAL

SubstringComparator

判斷提供的子串是否出現在值中，并且不區分大小寫，

列值過濾器：效率較低，需要做全表掃描
SingleColumnValueFilter：用于測驗值的情況（相等，不等，范圍 、、、）

列簇過濾器：
FamilyFilter：用于過濾列族（通常在 Scan 程序中通過設定某些列族來實作該功能，而不是直接使用該過濾器），

列名過濾器：
QualifierFilter：用于列名（Qualifier）過濾，

行鍵過濾器：效率較高，行鍵前綴過濾效率較高
RowFilter：行鍵過濾器，一般來講，執行 Scan 使用 startRow/stopRow 方式比較好，而 RowFilter 過濾器也可以完成對某一行的過濾，

4、專用過濾器

點我回傳目錄

單列值過濾器：SingleColumnValueFilter

SingleColumnValueFilter會回傳滿足條件的cell所在行的所有cell的值（即會回傳一行資料）

列值排除過濾器：SingleColumnValueExcludeFilter

與SingleColumnValueFilter相反，會排除掉指定的列，其他的列全部回傳

rowkey前綴過濾器：PrefixFilter

通過PrefixFilter前綴過濾器查詢以150010008開頭的所有前綴的rowkey

分頁過濾器PageFilter

使用PageFilter分頁效率比較低，每次都需要掃描前面的資料，直到掃描到所需要查的資料

可設計一個合理的rowkey來實作分頁需求

5、Bloom Filter 布隆過濾器

點我回傳目錄

Bloom Filter（布隆過濾器）是1970年由布隆提出的，它實際上是一個很長的二進制向量和一系列隨機映射函式，布隆過濾器可以用于檢索一個元素是否在一個集合中，它的優點是空間效率和查詢時間都遠遠超過一般的演算法，缺點是有一定的誤識別率和洗掉困難，
在計算機科學中，我們常常會碰到時間換空間或者空間換時間的情況，即為了達到某一個方面的最優而犧牲另一個方面，Bloom Filter在時間空間這兩個因素之外又引入了另一個因素：錯誤率，在使用Bloom Filter判斷一個元素是否屬于某個集合時，會有一定的錯誤率，也就是說，有可能把不屬于這個集合的元素誤認為屬于這個集合（False Positive），但不會把屬于這個集合的元素誤認為不屬于這個集合（False Negative），在增加了錯誤率這個因素之后，Bloom Filter通過允許少量的錯誤來節省大量的存盤空間，
它的用法其實是很容易理解的，我們拿個HBase中應用的例子來說下，我們已經知道rowKey存放在HFile中，那么為了從一系列的HFile中查詢某個rowkey，我們就可以通過 Bloom Filter 快速判斷 rowkey 是否在這個HFile中，從而過濾掉大部分的HFile，減少需要掃描的Block，

Bloom Filter 作業原理

點我回傳目錄

BloomFilter對于HBase的隨機讀性能至關重要，對于get操作以及部分scan操作可以剔除掉不會用到的HFile檔案，以減少實際IO次數，提高隨機讀性能，簡單地介紹一下Bloom Filter的作業原理，Bloom Filter使用位陣列來實作過濾，初始狀態下位陣列每一位都為0，如下圖所示：

假如此時有一個集合S = {x1, x2, … xn}，Bloom Filter使用k個獨立的hash函式，分別將集合中的每一個元素映射到｛1,…,m｝的范圍，對于任何一個元素，被映射到的數字作為對應的位陣列的索引，該位會被置為1，比如元素x1被hash函式映射到數字8，那么位陣列的第8位就會被置為1，下圖中集合S只有兩個元素x和y，分別被3個hash函式進行映射，映射到的位置分別為（0，3，6）和（4，7，10），對應的位會被置為1:

現在假如要判斷另一個元素是否是在此集合中，只需要被這3個hash函式進行映射，查看對應的位置是否有0存在，如果有的話，表示此元素肯定不存在于這個集合，否則有可能存在，下圖所示就表示z肯定不在集合｛x，y｝中：
從上面的內容我們可以得知，Bloom Filter有兩個很重要的引數
哈希函式個數
位陣列的大小

Bloom Filter 在HBase中的應用

點我回傳目錄

HFile 中和 Bloom Filter 相關的Block，
Scanned Block Section（掃描HFile時被讀取）：Bloom Block
Load-on-open-section（regionServer啟動時加載到記憶體）：BloomFilter Meta Block、Bloom Index Block
Bloom Block：Bloom資料塊，存盤Bloom的位陣列
Bloom Index Block：Bloom資料塊的索引
BloomFilter Meta Block：從HFile角度看bloom資料塊的一些元資料資訊，大小個數等等，
HBase中每個HFile都有對應的位陣列，KeyValue在寫入HFile時會先經過幾個hash函式的映射，映射后將對應的陣列位改為1，get請求進來之后再進行hash映射，如果在對應陣列位上存在0，說明該get請求查詢的資料不在該HFile中，
HFile中的Bloom Block中存盤的就是上面說的位陣列，當HFile很大時，Data Block 就會很多，同時KeyValue也會很多，需要映射入位陣列的rowKey也會很多，所以為了保證準確率，位陣列就會相應越大，那Bloom Block也會越大，為了解決這個問題就出現了Bloom Index Block，一個HFile中有多個Bloom Block（位陣列），根據rowKey拆分，一部分連續的Key使用一個位陣列，這樣查詢rowKey就要先經過Bloom Index Block（在記憶體中）定位到Bloom Block，再把Bloom Block加載到記憶體，進行過濾，

四、HBase的高可用

點我回傳目錄

五、HBase框架及讀寫流程

點我回傳目錄

六、MapReduce讀寫HBase

點我回傳目錄

七、HBase調優

點我回傳目錄

1、Pre-Creating Regions（預磁區）

點我回傳目錄

• 默認情況下，在創建HBase表的時候會自動創建一個region磁區，當匯入資料的時候， 所有的HBase客戶端都向這一個region寫資料，直到這個region足夠大了才進行切分， 一種可以加快批量寫入速度的方法是通過預先創建一些空的regions，這樣當資料寫入 HBase時，會按照region磁區情況，在集群內做資料的負載均衡，
• 如果知道hbase資料表的key的分布情況，就可以在建表的時候對hbase進行region的預磁區，這樣做的好處是防止大資料量插入的熱點問題，提高資料插入的效率，

2、預磁區實作步驟

點我回傳目錄

首先就是要想明白資料的key是如何分布的，然后規劃一下要分成多少region，每個region的startkey和endkey是多少，然后將規劃的key寫到一個檔案中，比如，key的前幾位字串都是從0001~0010的數字，這樣可以分成10個region，劃分key的檔案如下：注意不要多一行空行

為什么后面會跟著一個"|"，是因為在ASCII碼中，"|"的值是124，大于所有的數字和字母等符號，當然也可以用“~”（ASCII-126），分隔檔案的第一行為第一個region的stopkey，每行依次類推，最后一行不僅是倒數第二個region的stopkey，同時也是最后一個region的startkey，也就是說磁區檔案中填的都是key取值范圍的分隔點，如下圖所示：

3、HBase的Rowkey設計

點我回傳目錄

HBase是三維有序存盤的，通過rowkey（行鍵），column key（column family和qualifier）和TimeStamp（時間戳）這個三個維度可以對HBase中的資料進行快速定位，

HBase中rowkey可以唯一標識一行記錄，在HBase查詢的時候，有三種方式：

1. 通過get方式，指定rowkey獲取唯一一條記錄

2. 通過scan方式，設定startRow和stopRow引數進行范圍匹配

3. 全表掃描，即直接掃描整張表中所有行記錄

rowkey長度原則

點我回傳目錄

rowkey是一個二進制碼流，可以是任意字串，最大長度 64kb ，實際應用中一般為10-100bytes，以 byte[] 形式保存，一般設計成定長，建議越短越好，不要超過16個位元組，原因如下：資料的持久化檔案HFile中是按照KeyValue存盤的，如果rowkey過長，比如超過100位元組，1000w行資料，光rowkey就要占用100*1000w=10億個位元組，將近1G資料，這樣會極大影響HFile的存盤效率；MemStore將快取部分資料到記憶體，如果rowkey欄位過長，記憶體的有效利用率就會降低，系統不能快取更多的資料，這樣會降低檢索效率，

rowkey散列原則

點我回傳目錄

如果rowkey按照時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將rowkey的高位作為散列欄位，由程式隨機生成，低位放時間欄位，這樣將提高資料均衡分布在每個RegionServer，以實作負載均衡的幾率，如果沒有散列欄位，首欄位直接是時間資訊，所有的資料都會集中在一個RegionServer上，這樣在資料檢索的時候負載會集中在個別的RegionServer上，造成熱點問題，會降低查詢效率，

rowkey唯一原則

點我回傳目錄

必須在設計上保證其唯一性，rowkey是按照字典順序排序存盤的，因此，設計rowkey的時候，要充分利用這個排序的特點，將經常讀取的資料存盤到一塊，將最近可能會被訪問的資料放到一塊，

熱點問題，及解決方法

點我回傳目錄

HBase中的行是按照rowkey的字典順序排序的，這種設計優化了scan操作，可以將相關的行以及會被一起讀取的行存取在臨近位置，便于scan，然而糟糕的rowkey設計是熱點的源頭， 熱點發生在大量的client直接訪問集群的一個或極少數個節點（訪問可能是讀，寫或者其他操作），大量訪問會使熱點region所在的單個機器超出自身承受能力，引起性能下降甚至region不可用，這也會影響同一個RegionServer上的其他region，由于主機無法服務其他region的請求， 設計良好的資料訪問模式以使集群被充分，均衡的利用，

為了避免寫熱點，設計rowkey使得不同行在同一個region，但是在更多資料情況下，資料應該被寫入集群的多個region，而不是一個，

下面是一些常見的避免熱點問題的方法以及它們的優缺點：

加鹽

點我回傳目錄

這里所說的加鹽不是密碼學中的加鹽，而是在rowkey的前面增加亂數，具體就是給rowkey分配一個隨機前綴以使得它和之前的rowkey的開頭不同，分配的前綴種類數量應該和你想使用資料分散到不同的region的數量一致，加鹽之后的rowkey就會根據隨機生成的前綴分散到各個region上，以避免熱點，

哈希

點我回傳目錄

哈希會使同一行永遠用一個前綴加鹽，哈希也可以使負載分散到整個集群，但是讀卻是可以預測的，使用確定的哈希可以讓客戶端重構完整的rowkey，可以使用get操作準確獲取某一個行資料

反轉

點我回傳目錄

第三種防止熱點的方法時反轉固定長度或者數字格式的rowkey，這樣可以使得rowkey中經常改變的部分（最沒有意義的部分）放在前面，這樣可以有效的隨機rowkey，但是犧牲了rowkey的有序性，

反轉rowkey的例子以手機號為rowkey，可以將手機號反轉后的字串作為rowkey，這樣的就避免了以手機號那樣比較固定開頭導致熱點問題

時間戳反轉

點我回傳目錄

一個常見的資料處理問題是快速獲取資料的最近版本，使用反轉的時間戳作為rowkey的一部分對這個問題十分有用，可以用 Long.Max_Value - timestamp 追加到key的末尾，例如[key][reverse_timestamp] , [key] 的最新值可以通過scan [key]獲得[key]的第一條記錄，因為HBase中rowkey是有序的，第一條記錄是最后錄入的資料，

比如需要保存一個用戶的操作記錄，按照操作時間倒序排序，在設計rowkey的時候，可以這樣設計：
[userId反轉][Long.Max_Value - timestamp]，在查詢用戶的所有操作記錄資料的時候，直接指定反轉后的userId，startRow是[userId反轉][000000000000],stopRow是[userId反轉][Long.Max_Value - timestamp]

如果需要查詢某段時間的操作記錄，startRow是[user反轉][Long.Max_Value - 起始時間]，stopRow是[userId反轉][Long.Max_Value - 結束時間]

其它的一些調優建議

點我回傳目錄

• 盡量減少rowkey和列的大小，當具體的值在系統間傳輸時，它的rowkey，列簇、列名，時間戳也會一起傳輸，如果你的rowkey、列簇名、列名很大，甚至可以和具體的值相比較，那么將會造成大量的冗余，不利于資料的儲存與傳輸，列族盡可能越短越好，最好是一個字符；列名也盡可能越短越好，冗長的列名雖然可讀性好，但是更短的列名存盤在HBase中會更好

4、HBase In Memory

點我回傳目錄

• 創建表的時候，可以通過HColumnDescriptor.setInMemory(true)將表放到 RegionServer的快取中，保證在讀取的時候被cache命中，

5、HBase Max Version

• 創建表的時候，可以通過HColumnDescriptor.setMaxVersions(int maxVersions)設定 表中資料的最大版本，如果只需要保存最新版本的資料，那么可以設定 setMaxVersions(1)，

6、HBase Compact & Split

點我回傳目錄

• 在HBase中，資料在更新時首先寫入WAL 日志(HLog)和記憶體(MemStore)中， MemStore中的資料是排序的，當MemStore累計到一定閾值時，由單獨的執行緒flush到磁盤上，成為一個StoreFile，與此同時， 系統會在zookeeper中記錄一個redo point，表示這個時刻之前的變更已經持久化了

• StoreFile是只讀的，一旦創建后就不可以再修改，因此Hbase的更新其實是不斷追加的操作，當一個Store中的StoreFile達到一定的閾值后，就會進行一次合并(major compact)，將對同一個key的修改合并到一起，形成一個大的StoreFile，當StoreFile的大小達到一定閾值后，又會對 StoreFile進行分割(split)，等分為兩個StoreFile，

7、HBase BulkLoading

點我回傳目錄

優點：

1. 如果我們一次性入庫hbase巨量資料，處理速度慢不說，還特別占用Region資源， 一個比較高效便捷的方法就是使用 “Bulk Loading”方法，即HBase提供的HFileOutputFormat類，

2. 它是利用hbase的資料資訊按照特定格式存盤在hdfs內這一原理，直接生成這種hdfs記憶體儲的資料格式檔案，然后上傳至合適位置，即完成巨量資料快速入庫的辦法，配合mapreduce完成，高效便捷，而且不占用region資源，增添負載，

限制：

1. 僅適合初次資料匯入，即表內資料為空，或者每次入庫表內都無資料的情況，

2. HBase集群與Hadoop集群為同一集群，即HBase所基于的HDFS為生成HFile的MR的集群

八、HBase Phoenix

點我回傳目錄

Hbase適合存盤大量的對關系運算要求低的NOSQL資料，受Hbase 設計上的限制不能直接使用原生的API執行在關系資料庫中普遍使用的條件判斷和聚合等操作，Hbase很優秀，一些團隊尋求在Hbase之上提供一種更面向普通開發人員的操作方式，Apache Phoenix即是，

Phoenix 基于Hbase給面向業務的開發人員提供了以標準SQL的方式對Hbase進行查詢操作，并支持標準SQL中大部分特性:條件運算,分組，分頁，等高級查詢語法，

有關phoenix的詳細介紹，和使用操作，下一期整理！
鏈接位置先給預留好，嘻嘻