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)对性能的影响。

《HBase最佳实践-列族设计优化(转)》 Get

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

《HBase最佳实践-列族设计优化(转)》 Scan

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

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

数据压缩

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

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

《HBase最佳实践-列族设计优化(转)》

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

  • 资源使用情况:

    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最佳实践-列族设计优化(转)》

数据编码

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

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

《HBase最佳实践-列族设计优化(转)》

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

  • 资源使用情况:

    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 编码算法作者做的一个测试结果:

《HBase最佳实践-列族设计优化(转)》

可见,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

《HBase最佳实践-列族设计优化(转)》
《HBase最佳实践-列族设计优化(转)》
《HBase最佳实践-列族设计优化(转)》

结果分析:

  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 需要针对业务数据进行实际测试
    原文作者:Alex90
    原文地址: https://www.jianshu.com/p/821d99278d19
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞