HBase最佳实践－列族设计优化（转）

转自 网易视频云：HBase最佳实践－列族设计优化

HBase 中属性都是以列族为单位进行设置的，这些属性基本都会或多或少地影响该表的读写性能，有些属性却需要根据场景、根据业务来设置，比如：BLOCKSIZE 属性在不同场景下应该如何设置？COMPRESSION 属性和 DATA_BLOCK_ENCODING 属性，都可以提供压缩功能，应该选择哪个？本文就重点介绍这三个属性的设计原则。

BlockSize 设置

块大小（BlockSize）是 HBase的一个重要配置选项，默认块大小为64K。对于不同的业务数据，块大小的合理设置对读写性能有很大的影响。对块大小的调整，主要取决于两点：

1. 用户平均读取数据的大小。理论上讲，如果用户平均读取数据的大小较小，建议将块大小设置较小，这样可以使得内存可以缓存更多 Block，读性能自然会更好。相反，建议将块大小设置较大。

2. 数据平均键值对规模。
   可以使用 HFile 命令查看平均键值对规模:

> hbase hfile -m -f /${rootDir}/data/${namespace}/${table}/${region}/${columnfamily}/${hfile}
    compression=none,
    cacheConf=CacheConfig:disabled,
    avgKeyLen=30,
    avgValueLen=14,
    entries=45680106,
    length=2621677099

HFile 的平均键值对规模为 30B + 14B = 44B 相对较小，在这种情况下可以适当将块大小调小（例如32KB）。
这样可以使得一个 Block 内不会有太多 KeyValue，KeyValue 太多会增大块内寻址的延迟时间，因为 HBase 在读数据时，一个 Block 内部的查找是顺序查找。

注意： 默认块大小适用于多种数据使用模式，调整块大小是比较高级的操作。配置错误将对性能产生负面影响。因此建议在调整之后进行测试，根据测试结果决定是否调整。

BlockSize 测试

YCSB测试，分别在 Get、Scan 两种场景下测试不同 BlockSize 大小（16K，64K，128K）对性能的影响。

Get

随着 BlockSize 的增大，系统随机读的吞吐量不断降低，延迟不断增大。64K大小比16K大小的吞吐量大约降低13%，延迟增大13%。同样的，128K大小比64K大小的吞吐量降低约22%，延迟增大27%。因此，对于以随机读为主的业务，可以适当调低 BlockSize 的大小，以获得更好的读性能。

Scan

随着 BlockSize 增大，Scan 的吞吐量增大，延迟降低。因此，对于以 Scan 为主的业务，可以适当增大 BlockSize 的大小，以获得更好的读性能。

结论：
如果业务请求以 Get 请求为主，可以考虑将块大小设置较小；
如果以 Scan 请求为主，可以将块大小调大；
默认的64M块大小是在 Scan 和 Get 之间取得的一个平衡。

数据压缩

数据压缩是 HBase 提供的特性，HBase 在写入数据块到 HDFS 之前，会先对数据块进行压缩，再落盘，减少磁盘空间使用量。而在读数据的时候首先从HDFS中加载出 Block 之后进行解压缩，然后再缓存到 BlockCache，最后返回给用户。

写路径和读路径分别如下：

数据压缩对资源使用情况以及读写性能的影响：

• 资源使用情况：

  1. 减少数据硬盘容量，理论上 snappy 压缩率可以达到5:1，具体压缩比例根据真实数据结构有关
  2. 压缩/解压缩需要大量计算，更多的消耗CPU资源
  3. 数据读取到缓存之前 Block 会先被解压，缓存到内存中的 Block 是解压后的，因此和不压缩情况相比，内存没有影响

• 读写性能：

  1. 数据写入是先将 KeyValue 写到缓存，最后再统一 Flush 到硬盘，压缩是在 Flush 这个阶段执行的，因此会影响 Flush 的操作，对写性能本身并不会有太大影响
  2. 数据如果从HDFS中读取的话，首先需要解压缩，因此理论上读性能会有所下降；如果数据是从缓存中读取，缓存中的 Block 已经是解压后的，因此性能不会有任何影响
  3. 如果大多数读都是热点读，缓存读占大部分比例，压缩并不会对读有太大影响。

可见，压缩特性就是使用CPU资源换取磁盘空间资源，对读写性能并不会有太大影响。HBase 目前提供了三种常用的压缩方式：GZip | LZO | Snappy，官方分别从压缩率，编解码速率三个方面对其进行对比：
Snappy 的压缩率最低，但是编解码速率最高，对CPU的消耗也最小，目前一般建议使用 Snappy。

数据编码

除了数据压缩之外，HBase 还提供了数据编码功能。和压缩一样，数据在落盘之前首先会对KV数据进行编码；和压缩不同的地方，数据块在缓存前并没有执行解码，因此即使后续命中缓存的查询也是编码的数据块，需要解码后才能获取到具体的KV数据。

写路径和读路径分别如下：

数据编码对资源使用情况以及读写性能的影响：

• 资源使用情况：

  1. 减少数据硬盘容量，但是数据压缩率一般没有数据压缩的压缩率高，理论上只有5:2
  2. 编码/解码一般也需要大量计算，需要大量CPU资源
  3. 根据读路径来看，数据读取到缓存之前 Block 并没有被解码，缓存到内存中的 Block 是编码后的，因此和不编码情况相比，相同数据量 Block 占用内存更少，即内存利用率更高。

• 读写性能：

  1. 数据编码也是在数据 Flush 到HDFS阶段执行的，因此并不会直接影响写入过程
  2. 前面讲到，数据块是以编码形式缓存到 BlockCache 中的，因此同样大小的 BlockCache 可以缓存更多的数据块，这有利于读性能。另一方面，用户从缓存中加载出来数据块之后并不能直接获取KV，而需要先解码，这却不利于读性能。可见，数据编码在内存充足的情况下会降低读性能，而在内存不足的情况下需要经过测试才能得出具体结论。

HBase 目前提供了四种常用的编码方式：Prefix | Diff | Fast_Diff | Prefix_Tree。

下图是 Prefix_Tree 编码算法作者做的一个测试结果：

可见，prefix_tree 压缩算法在不同的 BlockSize 下性能都比较稳定，而另外两种压缩算法的查找性能会随着 BlockSize 增大直线下降。对于默认的64K的 Block 大小，性能相差40+倍。另外，阿里天梧大牛之前在一篇博文里面做过测试证明了 PREFIX_TREE 算法的优越性，见《HBase-0.96中新BlockEncoding算法-PREFIX_TREE压缩的初步探究及测试》，因此一般建议使用PREFIX_TREE编码压缩。

结论：
数据压缩和数据编码使命基本相同：消耗CPU资源压缩数据大小，可以认为是一种时间换空间的做法。但是同时开启两个功能会不会更好？如果只需要开启一个，优先选择哪一个？

压缩和编码测试

YCSB测试，分别在四种场景下（无压缩无编码、仅压缩、仅编码、既压缩既编码）对随机读以及扫描读的操作延时、CPU使用率以及对应的压缩率进行了测试。

数据：6000万条记录，一个列族，每个列族10个列，单条记录总共1K大小
硬件：3 RegionServer，3G BlockCache，CPU 64 cores

结果分析：

1. 数据压缩率并没有理论上0.2那么高，和数据结构有关系。
2. 随机读场景：
   snappy 压缩在性能上没有提升，CPU开销却上升了38%
   prefix_tree 性能上没有提升，CPU利用率也基本相当
   snappy + prefix_tree 性能没有提升，CPU开销上升了38%
3. 区间扫描场景：
   snappy 压缩在性能上略有10%的提升，但是CPU开销却上升了23%
   prefix_tree 性能上略有4%左右的下降，但是CPU开销也下降了5%
   snappy + prefix_tree 在性能上基本没有提升，CPU开销却上升了23%

设计原则：

1. 在任何场景下开启 prefix_tree 编码都是安全的
2. 在任何场景下都不要同时开启 snappy 压缩和 prefix_tree 编码
3. 通常情况下 snappy 压缩并不能比 prefix_tree 编码获得更好的优化结果，如果需要使用 snappy 需要针对业务数据进行实际测试

---