全面总结Hbase优化方案

﹏ヽ暗。殇╰゛Y 2023-03-01 05:57 1阅读 0赞

**Hbase应用**  
HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库，是谷歌BigTable的开源实现，主要用来存储非结构化和半结构化的松散数据。HBase的目标是处理非常庞大的表，可以通过水平扩展的方式，利用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表。

因此，对HBase性能提出了一定的要求，那么如何进行HBase性能优化呢？

## 对表的设计进行优化 ##

#### 1、RowKey 设计 ####

在HBase中，rowkey可以是任意字符串，最大长度64KB，实际应用中一般为10~100bytes，存为byte\[\]字节数组，一般设计成定长的。  
row key是按照字典序存储，因此，设计row key时，要充分利用这个排序特点，  
将经常一起读取的数据存储到一块，将最近可能会被访问的数据放在一块。

举个例子：  
如果最近写入HBase表中的数据是最可能被访问的，可以考虑将时间戳作为row key的一部分，由于是字典序排序，所以可以使用Long.MAX\_VALUE - timestamp作为row key，这样能保证新写入的数据在读取时可以被快速命中。

一条数据的唯一标识就是 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

#### 2、列簇的设计 ####

不要在一张表里定义太多的column family。目前Hbase并不能很好的处理超过2~3个column family的表。  
因为某个column family在flush的时候，它邻近的column family也会因关联效应被触发flush，最终导致系统产生更多的I/O。

#### 3、In Memory ####

创建表的时候，可以通过HColumnDescriptor.setInMemory(true)将表放到RegionServer的缓存中，保证在读取的时候被cache命中。

#### 4、Max Version ####

创建表的时候，可以通过HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大版本，如果只需要保存最新版本的数据，那么可以设置setMaxVersions(1)。

#### 5、Time To Live ####

创建表的时候，可以通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存储生命期，过期数据将自动被删除；  
例如如果只需要存储最近两天的数据，那么可以设置setTimeToLive(2 \* 24 \* 60 \* 60)。（相当于Linux中的Crontab任务）。

#### 6、Compact & Split ####

在HBase中，数据在更新时首先写入WAL 日志(HLog)和内存(MemStore)中，MemStore中的数据是排序的，  
当**MemStore**累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。  
于此同时， 系统会在zookeeper中记录一个redo point，表示这个时刻之前的变更已经持久化了(minor compact)。

**StoreFile**是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。  
当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并(major compact)，  
将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对 StoreFile进行分割(split)，等分为两个StoreFile。

由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部的StoreFile和MemStore，将它们按照row key进行合并；  
由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，通常合并过程还是比较快的。

实际应用中，可以考虑必要时手动进行major compact，将同一个row key的修改进行合并形成一个大的StoreFile。同时，可以将StoreFile设置大些，减少split的发生。

**compaction介绍**  
hbase为了防止小文件（被刷到磁盘的menstore）过多，以保证保证查询效率，hbase需要在必要的时候将这些小的store file合并成相对较大的store file，这个过程就称之为compaction。  
在hbase中，主要存在两种类型的compaction：**minor compaction 和 major compaction。**

minor compaction:对较小、数量很少文件的合并。

**major compaction 的功能是将所有的store file合并成一个**；  
**触发major compaction的可能条件有**：major\_compact 命令、majorCompact() API、region server自动运行（相关参数：**hbase.hregion.majoucompaction 默认为24 小时**、**hbase.hregion.majorcompaction.jetter** 默认值为0.2 防止region server 在同一时间进行major compaction）。

**hbase.hregion.majorcompaction.jetter参**数的作用是：对参数hbase.hregion.majoucompaction 规定的值起到浮动的作用；  
假如两个参数都为默认值24和0,2，那么major compact最终使用的数值为：19.2~28.8 这个范围。

**minor compaction**的运行机制要复杂一些，它由一下几个参数共同决定：

**hbase.hstore.compaction.min** :默认值为 3，表示至少需要三个满足条件的store file时，minor compaction才会启动

**hbase.hstore.compaction.max** 默认值为10，表示一次minor compaction中最多选取10个store file

**hbase.hstore.compaction.min.size** 表示文件大小小于该值的store file 一定会加入到minor compaction的store file中

**hbase.hstore.compaction.max.size** 表示文件大小大于该值的store file 一定会被minor compaction排除

**hbase.hstore.compaction.ratio** 将store file 按照文件年龄排序（older to younger），minor compaction总是从older store file开始选择

#### 多线程并发写 ####

在客户端开启多个HTable写线程，每个写线程负责一个HTable对象的flush操作，这样结合定时flush和写buffer（writeBufferSize），可以既保证在数据量小的时候，数据可以在较短时间内被flush（如1秒内），同时又保证在数据量大的时候，写buffer一满就及时进行flush。

核心代码如下：

for (int i = 0; i < threadN; i++) { 
        Thread th = new Thread() { 
            public void run() { 
                while (true) { 
    		try { 
                        sleep(1000); //1 second
                    } catch (InterruptedException e) { 
                        e.printStackTrace();
                    }
     synchronized (wTableLog[i]) { 
                        try { 
                            wTableLog[i].flushCommits();
                        } catch (IOException e) { 
                            e.printStackTrace();
                        }
                    }
                }
     }
        };
        th.setDaemon(true);
        th.start();
    }

#### 多HTable并发读 ####

创建多个HTable客户端用于读操作，提高读数据的吞吐量

static final Configuration conf = HBaseConfiguration.create();
    static final String table_log_name = “user_log”;
    rTableLog = new HTable[tableN];
    for (int i = 0; i < tableN; i++) { 
          rTableLog[i] = new HTable(conf, table_log_name);
        rTableLog[i].setScannerCaching(50);
    }

#### 内存管理 ####

HBase上的Regionserver的内存主要分为两部分，一部分作为Memstore，主要用来写；一部分作为BlockCache，主要用于读。  
写请求会先写入Memstore，Regionserver会给每个region提供一个Memstore，当Memstore满128M(hbase.hregion.memstore.flush.size)以后，会启动flush刷新到磁盘，当Memstore的总大小超过限制时（heapsizehbase.regionserver.global.memstore.upperLimit0.9），会强行启动flush进程，从最大的Memstore开始flush知道低于限制。  
读请求先到Memstore中查数据，查不到就到BlockCache中查，再查不到就会到磁盘上读，并把读的结果放入BlockCache。  
由于ClockCache采用的是LRU（最近最少使用）策略，因此BlockCache达到上限（heapsizehfile.block.cache.size0.85）后，会启动淘汰机制，淘汰掉最老的一批数据。  
在注重读响应时间的应用场景下，可以将BlockCache设置大些，Memstore设置小些，以加大缓存命中率。

如果不希望自动触发溢写，就将值调大
    <name>hbase.hregion.memstore.flush.size</name>
        <value>134217728</value>
    一般在企业中这个参数是禁用的
    <name>hbase.hregion.majorcompaction</name>
       <value>604800000</value>
    直接将值设置为0就可以了，表示禁用
    
    何时执行split
    <name>hbase.hregion.max.filesize</name>
        <value>10737418240</value>
    一般建议将值调大，在期间手动去触发split

Memstore刷写数据到磁盘时，造成RegionServer内存碎片增多，当生存时间较长的数据从堆的老年代空间刷写到磁盘，就会产生内存孔洞。  
由于碎片过多导致没有足够大的连续内存空间，JVM就会暂停工作进程，进行垃圾回收（GC），导致HBase的RegionServer对外服务停顿。  
本地Memstore缓存机制：  
启用本地memstore分配缓存区（Memstore-Local Allocation Buffers，MSLAB），也就是允许从堆中分配相同大小的对象，  
一旦这些对象分配并且最终被回收，就会在堆中留下固定大小的孔洞，这些孔洞可被重复利用，GC就无需使应用程序进程停顿来回收内存空间，配置参数hbase.hregion.memstore.mslab.enabled，默认为true。

#### 启动SNAPPY压缩 ####

HBase列存储，比较占用空间，所以一般需要采用压缩算法，（从mysql导入hbase数据时发现，原本在mysql中30G数据，在hbase中占用150G），  
其中snappy性能优异，而且CDH中，直接安装了snappy的库。

使用方式：
           1、创建时指定格式；
           create 'test', {  NAME => 'c', COMPRESSION => 'SNAPPY' }
           2、修改已经创建好的列簇的压缩格式
           disable 'test'
           alter 'test', NAME => 'c', COMPRESSION => 'snappy'
           enable 'test'
           major_compact 'test'   --修改之后，需要做一个major合并才能养压缩格式生效
           describe 'test'  --查看有没有生效

**注意：**  
snappy是需要单独下载并编译安装的

#### 预创建Region ####

创建HBase时，就预先根据可能的RowKey划分出多个Region而不是默认的一个，从而可以将后续的读写操作负载均衡到不同的Region上，避免热点现象；  
HBase表的预分区需结合业务场景来选择分区的key值，每个region都有一个startKey和一个endKey来表示该region存储的rowKey范围；

//有以下四种创建方式：
    create 'ns1:t1' , 'f1' , SPLITS => ['10','20','30','40'] ;
    create 't1','f1',SPLITS_FILE => 'splits.txt', OWNER=> 'johnode' ;
    //其中splits.txt文件内容是每行一个rowkey值
    create 't1','f1',{ NUMREGIONS => 15, SPLITALGO =>'HexStringSplit'}
    
    JavaAPI
            HTableDescriptor desc = new HTableDescriptor(TableName.valueOf(weibo_content));
            HColumnDescriptor family = new HColumnDescriptor(Bytes.toBytes("cf"));
            // 开启列簇 -- store的块缓存
            family.setBlockCacheEnabled(true);
            family.setBlocksize(1024 * 1024 * 2);
            family.setCompressionType(Algorithm.SNAPPY);
            family.setMaxVersions(1);
            family.setMinVersions(1);
    
    	desc.addFamily(family);
    	byte[][] splitKeys = {  Bytes.toBytes("100"), Bytes.toBytes("200"), Bytes.toBytes("300") };
            admin.createTable(desc, splitKeys);

#### 负载均衡 ####

balance\_switch，master用来均衡各个regionserver上region数量

#### 避免Region热点 ####

热点现象：某个小的时段内，对HBase的读写请求集中到极少数的Region上，导致这些Region所在的RegionServer处理请求量骤增，负载量明显偏大，而其他的RegionServer明显空闲；

出现的原因：主要是因为Hbase表设计时，rowKey设计不合理造成的；  
RowKey设计原则：

1、总的原则：避免热点现象，提高读写性能；  
2、长度原则：最大长度64KB，开发通常10-16个字节，因为Hbase中每个单元格是以key-value进行存储的，因此每个value都会存储rowkey，所以rowkey越来越占空间;  
3、散列原则：将时间上连续产生的rowkey散列化，以避免集中到极少数Region上;  
4、唯一原则：必须在设计上保证rowkey的唯一性；  
具体操作在前面没寂静讲过就不多做概述了！

#### 基础优化 ####

**1．允许在 HDFS 的文件中追加内容**  
hdfs-site.xml、hbase-site.xml  
**属性**：dfs.support.append  
**解释**：开启 HDFS 追加同步，可以优秀的配合 HBase 的数据同步和持久化  
Hadoop2.0 默认值为 true。

**2．优化 DataNode 允许的最大文件打开数**  
hdfs-site.xml  
**属性**：hdfs.datanode.max.transfer.threads  
**解释**：HBase 一般都会同一时间操作大量的文件，根据集群的数量和规模以及数据动作，设置为 4096 或者更高。默认值：4096。该操作前提是 Linux 的文件最大数已经设置完成。

**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．设置 RPC 监听数量**  
hbase-site.xml  
**属性**：hbase.regionserver.handler.count  
**解释**：默认值为 30，用于指定 RPC 监听的数量，可以根据客户端的请求数进行调整，读写请求较多时，增加此值.

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

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

**8．指定 scan.next 扫描 HBase 所获取的行数**  
客户端配置  
**属性**：hbase.client.scanner.caching  
**解释**：用于指定 scan.next 方法获取的默认行数，值越大，消耗内存越大。

**9．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.size**：默认整个堆大小的 40%

regionServer 的全局 memstore 的大小，超过该大小会触发 flush 到磁盘的操作,默认是堆大小的 40%,而且 regionserver 级别的 flush 会阻塞客户端读写。

**hbase.regionserver.global.memstore.size.lower.limit**：默认堆大小*0.4*0.95

有时候集群的“写负载”非常高，写入量一直超过 flush 的量，这时，我们  
就希望 MemStore 不要超过一定的安全设置。

在这种情况下，写操作就要被阻塞一直到 MemStore 恢复到一个“可管理”的大小, 这个大小就是默认值是堆大小 \* 0.4 \* 0.95;  
也就是当 HRegionserver 级别的 flush 操作发送后,会阻塞客户端写,一直阻塞到整个 HRegionserver 级别的 MemStore 的大小为 堆大小 \* 0.4 \*0.95 为止。