日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間:8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
HBase看上去很美我的項(xiàng)目失敗之路

HBase設(shè)計(jì):看上去很美

創(chuàng)新互聯(lián)專注于青龍網(wǎng)站建設(shè)服務(wù)及定制,我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供青龍營銷型網(wǎng)站建設(shè),青龍網(wǎng)站制作、青龍網(wǎng)頁設(shè)計(jì)、青龍網(wǎng)站官網(wǎng)定制、微信小程序開發(fā)服務(wù),打造青龍網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供青龍網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

HBase是模仿Google bigtable的開源產(chǎn)品,又是hadoop的衍生品,hadoop作為離線計(jì)算系統(tǒng)已經(jīng)得到業(yè)界的普遍認(rèn)可,并經(jīng)過N多公司大規(guī)模使用的驗(yàn)證,自然地認(rèn)為HBase也將隨之獲得成功。

《HBase: The Definitive Guide》第8章講述HBase的架構(gòu),從架構(gòu)上看,其架構(gòu)很***:

LSM - 解決磁盤隨機(jī)寫問題(順序?qū)懖攀峭醯?;

HFile - 解決數(shù)據(jù)索引問題(只有索引才能高效讀);

WAL - 解決數(shù)據(jù)持久化(面對故障的持久化解決方案);

zooKeeper - 解決核心數(shù)據(jù)的一致性和集群恢復(fù);

Replication - 引入類似MySQL的數(shù)據(jù)復(fù)制方案,解決可用性;

此外還有:自動(dòng)分拆Split、自動(dòng)壓縮(compaction,LSM的伴生技術(shù))、自動(dòng)負(fù)載均衡、自動(dòng)region遷移。

看上去如此美好,完全無需人工干預(yù),貌似只要將HBase搭建好,一切問題HBase都將應(yīng)對自如。面對如此***的系統(tǒng),不動(dòng)心很難。

但是,如此***的系統(tǒng)或許也意味著背后的復(fù)雜性是不容忽略的。HBase的代碼量也不是一星半點(diǎn)的。假如系統(tǒng)工作不正常,誰來解決?這是至關(guān)重要的。

性能與測試

HBase系統(tǒng)自身提供了性能測試工具:./bin/HBase  org.apache.hadoop.HBase.PerformanceEvaluation,該工具提供了隨機(jī)讀寫、多客戶端讀寫等性能測試功能。根據(jù)工具測試的結(jié)果看,HBase的性能不算差。

對于HBase這樣的系統(tǒng)長期穩(wěn)定運(yùn)行比什么都重要。然而,這或許就不那么"***"。

測試版本:HBase 0.94.1、 hadoop 1.0.2、 jdk-6u32-linux-x64.bin、snappy-1.0.5.tar.gz

測試HBase搭建:14臺(tái)存儲(chǔ)機(jī)器+2臺(tái)master、DataNode和regionserver放在一起。

HBase env配置:

 
 
  1. ulimit -n 65536 
  2. export HBASE_OPTS="$HBASE_OPTS -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode" 
  3. export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -Xmx20g -Xms20g -Xmn512m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSIn 
  4. itiatingOccupancyFraction=60 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:$HBASE_HOME/logs/gc-$(hostname)-hbase.lo 
  5. g" 

HBase-size.xml關(guān)鍵配置(根據(jù)《HBase: The Definitive Guide》第11章優(yōu)化):

 
 
  1.   
  2.                 hbase.regionserver.handler.count 
  3.                 16 
  4.                 Count of RPC Listener instances spun up on RegionServers. 
  5.                 Same property is used by the Master for count of master handlers. 
  6.                 Default is 10. 
  7.                  
  8.          
  9.  
  10.          
  11.                 hbase.regionserver.global.memstore.upperLimit 
  12.                 0.35 
  13.                 Maximum size of all memstores in a region server before new 
  14.                 updates are blocked and flushes are forced. Defaults to 40% of heap 
  15.                  
  16.          
  17.          
  18.                 hbase.regionserver.global.memstore.lowerLimit 
  19.                 0.3 
  20.                 When memstores are being forced to flush to make room in 
  21.                 memory, keep flushing until we hit this mark. Defaults to 35% of heap. 
  22.                 This value equal to hbase.regionserver.global.memstore.upperLimit causes 
  23.                 the minimum possible flushing to occur when updates are blocked due to 
  24.                 memstore limiting. 
  25.                  
  26.          
  27.  
  28.          
  29.                 hfile.block.cache.size 
  30.                 0.35 
  31.                  
  32.                 Percentage of maximum heap (-Xmx setting) to allocate to block cache 
  33.                 used by HFile/StoreFile. Default of 0.25 means allocate 25%. 
  34.                 Set to 0 to disable but it's not recommended. 
  35.                  
  36.          
  37.  
  38.          
  39.                 zookeeper.session.timeout 
  40.                 600000 
  41.                 ZooKeeper session timeout. 
  42.                 HBase passes this to the zk quorum as suggested maximum time for a 
  43.                 session (This setting becomes zookeeper's 'maxSessionTimeout').  See 
  44.                 http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions 
  45.                 "The client sends a requested timeout, the server responds with the 
  46.                 timeout that it can give the client. " In milliseconds. 
  47.                  
  48.          
  49.  
  50.  
  51.     hbase.zookeeper.property.tickTime 
  52.     60000 
  53.  
  54.  
  55.  
  56.     hbase.regionserver.restart.on.zk.expire 
  57.     true 
  58.  
  59.  
  60.    
  61.     hbase.hregion.majorcompaction 
  62.     0 
  63.     The time (in miliseconds) between 'major' compactions of all 
  64.     HStoreFiles in a region.  Default: 1 day(86400000). 
  65.     Set to 0 to disable automated major compactions. 
  66.      
  67.    
  68.  
  69.    
  70.     hbase.hregion.max.filesize 
  71.     536870912000 
  72.      
  73.     Maximum HStoreFile size. If any one of a column families' HStoreFiles has 
  74.     grown to exceed this value, the hosting HRegion is split in two. 
  75.     Default: 1G(1073741824).  Set 500G, disable file split! 
  76.      
  77.    

測試一:高并發(fā)讀(4w+/s) + 少量寫(允許分拆、負(fù)載均衡)

癥狀:1-2天后,HBase掛掉(系統(tǒng)性能極差,不到正常的10%)。其實(shí)并非全部掛掉,而是某些regionserver掛了,并在幾個(gè)小時(shí)內(nèi)引發(fā)其他regionserver掛掉。系統(tǒng)無法恢復(fù):單獨(dú)啟regionserver無法恢復(fù)正常。重啟后正常。

測試二:高并發(fā)讀(4w+/s)

癥狀:1-2天后,HBase掛掉(系統(tǒng)性能極差,不到正常的10%)。后發(fā)現(xiàn)是由于zookeeper.session.timeout設(shè)置不正確導(dǎo)致(參見regionserver部分:http://HBase.apache.org/book.html#trouble)。重啟后正常。

測試三:高并發(fā)讀(4w+/s)

癥狀:1-2天后,HBase掛掉(系統(tǒng)性能極差,不到正常的10%)。從log未看出問題,但regionserver宕機(jī),且datanode也宕機(jī)。重啟后正常。

測試四:高并發(fā)讀(4w+/s)+禁止分拆、禁止majorcompaction、禁止負(fù)載均衡(balance_switch命令)

癥狀:1-2天后,HBase掛掉(系統(tǒng)性能極差,不到正常的10%)。從log未看出問題,但regionserver宕機(jī),且datanode也宕機(jī)。重啟后正常。

測試期間,還發(fā)現(xiàn)過:無法獲取".MATE."表的內(nèi)容(想知道regionserver的分布情況)、HBase無法正確停止、HBase無法正確啟動(dòng)(日志恢復(fù)失敗,文件錯(cuò)誤,最終手動(dòng)刪除日志重啟)。

其他缺陷

HBase使用JAVA開發(fā),看上去很美的GC使用中代價(jià)可不小。HBase為了保證數(shù)據(jù)強(qiáng)一致性,每個(gè)key只能由一個(gè)regionserver提供服務(wù)。在下列情況下,HBase服務(wù)質(zhì)量都將受損:

1) GC CMS -- CMS回收內(nèi)存極其耗時(shí),當(dāng)HBase運(yùn)行1-2天后,CMS可能耗時(shí)10分鐘,這期間該regionserver無法服務(wù)。CMS經(jīng)常被觸發(fā),這意味著HBase的服務(wù)經(jīng)常會(huì)因?yàn)镚C操作而部分暫停!

2) regionserver宕機(jī) - 為了強(qiáng)一致性,每個(gè)key只由一個(gè)regionserver提供服務(wù),故當(dāng)regionserver宕機(jī)后,相應(yīng)的region即無法服務(wù)!

3) major compaction、split不可控 - 大量磁盤操作將極大影響服務(wù)。(levelDB也需要major compaction,只是使用更加可控的方式做壓縮,比如一次只有一個(gè)壓縮任務(wù)。是否影響服務(wù),待測試)

4) 數(shù)據(jù)恢復(fù) - 數(shù)據(jù)恢復(fù)期間設(shè)置WAL log的相關(guān)操作,在數(shù)據(jù)恢復(fù)期間regionserver無法服務(wù)!

結(jié)論

或許通過研究HBase的源碼可讓HBase穩(wěn)定運(yùn)行,但從上述測試結(jié)果看:1)HBase還無法穩(wěn)定長期運(yùn)行;2)HBase系統(tǒng)很脆弱,故障恢復(fù)能力差?;诖?,判斷HBase還無法滿足大規(guī)模線上系統(tǒng)的運(yùn)維標(biāo)準(zhǔn),只能放棄。考慮到HBase重啟基本可恢復(fù)正常,故HBase還是可作為離線存儲(chǔ)系統(tǒng)使用。

替代方案

面對大規(guī)模數(shù)據(jù),基于磁盤的存儲(chǔ)系統(tǒng)是必不可少的。google雖然公開了bigtable的設(shè)計(jì),但未開源,但google開源了levelDB KV存儲(chǔ)系統(tǒng)庫(http://code.google.com/p/leveldb/)。levelDB采用C++實(shí)現(xiàn),1.7版本的代碼量大概2W,實(shí)現(xiàn)了LSM(自動(dòng)壓縮)、LevelFile(基本同HFile),WAL,提供了簡單的Put、Get、Delete、Write(批量寫、事務(wù)功能)等接口。levelDB庫實(shí)現(xiàn)了單機(jī)單庫的磁盤存儲(chǔ)方案,開發(fā)者可根據(jù)自己需要開發(fā)定制的存儲(chǔ)系統(tǒng)(比如:數(shù)據(jù)Replication、自動(dòng)調(diào)度、自動(dòng)恢復(fù)、負(fù)載均衡等)。

參考文獻(xiàn)

HBase: The Definitive Guide

The Apache HBase? Reference Guide

HBase運(yùn)維碎碎念(尤其***的參考文獻(xiàn)): http://www.slideshare.net/NinGoo/HBase-8433555


文章標(biāo)題:HBase看上去很美我的項(xiàng)目失敗之路
當(dāng)前網(wǎng)址:http://www.dlmjj.cn/article/dpgjdeo.html