网易视频云：HBase最佳实践-列族设计优化选编.docx

网易视频云：HBase最佳实践－列族设计优化 随着大数据的越来越普及，HBase也变得越来越流行。会用HBase现在已经变的并不困难，然而，怎么把它用的更好却并不简单。那怎么定义‘用的好’呢？很简单，在保证系统稳定性、可用性的基础上能够用最少的系统资源（CPU,IO等）获得最好的性能（吞吐量，读写延迟）就是’用的好’。HBase是一个庞大的体系，涉及到很多方面，很多因素都会影响到系统性能和系统资源使用率，根据场景对这些配置进行优化会很大程度上提升系统的性能。笔者总结至少有如下几个方面：HDFS相关配置优化，HBase服务器端优化（GC优化、Compaction优化、硬件配置优化），列族设计优化，客户端优化等，其中客户端优化在前面已经通过超时机制、重试机制讲过，后面笔者会继续分别介绍其他三个优化重点。 本节重点介绍列族设计优化，HBase中基本属性都是以列族为单位进行设置的，如下示例，用户创建了一张称为‘ NewsClickFeedback’的表，表中只有一个列族’Toutiao’，紧接着的属性都是对此列族进行的设置。这些属性基本都会或多或少地影响该表的读写性能，但有些属性用户只需要理解其意义就知道如何设置，而有些属性却需要根据场景、根据业务来设置，比如BLOCKSIZE属性在不同场景下应该如何设置？还有COMPRESSION属性和DATA_BLOCK_ENCODING属性，两者都可以提供压缩功能，那到底应该选择哪个，还是两个都需要进行设置？本文就重点介绍这三个属性的设计原则。 BlockSize设置 块大小是HBase的一个重要配置选项，默认块大小为64M。对于不同的业务数据，块大小的合理设置对读写性能有很大的影响。而对块大小的调整，主要取决于两点： 1. 用户平均读取数据的大小。理论上讲，如果用户平均读取数据的大小较小，建议将块大小设置较小，这样可以使得内存可以缓存更多block，读性能自然会更好。相反，建议将块大小设置较大。 为了更好说明上述原理，笔者使用YCSB做了一个测试，分别在Get、Scan两种场景下测试不同BlockSize大小（16K，64K，128K）对性能的影响。测试结果分别如下面两图： 随着BlockSize的增大，系统随机读的吞吐量不断降低，延迟不断增大。64K大小??16K大小的吞吐量大约降低13%，延迟增大13%。同样的，128K大小比64K大小的吞吐量降低约22%，延迟增大27%。因此，对于以随机读为主的业务，可以适当调低BlockSize的大小，以获得更好的读性能。  随着BlockSize增大，scan的吞吐量逐渐增大，延迟不断降低。64K大小BlockSize比16K大小的吞吐量增加了33%，延迟降低了24%；128K大小比64K大小吞吐量增加了7%，延迟降低了7%；因此，对于以scan为主的业务，可以适当增大BlockSize的大小，以获得更好的读性能。 可见，如果业务请求以Get请求为主，可以考虑将块大小设置较小；如果以Scan请求为主，可以将块大小调大；默认的64M块大小是在Scan和Get之间取得的一个平衡。 2. 数据平均键值对规模。可以使用HFile命令查看平均键值对规模，如下： 从上面输出的信息可以看出，该HFile的平均键值对规模为62B + 93B = 155B，相对较小，在这种情况下可以适当将块大小调小（例如32KB）。这样可以使得一个block内不会有太多kv，kv太多会增大块内寻址的延迟时间，因为HBase在读数据时，一个block内部的查找是顺序查找。 注意：?默认块大小适用于多种数据使用模式，调整块大小是比较高级的操作。配置错误将对性能产生负面影响。因此建议在调整之后进行测试，根据测试结果决定是否可以线上使用。 数据编码/压缩 Compress/DeCompress 数据压缩是HBase提供的另一个特性，HBase在写入数据块到HDFS之前会首先对数据块进行压缩，再落盘，从而可以减少磁盘空间使用量。而在读数据的时候首先从HDFS中加载出block块之后进行解压缩，然后再缓存到BlockCache，最后返回给用户。写路径和读路径分别如下：  结合上图，来看看数据压缩对资源使用情况以及读写性能的影响： （1） 资源使用情况：压缩最直接、最重要的作用即是减少数据硬盘容量，理论上snappy压缩率可以达到5:1，但是根据测试数据不同，压缩率可能并没有理论上理想；压缩/解压缩无疑需要大量计算，需要大量CPU资源；根据读路径来看，数据读取到缓存之前block块会先被解压，缓存到内存中的block是解压后的，因此和不压缩情况相比，内存前后基本没有任何影响。 （2） 读写性能：因为数据写入是先将kv数据值写到缓存，最后再统一flush的硬盘，而压缩是在flush这个阶段执行