《seo关键解码:网站营销与搜索引擎优化》下载(网易视频云是最佳实践－列族设计优化(组图))

　　《seo关键解码:网站营销与搜索引擎优化》下载(网易视频云是最佳实践－列族设计优化(组图))

　　网易视频云是网易打造的基于云计算的分布式多媒体处理集群和专业音视频技术。PaaS 服务，例如音频和视频。在线教育、远程医疗、娱乐表演、在线金融等行业和企业用户可以通过简单的开发创建一个在线音视频平台。现在，网易视频云就和大家分享一下HBase的最佳实践——列族设计优化。

　　随着大数据的日益普及，HBase也越来越受欢迎。现在使用 HBase 并不难，但是如何更好地使用它并不容易。那么你如何定义“好用”呢？很简单，在保证系统稳定性和可用性的基础上，用最少的系统资源（CPU、IO等）获得最好的性能（吞吐量、读写延迟）。HBase是一个庞大的系统，涉及到很多方面，很多因素都会影响系统性能和系统资源利用率。根据场景优化这些配置，将大大提升系统的性能。作者至少总结了以下几个方面：HDFS相关的配置优化、HBase服务端优化（GC优化、Compaction优化、硬件配置优化）、列族设计优化、客户端优化等。其中，客户端优化通过了前面的超时机制。，重试机制已经讨论过了，接下来笔者将继续分别介绍其他三个优化点。

　　本节重点介绍柱族设计的优化。HBase 中的基本属性以列族为单位进行设置。在下面的示例中，用户创建了一个名为“NewsClickFeedback”的表，该表中只有一个列族“头条”。后面的属性都是这个列族的设置。这些属性基本上都会或多或少地影响表的读写性能，但有些属性用户只需要了解其含义就知道如何设置，而有些属性则需要根据场景和业务来设置，比如不同场景下的BLOCKSIZE属性。应该如何设置？还有COMPRESSION属性和DATA_BLOCK_ENCODING属性，都可以提供压缩，所以应该选哪一个，或者两者都需要设置？本文重点介绍这三个属性的设计原则。

　　块大小设置

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

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

　　为了更好的说明上述原理，作者使用YCSB做了一个测试，测试不同BlockSize大小（16K、64K、128K）在Get和Scan场景下的性能影响。测试结果如下：

　　随着 BlockSize 的增加，系统中随机读的吞吐量降低，延迟增加。与 16K 大小相比，64K 大小降低了约 13% 的吞吐量并增加了 13% 的延迟。同样，128K 大小的吞吐量比 64K 大小低 22% 左右，延迟增加 27%。因此，对于基于随机读取的服务，可以适当降低 BlockSize 以获得更好的读取性能。

　　随着 BlockSize 的增加，scan 的吞吐量逐渐增加，延迟不断减小。与 16K 相比，64K BlockSize 的吞吐量提高了 33%，延迟降低了 24%；与 64K 相比，128K 的吞吐量提高了 7%，延迟降低了 7%；因此，对于基于扫描的服务，可以适当增加 BlockSize 大小以获得更好的读取性能。

　　可以看出，如果业务请求以Get请求为主，可以考虑将block size设置为更小的size；如果主要业务请求是基于Scan请求的，可以增加block size；默认的 64M 块大小是 Scan 和 Get 之间的平衡。.

　　2. 数据平均键值对大小。可以使用 HFile 命令查看平均键值对大小，如下所示：

　　从上面的输出信息可以看出，这个HFile的平均key-value pair size是62B + 93B = 155B，比较小。在这种情况下，可以适当减小块大小（例如，32KB）。这样一来，一个区块中的kv就不会太多了。kv太多会增加block内寻址的延迟时间，因为HBase在读取数据时，block内的查找是顺序查找。

　　注意：默认块大小适用于各种数据使用模式，调整块大小是一项高级操作。配置错误会对性能产生负面影响。所以建议调整后进行测试，根据测试结果决定是否可以在线使用。

　　数据编码/压缩

　　压缩/解压缩

　　数据压缩是 HBase 提供的另一个特性。在将数据块写入HDFS之前，HBase会先对数据块进行压缩，然后再放到磁盘上，从而减少磁盘空间的使用。读取数据时，首先从HDFS加载block，然后解压，然后缓存在BlockCache中，最后返回给用户。写路径和读路径如下：

　　结合上图，我们来看看数据压缩对资源使用和读写性能的影响：

　　(1）资源使用：压缩最直接最重要的作用就是减少数据硬盘的容量。理论上snappy压缩比可以达到5:1，但是根据测试数据，压缩比例在理论上可能并不理想。；压缩/解压无疑需要大量的计算，需要大量的CPU资源；根据读取路径，在将数据读入缓存之前将块解压，将块缓存在内存是解压的，所以和未压缩的情况不同，对比起来，前后对内存基本没有影响。

　　(2）读写性能：因为数据写入是先将kv数据值写入缓存，最后统一flush硬盘，并且在flush阶段进行压缩，所以会影响flush性能本身不会有太大影响；如果从HDFS读取数据，需要先解压，所以理论上读取性能会下降；如果从缓存中读取数据，因为缓存中的block块文件已经解压，所以不会对性能产生任何影响；一般情况下，大部分读都是热读，缓存读占大部分，压缩对读影响不大。

　　可以看出，压缩特性是用CPU资源换取磁盘空间资源，对读写性能影响不大。HBase 目前提供了三种常用的压缩方式： GZip | 左旋 | 活泼。下表是压缩率和编解码率的官方对比：

　　一般来说，Snappy 的压缩率最低，但编解码率最高，CPU 消耗最少。目前，一般推荐使用 Snappy。

　　编码/解码

　　除了数据压缩，HBase 还提供数据编码能力。与压缩一样，KV 数据在放入磁盘之前先进行编码；但与压缩不同的是，数据块在被缓存之前不会被解码，因此即使是后续命中缓存的查询也是编码数据块，需要先解码才能解码。获取特定的 KV 数据。写路径和读路径如下：

　　再来看看数据压缩对资源使用和读写性能的影响：

　　(1）资源使用：和压缩一样，编码最直接最重要的作用就是降低数据硬盘的容量，但是数据压缩率一般没有数据压缩那么高，理论上只有5 :2; encoding/Decoding一般需要大量的计算，需要大量的CPU资源；根据读取路径，在数据读入缓存之前不对block块解码，对缓存在内存中的block进行编码，所以与不编码的情况相比，相同的数据块占用内存更少，即内存利用率更高。

　　(2）读写性能：和数据压缩一样，数据编码也是在数据flush到hdfs的阶段进行的，所以不直接影响写入过程；前面说过，数据块缓存到blockcache因此，同样大小的blockcache可以缓存更多的数据块，有利于读取性能；另一方面，用户从缓存中加载数据块后，无法直接获取KV，而是需要先解码，不利于Read性能，可见数据编码在内存充足的情况下会降低读取性能，需要在内存不足的情况下进行测试才能得出具体结论。

　　HBase 目前提供了四种常用的编码方式： Prefix | 差异 | Fast_Diff | 前缀树。下图是Prefix_Tree编码算法作者做的一个测试结果：

　　可以看出prefix_tree压缩算法在不同块大小下的性能比较稳定，而其他两种压缩算法的搜索性能会随着块大小线性下降。对于我们默认的 64K 块大小，性能差异是 40+ 倍。另外，阿里天武大牛在一篇博文中做了一个测试，证明了PREFIX_TREE算法的优越性。见《HBase-0.96新的BlockEncoding算法-PREFIX_TREE压缩的初步探索与测试》，所以一般推荐使用PREFIX_TREE编码进行压缩。

　　选择哪一个？为什么？

　　综上分析，数据压缩和数据编码有着基本相同的使命：消耗CPU资源来压缩数据大小可以认为是一种时间换空间的方式。但是同时开启这两个功能不是更好吗？如果只需要启用一项，应该首选哪一项？

　　为了对数据压缩编码有更深入的了解并回答以上两个问题，我在测试环境中使用YCSB做了一个简单的测试，在四种场景下（不压缩不编码，只压缩，只编码，压缩和压缩）编码））测试了随机读取和扫描读取的操作延迟，CPU使用率和相应的压缩比。

　　测试条件：

　　数据：6000w条记录，一个列族，每个列族10列，单条记录总大小1K；

　　硬件：Single RegionServer，3G BlockCache，CPU：32 Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz

　　检测结果：

　　结果分析：

　　1.数据压缩率理论上没有0.2高，只有0.7左右，和数据结构有关。其中，压缩、编码、压缩+编码的压缩率基本相同。

　　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，需要对业务数据进行实际测试

　　至此，本文主要介绍了HBase的一个优化方向：列族设计优化。重点介绍不同场景下BlockSize对读写性能的影响，以及Compress和Data_Block_Encoding的设计原则。希望评委能在以上基础上对HBase的列族优化有更好的了解，并能通过更多的测试巩固理解。需要注意的是，这里的设计原则对大部分应用服务都有效，可能不适用于一些特殊场景。因此，对于更敏感的业务，以实际测试为准。

　　更多技术分享请关注网易视频云官方网站()或网易视频云官方微信（vcloud163）交流咨询）

　　seo标签描述返利区