统一内容平台主要承担vivo内容生态的内容审核、内容理解、内容智作和内容分发等核心功能，通过聚合全网内容，建设行业级的业务中台和内容生态，为上下游提供优质可靠的一站式服务，目前服务的业务方包括视频业务、泛信息流业务等。

作为一个内容中台，每天要新增存储大量图文和视频内容来满足分发的需要。与此同时，对这些内容加工处理的数据也都需要存储，包括基础信息，分类标签信息，审核信息等等。而且不仅仅是需要存储的数据量级很大，对数据的读取和写入操作也非常频繁，当前对数据库的读写主要集中在两个方面：

在经过多年累积后，当前存储的数据量越变越大，并且可以预见数据量级会不断膨胀下去，如何选择一种可靠的存储选型，来保证服务稳定性和扩展性成了当前项目架构的重中之重。

在选用HBase之前，内容平台核心数据的存储以Mongodb为主要存储选型，但是在日常的使用中，发现存储侧存在如下一些痛点问题：

所以我们迫切需要寻找一个更适合当前场景的数据库来满足业务请求量和存储大小日益增长的需求，并且要求具备高性能、高稳定、可扩展、低维护成本的特性。

经过一些调研后发现HBase的一些特性能很好地满足当前场景的要求。

（2）高扩展性、高容错性
HBase的存储是基于Hadoop的，Hadoop实现了一个分布式文件系统（HDFS），HDFS的副本机制使得其具有高容错性的特点，并且HDFS的Federation机制使得其具有高扩展性。基于Hadoop意味着HBase与生俱来的超强扩展性和高容错性。

（4）列值支持多版本
HBase的多版本特性可以针对某个列族控制列值的版本数，默认是1，即每个key保存一个版本，同一个rowkey的情况下，后面的列值会覆盖前面的列值。可以动态修改列族的版本数，每个版本使用时间戳进行标记，默认是写入时间作为该版本的时间戳，也可以在写入时指定时间戳。

综合以上特性，HBase是非常适合当前项目对数据库选型的要求。

随着HBase在整个项目中逐步扩大使用，也发现了一些使用规范问题以及一些查询的性能问题。比如查询毛刺比较多、夜间Compact期间耗时比较高、流量高峰期的时候少量请求会有延迟。针对这些问题，我们从下面四个方面，对HBase的使用进行了优化。

4.1 集群升级

升级前

升级后

4.2 连接池使用和连接预热

4.3 按列读取

HBase建表的时候是不需要确定列的，因为列是可变的，它非常灵活，唯一需要确定的就是列族。一张表的很多属性比如过期时间、数据块缓存以及是否压缩等都是定义在列族上，而不是定义在表上或者列上，这一点做法跟以往的数据库有很大的区别。同一个表里的不同列族可以有完全不同的属性配置，但是同一个列族内的所有列都会有相同的属性。一个没有列族的表是没有意义的，因为列必须依赖列族而存在，所以在HBase中一个列的名称前面总是带着它所属的列族。列族存在使得HBase会把相同列族的列尽量放在同一台机器上，不同列族的列分布在不同的机器上。

一般情况下，从客户端发起请求读取数据，到数据返回大致有如下几步：

 简单的示意图如下所示：

整个过程中如果读取字段过多，或者字段长度过大，那么返回所有列的数据会导致大量无效的数据传输，进而导致集群网络带宽等系统资源被大量占用，必然导致读取性能降低，所以需要减少一些不必要字段的查询。

Get类是HBase官方提供的查询类，在该类中主要有以下几个方法提供来实现减少字段读取：

当前项目中没有使用到HBase的版本范围和版本数量的特性，但是主要场景使用的表字段都比较多（如内容的基本属性能达到上百个字段），或者字段的大小都比较大（如内容解析的一些向量字段），原本在查询时，都是直接读取所有字段，导致很多字段其实不需要使用也被一直读取，浪费性能。通过改用按列读取的方式来实现不同场景下不同字段的查询，避免了超过一半无用字段的返回，平均响应时间也下降了一些。

4.4 compact优化

HBase是基于LSM树存储模型的分布式NoSQL数据库。LSM树相比于普遍使用在各种数据库的B+树来说，能够获得较高随机写性能的同时，也能保持可靠的随机读性能。在进行读请求的时候，LSM树要把多个子树（类似B+树结构）进行归并查询， 因此归并查询的子树数越少，查询的性能就越高。当MemStore超过阀值的时候，就要flush到HDFS上生成一个HFile。因此随着不断写入，HFile的数量将会越来越多，根据前面所述，HFile数量过多会降低读性能。为了避免对读性能的影响，可以对这些HFile进行compact操作，把多个HFile合并成一个HFile。compact操作需要对HBase的数据进行多次的重新读写，因此这个过程会产生大量的IO。可以看到compact操作的本质就是以IO操作换取后续的读性能的提高。

HBase的compact是针对HRegion的HFile文件进行操作的。compact操作分为major和minor两种。major compaction会把所有的HFile都compact为一个HFile，并同时忽略标记为delete的KeyValue（被删除的KeyValue只有在compact过程中才真正被"删除"），可以想象major compaction会产生大量的IO操作，对HBase的读写性能产生影响。minor则只会选择数个HFile文件compact为一个HFile，minor的过程一般较快，而且IO相对较低。在业务高峰期间，都会禁止major操作，只在业务空闲的时段定时执行。

4.5 字段级版本管理

除了上述提到的优化点，我们也探索了一些HBase的其它特性，以备将来用来优化其他方面。上文提到，通过对HBase进行按列读取数据，可以减少get查询的时间，通常意义来讲，列（也就是每个字段）已经是每条数据的最基本单位了，但是HBase中的数据粒度比传统数据结构更细一级，同一个位置的数据还细分成多个版本，一个列上可以存储多个版本的值，多个版本的值被存储在多个单元格里面，多个版本之间用版本号（ version）来区分。所以，唯一确定一条结果的表达式应该是行键:列族:列:版本号（rowkey:column family:column:version）。不过，版本号通常是可以省略的，如果写入时不写版本号，每个列或者单元格的值都被赋予一个时间戳，这个时间戳默认是由系统制定的，当然写入时也可以由用户显式指定具体的版本号。在查询时如果不指定版本号，HBase默认获取最后一个版本的数据返回给你。当然也可以指定版本号返回需要的其他版本的数据。简单的示意图如下所示：

同时HBase为了避免数据存在过多的版本造成不必要的负担，HBase提供了两种数据版本的回收方式，一是按照数量维度，保存最后的n个版本，二是按照时间维度，保存最近一段时间的版本数据，比如保存一个月。通过多版本同时存储，对于一些有时序要求的场景非常友好，通过指定版本的时间戳，可以避免在已经更新了新数据的情况下，被旧数据覆盖。当前我们建表是都是只指定了一个版本，使用也都是用的以时间戳为版本号的默认版本，没有采取版本管理的措施，不同单元格可以记录多版本的特性可以考虑应用于字段更新时记录下多个版本的数据，在不影响读写效率的情况下，方便后续在没有相关日志的情况下，回溯最近几次更新的值，并且可以防止误操作或数据损坏，因为用户可以恢复到之前的版本数据。此外我们的系统中存在一些通过消息队列异步更新场景，此时可以使用消息体中的时间戳作为当前版本号，这样可以在多线程消费时，也能保证消费的时序性，因为低版本的版本号无法更新高版本的版本号。

本文在对统一内容平台在数据库选型分析和优化的基础上，简要介绍了HBase在实际使用中的一些优化方案，经优化后，项目整体读取和写入性能都有比较明显的提升，较好的保障了统一内容平台业务的稳定性，并且大大降低了业务侧的运维成本。Hbase本身就具备强大的功能，在大数据领域有独有的优势，但是在不同的业务场景，对于HBase的要求也是不一样的，可以结合具体的实际情况，从使用的数据库版本、从HBase底层机制的调参、从客户端调用机制的优化等多方面挖掘，探索更适合业务的方式，希望本文中提到的一些优化方案能给读者带来一些启发。