跟WAL有关的优化参数有：
- hbase.regionserver.maxlogs：Region中的最大WAL文件数量，默认值是32。 当WAL的数量超过这个阀值之后就会引发WAL日志滚动，旧的日志会被清理掉。
- hbase.regionserver.hlog.blocksize：HDFS块大小，没有默认值，如果不设定该值，HBase就会直接调用HDFS的API去获取出。
- hbase.regionserver.logroll.multiplier：WAL文件大小因子。每一个WAL文件所占的大小通过HDFS块大小 * WAL文件大小因子得出。默认值是0.95。
早期关于WAL的设置优化主要是针对如何设置合理的 hbase.regionserver.maxlogs的。maxlogs就是允许有多少个WAL文件同时存在于Region之中，当WAL的数量超过了这个阈值之后就会引发WAL日志滚动，关于WAL日志滚动参见WAL预写日志。
关于如何设置合理的maxlogs数值，Hortonworks给出了建议公式：
(regionserver_heap_size * memstore_fraction) / default_WAL_size- regionserver_heap_size：RegionServer的堆内存大小。
- memstore_fraction：memstore在JVM的堆内存中占用的比例。
- default_WAL_size：单个WAL文件的大小。
举个例子：
regionserver_heap_size：假设集群中的每个RegionServer 的堆内存大小是16GB。
memstore fraction：假设memstore占40%的堆内存大小，那么这个数值就是0.4。
default_WAL_size：假设设定了 hbase.regionserver.logroll.multiplier为0.95，而HDFS的块大小是64MB，那么现在单个WAL文件的大小就是60.8MB，为了计算简单就算60MB。
套用公式就是：(1638MB * 0.4) / 60MB = 109。则WAL大小的上限的最优值是109。
不过，后来HBase舍弃了hbase.regionserver.maxlogs。理由是大多数人并不知道这个公式，所以直接采用了默认值32。但是在上面的例子中，maxlogs轻易地就超过了100。而在例子中的参数其实都是很平常的服务器设置。这就给大多数用户造成了很多不便。
因此在新的版本中，HBase把hbase.regionserver.maxlogs的定义权从用户手中收回。直接由HBase内部自己计算出maxlogs的最优值。
Math.max(32, (regionserverHeapSize * memstoreSizeRatio * 2 / logRollSize))- regionserverHeapSize：RegionServer的堆内存大小。
- memstoreSizeRatio：memstore在JVM的堆内存中占用的比例。
- logRollSize：单个WAL文件的大小。
在新的版本中，如果设置了hbase.regionserver.maxlogs，会得到一句警告'hbase.regionserver.maxlogs' was deprecated。意味设置了也没有什么用。
其实Region级别的优化对性能的提高效果并不是很大， 而对于Store的优化比对Region的优化更重要。
