HBase性能优化

配置优化zookeeper.session.timeout
默认值：3分钟（180000ms）
说明：RegionServer与Zookeeper间的连接超时时间。当超时时间到后，ReigonServer会被Zookeeper从RS集群清单中移除，HMaster收到移除通知后，会对这台server负责的regions重新balance，让其他存活的RegionServer接管.
调优：
这个timeout决定了RegionServer是否能够及时的failover。设置成1分钟或更低，可以减少因等待超时而被延长的failover时间。
不过需要注意的是，对于一些Online应用，RegionServer从宕机到恢复时间本身就很短的（网络闪断，crash等故障，运维可快速介入），如果调低timeout时间，反而会得不偿失。因为当ReigonServer被正式从RS集群中移除时，HMaster就开始做balance了（让其他RS根据故障机器记录的WAL日志进行恢复）。当故障的RS在人工介入恢复后，这个balance动作是毫无意义的，反而会使负载不均匀，给RS带来更多负担。特别是那些固定分配regions的场景。

hbase.regionserver.handler.count
默认值：10
说明：RegionServer的请求处理IO线程数。
调优：
这个参数的调优与内存息息相关。
较少的IO线程，适用于处理单次请求内存消耗较高的Big PUT场景（大容量单次PUT或设置了较大cache的scan，均属于Big PUT）或ReigonServer的内存比较紧张的场景。
较多的IO线程，适用于单次请求内存消耗低，TPS要求非常高的场景。设置该值的时候，以监控内存为主要参考。
这里需要注意的是如果server的region数量很少，大量的请求都落在一个region上，因快速充满memstore触发flush导致的读写锁会影响全局TPS，不是IO线程数越高越好。


hbase.hregion.max.filesize
默认值：256M
说明：在当前ReigonServer上单个Reigon的最大存储空间，单个Region超过该值时，这个Region会被自动split成更小的region。
调优：
小region对split和compaction友好，因为拆分region或compact小region里的storefile速度很快，内存占用低。缺点是split和compaction会很频繁。
特别是数量较多的小region不停地split, compaction，会导致集群响应时间波动很大，region数量太多不仅给管理上带来麻烦，甚至会引发一些Hbase的bug。
一般512以下的都算小region。
大region，则不太适合经常split和compaction，因为做一次compact和split会产生较长时间的停顿，对应用的读写性能冲击非常大。此外，大region意味着较大的storefile，compaction时对内存也是一个挑战。
当然，大region也有其用武之地。如果你的应用场景中，某个时间点的访问量较低，那么在此时做compact和split，既能顺利完成split和compaction，又能保证绝大多数时间平稳的读写性能。
既然split和compaction如此影响性能，有没有办法去掉？
compaction是无法避免的，split倒是可以从自动调整为手动。
只要通过将这个参数值调大到某个很难达到的值，比如100G，就可以间接禁用自动split（RegionServer不会对未到达100G的region做split）。
再配合RegionSplitter这个工具，在需要split时，手动split。
手动split在灵活性和稳定性上比起自动split要高很多，相反，管理成本增加不多，比较推荐online实时系统使用。
内存方面，小region在设置memstore的大小值上比较灵活，大region则过大过小都不行，过大会导致flush时app的IO wait增高，过小则因store file过多影响读性能。

hbase.regionserver.global.memstore.upperLimit/lowerLimit
默认值：0.4/0.35

upperlimit说明：hbase.hregion.memstore.flush.size 这个参数的作用是当单个Region内所有的memstore大小总和超过指定值时，flush该region的所有memstore。RegionServer的flush是通过将请求添加一个队列，模拟生产消费模式来异步处理的。那这里就有一个问题，当队列来不及消费，产生大量积压请求时，可能会导致内存陡增，最坏的情况是触发OOM。
这个参数的作用是防止内存占用过大，当ReigonServer内所有region的memstores所占用内存总和达到heap的40%时，HBase会强制block所有的更新并flush这些region以释放所有memstore占用的内存。

lowerLimit说明： 同upperLimit，只不过lowerLimit在所有region的memstores所占用内存达到Heap的35%时，不flush所有的memstore。它会找一个memstore内存占用最大的region，做个别flush，此时写更新还是会被block。lowerLimit算是一个在所有region强制flush导致性能降低前的补救措施。在日志中，表现为 “** Flush thread woke up with memory above low water.”
调优：这是一个Heap内存保护参数，默认值已经能适用大多数场景。
参数调整会影响读写，如果写的压力大导致经常超过这个阀值，则调小读缓存hfile.block.cache.size增大该阀值，或者Heap余量较多时，不修改读缓存大小。
如果在高压情况下，也没超过这个阀值，那么建议你适当调小这个阀值再做压测，确保触发次数不要太多，然后还有较多Heap余量的时候，调大hfile.block.cache.size提高读性能。
还有一种可能性是 hbase.hregion.memstore.flush.size保持不变，但RS维护了过多的region，要知道 region数量直接影响占用内存的大小。

hfile.block.cache.size
默认值：0.2
说明：storefile的读缓存占用Heap的大小百分比，0.2表示20%。该值直接影响数据读的性能。
调优：当然是越大越好，如果写比读少很多，开到0.4-0.5也没问题。如果读写较均衡，0.3左右。如果写比读多，果断默认吧。设置这个值的时候，你同时要参考 hbase.regionserver.global.memstore.upperLimit ，该值是memstore占heap的最大百分比，两个参数一个影响读，一个影响写。如果两值加起来超过80-90%，会有OOM的风险，谨慎设置。

hbase.hstore.blockingStoreFiles
默认值：7
说明：在flush时，当一个region中的Store（Coulmn Family）内有超过7个storefile时，则block所有的写请求进行compaction，以减少storefile数量。
调优：block写请求会严重影响当前regionServer的响应时间，但过多的storefile也会影响读性能。从实际应用来看，为了获取较平滑的响应时间，可将值设为无限大。如果能容忍响应时间出现较大的波峰波谷，那么默认或根据自身场景调整即可。

hbase.hregion.memstore.block.multiplier
默认值：2
说明：当一个region里的memstore占用内存大小超过hbase.hregion.memstore.flush.size两倍的大小时，block该region的所有请求，进行flush，释放内存。
虽然我们设置了region所占用的memstores总内存大小，比如64M，但想象一下，在最后63.9M的时候，我Put了一个200M的数据，此时memstore的大小会瞬间暴涨到超过预期的hbase.hregion.memstore.flush.size的几倍。这个参数的作用是当memstore的大小增至超过hbase.hregion.memstore.flush.size 2倍时，block所有请求，遏制风险进一步扩大。
调优： 这个参数的默认值还是比较靠谱的。如果你预估你的正常应用场景（不包括异常）不会出现突发写或写的量可控，那么保持默认值即可。如果正常情况下，你的写请求量就会经常暴长到正常的几倍，那么你应该调大这个倍数并调整其他参数值，比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit，以预留更多内存，防止HBase server OOM。

hbase.hregion.memstore.mslab.enabled
默认值：true
说明：减少因内存碎片导致的Full GC，提高整体性能。
调优：详见 http://kenwublog.com/avoid-full-gc-in-hbase-using-arena-allocation
其他
启用LZO压缩
LZO对比Hbase默认的GZip，前者性能较高，后者压缩比较高，具体参见 Using LZO Compression 。对于想提高HBase读写性能的开发者，采用LZO是比较好的选择。对于非常在乎存储空间的开发者，则建议保持默认。

不要在一张表里定义太多的Column Family
Hbase目前不能良好的处理超过包含2-3个CF的表。因为某个CF在flush发生时，它邻近的CF也会因关联效应被触发flush，最终导致系统产生更多IO。

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

避免CMS concurrent mode failure
HBase使用CMS GC。默认触发GC的时机是当年老代内存达到90%的时候，这个百分比由 -XX:CMSInitiatingOccupancyFraction=N 这个参数来设置。concurrent mode failed发生在这样一个场景：
当年老代内存达到90%的时候，CMS开始进行并发垃圾收集，于此同时，新生代还在迅速不断地晋升对象到年老代。当年老代CMS还未完成并发标记时，年老代满了，悲剧就发生了。CMS因为没内存可用不得不暂停mark，并触发一次stop the world（挂起所有jvm线程），然后采用单线程拷贝方式清理所有垃圾对象。这个过程会非常漫长。为了避免出现concurrent mode failed，建议让GC在未到90%时，就触发。
通过设置 -XX:CMSInitiatingOccupancyFraction=N
这个百分比， 可以简单的这么计算。如果你的 hfile.block.cache.size 和 hbase.regionserver.global.memstore.upperLimit 加起来有60%（默认），那么你可以设置 70-80，一般高10%左右差不多。
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可能会出现问题（对应的Server资源无法释放）。

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通过空间换时间，提高读操作性能。
 

一、服务端调优

 1、参数配置

   1）、hbase.regionserver.handler.count：该设置决定了处理RPC的线程数量，默认值是10，通常可以调大，比 如：150，当请求内容很大（上MB，比如大的put、使用缓存的scans）的时候，如果该值设置过大则会占用过多的内存，导致频繁的GC，或者出现 OutOfMemory，因此该值不是越大越好。

 

  2）、hbase.hregion.max.filesize ：配置region大 小，0.94.12版本默认是10G，region的大小与集群支持的总数据量有关系，如果总数据量小，则单个region太大，不利于并行的数据处理， 如果集群需支持的总数据量比较大，region太小，则会导致region的个数过多，导致region的管理等成本过高，如果一个RS配置的磁盘总量为 3T*12=36T数据量，数据复制3份，则一台RS服务器可以存储10T的数据，如果每个region最大为10G，则最多1000个region，如 此看，94.12的这个默认配置还是比较合适的，不过如果要自己管理split，则应该调大该值，并且在建表时规划好region数量和rowkey设 计，进行region预建，做到一定时间内，每个region的数据大小在一定的数据量之下，当发现有大的region，或者需要对整个表进行 region扩充时再进行split操作，一般提供在线服务的hbase集群均会弃用hbase的自动split，转而自己管理split。

 

  3）、hbase.hregion.majorcompaction：配置major合并的间隔时间，默认为1天，可设置为0，禁止自动的 major合并，可手动或者通过脚本定期进行major合并，有两种compact：minor和major，minor通常会把数个小的相邻的 storeFile合并成一个大的storeFile，minor不会删除标示为删除的数据和过期的数据，major会删除需删除的数据，major合并 之后，一个store只有一个storeFile文件，会对store的所有数据进行重写，有较大的性能消耗。

 

  4）、hbase.hstore.compactionThreshold：HStore的storeFile数量>= compactionThreshold配置的值，则可能会进行compact，默认值为3，可以调大，比如设置为6，在定期的major compact中进行剩下文件的合并。

  5）、 hbase.hstore.blockingStoreFiles：HStore的storeFile的文件数大于配置值，则在 flush memstore前先进行split或者compact，除非超过hbase.hstore.blockingWaitTime配置的时间，默认为7，可 调大，比如：100，避免memstore不及时flush，当写入量大时，触发memstore的block，从而阻塞写操作。

 

  6）、hbase.regionserver.global.memstore.upperLimit：默认值0.4，RS所有 memstore占用内存在总内存中的upper比例，当达到该值，则会从整个RS中找出最需要flush的region进行flush，直到总内存比例 降至该数限制以下，并且在降至限制比例以下前将阻塞所有的写memstore的操作，在以写为主的集群中，可以调大该配置项，不建议太大，因为block cache和memstore cache的总大小不会超过0.8，而且不建议这两个cache的大小总和达到或者接近0.8，避免OOM，在偏向写的业务时，可配置为 0.45，memstore.lowerLimit保持0.35不变，在偏向读的业务中，可调低为0.35，同时memstore.lowerLimit 调低为0.3，或者再向下0.05个点，不能太低，除非只有很小的写入操作，如果是兼顾读写，则采用默认值即可。

 

  7）、hbase.regionserver.global.memstore.lowerLimit：默认值0.35，RS的所有 memstore占用内存在总内存中的lower比例，当达到该值，则会从整个RS中找出最需要flush的region进行flush，配置时需结合 memstore.upperLimit和block cache的配置。

 

  8）、file.block.cache.size：RS的block cache的内存大小限制，默认值0.25，在偏向读的业务中，可以适当调大该值，具体配置时需试hbase集群服务的业务特征，结合memstore的内存占比进行综合考虑。

 

  9）、hbase.hregion.memstore.flush.size：默认值128M，单位字节，超过将被flush到hdfs，该值比较适中，一般不需要调整。

 

  10）、hbase.hregion.memstore.block.multiplier：默认值2，如果memstore的内存大小已 经超过了hbase.hregion.memstore.flush.size的2倍，则会阻塞memstore的写操作，直到降至该值以下，为避免发生 阻塞，最好调大该值，比如：4，不可太大，如果太大，则会增大导致整个RS的memstore内存超过memstore.upperLimit限制的可能 性，进而增大阻塞整个RS的写的几率。如果region发生了阻塞会导致大量的线程被阻塞在到该region上，从而其它region的线程数会下降，影 响整体的RS服务能力，例如：

开始阻塞：

 
 解开阻塞：
 
 从10分11秒开始阻塞到10分20秒解开，总耗时9秒，在这9秒中无法写入，并且这期间可能会占用大量的RS handler线程，用于其它region或者操作的线程数会逐渐减少，从而影响到整体的性能，也可以通过异步写，并限制写的速度，避免出现阻塞。

 

  11）、hfile.block.index.cacheonwrite：在index写入的时候允许put无根（non-root）的多级索引块到block cache里，默认是false，设置为true，或许读性能更好，但是是否有副作用还需调查。

 

  12）、io.storefile.bloom.cacheonwrite：默认为false，需调查其作用。

 

  13）、hbase.regionserver.regionSplitLimit：控制最大的region数量，超过则不可以进行 split操作，默认是Integer.MAX，可设置为1，禁止自动的split，通过人工，或者写脚本在集群空闲时执行。如果不禁止自动的 split，则当region大小超过hbase.hregion.max.filesize时会触发split操作（具体的split有一定的策略，不 仅仅通过该参数控制，前期的split会考虑region数据量和memstore大小），每次flush或者compact之 后，regionserver都会检查是否需要Split，split会先下线老region再上线split后的region，该过程会很快，但是会存 在两个问题：1、老region下线后，新region上线前client访问会失败，在重试过程中会成功但是如果是提供实时服务的系统则响应时长会增 加；2、split后的compact是一个比较耗资源的动作。

 

  14）、Jvm调整：

       a、内存大小：master默认为1G，可增加到2G，regionserver默认1G，可调大到10G，或者更大，zk并不耗资源，可以不用调整；

   b、垃圾回收：待研究。

 

2、其它调优

  1）、列族、rowkey要尽量短，每个cell值均会存储一次列族名称和rowkey，甚至列名称也要尽量短，以下截图是表test2的数据和存入hdfs后的文件内容：
 
 
 
 由上图可见：短的列族名称、rowkey、列名称对最终的文件内容大小影响很大。

 

  2）、RS的region数量：一般每个RegionServer不要过1000，过多的region会导致产生较多的小文件，从而导致更多的compact，当有大量的超过5G的region并且RS总region数达到1000时，应该考虑扩容。

 

  3）、建表时：

                   a、如果不需要多版本，则应设置version=1；

                   b、 开启lzo或者snappy压缩，压缩会消耗一定的CPU，但是，磁盘IO和网络IO将获得极大的改善，大致可以压缩4~5倍；

                  c、合理的设计rowkey，在设计rowkey时需充分的理解现有业务并合理预见未来业务，不合理的rowkey设计将导致极差的hbase操作性能；

                 d、合理的规划数据量，进行预分区，避免在表使用过程中的不断split，并把数据的读写分散到不同的RS，充分的发挥集群的作用；

                 e、列族名称尽量短，比如：“f”，并且尽量只有一个列族；

                 f、视场景开启bloomfilter，优化读性能。

 

二、Client端调优

  1、hbase.client.write.buffer：写缓存大小，默认为2M，推荐设置为6M，单位是字节，当然不是越大越好，如果太大，则占用的内存太多；

 

  2、hbase.client.scanner.caching：scan缓存，默认为1，太小，可根据具体的业务特征进行配置，原则上不 可太大，避免占用过多的client和rs的内存，一般最大几百，如果一条数据太大，则应该设置一个较小的值，通常是设置业务需求的一次查询的数据条数， 比如：业务特点决定了一次最多100条，则可以设置为100

 

  3、设置合理的超时时间和重试次数，具体的内容会在后续的blog中详细讲解。

 

  4、client应用读写分离

    读和写分离，位于不同的tomcat实例，数据先写入redis队列，再异步写入hbase，如果写失败再回存redis队列，先读redis缓存的数据（如果有缓存，需要注意这里的redis缓存不是redis队列），如果没有读到再读hbase。

    当hbase集群不可用，或者某个RS不可用时，因为HBase的重试次数和超时时间均比较大（为保证正常的业务访问，不可能调整到比较小的值，如果一个 RS挂了，一次读或者写，经过若干重试和超时可能会持续几十秒，或者几分钟），所以一次操作可能会持续很长时间，导致tomcat线程被一个请求长时间占 用，tomcat的线程数有限，会被快速占完，导致没有空余线程做其它操作，读写分离后，写由于采用先写redis队列，再异步写hbase，因此不会出 现tomcat线程被占满的问题， 应用还可以提供写服务，如果是充值等业务，则不会损失收入，并且读服务出现tomcat线程被占满的时间也会变长一些，如果运维介入及时，则读服务影响也 比较有限。

 

  5、如果把org.apache.hadoop.hbase.client.HBaseAdmin配置为spring的bean，则需配置为懒加载，避免在启动时链接hbase的Master失败导致启动失败，从而无法进行一些降级操作。

 

  6、Scan查询编程优化：

     1）、调整caching；

     2）、如果是类似全表扫描这种查询，或者定期的任务，则可以设置scan的setCacheBlocks为false，避免无用缓存；

    3）、关闭scanner，避免浪费客户端和服务器的内存；

    4）、限定扫描范围：指定列簇或者指定要查询的列；

  5)、如果只查询rowkey时，则使用KeyOnlyFilter可大量减少网络消耗；

 

作为hbase依赖的状态协调者ZK和数据的存储则HDFS，也需要调优：

 

ZK调优：

  1、zookeeper.session.timeout：默认值3分钟，不可配置太短，避免session超时，hbase停止服务，线上生产环境由于 配置为1分钟，出现过2次该原因导致的hbase停止服务，也不可配置太长，如果太长，当rs挂掉，zk不能快速知道，从而导致master不能及时对 region进行迁移。

 

  2、zookeeper数量：至少5个节点。给每个zookeeper 1G左右的内存，最好有独立的磁盘。 (独立磁盘可以确保zookeeper不受影响).如果集群负载很重，不要把Zookeeper和RegionServer运行在同一台机器上面。就像 DataNodes 和 TaskTrackers一样，只有超过半数的zk存在才会提供服务，比如：共5台，则最多只运行挂2台，配置4台与3台一样，最多只运行挂1台。

 

  3、hbase.zookeeper.property.maxClientCnxns：zk的最大连接数，默认为300，可配置上千

 

hdf调优：

  1、dfs.name.dir： namenode的数据存放地址，可以配置多个，位于不同的磁盘并配置一个NFS远程文件系统，这样nn的数据可以有多个备份

  2、dfs.data.dir：dn数据存放地址，每个磁盘配置一个路径，这样可以大大提高并行读写的能力

  3、dfs.namenode.handler.count：nn节点RPC的处理线程数，默认为10，需提高，比如：60

  4、dfs.datanode.handler.count：dn节点RPC的处理线程数，默认为3，需提高，比如：20

  5、dfs.datanode.max.xcievers：dn同时处理文件的上限，默认为256，需提高，比如：8192

  6、dfs.block.size：dn数据块的大小，默认为64M，如果存储的文件均是比较大的文件则

 

一、服务端调优

 

 1、参数配置

 

   1）、hbase.regionserver.handler.count：该设置决定了处理RPC的线程数量，默认值是10，通常可以调大，比如：150，当请求内容很大（上MB，比如大的put、使用缓存的scans）的时候，如果该值设置过大则会占用过多的内存，导致频繁的GC，或者出现OutOfMemory，因此该值不是越大越好。

 

 

 

  2）、hbase.hregion.max.filesize ：配置region大小，0.94.12版本默认是10G，region的大小与集群支持的总数据量有关系，如果总数据量小，则单个region太大，不利于并行的数据处理，如果集群需支持的总数据量比较大，region太小，则会导致region的个数过多，导致region的管理等成本过高，如果一个RS配置的磁盘总量为3T*12=36T数据量，数据复制3份，则一台RS服务器可以存储10T的数据，如果每个region最大为10G，则最多1000个region，如此看，94.12的这个默认配置还是比较合适的，不过如果要自己管理split，则应该调大该值，并且在建表时规划好region数量和rowkey设计，进行region预建，做到一定时间内，每个region的数据大小在一定的数据量之下，当发现有大的region，或者需要对整个表进行region扩充时再进行split操作，一般提供在线服务的hbase集群均会弃用hbase的自动split，转而自己管理split。

 

 

 

  3）、hbase.hregion.majorcompaction：配置major合并的间隔时间，默认为1天，可设置为0，禁止自动的major合并，可手动或者通过脚本定期进行major合并，有两种compact：minor和major，minor通常会把数个小的相邻的storeFile合并成一个大的storeFile，minor不会删除标示为删除的数据和过期的数据，major会删除需删除的数据，major合并之后，一个store只有一个storeFile文件，会对store的所有数据进行重写，有较大的性能消耗。

 

 

 

  4）、hbase.hstore.compactionThreshold：HStore的storeFile数量>= compactionThreshold配置的值，则可能会进行compact，默认值为3，可以调大，比如设置为6，在定期的major compact中进行剩下文件的合并。

 

  5）、 hbase.hstore.blockingStoreFiles：HStore的storeFile的文件数大于配置值，则在flush memstore前先进行split或者compact，除非超过hbase.hstore.blockingWaitTime配置的时间，默认为7，可调大，比如：100，避免memstore不及时flush，当写入量大时，触发memstore的block，从而阻塞写操作。

 

 

 

  6）、hbase.regionserver.global.memstore.upperLimit：默认值0.4，RS所有memstore占用内存在总内存中的upper比例，当达到该值，则会从整个RS中找出最需要flush的region进行flush，直到总内存比例降至该数限制以下，并且在降至限制比例以下前将阻塞所有的写memstore的操作，在以写为主的集群中，可以调大该配置项，不建议太大，因为block cache和memstore cache的总大小不会超过0.8，而且不建议这两个cache的大小总和达到或者接近0.8，避免OOM，在偏向写的业务时，可配置为0.45，memstore.lowerLimit保持0.35不变，在偏向读的业务中，可调低为0.35，同时memstore.lowerLimit调低为0.3，或者再向下0.05个点，不能太低，除非只有很小的写入操作，如果是兼顾读写，则采用默认值即可。

 

 

 

  7）、hbase.regionserver.global.memstore.lowerLimit：默认值0.35，RS的所有memstore占用内存在总内存中的lower比例，当达到该值，则会从整个RS中找出最需要flush的region进行flush，配置时需结合memstore.upperLimit和block cache的配置。

 

 

 

  8）、file.block.cache.size：RS的block cache的内存大小限制，默认值0.25，在偏向读的业务中，可以适当调大该值，具体配置时需试hbase集群服务的业务特征，结合memstore的内存占比进行综合考虑。

 

 

 

  9）、hbase.hregion.memstore.flush.size：默认值128M，单位字节，超过将被flush到hdfs，该值比较适中，一般不需要调整。

 

 

 

  10）、hbase.hregion.memstore.block.multiplier：默认值2，如果memstore的内存大小已经超过了hbase.hregion.memstore.flush.size的2倍，则会阻塞memstore的写操作，直到降至该值以下，为避免发生阻塞，最好调大该值，比如：4，不可太大，如果太大，则会增大导致整个RS的memstore内存超过memstore.upperLimit限制的可能性，进而增大阻塞整个RS的写的几率。如果region发生了阻塞会导致大量的线程被阻塞在到该region上，从而其它region的线程数会下降，影响整体的RS服务能力，例如：

 

开始阻塞：

 

 

 解开阻塞：

 

 从10分11秒开始阻塞到10分20秒解开，总耗时9秒，在这9秒中无法写入，并且这期间可能会占用大量的RS handler线程，用于其它region或者操作的线程数会逐渐减少，从而影响到整体的性能，也可以通过异步写，并限制写的速度，避免出现阻塞。

 

 

 

  11）、hfile.block.index.cacheonwrite：在index写入的时候允许put无根（non-root）的多级索引块到block cache里，默认是false，设置为true，或许读性能更好，但是是否有副作用还需调查。

 

 

 

  12）、io.storefile.bloom.cacheonwrite：默认为false，需调查其作用。

 

 

 

  13）、hbase.regionserver.regionSplitLimit：控制最大的region数量，超过则不可以进行split操作，默认是Integer.MAX，可设置为1，禁止自动的split，通过人工，或者写脚本在集群空闲时执行。如果不禁止自动的split，则当region大小超过hbase.hregion.max.filesize时会触发split操作（具体的split有一定的策略，不仅仅通过该参数控制，前期的split会考虑region数据量和memstore大小），每次flush或者compact之后，regionserver都会检查是否需要Split，split会先下线老region再上线split后的region，该过程会很快，但是会存在两个问题：1、老region下线后，新region上线前client访问会失败，在重试过程中会成功但是如果是提供实时服务的系统则响应时长会增加；2、split后的compact是一个比较耗资源的动作。

 

 

 

  14）、Jvm调整：

 

       a、内存大小：master默认为1G，可增加到2G，regionserver默认1G，可调大到10G，或者更大，zk并不耗资源，可以不用调整；

 

   b、垃圾回收：待研究。

 

 

 

2、其它调优

 

  1）、列族、rowkey要尽量短，每个cell值均会存储一次列族名称和rowkey，甚至列名称也要尽量短，以下截图是表test2的数据和存入hdfs后的文件内容：

 

 

 

 由上图可见：短的列族名称、rowkey、列名称对最终的文件内容大小影响很大。

 

 

 

  2）、RS的region数量：一般每个RegionServer不要过1000，过多的region会导致产生较多的小文件，从而导致更多的compact，当有大量的超过5G的region并且RS总region数达到1000时，应该考虑扩容。

 

 

 

  3）、建表时：

 

                   a、如果不需要多版本，则应设置version=1；

 

                   b、 开启lzo或者snappy压缩，压缩会消耗一定的CPU，但是，磁盘IO和网络IO将获得极大的改善，大致可以压缩4~5倍；

 

                  c、合理的设计rowkey，在设计rowkey时需充分的理解现有业务并合理预见未来业务，不合理的rowkey设计将导致极差的hbase操作性能；

 

                 d、合理的规划数据量，进行预分区，避免在表使用过程中的不断split，并把数据的读写分散到不同的RS，充分的发挥集群的作用；

 

                 e、列族名称尽量短，比如：“f”，并且尽量只有一个列族；

 

                 f、视场景开启bloomfilter，优化读性能。

 

 

 

二、Client端调优

 

  1、hbase.client.write.buffer：写缓存大小，默认为2M，推荐设置为6M，单位是字节，当然不是越大越好，如果太大，则占用的内存太多；

 

 

 

  2、hbase.client.scanner.caching：scan缓存，默认为1，太小，可根据具体的业务特征进行配置，原则上不可太大，避免占用过多的client和rs的内存，一般最大几百，如果一条数据太大，则应该设置一个较小的值，通常是设置业务需求的一次查询的数据条数，比如：业务特点决定了一次最多100条，则可以设置为100

 

 

 

  3、设置合理的超时时间和重试次数，具体的内容会在后续的blog中详细讲解。

 

 

 

  4、client应用读写分离

 

    读和写分离，位于不同的tomcat实例，数据先写入redis队列，再异步写入hbase，如果写失败再回存redis队列，先读redis缓存的数据（如果有缓存，需要注意这里的redis缓存不是redis队列），如果没有读到再读hbase。

 

    当hbase集群不可用，或者某个RS不可用时，因为HBase的重试次数和超时时间均比较大（为保证正常的业务访问，不可能调整到比较小的值，如果一个RS挂了，一次读或者写，经过若干重试和超时可能会持续几十秒，或者几分钟），所以一次操作可能会持续很长时间，导致tomcat线程被一个请求长时间占用，tomcat的线程数有限，会被快速占完，导致没有空余线程做其它操作，读写分离后，写由于采用先写redis队列，再异步写hbase，因此不会出现tomcat线程被占满的问题， 应用还可以提供写服务，如果是充值等业务，则不会损失收入，并且读服务出现tomcat线程被占满的时间也会变长一些，如果运维介入及时，则读服务影响也比较有限。

 

 

 

  5、如果把org.apache.hadoop.hbase.client.HBaseAdmin配置为spring的bean，则需配置为懒加载，避免在启动时链接hbase的Master失败导致启动失败，从而无法进行一些降级操作。

 

 

 

  6、Scan查询编程优化：

 

     1）、调整caching；

 

     2）、如果是类似全表扫描这种查询，或者定期的任务，则可以设置scan的setCacheBlocks为false，避免无用缓存；

 

    3）、关闭scanner，避免浪费客户端和服务器的内存；

 

    4）、限定扫描范围：指定列簇或者指定要查询的列；

 

  5)、如果只查询rowkey时，则使用KeyOnlyFilter可大量减少网络消耗；

作为hbase依赖的状态协调者ZK和数据的存储则HDFS，也需要调优：

ZK调优：

 

  1、zookeeper.session.timeout：默认值3分钟，不可配置太短，避免session超时，hbase停止服务，线上生产环境由于配置为1分钟，出现过2次该原因导致的hbase停止服务，也不可配置太长，如果太长，当rs挂掉，zk不能快速知道，从而导致master不能及时对region进行迁移。

 

 

  2、zookeeper数量：至少5个节点。给每个zookeeper 1G左右的内存，最好有独立的磁盘。 (独立磁盘可以确保zookeeper不受影响).如果集群负载很重，不要把Zookeeper和RegionServer运行在同一台机器上面。就像DataNodes 和 TaskTrackers一样，只有超过半数的zk存在才会提供服务，比如：共5台，则最多只运行挂2台，配置4台与3台一样，最多只运行挂1台。

  3、hbase.zookeeper.property.maxClientCnxns：zk的最大连接数，默认为300，可配置上千

 

hdf调优：

 

  1、dfs.name.dir： namenode的数据存放地址，可以配置多个，位于不同的磁盘并配置一个NFS远程文件系统，这样nn的数据可以有多个备份

 

  2、dfs.data.dir：dn数据存放地址，每个磁盘配置一个路径，这样可以大大提高并行读写的能力

 

  3、dfs.namenode.handler.count：nn节点RPC的处理线程数，默认为10，需提高，比如：60

 

  4、dfs.datanode.handler.count：dn节点RPC的处理线程数，默认为3，需提高，比如：20

 

  5、dfs.datanode.max.xcievers：dn同时处理文件的上限，默认为256，需提高，比如：8192

 

  6、dfs.block.size：dn数据块的大小，默认为64M，如果存储的文件均是比较大的文件则可以考虑调大，比如，在使用hbase时，可以设置为128M，注意单位是字节

 

  7、dfs.balance.bandwidthPerSec：在通过start-balancer.sh做负载均衡时控制传输文件的速度，默认为1M/s，可配置为几十M/s，比如：20M/s

 

  8、dfs.datanode.du.reserved：每块磁盘保留的空余空间，应预留一些给非hdfs文件使用，默认值为0

 

  9、dfs.datanode.failed.volumes.tolerated：在启动时会导致dn挂掉的坏磁盘数量，默认为0，即有一个磁盘坏了，就挂掉dn，可以不调整。可以考虑调大，比如，在使用hbase时，可以设置为128M，注意单位是字节

  7、dfs.balance.bandwidthPerSec：在通过start-balancer.sh做负载均衡时控制传输文件的速度，默认为1M/s，可配置为几十M/s，比如：20M/s

  8、dfs.datanode.du.reserved：每块磁盘保留的空余空间，应预留一些给非hdfs文件使用，默认值为0

  9、dfs.datanode.failed.volumes.tolerated：在启动时会导致dn挂掉的坏磁盘数量，默认为0，即有一个磁盘坏了，就挂掉dn，可以不调整。