HBase的优化

文章目录

• • 高可用
  • Hadoop通用性优化
  • Linux优化
  • zookeeper的优化
  • HBase优化
  • 1) NameNode 元数据备份使用 SSD
  • 2) 定时备份 NameNode 上的元数据
  • 3)为NameNode指定多个元数据目录
  • 4) NameNode 的dir 自恢复
  • 5)HDFS保证RPC调用会有较多的线程数
  • 6) HDFS 副本数的调整
  • 7)HDFS文件块大小调整
  • 8) MapReduce Job 任务服务线程数调整
  • 9) Http 服务器工作线程数
  • 10) 文件排序合并优化
  • 11) 设置任务并发
  • 12) MR输出数据的压缩
  • 13) 优化Mapper和Reducer的个数
  • 1) 开启文件系统的预读缓存可以提高读取速度
  • 2)关闭进程睡眠池
  • 3) 调整ulimit上限,默认值为比较小的数字
  • 4) 开启集群时间同步NTP
  • 5)更新系统补丁
  • 1) 优化 Zookeeper
  • 1) 允许在HDFS的文件中追加内容
  • 2) 优化DataNode允许的最大文件打开数
  • 3) 优化延迟高的数据操作的等待时间
  • 4) 优化数据写入效率
  • 5) 优化 DataNode
  • 6) 设置RPC监听数量
  • 7) 优化 HStore 文件大小
  • 8) 优化Hbase客户端缓存
  • 9) 指定 scan.next 扫描 HBase
  • 10) flush 、compact 、split
  • 1) 生成随机数,hash,散列值
  • 2) 字符串反转
  • 3) 字符串拼接
  • 1) 手动设定预分区
  • 2) 生成16进制序列预分区
  • 3) 按照文件中设置的规则预分区
  • 4)使用JavaAPI预分区
  • 预分区
  • RowKey的设计
  • 内存优化
  • 基础优化

高可用

在Hbase中HMaster负责监控RegionServer的生命周期,均衡RegionServer的负载,如果HMaster挂掉,整个HBase集群将陷入不健康状态,并且此时的工作状态不会维持太久,所以对HBase支持HMaster高可用配置

1. 关闭 HBase 集群 （ 如果没有开启则跳过此 步）

$ bin/stop-hbase.sh

1. 在 在 conf 目录下创建 backup-masters 文件

$ touch conf/backup-masters

1. 在 在 backup-masters 文件中配置高可用 HMaster

$ echo linux02 > conf/backup-masters

1. 将整个 conf 目录 scp

$ scp -r conf/ linux02:/opt/modules/cdh/hbase-0.98.6-cdh5.3.6/

$ scp -r conf/ linux03:/opt/modules/cdh/hbase-0.98.6-cdh5.3.6/

1. 打开页面测试查看

0.98 版本之前：http://linux01:60010
0.98 版本之后：http://linux01:16010

Hadoop通用性优化

1) NameNode 元数据备份使用 SSD

2) 定时备份 NameNode 上的元数据

每小时或者每天备份，如果数据极其重要,可以5-10分钟备份一次,备份可以通过定时任务复制元数据集目录即可.

3)为NameNode指定多个元数据目录

使用 dfs.name.dir 或者 dfs.namenode.name.dir 指定。这样可以提供元数据的冗余和健壮性，以免发生故障

4) NameNode 的dir 自恢复

设置 dfs.namenode.name.dir.restore 为 true，允许尝试恢复之前失败的 dfs.namenode.name.dir目录,在尝试checkpoint时做此尝试,如果设置了多个磁盘,建议允许

5)HDFS保证RPC调用会有较多的线程数

hdfs-site.xml

属性：dfs.namenode.handler.count

解释:该属性是 NameNode 服务默认线程数，的默认值是 10，根据机器的可用内存可以调整为 50~100

属性：dfs.datanode.handler.count

解释:该属性默认值为10,是Datanode的处理线程数,如果HDFS客户端程序读写请求比较多,可以调到15-20,设置值越大,内存消耗越多,不要调整过高,一般业务中5-10即可

6) HDFS 副本数的调整

hdfs-site.xml

属性：dfs.replication

解释:如果数据量巨大,且不是非常重要,可以调整为2-3,如果数据非常之重要,可以调整为3-5

7)HDFS文件块大小调整

hdfs-site.xml

属性：dfs.blocksize

解释：块大小定义，该属性应该根据存储的大量的单个文件大小来设置，如果大量的单个文
件都小于 100M，建议设置成 64M 块大小，对于大于 100M 或者达到 GB 的这种情况，建议
设置成 256M，一般设置范围波动在 64M~256M 之间。

8) MapReduce Job 任务服务线程数调整

mapred-site.xml

属性：mapreduce.jobtracker.handler.count

解释:该属性是Job任务线程数,默认是10,根据机器内存可以调整为50-100

9) Http 服务器工作线程数

mapred-site.xml

属性：mapreduce.tasktracker.http.threads
解释：定义 HTTP 服务器工作线程数，默认值为 40，对于大集群可以调整到 80~100

10) 文件排序合并优化

mapred-site.xml

属性：mapreduce.task.io.sort.factor

解释:文件排序时同时合并的数据流的数量,这也定义了同时打开文件的个数,默认值为10,如果调高该参数,可以明显减少次磁盘的IO,即减少文件读取次数

11) 设置任务并发

mapred-site.xml

属性：mapreduce.map.speculative

解释:该属性可以设置任务是否可以并发执行,如果任务多而少,该属性设置为true可以明显加快任务执行效率,但是对于延迟非常高的任务,建议改为false

12) MR输出数据的压缩

mapred-site.xml

属性：mapreduce.map.output.compress、mapreduce.output.fileoutputformat.compress
解释：对于大集群而言，建议设置 Map-Reduce 的输出为压缩的数据，而对于小集群，则不
需要。

13) 优化Mapper和Reducer的个数

mapred-site.xml

属性：
mapreduce.tasktracker.map.tasks.maximum
mapreduce.tasktracker.reduce.tasks.maximum

解释:

设置一个单独job的Map和Reduce的数量,设置上面两个参数时,考虑cpu核数,磁盘和内存容量,假设是一个8核的cpu,业务内容非常消耗cpu,可以设置map数量为4,如果该业务不是特别消耗cpu类型的,可以设置map数量为40,Reduce个数为20,这些参数修改完成之后,要 观察是否有较长的等待任务,若有,可以减少数量以加快任务执行,如果设置很大,引起大量上下文切换,以及内存与磁盘之间的数据交换,这里没有标准配置,需要根据业务以及硬件配置以及经验选择

同一时刻,不要同时运行太多的MR,消耗过多内存, 任务执行缓慢.

根据cpu核数,内存容量设置一个MR任务并发的最大值,使得固定数据量的任务完全加载到内存中,避免频繁的内存和磁盘数据交换,从而降低磁盘IO提高性能

大概估算公式

map = 2 + ⅔cpu_core

reduce = 2 + ⅓cpu_core

Linux优化

1) 开启文件系统的预读缓存可以提高读取速度

$ sudo blockdev --setra 32768 /dev/sda

注意: ra是readahead缩写

2)关闭进程睡眠池

不允许后台进程进入睡眠状态,如果进程空闲,则直接kill掉释放资源

$ sudo sysctl -w vm.swappiness=0

3) 调整ulimit上限,默认值为比较小的数字

$ ulimit -n 查看允许最大进程数
$ ulimit -u 查看允许打开最大文件数

优化修改:

$ sudo vi /etc/security/limits.conf 修改打开文件数限制
末尾添加：

• soft nofile 1024000
• hard nofile 1024000
  Hive - nofile 1024000
  hive - nproc 1024000
  $ sudo vi /etc/security/limits.d/20-nproc.conf 修改用户打开进程数限制

修改为

#* soft nproc 4096
#root soft nproc unlimited

• soft nproc 40960
  root soft nproc unlimited

4) 开启集群时间同步NTP

集群中某台机器同步网络时间服务器的时间,集群中其他机器则同步这台机器的时间

5)更新系统补丁

更新补丁之前,测试新版本补丁对于集群的节点兼容性

zookeeper的优化

1) 优化 Zookeeper

参数：zookeeper.session.timeout
解释：In hbase-site.xml, set zookeeper.session.timeout to 30 seconds or less to bound failure
detection (20-30 seconds is a good start).该值会直接关系到 master 发现服务器宕机的最大周
期，默认值为 30 秒，如果该值过小，会在 HBase 在写入大量数据发生而 GC 时，导致
RegionServer 短暂的不可用，从而没有向 ZK 发送心跳包，最终导致认为从节点 shutdown。
一般 20 台左右的集群需要配置 5 台 zookeep

HBase优化

预分区

每个region维护一着startRow与endRowKey,如果加入的数据符合某个region维护的rowKey范围,则该数据交给这个region维护,依照这个原则,可以将数据索要投放到分区提前大致规划好,提高HBase性能

1) 手动设定预分区

hbase> create ‘staff’,‘info’,‘partition1’,SPLITS => [‘1000’,‘2000’,‘3000’,‘4000’]

2) 生成16进制序列预分区

create ‘staff2’,‘info’,‘partition2’,{NUMREGIONS => 15, SPLITALGO => ‘HexStringSplit’}

3) 按照文件中设置的规则预分区

创建split.txt文件,内容如下

aaa

bbb

ccc

ddd

然后执行

create ‘staff3’,‘partition3’,SPLITS_FILE => ‘splits.txt’

4)使用JavaAPI预分区

1.自定义算法,产生一系列Hash散列值存储在二维数组中

byte[][] splitKeys = 某个散列值函数

2.创建HBaseAdmin实例

HBaseAdmin hAdmin = new HBaseAdmin(HBaseConfiguration.create());

3.创建HTableDescriptor实例

HTableDescriptor tableDesc = new HTableDescriptor(tableName);

4.通过HTableDescriptor实例和散列值二维数组创建带有预分区的HBase表

hAdmin.createTable(tableDesc, splitKeys);

RowKey的设计

一条数据的唯一标识就是rowKey,那么这条数据存储在哪个分区,取决于rowkey处于哪个预分区的区间内,设计rowkey主要目的就是让数据均匀分布于所有的region中,在一定程度上防止数据倾斜

设计方案

1) 生成随机数,hash,散列值

比如：
原本 rowKey 为 1001 的，SHA1 后变成：dd01903921ea24941c26a48f2cec24e0bb0e8cc7
原本 rowKey 为 3001 的，SHA1 后变成：49042c54de64a1e9bf0b33e00245660ef92dc7bd
原本 rowKey 为 5001 的，SHA1 后变成：7b61dec07e02c188790670af43e717f0f46e8913
在做此操作之前，一般我们会选择从数据集中抽取样本，来决定什么样的 rowKey 来 Hash
后作为每个分区的临界值。

2) 字符串反转

20170524000001 转成 10000042507102
20170524000002 转成 2000004250710

这样也可以在一定程度上散列逐步put进来的数据

3) 字符串拼接

20170524000001_a12e
20170524000001_93i7

内存优化

HBase操作过程中,大量的内存开销,毕竟table是可以缓存在内存中的,一般会分配整个可用内存的70%给HBase的Java堆,但是不建议分配较大的堆内存,因为GC过程持续太久导致RegionServer处于长期不可用状态,一般16至48G就可以,如果框架占用内存过高,导致内存不足,框架一样被系统服务拖死

基础优化

1) 允许在HDFS的文件中追加内容

hdfs-site.xml 、hbase-site.xml

属性：dfs.support.append

解释：开启 HDFS 追加同步，可以优秀的配合 HBase 的数据同步和持久化。默认值为 true.

2) 优化Datanode允许的最大文件打开数

hdfs-site.xml

属性：dfs.datanode.max.transfer.threads
解释：HBase 一般都会同一时间操作大量的文件，根据集群的数量和规模以及数据动作，设
置为 4096 或者更高。默认值：4096

3) 优化延迟高的数据操作的等待时间

hdfs-site.xml

属性：dfs.image.transfer.timeou

解释: 对于某一次数据操作来讲,延迟非常高,Socket需要等待更长时间,建议把该值设置更大

默认是(6w毫秒),确保Socket不会被timeout掉

4) 优化数据写入效率

mapred-site.xml

属性：
mapreduce.map.output.compress
mapreduce.map.output.compress.codec
解释：开启这两个数据可以大大提高文件的写入效率，减少写入时间。第一个属性值修改为
true，第二个属性值修改为：org.apache.hadoop.io.compress.GzipCodec 或者其他压缩方式

5) 优化 Datanode

属性：dfs.datanode.Failed.volumes.tolerated
解释： 默认为 0，意思是当Datanode中有一个磁盘出现故障，则会认为该Datanode shutdown
了。如果修改为 1，则一个磁盘出现故障时，数据会被复制到其他正常的 Datanode 上，当
前的 Datanode 继续工作

6) 设置RPC监听数量

hbase-site.xml

属性：hbase.regionserver.handler.count
解释：默认值为 30，用于指定 RPC 监听的数量，可以根据客户端的请求数进行调整，读写
请求较多时，增加此值

7) 优化 HStore 文件大小

hbase-site.xml

属性：hbase.hregion.max.filesize
解释：默认值 10737418240（10GB），如果需要运行 HBase 的 MR 任务，可以减小此值，
因为一个 region 对应一个 map 任务，如果单个 region 过大，会导致 map 任务执行时间过长。
该值的意思就是，如果 HFile 的大小达到这个数值，则这个 region 会被切分为两个 Hfile

8) 优化Hbase客户端缓存

hbase-site.xml

属性：hbase.client.write.buffer
解释：用于指定 HBase 客户端缓存，增大该值可以减少 RPC 调用次数，但是会消耗更多内
存，反之则反之。一般我们需要设定一定的缓存大小，以达到减少 RPC 次数的目的.

9) 指定 scan.next 扫描 HBase

hbase-site.xml

属性：hbase.client.scanner.caching
解释：用于指定 scan.next 方法获取的默认行数，值越大，消耗内存越大

10) flush 、compact 、split

当Memstore达到阈值,将Memstore中的数据Flush进storeFile,compact机制则是把flush出来的小文件合并成大的StoreFile文件,split则是当Region达到阈值,会把过大的Region一分为二.

**涉及属性:**即128M是Memstore默认阈值

hbase.hregion.memstore.flush.size：134217728

即当这个参数作用是当单个Region内所有的MemStore大小总和超过指定值时,flush该Region的所有memstore.RegionServer的Flush是通过将请求添加一个队列,模拟生产消费模型来异步处理的,这里就有一个问题,当队列消费来不及产生大量的积压请求时,可能会导致内存徒增,最坏的情况就是OOM

hbase.regionserver.global.memstore.upperLimit：0.4
hbase.regionserver.global.memstore.lowerLimit：0.38

当MemStore使用内存总量达到hbase.regionserver.global.memstore.upperLimit 指定值时,将会有多个MemStore flush到文件中,MemStore flush 顺序是按照大小降序执行的,直到刷新到MemStore使用内存略小于lowerLimit