1、hbase.regionserver.handler.count
RegionServers处理远程请求的线程数，如果注重TPS，可以调大，默认10
note1：值设得越大，意味着内存开销变大，hbase.client.write.buffer * hbase.regionserver.handler.count，hbase.client.write.buffer默认大小为2M
note2: 对于提高write的速度，如果瓶颈在做flush、compact、split的速度，磁盘io跟不上，提高线程数，意义不大。
2、hfile.block.cache.size
默认0.25，hfile/StoreFile的最大读缓存空间，所占堆空间比例。
note1:参数设定根据应用场景，如果读比写多，建议调大，读写平衡，建议设成0.3,如果读少于写，建议调小
note2:block.cache.size memstore limits 这些内存加起来不要超过60%。因为剩余的内存还要用来做其他事情。否则容易OOM。
3、hbase.regionserver.global.memstore.upperLimit
默认0.4，memstores所占最大堆空间比例，如果达到上限，阻塞更新，强制flush数据
4、hbase.regionserver.global.memstore.lowerLimit
默认0.35，menstores达到上限，做flush，知道memstores降到该值，停止flush。
5、hbase.hstore.blockingStoreFiles
默认7，如果一个hstore里面storefile超过这个数字（每次memstore做flush时会生成一个hstore），会阻塞相应hregion的更新，知道一个compact压缩过程结束，或者阻塞时间超过hbase.hstore.blockingWaitTime（默认90s）
note1：hbase.hstore.compactionThreshold，默认3，如果一个hstore里面的storefile数量超过这个数字，一个压缩任务会启动，将所有的storefile合并成一个。如果数量较多，那么会推迟合并过程，但是再执行时，将会消耗更多时间。
note2：对于持续写的系统，这个参数的设置，是为了compact与flush的速度平衡，如果compact的速度远小于flush的速度，有可能造成 文件io过多，造成too many openfile异常，以及给namenode带来更大的压力。
6、hbase.hregion.memstore.flush.size、hbase.hregion.memstore.block.multiplier
默认134217728、2
第一个参数：如果一个memstore大小超过flushsize，则启动flush。后台会有一个线程在周期hbase.server.thread.wakefrequency内，定时检查
第二个参数：如果一个memstore大小超过 该值*flushsize，则阻塞更新。该参数可以平衡，写入速度、flush速度、compact速度、split速度
7、hbase.regionserver.checksum.verify
默认false，决定，hbase使用自己的数据校验，而不是hdfs的校验。
8、hbase.hregion.max.filesize
默认10G，一个region下，任一列簇的hfiles的大小，超过这个值，该region将split成2个region。
note:如果你的数据量增长的比较快，那么还是建议把这个大小调高，可以调成100G，因为越少的region你的集群越流畅，100G的阈值基本可以避免你的region增长过快，甚至你的region数目会长期不变。当然大region在compaction时也会更加缓慢。几十G的region启动和compaction都非常的慢，如果storefile较多，一个compaction可能会持续几天。
9、谈谈region数量设置、以及region split过程
个人观点，如果可以尽早对region进行规划，可以提前预判规划好region的数量，这样可以节省split带来的消耗。
note1：人工进行split
设置hbase.hregion.max.filesize的值为LONG.MAX_VALUE,但是建议设成一个较大的值。预先设计region数量为10，或者更少，然后看数据发展情况。
如果数据较少，可以讲major compact的周期调大。如果数据增长比较快，那么可以调用org.apache.hadoop.hbase.util.RegionSplitter接口，主动进行split。
