您所在的位置:开发 > 大数据应用 > HBase设计:看上去很美

HBase设计:看上去很美

2012-11-14 09:48 zhenjing 博客园 字号:T | T
一键收藏,随时查看,分享好友!

随着hadoop系列的兴起,基于HDFS的大规模KV存储系统HBase也进入“大规模使用阶段”。网上的Hbase资料很多,学习成本正在下降。从公开的资料看,国外facebook、国内taobao均宣称在线上环境大规模使用hbase。一切都让人很兴奋。

AD:

缘起

随着hadoop系列的兴起,基于HDFS的大规模KV存储系统HBase也进入“大规模使用阶段”。网上的Hbase资料很多,学习成本正在下降。从公开的资料看,国外facebook、国内taobao均宣称在线上环境大规模使用hbase。一切都让人很兴奋。于是,在项目中引入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. View Code   
  2.  
  3. ulimit -n 65536  
  4.  
  5. export HBASE_OPTS="$HBASE_OPTS -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode" 
  6.  
  7. export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -Xmx20g -Xms20g -Xmn512m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSIn  
  8. itiatingOccupancyFraction=60 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:$HBASE_HOME/logs/gc-$(hostname)-hbase.lo  
  9. g" 

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

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

测试一:高并发读(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、自动调度、自动恢复、负载均衡等)。

原文链接:http://www.cnblogs.com/zhenjing/archive/2012/11/13/hbase_is_OK.html

【编辑推荐】

  1. 今年会不会感冒?大数据告诉你!
  2. Informatic但彬:大数据整合与电子商务
  3. eBay利用大数据促进在线交易
  4. 大数据提速:Impala能否取代Hive
  5. IDC分析师关于中国大数据市场的十大预测
【责任编辑:小林 TEL:(010)68476606】



分享到:

  1. 彻底透视CDN痛点,互联网老兵聊聊CDN的那些事儿!
  2. 3行Python代码完成人脸识别

热点职位

更多>>

热点专题

更多>>

读书

大师品软件——软件之痛与应对之道
这并不是一本传统的技术专著,因为它并没有包含一行代码,而更像是一部技术评论。作者通过幽默诙谐而又不失辛辣的语言,从程序员

51CTO旗下网站

领先的IT技术网站 51CTO 领先的中文存储媒体 WatchStor 中国首个CIO网站 CIOage 中国首家数字医疗网站 HC3i 51CTO学院