1、Hbase_master_heapsize（64GB）

  • Hbase Master通常没有什么负载，Hbase_master_heapsize一般设置为4-8 GB。Master主要负责元数据的操作（例如：创建/删除表），以及通过zookeeper znodes持续观察 regionserver的健康状况，当regionserver 宕机时会重新分配region。 由于Master中的调度管理器对region状态的监控都发生在内存中，如果集群有大量的region，需要相应增加堆内存。

2、hbase_regionserver_heapsize（32GB）

  • 大多数的数据加载/处理都发生在regionserver的堆内存之中。 堆内存中包含块缓存可以使读更快，堆内存保存着用户所有写入的 region memstores（直到它们被刷写到磁盘上）。

  • 1）如果使用CMS GC算法，36GB以上的堆内存是比较难受的，因为长时间“stop the world”的GC暂停不仅会使Hbase无法运行而且会增加数据储存的复杂性。 可以根据当前的region数量，设置一个16GB-36GB之间的值，同时根据集群的容量以及节点中region数量的增加，适度调整堆内存的大小。
    【 可以通过Ambari> Hbase> Master UI> Memory选项卡观察堆内存的使用情况，如果高峰时段堆内存利用率占到60-70％，则可以适度增加堆内存的大小。 （发生内存泄漏除外）】
    2）如果使用G1 GC算法，堆内存的大小则没有限制。

3、hbase_regionsever_xmn_max（4096MB）

  • 该参数设置 regionsever 堆内存中年轻代的大小， 一般设置为堆内存的1/10 - 1/8，永远不要超过4000 MB。

4、regionserver 服务器上的region 个数（350-500）

  • 讨论这个值，可以帮助我们找出regionserver的最佳堆内存和最佳memstore的大小，同时向我们解释这些参数都依赖于region的数量，hbase的性能也依赖于这些参数的值。单台regionserver服务器建议将region个数控制在200-400个。 可以使用下面的公式计算集群中的现有值是否为最优值：
    (regionserver_memory_size)×(memstore_fraction)/((memstore_size)×(num_column_families))
  • 例如：某台 regionserver 服务器 ，256 GB 内存（262144MB），Memstore比例为0.4，Memstore大小是128 Mb ，数据表中有1个列族。
eg: (262144MB × 0.4) /(128MB × 1)= 816 个region

5、file.block.cache.size（0.4）

  • 块缓存是堆内存的一部分，当磁盘中的数据被加载到缓存中，下次访问相同的数据时，读取的速度更快。但只在下面两种情况下才有效：
a.单次，非常大的读取请求
b.有大量读取请求的情况下，用户重复读取相同的数据

6、hbase.regionserver.global.memstore.size（0.4）

  • 这个值是堆内存的一部分，代表每打开一个表，每个region的每个列族的memstore内存。这是写入操作发生编辑和突变的地方。对于大量的写入请求，20-40％之间的占比都是比较合适的。（需要注意的是，块缓存的总和和全局memstore大小不应该大于堆内存总量的70-75％，这样就有足够的堆内存可用于除了读写缓存之外的常规hbase操作。）

7、hbase.hregion.memstore.flush.size（128MB）（一张表table > 有多个分区region > 有多个列族 column > 对应一个存储仓库 store > 对应一个内存仓库 memstore、多个存储文件 storefile > 多个数据块 block）

  • 这个值是一个列族打开的memstore大小，在写操作期间，当memstore被占满的时候，会以Hfile的形式刷写到磁盘。当某个region的其中一个列族的memstore满了，这个region的所有列族的memstore都会被刷写到磁盘上。 每次刷写都会创建一个Hfile，因此这个数字越小，刷写频率越高，IO开销越大，创建Hfiles的次数越多，Hfiles的数量就越多，触发压缩的时间就越快。压缩会触发额外的一轮写操作，因为它是将较小的Hfiles写入更大的Hfile，所以如果非常频繁地触发刷写，对于服务器IO将会是很大的开销。因此，一个比较大的刷写值会减少Hfiles的数量和压缩的次数，需要综合考虑每个regionserver的堆内存大小、region个数、列族的数量。如果有太多的region和列族，就无法承受在有限的堆内存下配置更大的刷写值。 刷写值的理想范围在128 MB到256 MB之间。
常用的表共35张，每张表只有1个列族

8、hbase.hregion.memstore.block.multiplier（4）

  • 这个参数，允许单个memstore突发大量的写入时进行拉伸，一直拉伸到 flush.size × multiplier 的大小，随后在该列族上的写入操作将会被停止，直到刷写完成，才继续放开写入。

9、hbase.regionserver.handle.count（200）

  • 此参数定义处理传入请求的RPC 侦听器/线程 数量。默认值为30。如果有更多的并发请求访问Hbase，这个值会更高，但是该值应该与每个regionserver上的CPU核数和堆内存大小成比例，因为每个线程都会消耗一部分内存和CPU。当每个请求的有效负载较大时，可以将这个值设置的小一些，单个请求的有效负载较小时，这个值可以设置的大一点。可以把初始值设置成该节点上CPU核数的两倍，后续根据需求进行增减。

10、hbase.hstore.blockingStoreFiles

  • 该参数的默认值是10，每个memstore 刷写时会创建一个Hfile（hbase.hregion.memstore.flush.size），参数的目的是沿着写入管道发送一条消息，除非这些Hfiles正在进行minor conpaction，就不再刷写。 日志中显示这些消息，例如“ Too many HFiles，delaying flush ”。 然后就会延迟刷新几秒，如果还在持续写入，memstore就会扩展到以下参数的大小：
    （hbase.hregion.memstore.flush.size X hbase.hregion.memstore.block.multiplier）
    达到这个限制后，在regionserver 上的这个region就不再写入了，这时会看到如下消息出现在日志中“ org.apache.hadoop.hbase.RegionTooBusyException：Above memstore limit”
    当minor compaction结束后，写入才会恢复。
    一直增加此参数可以避免在发生大流量写入时出现任何潜在的问题，并且反过来可以使通道更有效率。
    为了进一步提高效率，还可以增加hbase.hstore.compaction.max的值，以便在压缩过程中涵盖更多的Hfiles。

11、hbase.hstore.compaction.max

  • 默认值为10。在写负载较重的情况下，可以调整此参数，使minor conpaction覆盖更多Hfiles，并协助恢复写入功能。 请注意，minor conpaction本身也有自己的IO开销，在提高该值的时候需要记住这一点。