一、JVM调优
-Xms 初始堆大小
-Xmx 最大堆大小
-XX:ParallelGCThreads 并行收集器的线程数: 8+(logical processors-8)(5/8)
-XX:MaxGCPauseMillis 每次年轻代垃圾回收的最长时间(最大暂停时间):如果无法满足此时间,JVM会自动调整年轻代大小,以满足此值.
-XX:+ParallelRefProcEnabled 使用多线程并行处理
-XX:-ResizePLAB 取消内存整理
-XX:G1NewSizePercent 使得Eden空间保持1GB左右。 例如：
- 32GB heap，-XX:G1NewSizePercent=3
- 64GB heap, -XX:G1NewSizePercent=2
- 100GB heap以上，-XX:G1NewSizePercent=1
-XX:+UseG1GC
-Xms100g -Xmx100g
-XX:MaxGCPauseMillis=100
-XX:+ParallelRefProcEnabled
-XX:-ResizePLAB
-XX:ParallelGCThreads= 8+(40-8)(5/8)=28
-XX:G1NewSizePercent=1
二、hbase服务端参数
hbase.regionserver.handler.count
master， regionserver RPC监听数。默认30。
如果请求多且提交的数据量小的时候，可以考虑加大。
如果请求的数据量大，达到MB级的时候，可以考虑减少，以减轻region server的写入压力。
hbase.hregion.max.filesize
一个region的文件最大大小。如果超过这个大小，则自动split。
如果无需执行mr，应该禁止自动分割，修改值为100g，由人工执行split。
hbase.hregion.majorcompaction
major compact的自动周期。
应该设置为0禁止使用自动major_compact。
手工hbase shell执行脚本调用major_compact命令，或者使用java类org.apache.hadoop.hbase.client.HBaseAdmin的majorCompact方法。
在major compact时，关闭balance，避免RIT。
#hbase.hstore.compactionThreshold：HStore的storeFile数量>= compactionThreshold配置的值，则可能会进行compact，默认值为3，可以调大，比如设置为4，在定期的major compact中进行剩下文件的合并，减少合并的次数，不过后果是会影响查询的性能
hbase.hstore.blockingStoreFiles
在MemStore flush后，检查文件数据。
如果一个store中的hfile数量超过配置，则block一个配置时间hbase.hstore.blockingWaitTime（默认90秒），腾出性能支持compact。默认7。
一定要加大，基本到30+，文件多了，最多读得慢，比写不入要好。
对于高写入系统，应该加大该值。（100+）
#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个点，不能太低，除非只有很小的写入操作，如果是兼顾读写，则采用默认值即可。
#hbase.regionserver.global.memstore.lowerLimit：默认值0.35，RS的所有memstore占用内存在总内存中的lower比例，当达到该值，则会从整个RS中找出最需要flush的region进行flush，配置时需结合memstore.upperLimit和block cache的配置。
#file.block.cache.size：RS的block cache的内存大小限制，默认值0.25，在偏向读的业务中，可以适当调大该值，具体配置时需试hbase集群服务的业务特征，结合memstore的内存占比进行综合考虑。
hbase.hregion.memstore.flush.size
memstore超过该值时,flush to HFILE。默认是dfs的block size 128m 。
不能因为要避免HFILE输出后的compact而将该值调整到很大,因为ConcurrentSkipListMap在存储的数据量达到一定大小以后，写入性能将会出现显著的恶化。
hbase.hregion.memstore.block.multiplier
memstore写入阻塞倍数。当memstore大小超过 hbase.hregion.memstore.flush.size * multiplier 则阻塞写入。默认4，则128 * 4 = 512m是阻塞写入。
#hfile.block.index.cacheonwrite：在index写入的时候允许put无根（non-root）的多级索引块到block cache里，默认是false，设置为true，或许读性能更好，但是是否有副作用还需调查。
#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是一个比较耗资源的动作。
hbase.regionserver.hlog.syncer.count
高写入时，WAL sync慢，也就是归档慢，可以增加这个值，默认5。
hbase.regionserver.optionallogflushinterval
异步写WAL间隔，解决高写入下的性能问题。
默认情况下是同步写入，如果遇到写入的瓶颈，可以考虑异步写入。但有可能在间隔时间内丢失数据。
hbase.hstore.compaction.min 和 hbase.hstore.compaction.max
每次compact 所涉及的文件数量范围。
一次compact的操作涉及的文件数据量如下：hbase.hstore.compaction.min >= compact 文件数据量 <= hbase.hstore.compaction.max
hbase.hstore.compaction.min默认为3,一般情况下都是过于小了,可以考虑改为8+.
hbase.hstore.compaction.max要根据min做调整,还要考虑合并的压力.
默认分别是3和10。
hbase.hstore.compaction.min.size 和 hbase.hstore.compaction.max.size
每次compact 所涉及的文件大小范围。与具体compact算法相关。
通过文件大小得出需要合并的文件清单，再通过文件数量判断本次是否需要compact。
如果hbase.hstore.compaction.min.size没有设置，则使用hbase.hregion.memstore.flush.size 。
小于hbase.hstore.compaction.min.size的HFILE，忽略compact算法的筛选，直接归入合并文件集合中。
hbase.hstore.compaction.kv.max
compact和flush时，每次处理的kv数量。
如果kv较大，减少。如果是宽表小cell，加大。
hbase.regionserver.global.memstore.size
regionserver中所有memstore的可用内存大小 ， 默认0.4 。
如果随机写的需求较少，多数是批量导入和读的话，可以减小。
hbase.hregion.percolumnfamilyflush.size.lower.bound
整体当Memstore内存达到上限时，对单个Memstore大小>配置值的，执行flush，避免生成小文件。
默认16M。
hbase.hstore.flusher.count
如果在高写入的情况下，flush慢，可以改为3，默认2。
当加快flush速度，要在一段时间内考虑是否增加compact的线程数或者关闭compact。
hbase.regionserver.global.memstore.size.lower.limit
全局memstore写入阻塞上限。默认0.95 。如果regionserver中所有memstore占用达到memstore可用内存的这个比例,则阻塞写入 ， 并flush 。
阻塞值= max heap of regionserver * hbase.regionserver.global.memstore.size * hbase.regionserver.global.memstore.size.lower.limit
hbase.regionserver.optionalcacheflushinterval
auto flush time interval ，默认1小时。如果设置为0，则关闭自动刷新。对于只做批量导入的，可以设置为0 。
hbase.regionserver.thread.compaction.small 和 hbase.regionserver.thread.compaction.large
大、小合并线程池，默认1。如果合并要加快，就加大，一般无需调整。
每次合并去哪个线程池由hbase.regionserver.thread.compaction.throttle决定，合并的文件大小超过就去large，否则small。
如果compact对性能有影响，可以
hbase.regionserver.thread.compaction.large = 0 ，
hbase.regionserver.thread.compaction.throttle =
53687091200(50g)，这样就变为所有compact由small的单线程处理，以实现限流。
如果只写不读，建议关闭balance
hbase.balance.period
负载均衡的检查间隔，默认300000。
如果在大部分时间是写少读多，如kylin在工作时间是只读不写的，可以加大。
echo "balancer_switch false" | bin/hbase shell
hbase.balancer.max.balancing
一次balance可以执行多久。如果在这个配置时间范围内无法执行完，将中止balance。如果没有配置，使用hbase.balance.period。
hbase.master.initializationmonitor.haltontimeout 和 hbase.master.initializationmonitor.timeout
是否启动master初始化时间限制，默认false。
master的初始化限制，默认15分钟。
如果启动了，在大量RIT或者region较多的情况下，应该加大时长。
Client端调优
hbase.client.write.buffer：写缓存大小，默认为2M，推荐设置为6M，单位是字节，当然不是越大越好，如果太大，则占用的内存太多；
hbase.client.scanner.caching：scan缓存，默认为1，太小，可根据具体的业务特征进行配置，原则上不可太大，避免占用过多的client和rs的内存，一般最大几百，如果一条数据太大，则应该设置一个较小的值，通常是设置业务需求的一次查询的数据条数，比如：业务特点决定了一次最多50条，则可以设置为50
三、zookeeper调优
1、zookeeper.session.timeout：默认值3分钟，不可配置太短，避免session超时，hbase停止服务，线上生产环境由于配置为1分钟，出现过2次该原因导致的hbase停止服务，也不可配置太长，如果太长，当rs挂掉，zk不能快速知道，从而导致master不能及时对region进行迁移。
2、zookeeper数量：建议5个节点或者以上。给每个zookeeper 1G左右的内存，最好有独立的磁盘。 (独立磁盘可以确保zookeeper不受影响).如果集群负载很重，不要把Zookeeper和RegionServer运行在同一台机器上面。
3、hbase.zookeeper.property.maxClientCnxns：zk的最大连接数，默认为300，应根据集群规模进行调整。
四、HDFS调优
1、dfs.namenode.handler.count：nn节点RPC的处理线程数，默认为10，需提高，比如：60
2、dfs.datanode.handler.count：dn节点RPC的处理线程数，默认为3，需提高，比如：20
3、dfs.datanode.max.xcievers：dn同时处理文件的上限，默认为256，需提高，比如：8192
参考：http://wangneng-168.iteye.com/blog/2067741
http://www.aboutyun.com/thread-21890-1-1.html
http://www.postgres.cn/downfiles/pg2016conf_day2_s3_am1.pdf