基于HBASE的并行计算架构之rowkey设计篇
生活随笔
收集整理的這篇文章主要介紹了
基于HBASE的并行计算架构之rowkey设计篇
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 自己在项目设计和开发的一些总结
- 下一篇: Mac os x下配置nginx + p