• 沒有找到結果。

删除指定的行是在构造 Delete 对象的时候只传入行健

7.5 HBase 集群规划

• 简介:

HBase 自身具有极好的扩展性,因此构建扩展集群是它的天生强项之一。在实际生产中很多业务都运行在一个集群上,业务之间共享集群硬件、软件资 源。那问题来了,一个集群上面到底应该运行哪些业务可以最大程度上利用系统的软硬件资源?另外,对于一个给定的业务来说,应该如何规划集群的 硬件容量才能使得资源不浪费?最后,一个给定的 RegionServer 上到底部署多少 Region 比较合适?

• 7.5.1 集群业务规划

7.5 HBase 集群规划

• 简介:

HBase 自身具有极好的扩展性,因此构建扩展集群是它的天生强项之一。在实际生产中很多业务都运行在一个集群上,业务之间共享集群硬件、软件资 源。那问题来了,一个集群上面到底应该运行哪些业务可以最大程度上利用系统的软硬件资源?另外,对于一个给定的业务来说,应该如何规划集群的 硬件容量才能使得资源不浪费?最后,一个给定的 RegionServer 上到底部署多少 Region 比较合适?

• 7.5.2 集群容量规划

• 公式:

Disk Size / Java Heap = RegionSize / MemstoreSize * ReplicationFactor * HeapFractionForMemstore * 2

• 按照默认配置, RegionSize = 10G ,对应参数为 hbase.hregion.max.filesize

• MemstoreSize = 128M ,对应参数为 hbase.hregion.memstore.flush.size

• ReplicationFactor = 3 ,对应参数为 dfs.replication

• HeapFractionForMemstore = 0.4 ,对应参数为 hbase.regionserver.global.memstore.lowerLimit 。 计算为: 10240M / 128M * 3 * 0.4 * 2 = 192

• 推导过程

硬盘容量纬度下 Region 个数: Disk Size / (RegionSize * ReplicationFactor)

Java Heap 纬度下 Region 个数: Java Heap * HeapFractionForMemstore / (MemstoreSize / 2 )

Disk Size / (RegionSize * ReplicationFactor) = Java Heap * HeapFractionForMemstore / (MemstoreSize / 2 )

= > Disk Size / Java Heap = RegionSize / MemstoreSize * ReplicationFactor * HeapFractionForMemstore * 2

7.5 HBase 集群规划

• 7.5.3 Region 规划

• Region 规划主要涉及到两个方面: Region 个数规划以及单 Region 大小规划

• 官方文档给出的一个推荐范围在 20 ~ 200 之间,而单个 Region 大小控制在 10G~30G ,比较符合实际情况。

• 最多可以存储的数据量差不多为 200 * 30G * 3 = 18T 。如果存储的数据量超过 18T ,必然会引起或多或少的性能问题。综上,从 Re gion 规模这个角度讲,当前单台 RegionServer 能够合理利用起来的硬盘容量上限基本为 18T 。

优点 缺点

大量小 Region

(1) 更加有利于集群之间负载分布。 (2) 有 利于高效平稳的 Compaction ,这是因为小 Region 中 HFile 相对较小, Compaction 代价小。

(1) 最直接的影响,在某台 RegionServer 异常宕机或者重启的情况下 大量小 Region 重分配以及迁移是一个很耗时的操作,一般一个 Region 迁移需要 1.5s ~ 2.5s 左右, Region 个数越多,迁移时间越长,直接 导致故障转移时间很长。

(2) 大量小 Region 有可能会产生更加频繁的 lush ,产生很多小文件,

进而引起不必要的 Compaction 。特殊场景下,一旦 Region 数超过一 个阈值,将会导致整个 RegionServer 级别的 Flush ,严重阻塞用户 读写。 (3)RegionServer 管理维护开销很大。

少量大 Region

(1) 有利于 RegionServer 的快速重启以及 宕机恢复。

(2) 可以减少总的远程文件拷贝数量。

(3) 有利于产生更少的、更大的 Flush 。

(1)Compaction 效果很差,会引起较大的数据写入抖动,稳定性较差。

(2) 不利于集群之间负载均衡。

7.5 HBase 集群规划

• 7.5.4 内存规划

HBase 中内存规划涉及读缓存 BlockCache ,写缓存 MemStore ,直接影响到系统内存利用率, I/O 利用率等资源以及读写性能等,重要性不言而喻。

主要配置也是针对 BlockCache 和 MemStore 进行,然而针对不同业务类型 ( 简单说来主要包括读多写少型和写多读少型 ) ,内存的相关配置却完全 不同。再者,对于读缓存 BlockCache ,实际生产中一般会有两种工作模式: LRUBlockCache 和 BucketCache ,不同工作模式下的相关配置也不尽 相同

• 1. 写多读少型 + LRUBlockCache

图中分配给 RegionServer 进程的内存就是 JVM 内存,主要分为三部分: LRUBlockCache ,用于读缓存; MemStore ,用于写缓存; Other ,用 于 RegionServer 运行所必须的其他对象。

• (1) 整个物理机内存: 128G 。

• (2) 业务负载分布: 30% 读, 70% 写。

(1)RegionServer 内存,为系统内存的 2/3 。

(2) 设置 LRUBlockCache 和 MemStore ,在写多读少的业务场景下,写缓存显然应该分配更多内存,读缓存相对分配更少; HBase 在此处有 个硬规定: LRUBlockCache + MemStore < 80% * JVM_HEAP ,否则 RegionServer 无法启动。

7.5 HBase 集群规划

• hbase-site.xml 中 MemStore 相关参数设置如下

• hbase-site.xml 中 LRUBlockCache 相关参数设置如下

-XX:SurvivorRatio=2 -XX:+PrintGCDateStamps -Xloggc:$HBASE_LOG_DIR/gc-regionserver.log -XX:

+UseGCLogFileRotation -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=512M -server -Xmx64g -Xms64g -Xmn2g -Xss256k -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:MaxTenuringThreshold=15 -XX:

+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled -XX:

+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC

<property>

<name>hbase.regionserver.global.memstore.upperLimit</name>

<value>0.45</value>

</property>

<property>

<name>hbase.regionserver.global.memstore.lowerLimit</name>

<value>0.40</value>

</property>

<property>

<name>hfile.block.cache.size</name>

<value>0.3</value>

</property>

7.5 HBase 集群规划

• 2. 读多写少型 + BucketCache

如图,整个 RegionServer 内存 (Java 进程内存 ) 分为两部分: JVM 内存和堆外内存。 JVM 内存中的 LRUBlockCache 和堆外内存 BucketCache 一起构成了读缓存 CombinedBlockCache ,用于缓存读到的 Block 数据,其中 LRUBlockCache 用于缓存元数据 Block , BucketCache 用于缓存 实际用户数据 Block ; MemStore 用于写流程,缓存用户写入 KeyValue 数据;还有部分用于 RegionServer 正常运行所必须的内存

序号 步骤 原理 计算公式 计算值 修正值

4 规划读缓存 BucketCache 部分 BucketCache 部分主要缓存用户数据块,数据量相对较大,设置为整个读缓存的 90% 。

2 * 90% 38.7G 40G

5 规划写缓存 MemStore 整个内存分为三部分:读缓存、写缓存、其他。基本按照 5 : 3 : 2 的分配原则,

写缓存设置为整个 RS 内存的 30% 。

1 * 30% 25.8G 30G

7.5 HBase 集群规划

• 2. 读多写少型 + BucketCache

前面说过 HBase 有一个硬规定: LRUBlockCache + MemStore < 80% * JVM_HEAP ,否则 RegionServer 无法启动。这个规定的本质是为了在 内存规划的时候能够给除了写缓存和读缓存之外的其他对象留够至少 20% 的内存空间。那按照上述计算方式能不能满足这个硬规定呢, (LRU + MemSt ore) / JVM_HEAP = (4.3G + 25.8G) / 47.3G = 63.6% ,远小于 80% 。因此需要对计算值进行简单的修正,适量减少 JVM_HEAP 值 ( 减少 至 46G) ,增大 Memstore 到 30G 。因为 JVM_HEAP 减少了,堆外内存就需要适量增大,因此将 BucketCache 增大到 40G 。

• 调整之后, (LRU + MemStore) / JVM_HEAP = (6G + 30G) / 46G = 78.2%

• 设置 JVM 参数如下

• hbase-site.xml 中 MemStore 相关参数设置如下

• hbase-site.xml 中 CombinedBlockCache 相关参数设置如下

-Xloggc:$HBASE_LOG_DIR/gc-regionserver.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=1

-XX:GCLogFileSize=512M -server -Xmx40g -Xms40g -Xmn1g -Xss256k -XX:PermSize=256m -XX:MaxPermSize=256m -XX:

+UseParNewGC -XX:MaxTenuringThreshold=15 -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC

<property>

<name>hbase.regionserver.global.memstore.upperLimit</name>

<value>0.65</value>

</property>

<property>

<name>hbase.regionserver.global.memstore.lowerLimit</name>

<value>0.60</value>

</property>

<property>

<name>hbase.bucketcache.ioengine</name>

<value>offheap</value>

</property>

<property>

<name>hbase.bucketcache.size</name>

<value>44032</value>

</property>

<property>

<name>hbase.bucketcache.percentage.in.combinedcache</name>

<value>0.90</value>

</property>

相關文件