打造一个亿级平台的 Hbase集群

  • 概念
  • 组件构成
  • 数据存储，可存储
  • 亿级平台集群
  • 服务器选型
  • 确定集群的承载量
  • 确定所需要的内存
  • 确定CPU型号和核数
  • 确定磁盘类型和容量
  • 磁盘选型：
  • 磁盘容量
  • 确定网络的承载量
  • Hbase的副本机制
  • 配置优化
  • 操作系统调优
  • Hbase配置优化
  • Hbase日常维护


概念

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

组件构成

HMaster：集群管理

HRegion Server：具体的数据存取

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

Hbase 入库工具 hbase入库1亿条_大数据

数据存储，可存储

本地文件系统
或 HDFS分布式文件系统
或 其他对象存储： S3(AWS）、OSS（Aliyun）、OBS(华为云）

亿级平台集群

服务器选型

内容如下：

确定集群的承载量

确定最大的承载量，是Hbase的最基础的需求。在处理能力适中的情况上，Hbase的处理能力是根据RegionServer横向扩展：比如集群总体10w/s读写能力，处理能力是根据RegionServer横向扩展，其集群的承载量设计如下：
集群的承载量设计，如此配置，每天的入库量在86亿条。计算规则

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

确定所需要的内存

Hbase内存型数据库是同存型数据库，数据写入规则：先存储在Memostore中 ，

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

Hbase 入库工具 hbase入库1亿条_大数据_02


Hbase内存型数据库

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

确定CPU型号和核数

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

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

Hbase 入库工具 hbase入库1亿条_数据_03

确定磁盘类型和容量

磁盘选型：

HDD: 数据大小写与读取请求数适中
SSD：有大量高效读取请求
以下需求选择SSD加快数据的读取效率：数据比较大，比如10GB，对数据 Read(读操作）要求频繁
以下需求选择HDS即可：高速写入，比如500M/S，稀疏写入的场景

磁盘容量

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

  • 数据结构
  • 压缩算法
  • 副本数
  • 数据存储时长

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

确定网络的承载量

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

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

Hbase 入库工具 hbase入库1亿条_数据_04

Hbase的副本机制

1、副本数与网络带宽算法
预估方式：假设一条数据大小为10kb，10万/秒的写入速度，每秒写入的数据量如下：

10kb * 10万/1024MB = 976MB

Hbase 入库工具 hbase入库1亿条_大数据_05


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

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

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

配置优化

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

操作系统调优

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

  • 文件句柄数
    Linux默认的句柄数为1024，不适合作为服务器的linux，修改如下
echo "* soft nofile 65535" >> /etc/security/limits.conf

echo "* hard nofile 65535"
  • 最大虚拟内存
    max_map_count： 定义为进程能拥有的最多的内存区域，建议设置如下：
sysctl -w vm.max_map_count=102400
  • Swap内存设置

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

echo "vm.swappiness = 0" >> /etc/sysctl.conf
Hbase配置优化

配置优化项很多，这里讲主要参数
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

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

Hbase 入库工具 hbase入库1亿条_大数据_06

数据写入流程

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

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

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

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

# 参数调优必选项

hbase.regionserver.max.filesize 10G
  • 高峰时关闭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
往大的调，会提升查询性能；大量查询为主，写入频率不高的情况下，设置为0.5即可.
hfile.block.cache.size 0.2
  • 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 停止刷盘百分比。

Hbase 入库工具 hbase入库1亿条_大数据_07


upperLimit与lowerLimit的关系及作用

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

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

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

Hbase日常维护

  • 指定Rowkey规则

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

1、尽量保存Rowkey随机性

Hbase 入库工具 hbase入库1亿条_大数据_08

  • Region预分区
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实时状态进行监控。