HBase性能调优方法(2)

　　hbase.hstore.blockingStoreFiles

　　默认值：7

　　说明：在compaction时，如果一个Store?oulmn Family)内有超过7个storefile需要合并，则block所有的写请求，进行flush，限制storefile数量增长过快。

　　调优：block请求会影响当前region的读写性能，将值设为单个region可以支撑的最大store file数量会是个不错的选择。最大storefile数量可通过region size/memstore size来计算。如果你将region size设为无限大，那么你需要预估一个region可能产生的最大storefile数。

　　hbase.hregion.memstore.block.multiplier

　　默认值：2

　　说明：当一个region里的memstore超过单个memstore.size两倍的大小时，block该region的所有请求，进行flush，释放内存。虽然我们设置了memstore的总大小，比如64M，但想象一下，在最后63.9M的时候，我Put了一个100M的数据或写请求量暴增，最后一秒钟put了1万次，此时memstore的大小会瞬间暴涨到超过预期的memstore.size。这个参数的作用是当memstore的大小增至超过memstore.size时，block所有请求，遏制风险进一步扩大。

　　调优： 这个参数的默认值还是比较靠谱的。如果你预估你的正常应用场景(不包括异常)不会出现突发写或写的量可控，那么保持默认值即可。如果正常情况下，你的写量就会经常暴增，那么你应该调大这个倍数并调整其他参数值，比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit，以预留更多内存，防止HBase server OOM。

　　其他

　　启用LZO压缩

　　LZO对比Hbase默认的GZip，前者性能较高，后者压缩比较高，具体参见 Using LZO Compression 。对于想提高HBase读写性能的开发者，采用LZO是比较好的选择。对于非常在乎存储空间的开发者，则建议保持默认。

　　不要在一张表里定义太多的Column Family

　　Hbase目前不能良好的处理超过2-3个CF的表。因为某个CF在flush发生时，它邻近的CF也会因关联效应被触发flush，最终导致系统产生很多IO。

　　批量导入

　　在批量导入数据到Hbase前，你可以通过预先创建region，来平衡数据的负载。详见 Table Creation: Pre-Creating Regions

　　Hbase客户端优化

　　AutoFlush

　　将HTable的setAutoFlush设为false，可以支持客户端批量更新。即当Put填满客户端flush缓存时，才发送到服务端。

　　默认是true。

　　Scan Caching

　　scanner一次缓存多少数据来scan(从服务端一次抓多少数据回来scan)。

　　默认值是 1，一次只取一条。

　　Scan Attribute Selection

　　scan时建议指定需要的Column Family，减少通信量，否则scan默认会返回整个row的所有数据(所有Coulmn Family)。

　　Close ResultScanners

　　通过scan取完数据后，记得要关闭ResultScanner，否则RegionServer可能会出现问题。

　　Optimal Loading of Row Keys

　　当你scan一张表的时候，返回结果只需要row key(不需要CF, qualifier,values,timestaps)时，你可以在scan实例中添加一个filterList，并设置 MUST_PASS_ALL操作，filterList中add FirstKeyOnlyFilter或KeyOnlyFilter。这样可以减少网络通信量。

　　Turn off WAL on Puts

　　当Put某些非重要数据时，你可以设置writeToWAL(false)，来进一步提高写性能。writeToWAL(false)会在Put时放弃写WAL log。风险是，当RegionServer宕机时，可能你刚才Put的那些数据会丢失，且无法恢复。

　　启用Bloom Filter

　　Bloom Filter通过空间换时间，提高读操作性能。

原文转自：http://kenwublog.com/hbase-performance-tuning