HBase 的优化

1、高可用
在 HBase 中 Hmaster 负责监控 RegionServer 的生命周期，均衡 RegionServer 的负载，如果Hmaster 挂掉了，那么整个 HBase 集群将陷入不健康的状态，并且此时的工作状态并不会维持太久。所以 HBase 支持对 Hmaster 的高可用配置。
1 关闭 HBase 集群（如果没有开启则跳过此步）
bin/stop-hbase.sh

2 在 conf 目录下创建 backup-masters 文件
touch conf/backup-masters

3 在 backup-masters 文件中配置高可用 HMaster 节点
echo hadoop102 > conf/backup-masters

4 将整个 conf 目录 scp 到其他节点
xsync conf/backup-masters

5 打开页面测试查看
0.98 版本之前： http://hadoop102:60010
0.98 版本之后： http://hadoop102:16010

2、 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。这些参数的值修改完成之后，一定要观察
是否有较长等待的任务，如果有的话，可以减少数量以加快任务执行，如果设置一个很大的
值， 会引起大量的上下文切换，以及内存与磁盘之间的数据交换，这里没有标准的配置数值，
需要根据业务和硬件配置以及经验来做出选择。
在同一时刻，不要同时运行太多的 MapReduce，这样会消耗过多的内存，任务会执行的非
常缓慢，我们需要根据 CPU 核数，内存容量设置一个 MR 任务并发的最大值，使固定数据
量的任务完全加载到内存中，避免频繁的内存和磁盘数据交换，从而降低磁盘 IO，提高性
能。

大概估算公式：
map = 2 + ⅔cpu_core
reduce = 2 + ⅓cpu_core

3、 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 更新系统补丁
更新补丁前，请先测试新版本补丁对集群节点的兼容性。

4、 Zookeeper 优化
1 优化 Zookeeper 会话超时时间
hbase-site.xml

参数： 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 台 zookeeper。

5、 HBase 优化
1、预分区
每一个 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) 按照文件中设置的规则预分区
创建 splits.txt 文件内容如下：

aaaa
bbbb
cccc
dddd

然后执行：
create 'staff3','partition3',SPLITS_FILE => 'splits.txt'

4) 使用 JavaAPI 创建预分区

//自定义算法，产生一系列 Hash 散列值存储在二维数组中
byte[][] splitKeys = 某个散列值函数
//创建 HBaseAdmin 实例
HBaseAdmin hAdmin = new HBaseAdmin(HBaseConfiguration.create());
//创建 HTableDescriptor 实例
HTableDescriptor tableDesc = new HTableDescriptor(tableName);
//通过 HTableDescriptor 实例和散列值二维数组创建带有预分区的 HBase 表
hAdmin.createTable(tableDesc, splitKeys);

2、 RowKey 设计
一条数据的唯一标识就是 rowkey，那么这条数据存储于哪个分区，取决于 rowkey 处于哪个一个预分区的区间内，设计 rowkey 的主要目的 ，就是让数据均匀的分布于所有的 region中，在一定程度上防止数据倾斜。 接下来我们就谈一谈 rowkey 常用的设计方案。

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

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

2) 字符串反转

20170524000001 转成 10000042507102
20170524000002 转成 20000042507102

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

3) 字符串拼接

20170524000001_a12e
20170524000001_93i7

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

4、 基础优化
1) 允许在 HDFS 的文件中追加内容
不是不允许追加内容么？没错，请看背景故事：
http://blog.cloudera.com/blog/2009/07/file-appends-in-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.timeout
解释：如果对于某一次数据操作来讲，延迟非常高， socket 需要等待更长的时间，建议把该
值设置为更大的值（默认 60000 毫秒），以确保 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
即：这个参数的作用是当单个 HRegion 内所有的 Memstore 大小总和超过指定值时， flush该 HRegion 的所有 memstore。 RegionServer 的 flush 是通过将请求添加一个队列，模拟生产消费模型来异步处理的。那这里就有一个问题，当队列来不及消费，产生大量积压请求时，可能会导致内存陡增，最坏的情况是触发 OOM。
hbase.regionserver.global.memstore.upperLimit： 0.4
hbase.regionserver.global.memstore.lowerLimit： 0.38
即：当 MemStore 使用内存总量达到hbase.regionserver.global.memstore.upperLimit 指定值时，将会有多个 MemStores flush 到文件中， MemStore flush 顺序是按照大小降序执行的，直到刷新到 MemStore 使用内存略小于 lowerLimit