Hbase优化之预分区

Aaron 发表了文章 • 0 个评论 • 158 次浏览 • 2018-07-03 12:32 • 来自相关话题

    如果在hbase shell中使用create建表时只写了表名和列族名,那么这张表将只有一个region ,当一个region的大小超过阈值时会自动split成两个,但split操作会带来资源消耗。region个数太少时,在数据量大、访问量大,或被批处理程序读写情况下性能可能会很差,并且伴随大批量读写而来的GC可能会使regionserver宕机,接着region被transit到其他节点上,将逐步拖垮Hbase集群上的所有节点。

    所以推荐在建表时进行预分区,充分考虑rowkey的分布做出合理的预分区方案。要考虑的点包括region的个数、region的大小等。
 
region的个数

    如果使用MapReduce读取Hbase表数据,Map的个数等于该表region的个数,每个region都会有一个单独进程来处理,这个进程会逐条处理region中的每一行数据。举例来说如果只有一个region,那么读取数据的就只有一个进程;如果拆成10个数据均匀分布的region,那么10个map会带来10倍的效率提升。

    大数据量情况下越发需要并行处理,因此我们往往希望源表的region的个数多一些。但是同时也要考虑集群的承载能力,Hbase的region个数上限可以参考官网给出的如下公式,其中RS Xmx是regionserver的内存堆栈大小,官网建议每台20~24或更小,因为过大的内存会导致GC时间过长(GC方式从CMS改为G1后可以增大该值,机器内存足够的情况下可以翻倍甚至更大)。

((RS Xmx) *hbase.regionserver.global.memstore.size) / (hbase.hregion.memstore.flush.size *(# column families))。

    即24G*0.45/128M=86.4个,在实际使用中很容易超过这个值。另外官网建议每个RS 20~200个regions是比较合理的。因此region个数也不是越多越好,还要考虑集群情况。我们可以在Hbase WebUI上看到这个值。







    对于不需要用MR批量读Hbase表,相比需要MR读的表region个数可以少一些,以此来控制regionserver上region总数。
 
region的大小

    单个region最大大小官方推荐5~10GB,这是三备份前的数据大小,通过hbase.hregion.max.filesize配置,当超过这个值后region会split,估计好数据量并合理的划分region会减少不必要的性能损失。甚至设置足够大的值,日常监控中发现过大后手工做split。
 
预分区的方法

    预建region可以在shell中或者程序中实现,网上很多文章,如下是一些例子,不再赘述。要想清楚rowkey的边界,比如对于全部都是数字开头的rowkey,分200个region,边界就是000,005,010……995。

hbase> create 't1', 'f1', SPLITS => ['10', '20', '30', '40']  

hbase> create 't1', 'f1', SPLITS_FILE => 'splits.txt'

hbase> create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'} private void createTable() { HBaseAdmin admin = null; String tableName="NewTable"; String columnFamilyName="cf"; try { Configuration conf = HBaseConfiguration.create(); admin = new HBaseAdmin(conf); TableName tableNameV = TableName.valueOf(tableName); if (admin.tableExists(tableNameV)) { System.out.println("Table " + tableName + " already exist."); return; } HTableDescriptor tableDesc = new HTableDescriptor(tableNameV); HColumnDescriptor columnDesc = new HColumnDescriptor(columnFamilyName); tableDesc.addFamily(columnDesc); admin.createTable(tableDesc, splits()); System.out.println("Created table : " + tableName + " successfully."); } catch (Exception e) { System.out.println("Failed create table " + tableName+ e.toString()); } } private static byte splits() {}
  查看全部
    如果在hbase shell中使用create建表时只写了表名和列族名,那么这张表将只有一个region ,当一个region的大小超过阈值时会自动split成两个,但split操作会带来资源消耗。region个数太少时,在数据量大、访问量大,或被批处理程序读写情况下性能可能会很差,并且伴随大批量读写而来的GC可能会使regionserver宕机,接着region被transit到其他节点上,将逐步拖垮Hbase集群上的所有节点。

    所以推荐在建表时进行预分区,充分考虑rowkey的分布做出合理的预分区方案。要考虑的点包括region的个数、region的大小等。
 
  • region的个数


    如果使用MapReduce读取Hbase表数据,Map的个数等于该表region的个数,每个region都会有一个单独进程来处理,这个进程会逐条处理region中的每一行数据。举例来说如果只有一个region,那么读取数据的就只有一个进程;如果拆成10个数据均匀分布的region,那么10个map会带来10倍的效率提升。

    大数据量情况下越发需要并行处理,因此我们往往希望源表的region的个数多一些。但是同时也要考虑集群的承载能力,Hbase的region个数上限可以参考官网给出的如下公式,其中RS Xmx是regionserver的内存堆栈大小,官网建议每台20~24或更小,因为过大的内存会导致GC时间过长(GC方式从CMS改为G1后可以增大该值,机器内存足够的情况下可以翻倍甚至更大)。

((RS Xmx) *hbase.regionserver.global.memstore.size) / (hbase.hregion.memstore.flush.size *(# column families))。

    即24G*0.45/128M=86.4个,在实际使用中很容易超过这个值。另外官网建议每个RS 20~200个regions是比较合理的。因此region个数也不是越多越好,还要考虑集群情况。我们可以在Hbase WebUI上看到这个值。


20180626092151769.png


    对于不需要用MR批量读Hbase表,相比需要MR读的表region个数可以少一些,以此来控制regionserver上region总数。
 
  • region的大小


    单个region最大大小官方推荐5~10GB,这是三备份前的数据大小,通过hbase.hregion.max.filesize配置,当超过这个值后region会split,估计好数据量并合理的划分region会减少不必要的性能损失。甚至设置足够大的值,日常监控中发现过大后手工做split。
 
  • 预分区的方法


    预建region可以在shell中或者程序中实现,网上很多文章,如下是一些例子,不再赘述。要想清楚rowkey的边界,比如对于全部都是数字开头的rowkey,分200个region,边界就是000,005,010……995。

hbase> create 't1', 'f1', SPLITS => ['10', '20', '30', '40']  

hbase> create 't1', 'f1', SPLITS_FILE => 'splits.txt'

hbase> create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'} private void createTable() { HBaseAdmin admin = null; String tableName="NewTable"; String columnFamilyName="cf"; try { Configuration conf = HBaseConfiguration.create(); admin = new HBaseAdmin(conf); TableName tableNameV = TableName.valueOf(tableName); if (admin.tableExists(tableNameV)) { System.out.println("Table " + tableName + " already exist."); return; } HTableDescriptor tableDesc = new HTableDescriptor(tableNameV); HColumnDescriptor columnDesc = new HColumnDescriptor(columnFamilyName); tableDesc.addFamily(columnDesc); admin.createTable(tableDesc, splits()); System.out.println("Created table : " + tableName + " successfully."); } catch (Exception e) { System.out.println("Failed create table " + tableName+ e.toString()); } } private static byte splits() {}
 

HBaseConWest2018演讲 - HBase Practice In XiaoMi

openinx 发表了文章 • 0 个评论 • 208 次浏览 • 2018-06-19 09:33 • 来自相关话题

HBaseConWest2018 于6.18日在美国加州圣何塞举办,本次会议由Hortonworks承办。每年去美国硅谷参加HBaseConWest已经算是小米HBase团队的惯例了,一方面小米团队在HBase社区的影响力有目共睹,目前已经培养了7位HBase Committer,其中有2位HBase PMC;另外一方面,小米内部也很乐意对外去分享公司一年所做的工作,相当于把一年的工作(包括内部的实践以及社区贡献)做一个年度总结分享给大家。 
 
所以,2018年我们也很积极的提交了演讲议题(HBase Practice In XiaoMi),并花了很多精力整理总结,内部还做过3次英文试讲。但遗憾的是,今年中美关系比较紧张,美国签证没有如期办下来。按照组内历年的经验,一般提前一个月左右办理签证,能很顺利办下来。今年我们在5.14日去大使馆面试申请签证,被要求填写补充材料,在5.16拿到承办方的visa letter并提交补充材料之后,一直到现在签证尚未发放。本想没办法去现场的话,就只能把我们这个议题提交到8.17日的HBaseConAsia去讲。写邮件跟组委会沟通,组委会之前把我们talk的优先级放的比较高,也比较喜欢我们演讲内容,所以后面就想让我们做一个远程分享。为了以防万一设备异常之类的,就先让我们准备一个视频,有任何异常的话,直接放视频也不慌。于是,我们就录了一个,发现视频效果还行(主要是可以做剪辑,哈哈),就跟组委会说,现场干脆直接用视频好了,有任何疑问的话,远程答疑就好。 
 
于是,最后在HBaseConWest2018上看到的就是以下PPT和视频了。演讲内容主要分两部分,第一部分小米内部实践,由我的同事田竞云来分享,第二部分复制功能改进,由我来分享。 
 
1. PPT 
2. 视频地址 
 
总体来说,没有机会去HBaseConWest2018现场分享这个事情,个人还是挺遗憾的。之前Hortonworks的Ted Yu和Pinterest的TianYing获知我们要去美国分享,都很积极的约了我们聚会,最后也只能取消。原定的去美国一些其他行程,也只得取消。有一点值得欣慰的是,在组委会和我们的共同努力下,总算是有机会把小米过去一年做的一些工作整理并呈现给大家,包括美国HBase社区的朋友们。感谢组委会和社区,也感谢铎神和小豪在试讲中提出的很多宝贵建议。
  查看全部

HBaseConWest2018 于6.18日在美国加州圣何塞举办,本次会议由Hortonworks承办。每年去美国硅谷参加HBaseConWest已经算是小米HBase团队的惯例了,一方面小米团队在HBase社区的影响力有目共睹,目前已经培养了7位HBase Committer,其中有2位HBase PMC;另外一方面,小米内部也很乐意对外去分享公司一年所做的工作,相当于把一年的工作(包括内部的实践以及社区贡献)做一个年度总结分享给大家。 
 
所以,2018年我们也很积极的提交了演讲议题(HBase Practice In XiaoMi),并花了很多精力整理总结,内部还做过3次英文试讲。但遗憾的是,今年中美关系比较紧张,美国签证没有如期办下来。按照组内历年的经验,一般提前一个月左右办理签证,能很顺利办下来。今年我们在5.14日去大使馆面试申请签证,被要求填写补充材料,在5.16拿到承办方的visa letter并提交补充材料之后,一直到现在签证尚未发放。本想没办法去现场的话,就只能把我们这个议题提交到8.17日的HBaseConAsia去讲。写邮件跟组委会沟通,组委会之前把我们talk的优先级放的比较高,也比较喜欢我们演讲内容,所以后面就想让我们做一个远程分享。为了以防万一设备异常之类的,就先让我们准备一个视频,有任何异常的话,直接放视频也不慌。于是,我们就录了一个,发现视频效果还行(主要是可以做剪辑,哈哈),就跟组委会说,现场干脆直接用视频好了,有任何疑问的话,远程答疑就好。 
 
于是,最后在HBaseConWest2018上看到的就是以下PPT和视频了。演讲内容主要分两部分,第一部分小米内部实践,由我的同事田竞云来分享,第二部分复制功能改进,由我来分享。 
 
1. PPT 
2. 视频地址 
 
总体来说,没有机会去HBaseConWest2018现场分享这个事情,个人还是挺遗憾的。之前Hortonworks的Ted Yu和Pinterest的TianYing获知我们要去美国分享,都很积极的约了我们聚会,最后也只能取消。原定的去美国一些其他行程,也只得取消。有一点值得欣慰的是,在组委会和我们的共同努力下,总算是有机会把小米过去一年做的一些工作整理并呈现给大家,包括美国HBase社区的朋友们。感谢组委会和社区,也感谢铎神和小豪在试讲中提出的很多宝贵建议。
 

CFP: HBaseConAsia 2018演讲议题征集

openinx 发表了文章 • 0 个评论 • 152 次浏览 • 2018-06-15 10:16 • 来自相关话题

 
EasyChair Link: https://easychair.org/cfp/hbaseconasia-2018?track=215839 

HBaseCon是由HBase社区举办的活动。Apache HBase是Hadoop生态圈内的一个分布式数据库实现,提供了对大数据的实时随机读写能力。欢迎所有的HBase开发者,贡献者,运维人员还有普通使用者来HBaseCon分享你的观点,经验以及使用案例,互相学习,共同进步。

HBaseConAsia是在亚洲举办的HBaseCon。今年的会议将在中国北京举办,由阿里巴巴主办,参会者无须缴纳任何费用。

组委会期望的演讲主题包括但不限于案例分享,HBase的改进和开发,集群管理和运维方面的最佳实践以及对HBase未来的展望。我们欢迎任何可以帮助大家在生产环境中更好的使用HBase方面的主题,也欢迎基于HBase之上的一些有趣的开发、应用、云端/内部集群部署以及周边生态项目相关的主题。

我们希望演讲摘要和PPT使用英文,演讲语言可以使用中文或者英文。

接收演讲主题摘要的截止日期是2018年6月17号。2018年6月30号会公布演讲者名单。
 
议题
 
主要包括如下三个议题
开发及运维: 包括但不限于HBase源码开发(新特性,改进等)、线上运维和调优等主 生态和解决方案: 包括但不限于基于HBase之上构建的开源项目(OpenTSDB/GeoMesa/Kylin等)以及解决方案(云服务)等主 应用: 基于HBase构建的,云上或者自建机房环境中的应用案, 我们希望提交的议题中包含HBase相关的设计及问题解决,而不只是单纯的案例分享
 
项目委员会
 
李钰, 阿里巴巴 (Chair)沈春辉, 阿里巴巴张铎, 小米毕杰山, 华为蔡嘉平, 亦思科技Andrew Purtell, SalesforceAnoop Sam John, IntelMichael Stack, Cloudera
 
场地

中国,北京市朝阳区鼓楼外大街19号,北京歌华开元大酒店
 
联系我们

如果您遇到任何问题,或者有意向成为赞助商,请发邮件给liyu@apache.org
 
  查看全部
 
EasyChair Link: https://easychair.org/cfp/hbaseconasia-2018?track=215839 

HBaseCon是由HBase社区举办的活动。Apache HBase是Hadoop生态圈内的一个分布式数据库实现,提供了对大数据的实时随机读写能力。欢迎所有的HBase开发者,贡献者,运维人员还有普通使用者来HBaseCon分享你的观点,经验以及使用案例,互相学习,共同进步。

HBaseConAsia是在亚洲举办的HBaseCon。今年的会议将在中国北京举办,由阿里巴巴主办,参会者无须缴纳任何费用。

组委会期望的演讲主题包括但不限于案例分享,HBase的改进和开发,集群管理和运维方面的最佳实践以及对HBase未来的展望。我们欢迎任何可以帮助大家在生产环境中更好的使用HBase方面的主题,也欢迎基于HBase之上的一些有趣的开发、应用、云端/内部集群部署以及周边生态项目相关的主题。

我们希望演讲摘要和PPT使用英文,演讲语言可以使用中文或者英文。

接收演讲主题摘要的截止日期是2018年6月17号。2018年6月30号会公布演讲者名单。
 
议题
 
主要包括如下三个议题
  • 开发及运维: 包括但不限于HBase源码开发(新特性,改进等)、线上运维和调优等主 
  • 生态和解决方案: 包括但不限于基于HBase之上构建的开源项目(OpenTSDB/GeoMesa/Kylin等)以及解决方案(云服务)等主 
  • 应用: 基于HBase构建的,云上或者自建机房环境中的应用案, 我们希望提交的议题中包含HBase相关的设计及问题解决,而不只是单纯的案例分享

 
项目委员会
 
  • 李钰, 阿里巴巴 (Chair)
  • 沈春辉, 阿里巴巴
  • 张铎, 小米
  • 毕杰山, 华为
  • 蔡嘉平, 亦思科技
  • Andrew Purtell, Salesforce
  • Anoop Sam John, Intel
  • Michael Stack, Cloudera

 
场地

中国,北京市朝阳区鼓楼外大街19号,北京歌华开元大酒店
 
联系我们

如果您遇到任何问题,或者有意向成为赞助商,请发邮件给liyu@apache.org
 
 

社区活动:阿里云在北京主办中国第一届HBase Meetup

openinx 发表了文章 • 0 个评论 • 185 次浏览 • 2018-06-06 10:41 • 来自相关话题

转载自:http://hbase.group/?/article/16 
 

 6月6日,由中国HBase技术社区组织,阿里云主办的中国第一届HBase Meetup将在北京举行,来自阿里、小米、滴滴、360等公司的各位大神会共同探讨HBase2.0的技术革新,HBase在国内各个大型企业内的应用价值,并一起见证中国HBase技术社区成立仪式的历史时刻。主办方阿里云将在线直播此次meetup,对于不能去现场的小伙伴可以收藏此网址,在6月6号下午14:00观看直播。中国HBase技术社区第一届MeetUp: https://promotion.aliyun.com/n ... .html
 
HBase Meetup亮点

共同见证中国HBase技术社区成立
HBase大佬,神秘嘉宾亮相寄语
多位HBase committer为您深度解读HBase2.0

名企HBase负责人讲述典型业务应用 

直播议程安排
2018.06.06
14:00-14:30 | 议程:云数据库HBase2.0产品发布
所在 阿里云HBase高级产品专家
宣布阿里云云数据库HBase2.0版本发布,介绍云数据库HBase2.0版本基于社区版本做的改进以及重点企业级功能介绍。

14:30-15:00 | 议程:HBase2.0研讨圆桌会

HBase Committers&各公司HBase负责人
出席嘉宾(排名不分次序): 
 
陈恒(HBase Committer,蚂蚁金服); 
曹龙(阿里云HBase负责人); 
胡争(HBase Committer,小米); 
罗李(研究员, 滴滴); 
李钰(HBase PMC, 阿里); 
杨文龙(HBase Committer, 阿里) ; 
杨哲(HBase Committer, 小马智行); 
沈春辉(HBase PMC, 阿里); 
王锋(奇虎360大数据负责人); 
姚靖怡(滴滴HBase负责人); 
张铎(HBase PMC, 小米); 
张洸豪(HBase PMC, 小米)。

15:00-15:10 | 议程:中国HBase技术社区成立及招募仪式

阿里云、滴滴、小米等社区发起者
宣布中国HBase技术社区正式成立,并进行成员招募
15:10-15:40 | 议程:HBase 3.0的发展规划
张铎 HBase PMC 小米HBase负责人
展望HBase3.0的规划及技术革新给业务场景带来的价值

15:40-16:10 | 议程:滴滴HBase应用与实践

姚靖怡 滴滴HBase负责人
讲述HBase在滴滴实际业务中的应用

16:10-17:00 | 议程:当HBase遇上云的思考

封神 阿里云HBase负责人详解阿里云HBase基于社区版本的改进及企业级功能解决的用户痛点
 
中国HBase技术社区招募

为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,由HBase项目负责人Stack授权,阿里云发起,滴滴、小米等公司的HBase技术研究人员共同组建了中国HBase技术社区(CHTC:Chinese HBase Technical Community),旨在成为中国最有影响力的HBase技术社区,社区已经试运行2个月,现正式对广大HBase爱好者开放招募,加入中国HBase用户会,您将获得:

获取HBase最新技术迭代信息以及权威解读
参加社区不定期组织的 线下meetup,拓展合作机会
与各路技术大牛共同探讨 学习HBase
为HBase的发展提出您的 意见,推动技术进步 
加入中国HBase技术社区

HBase是一个分布式的面向列的开源数据库,是大数据生态圈中非常重要的一环,主要应用在大数据量(PB级)存储及超大规模(千万级QPS)随机读写访问。为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,阿里巴巴、小米、华为、网易、京东、滴滴、知乎等公司的HBase技术研究人员共同发起了组建HBase技术社区。我们非常欢迎对HBase有技术激情的同学一起加入探讨HBase技术,如果你热爱写技术博客,欢迎加入我们,一起坚持创作写出高质量的内容。加入中国HBase技术社区请点击链接:
 
https://mp.weixin.qq.com/s/3XNu-cbDuhy7y6gARjFSzw 查看全部
转载自:http://hbase.group/?/article/16 
 

 6月6日,由中国HBase技术社区组织,阿里云主办的中国第一届HBase Meetup将在北京举行,来自阿里、小米、滴滴、360等公司的各位大神会共同探讨HBase2.0的技术革新,HBase在国内各个大型企业内的应用价值,并一起见证中国HBase技术社区成立仪式的历史时刻。主办方阿里云将在线直播此次meetup,对于不能去现场的小伙伴可以收藏此网址,在6月6号下午14:00观看直播。中国HBase技术社区第一届MeetUp: https://promotion.aliyun.com/n ... .html
 
HBase Meetup亮点

共同见证中国HBase技术社区成立
HBase大佬,神秘嘉宾亮相寄语
多位HBase committer为您深度解读HBase2.0

名企HBase负责人讲述典型业务应用 

直播议程安排
2018.06.06
14:00-14:30 | 议程:云数据库HBase2.0产品发布
所在 阿里云HBase高级产品专家
宣布阿里云云数据库HBase2.0版本发布,介绍云数据库HBase2.0版本基于社区版本做的改进以及重点企业级功能介绍。

14:30-15:00 | 议程:HBase2.0研讨圆桌会

HBase Committers&各公司HBase负责人
出席嘉宾(排名不分次序): 
 
陈恒(HBase Committer,蚂蚁金服); 
曹龙(阿里云HBase负责人); 
胡争(HBase Committer,小米); 
罗李(研究员, 滴滴); 
李钰(HBase PMC, 阿里); 
杨文龙(HBase Committer, 阿里) ; 
杨哲(HBase Committer, 小马智行); 
沈春辉(HBase PMC, 阿里); 
王锋(奇虎360大数据负责人); 
姚靖怡(滴滴HBase负责人); 
张铎(HBase PMC, 小米); 
张洸豪(HBase PMC, 小米)。

15:00-15:10 | 议程:中国HBase技术社区成立及招募仪式

阿里云、滴滴、小米等社区发起者
宣布中国HBase技术社区正式成立,并进行成员招募
15:10-15:40 | 议程:HBase 3.0的发展规划
张铎 HBase PMC 小米HBase负责人
展望HBase3.0的规划及技术革新给业务场景带来的价值

15:40-16:10 | 议程:滴滴HBase应用与实践

姚靖怡 滴滴HBase负责人
讲述HBase在滴滴实际业务中的应用

16:10-17:00 | 议程:当HBase遇上云的思考

封神 阿里云HBase负责人详解阿里云HBase基于社区版本的改进及企业级功能解决的用户痛点
 
中国HBase技术社区招募

为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,由HBase项目负责人Stack授权,阿里云发起,滴滴、小米等公司的HBase技术研究人员共同组建了中国HBase技术社区(CHTC:Chinese HBase Technical Community),旨在成为中国最有影响力的HBase技术社区,社区已经试运行2个月,现正式对广大HBase爱好者开放招募,加入中国HBase用户会,您将获得:

获取HBase最新技术迭代信息以及权威解读
参加社区不定期组织的 线下meetup,拓展合作机会
与各路技术大牛共同探讨 学习HBase
为HBase的发展提出您的 意见,推动技术进步 
加入中国HBase技术社区

HBase是一个分布式的面向列的开源数据库,是大数据生态圈中非常重要的一环,主要应用在大数据量(PB级)存储及超大规模(千万级QPS)随机读写访问。为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,阿里巴巴、小米、华为、网易、京东、滴滴、知乎等公司的HBase技术研究人员共同发起了组建HBase技术社区。我们非常欢迎对HBase有技术激情的同学一起加入探讨HBase技术,如果你热爱写技术博客,欢迎加入我们,一起坚持创作写出高质量的内容。加入中国HBase技术社区请点击链接:
 
https://mp.weixin.qq.com/s/3XNu-cbDuhy7y6gARjFSzw

恭喜Francis Liu当选为HBase PMC成员

openinx 发表了文章 • 0 个评论 • 294 次浏览 • 2018-04-12 14:28 • 来自相关话题

恭喜Francis Liu当选为HBase PMC成员

Francis Liu对社区的核心贡献有:
1. 实现RSGroup功能[1];
2. 当前branch-1.3分支的Release Manager; 

恭喜! 

On behalf of the Apache HBase PMC I am pleased to announce that Francis
Liu has accepted our invitation to become a PMC member on the Apache
HBase project. We appreciate Francis stepping up to take more
responsibility in the HBase project. He has been an active contributor to
HBase for many years and recently took over responsibilities as branch RM
for branch-1.3.

Please join me in welcoming Francis to the HBase PMC!

1. https://issues.apache.org/jira/browse/HBASE-6721 查看全部
恭喜Francis Liu当选为HBase PMC成员

Francis Liu对社区的核心贡献有:
1. 实现RSGroup功能[1];
2. 当前branch-1.3分支的Release Manager

恭喜! 

On behalf of the Apache HBase PMC I am pleased to announce that Francis
Liu has accepted our invitation to become a PMC member on the Apache
HBase project. We appreciate Francis stepping up to take more
responsibility in the HBase project. He has been an active contributor to
HBase for many years and recently took over responsibilities as branch RM
for branch-1.3
.

Please join me in welcoming Francis to the HBase PMC!

1. https://issues.apache.org/jira/browse/HBASE-6721

HBaseCon West 2018将于6月18日在美国加州圣何塞举办

openinx 发表了文章 • 0 个评论 • 289 次浏览 • 2018-04-10 15:06 • 来自相关话题

今年的HBaseCon 2018将于6.18日美国加州圣何塞举办,提交议题摘要的截止时间是4月16日,如果有兴趣参加的朋友,一定要在2018年4月16日之前把议题摘要写好,提交到指定地址[1].
 
今年的HBaseCon2018[2]和PhoenixCon2018[3]将在同一地点举行,到时候去大会分享完之后,还可以去听听HBaseCon和PhoenixCon的分享,机会比较难得.
 
另外,已经确定HBaseConAsia2018 将于8月17日在中国北京举行,会议由阿里巴巴,华为,小米共同赞助.阿里巴巴李钰(Yu Li,同时也是HBase社区的PMC成员)将负责协调会议举办.
 
In addition, the second annual HBaseCon Asia is being held in Beijing,
China, on Aug. 17, 2018. The event will be sponsored by Alibaba, Huawei,
and Xiaomi. Admission will be free to attendees. Thanks to Yu Li for
coordinating the event.

1. https://easychair.org/conferences/?conf=hbasecon2018​ 
2. https://hbase.apache.org/hbasecon-2018/​ 
3. https://dataworkssummit.com/san-jose-2018/ 查看全部
今年的HBaseCon 2018将于6.18日美国加州圣何塞举办,提交议题摘要的截止时间是4月16日,如果有兴趣参加的朋友,一定要在2018年4月16日之前把议题摘要写好,提交到指定地址[1].
 
今年的HBaseCon2018[2]和PhoenixCon2018[3]将在同一地点举行,到时候去大会分享完之后,还可以去听听HBaseCon和PhoenixCon的分享,机会比较难得.
 
另外,已经确定HBaseConAsia2018 将于8月17日在中国北京举行,会议由阿里巴巴,华为,小米共同赞助.阿里巴巴李钰(Yu Li,同时也是HBase社区的PMC成员)将负责协调会议举办.
 
In addition, the second annual HBaseCon Asia is being held in Beijing,
China, on Aug. 17, 2018. The event will be sponsored by Alibaba, Huawei,
and Xiaomi. Admission will be free to attendees. Thanks to Yu Li for
coordinating the event.

1. https://easychair.org/conferences/?conf=hbasecon2018​ 
2. https://hbase.apache.org/hbasecon-2018/​ 
3. https://dataworkssummit.com/san-jose-2018/

YCSB压测HBase经验分享

liuzq 发表了文章 • 1 个评论 • 615 次浏览 • 2017-10-11 15:33 • 来自相关话题

写这篇文章之前首先要感谢我们的群主范欣欣范神,感谢范神在我压测过程中给予的指导,可惜的是由于机器比较紧张的缘故,还没来得及优化,机器就被回收走了,使得最终测出来的集群性能并不是很好,所以最终测试的结果大家只是最低标准的一个参考吧。

1.    YCSB介绍:
YCSB,全称为“Yahoo!Cloud Serving Benchmark”。是雅虎开发的用来对云服务进行基础测试的工具,其内部涵盖了常见的NoSQL数据库产品,如Cassandra、MongoDB、HBase、Redis等等。在运行YCSB的时候,可以配置不同的workload和DB,也可以指定线程数&并发数等其他参数。
2.    YCSB版本选择
当前最新版本0.13.0但是需要自己打包编译,从网上查到的资料说需要修改pom文件中的HBase版本,因为我们的HBase用的是HBase 1.2.0-cdh5.8.3的,由于不清楚HBase所依赖的hadoop的版本没找到需要在哪里修改,担心会对测试有影响,故放弃了0.13.0的版本,最终采用0.12.0,网上有说为了解决版本的问题,需要把$HBASE_HOME/lib目录下的所有文件拷贝到$YCSB_HOME/hbase10-binding/lib中,我不确定这一操作是否是必须的,我没有把$HBASE_HOME/lib目录下的所有文件拷贝到$YCSB_HOME/hbase10-binding/lib中在运行的过程中并没有报错,(所以大家自行选择吧)当然如果有人对此有较好的见解欢迎补充。0.12.0下载地址:https://github.com/brianfrankc ... ar.gz
注:如果有人使用过0.13.0的,希望还可以提供些指导意见
3.    YCSB使用操作
(1)下载YCSB客户端
curl -0 --location https://github.com/brianfrankc ... ar.gz
(2)解压YCSB
tar xfvz ycsb-hbase10-binding-0.12.0.tar.gz
(3)进入YCSB客户端
cd ycsb-hbase10-binding-0.12.0
(4)YCSB文件介绍
YCSB自带有6中workload配置文件,,分别为在workloads目录下的workloada、workloadb、workloadc、workloadd、workloade、workloadf,每个文件对应用于模拟不同的压力场景:
workloada:混合了50%的读和50%的写;
workloadb:Read mostly workload,混合了95%的读和5%的写,该workload侧重于测试集群的读能力;
workloadc:Read only,100%只读
workloadd:Read latest workload,插入数据,接着就读取这些新插入的数据
workloade:Short ranges,短范围scan,不同于随机读,每个测试线程都会去scan一段数据
workloadf:Read-modiy-wirte,读改写,客户端读出一个记录,修改它并将被修改的记录返回
可根据需要自行设置每个文件里的Recordcount以及operationcount:在加载(load)阶段插入表中的记录数或在运行(run)阶段之前已经在表中记录的数目,recordcount=1000;
在运行阶段所进行的操作数,operationcount=1000
注:具体参数的意义大家可以参考workload_template文件里的说明
(5)运行YCSB客户端
YCSB提供了一些参数,供用户指定,主要用到的如下参数:
-threads n 指定用于测试的客户端线程数
-s  打印状态信息到终端
-P指明了所用的配置文件的路径;
-p 可以显示修改YCSB内置的默认配置,例如使用 -p recordcount=1000000来覆盖之前说过的workloada中默认的recordcount=1000
注:在指定线程数时应使用-threads n而不是-p threads=n
1) 创建测试数据表
使用hbase shell命令创建测试数据表usertable,列簇family
n_splits = 200
create 'usertable', 'family', {SPLITS => (1..n_splits).map {|i| "user#{1000+i*(9999-1000)/n_splits}"}}
2) 将hbase配置文件拷贝到ycsb中
在$YCSB_HOME/ ycsb-hbase10-binding-0.12.0中新建conf目录,并将$HBASE_HOME/conf/hbase-site.xml 拷贝到$YCSB_HOME/ ycsb-hbase10-binding-0.12.0 /conf/中或者直接在运行的命令行里指定
3) 加载数据
nohup python bin/ycsb load hbase10 -P workloads/workload_init -cp $HBASE_HOME/conf/ -p table=usertable -p columnfamily=family -p insertstart=0 -threads 500 -s > load_workload_init_500.txt 2>&1  &
注:这里我用了nohup,大家可自行选择是否使用nohup运行,我没有把hbase-site.xml拷贝到ycsb相应的目录下,而是在运行命令是指定的。workload_init是我自行创建的用于数据初始化的文件。大家在加载数据的时候注意表名和列簇名是否与创建的测试数据表一致。




注:上述的输出结果中主要包括了处理请求的总时间(Runtime),请求的吞吐量(Throughput),表示每秒钟可处理的请求个数,平均延时(AverageLatency),单位是us,95%的操作延时和99%的操作延时,单位都是us。此外还包括了GC相关的一些metrics。关于前面的CLEANUP和INSERT,这里做个说明,insert代表的是用于压测的客户端发往集群的请求,所以insert标示的metrics代表了对集群性能的真实度量,而cleanup表示的是客户端的一些现场清理工作,比如每个客户端线程在读写完hbase之后,都需要断开到zk的连接等等,所以CLEANUP标示的metrics不需要过多关注
4) 执行测试
nohup python bin/ycsb run  hbase10 -P workloads/workloada -cp $HBASE_HOME /conf -p table=usertable -p columnfamily=family -threads 10 -s >run_workloada_10.txt  2>&1 &
4.    测试环境
本次测试中,测试环境为2+4(2个master,4个regionserver),生成数据的YCSB程序与HBase集群并不运行在相同的物理集群。
服务器硬件配置




软件版本信息




5.    测试结果
(1)单条记录插入
1)测试参数
总记录数为10亿,分为200个region,均匀分布在4台region server上;插入操作执行2千万次;插入请求分布遵从zipfian分布;
2)测试结果




(2)单纯查询
1) 测试参数
总记录数为10亿,分为200个region,均匀分布在4台region server上;查询操作执行2千万次;查询请求分布遵从zipfian分布;
2) 测试结果




(3)查询插入平衡
1) 测试参数
总记录数为10亿,分为200个region,均匀分布在4台region server上;查询插入操作共执行2千万次;查询请求分布遵从zipfian分布;
2) 测试结果




(4) Range扫描查询
1) 测试参数
总记录数为10亿,分为200个region,均匀分布在4台region server上;scan操作执行两百万次,请求分布遵从zipfian分布; scan最大长度为1000条记录, scan长度随机分布且遵从uniform分布;
2) 测试结果




  查看全部
写这篇文章之前首先要感谢我们的群主范欣欣范神,感谢范神在我压测过程中给予的指导,可惜的是由于机器比较紧张的缘故,还没来得及优化,机器就被回收走了,使得最终测出来的集群性能并不是很好,所以最终测试的结果大家只是最低标准的一个参考吧。

1.    YCSB介绍:
YCSB,全称为“Yahoo!Cloud Serving Benchmark”。是雅虎开发的用来对云服务进行基础测试的工具,其内部涵盖了常见的NoSQL数据库产品,如Cassandra、MongoDB、HBase、Redis等等。在运行YCSB的时候,可以配置不同的workload和DB,也可以指定线程数&并发数等其他参数。
2.    YCSB版本选择
当前最新版本0.13.0但是需要自己打包编译,从网上查到的资料说需要修改pom文件中的HBase版本,因为我们的HBase用的是HBase 1.2.0-cdh5.8.3的,由于不清楚HBase所依赖的hadoop的版本没找到需要在哪里修改,担心会对测试有影响,故放弃了0.13.0的版本,最终采用0.12.0,网上有说为了解决版本的问题,需要把$HBASE_HOME/lib目录下的所有文件拷贝到$YCSB_HOME/hbase10-binding/lib中,我不确定这一操作是否是必须的,我没有把$HBASE_HOME/lib目录下的所有文件拷贝到$YCSB_HOME/hbase10-binding/lib中在运行的过程中并没有报错,(所以大家自行选择吧)当然如果有人对此有较好的见解欢迎补充。0.12.0下载地址:https://github.com/brianfrankc ... ar.gz
注:如果有人使用过0.13.0的,希望还可以提供些指导意见
3.    YCSB使用操作
(1)下载YCSB客户端
curl -0 --location https://github.com/brianfrankc ... ar.gz
(2)解压YCSB
tar xfvz ycsb-hbase10-binding-0.12.0.tar.gz
(3)进入YCSB客户端
cd ycsb-hbase10-binding-0.12.0
(4)YCSB文件介绍
YCSB自带有6中workload配置文件,,分别为在workloads目录下的workloada、workloadb、workloadc、workloadd、workloade、workloadf,每个文件对应用于模拟不同的压力场景:
workloada:混合了50%的读和50%的写;
workloadb:Read mostly workload,混合了95%的读和5%的写,该workload侧重于测试集群的读能力;
workloadc:Read only,100%只读
workloadd:Read latest workload,插入数据,接着就读取这些新插入的数据
workloade:Short ranges,短范围scan,不同于随机读,每个测试线程都会去scan一段数据
workloadf:Read-modiy-wirte,读改写,客户端读出一个记录,修改它并将被修改的记录返回
可根据需要自行设置每个文件里的Recordcount以及operationcount:在加载(load)阶段插入表中的记录数或在运行(run)阶段之前已经在表中记录的数目,recordcount=1000;
在运行阶段所进行的操作数,operationcount=1000
注:具体参数的意义大家可以参考workload_template文件里的说明
(5)运行YCSB客户端
YCSB提供了一些参数,供用户指定,主要用到的如下参数:
-threads n 指定用于测试的客户端线程数
-s  打印状态信息到终端
-P指明了所用的配置文件的路径;
-p 可以显示修改YCSB内置的默认配置,例如使用 -p recordcount=1000000来覆盖之前说过的workloada中默认的recordcount=1000
注:在指定线程数时应使用-threads n而不是-p threads=n
1) 创建测试数据表
使用hbase shell命令创建测试数据表usertable,列簇family
n_splits = 200
create 'usertable', 'family', {SPLITS => (1..n_splits).map {|i| "user#{1000+i*(9999-1000)/n_splits}"}}
2) 将hbase配置文件拷贝到ycsb中
在$YCSB_HOME/ ycsb-hbase10-binding-0.12.0中新建conf目录,并将$HBASE_HOME/conf/hbase-site.xml 拷贝到$YCSB_HOME/ ycsb-hbase10-binding-0.12.0 /conf/中或者直接在运行的命令行里指定
3) 加载数据
nohup python bin/ycsb load hbase10 -P workloads/workload_init -cp $HBASE_HOME/conf/ -p table=usertable -p columnfamily=family -p insertstart=0 -threads 500 -s > load_workload_init_500.txt 2>&1  &
注:这里我用了nohup,大家可自行选择是否使用nohup运行,我没有把hbase-site.xml拷贝到ycsb相应的目录下,而是在运行命令是指定的。workload_init是我自行创建的用于数据初始化的文件。大家在加载数据的时候注意表名和列簇名是否与创建的测试数据表一致。
压测输出样例.png

注:上述的输出结果中主要包括了处理请求的总时间(Runtime),请求的吞吐量(Throughput),表示每秒钟可处理的请求个数,平均延时(AverageLatency),单位是us,95%的操作延时和99%的操作延时,单位都是us。此外还包括了GC相关的一些metrics。关于前面的CLEANUP和INSERT,这里做个说明,insert代表的是用于压测的客户端发往集群的请求,所以insert标示的metrics代表了对集群性能的真实度量,而cleanup表示的是客户端的一些现场清理工作,比如每个客户端线程在读写完hbase之后,都需要断开到zk的连接等等,所以CLEANUP标示的metrics不需要过多关注
4) 执行测试
nohup python bin/ycsb run  hbase10 -P workloads/workloada -cp $HBASE_HOME /conf -p table=usertable -p columnfamily=family -threads 10 -s >run_workloada_10.txt  2>&1 &
4.    测试环境
本次测试中,测试环境为2+4(2个master,4个regionserver),生成数据的YCSB程序与HBase集群并不运行在相同的物理集群。
服务器硬件配置
服务器硬件配置.png

软件版本信息
软件版本信息.png

5.    测试结果
(1)单条记录插入
1)测试参数
总记录数为10亿,分为200个region,均匀分布在4台region server上;插入操作执行2千万次;插入请求分布遵从zipfian分布;
2)测试结果
insert.png

(2)单纯查询
1) 测试参数
总记录数为10亿,分为200个region,均匀分布在4台region server上;查询操作执行2千万次;查询请求分布遵从zipfian分布;
2) 测试结果
read.png

(3)查询插入平衡
1) 测试参数
总记录数为10亿,分为200个region,均匀分布在4台region server上;查询插入操作共执行2千万次;查询请求分布遵从zipfian分布;
2) 测试结果
readAndInsert.png

(4) Range扫描查询
1) 测试参数
总记录数为10亿,分为200个region,均匀分布在4台region server上;scan操作执行两百万次,请求分布遵从zipfian分布; scan最大长度为1000条记录, scan长度随机分布且遵从uniform分布;
2) 测试结果
scan.png

 

DataBlock压缩类型

SuperbDong 发表了文章 • 0 个评论 • 209 次浏览 • 2017-09-16 22:32 • 来自相关话题

1.prefix

HBase中的prefix_tree

2.diff

diff与prefix一样,先会和前一条KV进行全面的比较,而不重复写入相同的信息,因为同一个block肯定隶属于同一个cf,所以cf也只写入一次
具体结构:
flag(1bytes)
           bit 0,若1,Key长度相同
           bit 1,若1,Value长度相同
           bit 2,若1,type相同 
           bit 3,若1,则写入的timestamp是差值 
           bit 4~6,表示数字0-7,代表timestamp或差值的字节数 
           bit 7,若1,timestamp或差值取相反数(如timestamp差值为负,则写入绝对值,因为绝对值较小)
新key长度(与上一条key长度不一致,一致则忽略)(1~5 bytes)(7-bit encoding) 新key长度(与上一条value长度不一致,一致则忽略)(1~5 bytes)(7-bit encoding)与上一条key(不含timestamp和type)相同部分的长度(1~5 bytes)(7-bit encoding)剩余key内容(不含timestamp和type)
          cf信息(如果为block第一条KV)
          col信息
timestamp或同上一条timestamp差值(取二者最小值)(1-8 bytes)type(若与上一条相同则忽略)(1 bytes)value信息

3.fast_diff

fast_diff与prefix一样,只是做了细微的调整,降低了压缩量,同时提高了压缩速度降低了系统资源的消耗
具体结构:
flag(1bytes)           
           bit 0~2,表示数字0-7,代表timestamp字节数 
           bit 3,若1,key长度相同
           bit 4,若1,value长度相同 
           bit 5,若1,type相同
           bit 6,若1,value内容相同
           bit 7,无
新key长度(与上一条key长度不一致,一致则忽略)(1~5 bytes)(7-bit encoding)新value长度(与上一条value长度不一致,一致则忽略)(1~5 bytes)(7-bit encoding)与上一条key(不含timestamp和type)相同部分的长度(1~5 bytes)(7-bit encoding)剩余key内容(不含timestamp和type)     
          cf信息(如果为block第一条KV)
          col信息
timestamp(1-8 bytes)type(若与上一条相同则忽略)(1 bytes)value信息(若与上一条相同则忽略)
           查看全部
  • 1.prefix


HBase中的prefix_tree


  • 2.diff


diff与prefix一样,先会和前一条KV进行全面的比较,而不重复写入相同的信息,因为同一个block肯定隶属于同一个cf,所以cf也只写入一次
具体结构:

  • flag(1bytes)

           bit 0,若1,Key长度相同
           bit 1,若1,Value长度相同
           bit 2,若1,type相同 
           bit 3,若1,则写入的timestamp是差值 
           bit 4~6,表示数字0-7,代表timestamp或差值的字节数 
           bit 7,若1,timestamp或差值取相反数(如timestamp差值为负,则写入绝对值,因为绝对值较小)
  • 新key长度(与上一条key长度不一致,一致则忽略)(1~5 bytes)(7-bit encoding) 
  • 新key长度(与上一条value长度不一致,一致则忽略)(1~5 bytes)(7-bit encoding)
  • 与上一条key(不含timestamp和type)相同部分的长度(1~5 bytes)(7-bit encoding)
  • 剩余key内容(不含timestamp和type)

          cf信息(如果为block第一条KV)
          col信息
  • timestamp或同上一条timestamp差值(取二者最小值)(1-8 bytes)
  • type(若与上一条相同则忽略)(1 bytes)
  • value信息


  • 3.fast_diff


fast_diff与prefix一样,只是做了细微的调整,降低了压缩量,同时提高了压缩速度降低了系统资源的消耗
具体结构:

  • flag(1bytes)           

           bit 0~2,表示数字0-7,代表timestamp字节数 
           bit 3,若1,key长度相同
           bit 4,若1,value长度相同 
           bit 5,若1,type相同
           bit 6,若1,value内容相同
           bit 7,无
  • 新key长度(与上一条key长度不一致,一致则忽略)(1~5 bytes)(7-bit encoding)
  • 新value长度(与上一条value长度不一致,一致则忽略)(1~5 bytes)(7-bit encoding)
  • 与上一条key(不含timestamp和type)相同部分的长度(1~5 bytes)(7-bit encoding)
  • 剩余key内容(不含timestamp和type)     

          cf信息(如果为block第一条KV)
          col信息
  • timestamp(1-8 bytes)
  • type(若与上一条相同则忽略)(1 bytes)
  • value信息(若与上一条相同则忽略)

          


HBase中的prefix_tree

SuperbDong 发表了文章 • 0 个评论 • 422 次浏览 • 2017-09-14 01:10 • 来自相关话题

HBase中引进了两个数据层的压缩DataBlock compression和HLog compression
DataBlock compression
DataBlock compression是针对HFile V2中的DataBlock进行压缩,优点是可以节省磁盘开销,弊端是如果block中KV过多的话会导致系统开销比较大,同时有些场景的压缩后占用空间更大。
原理:
①使用前缀
向Block写入数据时,如果不是第一条数据会同前一条数据KEY(Key=Row+Family+Qualifier+Timestamp+Type)进行比较,同上一条数据相同的部分则不再写入(Byte)
 
结构:
 
HFIleV2未压缩结构:
KeyLength(4 bytes)ValueLength(4 bytes)RowLength(2 bytes)RowColumnFamilyLength(1 bytes)ColumnFamily+Columntimestamp(8 bytes)type(1 bytes)
 
HFileV2压缩结构:
KeyLength(1~5 bytes)(7-bit encoding) ValueLength(1~5 bytes) (7-bit encoding) 同上个Key相同部分长度,(1~5 bytes) (7-bit encoding) 除相同前缀部分,剩余的Key Value

最坏情况会比原数据增加3B(7-bit会增加1B,3次会增加3B)

注:7-bit encoding
a、将int数据转换成32位
b、写入前八位
c、如果还有下八位则写入1,否则写入0结束(压缩为1B)
d、重复上述过程 查看全部
HBase中引进了两个数据层的压缩DataBlock compression和HLog compression
DataBlock compression
DataBlock compression是针对HFile V2中的DataBlock进行压缩,优点是可以节省磁盘开销,弊端是如果block中KV过多的话会导致系统开销比较大,同时有些场景的压缩后占用空间更大。
原理:
①使用前缀
向Block写入数据时,如果不是第一条数据会同前一条数据KEY(Key=Row+Family+Qualifier+Timestamp+Type)进行比较,同上一条数据相同的部分则不再写入(Byte)
 
结构:
 
HFIleV2未压缩结构:
  • KeyLength(4 bytes)
  • ValueLength(4 bytes)
  • RowLength(2 bytes)
  • Row
  • ColumnFamilyLength(1 bytes)
  • ColumnFamily+Column
  • timestamp(8 bytes)
  • type(1 bytes)

 
HFileV2压缩结构:
  • KeyLength(1~5 bytes)(7-bit encoding) 
  • ValueLength(1~5 bytes) (7-bit encoding) 
  • 同上个Key相同部分长度,(1~5 bytes) (7-bit encoding) 
  • 除相同前缀部分,剩余的Key 
  • Value


最坏情况会比原数据增加3B(7-bit会增加1B,3次会增加3B)

注:7-bit encoding
a、将int数据转换成32位
b、写入前八位
c、如果还有下八位则写入1,否则写入0结束(压缩为1B)
d、重复上述过程

HBaseConAsia2017 PPT解读(上)

openinx 发表了文章 • 1 个评论 • 364 次浏览 • 2017-08-22 23:13 • 来自相关话题

主会场的两个Talk

HBase-2.0.0 by Michael Stack
Stack是HBase的Team Leader,分享了HBase2.0.0分支的一些最新进展。对于最新的HBase2.0分支,HBase1.x 的客户端是能正常访问HBase2.0服务端的,但是admin是无法访问的(coprocessor也需要做相关更新)。HBase2.0解决了超过4400个issue,只能使用jdk8运行,要求hadoop至少在2.7.1版本之上。
核心功能包括:AssignManagerV2可以支持更多的region,更快启动(状态持久化在hdfs上,而不是zk),不再需要hbck。读写路径offheap。in-memory compaction,新的异步客户端。
其他功能包括:  MOB/rsgroup/wal和hfile存储到不同的文件系统/c/s通信接入netty框架。
目前正在搞的一些issue主要有:C++客户端/HBase备份恢复/混合逻辑时钟等等。
 
HBase Practice At XiaoMi  by huzheng
作为本次会议主会场的两个session之一,小米分享了他们在异步客户端和g1gc调优所做的一些工作。

同步客户端存在两个问题,一个是单线程场景下需要阻塞等待上一个返回值,吞吐不及异步客户端,另一个问题就是存在故障放大的问题,简单来说就是业务的多个handler同时访问hbase的一个卡住的regionserver的时候,业务的这部分handler都会卡住,业务的可用性要比hbase的可用性低很多。而异步客户端没有上述两个问题,这是它的优势。小米对asyn hbase client做的性能测试显示,在latency方面异步客户端至少不比同步客户端差。

小米分享的另外一个话题是HBase+G1GC调优。G1GC相比CMS的优势在于,通过多次增量的mixed gc分摊式的回收老年代对象,从而有能力完全避免掉full gc的发生,所有G1能提供稳定的延迟和吞吐,对可用性要求很高的HBase业务比较友好。另外,G1是采用增量式GC,而CMS每次gc都要扫整个堆,所以G1更加适合大堆场景。  后续,小米给出了他们如何调G1的一个案例,感兴趣的同学可以跟着测试一下。 查看全部
主会场的两个Talk

HBase-2.0.0 by Michael Stack
Stack是HBase的Team Leader,分享了HBase2.0.0分支的一些最新进展。对于最新的HBase2.0分支,HBase1.x 的客户端是能正常访问HBase2.0服务端的,但是admin是无法访问的(coprocessor也需要做相关更新)。HBase2.0解决了超过4400个issue,只能使用jdk8运行,要求hadoop至少在2.7.1版本之上。
核心功能包括:AssignManagerV2可以支持更多的region,更快启动(状态持久化在hdfs上,而不是zk),不再需要hbck。读写路径offheap。in-memory compaction,新的异步客户端。
其他功能包括:  MOB/rsgroup/wal和hfile存储到不同的文件系统/c/s通信接入netty框架。
目前正在搞的一些issue主要有:C++客户端/HBase备份恢复/混合逻辑时钟等等。
 
HBase Practice At XiaoMi  by huzheng
作为本次会议主会场的两个session之一,小米分享了他们在异步客户端和g1gc调优所做的一些工作。

同步客户端存在两个问题,一个是单线程场景下需要阻塞等待上一个返回值,吞吐不及异步客户端,另一个问题就是存在故障放大的问题,简单来说就是业务的多个handler同时访问hbase的一个卡住的regionserver的时候,业务的这部分handler都会卡住,业务的可用性要比hbase的可用性低很多。而异步客户端没有上述两个问题,这是它的优势。小米对asyn hbase client做的性能测试显示,在latency方面异步客户端至少不比同步客户端差。

小米分享的另外一个话题是HBase+G1GC调优。G1GC相比CMS的优势在于,通过多次增量的mixed gc分摊式的回收老年代对象,从而有能力完全避免掉full gc的发生,所有G1能提供稳定的延迟和吞吐,对可用性要求很高的HBase业务比较友好。另外,G1是采用增量式GC,而CMS每次gc都要扫整个堆,所以G1更加适合大堆场景。  后续,小米给出了他们如何调G1的一个案例,感兴趣的同学可以跟着测试一下。