- 八年磨一剑
1.1 HBase 的前世今生
关系型数据库的发展已经经历了 40 多年的历史了，而 HBase 以及大数据这套东 西的历史大概从 2006 年被认为是大数据的发起时期到现在，也就是 13 年左右 而已。那么，为什么会出现 HBase 以及 Hadoop 整体生态链的这些内容呢?这 是因为在大数据时代，传统数据库需要面对很多挑战，出现了数据量增多、业务 复杂度提升、非结构化数据和结构化数据并存等诸多问题。这些问题所带来的最 直接的就是成本挑战，因此特别需要价格低廉的数据库来解决问题。
这也就是 Google 提出 BigTable 开源最佳实现的原因。Google 是全球最大的搜 索引擎，当他们发现出现的存储成本问题之后，通过内部研究就发出来关于 BigTable 的这篇论文，而大概在 2006 年的时候也就发起了 HBase 这个项目，并 且在两年之后其就成为 Hadoop 的子项目，经过了十几年的发展，目前演变到了 2.0 版本。HBase 能够帮助我们以低成本解决大数据量、高并发、低时延的问题， 并且保证了低成本的存储。
1.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 版本相比于开源版本在很多方面也有极大的提升。
1.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 有它自己非常适合的场景，比如高并发、低时延以及低成本需求的场景。
2. 重新定义 HBase
大家都知道开源软件在稳定性以及各方面的能力上都往往不能够达到企业实际 应用的要求。虽然这些开源软件的核心能力非常强大，但是当在企业中应用的时 候却是比较困难的。而阿里巴巴在 HBase 方面做了很多的工作，也经过内部的使 用提升了 HBase 的能力，使其能够更好地适应企业的应用，并且针对不同的场景 提供了不同的产品形态。
2.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.2 重新定义产品形态
HBase 作为开源软件，并没有考虑很多的企业级能力，而阿里云的 HBase 在开源软件的基础之上进行较大的创新和优化。首先针对于不同的业务场景，提供了不 同产品形态的 HBase。在开发测试环境下，可用性要求不高，数据量也不大，而 需要比较低的成本，这时候就可以使用单节点版本。而针对于在线业务，QPS 在 5000 万以内，存储在 10P 以内，需要高可靠、低时延的处理能力，阿里云优先 推荐集群版本。还有第三种双活版本，在很多企业的金融级业务里面，可用性要 求很高，也需要跨 AZ 的高可靠，需要双活版本，一个集群除了故障，另外一个 集群能够实时地进行接管。
除了提供了以上三种不同的产品形态之外，阿里云 HBase 还在可用性、数据冷热 分离、写安全以及二级索引等能力上做了较大的提升。
2.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 小时在线的服务，可以帮助客户搞定一切运维问题。
3.生态和案例
其实企业在选择 HBase 不仅仅是看重的是其高并发、低时延的处理能力，还看重了其背后的大数据生态，因为当有了这样的大数据生态之后将可以做很多的事情。
3.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) 图数据库-HGraphDB，关系分析，风控场景必备
图数据库虽然不常见，但是在很多行业中使用的也非常多，比如关系分析以及风控场景。
(6) Cube-Kylin，面向数据科学家建模专用
在大数据时代，数据的价值的挖掘需要数据科学家来实现。数据科学家在进行 数据建模之前需要将数据拿出来，反复地进行分析，所以需要很多随机的条件下进行，想要得到低时延的反馈就需要建立 Cube 来实现。
3.2 实际客户案例
(1) 客户案例-某车联网公司
对于现在的很多互联网公司而言，往往都需要将数据高并发地写入进来，但是超 期之后数据的价值就会降低，但是因为法律法规等方面政策的要求，这些数据不 能被删除。这样就需要分级存储的能力，能够以很低的成本解决大量数据的存储问题。
**
(2) 客户案例-某大数据风控公司**
(3) 客户案例-某社交公司
对于社交网络而言，比如一个帖子需要瞬间分发给三百万或者五百万用户还需要保证在几十毫秒之内，这样的能力目前只有 HBase 才能做到。案例中的用户使用 了双集群，最高有四个 9 的可靠性，并且其 QPS 能够达到 1 千万以上，能够瞬间将 Feed 流推到所有用户上面去。
(4) 客户案例-某基金公司
对于某基金公司而言，单张表有一万亿以上数据，而对于传统关系型数据库而言， 有个 1000 数据已经非常大了，而像这种百 TB 级别的数据的查询以及少量的更新只能使用 HBase+Phoenix 搞定。
（5) 客户案例-某公司报表系统
某公司的报表系统通过离线提前接好 Cube 实现了数据的实时更新和查询。
在本文中，首先介绍了阿里巴巴集团对于 HBase 的八年研发历程。第二部分，分 享了 HBase 作为一款开源软件在很多企业级软件功能上的不足，所以阿里云重新定义了产品形态，并增强了 HBase 产品能力，使得企业能够更快更好地使用 HBase 服务。最后，选择了 HBase 所代表的不仅仅是 HBase 本身的能力，而是 其背后的整个大数据生态，在未来进行业务能力扩展上也是非常有帮助的。而相 比于传统关系型数据库 40 几年的发展历程，HBase 的短短十几年的发展历史还 是比较短的，在使用门槛上相对比较高，因此阿里云也借助 HBase2.0 版本发布 的契机，联合了一些国内顶尖的公司，比如滴滴和小米，大家一起深度地解读 HBase 的能力和使用场景，也希望大家持续关注后续的相关解读。
技术社群
【HBase生态+Spark社区大群】
群福利：群内每周进行群直播技术分享及问答
加入方式1：点击link申请加入
加入方式2：钉钉扫码加入
