1.大數(shù)據(jù)在HBASE存儲、計算以及查詢的應(yīng)用場景

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

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

系統(tǒng)通過找到某個Rowkey (或者某個Rowkey?范圍)所在的Region，然后將查詢數(shù)據(jù)的請求路由到該Region獲取數(shù)據(jù)，如上圖所示。因此數(shù)據(jù)的合理的分布是提高檢索查詢性能的設(shè)計方式。例如獲取100萬條記錄，按每Region每秒1000條記錄算，獲取全部數(shù)據(jù)需要1000秒時間。如果數(shù)據(jù)均勻分布在集群每個Region上，那么在檢索時就可以最大可能利用并行計算特性，讓Region同時向客戶端吐數(shù)據(jù)，如果數(shù)據(jù)均勻分布在100個Region上，那么只需要10秒就能將所有數(shù)據(jù)取下來。HBASE也支持預(yù)建Region，根據(jù)數(shù)據(jù)的特性讓用戶來控制數(shù)據(jù)分布。 因此對于Rowkey的設(shè)計將控制平臺的并行計算效率。 3.根據(jù)HBASE功能特性設(shè)計rowkey實現(xiàn)并行計算 基于HBASE的特性，Rowkey的設(shè)計將決定并行計算架構(gòu)。 3.1.?設(shè)計原則 首先是Rowkey長度原則，Rowkey是一個二進(jìn)制碼流，Rowkey的長度被很多開發(fā)者建議說設(shè)計在10~100個字節(jié)，我的建議是越短越好，不要超過16個字節(jié)。原因一數(shù)據(jù)的持久化文件HFile中是按照KeyValue存儲的，如果Rowkey過長比如100個字節(jié)，1000萬列數(shù)據(jù)光Rowkey就要占用100*1000萬=10億個字節(jié)，將近1G數(shù)據(jù)，這會極大影響HFile的存儲效率；原因二MemStore將緩存部分?jǐn)?shù)據(jù)到內(nèi)存，如果Rowkey字段過長內(nèi)存的有效利用率會降低，系統(tǒng)將無法緩存更多的數(shù)據(jù)，這會降低檢索效率。因此Rowkey的字節(jié)長度越短越好。原因三目前操作系統(tǒng)是都是64位系統(tǒng)，內(nèi)存8字節(jié)對齊?？刂圃?6個字節(jié)，8字節(jié)的整數(shù)倍利用操作系統(tǒng)的最佳特性。 其次是Rowkey散列原則，如果Rowkey是按時間戳的方式遞增，不要將時間放在二進(jìn)制碼的前面，建議將Rowkey的高位作為散列字段，由程序循環(huán)生成，低位放時間字段，這樣將提高數(shù)據(jù)均衡分布在每個Regionserver實現(xiàn)負(fù)載均衡的幾率。如果沒有散列字段，首字段直接是時間信息將產(chǎn)生所有新數(shù)據(jù)都在一個RegionServer上堆積的熱點現(xiàn)象，這樣在做數(shù)據(jù)檢索的時候負(fù)載將會集中在個別RegionServer，降低查詢效率。 最后是Rowkey唯一原則，必須在設(shè)計上保證其唯一性。 3.2.?架構(gòu)模型 基于Rowkey的長度原則、散列原則以及唯一原則我將針對不同應(yīng)用場景提出不同的Rowkey設(shè)計建議。 針對事務(wù)數(shù)據(jù)Rowkey設(shè)計：事務(wù)數(shù)據(jù)是帶時間屬性的，我會將時間信息存入到Rowkey中，這有助于提示查詢檢索速度。對于事務(wù)數(shù)據(jù)我缺省就按天為數(shù)據(jù)建表，這樣設(shè)計的好處是多方面的。按天分表后，我時間信息就可以去掉日期部分只保留小時分鐘毫秒，這樣4個字節(jié)即可搞定。加上散列字段2個字節(jié)一共6個字節(jié)即可組成唯一Rowkey。如下圖所示：

?

事務(wù)數(shù)據(jù)Rowkey設(shè)計
第0字節(jié)	第1字節(jié)	第2字節(jié)	第3字節(jié)	第4字節(jié)	第5字節(jié)	…
散列字段		時間字段(毫秒)				擴(kuò)展字段
0~65535(0x0000~0xFFFF)		0~86399999(0x00000000~0x05265BFF)

?

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

?

統(tǒng)計數(shù)據(jù)Rowkey設(shè)計
第0字節(jié)	第1字節(jié)	第2字節(jié)	第3字節(jié)	第4字節(jié)	第5字節(jié)	…
散列字段(序列字段）				時間字段(分鐘)		擴(kuò)展字段
0x00000000~0xFFFFFFFF)				0~1439(0x0000~0x059F)

?

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

?

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

?

4.結(jié)論 以上總結(jié)了HBASE的并行計算架構(gòu)中關(guān)于Rowkey設(shè)計的要點。并行計算除了Rowkey之外還有其它影響因素，將在其他篇章予以說明。

參考鏈接：

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

轉(zhuǎn)載于:https://www.cnblogs.com/qxwandy/p/3716456.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。