Hbase优化之预分区

Aaron 发表了文章 • 0 个评论 • 264 次浏览 • 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 个评论 • 296 次浏览 • 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 个评论 • 239 次浏览 • 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 个评论 • 257 次浏览 • 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 个评论 • 396 次浏览 • 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 个评论 • 373 次浏览 • 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/

DataBlock压缩类型

SuperbDong 发表了文章 • 0 个评论 • 243 次浏览 • 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 个评论 • 481 次浏览 • 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 发表了文章 • 0 个评论 • 512 次浏览 • 2017-08-14 10:06 • 来自相关话题

作者: 范欣欣  http://hbasefly.com

接上文: HBaseConAsia2017 PPT解读(上)

 HBaseConAsia技术峰会在深圳坂田华为圆满结束,本人有幸作为分享嘉宾参与了峰会分享并与各位大佬一起探讨交流HBase的未来发展。据个人了解,HBase在国内各大技术公司的使用是很普遍的,包括BAT、小米、华为、网易、京东、携程、新浪、知乎等等吧,很多朋友也私底下表示后续还有很多业务在尝试着将大量历史数据搬到HBase上来。这在以前是不可想象的。HBase之前在国内的发展是比较低调的,大家很少能够在网上看到相关的系统性介绍,以至于生产线上出现了很多问题也不知道如何解决。这次大会第一次真正意义上将国际/国内研究HBase、使用HBase的同学聚到了一起,交流分享HBase在生产线上的应用场景、实践经验,探讨HBase在未来版本中的核心改进。在不远的将来,HBase还会以更加立体的姿态出现在大家面前,包括阿里云、华为云在内的国内云计算提供商都会在接下来重点提供HBase云服务,真正意义上为更多公司提供专业的HBase运维技术服务与支持。

这篇文章笔者会就峰会分会场track2内的多个talk进行一个简单的梳理,将核心内容整理出一个概要,对某个talk有兴趣的同学可以下载具体的PPT进行详细浏览:

HBase Synchronous Replication

阿里同学介绍了HBase在复制层面所作的一些工作,首先介绍了阿里内部针对HBase异步复制做的一些优化工作,包括并发复制、利用空闲计算资源减少复制热点、在线配置更改等。接着重点介绍了阿里在同步复制上做的工作,同步复制意味着在主集群发生宕机的情况下用户切换到从集群后能够保证数据不丢失。speaker提到阿里内部大部分业务都能够接受异步复制,但还有那么一小撮业务希望提供更加严格意义上的数据同步。同步复制主题主要从如下3个方面进行了说明:

1. 同步复制在技术上的实现思路:核心理念是在异步复制基础上在从集群上增加了一个remotelog,主集群在数据写入的时候不仅需要写入本地hlog,还需要将数据写入remotelog。接着讨论了remotelog的基本格式、删除时机等细节。

2. 探讨多种异常场景:
(1)主集群宕掉的情况下,首先禁用remotelog,再通过回放remotelog使得从集群的数据和主集群一致,最后将业务切到从集群。
(2)主集群宕掉起来之后,先禁掉主集群上的所有读写,不允许请求进来。开启remotelog,并等待从集群到主集群的异步复制延迟小于10s,此时禁掉从集群上的所有读写,不允许从集群上有读写发生。主集群等待从集群异步复制完成,完成之后将业务切到主集群并开启主集群读写能力。
(3)从集群宕掉的情况下,同步复制将会退化为异步复制。

3. 对比讨论同步复制技术与异步复制技术在性能、一致性、资源使用等方面的差异。总体来看,同步复制在实现主从数据严格一致的情况仅会导致写性能下降2%,不过带宽资源相比异步复制使用了两倍。

HBase: Recent Improvement And Practice At Alibaba
这个talk也来自alibaba,主要分三个部分对阿里内部使用HBase进行了介绍。第一部分介绍了HBase在阿里内部的典型使用场景,包括双十一大屏实时数据处理存储以及蚂蚁金服实时风控体系使用HBase进行在线查询以及离线存储等。
第二部分主要介绍了两个核心改进点,其一是基于主从异步复制的Data Range Copy,功能类似于CopyTable以及snapshot,主要用于机房搬迁、历史数据迁移等。不同于snapshot的是,完全分布式操作,不需要开启MR,用户可以指定range进行迁移。其二是Dual Service,基于主从异步复制实现降低读取延时毛刺,HBase一个很大的问题是因为GC、HDFS等原因不能充分保证99%读延迟,Dual Service会先让读请求落到主集群,如果在一定时间内没有返回再将请求发往从集群。通过这种方式,HBase读请求的毛刺率(延迟超过50ms的读请求占总请求比例)可以由0.047%降低到0.0017%
第三部分介绍了两个基于Phoenix的特性,其一是阿里内部对SQL的使用以及对Phoenix的部分改造,speaker首先讲解了Phoenix的架构以及Phoenix和原生HBase API的性能对比,结果显示Phoenix的性能相比HBase API差2~3倍,接着分析了性能损耗的几个原因以及针对性优化,比如将单个Scan做成并行Scan,改造完成之后Phoenix性能基本和原生HBase API性能相差不多。其二是介绍了基于Phoenix的全局索引,重点分享了全局索引的工作原理,以及索引在更新异常情况下引起的一致性问题以及两种可行的解决方案。

Ecosystems built with HBase and CloudTable service at Huawei

华为同学分三个主题介绍了基于HBase打造的大数据生态组件(CTBase、Tagram)以及CloudTable服务。
1. CTBase是基于HBase实现的一个结构化存储系统,支持强schema管理、全局索引、跨表join查询、在线DDL更新等核心特性。这个组件类似于MegaStore、Spanner、F1、Kudu等,满足结构化数据存储管理服务。后期将会在全文索引、OLAP以及双活集群等多个方向上有所探索。

2. Tagram是基于HBase实现的一个分布式bitmap索引,主要用于低基数字段的有效存储以及部分ad-hot查询支持。作者主要就Tagram的应用场景、框架设计、数据模型进行了深入分析介绍。并结合具体事例给出了如何使用Tagram对查询进行优化,最后还针对Tagram的性能给出了性能测试数据。

3. CloudTable是HBase在华为云上的一种包装,华为内部对HBase内核进行了大量的改造用来适应云上的环境,包括在HBase安全性、易维护性、低成本等各个方面都投入了很大的成本。作者首先介绍了CloudTable在硬件层面对IO进行的优化策略,接着介绍了如何将Compaction下压到HDFS层面以减小HBase层面的负载,最后分享了CloudTable如何使用replication实现4个9的高可用性

Large scale data near-line loading method and architecture
来自FiberHome的同学介绍了如何将读写在进程级别进行分离来优化集群中读写之间的相互影响。talk中提到因为HBase在读写路径中会共享很多资源,因此大吞吐量的数据写入会严重影响数据的读取性能,因此有必要将HBase的读写路径拆分成两个独立的进程。

talk中提到HBase读进程就是RegionServer进程,即用户读请求依然发送给RegionServer进程。并将写请求发送给一个称为WriterServer的进程,这个进程是对RegionServer进程的一定改造,主要是瘦身,将很多不必要的功能进行了裁剪。WriteServer主要负责批量数据写入,并将数据写成HFile文件之后通知RegionServer进程使用bulkload进行加载,供用户读取。因此整个过程有一定的读延迟。

HBase在hulu的使用和实践
该talk主要介绍了HBase在hulu内部的使用和实践情况。hulu内部HBase集群规模在200台左右,数据规模在700TB。主要使用场景为用户画像系统、日志存储系统、订单信息存储系统以及OpenTSDB等。第二部分speaker主要介绍了hulu内部两种核心使用场景下使用HBase的经验。第一种场景是用户画像系统,介绍了HBase在用户画像系统中扮演的核心作用以及在使用过程中遇到的RegionSize相关问题以及snapshot相关问题。第二种场景是订单信息存储系统,并介绍了订单存储系统中如何使用replication实现数据灾备、如何使用replica技术实现服务高可用,并对RPC QUEUE的实践设置经验进行分享。

HBase at JD

京东使用HBase无论是集群规模还是业务规模都是相当庞大的,根据分享数据,京东内部有30多个HBase集群,3000+台服务器,600多个业务,服务于很多非常有名的核心业务,比如订单系统、罗盘系统(商家、供应商)、个性化推荐系统、商品评论系统、金融白条、风控系统等等,可谓对HBase是重度依赖。
speaker分别对部分核心应用场景进行了比较细粒度的介绍,包括业务概括、存储数据量大小、业务表数量以及在线读写QPS等核心指标。接着就京东内部在使用HBase过程中一些核心的实践经验进行了分享,包括使用RSGroup实现业务之间的隔离、业务差异化配置管理、资源弹性管理,使用内部鉴权系统进一步保障HBase的安全性、使用Replication实现系统高可用、系统参数调优策略、监控报警运维实践、HBase版本升级实践等

Apache HBase At Netease

笔者主要介绍了网易内部使用HBase的一些实践经验,整体来说比较偏细节。首先笔者介绍了HBase在网易内部的使用规模,不得不说,HBase在网易内部的业务正处于急剧扩张期,包括考拉、云音乐在内的很多业务都不断的将很多在线业务迁移到HBase上来。第二部分笔者简单从Linux系统、Scheme设置、GC优化等多个层面就一些比较重要的调优点进行了分享,希望大家能够更好的使用HBase而少走弯路。接着分享了网易在RPC多队列管理、表级别Metrics管理以及倒排索引等几个方面所作的尝试。

Building Online HBase Cluster of Zhihu Based on Kubernetes
知乎同学分享了基于Kubernetes构建HBase集群的主题。使用Kubernete构建HBase这个方向在第二天的圆桌会议上也成为包括stack在内的各个PMC大佬比较关心的话题,可见必然是以后的一个发展重点。speaker首先对Kubernete进行了简单的介绍,接下来对如何使用Kubernete对HBase集群进行管理进行了详细的说明,包括容器的配置、RegionServer参数设置、网络设置等。最后分享了试用Kubernete管理HBase集群带来的有效收益:更容易的运维、更有效的隔离以及更简单的管理。 查看全部
作者: 范欣欣  http://hbasefly.com

接上文: HBaseConAsia2017 PPT解读(上)

 HBaseConAsia技术峰会在深圳坂田华为圆满结束,本人有幸作为分享嘉宾参与了峰会分享并与各位大佬一起探讨交流HBase的未来发展。据个人了解,HBase在国内各大技术公司的使用是很普遍的,包括BAT、小米、华为、网易、京东、携程、新浪、知乎等等吧,很多朋友也私底下表示后续还有很多业务在尝试着将大量历史数据搬到HBase上来。这在以前是不可想象的。HBase之前在国内的发展是比较低调的,大家很少能够在网上看到相关的系统性介绍,以至于生产线上出现了很多问题也不知道如何解决。这次大会第一次真正意义上将国际/国内研究HBase、使用HBase的同学聚到了一起,交流分享HBase在生产线上的应用场景、实践经验,探讨HBase在未来版本中的核心改进。在不远的将来,HBase还会以更加立体的姿态出现在大家面前,包括阿里云、华为云在内的国内云计算提供商都会在接下来重点提供HBase云服务,真正意义上为更多公司提供专业的HBase运维技术服务与支持。

这篇文章笔者会就峰会分会场track2内的多个talk进行一个简单的梳理,将核心内容整理出一个概要,对某个talk有兴趣的同学可以下载具体的PPT进行详细浏览:

HBase Synchronous Replication

阿里同学介绍了HBase在复制层面所作的一些工作,首先介绍了阿里内部针对HBase异步复制做的一些优化工作,包括并发复制、利用空闲计算资源减少复制热点、在线配置更改等。接着重点介绍了阿里在同步复制上做的工作,同步复制意味着在主集群发生宕机的情况下用户切换到从集群后能够保证数据不丢失。speaker提到阿里内部大部分业务都能够接受异步复制,但还有那么一小撮业务希望提供更加严格意义上的数据同步。同步复制主题主要从如下3个方面进行了说明:

1. 同步复制在技术上的实现思路:核心理念是在异步复制基础上在从集群上增加了一个remotelog,主集群在数据写入的时候不仅需要写入本地hlog,还需要将数据写入remotelog。接着讨论了remotelog的基本格式、删除时机等细节。

2. 探讨多种异常场景:
(1)主集群宕掉的情况下,首先禁用remotelog,再通过回放remotelog使得从集群的数据和主集群一致,最后将业务切到从集群。
(2)主集群宕掉起来之后,先禁掉主集群上的所有读写,不允许请求进来。开启remotelog,并等待从集群到主集群的异步复制延迟小于10s,此时禁掉从集群上的所有读写,不允许从集群上有读写发生。主集群等待从集群异步复制完成,完成之后将业务切到主集群并开启主集群读写能力。
(3)从集群宕掉的情况下,同步复制将会退化为异步复制。

3. 对比讨论同步复制技术与异步复制技术在性能、一致性、资源使用等方面的差异。总体来看,同步复制在实现主从数据严格一致的情况仅会导致写性能下降2%,不过带宽资源相比异步复制使用了两倍。

HBase: Recent Improvement And Practice At Alibaba
这个talk也来自alibaba,主要分三个部分对阿里内部使用HBase进行了介绍。第一部分介绍了HBase在阿里内部的典型使用场景,包括双十一大屏实时数据处理存储以及蚂蚁金服实时风控体系使用HBase进行在线查询以及离线存储等。
第二部分主要介绍了两个核心改进点,其一是基于主从异步复制的Data Range Copy,功能类似于CopyTable以及snapshot,主要用于机房搬迁、历史数据迁移等。不同于snapshot的是,完全分布式操作,不需要开启MR,用户可以指定range进行迁移。其二是Dual Service,基于主从异步复制实现降低读取延时毛刺,HBase一个很大的问题是因为GC、HDFS等原因不能充分保证99%读延迟,Dual Service会先让读请求落到主集群,如果在一定时间内没有返回再将请求发往从集群。通过这种方式,HBase读请求的毛刺率(延迟超过50ms的读请求占总请求比例)可以由0.047%降低到0.0017%
第三部分介绍了两个基于Phoenix的特性,其一是阿里内部对SQL的使用以及对Phoenix的部分改造,speaker首先讲解了Phoenix的架构以及Phoenix和原生HBase API的性能对比,结果显示Phoenix的性能相比HBase API差2~3倍,接着分析了性能损耗的几个原因以及针对性优化,比如将单个Scan做成并行Scan,改造完成之后Phoenix性能基本和原生HBase API性能相差不多。其二是介绍了基于Phoenix的全局索引,重点分享了全局索引的工作原理,以及索引在更新异常情况下引起的一致性问题以及两种可行的解决方案。

Ecosystems built with HBase and CloudTable service at Huawei

华为同学分三个主题介绍了基于HBase打造的大数据生态组件(CTBase、Tagram)以及CloudTable服务。
1. CTBase是基于HBase实现的一个结构化存储系统,支持强schema管理、全局索引、跨表join查询、在线DDL更新等核心特性。这个组件类似于MegaStore、Spanner、F1、Kudu等,满足结构化数据存储管理服务。后期将会在全文索引、OLAP以及双活集群等多个方向上有所探索。

2. Tagram是基于HBase实现的一个分布式bitmap索引,主要用于低基数字段的有效存储以及部分ad-hot查询支持。作者主要就Tagram的应用场景、框架设计、数据模型进行了深入分析介绍。并结合具体事例给出了如何使用Tagram对查询进行优化,最后还针对Tagram的性能给出了性能测试数据。

3. CloudTable是HBase在华为云上的一种包装,华为内部对HBase内核进行了大量的改造用来适应云上的环境,包括在HBase安全性、易维护性、低成本等各个方面都投入了很大的成本。作者首先介绍了CloudTable在硬件层面对IO进行的优化策略,接着介绍了如何将Compaction下压到HDFS层面以减小HBase层面的负载,最后分享了CloudTable如何使用replication实现4个9的高可用性

Large scale data near-line loading method and architecture
来自FiberHome的同学介绍了如何将读写在进程级别进行分离来优化集群中读写之间的相互影响。talk中提到因为HBase在读写路径中会共享很多资源,因此大吞吐量的数据写入会严重影响数据的读取性能,因此有必要将HBase的读写路径拆分成两个独立的进程。

talk中提到HBase读进程就是RegionServer进程,即用户读请求依然发送给RegionServer进程。并将写请求发送给一个称为WriterServer的进程,这个进程是对RegionServer进程的一定改造,主要是瘦身,将很多不必要的功能进行了裁剪。WriteServer主要负责批量数据写入,并将数据写成HFile文件之后通知RegionServer进程使用bulkload进行加载,供用户读取。因此整个过程有一定的读延迟。

HBase在hulu的使用和实践
该talk主要介绍了HBase在hulu内部的使用和实践情况。hulu内部HBase集群规模在200台左右,数据规模在700TB。主要使用场景为用户画像系统、日志存储系统、订单信息存储系统以及OpenTSDB等。第二部分speaker主要介绍了hulu内部两种核心使用场景下使用HBase的经验。第一种场景是用户画像系统,介绍了HBase在用户画像系统中扮演的核心作用以及在使用过程中遇到的RegionSize相关问题以及snapshot相关问题。第二种场景是订单信息存储系统,并介绍了订单存储系统中如何使用replication实现数据灾备、如何使用replica技术实现服务高可用,并对RPC QUEUE的实践设置经验进行分享。

HBase at JD

京东使用HBase无论是集群规模还是业务规模都是相当庞大的,根据分享数据,京东内部有30多个HBase集群,3000+台服务器,600多个业务,服务于很多非常有名的核心业务,比如订单系统、罗盘系统(商家、供应商)、个性化推荐系统、商品评论系统、金融白条、风控系统等等,可谓对HBase是重度依赖。
speaker分别对部分核心应用场景进行了比较细粒度的介绍,包括业务概括、存储数据量大小、业务表数量以及在线读写QPS等核心指标。接着就京东内部在使用HBase过程中一些核心的实践经验进行了分享,包括使用RSGroup实现业务之间的隔离、业务差异化配置管理、资源弹性管理,使用内部鉴权系统进一步保障HBase的安全性、使用Replication实现系统高可用、系统参数调优策略、监控报警运维实践、HBase版本升级实践等

Apache HBase At Netease

笔者主要介绍了网易内部使用HBase的一些实践经验,整体来说比较偏细节。首先笔者介绍了HBase在网易内部的使用规模,不得不说,HBase在网易内部的业务正处于急剧扩张期,包括考拉、云音乐在内的很多业务都不断的将很多在线业务迁移到HBase上来。第二部分笔者简单从Linux系统、Scheme设置、GC优化等多个层面就一些比较重要的调优点进行了分享,希望大家能够更好的使用HBase而少走弯路。接着分享了网易在RPC多队列管理、表级别Metrics管理以及倒排索引等几个方面所作的尝试。

Building Online HBase Cluster of Zhihu Based on Kubernetes
知乎同学分享了基于Kubernetes构建HBase集群的主题。使用Kubernete构建HBase这个方向在第二天的圆桌会议上也成为包括stack在内的各个PMC大佬比较关心的话题,可见必然是以后的一个发展重点。speaker首先对Kubernete进行了简单的介绍,接下来对如何使用Kubernete对HBase集群进行管理进行了详细的说明,包括容器的配置、RegionServer参数设置、网络设置等。最后分享了试用Kubernete管理HBase集群带来的有效收益:更容易的运维、更有效的隔离以及更简单的管理。

HBaseConAsia2017 资料分享

openinx 发表了文章 • 0 个评论 • 752 次浏览 • 2017-08-07 14:50 • 来自相关话题

 
首届HBaseConAsia在2017.8.4日深圳坂田华为举行,并取得圆满成功。在会议举行第二天,所有参加HBaseCon的speaker参加了在华为举行的圆桌会议,stack对会议内容做了详细的keynote[1]。关于本次会议,stack也在邮件中做了高度评价,并分享了一些照片。

这里整理了下会议相关的一些资料:
1. 大会的演讲PPT(初级版本) 链接: http://pan.baidu.com/s/1o7CSLHS 密码: fkmc
2. 大会的演讲PPT(现场版本) http://pan.baidu.com/s/1hs9rXoK

3. 大会演讲的录音资料 http://pan.baidu.com/s/1hrVwau4  密码:p9ct

参考资料
[1] https://mail-archives.apache.o ... %253E
[2] https://mail-archives.apache.o ... %253E
 
  查看全部
_YP99193.JPG

 
首届HBaseConAsia在2017.8.4日深圳坂田华为举行,并取得圆满成功。在会议举行第二天,所有参加HBaseCon的speaker参加了在华为举行的圆桌会议,stack对会议内容做了详细的keynote[1]。关于本次会议,stack也在邮件中做了高度评价,并分享了一些照片。

这里整理了下会议相关的一些资料:
1. 大会的演讲PPT(初级版本) 链接: http://pan.baidu.com/s/1o7CSLHS 密码: fkmc
2. 大会的演讲PPT(现场版本) http://pan.baidu.com/s/1hs9rXoK

3. 大会演讲的录音资料 http://pan.baidu.com/s/1hrVwau4  密码:p9ct

参考资料
[1] https://mail-archives.apache.o ... %253E
[2] https://mail-archives.apache.o ... %253E