HBase看上去很美我的项目失败之路

HBase设计：看上去很美

创新互联专注于青龙网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供青龙营销型网站建设，青龙网站制作、青龙网页设计、青龙网站官网定制、微信小程序开发服务，打造青龙网络公司原创品牌,更为您提供青龙网站排名全网营销落地服务。

HBase是模仿Google bigtable的开源产品，又是hadoop的衍生品，hadoop作为离线计算系统已经得到业界的普遍认可，并经过N多公司大规模使用的验证，自然地认为HBase也将随之获得成功。

《HBase: The Definitive Guide》第8章讲述HBase的架构，从架构上看，其架构很***：

LSM - 解决磁盘随机写问题(顺序写才是王道)；

HFile - 解决数据索引问题(只有索引才能高效读)；

WAL - 解决数据持久化(面对故障的持久化解决方案)；

zooKeeper - 解决核心数据的一致性和集群恢复；

Replication - 引入类似MySQL的数据复制方案，解决可用性；

此外还有：自动分拆Split、自动压缩(compaction,LSM的伴生技术)、自动负载均衡、自动region迁移。

看上去如此美好，完全无需人工干预，貌似只要将HBase搭建好，一切问题HBase都将应对自如。面对如此***的系统，不动心很难。

但是，如此***的系统或许也意味着背后的复杂性是不容忽略的。HBase的代码量也不是一星半点的。假如系统工作不正常，谁来解决？这是至关重要的。

性能与测试

HBase系统自身提供了性能测试工具：./bin/HBase  org.apache.hadoop.HBase.PerformanceEvaluation，该工具提供了随机读写、多客户端读写等性能测试功能。根据工具测试的结果看，HBase的性能不算差。

对于HBase这样的系统长期稳定运行比什么都重要。然而，这或许就不那么"***"。

测试版本：HBase 0.94.1、 hadoop 1.0.2、 jdk-6u32-linux-x64.bin、snappy-1.0.5.tar.gz

测试HBase搭建：14台存储机器+2台master、DataNode和regionserver放在一起。

HBase env配置：

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

HBase-size.xml关键配置(根据《HBase: The Definitive Guide》第11章优化)：

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

测试一：高并发读(4w+/s) + 少量写(允许分拆、负载均衡)

症状：1-2天后，HBase挂掉(系统性能极差，不到正常的10%)。其实并非全部挂掉，而是某些regionserver挂了，并在几个小时内引发其他regionserver挂掉。系统无法恢复：单独启regionserver无法恢复正常。重启后正常。

测试二：高并发读(4w+/s)

症状：1-2天后，HBase挂掉(系统性能极差，不到正常的10%)。后发现是由于zookeeper.session.timeout设置不正确导致(参见regionserver部分：http://HBase.apache.org/book.html#trouble)。重启后正常。

测试三：高并发读(4w+/s)

症状：1-2天后，HBase挂掉(系统性能极差，不到正常的10%)。从log未看出问题，但regionserver宕机，且datanode也宕机。重启后正常。

测试四：高并发读(4w+/s)+禁止分拆、禁止majorcompaction、禁止负载均衡(balance_switch命令)

症状：1-2天后，HBase挂掉(系统性能极差，不到正常的10%)。从log未看出问题，但regionserver宕机，且datanode也宕机。重启后正常。

测试期间，还发现过：无法获取".MATE."表的内容(想知道regionserver的分布情况)、HBase无法正确停止、HBase无法正确启动(日志恢复失败，文件错误，最终手动删除日志重启)。

其他缺陷

HBase使用JAVA开发，看上去很美的GC使用中代价可不小。HBase为了保证数据强一致性，每个key只能由一个regionserver提供服务。在下列情况下，HBase服务质量都将受损：

1) GC CMS -- CMS回收内存极其耗时，当HBase运行1-2天后，CMS可能耗时10分钟，这期间该regionserver无法服务。CMS经常被触发，这意味着HBase的服务经常会因为GC操作而部分暂停！

2) regionserver宕机 - 为了强一致性，每个key只由一个regionserver提供服务，故当regionserver宕机后，相应的region即无法服务！

3) major compaction、split不可控 - 大量磁盘操作将极大影响服务。(levelDB也需要major compaction，只是使用更加可控的方式做压缩，比如一次只有一个压缩任务。是否影响服务，待测试)

4) 数据恢复 - 数据恢复期间设置WAL log的相关操作，在数据恢复期间regionserver无法服务！

结论

或许通过研究HBase的源码可让HBase稳定运行，但从上述测试结果看：1）HBase还无法稳定长期运行；2）HBase系统很脆弱，故障恢复能力差。基于此，判断HBase还无法满足大规模线上系统的运维标准，只能放弃。考虑到HBase重启基本可恢复正常，故HBase还是可作为离线存储系统使用。

替代方案

面对大规模数据，基于磁盘的存储系统是必不可少的。google虽然公开了bigtable的设计，但未开源，但google开源了levelDB KV存储系统库(http://code.google.com/p/leveldb/)。levelDB采用C++实现，1.7版本的代码量大概2W，实现了LSM(自动压缩)、LevelFile(基本同HFile)，WAL，提供了简单的Put、Get、Delete、Write(批量写、事务功能)等接口。levelDB库实现了单机单库的磁盘存储方案，开发者可根据自己需要开发定制的存储系统(比如：数据Replication、自动调度、自动恢复、负载均衡等)。

参考文献

HBase: The Definitive Guide

The Apache HBase™ Reference Guide

HBase运维碎碎念(尤其***的参考文献)： http://www.slideshare.net/NinGoo/HBase-8433555

分享题目：HBase看上去很美我的项目失败之路
链接URL：http://www.shufengxianlan.com/qtweb/news0/78950.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

App开发知识

各行业网站

网站制作价格　　 　小谭建站　　 　航龙航空　　 　成都小程序商城　　 　温江网站设计　　 　防护网厂　　 　芦山网站建设　　 　led背发光字　　 　成都塑料加工　　 　重庆网站制作　　 　免备案空间　　 　企业网站维护　　 　成都虚拟主机　　 　简阳电信机房　　 　建站定制开发　　 　网站空间　　 　做网站价格　　 　成都服务器托管　　 　画册设计制作　　 　手提袋印刷制作