1 ColumnFamily 設計

追求的原則是：在合理的范圍內能盡量少的減少列簇就盡量減少列簇。

最優設計是：將所有相關性很強的 Key-Value 都放在同一個列簇下，這樣既能做到查詢效率最高，也能保持盡可能少的訪問不同的磁盤文件。

以用戶信息為例，可以將必須的基本信息存放在一個列簇，而一些附加的額外信息可以放在另一個列簇。

?

2 RowKey 設計

HBase 中，表會被劃分為 1...n 個 Region，被托管在 RegionServer 中。Region 兩個重要的屬性：StartKey 與 EndKey 表示這個 Region 維護的 RowKey 范圍，當我們要讀/寫數據時，如果 RowKey 落在某個 Start-end Key 范圍內，那么就會定位到目標 Region 并且讀/寫到相關的數據。

那怎么快速精準的定位到想要操作的數據，就在于 RowKey 的設計。

?

3. RowKey 設計三原則

3.1?RowKey 長度原則

RowKey 是一個二進制碼流，RowKey 的長度被很多開發者建議說設計在 10-100 個字節，建議是越短越好，不要超過 16 個字節。原因如下：

數據的持久化文件 HFile 中是按照 KeyValue 存儲的，如果 RowKey 過長，比如 100 個字節，如果有 1000 萬行數據，光 RowKey 就要占用 100 * 1000 萬 = 10 億字節，將近 1G 數據，這會極大的影響 HFile 的存儲效率。

MemStore 將緩存部分數據到內存當中，如果 RowKey 字段過長，內存的有效利用率就會降低，系統將無法緩存更多的數據，從而降低數據檢索效率。因此 RowKey 的字節長度越短越好。

目前操作系統都是 64 位系統，內存 8 字節對齊?？刂圃?16 個字節，是 8 字節的整數倍，利用操作系統的最佳特性。

?

3.2?RowKey 散列原則

如果 RowKey 是按時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將 RowKey 的高位作為散列字段，由程序循環生成，低位放時間字段，這樣將提高數據均衡分布在每個 RegionServer 實現負載均衡的幾率。如果沒有散列字段，首字段直接是時間信息，將產生所有新數據都在一個 RegionServer 上堆積的熱點現象，這樣在做數據檢索的時候負載會集中到個別的 RegionServer，降低查詢效率。

?

3.3 RowKey 唯一原則

必須在設計上保證其具有唯一性。RowKey 是按照字典順序進行排序存儲的，因此，設計 RowKey 的時候，要充分利用這個排序特點，將經常讀取的數據存儲到一個 Region 中，將最近可能會被訪問的數據放到一起。

?

數據熱點：

HBase 中的行是按照 RowKey 的字典順序進行排序的，這種設計優化了 scan 操作，可以將相關的行以及會被一起讀取的行存儲在臨近的位置，便于 scan 操作。然而，糟糕的 RowKey 設計是熱點的源頭。大量訪問會使熱點 Region 所在的單個節點超出自身承受能力，引起性能下降甚至 Region 不可用，由于主機無法提供其它 Region 的請求，這也會影響同一個 RegionServer 上的其它的 Region 的訪問。設計良好的數據訪問模式以使集群被充分和均衡的利用。為了避免寫熱點，設計 RowKey 使得不同行在同一個 Region，但是在更多數據情況下，數據應該被寫入集群的多個 Region，而不是一個 Region。

?

防止數據熱點的有效措施：

1. 加鹽

這里所說的加鹽不是密碼學中的加鹽，而是在 RowKey 的前面都加隨機數，就是給 RowKey 分配一個隨機前綴以使得它和之前的 RowKey 的開頭不同。分配的前綴各類數量應該和要使數據分散到的 Region 的數量一致。加鹽之后的 RowKey 就會根據隨機生成的前綴分散到各個 Region 上，以避免數據熱點的現象產生。

2. 哈希

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

3. 反轉

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

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

4. 時間戳反轉

一個常見的數據處理問題是快速獲取數據的最近版本，使用反轉的時間戳作為 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 - 結束時間]

?

總結

以上是生活随笔為你收集整理的HBase 的表设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。