HBase

HBase

hbase namespace ACL授权后仍然,无法create table

回复

有问必答paulsenzou 发起了问题 • 1 人关注 • 0 个回复 • 71 次浏览 • 2018-07-23 14:30 • 来自相关话题

hbase生产环境都适合哪些应用场景?

有问必答hmaster 回复了问题 • 3 人关注 • 3 个回复 • 567 次浏览 • 2018-07-13 23:56 • 来自相关话题

使用TableSnapshotInputFormat读取快照的过程中有用到TableSnapshotScanner么?

有问必答openinx 回复了问题 • 2 人关注 • 1 个回复 • 94 次浏览 • 2018-07-09 15:02 • 来自相关话题

请问hbase的0.94、0.98、1.0、1.2、2.0版本之间的区别是什么?

回复

有问必答bupt_lxc 发起了问题 • 1 人关注 • 0 个回复 • 115 次浏览 • 2018-07-07 16:56 • 来自相关话题

【融360招聘】大数据架构师

回复

招聘应聘xiangqiao 发起了问题 • 1 人关注 • 0 个回复 • 150 次浏览 • 2018-06-29 16:28 • 来自相关话题

HBaseConWest2018演讲 - HBase Practice In XiaoMi

文章分享openinx 发表了文章 • 0 个评论 • 199 次浏览 • 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 个评论 • 149 次浏览 • 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快照跨集群复制表经常失败

有问必答smartZY 回复了问题 • 2 人关注 • 1 个回复 • 117 次浏览 • 2018-06-14 16:29 • 来自相关话题

有没有好用的Hbase的Web查询客户端?

有问必答Aaron 回复了问题 • 2 人关注 • 2 个回复 • 149 次浏览 • 2018-06-14 09:56 • 来自相关话题

Hbase 的列有没有多少个的限制呢

有问必答Aaron 回复了问题 • 3 人关注 • 2 个回复 • 383 次浏览 • 2018-06-07 12:37 • 来自相关话题

条新动态, 点击查看
libis

libis 回答了问题 • 2017-06-07 20:30 • 3 个回复 不感兴趣

hbase生产环境都适合哪些应用场景?

赞同来自:

hbase目前有很多的应用场景可以使用,最常见的有消息存储类(facebook的messenger,网易的易信,米聊等),历史订单类(阿里等),推荐系统,实时流存储(阿里双11大屏等),监控数据存储,图数据库底层存储,kylin底层存储等等。目前在几乎所有互联... 显示全部 »
hbase目前有很多的应用场景可以使用,最常见的有消息存储类(facebook的messenger,网易的易信,米聊等),历史订单类(阿里等),推荐系统,实时流存储(阿里双11大屏等),监控数据存储,图数据库底层存储,kylin底层存储等等。目前在几乎所有互联网公司都有使用,比如阿里、小米、华为、腾讯、网易、京东等等。
libis

libis 回答了问题 • 2017-06-07 20:36 • 1 个回复 不感兴趣

HBase2.0发布的话, 会有哪些重磅功能 ?

赞同来自:

1. procv2 - 主要解决分布式ddl(建表)无法完成原子性操作、Assignment Manage中region状态一致性等,这个功能主要解决很多操作下出现的region状态不一致等问题
2. 异步接口功能
3. offheap更加强大,不仅可以降低g... 显示全部 »
1. procv2 - 主要解决分布式ddl(建表)无法完成原子性操作、Assignment Manage中region状态一致性等,这个功能主要解决很多操作下出现的region状态不一致等问题
2. 异步接口功能
3. offheap更加强大,不仅可以降低gc影响,而且对性能几乎没有影响。
4. rsgroup:可以让用户指定哪些表可以分布在哪些机器上,实现一定程度的资源隔离
5. mob:大数据存储不再成为问题(文件、图片等)
我们基本上是按照这个博客来的:  https://blogs.apache.org/hbase/entry/tuning_g1gc_for_your_hbase
 
在用CMS的时候,我们一般是在128G的机器上,部署4个RegionServer, 其中每个... 显示全部 »
我们基本上是按照这个博客来的:  https://blogs.apache.org/hbase/entry/tuning_g1gc_for_your_hbase
 
在用CMS的时候,我们一般是在128G的机器上,部署4个RegionServer, 其中每个RegionServer的堆内内存12G,堆外内存12G,所有RS的堆内堆外内存96G左右.
 
后面改成G1GC之后,同样是128G的机器上,部署1个RegionServer,其中每个RegionServer的堆内内存50G,堆外内存50G,算起来差不多100G.改成G1GC之后,把之前的4个RegionServer合成了1个大堆RegionServer,主要是之前CMS的方式老年代占用太多的情况下,full GC会非常耗时,所以,CMS GC其实不适合大堆进程,因此我们拆成4个进程.而对于G1GC来说,在大堆进程下,GC的延迟能够控制在一个给定的时间内,代价是轻微的降低吞吐(按照论文的说法是,吞吐降低5%~10%左右,这对于大部分情况是可以接受的),因此我们只需要启动一个RegionServer进程就好了.
改用G1GC之后,大部分的RegionServer的STW时间基本上能控制在150ms左右(Target Pause time=150ms),效果还是比较好的. 
 
G1GC的相关参数主要有: -XX:+UnlockExperimentalVMOptions
-XX:MaxGCPauseMillis={50/90/500} for SSD/HDD/offline cluster
-XX:G1NewSizePercent={2/5} for normal/heavy load cluster
-XX:InitiatingHeapOccupancyPercent=65
-XX:+ParallelRefProcEnabled
-XX:ConcGCThreads=4
-XX:ParallelGCThreads=16
-XX:MaxTenuringThreshold=1
-XX:G1HeapRegionSize=32m
-XX:G1MixedGCCountTarget=64
-XX:G1OldCSetRegionThresholdPercent=5

Update 再来说一下G1和CMS两种gc算法的一些具体的区别 .
 
1. G1相当于每次gc都在整理内存碎片(Evacuation Pause),而CMS在正常的old gen gc过程中,只是把dead object标记为内存清空,而不会整理碎片,除非是CMS发生了full gc. 因此CMS gc随着时间的推移,碎片可能会越来越多,如果这时候需要分配一块较大的内存,就可能会导致触发一次full gc用来整理碎片,进而导致一段不可预见的STW停顿.
2. G1算法有一个预设的TargetPauseTime, G1在每次执行gc时,会尝试选择一个region集合(Choose Region Set),使得这个region集合的gc卡顿时间不超过TargetPauseTime. 但这个TargetPauseTime并不是硬性指标,也就是说gc卡顿可能会超过TargetPauseTime.  这也是g1优于cms的地方,通过建立一个可评估的模型,通过这个模型来评估每次gc的时间,使之stw时间尽量控制在可控时间范围内.
3. G1和CMS一样都可能会导致full gc, 典型的场景就是内存的分配速度超过gc的速度,从而导致某次内存分配请求的内存超过了当前heap中连续的可分配内存数量. 在HBase场景下,可能就是存在某些KV,这些KV超过200M这种,这时候可能会导致g1出现频繁的full gc,而且每次full gc的耗时都比较长.这是很坑的情况,所以一般在配置g1的时候,都会尝试配置参数,让g1尽量避免发生full gc. 从另一种角度来说,就是让g1的old gen gc做的更加频繁一点,把old gen的内存占用控制在一个比例.
 
推荐两份参考资料:
1.  http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html
2.  https://www.researchgate.net/publication/221032945_Garbage-First_garbage_collection
 
1.1.3 版本,目前还算比较稳定,之前使用过1.0.0版本,不是很稳定
1.1.3 版本,目前还算比较稳定,之前使用过1.0.0版本,不是很稳定
openinx

openinx 回答了问题 • 2017-06-27 10:13 • 3 个回复 不感兴趣

对HBase而言,PREAD和STREAM有什么区别?

赞同来自:

具体到HBase代码中的 HFileBLock#readAtOffset 方法,可以比较好的说明PREAD和STREAM的区别.
[list=1]
[*]pread其实就是positional read, 每次都会发一个offset到datanode,让d... 显示全部 »
具体到HBase代码中的 HFileBLock#readAtOffset 方法,可以比较好的说明PREAD和STREAM的区别.
[list=1]
[*]pread其实就是positional read, 每次都会发一个offset到datanode,让datanode去seek到对应的位置,然后读取数据. 在同一个DFSInputStream上可以跑多个pread操作.pread适合的场景是小数据量的随机读,就是频率高且数据量小的操作,典型的例如 small scan操作 以及[i] 读取meta表定位rowKey所在region的操作 ,这些操作一般默认都用PREAD.
[*]stream其实是seek + read,就是发一个offset到datanode,然后就不需要你再发offset给datanode了,然后datanode依次吐数据给你.因此,同一个DFSInputStream上跑多个stream的话,吐出来的数据就乱了. stream更适合较大数据量的顺序scan操作 ,典型的场景例如业务扫表操作以及Compaction的扫表操作.

 
参考资料:https://issues.apache.org/jira/browse/HBASE-17917
openinx

openinx 回答了问题 • 2017-07-10 20:41 • 6 个回复 不感兴趣

regionserver发生full gc导致宕机

赞同来自:

Heap: 62.5G(64.0G)->60.2G(64.0G)  做了一次full gc之后,你的堆仍然使用了60G,说明你使用的内存本身就很多?
 
另外,你能否上传一份完整的gc.log到系统 ? (gc.log里面没有hbase的相关信息,应该... 显示全部 »
Heap: 62.5G(64.0G)->60.2G(64.0G)  做了一次full gc之后,你的堆仍然使用了60G,说明你使用的内存本身就很多?
 
另外,你能否上传一份完整的gc.log到系统 ? (gc.log里面没有hbase的相关信息,应该不会暴露公司隐私)
 
单看这一次full gc, 很难看出是什么问题...

【融360招聘】大数据架构师

回复

招聘应聘xiangqiao 发起了问题 • 1 人关注 • 0 个回复 • 150 次浏览 • 2018-06-29 16:28 • 来自相关话题

HBaseCon Asia 2017将于8月4日在深圳举办

文章分享openinx 发表了文章 • 0 个评论 • 639 次浏览 • 2017-06-07 19:44 • 来自相关话题

 
 HBaseCon Asia 2017大会报名已正式开放。HBaseCon Asia 2017是第一届在亚洲举办的HBase技术大会,大会将在中国深圳举办,华为是本次大会的主办方。

如果您想作为普通的参会者参加此会,欢迎您通过如下链接报名(本次大会无需任何门票费用):  http://hbaseconasia.eventbrite.com

如果您想成为演讲者,欢迎您通过如下链接申报您的演讲主题内容:  https://easychair.org/cfp/HBaseConAsia2017

会议细节:https://www.eventbrite.com/e/h ... 46159
 
会议安排如下:






  查看全部
hbasecon2015noyear.eps_.png

 
 HBaseCon Asia 2017大会报名已正式开放。HBaseCon Asia 2017是第一届在亚洲举办的HBase技术大会,大会将在中国深圳举办,华为是本次大会的主办方。

如果您想作为普通的参会者参加此会,欢迎您通过如下链接报名(本次大会无需任何门票费用):  http://hbaseconasia.eventbrite.com

如果您想成为演讲者,欢迎您通过如下链接申报您的演讲主题内容:  https://easychair.org/cfp/HBaseConAsia2017

会议细节:https://www.eventbrite.com/e/h ... 46159
 
会议安排如下:
hbasecon.png



 

hbase namespace ACL授权后仍然,无法create table

回复

有问必答paulsenzou 发起了问题 • 1 人关注 • 0 个回复 • 71 次浏览 • 2018-07-23 14:30 • 来自相关话题

hbase生产环境都适合哪些应用场景?

回复

有问必答hmaster 回复了问题 • 3 人关注 • 3 个回复 • 567 次浏览 • 2018-07-13 23:56 • 来自相关话题

使用TableSnapshotInputFormat读取快照的过程中有用到TableSnapshotScanner么?

回复

有问必答openinx 回复了问题 • 2 人关注 • 1 个回复 • 94 次浏览 • 2018-07-09 15:02 • 来自相关话题

请问hbase的0.94、0.98、1.0、1.2、2.0版本之间的区别是什么?

回复

有问必答bupt_lxc 发起了问题 • 1 人关注 • 0 个回复 • 115 次浏览 • 2018-07-07 16:56 • 来自相关话题

【融360招聘】大数据架构师

回复

招聘应聘xiangqiao 发起了问题 • 1 人关注 • 0 个回复 • 150 次浏览 • 2018-06-29 16:28 • 来自相关话题

使用hbase快照跨集群复制表经常失败

回复

有问必答smartZY 回复了问题 • 2 人关注 • 1 个回复 • 117 次浏览 • 2018-06-14 16:29 • 来自相关话题

有没有好用的Hbase的Web查询客户端?

回复

有问必答Aaron 回复了问题 • 2 人关注 • 2 个回复 • 149 次浏览 • 2018-06-14 09:56 • 来自相关话题

Hbase 的列有没有多少个的限制呢

回复

有问必答Aaron 回复了问题 • 3 人关注 • 2 个回复 • 383 次浏览 • 2018-06-07 12:37 • 来自相关话题

HBASE并发读阻塞

回复

有问必答Aaron 回复了问题 • 3 人关注 • 2 个回复 • 259 次浏览 • 2018-06-07 12:30 • 来自相关话题

HBase 有没有对业务影响最小的滚动重启方案?

回复

有问必答bean 回复了问题 • 3 人关注 • 2 个回复 • 230 次浏览 • 2018-05-29 10:00 • 来自相关话题

HBaseConWest2018演讲 - HBase Practice In XiaoMi

文章分享openinx 发表了文章 • 0 个评论 • 199 次浏览 • 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 个评论 • 149 次浏览 • 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
 
 

恭喜Francis Liu当选为HBase PMC成员

文章分享openinx 发表了文章 • 0 个评论 • 291 次浏览 • 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 个评论 • 285 次浏览 • 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/

HBaseConAsia2017 PPT解读(下)

文章分享openinx 发表了文章 • 0 个评论 • 442 次浏览 • 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 个评论 • 698 次浏览 • 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
 
 

HBase+G1GC性能调优

文章分享openinx 发表了文章 • 2 个评论 • 2281 次浏览 • 2017-07-18 10:04 • 来自相关话题

目前小米已经在线上开始大规模使用G1垃圾回收算法,在论坛中也看到一些朋友在讨论使用G1碰到的各种各样的问题,这里打算写一篇文章记录下调G1的一些经验.
 
先传送门一下,之前在HBaseConAsia2017分享过一个g1gc调优的ppt: http://openinx.github.io/2012/01/01/my-share/ 

首先,对G1算法不熟悉的同学,可以仔细读一读Oracle的G1算法教程,教程基本交代了G1的运行原理以及和CMS本质区别,如果对算法细节干兴趣,可以读一下Garbage-First Garbage Collection这篇论文,JVM的G1实现应该是按照这篇论文来的.
为了便于统计G1GC的日志信息,我们需要开启以下所有的G1参数:$(document).ready(function() {$('pre code').each(function(i, block) { hljs.highlightBlock( block); }); });-verbose:gc
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintHeapAtGC
-XX:+PrintGCDateStamps
-XX:+PrintAdaptiveSizePolicy
-XX:+PrintTenuringDistribution
-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=1
-XX:PrintFLSStatistics=1

 在阅读了Tuning G1GC For Your HBase Cluster 这篇官方博客之后,大致确定了以下G1初始参数(以下参数都只是初始值,具体哪个参数合适,还需要我们手动来调整具体每个参数,然后看G1GC的统计数据来分析):-Xmx30g -Xms30g
-XX:MaxDirectMemorySize=30g
-XX:+UseG1GC
-XX:+UnlockExperimentalVMOptions
-XX:MaxGCPauseMillis=90
-XX:G1NewSizePercent=8
-XX:InitiatingHeapOccupancyPercent=30
-XX:+ParallelRefProcEnabled
-XX:ConcGCThreads=4
-XX:ParallelGCThreads=16
-XX:MaxTenuringThreshold=1
-XX:G1HeapRegionSize=32m
-XX:G1MixedGCCountTarget=64
-XX:G1OldCSetRegionThresholdPercent=5
 
其中重点需要调优的参数主要有:
1. G1NewSizePercent :  G1的Young区大小是通过算法来自适应确定的, 也就是根据之前Young区GC的耗时来确定之后的Young大小,如果耗时过长,则调小Young区,耗时过短,则调大Young区. 这个参数表示Young的最小百分比.
2. InitiatingHeapOccupancyPercent: 当占用内存超过这个百分比的时候, G1开始执行多次Mixed GC来整理老年代内存碎片.
3. G1MixedGCCountTarget: 当占用内存超过InitiatingHeapOccupancyPercent阀值时, 最多通过多少次Mixed GC来将内存控制在阀值之下.
4. MaxTenuringThreshold: 当一个对象gc的代数超过这个值的时候, 会将对象从young区挪到old区.
5. G1HeapRegionSize: 表示G1将每个Region切分成多大, 注意一定要写单位, 例如32m.
 
 
由于每个参数的取值范围非常广, 例如G1NewSizePercent一般可以从0到10不等(甚至可以取更大), 而且参数众多. 于是, 我们写一个脚本用来修改每一个参数,然后自动重启, 并记录每个参数的测试开始时间点和结束时间点. 后面只需要通过工具自动分析gc日志即可. 这里, 脚本每次只会调整一个参数, 然后重启整个集群, 然后通过PerformanceEvaluation工具进行压力测试, 压力测试会跑一个小时,跑完之后调整下一个参数, 后续接着跑.
 
脚本地址在这里: https://github.com/openinx/scripts/blob/master/java-g1gc-tuning.py 
 
跑完所有的参数之后, 后续就需要通过工具来分析G1的日志了, 之前HubSpot开发了一个Python工具, 叫做gc_log_visualizer , 这个工具通过正则提取日志数据, 然后绘制成监控图, 比较方便查看G1的全局状态. 
  查看全部
目前小米已经在线上开始大规模使用G1垃圾回收算法,在论坛中也看到一些朋友在讨论使用G1碰到的各种各样的问题,这里打算写一篇文章记录下调G1的一些经验.
 
先传送门一下,之前在HBaseConAsia2017分享过一个g1gc调优的ppt: http://openinx.github.io/2012/01/01/my-share/ 

首先,对G1算法不熟悉的同学,可以仔细读一读Oracle的G1算法教程,教程基本交代了G1的运行原理以及和CMS本质区别,如果对算法细节干兴趣,可以读一下Garbage-First Garbage Collection这篇论文,JVM的G1实现应该是按照这篇论文来的.
为了便于统计G1GC的日志信息,我们需要开启以下所有的G1参数:
-verbose:gc
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintHeapAtGC
-XX:+PrintGCDateStamps
-XX:+PrintAdaptiveSizePolicy
-XX:+PrintTenuringDistribution
-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=1
-XX:PrintFLSStatistics=1

 在阅读了Tuning G1GC For Your HBase Cluster 这篇官方博客之后,大致确定了以下G1初始参数(以下参数都只是初始值,具体哪个参数合适,还需要我们手动来调整具体每个参数,然后看G1GC的统计数据来分析):
-Xmx30g -Xms30g 
-XX:MaxDirectMemorySize=30g
-XX:+UseG1GC
-XX:+UnlockExperimentalVMOptions
-XX:MaxGCPauseMillis=90
-XX:G1NewSizePercent=8
-XX:InitiatingHeapOccupancyPercent=30
-XX:+ParallelRefProcEnabled
-XX:ConcGCThreads=4
-XX:ParallelGCThreads=16
-XX:MaxTenuringThreshold=1
-XX:G1HeapRegionSize=32m
-XX:G1MixedGCCountTarget=64
-XX:G1OldCSetRegionThresholdPercent=5
 
其中重点需要调优的参数主要有:
1. G1NewSizePercent :  G1的Young区大小是通过算法来自适应确定的, 也就是根据之前Young区GC的耗时来确定之后的Young大小,如果耗时过长,则调小Young区,耗时过短,则调大Young区. 这个参数表示Young的最小百分比.
2. InitiatingHeapOccupancyPercent: 当占用内存超过这个百分比的时候, G1开始执行多次Mixed GC来整理老年代内存碎片.
3. G1MixedGCCountTarget: 当占用内存超过InitiatingHeapOccupancyPercent阀值时, 最多通过多少次Mixed GC来将内存控制在阀值之下.
4. MaxTenuringThreshold: 当一个对象gc的代数超过这个值的时候, 会将对象从young区挪到old区.
5. G1HeapRegionSize: 表示G1将每个Region切分成多大, 注意一定要写单位, 例如32m.
 
 
由于每个参数的取值范围非常广, 例如G1NewSizePercent一般可以从0到10不等(甚至可以取更大), 而且参数众多. 于是, 我们写一个脚本用来修改每一个参数,然后自动重启, 并记录每个参数的测试开始时间点和结束时间点. 后面只需要通过工具自动分析gc日志即可. 这里, 脚本每次只会调整一个参数, 然后重启整个集群, 然后通过PerformanceEvaluation工具进行压力测试, 压力测试会跑一个小时,跑完之后调整下一个参数, 后续接着跑.
 
脚本地址在这里: https://github.com/openinx/scripts/blob/master/java-g1gc-tuning.py 
 
跑完所有的参数之后, 后续就需要通过工具来分析G1的日志了, 之前HubSpot开发了一个Python工具, 叫做gc_log_visualizer , 这个工具通过正则提取日志数据, 然后绘制成监控图, 比较方便查看G1的全局状态. 
 

HBaseCon West 2017 PPT解读(下)

文章分享openinx 发表了文章 • 0 个评论 • 1268 次浏览 • 2017-07-01 16:52 • 来自相关话题

接着HBaseCon West 2017 PPT解读(上)继续后面的PPT解读
 
11. OpenTSDB: 2.4 and 3.0 update(by Yahoo)
作者是一位维护OpenTSDB近4年的程序员,干货比较多。OpenTSDB是一款基于HBase之上开发的时间序列数据库产品,能方便的实现水平扩展。具体到HBase的存储时,OpenTSDB设计的rowKey为rowKey=salt + metric + timestamp + tagk1 + tagv1… + tagkN + tagvN这样的rowKey设计,可以满足用户根据metric + ts + 若干个tag组合进行查询,用SQL来表达是select * from table where metric=? and ts < ? and ts > ? and (tag_i= ?) and (tag_j= ?)HBASE-15181 实现了DateTieredCompaction。DateTieredCompaction的策略是按照时间轴(一般待合并区间为[now - maxAge, now], 其中maxAge可配置) ,从新到旧划分时间区间,其中时间越新,划分时间区间长度越短,然后对时间轴内区间的多个文件做合并,落在对应区间的KeyValue被写入到对应区间的storeFile内,最终合并的结果是每个区间只有一个文件,这个文件只包含自己区间内的数据。这种策略的好处在于数据越新,compaction越频繁,数据越旧,compaction越少(甚至不compaction),这种策略非常适合OpenTSDB,因为OpenTSDB写入数据都是按照时间递增,而之前的老数据从不修改,因此推荐OpenTSDB下的HBase集群采用DateTieredCompaction策略。
 
另外,PPT中还提到很多其他的内容,例如AsyncHBase的进展,OpenTSDB3.0的规划,OpenTSDB2.4的其他新特性等等,这里不再展开细评, 感兴趣可以读读PPT。
 
参考资料:
1. https://labs.spotify.com/2014/12/18/date-tiered-compaction/
 
12. A study of Salesforce’s use of HBase and Phoenix ( by Salesforce )
主要介绍了Salesforce公司内部的HBase/Phoenix业务情况。
 
13. Cursors in Apache Phoenix (by bloomberg)
Bloomberg是一家研发NewSQL的数据库厂商,其核心产品是comdb2,目前已经在Github开源,其项目的介绍专门在VLDB2016上发了paper,感兴趣的同学可以读读。本次talk主要介绍他们是如何在phoenix上实现的关系型数据库中cursor功能。

14. Warp 10 - A novel approach for time series management and analysis based on HBase (by Herberts)
这个PPT主要应该是介绍他们的Wrap10项目。
 
15. Removable Singularity: A Story of HBaseUpgrade at Pinterest(by Pinterest)
Pinterest之前有40多个0.94版本的集群,他们面临着和小米一样的问题,就是需要把0.94版本的集群升级到1.2版本,而0.94版本HBase的rpc协议和1.2不兼容,前者是基于Writable接口的自定义协议,后者是Protobuf协议。解决问题的思路大致是一样的,就是先把快照数据通过ExportSnapshot导入1.2版本的HBase集群,再把增量数据通过thrift replication导入到新集群。后面需要考虑的问题就是业务如何实现在线切换。Pinterest比较有优势的一个地方就是,他们的业务使用的客户端是AsyncHBase1.7,而AsyncHBase1.7本身是支持0.94和1.2的,因此业务只需要修改访问HBase的集群地址就好。升级到1.2版本之后,无论是读性能还是写性能都有较好的提升。

16. Improving HBase availability in a multi-tenant environment (by Hubspot)
HBase在CAP中属于CP型的系统,可用性方面有一些缺陷,例如一个RegionServer宕机,Failover时长主要分3段,首先是故障检测的时间(<10s),然后是SplitLog的时间(20~40s),然后是最终RegionOnline的时间(10s~30s),数据取自Hubspot PPT。总体来讲,Failover时长优化空间较大。为此,Hubspot分享了一些提高HBase可用性的相关work:
a. 测试发现将大集群拆分成更多小实例能减少总体的failover时间。
b. 通过Normalizer控制Region的大小,使之均匀。
c. HBASE-17707和HBASE-18164优化StochasticLoadBalancer策略,使balance更合理,更高效。
d. 对每个用户消耗的RPC Handler做上限限制,社区版本貌似没这功能,应该是内部实现的。
e. 使用内部硬件检测工具提前发现硬件问题,并移走HBase服务。
 
17. Highly Available HBase (by Sift Science)
Sift Science是一家通过实时机器学习技术来防止商业诈骗的公司, Uber/Airbnb等都是他们的客户。由于他们的业务跟钱相关,对HBase可用性要求非常高。经过一些优化之后, 他们成功将HBase的宕机时间从5小时/月优化到4分钟/月。这些优化工作主要有:
1. 修改hbase-client代码,当client发现突然有较多请求失败时,client直接上抛DoNotRetryRegionException到上层,避免RS已经不可用时仍然被客户端大量请求导致大量handler被卡住,影响MTTR时间。
2. 搭建在线备份集群,同时修改client代码,发现主集群有问题, client可以直接借助zk自动切换到备份集群。 存在的问题是,备份集群数据可能落后主集群,切换可能数据不一致。PPT上只是说会通过离线任务去抽样校验,所以,我觉得对于两集群的一致性问题,要么牺牲一致性保可用性,要么牺牲可用性保一致性。
3. 加强监控,尤其是locality/balance状况/p99延迟这些,尽早发现问题并解决,而不是等出问题再解决。
 
18. Transactions in HBase (by cask.co)
这个talk应该是全场21个talk中干货最多的PPT之一,讨论的重点是基于HBase之上如何实现分布式事务。作者深入探讨了3种分布式事务模型,分别是Tephra/Trafodion/Omid,3个项目都是Apache下的孵化项目。这里,简单说一下我对这3种事务模型的理解:
a. Tephra: 该模型本质上是通过一个叫做Trx Manager的集中式服务用来维护当前活跃事务,该TrxManager用来分配事务start/commit/rollback逻辑时钟,每个事务开始时都会分配一个ts和一个叫做excludes={...}的集合,用来维护该事务开始前的活跃事务,这个excludes集合可用来做隔离性检查,也可用来做冲突检查。由于有一个较为重量级的集中式TrxManager,所以事务高并发场景下该模型压力会较大,因此该模型推荐的用来运行并发少的long-running MapReduce之类的事务Job。
b. Trafodion:  这个没太看懂和tephra的区别是啥。。ppt上看不太出来。
c. Omid: Apache Omid事务模型和Google Percolator事务模型是类似的,小米研发的Themis也是一样,本质上是借助HBase的行级别事务来实现跨行跨表事务。每个事务begin和commit/rollback都需要去TimeOracle拿到一个全局唯一递增的逻辑timestamp,然后为每一个column新增两个隐藏的column分别叫做lock和write,用来跟踪每次写入操作的锁以及逻辑timestamp,通过2PC实现跨行事务提交。对于读取的4个隔离级别(RS, RR, SI, RU),有了全局唯一递增的逻辑时钟之后,也就很容易决定哪些数据应该返回给用户。

参考资料
1. http://andremouche.github.io/t ... .html 
2. https://research.google.com/pubs/pub36726.html
3. https://github.com/xiaomi/themis
4. http://nosqlmark.informatik.un ... d.pdf

19. Achieving HBase Multi-Tenancy: RegionServer Groups and Favored Nodes 
这个talk介绍了Yahoos主导的两个重要feature:RegionServer Group和Favored Nodes。
1. RegionServer Group可以让指定表分布在某些RegionServer上,一定程度上实现了多租户之间的隔离,相比Hortonworks在微观层面对多租户所做出的努力(rpc队列分离、quota机制、请求优先级等),个人认为rsGroup在多租户管理方面效果可能更加明显。rsGroup是这次峰会比较明星的话题,包括滴滴等公司都作为主旨来介绍其在生产实践中的应用,可见已经被很多大厂所接受并实践,遗憾的是,该功能目前只在未发布的2.0.0里面包含,要想在当前版本中使用必须移植对应patch,因为功能的复杂性,这看起来并不是一件容易的事情。
2. Favored Nodes机制相对比较陌生,该功能允许HBase在region层面指定该region上所有文件分布在哪些DN之上,这个功能最大的好处是可以提升数据文件的本地率,试想,每个Region都知道文件存放的DN,迁移Region的时候就可以多考虑文件本地率进行迁移。
 
20. Community-Driven Graphs With JanusGraph
这个talk介绍了HBase应用的另一个重要领域-图数据库,图数据库在互联网业务中诸多方面(社交图谱分析、推荐分析)都有实际应用。比如大家可能比较熟悉的titan数据库就是一个典型的图数据库。而这个主题介绍的是另一个图数据库 - JanusGraph,PPT中分别对JanusGraph的架构、存储模型以及如何使用HBase作为后端存储进行了详细的分析。对Graph比较感兴趣的童鞋可以重点关注! 查看全部
接着HBaseCon West 2017 PPT解读(上)继续后面的PPT解读
 
11. OpenTSDB: 2.4 and 3.0 update(by Yahoo)
作者是一位维护OpenTSDB近4年的程序员,干货比较多。OpenTSDB是一款基于HBase之上开发的时间序列数据库产品,能方便的实现水平扩展。具体到HBase的存储时,OpenTSDB设计的rowKey为
rowKey=salt + metric + timestamp + tagk1 + tagv1… + tagkN + tagvN
这样的rowKey设计,可以满足用户根据metric + ts + 若干个tag组合进行查询,用SQL来表达是
select * from table where metric=? and ts < ? and ts > ? and (tag_i= ?) and (tag_j= ?)
HBASE-15181 实现了DateTieredCompaction。DateTieredCompaction的策略是按照时间轴(一般待合并区间为[now - maxAge, now], 其中maxAge可配置) ,从新到旧划分时间区间,其中时间越新,划分时间区间长度越短,然后对时间轴内区间的多个文件做合并,落在对应区间的KeyValue被写入到对应区间的storeFile内,最终合并的结果是每个区间只有一个文件,这个文件只包含自己区间内的数据。这种策略的好处在于数据越新,compaction越频繁,数据越旧,compaction越少(甚至不compaction),这种策略非常适合OpenTSDB,因为OpenTSDB写入数据都是按照时间递增,而之前的老数据从不修改,因此推荐OpenTSDB下的HBase集群采用DateTieredCompaction策略
 
另外,PPT中还提到很多其他的内容,例如AsyncHBase的进展,OpenTSDB3.0的规划,OpenTSDB2.4的其他新特性等等,这里不再展开细评, 感兴趣可以读读PPT。
 
参考资料:
1. https://labs.spotify.com/2014/12/18/date-tiered-compaction/
 
12. A study of Salesforce’s use of HBase and Phoenix ( by Salesforce )
主要介绍了Salesforce公司内部的HBase/Phoenix业务情况。
 
13. Cursors in Apache Phoenix (by bloomberg)
Bloomberg是一家研发NewSQL的数据库厂商,其核心产品是comdb2,目前已经在Github开源,其项目的介绍专门在VLDB2016上发了paper,感兴趣的同学可以读读。本次talk主要介绍他们是如何在phoenix上实现的关系型数据库中cursor功能。

14. Warp 10 - A novel approach for time series management and analysis based on HBase (by Herberts)
这个PPT主要应该是介绍他们的Wrap10项目。
 
15. Removable Singularity: A Story of HBaseUpgrade at Pinterest(by Pinterest)
Pinterest之前有40多个0.94版本的集群,他们面临着和小米一样的问题,就是需要把0.94版本的集群升级到1.2版本,而0.94版本HBase的rpc协议和1.2不兼容,前者是基于Writable接口的自定义协议,后者是Protobuf协议。解决问题的思路大致是一样的,就是先把快照数据通过ExportSnapshot导入1.2版本的HBase集群,再把增量数据通过thrift replication导入到新集群。后面需要考虑的问题就是业务如何实现在线切换。Pinterest比较有优势的一个地方就是,他们的业务使用的客户端是AsyncHBase1.7,而AsyncHBase1.7本身是支持0.94和1.2的,因此业务只需要修改访问HBase的集群地址就好。升级到1.2版本之后,无论是读性能还是写性能都有较好的提升。

16. Improving HBase availability in a multi-tenant environment (by Hubspot)
HBase在CAP中属于CP型的系统,可用性方面有一些缺陷,例如一个RegionServer宕机,Failover时长主要分3段,首先是故障检测的时间(<10s),然后是SplitLog的时间(20~40s),然后是最终RegionOnline的时间(10s~30s),数据取自Hubspot PPT。总体来讲,Failover时长优化空间较大。为此,Hubspot分享了一些提高HBase可用性的相关work:
a. 测试发现将大集群拆分成更多小实例能减少总体的failover时间。
b. 通过Normalizer控制Region的大小,使之均匀。
c. HBASE-17707HBASE-18164优化StochasticLoadBalancer策略,使balance更合理,更高效。
d. 对每个用户消耗的RPC Handler做上限限制,社区版本貌似没这功能,应该是内部实现的。
e. 使用内部硬件检测工具提前发现硬件问题,并移走HBase服务。
 
17. Highly Available HBase (by Sift Science)
Sift Science是一家通过实时机器学习技术来防止商业诈骗的公司, Uber/Airbnb等都是他们的客户。由于他们的业务跟钱相关,对HBase可用性要求非常高。经过一些优化之后, 他们成功将HBase的宕机时间从5小时/月优化到4分钟/月。这些优化工作主要有:
1. 修改hbase-client代码,当client发现突然有较多请求失败时,client直接上抛DoNotRetryRegionException到上层,避免RS已经不可用时仍然被客户端大量请求导致大量handler被卡住,影响MTTR时间。
2. 搭建在线备份集群,同时修改client代码,发现主集群有问题, client可以直接借助zk自动切换到备份集群。 存在的问题是,备份集群数据可能落后主集群,切换可能数据不一致。PPT上只是说会通过离线任务去抽样校验,所以,我觉得对于两集群的一致性问题,要么牺牲一致性保可用性,要么牺牲可用性保一致性。
3. 加强监控,尤其是locality/balance状况/p99延迟这些,尽早发现问题并解决,而不是等出问题再解决。
 
18. Transactions in HBase (by cask.co)
这个talk应该是全场21个talk中干货最多的PPT之一,讨论的重点是基于HBase之上如何实现分布式事务。作者深入探讨了3种分布式事务模型,分别是Tephra/Trafodion/Omid,3个项目都是Apache下的孵化项目。这里,简单说一下我对这3种事务模型的理解:
a. Tephra: 该模型本质上是通过一个叫做Trx Manager的集中式服务用来维护当前活跃事务,该TrxManager用来分配事务start/commit/rollback逻辑时钟,每个事务开始时都会分配一个ts和一个叫做excludes={...}的集合,用来维护该事务开始前的活跃事务,这个excludes集合可用来做隔离性检查,也可用来做冲突检查。由于有一个较为重量级的集中式TrxManager,所以事务高并发场景下该模型压力会较大,因此该模型推荐的用来运行并发少的long-running MapReduce之类的事务Job。
b. Trafodion:  这个没太看懂和tephra的区别是啥。。ppt上看不太出来。
c. Omid: Apache Omid事务模型和Google Percolator事务模型是类似的,小米研发的Themis也是一样,本质上是借助HBase的行级别事务来实现跨行跨表事务。每个事务begin和commit/rollback都需要去TimeOracle拿到一个全局唯一递增的逻辑timestamp,然后为每一个column新增两个隐藏的column分别叫做lock和write,用来跟踪每次写入操作的锁以及逻辑timestamp,通过2PC实现跨行事务提交。对于读取的4个隔离级别(RS, RR, SI, RU),有了全局唯一递增的逻辑时钟之后,也就很容易决定哪些数据应该返回给用户。

参考资料
1. http://andremouche.github.io/t ... .html 
2. https://research.google.com/pubs/pub36726.html
3. https://github.com/xiaomi/themis
4. http://nosqlmark.informatik.un ... d.pdf

19. Achieving HBase Multi-Tenancy: RegionServer Groups and Favored Nodes 
这个talk介绍了Yahoos主导的两个重要feature:RegionServer Group和Favored Nodes。
1. RegionServer Group可以让指定表分布在某些RegionServer上,一定程度上实现了多租户之间的隔离,相比Hortonworks在微观层面对多租户所做出的努力(rpc队列分离、quota机制、请求优先级等),个人认为rsGroup在多租户管理方面效果可能更加明显。rsGroup是这次峰会比较明星的话题,包括滴滴等公司都作为主旨来介绍其在生产实践中的应用,可见已经被很多大厂所接受并实践,遗憾的是,该功能目前只在未发布的2.0.0里面包含,要想在当前版本中使用必须移植对应patch,因为功能的复杂性,这看起来并不是一件容易的事情。
2. Favored Nodes机制相对比较陌生,该功能允许HBase在region层面指定该region上所有文件分布在哪些DN之上,这个功能最大的好处是可以提升数据文件的本地率,试想,每个Region都知道文件存放的DN,迁移Region的时候就可以多考虑文件本地率进行迁移。
 
20. Community-Driven Graphs With JanusGraph
这个talk介绍了HBase应用的另一个重要领域-图数据库,图数据库在互联网业务中诸多方面(社交图谱分析、推荐分析)都有实际应用。比如大家可能比较熟悉的titan数据库就是一个典型的图数据库。而这个主题介绍的是另一个图数据库 - JanusGraph,PPT中分别对JanusGraph的架构、存储模型以及如何使用HBase作为后端存储进行了详细的分析。对Graph比较感兴趣的童鞋可以重点关注!

HBaseCon Asia 2017将于8月4日在深圳举办

文章分享openinx 发表了文章 • 0 个评论 • 639 次浏览 • 2017-06-07 19:44 • 来自相关话题

 
 HBaseCon Asia 2017大会报名已正式开放。HBaseCon Asia 2017是第一届在亚洲举办的HBase技术大会,大会将在中国深圳举办,华为是本次大会的主办方。

如果您想作为普通的参会者参加此会,欢迎您通过如下链接报名(本次大会无需任何门票费用):  http://hbaseconasia.eventbrite.com

如果您想成为演讲者,欢迎您通过如下链接申报您的演讲主题内容:  https://easychair.org/cfp/HBaseConAsia2017

会议细节:https://www.eventbrite.com/e/h ... 46159
 
会议安排如下:






  查看全部
hbasecon2015noyear.eps_.png

 
 HBaseCon Asia 2017大会报名已正式开放。HBaseCon Asia 2017是第一届在亚洲举办的HBase技术大会,大会将在中国深圳举办,华为是本次大会的主办方。

如果您想作为普通的参会者参加此会,欢迎您通过如下链接报名(本次大会无需任何门票费用):  http://hbaseconasia.eventbrite.com

如果您想成为演讲者,欢迎您通过如下链接申报您的演讲主题内容:  https://easychair.org/cfp/HBaseConAsia2017

会议细节:https://www.eventbrite.com/e/h ... 46159
 
会议安排如下:
hbasecon.png