HBase Committers&各公司HBase负责人
出席嘉宾(排名不分次序)：
封神(HBase Committer，阿里)
天梧(HBase Committer，阿里)
陈恒(HBase Committer，蚂蚁金服)
李钰(HBase PMC，阿里)
王锋(奇虎360大数据负责人)
杨文龙(HBase Committer，
阿里)
姚靖怡(滴滴HBase负责人)
张铎(HBase PMC，小米)
张洸豪(HBase PMC，小米)
本次直播视频精彩回顾，戳这里！https://yq.aliyun.com/video/play/1481
以下内容根据直播视频分享整理而成。
本次的研讨圆桌会主要围绕以下几个问题：
一、HBase2.0 社区构建花了4年之久，为什么社区需要这么多时间去构建HBase2.0呢？这意味着什么？你期待HBase2.0 具备什么样的功能？
张铎(HBase PMC，小米)：时间比较长的问题其实社区也在反思为什么花了这么长时间，后来大家觉得是开发节奏上的问题。咱们正常开发时候有一段时间需要feature freeze，但是当时HBase 一直没有把branch 2开出来，所以有些人做完之后要开始做稳定，他在给feature测稳定的状态下有些人也把其它feature放进来，所以2.0累积了很多很多的feature，到最后就需要不停的测试，不停的想办法搞稳定。最后强行把branch 2开出来之后，还是跟常规做法一样，一段时间feature freeze，然后把branch 2再开出来，做稳定，最后把版本发出来。社区也是一直反思这个问题，最后还是要定一个时间表，另外开发时都用feature branch，如果一个feature赶不上就不要合回来，不用影响本身发版的进度。另外最期待的功能是assignment management的改动。如果大家用过HBase都会遇到过Region in transition的状态，经常有的时候assign一旦RPC timeout的问题，Region状态就恢复不了，一直显示Region intransition，必须需要人工恢复。这个在1.0的版本里面不是说实现不了，实际上实现状态存在好多个地方，assignment management在2.0里面用了一个模型，就是先打日志，先打write ahead log，然后一步一步，中间是打断不了的，它是有log保证的，这样的话更容易把程序写对。当然现在可能还是有些问题，但总体上可以Region in transition状态恢复不了的问题解决。
二、我们知道HBase是基于BigTable那篇论文的，当初在搜索场景中使用的比较多。我们也知道阿里集团搜索这边用了大规模的HBase集群，那么阿里选择HBase作为搜索核心部件的关键理由是什么？另外阿里内部也用了一些HBase2.0的功能，那都是哪些功能？在搜索这边达到了什么样的效果？
李钰(HBase PMC，阿里)：因为HBase是Google承认的BigTable最好的实现，就是最符合BigTable论文的实现。首先，搜索的主业务就是BigTable的场景。另外，除了搜索场景，阿里线上也有很多推荐的场景，那很多场景都是类似的，业务的字段灵活变化，其实很多商品的特征，客户的特征等并不是固定的schema的东西。另外推荐的场景在机器学习下要求很高，如果单位时间内能做的迭代越多的话，他推荐的效果就越好，这是非常直观的效果。所以我们这边非常关注HBase2.0吞吐的能力，包括单击的能力。阿里线上在2016双11就用了读路径的off heap的功能，这里面的读路径指的是全路径，这些内容在社区的官方博客上有相关的文章。在去年的双11的时候线上也使用了写路径的off heap，这些功能在社区版本里面是2.0才有的。我们在线上使用的效果也挺明显的，2016年的时候单机峰值达到了10万qps，2017年是平均qps达到了10万。
主持人：HBase发源于搜索的场景，Google也是存了很多网页。当时我们把HBase形容为存储整个互联网的数据库，也就是说它是非常大容量，高并发的数据库，随着这么多年的发展也衍生出了非常非常多的场景。
三、360在什么样的场景下使用了HBase？另外我们知道360有一定的规模Cassandra，假设HBase在360内部使用了，能不能替代一些Cassandra的场景？
王锋(奇虎360大数据负责人)：360这边使用的场景一方面是搜索的场景，主力是这个场景，也是HBase比较擅长的场景。还有一种场景是病毒分析，样本的扫描。这一块我们作为对象的存储放在HBase里面。还有一种是网络安全分析，大量的小数据，360也是放在HBase里面存储。当然也有简单的二级索引查询，这是360内部自己开发的一些东西。Cassandra这块前期的发展比HBase好，这里面有一些历史原因，在2011年360做大数据的时候走了一些弯路，比如没有采用社区的版本，当时觉得可能Facebook的版本更稳定一些，而且Facebook是大公司，我们采用的策略就是跟随大公司，把它的版本用下来。当然Facebook后来也换了社区的版本，这对我们的技术路线影响蛮大的。随后的几年我们想逐步的切换到社区里，但是2011-2013是360极大发展的阶段，这时数据膨胀非常厉害，所以这导致了我们调整会非常痛苦。所以我们首先做的一件事情是把计算往社区里迁，包括HBase，但是它底层的存储还是在1.0版本之上，我们就做了一些中间件对接上。当然这样的性能相当于在绿皮车上做运动，速度快不起来，这是我们本身的技术路线走了弯路导致的。从后续来看我们360内部也对HBase2.0做了内测，从性能上，Region的分配效率上有蛮大的提升。另外Cassandra对于360来说是主要的问题是扩展性不够，比如做指数级的扩容，以及运维的成本比较高。所以从未来的考虑上来讲，我们也会逐步的推动HBase在我们内部的应用，长远来看HBase的规模肯定会远远超过Cassandra集群。
四、目前来看阿里集团是HBase规模最大的公司，大概有1万多个节点，阿里向往多少个节点，你自己最期待HBase2.0什么样的功能？
天梧(HBase Committer，阿里) ：阿里用HBase其实非常早，走过很多的版本，从0.90开始，0.92，0.94，到后面1.系列的，包括未来2.系列的。那从垂直角度来讲，HBase2.0有比较巨大的提升，对于单位场景来讲，它的成本节点数肯定是下降的。阿里云内部有1万3，4千节点，40万CPU，肯定能够给我们成本上带来巨大的节省。过去HBase是以整个大数据为定位的，它能承载的大数据场景是以商业价值比较高的数据场景为主。那阿里巴巴这种面向商家的做运营活动的，或者说支付宝做智能风控，或者说高德做实时路况的，anyway，面向的是由数据带动商业价值的这部分场景，我们用HBase。对于整个社会的智能化而言，智能化是以数据为前提。比如说现在阿里巴巴每个业务，或者基础的系统都在做一个智能诊断的场景，智能诊断是什么意思？简单来说在阿里巴巴交易出现下跌的时候，能够智能的判断出是哪个系统，甚至是这个系统的哪个应用，哪个节点发生问题，不需要有支撑的运维解决这个问题，我希望的是系统化的智能化的解决这个问题。但是要解决好这个问题并不简单，整个数据请求列的复杂性，攻击的数据能够完整克隆下来，并通过大量的数据分析，当交易下跌，当服务与服务的调用出现异常，能够智能的判断出这么复杂的分布式服务体系里面是哪个环节出了问题。那今天，阿里巴巴已经智能的驱动，当出现应用或服务质量下降时，能够准确找出真正的root cause是哪一个环节。这里面需要大量的数据调用，而原先如果说对于数据的存储成本比较高，不会去解决这个场景的。未来如果对数据的处理能力达到十倍，除了商业，能够帮助大家的生活，工作智能化，这个智能化意味着以数据化为前提，数据化会给HBase这样的系统，或者说更多的场景，这些场景会爆发式的在阿里巴巴扩张，扩张有可能把阿里巴巴的节点从1万个节点带到5万个节点。这是我能够看到的，也是跟业务逐步沟通之后看到，就是用户对数据的需求越来越旺盛。那么HBase给大家，给公司老板带来的更多的意义是原先的场景因为现在有一个更加靠谱，高能力的系统而能够商业带来更大的想象。HBase2.0里面有很多很不错的能力的延伸，包括MOB面向大对象功能。HBase已经不是狭义的系统，已经逐步提升到整个HBase生态体系，今天HBase有了SQL Phoenix，有了图，这些都会给HBase带来更大的市场，它的定位也会越来越宽。
主持人：非常感谢文龙同学，从非常业务sence的高度为我们解读HBase。我们做数据库追求的不止是牛的数据库能力，最终还是要驱动商业，让不可想象的事实变成可能。
五、我们知道滴滴是是一家打车，或者说让出行更方便的公司，现在车联网非常火，滴滴已经是最大的车联网企业，那么滴滴当初为什么会选择HBase？HBase上做了哪些事情？期待HBase2.0什么样的功能？
姚靖怡(滴滴HBase负责人)：滴滴这边2017年的6月到现在差不多增长了100多个项目，几百个表。滴滴使用HBase有几方面的原因，第一方面，传统数据库可能会有分库分表这样的操作，使用HBase可以有这样的操作，方便扩容，对于用户没有太大的感知。还有一个是有一个动态列的特性，滴滴这边对于动态列的需求比较多，因为互联网的公司需求方面会接入各个来源的数据，通过动态列记录数据的来源。HBase有一个Phoenix SQL组件，这也支持了我们一个线上的业务。HBase2.0功能这块有几个特性，一个是评价故障的恢复时间，然后现在存储型的机器对IO的压力比较大，在2.0里面有In-Memory的contection和flush，这些特性我们也是比较期待的。其它的还有使用对外内存的特性，这个对用户来说是比较关注的。另外是HBase2.0里面异步客户端的特性。
六、小米这边对HBase的贡献比较多，小米当初为什么选择HBase，另外HBase2.0会给小米带来什么样的好处？另外小米也在有云这边的业务，小米对做什么样的赋能？
张洸豪(HBase PMC, 小米)：小米这边使用HBase是国内比较早的，从2012年就开始使用HBase了。在选择HBase的时候小米这边的打法就是比较简单，更看中它的开源。另外在使用过程中去优化社区这样的打法。其次的话是Hadoop生态，因为你如果已经有了HDFS这种分布式文件系统，或者已经有了yarn这种Hadoop生态之后，搭建HBase是非常简单的事情。还有一点在当时算是比较大的推动力就是Facebook的message，在2011年的时候全部迁往HBase。有哪家大公司在生态环境下使用，我们就用起来比较放心，这也就推动了2012年的时候小米选择HBase来作为主力的分布式存储方案。小米这边业务比较多，维护的集群中虽然说没有单集群上千节点这种，但是单独的小集群比较多，所以我们这边对于rsgroup会比较期待，就还是希望后面将一些小集群进行合并，降低运维上的成本。其次off heap这块的使用可能会带来GC.99 latency的下降。小米HBase云端这块，因为小米的云不是对外的，目前只是针对内部融和云，还有面对小米的生态链公司。比如小米手环，空气净化器等。只是在HBase之上，封装了SDS结构化存储的服务，带数据类型和索引的服务给公司使用。还有封装FDS，类似于对象存储S3这样的给生态链公司使用。
七、小米这边投了HBase，阿里也投了，那小米在后续在HBase这边会有什么样的大力支持和投入呢？
张铎(HBase PMC, 小米)：投入还是会继续的，因为自己也在用，而且小米人工智能与云平台的头-崔宝秋，他其实非常注重开源。他在开源界做了很久，当时也是他认为开源肯定是未来大趋势。所以不用担心小米减少支持，而且小米内部有的feature社区肯定都有，我们现在两边一起开发，甚至有的feature先在社区里开发，总体而言我们在社区这边的投入肯定是非常大的。后续的话，可能2.1版本的release我会去申请一下release manager，3.0版本的release可能也是我们这边出一些人来当release manager。
主持人:我们也希望社区能小步快跑，把更好的东西让大家尽快用起来。
八、在风控场景下HBase有什么核心优势?为什么很多企业在风控场景下用HBase？
陈恒(HBase Committer，蚂蚁金服)：其实蚂蚁这边的HBase也是阿里集团这边提供支持的，我们这边的HBase跟集团这边是采取类似于共创的方式做这个事情。之所以落地在HBase的原因是风控的数据量是非常大的，节点是以上千为单位的，在这样的大数据场景下提供单个用户的随机查询，随机读取这整个社区里面是没有非常好的别的选择，HBase是比较好的方案。再一个原因是集团对于的HBase这边有长期的支持，稳定性，可运维能力，performance都非常完善。这是蚂蚁使用HBase的核心原因。
开放性问题：刚刚大家聊下来，感觉HBase是非它不可。但是狭义来讲HBase就是一个非常强悍的KV系统，或者说是一个BigTable，或者Table Store的系统。其实很多中小型公司，它的场景非常多，要有检索，SQL能力，索引，分析等等。那么HBase对这些场景有没有单独的组件支持，或者说社区这边有什么样的考虑？
陈恒(HBase Committer，蚂蚁金服)：HBase就是提供结构化的数据，但是KV系统的话，你可以这么用，但是Hbase并没有提供纯的KV接口。大家对于大多数据库,包括HBase,其实需求最大的是它的可运维能力。我希望我就一个运维团队，一个数据库就能解决所有的场景。这样的话要支持非常大的数据量，高吞吐低延时的performance，还要支持基本实时的OLAP的功能,这样选来选去HBase是一个非常好的选择。
张铎(HBase PMC, 小米)：其实一个系统，生态起来的话，其实不需要担心HBase只能当KV用，肯定会有人在上面搭各种各样东西。时序数据库有OpenTSDB,Phoenix支持Local的二级索引，也有数据库支持全局事务，跨行跨表的操作，然后现在也有各种各样图数据库。开源就是有这点好处，只要有人有需求都可以往上搭。
李钰(HBase PMC, 阿里)：其实我也是认为生态的发展吧。我觉得任何的系统都有它适合的场景，不是说我们做HBase就说它是万能的。但是确实HBase在现在的*的开源项目里面发展的蛮久的，围绕着它也生成了非常多的生态，现在也有很多的大公司在用，我们有很多的生产经验可以借鉴，这是目前很多开源项目不具备的。
王锋(奇虎360大数据负责人)：360未来在IoT的战略需要在某些场景下做一些IoT的数据库，包括时序数据库，包括深度的定制化的东西，它们都有个特点，几乎后端对接的都是以HBase作为比较可靠的支撑。所以说这也是为什么我们要从Cassandra的生态下迁移到HBase的生态下的原因，这也是HBase生态相对比较完善的特点。
杨文龙(HBase Committer, 阿里)：其实今天不是回答HBase能做什么，随着开源生态的包容性和发展，慢慢的已经到了HBase在整个大数据这个领域不能做什么。如果大家仔细了解后发现都能做，那相对于而言，对某些垂直化场景做优化或者做产品，跟HBase这种以底层分布式KV也好，结构化存储也好，为基础衍生各个生态到底有什么差异，这涉及到不同公司，不同环境的要求不一样而走的路会不一样。从目前来看，专用的一定比通用的要好，这是万古不变的道理，但是大家不能忽视的是对于产品的碎片化，对于能源组织的碎片化，对于系统运行环境的碎片化。如果说HBase能做很多场景，那我只需要组建一个HBase团队,用更多的精力去完善产品，完善组织，这样可以满足很多层的需求。但是反而说要为时序，要为图，要为轨迹，要为对象组织十个产品，那没有一个能搞的好。从设计层面来说，专业定制型的设计永远是最佳的。但是从工程角度而言不是最佳的，我们需要把合适的人，合适的环境，聚集到一起，这个产品才是能够适合工业的生产型产品。从这种层面来说，我用HBase比较放心，看起来是万金油，但是我的体量没有那么大的时候其实我们没有必要去为这个场景组织一拨人甚至组织一个系统。那今天HBase已经可以解决很多问题了，剩下的是根据每个人的环境而言，怎么去选择的问题。
姚靖怡(滴滴HBase负责人)：HBase到的能做什么的话，最简单的一个是scan，一个是get,还有一些协处理器的处理。滴滴这边是根据用户的需求从这些纬度上取了一些封装，滴滴也开发了一些工具，HBase周边的一些组件比如实时计算集群等这种数据的流入流出都做了一定的封装，包括跟Hive的操作。根据HBase基础的特性上，根据自己的需求做一些定制化的东西，这是比较重要的。另外我们也做了一些HBase上面相关的组件，比如Phoenix,我们也在进一步的开拓中。
张洸豪(HBase PMC，小米)：HBase社区在国内发展是十分健康的，有阿里，小米在参与，最近又发展了腾讯的committer，还有滴滴，360等。所以我认为社区发展真的是非常健康的。所以这也是选择HBase的理由。
主持人：请各位用一句话为HBase2.0代言。
陈恒(HBase Committer，蚂蚁金服)：HBase2.0你值得拥有。
张铎(HBase PMC, 小米)：HBase2.0高性能的数据库。
李钰(HBase PMC, 阿里)：值得信赖。
王锋(奇虎360大数据负责人)：未来可期。
杨文龙(HBase Committer, 阿里)：加入HBase,成就自己，成就HBase。
姚靖怡(滴滴HBase负责人)：HBase2.0，更快，更高，更强。
张洸豪(HBase PMC, 小米)：希望国内越来越多的人加入HBase社区，共同推动HBase发展。