摘要：2018年6月6日，阿里云ApsaraDB for HBase2.0正式发布！从2010年开始“试水”到2018年，拥有了3个PMC，6个Committer，拥有中国最多HBase Committer的公司之一的阿里巴巴是如何八年磨一剑，重新定义HBase的？本文中，阿里云技术专家所在就为你揭晓答案。
本文内容根据演讲嘉宾PPT以及视频整理而成。
一、八年磨一剑
二、重新定义HBase
三、生态和案例
首先，本文会为大家分享HBase的前世今生以及HBase在阿里巴巴的发展过程，为大家讲解什么叫做“八年磨一剑”。在这之后将为大家介绍HBase使用的场景以及一些相关问题，希望能够帮助大家更好地理解HBase，帮助大家在未来更好地使用HBase。第二部分将分享对于HBase的重新定义，为大家解读最新的HBase 2.0版本的能力以及其最新的能力到底是什么。此外，因为HBase的生态是开源的，要将HBase用得好，用得方便，用得稳，这中间还欠缺很多企业级软件的能力。而阿里云在这个过程中做了很多的工作，因此在这部分也将为大家介绍阿里云HBase的整体产品形态以及阿里云为了帮助企业和用户更好地使用HBase和享受到HBase的能力做了哪些事情。在第三部分将整体地介绍HBase的生态以及一些实际的客户案例。因为当客户选择使用HBase就不仅仅意味着只使用了HBase，而是代表选择了HBase背后整个大数据生态，因此可以使用整个Hadoop生态的能力，并在这部分的最后将为大家分享一些实际客户的案例，帮助大家更好地使用和理解HBase。
一、八年磨一剑
1. HBase的前世今生
首先为大家分享HBase的发展历程。关系型数据库的发展已经经历了40多年的历史了，而HBase以及大数据这套东西的历史大概从2006年被认为是大数据的发起时期到现在，也就是13年左右而已。那么，为什么会出现HBase以及Hadoop整体生态链的这些内容呢？这是因为在大数据时代，传统数据库需要面对很多挑战，出现了数据量增多、业务复杂度提升、非结构化数据和结构化数据并存等诸多问题。这些问题所带来的最直接的就是成本挑战，因此特别需要价格低廉的数据库来解决问题。
这也就是Google提出BigTable开源最佳实现的原因。Google是全球最大的搜索引擎，当他们发现出现的存储成本问题之后，通过内部研究就发出来关于BigTable的这篇论文，而大概在2006年的时候也就发起了HBase这个项目，并且在两年之后其就成为Hadoop的子项目，经过了十几年的发展，目前演变到了2.0版本。HBase能够帮助我们以低成本解决大数据量、高并发、低时延的问题，并且保证了低成本的存储。
2. 阿里的HBase之旅
为何叫做“八年磨一剑”呢？这其实与阿里巴巴对于HBase的研发历程是紧密相关的。在2010年，HBase正式成为了Apache的顶级项目，与此同时阿里巴巴内部的业务也达到了瓶颈期，因此在2010年阿里巴巴开始对于HBase进行预研，经过了持续8年的研发，在2017年的时候输出到阿里云上，并将HBase的能力提供给广大的用户。其实，在阿里集团内部已经有了超过12000台的HBase服务器规模，而最大集群也超过了2000台，这在世界上都是数一数二的，并且也经过了天猫“双11”的历练。
阿里投入了很多资源和人力来研发HBase，所以开源社区也给予了非常积极的回馈。目前第一个东八区的PMC就诞生在阿里云，而整个阿里集团内有3个HBase PMC、6个Committer以及几十位核心贡献者，并且共享了200多个核心patch。此外，阿里云的HBase版本相比于开源版本在很多方面也有极大的提升。
3. Hbase适合的场景和问题
(1) 关系型数据库与HBase的区别
HBase等NoSQL出现的原因是传统的关系型数据库在面对大数据量、高业务复杂度以及高成本的挑战时，无法对于底层进行优化和改进。如下图所示的表格能够帮助大家对比关系型数据库与HBase的主要区别。
关系型数据的主要应用场景基本都是交易类场景，而HBase所代表的的非关系型数据库所需要解决的就是兼容结构化和非结构化的数据，解决交易场景之外的实时业务或者OLAP分析以及大规模存储。而在可扩展性上，关系型数据库单表不超过千列，一般在GB~TB级别，而对于HBase而言，这样的数据量就不算什么挑战了，一张表会轻松突破百亿行和百万列，HBase比较适合200G到10P数据量级别。在性能方面也能体现出关系型数据和HBase最大的区别，对于关系型数据库而言，10W级别的性能就已经很强了，HBase能力能够达到5000万并发量，其核心需要解决的就是高并发和低吞吐。在成本方面，传统关系型数据库需要使用高性能硬件，随着也带来了成本问题，而HBase则是选择了另外一条路，通过本地盘和普通CPU实现，其核心的存储结构不再是关系型存储结构，而是合并成批量读写，充分地利用硬盘高吞吐的能力来达到低成本。总结而言，HBase数据库解决的核心问题就是兼容结构化和非结构化的数据、大数据量、高并发、低延时等问题。
(2) ApsaraDB HBase典型场景
NoSQL数据库和传统数据的一个较大区别就是传统数据库比较适合所以行业的交易模型，而HBase的能力非常聚焦，其适合时序数据、时空数据、Cube分析、NewSQL、Feeds流、消息/订单存储、推荐画像、对象存储等8个场景。接下来逐一介绍各个典型场景。
时序数据：在如今这个IoT的时代，出现了大量的时序数据。因为各种传感器比较多，时序数据需要满足高并发、海量存储等基本要求，除了IoT之外，在股票以及监控数据里面也需要用到这样的时序数据。
时空数据：轨迹以及气象网格数据也需要HBase的高并发和海量存储能力。
Cube分析：实时报表以及数据科学家需要进行实时数据分析，这些需要以很低的时延查询出来，并且并发量非常高，这时候就需要用到Cube的能力。
NewSQL：对于传统SQL所不能解决的一些问题，比如性能瓶颈，这些就需要使用NewSQL能力，并且除了能够解决性能问题之外，还会有一定的更新能力。HBase能够较好地适应这种场景，除了支持SQL之外，还支持二级索引、动态增加列，所以很多元数据库也使用了HBase。
Feeds流：Feeds流的典型应用场景就是微信朋友圈以及微博等社交网络，其所需要的就是高并发的请求访问，因为用户数非常多，需要保证一致性体验，HBase非常适合这样的场景。
消息/订单存储：订单数量是非常多的，所以需要强同步，并且可靠性不能丢，对于聊天消息而言也是一样的，这就会用到HBase的强一致性同步以及大数据存储能力。
推荐画像：推荐画像在用户特征里面使用的比较多，一般而言在做画像时对于用户会勾画很多特征，数据表中的每一列就可以放一个特征，而随着不断深入地挖掘，特征就会越来越多，而传统关系型数据库首先不能够存储太多列，超过1000列就遇到瓶颈了，而在真正进行存储的时候可能需要百万列。其次，对于传统关系型数据库而言，如果某列存在空值，依然占据空间，而HBase不仅可以动态地增加列，而且如果某列为空就不会占据空间，所以非常适合这样的场景。
对象存储：通常而言对象存储最可能用到的就是OSS，但是OSS比较适合高并发地写，但是并不适合高并发地读，但是还有很多数据比如图片、网页、文档、新闻等，除了需要能够写入之外，还需要提供高并发地查询能力的场景下，就比较适合使用HBase作为前置数据存储。而如果随着时间的迁移，一些数据的重要性降低了，那就可以通过HBase本身的能力将数据迁移到OSS里面，作为温数据或者冷数据的归档。
上面大致分享了HBase的整个发展历程以及HBase的适合场景。总结而言，就是阿里巴巴经过了8年的研发将自己改进的HBase版本能够提供给广大的用户，这就叫做8年磨一剑。这首先说明了阿里巴巴有很强的技术实力，其次说明了HBase有它自己非常适合的场景，比如高并发、低时延以及低成本需求的场景。
二、重新定义HBase
大家都知道开源软件在稳定性以及各方面的能力上都往往不能够达到企业实际应用的要求。虽然这些开源软件的核心能力非常强大，但是当在企业中应用的时候却是比较困难的。而阿里巴巴在HBase方面做了很多的工作，也经过内部的使用提升了HBase的能力，使其能够更好地适应企业的应用，并且针对不同的场景提供了不同的产品形态。
1. HBase2.0解读
HBase 2.0版本是本次重点发布的版本。实际上，社区在2014年6月开始迭代，经过了4年的时间，终于在2018年4月30日正式发布。而阿里巴巴也立即将原来的一些能力反向地融合到HBase最新的版本中，并且经过了稳定性和性能测试，这个版本将会在6月6日正式发布公测。
HBase 2.0版本经过四年时间的研发，其在架构上也发生了较大的变化，在性能以及稳定性上也有了较大的提升。总结而言，产生了两个最有价值的场景，其中一个是大容量、高并发、低延时的写场景，相比于1.X版本，HBase 2.0版本提升了稳定性，将内存全部放在堆外进行管理，不再完全依赖JVM，这是因为JVM存在一些始终难于解决的问题。此外HBase 2.0版本还提升了性能，对于资源管理器进行了优化，解决了性能毛刺问题。此外，性能的增强还体现在了时延的提升上。HBase处理时延可以稳定在50ms以内。这个对HBase来说拓宽了一个大容量推荐场景；这个也是其他目前数据库引擎不具备的能力。例如金融，社交朋友圈等行业有广泛的诉求。另外一个场景就是高性能对象存储场景，以前包括阿里集团更多的是适合结构化的数据的存储。HBase 2.0版本支持高效对象存储，能高效地存储那些100k~10M中等大小的对象。有了这个能力之后，就相当于在对象存储能力上有了非常强的提升，可以包装出一种新的产品形态或者场景，解决不满意对象存储性能的，对性能有一定要求的大容量对象存储的需求。这样的能力预计在传媒，教育，企业办公等领域有广泛的诉求。HBase 2.0不仅能够提供很强大的写能力之外，还能够提供很强大的读能力。
2.重新定义产品形态
HBase作为开源软件，并没有考虑很多的企业级能力，而阿里云的HBase在开源软件的基础之上进行较大的创新和优化。首先针对于不同的业务场景，提供了不同产品形态的HBase。在开发测试环境下，可用性要求不高，数据量也不大，而需要比较低的成本，这时候就可以使用单节点版本。而针对于在线业务，QPS在5000万以内，存储在10P以内，需要高可靠、低时延的处理能力，阿里云优先推荐集群版本。还有第三种双活版本，在很多企业的金融级业务里面，可用性要求很高，也需要跨AZ的高可靠，需要双活版本，一个集群除了故障，另外一个集群能够实时地进行接管。
除了提供了以上三种不同的产品形态之外，阿里云HBase还在可用性、数据冷热分离、写安全以及二级索引等能力上做了较大的提升。
3. 重新定义HBase能力
(1) 存储计算分离，真正的弹性
存储计算分离这个特性是非常有价值的能力，虽然在现在企业往往也能够自己搭建HBase服务器，但是却很难实现存储计算分离的能力。这是因为业务会飞速发展变化，所以难以在最初规划时确定究竟多少资源是足够的，后续扩充就会变得比较麻烦，也会造成资源的浪费和比较高的成本。在阿里云上做了存储于计算分离，使得存储和计算可以分开进行计费，可以单独扩充存储或者计算资源，这极大地有利于企业业务的灵活变化，同样也极大地降低了成本。
(2) 多重防护机制，企业级安全
大家都知道开源版本的HBase基本上没有安全能力，完全属于“裸奔”状态。这使得企业数据的安全性无法得到有效的保证，因此阿里云在HBase的安全方面也做了大量的工作。比如权限控制管理上，提供了账号密码验证、ACL权限控制以及抵御恶意数据损毁上，这些方面阿里云都贡献了很大的能力。而在VPC隔离、防DDOS攻击以及IP白名单配置上，阿里云也做了非常多的事情，通过多重机制保证用户的数据安全以及可靠性。
(3) 全量和增量备份以及恢复，数据无丢失风险
对于企业而言，最具有价值的就是数据，因此企业所最担心的也就是数据的丢失。借助阿里云HBase的全量和增量备份以及恢复的能力则能够尽量降低数据丢失的风险。首先，阿里云在机器里面有高可靠的能力，其次再通过全量或者增量备份一份数据到对象存储里面来。如果万一出现了数据故障，也能够迅速地将数据恢复回来，不会有数据丢失的风险，这对于DBA或者企业而言，能够有效地对于数据进行保障。
(4) 内核级优化，性能和稳定性全面提升
阿里云具备可以称得上东半球对于HBase最强的研发实力，这也是能够非常深刻地体现到阿里云HBase产品里面的一点。如上图所示的是用阿里云HBase与社区的HBase的一个版本进行的对比情况，可以看到随机读最高可以提升200%以上，而随机写提升50%以上。此外，在稳定性方面还实现了读写分离机制，能够确保读写不会冲突，进而保证稳定性。
(5) 重新定义运维能力，客户基本免运维
大家都知道，21世纪最具有价值的就是人才，HBase的确非常好，但是其使用起来的难度也非常高，因为其技术难度的门槛放在那里，如果没有能力较强的人才，很难帮助企业恢复数据，并且实时地保障业务的平稳运行。而阿里云所提供的HBase版本基本上能够实现客户免运维。在阿里云提供的运维自动化里面，专家会提供24小时在线的服务，可以帮助客户搞定一切运维问题。
三、生态和案例
其实企业在选择HBase不仅仅是看重的是其高并发、低时延的处理能力，还看重了其背后的大数据生态，因为当有了这样的大数据生态之后将可以做很多的事情。
1. 使用场景和生态
(1) NewSQL-Phoenix支持二级索引，解决TP数据性能瓶颈
在NewSQL方面，阿里云HBase默认搭配了Phoenix组件，这样就可以用标准的SQL接口去访问数据。此外，相比于开源版本，阿里云的HBase在扩展性方面也有极大的提升，在这里面可以实现更新、高并发的读写。并且Phoenix还支持二级索引能力，进而可以进一步提升性能。
(2) HTAP-同时支持TP和AP
当需要大数据分析能力时，HBase就需要结合大数据生态中一个非常重要的组件——Spark。Spark可以通过三种方式访问数据，而每种方式都有自己不同的特点，比如直接通过API的方式，比较简单，但是只适合基本的使用；其次可以使用Spark SQL，其自带了算子下推、schema映射以及各种参数调优的能力；第三种就是在打批量访问的时候可以直接访问HFile进行分析。HBase搭配Spark可以实现混合的TP和AP能力。
(3) 时序-OpenTSDB&HiTSDB，IoT场景首选
HBase本身自带了开源组件OpenTSDB，直接搭配就可以满足时序需求。
(4) 时空-GeoMesa
HBase结合GeoMesa的能力就可以将三维的精度、维度以及时间进行降维，得到一维的数据并存储到HBase里面。
(5) 图数据库-JanusGraph，关系分析，风控场景必备
图数据库虽然不常见，但是在很多行业中使用的也非常多，比如关系分析以及风控场景。
(6) Cube-Kylin，面向数据科学家建模专用
在大数据时代，数据的价值的挖掘需要数据科学家来实现。数据科学家在进行数据建模之前需要将数据拿出来，反复地进行分析，所以需要很多随机的条件下进行，想要得到低时延的反馈就需要建立Cube来实现。
2. 实际客户案例
(1) 客户案例-某车联网公司
对于现在的很多互联网公司而言，往往都需要将数据高并发地写入进来，但是超期之后数据的价值就会降低，但是因为法律法规等方面政策的要求，这些数据不能被删除。这样就需要分级存储的能力，能够以很低的成本解决大量数据的存储问题。
(2) 客户案例-某大数据风控公司
大数据风控公司通过爬虫或者ECS上的APP记录传感器等将数据收集上来，并对于用户进行画像，这就用到了HBase的画像能力以及稀疏矩阵存储能力。
(3) 客户案例-某社交公司
对于社交网络而言，比如一个帖子需要瞬间分发给三百万或者五百万用户还需要保证在几十毫秒之内，这样的能力目前只有HBase才能做到。案例中的用户使用了双集群，最高有四个9的可靠性，并且其QPS能够达到1千万以上，能够瞬间将Feed流推到所有用户上面去。
(4) 客户案例-某基金公司
对于某基金公司而言，单张表有一万亿以上数据，而对于传统关系型数据库而言，有个1000数据已经非常大了，而像这种百TB级别的数据的查询以及少量的更新只能使用HBase+Phoenix搞定。
(5) 客户案例-某公司报表系统
某公司的报表系统通过离线提前接好Cube实现了数据的实时更新和查询。
总结
在本文中，首先介绍了阿里巴巴集团对于HBase的八年研发历程。第二部分，分享了HBase作为一款开源软件在很多企业级软件功能上的不足，所以阿里云重新定义了产品形态，并增强了HBase产品能力，使得企业能够更快更好地使用HBase服务。最后，选择了HBase所代表的不仅仅是HBase本身的能力，而是其背后的整个大数据生态，在未来进行业务能力扩展上也是非常有帮助的。而相比于传统关系型数据库40几年的发展历程，HBase的短短十几年的发展历史还是比较短的，在使用门槛上相对比较高，因此阿里云也借助HBase2.0版本发布的契机，联合了一些国内顶尖的公司，比如滴滴和小米，大家一起深度地解读HBase的能力和使用场景，也希望大家持续关注后续的相关解读。
本文由云栖志愿小组贾子甲整理，编辑不与
本文内容根据演讲嘉宾PPT以及视频整理而成。
一、八年磨一剑
二、重新定义HBase
三、生态和案例
首先，本文会为大家分享HBase的前世今生以及HBase在阿里巴巴的发展过程，为大家讲解什么叫做“八年磨一剑”。在这之后将为大家介绍HBase使用的场景以及一些相关问题，希望能够帮助大家更好地理解HBase，帮助大家在未来更好地使用HBase。第二部分将分享对于HBase的重新定义，为大家解读最新的HBase 2.0版本的能力以及其最新的能力到底是什么。此外，因为HBase的生态是开源的，要将HBase用得好，用得方便，用得稳，这中间还欠缺很多企业级软件的能力。而阿里云在这个过程中做了很多的工作，因此在这部分也将为大家介绍阿里云HBase的整体产品形态以及阿里云为了帮助企业和用户更好地使用HBase和享受到HBase的能力做了哪些事情。在第三部分将整体地介绍HBase的生态以及一些实际的客户案例。因为当客户选择使用HBase就不仅仅意味着只使用了HBase，而是代表选择了HBase背后整个大数据生态，因此可以使用整个Hadoop生态的能力，并在这部分的最后将为大家分享一些实际客户的案例，帮助大家更好地使用和理解HBase。
一、八年磨一剑
1. HBase的前世今生
首先为大家分享HBase的发展历程。关系型数据库的发展已经经历了40多年的历史了，而HBase以及大数据这套东西的历史大概从2006年被认为是大数据的发起时期到现在，也就是13年左右而已。那么，为什么会出现HBase以及Hadoop整体生态链的这些内容呢？这是因为在大数据时代，传统数据库需要面对很多挑战，出现了数据量增多、业务复杂度提升、非结构化数据和结构化数据并存等诸多问题。这些问题所带来的最直接的就是成本挑战，因此特别需要价格低廉的数据库来解决问题。
2. 阿里的HBase之旅
为何叫做“八年磨一剑”呢？这其实与阿里巴巴对于HBase的研发历程是紧密相关的。在2010年，HBase正式成为了Apache的顶级项目，与此同时阿里巴巴内部的业务也达到了瓶颈期，因此在2010年阿里巴巴开始对于HBase进行预研，经过了持续8年的研发，在2017年的时候输出到阿里云上，并将HBase的能力提供给广大的用户。其实，在阿里集团内部已经有了超过12000台的HBase服务器规模，而最大集群也超过了2000台，这在世界上都是数一数二的，并且也经过了天猫“双11”的历练。
3. Hbase适合的场景和问题
(1) 关系型数据库与HBase的区别
HBase等NoSQL出现的原因是传统的关系型数据库在面对大数据量、高业务复杂度以及高成本的挑战时，无法对于底层进行优化和改进。如下图所示的表格能够帮助大家对比关系型数据库与HBase的主要区别。
(2) ApsaraDB HBase典型场景
NoSQL数据库和传统数据的一个较大区别就是传统数据库比较适合所以行业的交易模型，而HBase的能力非常聚焦，其适合时序数据、时空数据、Cube分析、NewSQL、Feeds流、消息/订单存储、推荐画像、对象存储等8个场景。接下来逐一介绍各个典型场景。
时空数据：轨迹以及气象网格数据也需要HBase的高并发和海量存储能力。
Cube分析：实时报表以及数据科学家需要进行实时数据分析，这些需要以很低的时延查询出来，并且并发量非常高，这时候就需要用到Cube的能力。
NewSQL：对于传统SQL所不能解决的一些问题，比如性能瓶颈，这些就需要使用NewSQL能力，并且除了能够解决性能问题之外，还会有一定的更新能力。HBase能够较好地适应这种场景，除了支持SQL之外，还支持二级索引、动态增加列，所以很多元数据库也使用了HBase。
Feeds流：Feeds流的典型应用场景就是微信朋友圈以及微博等社交网络，其所需要的就是高并发的请求访问，因为用户数非常多，需要保证一致性体验，HBase非常适合这样的场景。
消息/订单存储：订单数量是非常多的，所以需要强同步，并且可靠性不能丢，对于聊天消息而言也是一样的，这就会用到HBase的强一致性同步以及大数据存储能力。
推荐画像：推荐画像在用户特征里面使用的比较多，一般而言在做画像时对于用户会勾画很多特征，数据表中的每一列就可以放一个特征，而随着不断深入地挖掘，特征就会越来越多，而传统关系型数据库首先不能够存储太多列，超过1000列就遇到瓶颈了，而在真正进行存储的时候可能需要百万列。其次，对于传统关系型数据库而言，如果某列存在空值，依然占据空间，而HBase不仅可以动态地增加列，而且如果某列为空就不会占据空间，所以非常适合这样的场景。
对象存储：通常而言对象存储最可能用到的就是OSS，但是OSS比较适合高并发地写，但是并不适合高并发地读，但是还有很多数据比如图片、网页、文档、新闻等，除了需要能够写入之外，还需要提供高并发地查询能力的场景下，就比较适合使用HBase作为前置数据存储。而如果随着时间的迁移，一些数据的重要性降低了，那就可以通过HBase本身的能力将数据迁移到OSS里面，作为温数据或者冷数据的归档。
上面大致分享了HBase的整个发展历程以及HBase的适合场景。总结而言，就是阿里巴巴经过了8年的研发将自己改进的HBase版本能够提供给广大的用户，这就叫做8年磨一剑。这首先说明了阿里巴巴有很强的技术实力，其次说明了HBase有它自己非常适合的场景，比如高并发、低时延以及低成本需求的场景。
二、重新定义HBase
大家都知道开源软件在稳定性以及各方面的能力上都往往不能够达到企业实际应用的要求。虽然这些开源软件的核心能力非常强大，但是当在企业中应用的时候却是比较困难的。而阿里巴巴在HBase方面做了很多的工作，也经过内部的使用提升了HBase的能力，使其能够更好地适应企业的应用，并且针对不同的场景提供了不同的产品形态。
1. HBase2.0解读
HBase 2.0版本是本次重点发布的版本。实际上，社区在2014年6月开始迭代，经过了4年的时间，终于在2018年4月30日正式发布。而阿里巴巴也立即将原来的一些能力反向地融合到HBase最新的版本中，并且经过了稳定性和性能测试，这个版本将会在6月6日正式发布公测。
HBase 2.0版本经过四年时间的研发，其在架构上也发生了较大的变化，在性能以及稳定性上也有了较大的提升。总结而言，产生了两个最有价值的场景，其中一个是大容量、高并发、低延时的写场景，相比于1.X版本，HBase 2.0版本提升了稳定性，将内存全部放在堆外进行管理，不再完全依赖JVM，这是因为JVM存在一些始终难于解决的问题。此外HBase 2.0版本还提升了性能，对于资源管理器进行了优化，解决了性能毛刺问题。此外，性能的增强还体现在了时延的提升上。HBase处理时延可以稳定在50ms以内。这个对HBase来说拓宽了一个大容量推荐场景；这个也是其他目前数据库引擎不具备的能力。例如金融，社交朋友圈等行业有广泛的诉求。另外一个场景就是高性能对象存储场景，以前包括阿里集团更多的是适合结构化的数据的存储。HBase 2.0版本支持高效对象存储，能高效地存储那些100k~10M中等大小的对象。有了这个能力之后，就相当于在对象存储能力上有了非常强的提升，可以包装出一种新的产品形态或者场景，解决不满意对象存储性能的，对性能有一定要求的大容量对象存储的需求。这样的能力预计在传媒，教育，企业办公等领域有广泛的诉求。HBase 2.0不仅能够提供很强大的写能力之外，还能够提供很强大的读能力。
2.重新定义产品形态
HBase作为开源软件，并没有考虑很多的企业级能力，而阿里云的HBase在开源软件的基础之上进行较大的创新和优化。首先针对于不同的业务场景，提供了不同产品形态的HBase。在开发测试环境下，可用性要求不高，数据量也不大，而需要比较低的成本，这时候就可以使用单节点版本。而针对于在线业务，QPS在5000万以内，存储在10P以内，需要高可靠、低时延的处理能力，阿里云优先推荐集群版本。还有第三种双活版本，在很多企业的金融级业务里面，可用性要求很高，也需要跨AZ的高可靠，需要双活版本，一个集群除了故障，另外一个集群能够实时地进行接管。
3. 重新定义HBase能力
(1) 存储计算分离，真正的弹性
(2) 多重防护机制，企业级安全
(3) 全量和增量备份以及恢复，数据无丢失风险
(4) 内核级优化，性能和稳定性全面提升
(5) 重新定义运维能力，客户基本免运维
三、生态和案例
其实企业在选择HBase不仅仅是看重的是其高并发、低时延的处理能力，还看重了其背后的大数据生态，因为当有了这样的大数据生态之后将可以做很多的事情。
1. 使用场景和生态
(1) NewSQL-Phoenix支持二级索引，解决TP数据性能瓶颈
(2) HTAP-同时支持TP和AP
(3) 时序-OpenTSDB&HiTSDB，IoT场景首选
(4) 时空-GeoMesa
(5) 图数据库-JanusGraph，关系分析，风控场景必备
(6) Cube-Kylin，面向数据科学家建模专用
2. 实际客户案例
(1) 客户案例-某车联网公司
(2) 客户案例-某大数据风控公司
(3) 客户案例-某社交公司
(4) 客户案例-某基金公司
(5) 客户案例-某公司报表系统
总结
在本文中，首先介绍了阿里巴巴集团对于HBase的八年研发历程。第二部分，分享了HBase作为一款开源软件在很多企业级软件功能上的不足，所以阿里云重新定义了产品形态，并增强了HBase产品能力，使得企业能够更快更好地使用HBase服务。最后，选择了HBase所代表的不仅仅是HBase本身的能力，而是其背后的整个大数据生态，在未来进行业务能力扩展上也是非常有帮助的。而相比于传统关系型数据库40几年的发展历程，HBase的短短十几年的发展历史还是比较短的，在使用门槛上相对比较高，因此阿里云也借助HBase2.0版本发布的契机，联合了一些国内顶尖的公司，比如滴滴和小米，大家一起深度地解读HBase的能力和使用场景，也希望大家持续关注后续的相关解读。
本文由云栖志愿小组贾子甲整理，编辑不与
