HBase regionserver非GC暂停

有问必答qgxiaozhan 回复了问题 • 4 人关注 • 2 个回复 • 645 次浏览 • 2017-07-17 12:52 • 来自相关话题

regionserver发生full gc导致宕机

有问必答qgxiaozhan 回复了问题 • 3 人关注 • 6 个回复 • 886 次浏览 • 2017-07-13 11:23 • 来自相关话题

碰到一个问题 java.lang.OutOfMemoryError: Requested array size exceeds VM limit,怎么回事?

有问必答qgxiaozhan 回复了问题 • 3 人关注 • 2 个回复 • 616 次浏览 • 2017-07-07 23:00 • 来自相关话题

HBase的Quato机制具体是怎么实现的?

有问必答qgxiaozhan 回复了问题 • 5 人关注 • 2 个回复 • 480 次浏览 • 2017-07-07 22:52 • 来自相关话题

scan的next操作是串行执行的,能不能设计为并发执行?

有问必答openinx 回复了问题 • 3 人关注 • 1 个回复 • 348 次浏览 • 2017-07-06 18:32 • 来自相关话题

HBase中的mvcc/memstoreTS/sequenceID三者分别起什么作用? 有什么区别呢?

回复

有问必答匿名用户 回复了问题 • 4 人关注 • 1 个回复 • 600 次浏览 • 2017-07-05 09:52 • 来自相关话题

HBase内部实现中行锁的具体语意是什么?和MySQL中行锁语意有区别吗?

有问必答openinx 回复了问题 • 4 人关注 • 2 个回复 • 334 次浏览 • 2017-07-04 10:57 • 来自相关话题

HBaseCon West 2017 PPT解读(下)

文章分享openinx 发表了文章 • 0 个评论 • 1423 次浏览 • 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为$(document).ready(function() {$('pre code').each(function(i, block) { hljs.highlightBlock( block); }); });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比较感兴趣的童鞋可以重点关注!

RegionServer经常oom,能看看什么回事么?

有问必答dcswinner 回复了问题 • 4 人关注 • 4 个回复 • 767 次浏览 • 2017-06-30 20:35 • 来自相关话题

机器节点挂时,其他的datanode节点last contact也增大

有问必答qgxiaozhan 回复了问题 • 2 人关注 • 1 个回复 • 370 次浏览 • 2017-06-30 12:24 • 来自相关话题