大資料入門 Hbase Rowkey設計

在hadoop技術生態體系當中，hbase作為分布式資料庫而存在，也可以說是業界最早最經典的乙個分布式資料庫。hbase的原型來自google的bigtable，各方面效能優異，這其實得益於hbase的內部設計。今天的大資料入門分享，我們就來具體講講，hbase rowkey設計。

hbase與一般傳統分布式關係型資料庫相比，明顯不同的是，它是基於列模式儲存，同時是非常適合非結構化資料儲存的。

資料儲存在hdfs檔案系統上，要基於檔案系統將資料格式儲存，有兩種檔案型別——

hfile，hbase中keyvalue資料的儲存格式，hfile是hadoop的二進位制格式檔案，實際上storefile就是對hfile做了輕量級包裝，即storefile底層就是hfile。

hlogfile，hbase中wal（write ahead log）的儲存格式，物理上是hadoop的sequence file。

對於分布式資料庫，資料是分布在不同伺服器節點，hbase作為列式資料庫，一張表可以達到十億行，這就需要將表拆分成多個部分儲備起來，分別存入region中，由regionserver管理。

hbase通過rowkey進行劃分，在設計rowkey時，如有大量連續編號的rowkey，會導致大量rowkey相近的記錄集中在個別region裡，也就是集中在一台或幾台regionserver當中。

要實現很好的資料儲存、查詢、管理等操作，就需要有很好的rowkey的設計，對於各個專案業務場景來具體分析，從需求、開發、架構部署、查詢等整個生命週期都要開始考慮和優化的。

①rowkey長度原則

一般越短越好，不要超過16個位元組，原因如下：

目前作業系統都是64位系統，記憶體8位元組對齊，控制在16位元組，8位元組的整數倍利用了作業系統的最佳特性。

hbase將部分資料載入到記憶體當中，如果rowkey過長，記憶體的有效利用率就會下降。

②rowkey雜湊原則

如果rowkey按照時間戳的方式遞增，不要將時間放在二進位製碼的前面，建議將rowkey的高位位元組採用雜湊字段處理，由程式隨即生成。低位放時間字段，這樣將提高資料均衡分布，各個regionserver負載均衡的機率。

如果不進行雜湊處理，首字段直接使用時間資訊，所有該時段的資料都將集中到乙個regionserver當中，這樣當檢索資料時，負載會集中到個別regionserver上，造成熱點問題，會降低查詢效率。

③rowkey唯一原則

必須在設計上保證其唯一性，rowkey是按照字典順序排序儲存的，因此，設計rowkey的時候，要充分利用這個排序的特點，將經常讀取的資料儲存到一塊，將最近可能會被訪問的資料放到一塊。但是這裡的量不能太大，如果太大需要拆分到多個節點上去。

hbase在hadoop技術生態當中，地位還是非常重要的，對於hbase的內部原理、架構設計等，也建議大家理解透徹，掌握紮實。