2.8.13 hadoop体系之离线计算-HBase数据库-HBase的优化

r囧r小猫 2022-12-27 04:52 151阅读 0赞

**目录**

1.高可用HA

2.预分区

3.RowKey设计

4.内存优化

5.基础优化

涉及属性：

--------------------

# 1.高可用HA #

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

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

\[atguigu@hadoop102 hbase\]$ bin/stop-hbase.sh

**（2）在 conf 目录下创建 backup-masters 文件**

\[atguigu@hadoop102 hbase\]$ touch conf/backup-masters

**（3）将整个 conf 目录 scp 到其他节点**

\[atguigu@hadoop102 hbase\]$ scp -r conf/ hadoop103:/opt/module/hbase/

\[atguigu@hadoop102 hbase\]$ scp -r conf/ hadoop104:/opt/module/hbase/

**（4）打开页面测试查看**

http://hadooo102:16010

# 2.预分区 #

每一个 region 维护着 StartRow 与 EndRow，如果加入的数据符合某个 Region 维护的 RowKey 范围，则该数据交给这个 Region 维护。那么依照这个原则，我们可以将数据所要 投放的分区提前大致的规划好，以提高 HBase 性能。

预分区与**数据量**和**机器规模（一般一个机器最大放2到3个region）**有关。

**（1）手动设定预分区**

Hbase> create 'staff1','info','partition1',SPLITS => \['1000','2000','3000','4000'\]

切了四刀（4个**分区键**），切了5个区，如果**按位比较**，4、40、400都落在了3000-4000的区。我们可以在前面拼接0000.1000.2000.3000.4000可以让我们第一眼就可以分辨出落在那个区，这个方法也并不是好的方法，可能会产生数据倾斜。分区键的设计会影响到rowkey的设计

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70][]

**（2）生成 16 进制序列预分区（用的比较少）**

create 'staff2','info','partition2',\{NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'\}

分成了15个分区

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 1][]

**（3）按照文件中设置的规则预分区（用的比较多）**

创建 splits.txt 文件内容如下（即使顺序不对，系统内部也会帮助我们进行排序）：

aa
    bb
    cc
    dd

然后执行：

create 'staff3','partition3',SPLITS\_FILE => 'splits.txt'

四个分区键，划分为了5个区

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 2][]

**（4）使用 JavaAPI 创建预分区 （用的最多）**

**二维数组：**比如我们传a,b,c,d。这整个是一个大的数组，但是a,b,c,d单独的又是一个数组，所以需要传一个二维字节数组。

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

# 3.RowKey设计 #

RowKey设计原则：唯一性、长度原则、散列性。

一条数据的**唯一标识**就是 RowKey（**唯一性**，**长度原则**【公司里面都是70-100位】），那么这条数据存储于哪个分区，取决于 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

** （3）字符串拼接**

20170524000001_a12e
    20170524000001_93i7

##  3.1 RowKey情景设计（电信数据统计） ##

需求：有一张数据表，其中包含手机号码字段。1. 查询一段时间内固定号码的所有数据 2. 查询一段时间内所有数据

131给189打电话，通话日期，通话时间，通话时长（秒）

![20201208150123950.png][]

我们拿到原始数据后，可以利用MR或者hive统计月份通话时间，通话详情等信息。

比如我们数据量很大，用hbase存储，我们希望拿到详情，我们已知分区数为300个区（大概有200多台机器），**预分区和RowKey我们应该怎么设计？**

### 思考 ###

300个区需要299个分区键，如果按照电话号码前几位肯定是不可以的。

### 分区键的设计 ###

设计成数字**(000-298)+|**，一共299个分区键，会划分为300个区。|的ASKI码非常大，可以起到拦截作用。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 3][]

### RowKey的设计（拼接上类似于分区键的东西） ###

设计成数字(000-298)+\_

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 4][]

### 考虑散列和集中性 ###

我们拿到通话详情数据，希望同一个手机号放在一个分区。我们需要将同一个手机号转化为RowKey中的同一个前缀。我们可以直接用手机号对299取mod，得到0-298，只要手机号相同，余数是相同的。一个分区中会有多个手机号，但是同一个手机号会进入到同一个分区。

因为一个分区中有多个手机号，我们希望集中读取数据，所以rowkey后面拼接手机号比较好，可以后面再拼接时间。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 5][]

另外为了让数据按照时间进行集中，我们后面拼接上时间（越关注什么，什么拼接在前面）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 6][]

### 如何确定数据落到哪个分区（怎么放）？ ###

![20201208163706340.png][]

### 如何查询某个范围的数据（怎么取）？ ###

我们希望查询 131232323这电话号码在2019-02这个月份的通话总记录，startRow和stopRow（左闭右开）：

这个电话号码对应的rowkey：

![20201208163852348.png][]

*  （1）我们首先需要拼接电话号和年月算出xxx是什么（怎么放的怎么取）
 *  （2）比如算出xxx是123，我们将startRow设为123\_131232212\_2019-02（左闭，可以取到这个值，2月份数据都比它大，不会丢数据，也不会多数据）
 *  （3）stopRow可以设为123\_131232212\_2019-03（右开，完整取到2月份数据），或者设为123\_131232212\_2019-02|（更好理解，起到拦截作用即可）

# 4.内存优化 #

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

# 5.基础优化 #

**（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.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-site.xml

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

**（8）指定 scan.next 扫描 HBase所获取的行数**

hbase-site.xml

属性：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.upperLimit：0.4
    hbase.regionserver.global.memstore.lowerLimit：0.38

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70]: /images/20221120/a51fd3fe6858498e831e230dbc6b5000.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 1]: /images/20221120/4d6edb2ece784e588c091ddc62c7edd8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 2]: /images/20221120/0683012499844673a73e6c6e69eab98f.png
[20201208150123950.png]: /images/20221120/f1f0d73a33234254a05fff26e426e7f0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 3]: /images/20221120/0e5b38ac55d74460acb72111ace6b4df.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 4]: /images/20221120/0954f2f1d15948d2b3d7cc02f7cd8e6d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 5]: /images/20221120/0b7d3cdd267b4fd5a9151d61a958a938.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 6]: /images/20221120/af8b431d70c24f5b8ae968afae7754f2.png
[20201208163706340.png]: /images/20221120/2675587947c045e198c13c6ed4019325.png
[20201208163852348.png]: /images/20221120/4de758aa8efa4f18b3e5e37236232d5e.png