HBaseCon

HBaseCon

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社区的朋友们。感谢组委会和社区,也感谢铎神和小豪在试讲中提出的很多宝贵建议。
 

HBaseConAsia2017 PPT解读(上)

文章分享openinx 发表了文章 • 1 个评论 • 362 次浏览 • 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的一个案例,感兴趣的同学可以跟着测试一下。

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
 
 

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为$(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比较感兴趣的童鞋可以重点关注!

HBaseCon West 2017 PPT解读(上)

文章分享qgxiaozhan 发表了文章 • 0 个评论 • 1421 次浏览 • 2017-06-28 14:56 • 来自相关话题

链接: HBaseConWest2017 密码: 2fgh
 
HBaseCon West 2017的PPT解读如下:

1. HBase at Xiaomi 
由小米的杨哲和张洸濠合作分享,两位是2016年新晋升的HBase Committer (ps: 小米目前总共产生了5位HBase Committer加上1位HBase PMC,解决了180+个issue).  分享的一些亮点主要有:
a. 0.94升级到0.98集群的一些经验。
b. 小米内部HBase使用g1gc的一些经验。
c. 2016年小米对社区做的一些开发和改进,包括但不限于顺序推送复制日志/优化Scan操作/开发异步客户端功能以及相关测试结果,等等。
 
2. Apache HBase at DiDi (by Kang Yuan)
主要分享了HBase在滴滴的一些实践经验,目前滴滴的HBase是基于0.98.21版本,然后将rsgroup这个功能迁移到了自己的分支,用来做业务隔离。另外,PPT中也提到通过将地理位置坐标进行GeoHash转换成一维byte存放到HBase中,可以解决查询一个点周边坐标的问题。
 
3. Accordion: HBase Breathes with In-Memory Compaction (From Yahoo)
有了InMemory-Compaction功能之后,HBase支持将Memstore直接Flush成一个ImmutableSegment,这个ImmutableSegment其实是一块内存空间,多次Memstore的Flush操作会导致产生多个ImmutableSegment,特定条件下,多个ImmtableSegment会进行In-Memory的Compaction,也就是多个ImmutableSegment完全在内存中合并成为一个大的ImmutableSegment(其中BASIC类型的InMemoryCompaction会保留所有数据,EAGER类型的InMemoryCompaction会清理冗余版本数据)。最终,这个大的ImmutableSegment还是要Flush到磁盘的,然后接着触发做磁盘上的Compaction操作。
 
按照设计文档以及PPT的说明,InMemory-Compaction有以下好处:
a.  由于InMemoryCompaction会在内存中进行compaction, 不用频繁的Flush Memstore到Disk(Flush次数太多会造成storefile个数增长, storefile的增长会导致读性能严重下降), 从而可以降低读操作延迟。
b.  ImmtableSegment今后可能会和HFile的layout保持一致,这样Flush的速度将大幅提升。
c.   对于行数据频繁更新的场景,InMemory-Compaction可以采用EAGER方式在内存中就清理掉冗余版本数据,节省了这部分数据落盘的代价。
最后,PPT测试数据也确实说明使用InMemoryCompaction后,写吞吐有较大幅度提升,读延迟有较大幅度下降。

ps. In-memory Compaction由stack等6位成员共同完成(将在HBase2.0的release版本发布),这其中有两位美女工程师(PPT中的照片证明颜值确实很高),现在都已经是HBase的Committer了。
另外,In-memory compaction详细设计文档请参考:https://issues.apache.org/jira/browse/HBASE-13408
 
4. Efficient and portable data processing with Apache Beam and HBase (By Google)
这个演讲更多是来HBaseCon宣传下Apache Beam这个项目。
Apache Beam这个项目始于2016年2月份,近1年多的时间内就收到了来自全球178个贡献者的8600+提交,主要是希望提供一个统一的API用来同时处理Batch任务和Streaming任务,他的API后端可以接Apex/Flink/Spark/GoogleCloudDataFlow等服务,同时提供Java和Python的客户端SDK。这个东西就好比JDBC一样,提供了一个统一的借口,后端可以连接MySQL/Oracle/Postgresql/SQLServer等关系型数据库。我没理解错的话,这个东西应该是可以用来在HBase/MongoDB/HDFS/Cassandra/Kafka/BigTable/Spanner/Elasticsearch/GridFS/Hive/AMQP等(超过20种通用的存储服务)各种服务间实现数据transform。
 
5. Data Product at Airbnb
来自Airbnb的这份演讲,主要介绍了Airbnb内部HBase的应用场景,以及如何实现统一执行batch任务和streaming任务。
 
6. Democratizing HBase(by Hortonworks)
作者Josh Elser是来自Hortonworks的工程师,也是HBase Committer,他参与了多个Apache的顶级项目,例如HBase/Phoenix等等。演讲主要介绍了目前HBase在多租户资源隔离方面的一些工作,主要包括安全认证,RPC Quotas,Rpc优先级,Space Quotas,RegionServer Group等内容。
 
7. Apache Spark – Apache HBase Connector Feature Rich and Efficient Access to HBase through Spark SQL (by Hortonworks)
介绍Hortonworks开源的SHC项目相关内容。
 
8. Gohbase: Pure Go HBase Client(by Arista Networks)
一般非Java语言(Python/Golang/Javascript)会采用Thrift协议生成各自语言的SDK, SDK先访问HBase的Thrift server,然后thrift server后端通过Java Native Client连RS/Master,通过ThriftServer中转来实现通信,但通过thrift协议生成的非Java版本的客户端接口比较原始,不是特别好用,另外早期的ThriftServer bug也比较多。

因此,演讲者基于HBase的Protobuf协议,实现了一套纯Golang写的hbase client,其实相当于说把Java Native Client的逻辑全部用Golang写了一遍。使用体验应该要比其他Golang语言写的SDK好用。性能上,Gohbase某些场景下甚至优于Java的客户端。
 
最后,作者在开发Gohbase的过程中,发现了HBASE-18066这个bug, 这个bug目前已经由小米openinx修复。这个bug的问题在于:设置closestRowBefore为true的Get操作,在RegionServer端的代码实现中,是先通过不带mvcc的方式拿到rowKey, 然后再通过带mvcc的方式去找这个rowKey对应的Value, 并返回。由于前者不带mvcc, 后者带mvcc,所以导致拿到的数据可能不一致。修复方式就是把这类操作都由reversed scan来实现,由于scan操作统一设了mvcc,也就解决了这个BUG。
 
9. Analyzing Cryptocurrencies on HBase For Finance, Forensics, and Fraud (by Ripple)
Ripple是一种有点类似Bitcoin的加密数字货币,背后应该是有Ripple这个商业公司在支撑,这份演讲主要介绍了Ripple现状以及HBase在公司内部的应用场景,重点应该还是Ripple的相关业务介绍。
 
10. Splice Machine: Powering Hybrid Applications (by Splice Machine)
Splice Machine是一家做数据库(DAAS)云服务的厂商,PPT主要是演示了一遍他们的Hadoop相关云产品使用过程,对HBase云产品形态感兴趣的同学可以看一下。本次分享主要还是推广他们的产品。
 
 
余下PPT解读,请参考HBaseCon West 2017 PPT解读(下) 查看全部
链接: HBaseConWest2017 密码: 2fgh
 
HBaseCon West 2017的PPT解读如下:

1. HBase at Xiaomi 
由小米的杨哲和张洸濠合作分享,两位是2016年新晋升的HBase Committer (ps: 小米目前总共产生了5位HBase Committer加上1位HBase PMC,解决了180+个issue).  分享的一些亮点主要有:
a. 0.94升级到0.98集群的一些经验。
b. 小米内部HBase使用g1gc的一些经验。
c. 2016年小米对社区做的一些开发和改进,包括但不限于顺序推送复制日志/优化Scan操作/开发异步客户端功能以及相关测试结果,等等。
 
2. Apache HBase at DiDi (by Kang Yuan)
主要分享了HBase在滴滴的一些实践经验,目前滴滴的HBase是基于0.98.21版本,然后将rsgroup这个功能迁移到了自己的分支,用来做业务隔离。另外,PPT中也提到通过将地理位置坐标进行GeoHash转换成一维byte存放到HBase中,可以解决查询一个点周边坐标的问题。
 
3. Accordion: HBase Breathes with In-Memory Compaction (From Yahoo)
有了InMemory-Compaction功能之后,HBase支持将Memstore直接Flush成一个ImmutableSegment,这个ImmutableSegment其实是一块内存空间,多次Memstore的Flush操作会导致产生多个ImmutableSegment,特定条件下,多个ImmtableSegment会进行In-Memory的Compaction,也就是多个ImmutableSegment完全在内存中合并成为一个大的ImmutableSegment(其中BASIC类型的InMemoryCompaction会保留所有数据,EAGER类型的InMemoryCompaction会清理冗余版本数据)。最终,这个大的ImmutableSegment还是要Flush到磁盘的,然后接着触发做磁盘上的Compaction操作。
 
按照设计文档以及PPT的说明,InMemory-Compaction有以下好处:
a.  由于InMemoryCompaction会在内存中进行compaction, 不用频繁的Flush Memstore到Disk(Flush次数太多会造成storefile个数增长, storefile的增长会导致读性能严重下降), 从而可以降低读操作延迟。
b.  ImmtableSegment今后可能会和HFile的layout保持一致,这样Flush的速度将大幅提升。
c.   对于行数据频繁更新的场景,InMemory-Compaction可以采用EAGER方式在内存中就清理掉冗余版本数据,节省了这部分数据落盘的代价。
最后,PPT测试数据也确实说明使用InMemoryCompaction后,写吞吐有较大幅度提升,读延迟有较大幅度下降。

ps. In-memory Compaction由stack等6位成员共同完成(将在HBase2.0的release版本发布),这其中有两位美女工程师(PPT中的照片证明颜值确实很高),现在都已经是HBase的Committer了。
另外,In-memory compaction详细设计文档请参考:https://issues.apache.org/jira/browse/HBASE-13408
 
4. Efficient and portable data processing with Apache Beam and HBase (By Google)
这个演讲更多是来HBaseCon宣传下Apache Beam这个项目。
Apache Beam这个项目始于2016年2月份,近1年多的时间内就收到了来自全球178个贡献者的8600+提交,主要是希望提供一个统一的API用来同时处理Batch任务和Streaming任务,他的API后端可以接Apex/Flink/Spark/GoogleCloudDataFlow等服务,同时提供Java和Python的客户端SDK。这个东西就好比JDBC一样,提供了一个统一的借口,后端可以连接MySQL/Oracle/Postgresql/SQLServer等关系型数据库。我没理解错的话,这个东西应该是可以用来在HBase/MongoDB/HDFS/Cassandra/Kafka/BigTable/Spanner/Elasticsearch/GridFS/Hive/AMQP等(超过20种通用的存储服务)各种服务间实现数据transform。
 
5. Data Product at Airbnb
来自Airbnb的这份演讲,主要介绍了Airbnb内部HBase的应用场景,以及如何实现统一执行batch任务和streaming任务。
 
6. Democratizing HBase(by Hortonworks)
作者Josh Elser是来自Hortonworks的工程师,也是HBase Committer,他参与了多个Apache的顶级项目,例如HBase/Phoenix等等。演讲主要介绍了目前HBase在多租户资源隔离方面的一些工作,主要包括安全认证,RPC Quotas,Rpc优先级,Space Quotas,RegionServer Group等内容。
 
7. Apache Spark – Apache HBase Connector Feature Rich and Efficient Access to HBase through Spark SQL (by Hortonworks)
介绍Hortonworks开源的SHC项目相关内容。
 
8. Gohbase: Pure Go HBase Client(by Arista Networks)
一般非Java语言(Python/Golang/Javascript)会采用Thrift协议生成各自语言的SDK, SDK先访问HBase的Thrift server,然后thrift server后端通过Java Native Client连RS/Master,通过ThriftServer中转来实现通信,但通过thrift协议生成的非Java版本的客户端接口比较原始,不是特别好用,另外早期的ThriftServer bug也比较多。

因此,演讲者基于HBase的Protobuf协议,实现了一套纯Golang写的hbase client,其实相当于说把Java Native Client的逻辑全部用Golang写了一遍。使用体验应该要比其他Golang语言写的SDK好用。性能上,Gohbase某些场景下甚至优于Java的客户端。
 
最后,作者在开发Gohbase的过程中,发现了HBASE-18066这个bug, 这个bug目前已经由小米openinx修复。这个bug的问题在于:设置closestRowBefore为true的Get操作,在RegionServer端的代码实现中,是先通过不带mvcc的方式拿到rowKey, 然后再通过带mvcc的方式去找这个rowKey对应的Value, 并返回。由于前者不带mvcc, 后者带mvcc,所以导致拿到的数据可能不一致。修复方式就是把这类操作都由reversed scan来实现,由于scan操作统一设了mvcc,也就解决了这个BUG。
 
9. Analyzing Cryptocurrencies on HBase For Finance, Forensics, and Fraud (by Ripple)
Ripple是一种有点类似Bitcoin的加密数字货币,背后应该是有Ripple这个商业公司在支撑,这份演讲主要介绍了Ripple现状以及HBase在公司内部的应用场景,重点应该还是Ripple的相关业务介绍。
 
10. Splice Machine: Powering Hybrid Applications (by Splice Machine)
Splice Machine是一家做数据库(DAAS)云服务的厂商,PPT主要是演示了一遍他们的Hadoop相关云产品使用过程,对HBase云产品形态感兴趣的同学可以看一下。本次分享主要还是推广他们的产品。
 
 
余下PPT解读,请参考HBaseCon West 2017 PPT解读(下)

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



 

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



 

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社区的朋友们。感谢组委会和社区,也感谢铎神和小豪在试讲中提出的很多宝贵建议。
 

HBaseConAsia2017 PPT解读(上)

文章分享openinx 发表了文章 • 1 个评论 • 362 次浏览 • 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的一个案例,感兴趣的同学可以跟着测试一下。

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
 
 

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 West 2017 PPT解读(上)

文章分享qgxiaozhan 发表了文章 • 0 个评论 • 1421 次浏览 • 2017-06-28 14:56 • 来自相关话题

链接: HBaseConWest2017 密码: 2fgh
 
HBaseCon West 2017的PPT解读如下:

1. HBase at Xiaomi 
由小米的杨哲和张洸濠合作分享,两位是2016年新晋升的HBase Committer (ps: 小米目前总共产生了5位HBase Committer加上1位HBase PMC,解决了180+个issue).  分享的一些亮点主要有:
a. 0.94升级到0.98集群的一些经验。
b. 小米内部HBase使用g1gc的一些经验。
c. 2016年小米对社区做的一些开发和改进,包括但不限于顺序推送复制日志/优化Scan操作/开发异步客户端功能以及相关测试结果,等等。
 
2. Apache HBase at DiDi (by Kang Yuan)
主要分享了HBase在滴滴的一些实践经验,目前滴滴的HBase是基于0.98.21版本,然后将rsgroup这个功能迁移到了自己的分支,用来做业务隔离。另外,PPT中也提到通过将地理位置坐标进行GeoHash转换成一维byte存放到HBase中,可以解决查询一个点周边坐标的问题。
 
3. Accordion: HBase Breathes with In-Memory Compaction (From Yahoo)
有了InMemory-Compaction功能之后,HBase支持将Memstore直接Flush成一个ImmutableSegment,这个ImmutableSegment其实是一块内存空间,多次Memstore的Flush操作会导致产生多个ImmutableSegment,特定条件下,多个ImmtableSegment会进行In-Memory的Compaction,也就是多个ImmutableSegment完全在内存中合并成为一个大的ImmutableSegment(其中BASIC类型的InMemoryCompaction会保留所有数据,EAGER类型的InMemoryCompaction会清理冗余版本数据)。最终,这个大的ImmutableSegment还是要Flush到磁盘的,然后接着触发做磁盘上的Compaction操作。
 
按照设计文档以及PPT的说明,InMemory-Compaction有以下好处:
a.  由于InMemoryCompaction会在内存中进行compaction, 不用频繁的Flush Memstore到Disk(Flush次数太多会造成storefile个数增长, storefile的增长会导致读性能严重下降), 从而可以降低读操作延迟。
b.  ImmtableSegment今后可能会和HFile的layout保持一致,这样Flush的速度将大幅提升。
c.   对于行数据频繁更新的场景,InMemory-Compaction可以采用EAGER方式在内存中就清理掉冗余版本数据,节省了这部分数据落盘的代价。
最后,PPT测试数据也确实说明使用InMemoryCompaction后,写吞吐有较大幅度提升,读延迟有较大幅度下降。

ps. In-memory Compaction由stack等6位成员共同完成(将在HBase2.0的release版本发布),这其中有两位美女工程师(PPT中的照片证明颜值确实很高),现在都已经是HBase的Committer了。
另外,In-memory compaction详细设计文档请参考:https://issues.apache.org/jira/browse/HBASE-13408
 
4. Efficient and portable data processing with Apache Beam and HBase (By Google)
这个演讲更多是来HBaseCon宣传下Apache Beam这个项目。
Apache Beam这个项目始于2016年2月份,近1年多的时间内就收到了来自全球178个贡献者的8600+提交,主要是希望提供一个统一的API用来同时处理Batch任务和Streaming任务,他的API后端可以接Apex/Flink/Spark/GoogleCloudDataFlow等服务,同时提供Java和Python的客户端SDK。这个东西就好比JDBC一样,提供了一个统一的借口,后端可以连接MySQL/Oracle/Postgresql/SQLServer等关系型数据库。我没理解错的话,这个东西应该是可以用来在HBase/MongoDB/HDFS/Cassandra/Kafka/BigTable/Spanner/Elasticsearch/GridFS/Hive/AMQP等(超过20种通用的存储服务)各种服务间实现数据transform。
 
5. Data Product at Airbnb
来自Airbnb的这份演讲,主要介绍了Airbnb内部HBase的应用场景,以及如何实现统一执行batch任务和streaming任务。
 
6. Democratizing HBase(by Hortonworks)
作者Josh Elser是来自Hortonworks的工程师,也是HBase Committer,他参与了多个Apache的顶级项目,例如HBase/Phoenix等等。演讲主要介绍了目前HBase在多租户资源隔离方面的一些工作,主要包括安全认证,RPC Quotas,Rpc优先级,Space Quotas,RegionServer Group等内容。
 
7. Apache Spark – Apache HBase Connector Feature Rich and Efficient Access to HBase through Spark SQL (by Hortonworks)
介绍Hortonworks开源的SHC项目相关内容。
 
8. Gohbase: Pure Go HBase Client(by Arista Networks)
一般非Java语言(Python/Golang/Javascript)会采用Thrift协议生成各自语言的SDK, SDK先访问HBase的Thrift server,然后thrift server后端通过Java Native Client连RS/Master,通过ThriftServer中转来实现通信,但通过thrift协议生成的非Java版本的客户端接口比较原始,不是特别好用,另外早期的ThriftServer bug也比较多。

因此,演讲者基于HBase的Protobuf协议,实现了一套纯Golang写的hbase client,其实相当于说把Java Native Client的逻辑全部用Golang写了一遍。使用体验应该要比其他Golang语言写的SDK好用。性能上,Gohbase某些场景下甚至优于Java的客户端。
 
最后,作者在开发Gohbase的过程中,发现了HBASE-18066这个bug, 这个bug目前已经由小米openinx修复。这个bug的问题在于:设置closestRowBefore为true的Get操作,在RegionServer端的代码实现中,是先通过不带mvcc的方式拿到rowKey, 然后再通过带mvcc的方式去找这个rowKey对应的Value, 并返回。由于前者不带mvcc, 后者带mvcc,所以导致拿到的数据可能不一致。修复方式就是把这类操作都由reversed scan来实现,由于scan操作统一设了mvcc,也就解决了这个BUG。
 
9. Analyzing Cryptocurrencies on HBase For Finance, Forensics, and Fraud (by Ripple)
Ripple是一种有点类似Bitcoin的加密数字货币,背后应该是有Ripple这个商业公司在支撑,这份演讲主要介绍了Ripple现状以及HBase在公司内部的应用场景,重点应该还是Ripple的相关业务介绍。
 
10. Splice Machine: Powering Hybrid Applications (by Splice Machine)
Splice Machine是一家做数据库(DAAS)云服务的厂商,PPT主要是演示了一遍他们的Hadoop相关云产品使用过程,对HBase云产品形态感兴趣的同学可以看一下。本次分享主要还是推广他们的产品。
 
 
余下PPT解读,请参考HBaseCon West 2017 PPT解读(下) 查看全部
链接: HBaseConWest2017 密码: 2fgh
 
HBaseCon West 2017的PPT解读如下:

1. HBase at Xiaomi 
由小米的杨哲和张洸濠合作分享,两位是2016年新晋升的HBase Committer (ps: 小米目前总共产生了5位HBase Committer加上1位HBase PMC,解决了180+个issue).  分享的一些亮点主要有:
a. 0.94升级到0.98集群的一些经验。
b. 小米内部HBase使用g1gc的一些经验。
c. 2016年小米对社区做的一些开发和改进,包括但不限于顺序推送复制日志/优化Scan操作/开发异步客户端功能以及相关测试结果,等等。
 
2. Apache HBase at DiDi (by Kang Yuan)
主要分享了HBase在滴滴的一些实践经验,目前滴滴的HBase是基于0.98.21版本,然后将rsgroup这个功能迁移到了自己的分支,用来做业务隔离。另外,PPT中也提到通过将地理位置坐标进行GeoHash转换成一维byte存放到HBase中,可以解决查询一个点周边坐标的问题。
 
3. Accordion: HBase Breathes with In-Memory Compaction (From Yahoo)
有了InMemory-Compaction功能之后,HBase支持将Memstore直接Flush成一个ImmutableSegment,这个ImmutableSegment其实是一块内存空间,多次Memstore的Flush操作会导致产生多个ImmutableSegment,特定条件下,多个ImmtableSegment会进行In-Memory的Compaction,也就是多个ImmutableSegment完全在内存中合并成为一个大的ImmutableSegment(其中BASIC类型的InMemoryCompaction会保留所有数据,EAGER类型的InMemoryCompaction会清理冗余版本数据)。最终,这个大的ImmutableSegment还是要Flush到磁盘的,然后接着触发做磁盘上的Compaction操作。
 
按照设计文档以及PPT的说明,InMemory-Compaction有以下好处:
a.  由于InMemoryCompaction会在内存中进行compaction, 不用频繁的Flush Memstore到Disk(Flush次数太多会造成storefile个数增长, storefile的增长会导致读性能严重下降), 从而可以降低读操作延迟。
b.  ImmtableSegment今后可能会和HFile的layout保持一致,这样Flush的速度将大幅提升。
c.   对于行数据频繁更新的场景,InMemory-Compaction可以采用EAGER方式在内存中就清理掉冗余版本数据,节省了这部分数据落盘的代价。
最后,PPT测试数据也确实说明使用InMemoryCompaction后,写吞吐有较大幅度提升,读延迟有较大幅度下降。

ps. In-memory Compaction由stack等6位成员共同完成(将在HBase2.0的release版本发布),这其中有两位美女工程师(PPT中的照片证明颜值确实很高),现在都已经是HBase的Committer了。
另外,In-memory compaction详细设计文档请参考:https://issues.apache.org/jira/browse/HBASE-13408
 
4. Efficient and portable data processing with Apache Beam and HBase (By Google)
这个演讲更多是来HBaseCon宣传下Apache Beam这个项目。
Apache Beam这个项目始于2016年2月份,近1年多的时间内就收到了来自全球178个贡献者的8600+提交,主要是希望提供一个统一的API用来同时处理Batch任务和Streaming任务,他的API后端可以接Apex/Flink/Spark/GoogleCloudDataFlow等服务,同时提供Java和Python的客户端SDK。这个东西就好比JDBC一样,提供了一个统一的借口,后端可以连接MySQL/Oracle/Postgresql/SQLServer等关系型数据库。我没理解错的话,这个东西应该是可以用来在HBase/MongoDB/HDFS/Cassandra/Kafka/BigTable/Spanner/Elasticsearch/GridFS/Hive/AMQP等(超过20种通用的存储服务)各种服务间实现数据transform。
 
5. Data Product at Airbnb
来自Airbnb的这份演讲,主要介绍了Airbnb内部HBase的应用场景,以及如何实现统一执行batch任务和streaming任务。
 
6. Democratizing HBase(by Hortonworks)
作者Josh Elser是来自Hortonworks的工程师,也是HBase Committer,他参与了多个Apache的顶级项目,例如HBase/Phoenix等等。演讲主要介绍了目前HBase在多租户资源隔离方面的一些工作,主要包括安全认证,RPC Quotas,Rpc优先级,Space Quotas,RegionServer Group等内容。
 
7. Apache Spark – Apache HBase Connector Feature Rich and Efficient Access to HBase through Spark SQL (by Hortonworks)
介绍Hortonworks开源的SHC项目相关内容。
 
8. Gohbase: Pure Go HBase Client(by Arista Networks)
一般非Java语言(Python/Golang/Javascript)会采用Thrift协议生成各自语言的SDK, SDK先访问HBase的Thrift server,然后thrift server后端通过Java Native Client连RS/Master,通过ThriftServer中转来实现通信,但通过thrift协议生成的非Java版本的客户端接口比较原始,不是特别好用,另外早期的ThriftServer bug也比较多。

因此,演讲者基于HBase的Protobuf协议,实现了一套纯Golang写的hbase client,其实相当于说把Java Native Client的逻辑全部用Golang写了一遍。使用体验应该要比其他Golang语言写的SDK好用。性能上,Gohbase某些场景下甚至优于Java的客户端。
 
最后,作者在开发Gohbase的过程中,发现了HBASE-18066这个bug, 这个bug目前已经由小米openinx修复。这个bug的问题在于:设置closestRowBefore为true的Get操作,在RegionServer端的代码实现中,是先通过不带mvcc的方式拿到rowKey, 然后再通过带mvcc的方式去找这个rowKey对应的Value, 并返回。由于前者不带mvcc, 后者带mvcc,所以导致拿到的数据可能不一致。修复方式就是把这类操作都由reversed scan来实现,由于scan操作统一设了mvcc,也就解决了这个BUG。
 
9. Analyzing Cryptocurrencies on HBase For Finance, Forensics, and Fraud (by Ripple)
Ripple是一种有点类似Bitcoin的加密数字货币,背后应该是有Ripple这个商业公司在支撑,这份演讲主要介绍了Ripple现状以及HBase在公司内部的应用场景,重点应该还是Ripple的相关业务介绍。
 
10. Splice Machine: Powering Hybrid Applications (by Splice Machine)
Splice Machine是一家做数据库(DAAS)云服务的厂商,PPT主要是演示了一遍他们的Hadoop相关云产品使用过程,对HBase云产品形态感兴趣的同学可以看一下。本次分享主要还是推广他们的产品。
 
 
余下PPT解读,请参考HBaseCon West 2017 PPT解读(下)

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