Hbase -- 表的設計

1. 表的設計1.1 Pre-Creating Regions

默認情況下,在創建HBase表的時候會自動創建一個region分區,當導入數據的時候,所有的HBase客戶端都向這一個region寫數據,直到這個region足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先創建一些空的regions,這樣當數據寫入HBase時,會按照region分區情況,在集羣內做數據的負載均衡。

1.2 Row Key

HBase中row key用來檢索表中的記錄,支持以下三種方式:

  • 通過單個row key訪問:即按照某個row key鍵值進行get操作;
  • 通過row key的range進行scan:即通過設置startRowKey和endRowKey,在這個範圍內進行掃描;
  • 全表掃描:即直接掃描整張表中所有行記錄。

在HBase中,row key可以是任意字符串,最大長度64KB,實際應用中一般爲10~100bytes,存爲byte[]字節數組,一般設計成定長的。

row key是按照字典序存儲,因此,設計row key時,要充分利用這個排序特點,將經常一起讀取的數據存儲到一塊,將最近可能會被訪問的數據放在一塊。

舉個例子:如果最近寫入HBase表中的數據是最可能被訪問的,可以考慮將時間戳作爲row key的一部分,由於是字典序排序,所以可以使用Long.MAX_VALUE - timestamp作爲row key,這樣能保證新寫入的數據在讀取時可以被快速命中。

1.3 Column Family

不要在一張表裏定義太多的column family。目前Hbase並不能很好的處理超過2~3個column family的表。因爲某個column family在flush的時候,它鄰近的column family也會因關聯效應被觸發flush,最終導致系統產生更多的I/O。感興趣的同學可以對自己的HBase集羣進行實際測試,從得到的測試結果數據驗證一下。

1.4 In Memory

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

1.5 Max Version

創建表的時候,可以通過HColumnDescriptor.setMaxVersions(int maxVersions)設置表中數據的最大版本,如果只需要保存最新版本的數據,那麼可以設置setMaxVersions(1)。

1.6 Time To Live

創建表的時候,可以通過HColumnDescriptor.setTimeToLive(int timeToLive)設置表中數據的存儲生命期,過期數據將自動被刪除,例如如果只需要存儲最近兩天的數據,那麼可以設置setTimeToLive(2 * 24 * 60 * 60)。

1.7 Compact & Split

在HBase中,數據在更新時首先寫入WAL 日誌(HLog)和內存(MemStore)中,MemStore中的數據是排序的,當MemStore累計到一定閾值時,就會創建一個新的MemStore,並且將老的MemStore添加到flush隊列,由單獨的線程flush到磁盤上,成爲一個StoreFile。於此同時, 系統會在zookeeper中記錄一個redo point,表示這個時刻之前的變更已經持久化了(minor compact)。

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

由於對錶的更新是不斷追加的,處理讀請求時,需要訪問Store中全部的StoreFile和MemStore,將它們按照row key進行合併,由於StoreFile和MemStore都是經過排序的,並且StoreFile帶有內存中索引,通常合併過程還是比較快的。


實際應用中,可以考慮必要時手動進行major compact,將同一個row key的修改進行合併形成一個大的StoreFile。同時,可以將StoreFile設置大些,減少split的發生。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章