Hbase的表結構設計與關係型資料庫有很多不同，主要是Hbase有Rowkey和列族、timestamp這幾個全新的概念，如何設計表結構就非常的重要。

建立

Hbase就是通過 表 Rowkey 列族 timestamp確定一行資料。

這與關係型資料庫完全不同：

屬性	HBase	RDBMS
資料型別	只有字串	豐富的資料型別
資料操作	簡單的增刪改查 不支援join	各種函式和表連線
儲存模式	基於列式儲存	基於表格結構和行式儲存
資料保護	更新後仍然保留舊版本	替換
可伸縮性	輕易的增加節點，相容性高	需要中間層，犧牲功能

所以Hbase需要考慮的因素有：

1、這個表應該有多少列族

2、列族使用什麼資料

3、每個列族有多少列

4、列名是什麼

5、單元應該存放什麼資料

6、每個單元儲存多少時間版本

7、Rowkey結構是什麼，應該包含什麼資訊

需要注意的點：

1、Join

Hbase中沒有join 所以需要大表結構 行記錄加關鍵字 解決這個問題

2、Rowkey

Rowkey設計非常重要 由於Hbase是有序的 需要考慮字首字尾問題

可以通過Hbase Shell和 Java Api建立：

Configuration config = HBaseConfiguration.create();
Admin admin = new Admin(conf);
TableName table = TableName.valueOf("myTable");

admin.disableTable(table);

HColumnDescriptor cf1 = ...;
admin.addColumn(table, cf1);      // adding new ColumnFamily
HColumnDescriptor cf2 = ...;
admin.modifyColumn(table, cf2);    // modifying existing ColumnFamily

admin.enableTable(table);
 

Rowkey設計

Rowkey是不可分割的位元組陣列，按字典序儲存在表中。

由於：Region基於Rowkey為一個區間的行提供服務 HFile在硬碟上儲存有序的行 所以Rowkey就極大的影響了Hbase的效能。

Rowkey就是索引，如果不清楚Rowkey就只能掃描全表，那麼效能將會大幅度下降。

這裡用影片熱度排行榜舉例：

1、Rowkey是以字典序從大到小

原生Hbase只支援從小到大排序，要想實現從大到小，可以採用 Rowkey=Integer.MAX_VALUE-Rowkey的方式，在應用層再轉回來完成需求。

2、Rowkey儘量雜湊

Rowkey要儘量雜湊，這樣可以保證資料不在一個Region上，從而避免了讀寫的集中。

比如我們可以設計 userid_videoid 拼接字串 這樣的話user就會不均勻。

有三種辦法解決： 反轉userid 雜湊userid 將userid取模後進行MD5加密 取前6位加入userid中

3、Rowkey長度要儘量短

Rowkey過長，儲存開銷會大。

Rowkey過長，會導致記憶體的利用率降低，進而降低索引命中率。

列族

列族是一些列的集合，一個列族所有成員都有同樣的字首，比如courses：history 和 courses：math都是courses列族的成員。冒號是分隔符。列族字首必須是可輸出字元，列可由任意位元組陣列組成。

列族必須在表建立的時候宣告，列則不需要特別宣告，使用者隨時可以建立新列。

經驗法則：

• 目標是把 region 的大小限制在 10 到 50 GB 之間。
• 目標是限制 cell 的大小在 10 MB 之內，如果使用的是 mob型別，限制在 50 MB 之內。否則，考慮把 cell 的資料儲存在 HDFS 中，並在 HBase 中儲存指向該資料的指標。
• 典型的 scheme 每張表包含 1 到 3 個列族。HBase 表設計不應當和 RDBMS 表設計類似。
• 對於擁有 1 或 2 個列族的表來說，50-100 個 region 是比較合適的。請記住， region 是列族的連續段。
• 保持列族名稱儘可能短。每個值都會儲存列族的名稱(忽略字首編碼)。它們不應該像典型 RDBMS 那樣，是自文件化，描述性的名稱。
• 如果你正在儲存基於時間的機器資料或者日誌資訊，並且 row key 是基於裝置 ID 或者服務 ID + 時間，最終會出現這樣一種情況，即更舊的資料 region 永遠不會有額外寫入。在這種情況下，最終會存在少量的活動 region 和大量不會再有新寫入的 region。對於這種情況，可以接受更多的 region 數量，因為資源的消耗只取決於活動 region。
• 如果只有一個列族會頻繁寫，那麼只讓這個列族佔用記憶體。當分配資源的時候注意寫入模式。

例項

店鋪與商品

店鋪shop 商品 item 是多對多的關係

RDBMS表結構設計：

商鋪表：

列名	列含義
id	主鍵
name	店鋪名稱
address	所在地
regdate	註冊日期

商品表：

列名	列含義
id	主鍵
name	商品名稱
price	價格
details	商品詳情
title	展示名稱

關係表：

列名	列含義
shop_id	店鋪主鍵
item_id	商品主鍵
type	關聯型別

Hbase表結構設計：

店鋪表：

商品表：

微博使用者與粉絲

使用者與粉絲是一對多

RDBMS表結構設計：

使用者表：

列名	列含義
id	主鍵
nickname	使用者名稱

粉絲對應表：

列名	列含義
user_id	使用者id
fans_id	粉絲id

Hbase表結構設計：

更多實時計算，Hbase，Flink，Kafka等相關技術博文，歡迎關注實時流式計算

相關推薦