Apache HBase 的现状和发展

一、ＨBase 是什么

HBase(Hadoop Database)，是一个基于 Google BigTable 论文设计的高可靠性、高性能、可伸缩的分布式存储系统。

它有以下特征：

1.HBase 仍然是采用行存储的，采用松散表的结构来获得动态列的功能；

2.原生海量数据分布式存储。在单个数据库中可以存档 GB 甚至上 pb。在一行中也可以存储上百万列。任何大小的数据量都适合采用 HBase；

3.不仅支持随机查询，还支持范围查询；

4.高吞吐，低延迟。一个集群可以有上千万个 dps，平均的延迟可以做到一毫秒之内；

5.在线 NOSQL 数据库；

6.多版本，增量导入，多维删除。

1.1 HBase 的四大基因

1.1.1 自动分区

最开始的时候，我们的数据库是单机的数据库。慢慢的我们发现单机的数据库无法承受数据和访问的爆发式增长。因此就出现了分库分表的方案。将数据库和表拆分到多个服务器上，然后利用中间件作为一个路由。这里就会遇到一个问题，随着数据的增加，中间件就会成为一个瓶颈。如果请求量爆发式增长的时候，要加载新的进去，整个物理的变化需要进行搬迁之后才能够进行使用。

而在 HBase 中，使用的是自动分区功能。当访问量和请求量增加的时候它可以自动的进行数据分片，以应对数据和请求的爆发式增长。

1.1.2 LSM-Tree

LSM(Log Structured Merge)Tree，它的一个重要的功能就是随机写变成顺序写。

现在 LSM 模型是大数据库的标配。它主要包括如下几个特点：

1）写吞吐量高；

2）不受 hdd 随机写瓶颈和 ssd 随机写入放大干扰；

3）超强数据导入能力。

1.1.3 存储计算分离

HBase 本身不会存任何数据。数据都是存储在底层的 HDFS 中。存储计算分离有以下好处：负载均衡更高效、资源扩容更节省、存储优化更便捷。

1.1.4　ＨBase 生态

HBase 有一个非常强大的朋友圈。具体见下：

1.2 场景

HBase 是几乎可以满足所有的大数据场景需求。比如说对象存储，比如说推荐系统。比如说用来存储订单，用来存储聊天记录。高性能推送的朋友圈应用的场景。针对一些其他的场景，我们可以利用 HBase 加上组件能力来实现这些场景的应用。比如说 HBase 加 Linux，来实现 NEWSQL 的数据库。比如说 HBase 加上 geomesa 来实现时空数据的存储，滴滴就是采用这种方案来存储他们的轨迹数据。在物联网场景，可以采用 HBase 加 openjsdb 来存储海量的时序数据。

1.3 使用 HBase 的商业公司

基本上每一个大型的公司都在使用 HBase。

1.4 HBase 特性总结

HBase，为大数据而生，有 LSM 树：离线导入效率巨高 、实时写入吞吐大、增量导入隔离性强；伸缩性强；TTL：数据时效性，系统自动处理、时效性的个性化设置；多版本：数据的第三维度、高效删除方式；动态列：数据发散的利器；协处理器：数据校正、高效适应个性化；异构介质多副本存储：海量与实时的性价比满足；Erasure Code：因大而生。

二、ＨBase 社区的发展

2.1　HBase 的起源

HBase 于 2006 年诞生于 Powerset,一家从事自然语言处理和搜索的创业公司(后被微软收购)

HBase 的实现基于 Google 发布的 BigTable 论文，用来解决 Hadoop 中随机读写效率低下的问题。HBase 最初的开发人员是 MichaelStack 和 JimKellerman。2007 年 4 月，HBase 做为一个模块提交到 Hadoop 的代码库中，代码量~8000 行，2010 年 5 月 HBase 成为 Apache 的顶级项目，同年，Facebook 把 HBase 使用在其消息平台中。

2.2　HBase 项目现状

目前 HBase 的代码已经超过 100 万行，HBase 仍然是最活跃的 Apache 项目之一，拥有 76 个 Committer，42 位 PMC，共有 328 位 Contributor，其中 14 位 Committer/PMC 来自中国。

2.3　HBase 目前版本

ＨBase 目前版本众多。见下图：

三、ＨBase2.0

3.1 HBase2.0 版本发布历史

HBase2.0 的发布是一部血泪史，因为在四年前已经有这个版本了，由于一些因素，造成了没有人管理。最后花了一年多的时间才稳定他的版本发布出来，他的 Release Manger 多次更换，才把他发布出来。由此，我们吸取了这次教训，我们以后会做好版本控制，把控好发布的节奏。

3.2 新功能

3.2.1 Region Replica

Region Replica 这个功能在 1.2 版本中已经存在，但是为什么叫做新功能呢？是因为之后修改了很多 bug，在 1.4 版本才稳定下来，然后 1.4 和 2.0 是同时发布的。在 CAP 理论中,HBase 一直是一个 CP 系统，遵循强一致的读写语义，所以 Server 宕机后需要一定的恢复时间，如果宕机了，客户端可以从另外的副本中去读取数据，Region Replica 为数据分片 Region 准备了多个副本,host 在不同的 RegionServer 上，同时，客户端也可以做到，对多个副本同时发请求，然后做到选择最快速的那个副本，提供高可用读，宕机 0 影响，规避抖动，毛刺，降低 P999 延迟；缺点是需要额外耗费 CPU/Memory 资源，但不会占用额外空间。

3.2.2 读写链路 Off-heap

第二个新功能是全链路 Off-heap，意思就是读写链路数据端到端 Off-heap，减少 java GC 带来的停顿，进一步降低 P999 延迟，提高吞吐。这个功能我们从两方面来实现的：写链路 Off-heap，我们使用在 RPC 层使用 Netty 的 Off-heap ByteBuffer，使用支持 Off-heap 的 Protobuf。同时使用 Off-heap 的 Chunk 来存储 Memstore 中的 KeyValue。

在读链路 Off-heap 方面，使用 Off-heap 的 Bucket Cache，HBase 自己管理内存的，我们从 Bucket Cache 读取数据的时候，先要从 Protobuf 做一次拷贝，因为可能读取的时候，发生内存不够了，再次分配的情况。在读取对 Bucket Cache 进行引用计数，保证读取的时候，内存不会被回收掉，读取时不再需要先拷贝到 heap，对 Bucket Cache 进行了一系列性能优化。

后面这是 HBase 官方放着阿里巴巴在双十一对 HBase 优化之后的对比图，可以看到优化之后他的请求的曲线更加平稳，吞吐量增长了 30%，这个案例大家可以去 HBase 的官方去看一下。

3.2.3 In Memory Compaction

在 HBase2.0 中另外一个重磅的功能就是 In Memory Compaction，以前我们知道 HBase 中使用的数据结构是 java 中原生的跳表，但是跳表依然是一个松散的结构，这样的话，虽然内存不断的在增大，但是刷到之后，会造成通过 In memory 的 flush 不会到 hdfs 上，反而回转到更加紧凑的 CellArrayMap 这个结构，同时多个 CellArrayMap 会在内存中做 compaction，使内存的使用更加紧凑。然后通过 In memory 的 flush 和 compaction,在内存中可以存储更多的数据，因此可以提高读性能，同时减少磁盘 IO，减轻 compaction 小文件造成的写放大。这个功能社区也有介绍。

3.2.4 小对象存储 MOB

之前我们建议在 HBase 上不要存很大的 KV 值，但是 MOB(Moderate Object Storage) 功能使 HBase 能高效地存储那些 100k~10M 中等大小的对象。这使得用户可以把文档、图片对象保存到 HBase 系统中，用户写入的小对象 flush 成一个独立文件，原有的 KV 中的 value 只存这个对象的引用路径，对于存储对象文件,更少地进行 compaction 来减少写入放大效应。

3.2.5 Assignment MangerV2

这是一个非常重要的模块，HBase 中的状态流转，建表删表，都需要在 Assignment MangerV2 上进行，之前旧 AM 系统参与角色多,状态更新混乱，效率低，无事务保证，容易出现 RIT 问题。所以 AM V2 使用 ProcedureV2 来保证 Table/Region 状态转换在 master 重启后仍然能恢复执行，然后去除了 Zookeeper 做为中间角色，Master/RegionServer 直接交互，Region assign/unassgin 速度大大提升。

3.2.6 其他

在 HBase2.0 中，还有非常多的新功能，具体如下：

3.3 兼容性和升级建议

建议如下：

四、ＨBase 未来规划

4.1 HBaseConAsia & 开发者圆桌会议

HBase 众多开发者也会参加这个会议，参与讨论它的未来发展方向。

4.2 更加易用

HBase 已经提供了，Java 的 API，但是这个案例不太友好，我们目前打算提供 Native 的 SQL 接口，能够做到轻量级的 SQL 支持、内置的二级索引方案、与 Spark SQL 更好地结合等功能。

4.3 更高性能

在以后的版本中，不用在对 HBase 的性能担心了，我们在以后的版本中准备从 Use CCSMap to improve HBase YGC tim、全链路异步化、基于非易失存储的 WALLess 方案等方面努力成为 LSM 模型下性能最好的 Java 存储引擎。

4.4 更强扩展性和稳定性

这个方面我们以下几个方面来解决：

五、如何成为 Committer

作者介绍

杨文龙，阿里巴巴技术专家。HBase 社区 Committer&PMC，Ali-HBase 内核负责人，对分布式存储系统的设计、实践具备丰富的大规模生产的经验。

本文来自杨文龙在 DataFun 社区的演讲，由 DataFun 编辑整理。