1.大數據在HBASE存儲、計算以及查詢的應用場景

海量數據都是事務數據，事務數據都是在時間的基礎上產生的。數據的業務時間可能會順序產生，也可能不會順序產生，比如某些事務發生在早上10點，但是在下午5點才結束閉并生成出來，這樣的數據就會造成存儲加載時的時間連續性。另外海量數據的挖掘后產生的是統計數據，統計數據也有時間屬性，統計數據如果進行保存必須保證在統計計算之后數據盡量不再變化，如果統計發生后又有新的事務數據產生，那么將重新觸發統計計算然后重新保存覆蓋原有已經存儲的數據。其它數據則主要是以配置數據為主的通用數據。 根據以上分析按照數據的特性，我們可以將數據分為事務數據、統計數據與通用數據。 針對數據的查詢根據數據的分類會有不同的用戶操作場景。對于事務數據，用戶的查詢一定會給出時間范圍（即使用戶不給這個條件系統也會缺省設置），因為事務數據是海量的，如果要在指定時間范圍根據不同的條件進行過濾、篩選、分組、聚合、多表關聯等操作，數據在文件持久化的方式以及索引的架構將決定查詢的效率，如何聰明的設計應對以上問題是高效應用HBASE的一個最大的課題。統計數據相對事務數據有一定收斂，但是同樣要解決相同的查詢問題。通用數據不會涉及復雜的查詢需求，但是從產品的深度規劃來說，要考慮與其它表關聯的問題。 以上是我們對大數據應用出現的3種數據形態的應用場景做的一個簡單介紹，下面我簡單分析一下HBASE的架構與功能特性，從而推導出如何實現以上應用場景中的存儲、計算與查詢的需求。 2.標準HBASE功能特性分析 HBase是一個分布式的、面向列的開源數據庫，是Apache的Hadoop?項目的子項目。HBase不同于一般的關系數據庫，它是一個適合于非結構化數據存儲的數據庫。另一個不同的是HBase基于列的而不是基于行的模式。如下圖所示，HBASE是介于hadoop的HDFS與MapReduce之間的一個系統，基礎性的介紹我這里不做多的描述，相關資料很多可參考。 如下圖所示，HBASE的層次結構是RegionServer > Region > Store(MemStore) > StoreFile > HFile。HFile是數據的持久化存儲媒質，MemStore是數據的內存緩存。HBASE是采用KeyValue的列存儲，Rowkey是KeyValue的Key，表示唯一一行。Rowkey是一段二進制碼流，最大程度為64KB，內容用戶自定義。數據的加載根據Rowkey的二進制序由小到大進行排序。HBASE根據數據的規模將數據自動分切到多個Region的多個HFile中。??

HBASE是根據Rowkey來進行檢索的。支持3種方式。通過單個Rowkey訪問，即按照某個Rowkey鍵值進行get操作；通過Rowkey的range進行scan，即通過設置startRowKey和endRowKey，在這個范圍內進行掃描；全表掃描，即直接掃描整張表中所有行記錄。HBASE按單個Rowkey檢索的效率是很高的，耗時在1毫秒以下，每秒鐘可獲取1000~2000條記錄。

系統通過找到某個Rowkey (或者某個Rowkey?范圍)所在的Region，然后將查詢數據的請求路由到該Region獲取數據，如上圖所示。因此數據的合理的分布是提高檢索查詢性能的設計方式。例如獲取100萬條記錄，按每Region每秒1000條記錄算，獲取全部數據需要1000秒時間。如果數據均勻分布在集群每個Region上，那么在檢索時就可以最大可能利用并行計算特性，讓Region同時向客戶端吐數據，如果數據均勻分布在100個Region上，那么只需要10秒就能將所有數據取下來。HBASE也支持預建Region，根據數據的特性讓用戶來控制數據分布。 因此對于Rowkey的設計將控制平臺的并行計算效率。 3.根據HBASE功能特性設計rowkey實現并行計算 基于HBASE的特性，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字節的整數倍利用操作系統的最佳特性。 其次是Rowkey散列原則，如果Rowkey是按時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將Rowkey的高位作為散列字段，由程序循環生成，低位放時間字段，這樣將提高數據均衡分布在每個Regionserver實現負載均衡的幾率。如果沒有散列字段，首字段直接是時間信息將產生所有新數據都在一個RegionServer上堆積的熱點現象，這樣在做數據檢索的時候負載將會集中在個別RegionServer，降低查詢效率。 最后是Rowkey唯一原則，必須在設計上保證其唯一性。 3.2.?架構模型 基于Rowkey的長度原則、散列原則以及唯一原則我將針對不同應用場景提出不同的Rowkey設計建議。 針對事務數據Rowkey設計：事務數據是帶時間屬性的，我會將時間信息存入到Rowkey中，這有助于提示查詢檢索速度。對于事務數據我缺省就按天為數據建表，這樣設計的好處是多方面的。按天分表后，我時間信息就可以去掉日期部分只保留小時分鐘毫秒，這樣4個字節即可搞定。加上散列字段2個字節一共6個字節即可組成唯一Rowkey。如下圖所示：

?

事務數據Rowkey設計
第0字節	第1字節	第2字節	第3字節	第4字節	第5字節	…
散列字段		時間字段(毫秒)				擴展字段
0~65535(0x0000~0xFFFF)		0~86399999(0x00000000~0x05265BFF)

?

這樣的設計從操作系統內存管理層面無法節省開銷，因為64位操作系統是必須8字節對齊。但是對于持久化存儲中Rowkey部分可以節省25%的開銷。也許有人要問為什么不將時間字段以主機字節序保存，這樣它也可以作為散列字段了。這是因為時間范圍內的數據還是盡量保證連續，相同時間范圍內的數據查找的概率很大，對查詢檢索有好的效果，因此使用獨立的散列字段效果更好，對于某些應用，我們可以考慮利用散列字段全部或者部分來存儲某些數據的字段信息，只要保證相同散列值在同一時間（毫秒）唯一。 針對統計數據的Rowkey設計：統計數據也是帶時間屬性的，統計數據最小單位只會到分鐘（到秒預統計就沒意義了）。同時對于統計數據我們也缺省采用按天數據分表，這樣設計的好處無需多說。按天分表后，時間信息只需要保留小時分鐘，那么0~1400只需占用兩個字節即可保存時間信息。由于統計數據某些維度數量非常龐大，因此需要4個字節作為序列字段，因此將散列字段同時作為序列字段使用也是6個字節組成唯一Rowkey。如下圖所示：

?

統計數據Rowkey設計
第0字節	第1字節	第2字節	第3字節	第4字節	第5字節	…
散列字段(序列字段）				時間字段(分鐘)		擴展字段
0x00000000~0xFFFFFFFF)				0~1439(0x0000~0x059F)

?

同樣這樣的設計從操作系統內存管理層面無法節省開銷，因為64位操作系統是必須8字節對齊。但是對于持久化存儲中Rowkey部分可以節省25%的開銷。預統計數據可能涉及到多次反復的重計算要求，需確保作廢的數據能有效刪除，同時不能影響散列的均衡效果，因此要特殊處理。 針對通用數據的Rowkey設計：通用數據采用自增序列作為唯一主鍵，用戶可以選擇按天建分表也可以選擇單表模式。這種模式需要確保同時多個入庫加載模塊運行時散列字段（序列字段）的唯一性。可以考慮給不同的加載模塊賦予唯一因子區別。設計結構如下圖所示。

?

通用數據Rowkey設計
第0字節	第1字節	第2字節	第3字節	…
散列字段(序列字段）				擴展字段（控制在12字節內）
0x00000000~0xFFFFFFFF)				可由多個用戶字段組成

?

4.結論 以上總結了HBASE的并行計算架構中關于Rowkey設計的要點。并行計算除了Rowkey之外還有其它影響因素，將在其他篇章予以說明。

參考鏈接：

http://xdataopen.blog.51cto.com/4219560/1117864

轉載于:https://www.cnblogs.com/qxwandy/p/3716456.html

總結

以上是生活随笔為你收集整理的基于HBASE的并行计算架构之rowkey设计篇的全部內容，希望文章能夠幫你解決所遇到的問題。

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