关于HBase的一些零碎事

标签: 技术 Cassandra cloudera hadoop hbase | 发表时间:2011-06-18 10:15 | 作者:NinGoo jiaosq
出处:http://www.ningoo.net

随着Facebook使用HBase来构建实时消息系统,基于Hadoop的面向列存储的HBase持续升温。

目前稳定版本的HBase0.90.2只能基于Hadoop0.20.x系列版本,暂不支持最新的0.21.x。而且官方版本的Hadoop0.20.2(或者0.203.0)缺少一个重要的特性,HDFS不支持sync模式的持久,这样HBase就有较大的丢失数据的风险。要在生产环境使用HBase,有两个选择,一是使用Cloudera的CDH3版本,Cloudera就类似MySQL的Percona,对官方版本的Hadoop做了很多改进工作,而且经典的《Hadoop:The Definitive Guide》一书的作者Tom White就是Cloudera的一员,这也和《High performance MySQL》一书的作者主要来是Percona一样。另外一种选择,就是自行编译Hadoop branch-0.20-append源码分支,这里有详细的说明

对于HBase这种类似BigTable的系统,其优化之一是消除了磁盘的随机写。付出的代价是将最新的数据保存在内存表中,对内存有较大的需求。如果内存表的数量较多,则每个内存表就会在较小的时候刷到磁盘,导致磁盘文件多而且小。范围读取数据的时候就会跨多个数据文件甚至多个节点。为提升读性能,系统都会设计有compaction操作。另外为了防止某些情况下数据文件过大(hbase.hregion.max.filesize,默认256M,太大的数据文件在compaction等操作是对内存的消耗更大),HBase也设计了split操作。Compaction和Split操作,对于在线应用的响应时间都容易造成波动,他们的策略需要根据应用的特性进行调整。建议在业务低峰期手工调整。

HBase的regionserver宕机超过一定时间后,HMaster会将其所管理的region重新分布到其他存活的regionserver,由于数据和日志都持久在HDFS中,因此该操作不会导致数据丢失。但是重新分配的region需要根据日志恢复原regionserver中的内存表,这会导致宕机的region在这段时间内无法对外提供服务。而一旦重分布,宕机的节点起来后就相当于一个新的regionserver加入集群,为了平衡,需要再次将某些region分布到该server。 因此这个超时建议根据情况进行调整,一般情况下,宕机重启后即可恢复,如果重启需要10分钟,region重分布加恢复的时间要超过5分钟,那么还不如等节点重启。Region Server的内存表memstore如何在节点间做到更高的可用,是HBase的一个较大的挑战。Oceanbase也是采用内存表保持最新的更新数据,和HBase不同的是,Oceanbase使用的是集中的UpdateServer,只需要全力做好UpdateServer的容灾切换即可对业务连续性做到最小影响。分布还是集中,哪些功能分布,哪些功能集中,各自取不同平衡,是目前大部分分布式数据库或者存储的一个主要区别。当然,像Cassandra这种全分布的,架构上看起来很完美,实际应用起来反而问题更多。

对于java应用,线上运维最大的挑战之一就是heap内存管理。GC的不同方式,以及使用内存表和cache对内存的消耗,可能导致局部阻塞应用或者stop the world全局阻塞或者OOM。因此HBase的很多参数设置都是针对这两种情况。HBase使用了较新的CMS GC(-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode)。

默认触发GC的时机是当年老代内存达到90%的时候,这个百分比由 -XX:CMSInitiatingOccupancyFraction=N 这个参数来设置。concurrent mode failed发生在这样一个场景:
当年老代内存达到90%的时候,CMS开始进行并发垃圾收集,于此同时,新生代还在迅速不断地晋升对象到年老代。当年老代CMS还未完成并发标记时,年老代满了,悲剧就发生了。CMS因为没内存可用不得不暂停mark,并触发一次全jvm的stop the world(挂起所有线程),然后采用单线程拷贝方式清理所有垃圾对象。这个过程会非常漫长。为了避免出现concurrent mode failed,我们应该让GC在未到90%时,就触发。

通过设置 -XX:CMSInitiatingOccupancyFraction=N

这个百分比, 可以简单的这么计算。如果你的 hfile.block.cache.size 和 hbase.regionserver.global.memstore.upperLimit 加起来有60%(默认),那么你可以设置 70-80,一般高10%左右差不多。

(以上CMS GC的说明引自HBase性能调优

目前关于HBase的书不多,《Hadoop: The Definitive Guide》第二版有一章,另外最权威的要算官方的这本电子书了。

这篇是最近看HBase过程中的一些零碎的东西,记录于此备忘。

您可能也喜欢:

HBase运维碎碎念

OOW2009美国行:大会第一天

淘宝网招聘Oracle&MySQL DBA

StarCraft II呼之欲出

开源的淘宝
无觅

相关 [hbase] 推荐:

hbase介绍

- AreYouOK? - 淘宝数据平台与产品部官方博客 tbdata.org
hbase是bigtable的开源山寨版本. 是建立的hdfs之上,提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统. 它介于nosql和RDBMS之间,仅能通过主键(row key)和主键的range来检索数据,仅支持单行事务(可通过hive支持来实现多表join等复杂操作). 主要用来存储非结构化和半结构化的松散数据.

Riak对比HBase

- - NoSQLFan
文章来自 Riak官方wiki,是一篇Riak与HBase的对比文章. Riak官方的对比通常都做得很中肯,并不刻意偏向自家产品. 对比的Riak版本是1.1.x,HBase是0.94.x. Riak 与 HBase 都是基于 Apache 2.0 licensed 发布. Riak 的实现是基于 Amazon 的 Dynamo 论文,HBase 是基于 Google 的 BigTable.

[转]HBase简介

- - 小鸥的博客
   Hbase是一个分布式开源数据库,基于Hadoop分布式文件系统,模仿并提供了基于Google文件系统的Bigtable数据库的所有功能. 其目标是处理非常庞大的表,可以用普通的计算机处理超过10亿行数据,并且有数百万列元素组成的数据表. Hbase可以直接使用本地文件系统或者Hadoop作为数据存储方式,不过为了提高数据可靠性和系统的健壮性,发挥Hbase处理大数据量等功能,需要使用Hadoop作为文件系统.

HBase表设计

- - 互联网 - ITeye博客
默认情况下,在创建HBase表的时候会自动创建一个region分区,当导入数据的时候,所有的HBase客户端都向这一个region写数据, 直到这 个region足够大了才进行切分. 一种可以加快批量写入速度的方法是通过预先创建一些空的regions,这样当数据写入HBase时,会按 照 region分区情况,在集群内做数据的负载均衡.

HBase Memstore配置

- - 行业应用 - ITeye博客
HBase Memstore配置. 本文为翻译,原英文地址:http://blog.sematext.com/2012/07/16/hbase-memstore-what-you-should-know/.     当regionserver(以下简称RS)收到一个写请求,会将这个请求定位到某个特定的region.

hbase原理

- - CSDN博客云计算推荐文章
1.hbase利用hdfs作为其文件存储系统,利用mapreduce来处理数据,利用zookeeper作为协调工具. 2.行键(row key),类似于主键,但row key是表自带的. 3.列族(column family) ,列(也称作标签/修饰符)的集合,定义表的时候指定的,列是在插入记录的时候动态增加的.

hbase锁机制

- - 数据库 - ITeye博客
博文说明:1、研究版本hbase0.94.12;2、贴出的源代码可能会有删减,只保留关键的代码.   hbase的锁是采用jdk的ReentrantReadWriteLock类实现.   一、HRegion有两种锁:lock、updatesLock,这两种锁均是ReentrantReadWriteLock类的实例,基本上所有的region操作均需要获取lock的read共享锁,在获取了lock的read锁后,如果是增加或者删除等影响数据内容的操作则还需要获取updatesLock的read锁.

Hbase入门

- - CSDN博客云计算推荐文章
Hbase 全称是Hadoop DataBase ,是一种开源的,可伸缩的,高可靠,高性能,面向列的分布式存储系统. 类似于Google的BigTable,其分布式计算采用MapReduce,通过MapReduce完成大块数据加载和全表扫描操作. 文件存储系统是HDFS,通过Zookeeper来完成状态管理协同服务.

[原]HBase StoreFile Compaction

- - 芒果先生Mango的专栏
Store File的合并策略比较复杂,涉及多个参数,合并策略的好坏,直接影响HBase的读写性能. 发现这篇博文:http://blog.csdn.net/azhao_dn/article/details/8867036 对Compaction描述的言简意赅:. hbase为了防止小文件(被刷到磁盘的menstore)过多,以保证保证查询效率,hbase需要在必要的时候将这些小的store file合并成相对较大的store file,这个过程就称之为compaction.

hbase的调优

- - CSDN博客推荐文章
1.1 Pre-Creating Regions 默认情况下,在创建HBase表的时候会自动创建一个region分区,当导入数据的时候,所有的HBase客户端都向这一个region写数据,直到这个region足够大了才进行切分. 一种可以加快批量写入速度的方法是通过预先创建一些空的regions,这样当数据写入HBase时,会按照region分区情况,在集群内做数据的负载均衡.