HBase最佳实践－集群规划

http://hbasefly.com

HBase自身具有极好的扩展性，也因此，构建扩展集群是它的天生强项之一。在实际线上应用中很多业务都运行在一个集群上，业务之间共享集群硬件、软件资源。那问题来了，一个集群上面到底应该运行哪些业务可以最大程度上利用系统的软硬件资源？另外，对于一个给定业务来说，应该如何规划集群的硬件容量才能使得资源不浪费？最后，一个给定的RegionServer上到底部署多少Region比较合适？想必这些问题都曾经困惑过很多HBaser，那本文将结合前人的分享以及笔者的经验简单的对这三个问题分别进行解析，抛砖引玉，希望大家能够针对这几个话题进行深入的交流！

集群业务规划

一般而言，一个HBase集群上很少只跑一个业务，大多数情况都是多个业务共享集群，实际上就是共享系统软硬件资源。这里通常涉及两大问题，其一是业务之间资源隔离问题，就是将各个业务在逻辑上隔离开来，互相不受影响，这个问题产生于业务共享场景下一旦某一业务一段时间内流量猛增必然会因为过度消耗系统资源而影响其他业务；其二就是共享情况下如何使得系统资源利用率最高，理想情况下当然希望集群中所有软硬件资源都得到最大程度利用。前者本次并不讨论，后期会开’专场’讨论，本节主要就后者进行探讨。

使得集群系统资源最大化利用，那首先要看业务对系统资源的需求情况。经过对线上业务的梳理，通常可将这些业务分为如下几类：

1. 硬盘容量敏感型业务：这类业务对读写延迟以及吞吐量都没有很大的要求，唯一的需要就是硬盘容量。比如大多数离线读写分析业务，上层应用一般每隔一段时间批量写入大量数据，然后读取也是定期批量读取大量数据。特点：离线写、离线读，需求硬盘容量

2. 带宽敏感型业务：这类业务大多数写入吞吐量很大，但对读取吞吐量没有什么要求。比如日志实时存储业务，上层应用通过kafka将海量日志实时传输过来，要求能够实时写入，而读取场景一般是离线分析或者在上次业务遇到异常的时候对日志进行检索。特点：在线写、离线读，需求带宽

3. IO敏感型业务：相比前面两类业务来说，IO敏感型业务一般都是较为核心的业务。这类业务对读写延迟要求较高，尤其对于读取延迟通常在100ms以内，部分业务可能要求更高。比如在线消息存储系统、历史订单系统、实时推荐系统等。特点：在（离）线写、在线读，需求内存、高IOPS介质

（而对于CPU资源，HBase本身就是CPU敏感型系统，主要用于数据块的压缩/解压缩，所有业务都对CPU有共同的需求）

一个集群想要资源利用率最大化，一个思路就是各个业务之间‘扬长避短’，合理搭配，各取所需。实际上就是上述几种类型的业务能够混合分布，建议不要将同一种类型的业务太多分布在同一个集群。因此一个集群理论上资源利用率比较高效的配置为：硬盘敏感型业务 ＋ 带宽敏感型业务 ＋ IO敏感型业务。

另外，集群业务规划的时候除了考虑资源使用率最大化这个问题之外，还需要考虑实际运维的需求。建议将核心业务和非核心业务分布在同一个集群，强烈建议不要将太多核心业务同时分布在同一个集群。这主要有两方面的考虑：

1. 一方面是因为‘一山不容二虎’，核心业务共享资源必然会产生竞争，一旦出现竞争无论哪个业务’落败’都不是我们愿意看到的；

2. 另一方面在特殊场景下方便运维童鞋进行降级处理，比如类似于淘宝双十一这类大促活动，某个核心业务预期会有很大的流量涌入，为了保证核心业务的平稳，在资源共享的情况下只能牺牲其他非核心业务，在和非核心业务方充分交流沟通的基础上限制这些业务的资源使用，在流量极限的时候甚至可以直接停掉这些非核心业务。试想，如果是很多核心业务共享集群的话，哪个核心业务愿意轻易让路？

那有些同学就说了：如果按照你这样设计，那岂不是会产生很多小集群。的确，这种设计会产生很多小集群，相信如果没有资源隔离的话，小集群是没法避免的。有些使用’rsgroup’进行业务资源隔离的集群会做的很大，大集群通过隔离会将业务独立分布到很多独立的RS上，这样实际上就产生了很多逻辑上的小集群，那么，这些小集群同样适用上面提出的规划思路。

集群容量规划

每个季度公司都会要求采购新机器，一般情况下机器的规格（硬盘总容量、内存大小、CPU规格）都是固定的。假如现在一台RegionServer的硬盘规格是3.6T * 12，总内存大小为128G，从理论上来说这样的配置是否会有资源浪费？如果有的话是硬盘浪费还是内存浪费？那合理的硬盘/内存搭配应该是什么样？和哪些影响因素有关？

这里需要提出一个’Disk / Java Heap Ratio’的概念，意思是说一台RegionServer上1bytes的Java内存大小需要搭配多大的硬盘大小最合理。在给出合理的解释在前，先把结果给出来：

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；

计算为：10G / 128M * 3 * 0.4 * 2 = 192，意思是说RegionServer上1bytes的Java内存大小需要搭配192bytes的硬盘大小最合理，再回到之前给出的问题，128G的内存总大小，拿出96G作为Java内存用于RegionServer，那对应需要搭配96G ＊ 192 = 18T硬盘容量，而实际采购机器配置的是36T，说明在默认配置条件下会有几乎一半硬盘被浪费。

计算公式是如何’冒’出来的？

再回过头来看看那个计算公式是怎么’冒’出来的，其实很简单，只需要从硬盘容量纬度和Java Heap纬度两方面计算Region个数，再令两者相等就可以推导出来，如下：

硬盘容量纬度下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

这样的公式有什么具体意义？

1. 最直观的意义就是判断在当前给定配置下是否会有资源浪费，内存资源和硬盘资源是否匹配。

2. 那反过来，如果已经给定了硬件资源，比如硬件采购部已经采购了当前机器内存128G，分配给Java Heap为96G，而硬盘是40T，很显然两者是不匹配的，那能不能通过修改HBase配置来使得两者匹配？当然可以，可以通过增大RegionSize或者减少MemstoreSize来实现，比如将默认的RegionSize由10G增大到20G，此时Disk Size / Java Heap ＝ 384，96G * 384 = 36T，基本就可以使得硬盘和内存达到匹配。

3. 另外，如果给定配置下内存硬盘不匹配，那实际场景下内存’浪费’好呢还是硬盘’浪费’好？答案是内存’浪费’好，比如采购的机器Java Heap可以分配到126G，而总硬盘容量只有18T，默认配置下必然是Java Heap有浪费，但是可以通过修改HBase配置将多余的内存资源分配给HBase读缓存BlockCache，这样就可以保证Java Heap并没有实际浪费。

另外，还有这些资源需要注意…

带宽资源：因为HBase在大量scan以及高吞吐量写入的时候特别耗费网络带宽资源，强烈建议HBase集群部署在万兆交换机机房，单台机器最好也是万兆网卡＋bond。如果特殊情况交换机是千兆网卡，一定要保证所有的RegionServer机器部署在同一个交换机下，跨交换机会导致写入延迟很大，严重影响业务写入性能。

 CPU资源：HBase是一个CPU敏感型业务，无论数据写入读取，都会因为大量的压缩解压操作，特别耗费计算资源。因此对于HBase来说，CPU越多越好。

参考：

http://hadoop-hbase.blogspot.com/2013/01/hbase-region-server-memory-sizing.html

Region规划

Region规划主要涉及到两个方面：Region个数规划以及单Region大小规划，这两个方面并不独立，而是相互关联的，大Region对应的Region个数少，小Region对应的Region个数多。Region规划相信是很多HBase运维同学比较关心的问题，一个给定规格的RegionServer上运行多少Region比较合适，在刚开始接触HBase的时候，这个问题也一直困扰着笔者。在实际应用中，Region太多或者太少都有一定的利弊：

	优点	缺点
大量小Region	1. 更加有利于集群之间负载分布 2. 有利于高效平稳的Compaction，这是因为小Region中HFile相对较小，Compaction代价小，详情可见：Stripe Compaction	1. 最直接的影响：在某台RegionServer异常宕机或者重启的情况下大量小Region重分配以及迁移是一个很耗时的操作，一般一个Region迁移需要1.5s～2.5s左右，Region个数越多，迁移时间越长。直接导致failover时间很长。 2. 大量小Region有可能会产生更加频繁的flush，产生很多小文件，进而引起不必要的Compaction。特殊场景下，一旦Region数超过一个阈值，将会导致整个RegionServer级别的flush，严重阻塞用户读写。 3. RegionServer管理维护开销很大
少量大Region	1. 有利于RegionServer的快速重启以及宕机恢复 2. 可以减少总的RCP数量 3. 有利于产生更少的、更大的flush	1. Compaction效果很差，会引起较大的数据写入抖动，稳定性较差 2. 不利于集群之间负载均衡

可以看出来，在HBase当前工作模式下，Region太多或者太少都不是一件太好的事情，在实际线上环境需要选择一个折中点。官方文档给出的一个推荐范围在20～200之间，而单个Region大小控制在10G~30G，比较符合实际情况。

然而，HBase并不能直接配置一台RegionServer上的Region数，Region数最直接取决于RegionSize的大小配置hbase.hregion.max.filesize，HBase认为，一旦某个Region的大小大于配置值，就会进行分裂。

hbase.hregion.max.filesize默认为10G，如果一台RegionServer预期运行100个Region，那单台RegionServer上数据量预估值就为：10G * 100 * 3 = 3T。反过来想，如果一台RegionServer上想存储12T数据量，那按照单Region为10G计算，就会分裂出400个Region，很显然不合理。此时就需要调整参数hbase.hregion.max.filesize，将此值适度调大，调整为20G或者30G。而实际上当下单台物理机所能配置的硬盘越来越大，比如36T已经很普遍，如果想把所有容量都用来存储数据，依然假设一台RegionServer上分布100个Region，那么每个Region的大小将会达到可怕的120G，一旦执行Compaction将会是一个灾难。

可见，对于当下的HBase，如果想让HBase工作的更加平稳（Region个数控制在20～200之间，单Region大小控制在10G~30G之间），最多可以存储的数据量差不多为200 * 30G ＊ 3＝ 18T。如果存储的数据量超过18T，必然会引起或多或少的性能问题。所以说，从Region规模这个角度讲，当前单台RegionServer能够合理利用起来的硬盘容量上限基本为18T。

然而随着硬件成本的不断下降，单台RegionServer可以轻松配置40T＋的硬盘容量，如果按照上述说法，越来越多的硬盘其实只是’镜中月，水中花’。社区也意识到了这样的问题，在当前Region的概念下提出了Sub-Region的概念，可以简单理解为将当前的Region切分为很多逻辑上小的Sub-Region。Region还是以前的Region，只是所有之前以Region为单位进行的Compaction将会以更小的Sub-Region粒度执行。这样，单Region就可以配置的很大，比如50G、100G，此时单台RegionServer上也就可以存储更多的数据。个人认为Sub-Region功能将会是HBase开发的一个重点。