概念

分布式key-value数据库，面向数十亿数据的实时入库与快速的随机访问。上百万的QPS与PB级数据，需要专门学习。

Hbase与MP一起操作比较少见，与Java API操作较多。

组件构成

• HMaster：集群管理

• HRegion Server：具体的数据存取

• Zookeeper：集群状态管理与元数据的存储

Hbase组件构成

数据存储，可存储

• 本地文件系统

• 或 HDFS分布式文件系统

• 或 其他对象存储： S3(AWS）、OSS（Aliyun）、OBS(华为云）

亿级平台集群

• 1、服务器选型

• 2、配置优化

• 3、日常运维

一、 服务器选型

内容如下：

• 1、确定集群的承载量

• 2、确定所需要的内存

• 3、确定CPU型号和核数

• 4、确定磁盘类型和容量

• 5、确定网络承载

确定集群的承载量

确定最大的承载量，是Hbase的最基础的需求。在处理能力适中的情况上，Hbase的处理能力是根据RegionServer横向扩展：比如集群总体10w/s读写能力，处理能力是根据RegionServer横向扩展，其集群的承载量设计如下：

集群的承载量设计

如此配置，每天的入库量在86亿条。计算规则：

1w/s * 3600秒/h * 24h * 10台主机 = 86400万 ，约等于86亿条

确定所需要的内存

Hbase内存型数据库是同存型数据库，数据写入规则：

1. 先存储在Memostore中 ，

2. 同时将经常查询的热数据缓存在内存中RedCache，提高性能。

Hbase内存型数据库

因此Hbase是对内存要求比较高的服务， 为了保证Hbase运行的稳定，线上要求Hbase的服务器的内存配置为：16GB、32GB、64GB

确定CPU核数

为了保证快速的对Hbase数据进行处理，我们选择4核、8核、16核。

根据对数据实时性要求高低配置不同的配置，如果对实时性要求不高的，我们选择4核16G，以够用为原则。CPU与内存的比例1/4，如下图：

CPU核数与内存关系表

确定磁盘类型和容量

1、磁盘选型：

• HDD: 数据大小写与读取请求数适中

• SSD：有大量高效读取请求

以下需求选择SSD加快数据的读取效率：

• 数据比较大，比如10GB

• 对数据 Read(读操作）要求频繁

以下需求选择HDS即可：

• 高速写入，比如500M/S

• 稀疏写入的场景

2、磁盘容量

根据数据量确定磁盘容量盘大小，参考如下指标：

• 数据结构

• 压缩算法

• 副本数

• 数据存储时长

方法：通过在测试环境写入一部份数据来确定每条数据大小，再根据存储长短与副本确定磁盘大小。

确定网络的承载量

Hbase的副本机制，需要将一份数据的多个副本实时存储在多个HDFS上，保存一个副本数据丢失，可以从其他副本中恢复数据。

对网络的要求是只要能保证网络能实时完成多副本写入数据即可。

Hbase的副本机制

1、副本数与网络带宽算法

预估方式：

• 假设一条数据大小为10kb，10万/秒的写入速度，每秒写入的数据量如下：

10kb * 10万/1024MB = 976MB

image.png

• 保存3个副本的数据，则网络带宽至少是

3 * 976MB/s = 2928MB/s  大约2.9GB

2、Rebalance

良好的网络运营环境，也能保障集群发生Rebalance所需要的时间不会太长。

服务器选型总结

项目	要点
数量承载量
所需内存	写入先缓存到Memstore、热数据缓存Redcache，16G、32G、64G
CPU型号与核数	和内存1/4的关系，对速度要求不高可选4核
磁盘选型与容量	SSD与HDD、 容量由“数据结构、压缩算法、副本数、数据存储时间
网络承载量	副本机制计算带宽、网络环境对Relance的影响

配置优化

操作系统和Hbase集群参数调优，以达最优性能表现。

一、 操作系统调优

• 文件句柄数

• 最大虚拟内存

• Swap内存设置

同样适用于Mangodb、Cassandra、Elasticsearch等nosql数据库。

文件句柄数

Linux默认的句柄数为1024，不适合作为服务器的linux，修改如下：

echo "* soft nofile 65535" >>  /etc/security/limits.conf

echo "* hard nofile 65535" >>  /etc/security/limits.conf

最大虚拟内存

max_map_count： 定义为进程能拥有的最多的内存区域，建议设置如下：

sysctl -w vm.max_map_count=102400

Swap内存设置

Swap开启是为了服务器吞吐量，但Hbase需要一个内存操作都能快速执行的环境，关闭Swap会提高读效率，设置如下

echo  "vm.swappiness = 0" >> /etc/sysctl.conf

二、Hbase配置优化

配置优化项很多，这里讲主要参数

Hbase RegionServer的JVM内存配置

• 1、堆内存

Hbase实时数据首先写入Memstore内存中，再到磁盘，同时缓存热点数据。

分配数量计算规则参考，以操作系统总内存为32G为例：

Hbase JVM堆内存：24G(3/4)

操作系统+JVM堆外内存：8G（1/4） -- 保存系统稳定运行

配置信息如下

hbase_regionserfver_opts -Xmx24g -Xms24g -Xmn6g

#Xmx - 设定程序启动时占用堆内存大小

#Xms - 设定程序运行期间最大可占用的内存大小（超出为OOM）

#Xmn - 年轻代大小

• 2、G1垃圾回收器的配置

G1垃圾回收器能有效的降低JVM full CG的次数。

-XX: +UseG1GC #配置G1垃圾回收，JDK升级到11(jdk8不支持）

-XX: MaxGCPauseMillis = 500

-XX: +ParalleRefProcEnabled

-XX: -ResizePLAB

-XX: +ParalleGCThreads=8

-Xloggc: /data/log/hbase/gc/gc-%t.log

-XX: +PrintGCDetails

-XX: +PrintGCTimeStamps

-XX: +PrintGCCause

-XX: +PrintTenuringDistribution

-XX: +UseGCLogFileRotation

-XX: NumberOfGCLogFile=20

-XX: GCLogFileSize=5M

Hbase 线程参数设置

和CPU计算资源相关

• Hbase.regionserver.handler.count：regionserver同时支持的线程数

regionserver同时支持的线程数

• compaction.small和compaction.large

负载所有的compaction请求，当文件compaction总大小>（大于）throttlePoint，则compation分配给largeCompaction线程池，否则由smallCompaction线程池处理。

具体配置

# 配置throttlePoint，默认为2.5G

hbase.regionserver.thread.compaction.throttlePoint: 2.5G

# smallCompaction和largeCompaction线程池默认都只有1个线程

hbase.regionserver.thread.compaction.small: 4

hbase.regionserver.thread.compaction.large: 6

• hbase.regionserver.max.filesize

数据写入流程，数据合并与分裂的基本流程。

数据写入流程

1. 先写入Memstore，超过阀值，写入StoreFile(HFile), 超过阀值，启动compaction，合并为一个StoreFile，当合并后的StoreFile大于hbase.regionserver.max.filesize所设置的参数时，会触发分裂动作，拆分为两个region

2. hbase.regionserver.max.filesize的需大小适中。当filesize太小，则触发分裂的机率更大，系统整体访问服务会出现不稳定现象。当filesize太大，一次compaction 与split所需要的时间会较长，甚至产生停顿感，太大不适合常 compaction 与split，对应用读写冲击较大。

3. 实战经验，高并发情况下，最佳大小是5~10G

# 参数的设置和单条数据的大小，和Region个数有关

# 参数调优必选项

hbase.regionserver.max.filesize 10G

4. 高峰时关闭hbase表的major_compact

关闭hbase表的major_compact是为避免major_compact对系统性能的影响。非高峰时期时，再调用major_compact对hbase表进行大合并，可减少split时间极大的提升集群性能和吞吐量。

语句如下，

major_compact 'table_name'

• hfile.block.cache.size

regionserver cache的大小，

#表示占hbase整个堆内存的0.2

hfile.block.cache.size 0.2

往大的调，会提升查询性能；大量查询为主，写入频率不高的情况下，设置为0.5即可.

• hfile.hregion.memstore.flush.size

一个regionserver默认的memstore的大小，默认为64MB。参考平均每个regionserver管理的region数量，如果管理量不大，可适当往大调整，如下：

hfile.hregion.memstore.flush.size 512MB

• hfile.regionserver.global.memstore.upperLimit

• hfile.regionserver.global.memstore.lowerLimit

upperLimit与lowerLimit指定memStore总使用内存大小百分比。upperLimit 开始刷盘百分比，lowerLimit 停止刷盘百分比。

upperLimit与lowerLimit的关系及作用

读取频繁写入不频繁：适当调小，让更多内存让给查询缓存。

hfile.regionserver.global.memstore.upperLimit 6  #开始刷盘

hfile.regionserver.global.memstore.lowerLimit 4  #停止刷盘

Hbase日常维护

• 指定Rowkey规则

• Region预分区

• 开启数据压缩

• 监控报警

指定RowKey规则

不合理的规则，会造成regionserver上的数据不均匀，造成数据倾斜，进行让某一个regionserver过热。

1、尽量保存Rowkey随机性

指定Rowkey规则

2、预创建分区

create 't1','f1',SPLITS_FILE => 'splits.txt';

预先根据可能的RowKey划分出多个Region而 不是一个，从而可以将后续的多个操作均衡到不同的Region上，避免热点现象的产生。

开启数据压缩

Hbase存储的数据以PB级别为主，将造成服务器磁盘费用过高。

create 'test',{NAME -> 'C', COMPRESSION => 'SNAPPY'};

Hbase默认的压缩算法有: GZ、LZO以及snappy，其中snappy算法其压缩率与性能最优。

监控告警

安装Cloudera 监控对Hbase实时状态进行监控。