HBase总结

参考自：
https://segmentfault.com/a/1190000019959411
尚硅谷HBase视频
HBase权威指南
HBase大神博客

文章目录

• • HBase架构
  • • 1.数据模型
    • 2.架构
  • HBase的读写操作
  • • HBase读操作
    • • Scanner体系
    • HBase写操作
    • • WAL机制
  • HBase Region Flush
  • StoreFile Compaction
  • • Compaction作用 | 副作用
    • Compaction流程
  • Region Split
  • • 切分策略
    • 寻找SplitPoint
    • Region核心切分流程
    • Region切分对其他模块的影响
  • HBase HFile
  • HBase数据备份和故障恢复
  • Rowkey 设计
  • • 数据热点问题
  • HBase性能优化
  • • 1. 垃圾回收优化
    • 2. 配置优化

HBase架构

1.数据模型

1. Name Space
   命名空间，类似于关系型数据库的 DatabBase 概念，每个命名空间下有多个表。 HBase有两个自带的命名空间，分别是 hbase 和 default， hbase 中存放的是 HBase 内置的表，default 表是用户默认使用的命名空间。

2. Region:类似于关系型数据库的表概念。HBase 表（Table）根据 rowkey 的范围被水平拆分成若干个 region。每个 region 都包含了这个region 的 start key 和 end key 之间的所有行（row）。Regions 被分配给集群中的某些节点来管理，即 Region Server，由它们来负责处理数据的读写请求。

3. Row:HBase 表中的每行数据都由一个 RowKey 和多个 Column（列）组成，数据是按照 RowKey的字典顺序存储的，并且查询数据时只能根据 RowKey 进行检索，所以 RowKey 的设计十分重要

4. Column:HBase 中的每个列都由 Column Family(列族)和 Column Qualifier（列限定符） 进行限定

5. Time Stamp:用于标识数据的不同版本（version）， 每条数据写入时， 如果不指定时间戳， 系统会自动为其加上该字段，其值为写入 HBase 的时间。

6. **Cell:**由{rowkey, column Family： column Qualifier, time Stamp} 唯一确定的单元。 cell 中的数
   据是没有类型的，全部是字节码形式存贮。

2.架构

物理上，Hbase 是由三种类型的 server 组成的的**主从式（master-slave）**架构：

• Region Server 负责处理数据的读写请求，客户端请求数据时直接和 Region Server 交互。
• HBase Master 负责 Region 的分配，监控每个 RegionServer的状态，负载均衡和故障转移。DDL（创建，删除 table）等操作。

1. 启动时分配 regions，在故障恢复和负载均衡时重分配 region
2. 监控集群中所有 Region Server 实例（从 Zookeeper 获取通知信息）

• Zookeeper，作为 HDFS 的一部分，负责维护集群状态，Master 的高可用、 RegionServer 的监控、元数据的入口以及集群配置的维护等工作。Zookeeper 维护了哪些 servers 是健康可用的，并且在 server 故障时做出通知。Zookeeper 使用一致性协议来保证分布式状态的一致性。

当然底层的存储都是基于 Hadoop HDFS 的：

• DataNode 负责存储 Region Server 所管理的数据。所有的 HBase 数据都存储在 HDFS 文件中Region Server 和 HDFS DataNode 往往是分布在一起的，这样 Region Server 就能够实现数据本地化（data locality，即将数据放在离需要者尽可能近的地方）。HBase 的数据在写的时候是本地的，但是当 region 被迁移的时候，数据就可能不再满足本地性了，直到完成 compaction，才能又恢复到本地。
  • Hadoop NameNode 维护了所有 HDFS 物理 data block 的元信息。

三者之间是如何工作的：

• Zookeeper 用来协调分布式系统中集群状态信息的共享。Region Servers 和 在线 HMaster（active HMaster）和 Zookeeper 保持会话（session）。Zookeeper 通过心跳检测来维护所有临时节（ephemeral nodes）。
• 每个 Region Server 都会创建一个 ephemeral 节点。HMaster 会监控这些节点来发现可用的 Region Servers，同样它也会监控这些节点是否出现故障
• HMaster 们会竞争创建 ephemeral 节点，而 Zookeeper 决定谁是第一个作为在线 HMaster，保证线上只有一个 HMaster。在线 HMaster（active HMaster） 会给 Zookeeper 发送心跳，不在线的待机 HMaster （inactive HMaster） 会监听 active HMaster 可能出现的故障并随时准备上位。
• Active HMaster 监听的是 region servers 下线的消息，然后会恢复故障的 region server 以及它所负责的 region 数据。而 Inactive HMaster 关心的则是 active HMaster 下线的消息，然后竞争上线变成 active HMaster。
• Zookeeper 是沟通一切的桥梁，所有的参与者都和 Zookeeper 保持心跳会话，并从 Zookeeper 获取它们需要的集群状态信息，来管理其它节点，转换角色

Meta table 是一个特殊的 HBase table，它保存了系统中所有的 region 列表。这张 table 类似一个 b-tree，结构大致如下：Key：table, region start key, region id Value：region server

RegionServer组成：
Region Server 运行在 HDFS DataNode 上，由以下组件组成：

• WAL：Write Ahead Log 是分布式文件系统上的一个文件，用于存储新的还未被持久化存储的数据，它被用来做故障恢复。

• BlockCache：这是读缓存，在内存中存储了最常访问的数据，是 **LRU（Least Recently Used）**缓存。

• MemStore：这是写缓存，在内存中存储了新的还未被持久化到硬盘的数据。当被写入硬盘时，数据会首先被排序。注意每个 Region 的每个 Column Family 都会有一个 MemStore。

• HFile 在硬盘上（HDFS）存储 HBase 数据，以有序 KeyValue 的形式。
  HBase HFile

• 数据存储在 HFile 中，以 Key/Value 形式。当 MemStore 累积了足够多的数据后，整个有序数据集就会被写入一个新的 HFile 文件到 HDFS 上。整个过程是一个顺序写的操作，速度非常快，因为它不需要移动磁盘头。（注意 HDFS 不支持随机修改文件操作，但支持 append 操作。）

• HFile 使用多层索引来查询数据而不必读取整个文件，这种多层索引类似于一个 B+ tree：

• KeyValues 有序存储。

• rowkey 指向 index，而 index 则指向了具体的 data block，以 64 KB 为单位。

• 每个 block 都有它的叶索引。

• 每个 block 的最后一个 key 都被存储在中间层索引。

• 索引根节点指向中间层索引。

HBase的读写操作

Meta table中包含了集群中所有 regions 的位置信息。Zookeeper 保存了这个 Meta table 的位置。
当 HBase 第一次读或者写操作到来时：

• 客户端从 Zookeeper 那里获取是哪一台 Region Server (ROOT Region)负责管理 Meta table。
• 客户端会查询那台管理 Meta table 的 Region Server，进而获知是哪一台 Region Server 负责管理本次数据请求所需要的 rowkey。客户端会缓存这个信息，以及 Meta table 的位置信息本身。
• 然后客户端回去访问那台 Region Server，获取数据。
• 对于以后的的读请求，客户端从可以缓存中直接获取 Meta table 的位置信息（在哪一台 Region Server 上），以及之前访问过的 rowkey 的位置信息（哪一台 Region Server 上）
• 如果因为 Region 被迁移了导致缓存失效。这时客户端会重复上面的步骤，重新获取相关位置信息并更新缓存。

HBase读操作

HBase读操作

HBase读操作比写操作更复杂，速度也更慢，原因有两个：

• 其一是因为整个HBase存储引擎基于LSM-Like树实现，因此一次范围查询可能会涉及多个分片、多块缓存甚至多个数据存储文件；
• 其二是因为HBase中更新操作以及删除操作实现都很简单，更新操作并没有更新原有数据，而是使用时间戳属性实现了多版本。删除操作也并没有真正删除原有数据，只是插入了一条打上”deleted”标签的数据，而真正的数据删除发生在系统异步执行Major_Compact的时候。很显然，这种实现套路大大简化了数据更新、删除流程，但是对于数据读取来说却意味着套上了层层枷锁，读取过程需要根据版本进行过滤，同时对已经标记删除的数据也要进行过滤。

为什么HBase客户端配置文件中没有配置RegionServer的地址信息？

• 客户端只需要配置zookeeper的访问地址以及根目录，就可以进行正常的读写请求。不需要配置集群的RegionServer地址列表。
• 客户端会将hbase:meta元数据表缓存在本地，因此上述步骤中向Zookeeper请求元数据的存在只会发生在第一次请求时候，之后所有请求都直接从缓存中加载元数据。如果集群发生某些变化导致hbase:meta元数据更改，客户端再根据本地元数据表请求的时候就会发生异常，此时客户端需要重新加载一份最新的元数据表到本地。

读流程：

• 在经过上述第一次读写操作以后，client获取到了目标RegionServer信息，并与其通信
• RegionServer接受到请求后，分别在 Block Cache（读缓存）， MemStore 和 **Store File（HFile）**中查询目标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本（time stamp）或者不同的类型（Put/Delete）
• 将从文件中查询到的数据块（Block， HFile 数据存储单元，默认大小为 64KB）缓存到Block Cache。并将结果返回给客户端

Scanner体系

RegionServer接收到客户端的get/scan请求之后，先后做了两件事情：构建scanner体系（实际上就是做一些scan前的准备工作），在此体系基础上一行一行检索。

scanner体系的核心在于三层scanner：RegionScanner、StoreScanner以及StoreFileScanner。三者是层级的关系，一个RegionScanner由多个StoreScanner构成，一张表由多个列族组成，就有多少个StoreScanner负责该列族的数据扫描。一个StoreScanner又是由多个StoreFileScanner组成。每个Store的数据由内存中的MemStore和磁盘上的StoreFile文件组成，相对应的，StoreScanner对象会雇佣一个MemStoreScanner和N个StoreFileScanner来进行实际的数据读取，每个StoreFile文件对应一个StoreFileScanner，注意：StoreFileScanner和MemstoreScanner是整个scan的最终执行者。

• RegionScanner会根据列族构建StoreScanner，有多少列族就构建多少StoreScanner，用于负责该列族的数据检索
• **构建StoreFileScanner：**每个StoreScanner会为当前该Store中每个HFile构造一个StoreFileScanner，用于实际执行对应文件的检索。同时会为对应Memstore构造一个MemstoreScanner，用于执行该Store中Memstore的数据检索。
• 过滤淘汰StoreFileScanner：根据Time Range以及RowKey Range对StoreFileScanner以及MemstoreScanner进行过滤，淘汰肯定不存在待检索结果的Scanner。
• **Seek rowkey：**所有StoreFileScanner开始做准备工作，在负责的HFile中定位到满足条件的起始Row。

Seek rowkey包含下列三部：

1. 定位Block Offset：在Blockcache中读取该HFile的索引树结构，根据索引树检索对应RowKey所在的Block Offset和Block Size
2. **Load Block：**根据BlockOffset首先在BlockCache中查找Data Block，如果不在缓存，再在HFile中加载
3. Seek Key：在Data Block内部通过二分查找的方式定位具体的RowKey

• StoreFileScanner合并构建最小堆：将该Store中所有StoreFileScanner和MemstoreScanner合并形成一个heap（最小堆），所谓heap是一个优先级队列，队列中元素是所有scanner，排序规则按照scanner seek到的keyvalue大小由小到大进行排序。

HBase中的KeyValue结构？
HBase中KeyValue并不是简单的KV数据对，而是一个具有复杂元素的结构体，其中Key由RowKey，ColumnFamily，Qualifier ，TimeStamp，KeyType等多部分组成，Value是一个简单的二进制数据。Key中元素KeyType表示该KeyValue的类型，取值分别为Put/Delete/Delete Column/Delete Family等。KeyValue可以表示为如下图所示：
KeyValue结构为什么要这样设计？
这个就得从HBase所支持的数据操作说起了，HBase支持四种主要的数据操作，分别是Get/Scan/Put/Delete，其中Get和Scan代表数据查询，Put操作代表数据插入或更新（如果Put的RowKey不存在则为插入操作、否则为更新操作），特别需要注意的是HBase中更新操作并不是直接覆盖修改原数据，而是生成新的数据，新数据和原数据具有不同的版本（时间戳）；Delete操作执行数据删除，和数据更新操作相同，HBase执行数据删除并不会马上将数据从数据库中永久删除，而只是生成一条删除记录，最后在系统执行文件合并的时候再统一删除。HBase中更新删除操作并不直接操作原数据，而是生成一个新纪录，那问题来了，如何知道一条记录到底是插入操作还是更新操作亦或是删除操作呢？这正是KeyType和Timestamp的用武之地。上文中提到KeyType取值为分别为Put/Delete/Delete Column/Delete Family四种，如果KeyType取值为Put，表示该条记录为插入或者更新操作，而无论是插入或者更新，**都可以使用版本号（Timestamp）对记录进行选择；**如果KeyType为Delete，表示该条记录为整行删除操作；相应的KeyType为Delete Column和Delete Family分别表示删除某行某列以及某行某列族操作；

• 不同KeyValue之间如何进行大小比较？

HBase设定Key大小首先比较RowKey，RowKey越小Key就越小；RowKey如果相同就看CF，CF越小Key越小；CF如果相同看Qualifier，Qualifier越小Key越小；Qualifier如果相同再看Timestamp，Timestamp越大表示时间越新，对应的Key越小。如果Timestamp还相同，就看KeyType，KeyType按照DeleteFamily -> DeleteColumn -> Delete -> Put 顺序依次对应的Key越来越大。

• 对于一行数据的查询，又可以分解为多个列族的查询，比如RowKey=row1的一行数据查询，首先查询列族1上该行的数据集合，再查询列族2里该行的数据集合。

• HBase是列族式存储，HBase扫描本质上是一个一个的随即读，不能做到像HDFS(Parquet)这样的顺序扫描。

HBase写操作

HBase默认适用于写多读少的应用，正是依赖于它相当出色的写入性能：一个100台RS的集群可以轻松地支撑每天10T的写入量。

写流程：

• 在经过上述第一次读写操作以后，client获取到了目标RegionServer信息，并与其通信。
• 服务器端RegionServer接收到客户端的写入请求后，首先会反序列化为Put对象，然后执行各种检查操作，比如检查region是否是只读、memstore大小是否超过blockingMemstoreSize等。检查完成之后，就会执行如下核心操作：
• 获取行锁、Region更新共享锁： HBase中使用行锁保证对同一行数据的更新都是互斥操作，用以保证更新的原子性，要么更新成功，要么失败。
• 开始写事务：获取write number，用于实现MVCC，实现数据的非锁定读，在保证读写一致性的前提下提高读取性能。
• 写缓存memstore： HBase中每列族都会对应一个store，用来存储该列数据。每个store都会有个写缓存memstore，用于缓存写入数据。HBase并不会直接将数据落盘，而是先写入缓存，等缓存满足一定大小之后再一起落盘。
• Append HLog： HBase使用WAL机制保证数据可靠性，即**首先写日志再写缓存，即使发生宕机，也可以通过恢复HLog还原出原始数据。**该步骤就是将数据构造为WALEdit对象，然后顺序写入HLog中，此时不需要执行sync操作。
• 释放行锁以及共享锁 结束写事务
• **flush memstore：**当写缓存满64M之后，会启动flush线程将数据刷新到硬盘。

WAL机制

WAL(Write-Ahead Logging)是一种高效的日志算法，几乎是所有非内存数据库提升写性能的不二法门，**基本原理是在数据写入之前首先顺序写入日志，然后再写入缓存，等到缓存写满之后统一落盘。之所以能够提升写性能，是因为WAL将一次随机写转化为了一次顺序写加一次内存写。**提升写性能的同时，**WAL可以保证数据的可靠性，即在任何情况下数据不丢失。**假如一次写入完成之后发生了宕机，即使所有缓存中的数据丢失，也可以通过恢复日志还原出丢失的数据。

WAL持久化等级
HBase中可以通过设置WAL的持久化等级决定是否开启WAL机制、以及HLog的落盘方式。WAL的持久化等级分为如下四个等级：

1. SKIP_WAL：只写缓存，不写HLog日志。这种方式因为只写内存，因此可以极大的提升写入性能，但是数据有丢失的风险。在实际应用过程中并不建议设置此等级，除非确认不要求数据的可靠性。

2. ASYNC_WAL：异步将数据写入HLog日志中。

3. SYNC_WAL：同步将数据写入日志文件中，需要注意的是数据只是被写入文件系统中，并没有真正落盘。

4. FSYNC_WAL：同步将数据写入日志文件并强制落盘。最严格的日志写入等级，可以保证数据不会丢失，但是性能相对比较差。

5. USER_DEFAULT：默认如果用户没有指定持久化等级，HBase使用SYNC_WAL等级持久化数据。

HLog数据结构
HBase中，WAL的实现类为HLog，每个Region Server拥有一个HLog日志，所有region的写入都是写到同一个HLog。下图表示同一个Region Server中的3个 region 共享一个HLog。当数据写入时，是将数据对<HLogKey,WALEdit>按照顺序追加到HLog中，以获取最好的写入性能。

WAL写入模型

HLog的写入可以分为三个阶段，首先将数据对<HLogKey,WALEdit>写入本地缓存，然后再将本地缓存写入文件系统，最后执行sync操作同步到磁盘。

HBase Region Flush

MemStore 中累积了足够多的的数据后，整个有序数据集就会被写入一个新的 HFile 文件到 HDFS 上。HBase 为每个 Column Family 都创建一个 HFile，里面存储了具体的 Cell，也即 KeyValue 数据。随着时间推移，HFile 会不断产生，因为 KeyValue 会不断地从 MemStore 中被刷写到硬盘上。

注意这也是为什么 HBase 要限制 Column Family 数量的一个原因。每个 Column Family 都有一个 MemStore；如果一个 MemStore 满了，所有的 MemStore 都会被刷写到硬盘。同时它也会记录最后写入的数据的最大序列号（sequence number），这样系统就能知道目前为止哪些数据已经被持久化了。最大序列号是一个 meta 信息，被存储在每个 HFile 中，来表示持久化进行到哪条数据了，应该从哪里继续。当 region 启动时，这些序列号会被读取，取其中最大的一个，作为基础序列号，后面的新的数据更新就会在该值的基础上递增产生新的序列号。每次 HBase 数据更新都会绑定一个新的自增序列号。而每个 HFile 则会存储它所保存的数据的最大序列号，这个元信息非常重要，它相当于一个 commit point，告诉我们在这个序列号之前的数据已经被持久化到硬盘了。它不仅在 region 启动时会被用到，在故障恢复时，也能告诉我们应该从 WAL 的什么位置开始回放数据的历史更新记录。

相关参数:

• 当某个 memstroe 的大小达到了 hbase.hregion.memstore.flush.size（默认值 128M） ，其所在 region 的所有 memstore 都会刷写。
• 当 memstore 的大小达到了**hbase.hregion.memstore.flush.size（默认值128M）*hbase.hregion.memstore.block.multiplier（默认值 4）**时，会阻止继续往该 memstore 写数据。
• 当 region server 中 memstore 的总大小达到*java_heapsize*hbase.regionserver.global.memstore.size（默认值 0.4）hbase.regionserver.global.memstore.size.lower.limit（默认值 0.95） ，region 会按照其所有 memstore 的大小顺序（由大到小）依次进行刷写。直到 region server中所有 memstore 的总大小减小到上述值以下。
• 当 region server 中 memstore 的总大小达到**java_heapsize*hbase.regionserver.global.memstore.size（默认值 0.4）**时，会阻止继续往所有的 memstore 写数据。
• 到达自动刷写的时间，也会触发 memstore flush。自动刷新的时间间隔由该属性进行配置 hbase.regionserver.optionalcacheflushinterval（默认 1 小时）

StoreFile Compaction

由于memstore每次刷写都会生成一个新的HFile，且同一个字段的不同版本（timestamp）和不同类型（Put/Delete）有可能会分布在不同的 HFile 中，因此查询时需要遍历所有的 HFile。为了减少 HFile 的个数，以及清理掉过期和删除的数据，会进行 StoreFile Compaction。 Compaction会从一个region的一个store中选择一些hfile文件进行合并。合并说来原理很简单，先从这些待合并的数据文件中读出KeyValues，再按照由小到大排列后写入一个新的文件中。之后，这个新生成的文件就会取代之前待合并的所有文件对外提供服务。

Compaction 分为两种，分别是 Minor Compaction 和 Major Compaction。

• Minor Compaction会将临近的若干个较小的 HFile 合并成一个较大的 HFile，但不会清理过期和删除的数据。
• Major Compaction 会将一个 Store 下的所有的 HFile 合并成一个大 HFile，这个过程还会清理三类无意义数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。另外，一般情况下，Major Compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发Major Compaction功能，改为手动在业务低峰期触发。
  

Compaction作用 | 副作用

随着hfile文件数不断增多，一次查询就可能会需要越来越多的IO操作，延迟必然会越来越大，随着数据写入不断增加，文件数不断增多，读取延时也在不断变大。而执行compaction会使得文件数基本稳定，进而IO Seek次数会比较稳定，延迟就会稳定在一定范围。
为了换取后续查询的低延迟，除了短时间的读放大之外，Compaction对写入也会有很大的影响。我们首先假设一个现象：当写请求非常多，导致不断生成HFile，但**compact的速度远远跟不上HFile生成的速度，这样就会使HFile的数量会越来越多，导致读性能急剧下降。**为了避免这种情况，在HFile的数量过多的时候会限制写请求的速度：**在每次执行MemStore flush的操作前，如果HStore的HFile数超过hbase.hstore.blockingStoreFiles （默认7），则会阻塞flush操作hbase.hstore.blockingWaitTime时间，在这段时间内，如果compact操作使得HStore文件数下降到回这个值，则停止阻塞。**另外阻塞超过时间后，也会恢复执行flush操作。这样做就可以有效地控制大量写请求的速度，但同时这也是影响写请求速度的主要原因之一。

• 可见，Compaction会使得数据读取延迟一直比较平稳，但付出的代价是大量的读延迟毛刺和一定的写阻塞。

Compaction流程

整个Compaction始于特定的触发条件，比如flush操作、周期性地Compaction检查操作等。一旦触发，HBase会将该Compaction交由一个独立的线程处理，该线程首先会从对应store中选择合适的hfile文件进行合并，这一步是整个Compaction的核心，选取文件需要遵循很多条件，比如文件数不能太多、不能太少、文件大小不能太大等等，最理想的情况是，选取那些承载IO负载重、文件小的文件集，实际实现中，HBase提供了多个文件选取算法：RatioBasedCompactionPolicy、ExploringCompactionPolicy和StripeCompactionPolicy等，用户也可以通过特定接口实现自己的Compaction算法；选出待合并的文件后，HBase会根据这些hfile文件总大小挑选对应的线程池处理，最后对这些文件执行具体的合并操作。

触发时机：
HBase中可以触发compaction的因素有很多，最常见的因素有这么三种：Memstore Flush、后台线程周期性检查、手动触发。

1. Memstore Flush: 应该说compaction操作的源头就来自flush操作，memstore flush会产生HFile文件，文件越来越多就需要compact。因此在每次执行完Flush操作之后，都会对当前Store中的文件数进行判断，一旦文件数＃ > ，就会触发compaction。需要说明的是，compaction都是以Store为单位进行的，而在Flush触发条件下，整个Region的所有Store都会执行compact，所以会在短时间内执行多次compaction。
2. 后台线程周期性检查：后台线程CompactionChecker定期触发检查是否需要执行compaction，检查周期为：hbase.server.thread.wakefrequency*hbase.server.compactchecker.interval.multiplier。和flush不同的是，该线程优先检查文件数＃是否大于，一旦大于就会触发compaction。如果不满足，它会接着检查是否满足major compaction条件，简单来说，如果当前store中hfile的最早更新时间早于某个值mcTime，就会触发major compaction，HBase预想通过这种机制定期删除过期数据。上文mcTime是一个浮动值，浮动区间默认为［7-70.2，7+70.2］，其中7为hbase.hregion.majorcompaction，0.2为hbase.hregion.majorcompaction.jitter，可见默认在7天左右就会执行一次major compaction。用户如果想禁用major compaction，只需要将参数hbase.hregion.majorcompaction设为0
3. 手动触发：一般来讲，手动触发compaction通常是为了执行major compaction，原因有三，其一是因为很多业务担心自动major compaction影响读写性能，因此会选择低峰期手动触发；其二也有可能是用户在执行完alter操作之后希望立刻生效，执行手动触发major compaction；其三是HBase管理员发现硬盘容量不够的情况下手动触发major compaction删除大量过期数据；无论哪种触发动机，一旦手动触发，HBase会不做很多自动化检查，直接执行合并。

选择合适HFile合并：

选择合适的文件进行合并是整个compaction的核心，因为合并文件的大小以及其当前承载的IO数直接决定了compaction的效果。最理想的情况是，这些文件承载了大量IO请求但是大小很小，这样compaction本身不会消耗太多IO，而且合并完成之后对读的性能会有显著提升。在进行compaction时，会排出不满足条件的部分文件：

1. 排除当前正在执行compact的文件及其比这些文件更新的所有文件（SequenceId更大）
2. 排除某些过大的单个文件，如果文件大小大于hbase.hzstore.compaction.max.size（默认Long最大值），则被排除，否则会产生大量IO消耗
   经过排除的文件称为候选文件。HBase接下来会再判断是否满足major compaction条件，如果满足，就会选择全部文件进行合并。判断条件有下面三条，只要满足其中一条就会执行major compaction：
3. 用户强制执行major compaction
4. 长时间没有进行compact（CompactionChecker的判断条件2）且候选文件数小于hbase.hstore.compaction.max（默认10）
5. Store中含有Reference文件 Reference文件是split region产生的临时文件，只是简单的引用文件，一般必须在compact过程中删除

如果不满足major compaction条件，就必然为minor compaction，HBase主要有两种minor策略：RatioBasedCompactionPolicy和ExploringCompactionPolicy，下面分别进行介绍：
RatioBasedCompactionPolicy
从老到新逐一扫描所有候选文件，满足其中条件之一便停止扫描：
（1）当前文件大小 < 比它更新的所有文件大小总和 * ratio，其中ratio是一个可变的比例，在高峰期时ratio为1.2，非高峰期为5，也就是非高峰期允许compact更大的文件。那什么时候是高峰期，什么时候是非高峰期呢？用户可以配置参数hbase.offpeak.start.hour和hbase.offpeak.end.hour来设置高峰期

（2）当前所剩候选文件数 <= hbase.store.compaction.min（默认为3）

停止扫描后，待合并文件就选择出来了，即为当前扫描文件+比它更新的所有文件

ExploringCompactionPolicy

该策略思路基本和RatioBasedCompactionPolicy相同，不同的是，Ratio策略在找到一个合适的文件集合之后就停止扫描了，而Exploring策略会记录下所有合适的文件集合，并在这些文件集合中寻找最优解。最优解可以理解为：待合并文件数最多或者待合并文件数相同的情况下文件大小较小，这样有利于减少compaction带来的IO消耗

挑选合适的线程池

HBase实现中有一个专门的线程CompactSplitThead负责接收compact请求以及split请求，而且为了能够独立处理这些请求，这个线程内部构造了多个线程池：largeCompactions、smallCompactions以及splits等，其中splits线程池负责处理所有的split请求，largeCompactions和smallCompaction负责处理所有的compaction请求，其中前者用来处理大规模compaction，后者处理小规模compaction。这里需要明白三点：

1. 上述设计目的是为了能够将请求独立处理，提供系统的处理性能。

2. 哪些compaction应该分配给largeCompactions处理，哪些应该分配给smallCompactions处理？是不是Major Compaction就应该交给largeCompactions线程池处理？不对。这里有个分配原则：待compact的文件总大小如果大于值throttlePoint（可以通过参数hbase.regionserver.thread.compaction.throttle配置，默认为2.5G），分配给largeCompactions处理，否则分配给smallCompactions处理。

3. largeCompactions线程池和smallCompactions线程池默认都只有一个线程，用户可以通过参数hbase.regionserver.thread.compaction.large和hbase.regionserver.thread.compaction.small进行配置

执行HFile文件合并

主要分为如下几步：

1. 分别读出待合并hfile文件的KV，并顺序写到位于./tmp目录下的临时文件中

2. 将临时文件移动到对应region的数据目录

3. 将compaction的输入文件路径和输出文件路径封装为KV写入WAL日志，并打上compaction标记，最后强制执行sync

4. 将对应region数据目录下的compaction输入文件全部删除
   上述四个步骤看起来简单，但实际是很严谨的，具有很强的容错性和完美的幂等性：

5. 如果RS在步骤2之前发生异常，本次compaction会被认为失败，如果继续进行同样的compaction，上次异常对接下来的compaction不会有任何影响，也不会对读写有任何影响。唯一的影响就是多了一份多余的数据。

6. 如果RS在步骤2之后、步骤3之前发生异常，同样的，仅仅会多一份冗余数据。

7. 如果在步骤3之后、步骤4之前发生异常，RS在重新打开region之后首先会从WAL中看到标有compaction的日志，因为此时输入文件和输出文件已经持久化到HDFS，因此只需要根据WAL移除掉compaction输入文件即可

Region Split

切分策略

默认情况下，每个 Table 起初只有一个 Region，随着数据的不断写入， Region 会自动进行拆分。刚拆分时，两个子 Region 都位于当前的 Region Server，但处于负载均衡的考虑，HMaster 有可能会将某个 Region 转移给其他的 Region Server。
在最新稳定版中，HBase已经有多达6种切分触发策略。当然，每种触发策略都有各自的适用场景，用户可以根据业务在表级别选择不同的切分触发策略。常见的切分策略如下：

• ConstantSizeRegionSplitPolicy：0.94版本前默认切分策略。这是最容易理解但也最容易产生误解的切分策略，从字面意思来看，当region大小大于某个阈值（hbase.hregion.max.filesize）之后就会触发切分，实际上并不是这样，真正实现中这个阈值是对于某个store来说的，即一个region中最大store的大小大于设置阈值之后才会触发切分。**ConstantSizeRegionSplitPolicy相对来来说最容易想到，但是在生产线上这种切分策略却有相当大的弊端：**切分策略对于大表和小表没有明显的区分。阈值（hbase.hregion.max.filesize）设置较大对大表比较友好，但是小表就有可能不会触发分裂，极端情况下可能就1个，这对业务来说并不是什么好事。如果设置较小则对小表友好，但一个大表就会在整个集群产生大量的region，这对于集群的管理、资源使用、failover来说都不是一件好事。

• IncreasingToUpperBoundRegionSplitPolicy: 0.94版本~2.0版本默认切分策略。这种切分策略微微有些复杂，总体来看和ConstantSizeRegionSplitPolicy思路相同，一个region中最大store大小大于设置阈值就会触发切分。但是这个**阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值，而是会在一定条件下不断调整，调整规则和region所属表在当前regionserver上的region个数有关系 ：*当 1 个 region 中 的 某 个 Store 下 最大StoreFile 的 大 小 超 过Min(R^2"hbase.hregion.memstore.flush.size",hbase.hregion.max.filesize")， 该 Region 就会进行拆分，其中 R 为当前表在Region Server 中属于该 Region的个数,当然阈值并不会无限增大，最大值为用户设置的MaxRegionFileSize。这种切分策略很好的弥补了ConstantSizeRegionSplitPolicy的短板，能够自适应大表和小表。而且在大集群条件下对于很多大表来说表现很优秀，但并不完美，这种策略下很多小表会在大集群中产生大量小region，分散在整个集群中。而且在发生region迁移时也可能会触发region分裂。

• SteppingSplitPolicy: 2.0版本默认切分策略。这种切分策略的切分阈值又发生了变化，相比IncreasingToUpperBoundRegionSplitPolicy简单了一些，依然和待分裂region所属表在当前regionserver上的region个数有关系，如果region个数等于1，切分阈值为flush size * 2，否则为MaxRegionFileSize。这种切分策略对于大集群中的大表、小表会比IncreasingToUpperBoundRegionSplitPolicy更加友好，小表不会再产生大量的小region，而是适可而止。

• 另外，还有一些其他分裂策略，比如使用DisableSplitPolicy:可以禁止region发生分裂；而KeyPrefixRegionSplitPolicy，DelimitedKeyPrefixRegionSplitPolicy对于切分策略依然依据默认切分策略，但对于切分点有自己的看法，比如KeyPrefixRegionSplitPolicy要求必须让相同的PrefixKey待在一个region中。

寻找SplitPoint

region切分策略会触发region切分，切分开始之后的第一件事是寻找切分点－splitpoint。所有默认切分策略，无论是ConstantSizeRegionSplitPolicy、IncreasingToUpperBoundRegionSplitPolicy或是SteppingSplitPolicy，对于切分点的定义都是一致的。当然，用户手动执行切分时是可以指定切分点进行切分的，这里并不讨论这种情况。

那切分点是如何定位的呢？整个region中最大store中的最大文件中最中心的一个block的首个rowkey。 另外，HBase还规定，如果定位到的rowkey是整个文件的首个rowkey或者最后一个rowkey的话，就认为没有切分点。

Region核心切分流程

Region的生命状态：

HBase将整个切分过程包装成了一个事务，意图能够保证切分事务的原子性。整个分裂事务过程分为三个阶段：prepare – execute – (rollback) ，操作模版如下：

• prepare阶段：在内存中初始化两个子region，具体是生成两个HRegionInfo对象，包含tableName、regionName、startkey、endkey等。同时会生成一个transaction journal，这个对象用来记录切分的进展，具体见rollback阶段。
• execute阶段：切分的核心操作。
  

1. regionserver更改ZK节点 /region-in-transition 中该region的状态为SPLITING。
2. master通过watch节点/region-in-transition检测到region状态改变，并修改内存中region的状态，在master页面RIT模块就可以看到region执行split的状态信息。
3. 在父存储目录下新建临时文件夹.split保存split后的daughter region信息。
4. 关闭parent region： parent region关闭数据写入并触发flush操作，将写入region的数据全部持久化到磁盘。此后短时间内客户端落在父region上的请求都会抛出异常NotServingRegionException。
5. 核心分裂步骤：在.split文件夹下新建两个子文件夹，称之为daughter A、daughter B，并在文件夹中生成reference文件，分别指向父region中对应文件。这个步骤是所有步骤中最核心的一个环节，生成reference文件。
   其中reference文件名为d24415c4fb44427b8f698143e5c4d9dc.00bb6239169411e4d0ecb6ddfdbacf66，根据日志可以看到，切分的父region是00bb6239169411e4d0ecb6ddfdbacf66，对应的切分文件是d24415c4fb44427b8f698143e5c4d9dc
   

还需要关注reference文件的文件内容，reference文件是一个引用文件（并非linux链接文件），文件内容很显然不是用户数据。文件内容其实非常简单，主要有两部分构成：其一是切分点splitkey，其二是一个boolean类型的变量（true或者false），true表示该reference文件引用的是父文件的上半部分（top），而false表示引用的是下半部分 （bottom）。

6. 父region分裂为两个子region后，将daughter A、daughter B拷贝到HBase根目录下，形成两个新的region。
7. parent region通知修改 hbase.meta 表后下线，不再提供服务。下线后parent region在meta表中的信息并不会马上删除，而是标注split列、offline列为true，并记录两个子region。
8. 开启daughter A、daughter B两个子region。通知修改 hbase.meta 表，正式对外提供服务。

• rollback阶段：如果execute阶段出现异常，则执行rollback操作。为了实现回滚，整个切分过程被分为很多子阶段，回滚程序会根据当前进展到哪个子阶段清理对应的垃圾数据。

Region切分事务性保证
整个region切分是一个比较复杂的过程，涉及到父region中HFile文件的切分、两个子region的生成、系统meta元数据的更改等很多子步骤，因此必须保证整个切分过程的事务性，即要么切分完全成功，要么切分完全未开始，在任何情况下也不能出现切分只完成一半的情况。
为了实现事务性，**hbase设计了使用状态机（见SplitTransaction类）的方式保存切分过程中的每个子步骤状态，这样一旦出现异常，系统可以根据当前所处的状态决定是否回滚，以及如何回滚。**遗憾的是，**目前实现中这些中间状态都只存储在内存中，因此一旦在切分过程中出现regionserver宕机的情况，有可能会出现切分处于中间状态的情况，也就是RIT状态。**这种情况下需要使用hbck工具进行具体查看并分析解决方案。**在2.0版本之后，HBase实现了新的分布式事务框架Procedure V2(**HBASE-12439)， 新框架将会使用HLog存储这种单机事务（DDL操作、Split操作、Move操作等）的中间状态，因此可以保证即使在事务执行过程中参与者发生了宕机，依然可以使用HLog作为协调者对事务进行回滚操作或者重试提交，大大减少甚至杜绝RIT现象。 **

Region切分对其他模块的影响

通过region切分流程的了解，我们知道整个region切分过程并没有涉及数据的移动，所以切分成本本身并不是很高，可以很快完成。切分后子region的文件实际没有任何用户数据，文件中存储的仅是一些元数据信息－切分点rowkey等，那通过引用文件如何查找数据呢？子region的数据实际在什么时候完成真正迁移？数据迁移完成之后父region什么时候会被删掉？

1. 通过reference文件如何查找数据？

这里就会看到reference文件名、文件内容的实际意义啦。整个流程如下图所示：

2. 父region的数据什么时候会迁移到子region目录？

答案是子region发生major_compaction时。我们知道compaction的执行实际上是将store中所有小文件一个KV一个KV从小到大读出来之后再顺序写入一个大文件，完成之后再将小文件删掉，因此compaction本身就需要读取并写入大量数据。**子region执行major_compaction后会将父目录中属于该子region的所有数据读出来并写入子region目录数据文件中。**可见将数据迁移放到compaction这个阶段来做，是一件顺便的事。

3. 父region什么时候会被删除？

实际上HMaster会启动一个线程定期遍历检查所有处于splitting状态的父region，确定检查父region是否可以被清理。检测线程首先会在meta表中揪出所有split列为true的region，并加载出其分裂后生成的两个子region（meta表中splitA列和splitB列），只需要检查此两个子region是否还存在引用文件，如果都不存在引用文件就可以认为该父region对应的文件可以被删除。现在再来看看上文中父目录在meta表中的信息，就大概可以理解为什么会存储这些信息了：

4. 分裂以后的Region是否均在一个RegionServer？
   Splitting 一开始是发生在同一台 region server 上的，但是出于负载均衡的原因，HMaster 可能会将新的 regions 迁移给其它 region server，这会导致那些 region server 需要访问离它比较远的 HDFS 数据，直到 major compaction 的到来，它会将那些远方的数据重新移回到离 region server 节点附近的地方。

HBase HFile

HBase数据备份和故障恢复

所有的读写都发生在 HDFS 的主 DataNode 节点上。 HDFS 会自动备份 WAL 和 HFile 的文件 blocks。**HBase 依赖于 HDFS 来保证数据完整安全。**当数据被写入 HDFS 时，一份会写入本地节点，另外两个备份会被写入其它节点。WAL 和 HFiles 都会持久化到硬盘并备份。
当某个 Region Server 发生 crash 时，它所管理的 region 就无法被访问了，直到 crash 被检测到，然后故障恢复完成，这些 region 才能恢复访问。Zookeeper 依靠心跳检测发现节点故障，然后 HMaster 会收到 region server 故障的通知。当 HMaster 发现某个 region server 故障，HMaster 会将这个 region server 所管理的 regions 分配给其它健康的 region servers。
为了恢复故障的 region server 的 MemStore 中还未被持久化到 HFile 的数据，HMaster 会将 WAL 分割成几个文件，将它们保存在新的 region server 上。每个 region server 然后回放各自拿到的 WAL 碎片中的数据，来为它所分配到的新 region 建立 MemStore。WAL 包含了一系列的修改操作，每个修改都表示一个 put 或者 delete 操作。这些修改按照时间顺序依次写入，持久化时它们被依次写入 WAL 文件的尾部。

当数据仍然在 MemStore 还未被持久化到 HFile 怎么办呢？WAL 文件会被回放。操作的方法是读取 WAL 文件，排序并添加所有的修改记录到 MemStore，最后 MemStore 会被刷写到 HFile。

Rowkey 设计

https://www.cnblogs.com/qingyunzong/p/8696962.html

1. 列簇设计

追求的原则是：在合理范围内能尽量少的减少列簇就尽量减少列簇。
最优设计是：将所有相关性很强的 key-value 都放在同一个列簇下，这样既能做到查询效率 最高，也能保持尽可能少的访问不同的磁盘文件。

2. RowKey 设计

HBase 中，表会被划分为 1…n 个 Region，被托管在 RegionServer 中。Region两个重要的属性：StartKey 与 EndKey 表示这个 Region 维护的 rowKey 范围，当我们要读/写数据时，如 果 rowKey 落在某个 start-end key 范围内，那么就会定位到目标 region 并且读/写到相关的数据
Rowkey 设计三原则

• rowkey 长度原则

Rowkey 是一个二进制码流，Rowkey 的长度被很多开发者建议说设计在 10~100 个字节，不过建议是越短越好，不要超过 16 个字节。
原因如下：

1. 数据的持久化文件 HFile 中是按照 KeyValue 存储的，如果 Rowkey 过长比如 100 个字 节，1000 万列数据光 Rowkey 就要占用 100*1000 万=10 亿个字节，将近 1G 数据，这会极大影响 HFile 的存储效率；
2. MemStore 将缓存部分数据到内存，如果 Rowkey 字段过长内存的有效利用率会降低， 系统将无法缓存更多的数据，这会降低检索
3. 目前操作系统是都是 64 位系统，内存 8 字节对齐。控制在 16 个字节，8 字节的整数倍利用操作系统的最佳特性。

• rowkey 散列原则

如果 Rowkey 是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将 Rowkey 的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个 Regionserver 实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有 新数据都在一个 RegionServer 上堆积的热点现象，这样在做数据检索的时候负载将会集中 在个别 RegionServer，降低查询效率。

• rowkey 唯一原则

必须在设计上保证其唯一性。rowkey 是按照字典顺序排序存储的，因此，设计 rowkey 的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问 的数据放到一块。

数据热点问题

HBase 中的行是按照 rowkey 的字典顺序排序的，这种设计优化了 scan 操作，可以将相 关的行以及会被一起读取的行存取在临近位置，便于 scan。然而糟糕的 rowkey 设计是热点 的源头。 热点发生在大量的 client 直接访问集群的一个或极少数个节点（访问可能是读， 写或者其他操作）。大量访问会使热点 region 所在的单个机器超出自身承受能力，引起性能 下降甚至 region 不可用，这也会影响同一个 RegionServer 上的其他 region，由于主机无法服 务其他 region 的请求。 设计良好的数据访问模式以使集群被充分，均衡的利用。 为了避免写热点，设计 rowkey 使得不同行在同一个 region，但是在更多数据情况下，数据 应该被写入集群的多个 region，而不是一个。

防止数据热点的有效措施

1. 加盐
   这里所说的加盐不是密码学中的加盐，而是在 rowkey 的前面增加随机数，具体就是给 rowkey 分配一个随机前缀以使得它和之前的 rowkey 的开头不同。分配的前缀种类数量应该 和你想使用数据分散到不同的 region 的数量一致。加盐之后的 rowkey 就会根据随机生成的 前缀分散到各个 region 上，以避免热点。
2. 哈希
   哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群，但是读却是 可以预测的。使用确定的哈希可以让客户端重构完整的 rowkey，可以使用 get 操作准确获取 某一个行数据
3. 反转
   第三种防止热点的方法是反转固定长度或者数字格式的 rowkey。这样可以使得 rowkey 中经常改变的部分（最没有意义的部分）放在前面。这样可以有效的随机 rowkey，但是牺 牲了 rowkey 的有序性。
   反转 rowkey 的例子以手机号为 rowkey，可以将手机号反转后的字符串作为 rowkey，这 样的就避免了以手机号那样比较固定开头导致热点问题
4. 时间戳反转
   　　一个常见的数据处理问题是快速获取数据的最近版本，使用反转的时间戳作为 rowkey 的一部分对这个问题十分有用，可以用 Long.Max_Value - timestamp 追加到 key 的末尾，例 如 [key][reverse_timestamp] , [key] 的最新值可以通过 scan [key]获得[key]的第一条记录，因 为 HBase 中 rowkey 是有序的，第一条记录是最后录入的数据。比如需要保存一个用户的操 作记录，按照操作时间倒序排序，在设计 rowkey 的时候，可以这样设计 [userId 反转][Long.Max_Value - timestamp]，在查询用户的所有操作记录数据的时候，直接指 定 反 转 后 的 userId ， startRow 是 [userId 反 转 ][000000000000],stopRow 是 [userId 反 转][Long.Max_Value - timestamp]
   如果需要查询某段时间的操作记录，startRow 是[user 反转][Long.Max_Value - 起始时间]， stopRow 是[userId 反转][Long.Max_Value - 结束时间]

HBase性能优化

1. 垃圾回收优化

垃圾回收时，Master通常不会产生问题，因为Master没有处理任何过重的负载，并且实际的数据服务并不经过它。
对写入负载过大的情况来说，memstore在不同时期创建并释放着各种不同大小的对象。因为数据是被存储在内存缓冲区内的，它们会被保留直到超过用户配置的最小刷写大小，用户可以在配置文件中使用hbase.hregion.memstore.flush.size来设置region 的 memstore刷写大小，此外在定义表时也可以对不同的表单独指定表的这个属性。
一旦memstore大于这个值，数据就会被刷写到磁盘，并创建一个新的存储文件。因为写入磁盘的数据是由客户端在不同时间写入的，那么它们占据的Java堆空间很可能是不连续的,所以 Java 虚拟机的堆内存会出现孔洞(内存碎片)。
数据会根据自身在内存中停留的时间被保存在Java堆中分代结构的不同位置:被快速插入且被刷写到磁盘的数据，通常会被分配到被称为年轻代( young generation)或新生代(new generation）的堆中。这种空间可以被迅速地回收，并且对内存管理没有影响。另一方面，**如果数据在内存中停留的时间过长，例如，向一个列族中插入数据的速度较慢时，对应的数据就很可能被提升为了老生代 (old generation）或终生代( tenured generation)。**年轻代和老生代的不同点在于空间大小:年轻代占用的空间在128 MB 到512 MB之间，而老生代几乎占用了所有可以占用的堆空间，通常是好几 GB的内存。

用户可以通过向hbase-env.sh配置文件中添加HBASE_OPTS或者HBASE_REGIONSERVER_OPT变量来设置垃圾回收相关选项。后者仅仅影响region服务器进程（例如，相对于master )，并且也是推荐的修改方式。

指定新生代的空间可以通过以下两种方式完成:

-XX:MaxNewSize=128m -XX: NewSize=128m

使用128 MB是一个好的开端，用户可以通过对JVM各指标的进一步观察来确认年轻代的大小是否满足需求。
注意，**默认值对于多数region服务器面对的负载来说都太小，所以它必须增大。**如果不这样做的话，用户可能会发现服务器CPU的使用量会急剧上升，因为从年轻代中收集对象会消耗大量的CPU。
为了重复使用由于刷写数据到磁盘而产生（或由其他对象的创建和释放产生）的堆孔洞，新老生代都需要由JRE来维护。如果在某个时间内，**应用程序需要的堆大小不适合这些碎片空间，那么JRE需要压缩堆内存碎片。**这个操作包含了其他隐式操作，例如，将长时间存在的对象从年轻代提升并转移到老生代。如果这个操作失败，用户将会在垃圾回收日志中看到提升失败的信息。
重写并整理堆中不同代的过程被称之为垃圾回收，并且用户可以通过不同的JRE参数来指定不同的垃圾回收实现策略，推荐的值是:

-xx:+UseParNewGc and -xx:+UseConcMarksweepGc

第一个选项是设置年轻代使用Parallel New Collector垃圾回收策略:这将停止运行Java进程而去清空年轻代堆。与老生代相比，新生代很小，所以这个过程花费时间很短，通常只需要几百毫秒时间。
以上回收策略对于较小的年轻代来说是可以接受的，**但是并不适合老生代:在最差的情况下，以上回收策略会造成数秒钟甚至几分钟的进程停顿。一旦停顿时间达到了ZooKeeper 会话超时限制,这个服务器将被master认为已经崩溃并且随后会被抛弃。一旦region服务器从垃圾回收暂停中恢复之后，它会获知自己已经被抛弃，然后它会自行关闭。
这种情况可以通过使用并行标记回收器(Concurrent Mark-Sweep Collector，CMS）**来缓解，这种回收策略通过上述例子中后面的选项启用。不同之处在于其工作时试图在不停止运行Java进程的情况下尽可能异步并行地完成工作。这种策略将增加CPU的负载，但是却可以避免重写老生代堆碎片时的停顿–除非发生提升失败，这种错误会迫使垃圾回收暂停运行JAVA进程并进行内存整理。
CMS有一个额外的开关选项,这个选项控制着将在什么时候开始并发标记和清扫检查。这个值可以通过以下选项来设置:

-XX:CMSInitiatingoccupancyFraction=70

这个值是一个百分比，当老年代达到70%时，触发CMS垃圾回收，并指定后台线程何时启用，用户需要设定这个值以防止另一种情况发生，即并发模式失败。当后台进程为回收空间而标记和清理堆内存时，可能会发生堆空间不足（如回收碎片时)。在这种情况下，JRE必须暂停运行Java进程并且通过释放对象来强制释放空间，或者将停留时间较长的对象转移到老生代。
将初始占用百分比设置为70%意味着其比region服务器设置的60%的堆占用率要大一点，60%的堆占用率由默认的20%块缓存和40%的memstore组成。这样的配置允许在堆空间被占用完之前就开始并行垃圾回收过程，同时这样的配置也不会使回收工作开始得太早而使回收过程频繁运行。

把上面的设置放在一起，用户可以使用下列内容作为最开始的配置:

export HBASE_REGIONSERVER_OPTS="-Xmx8g -Xms8g -Xmn128m -XX:+UseParNewGC \-XX;+UseConcMarkSweepGC -XX:CMSInitiatingoccupancyFraction=70 -verbose:gc \-XX:+PrintGCDetails -XX:+PrintGCTimestamps \
-xloggc:$HBASE_HOME/logs/gc-$ (hostname)-hbase.log"

2. 配置优化

1. 增加处理线程
   hbase.regionserver.handler.count属性定义了响应外部用户访问数据表请求的线程数。默认值10有些偏小，这是为了防止用户在客户端高并发使用较大写缓冲区的情况下使服务器端过载。将这个值设得小是为了优化单次请求涉及的数据量达到MB级别（如较大的写入和使用大缓存的扫描）场景，而当单次请求开销较小时（如get、较小的put、increment和 delete等操作）可以将工作线程数设得高一些。
   **如果客户端的请求开销较小时,用户将该属性设置为最大的客户端数目会比较安全。典型的例子就是，当一个集群服务于一个网站时，写请求一般不会使用缓存，同时大多数的请求都是读取数据。
   将这个值设置得高也有可能产生问题，因为并发的写请求涉及到的数据累加起来之后很可能会对一个region 服务器的内存造成巨大压力，这甚至会导致服务器端抛出OutofMemoryError 异常。 region服务器运行在可用内存过低的情况下时，其将会使JVM的垃圾回收器运行地更加频繁,**同时随之发生的停顿也会更加明显(原因是内存都被写请求占用，无论垃圾回收器怎么尝试，它们都不能被回收)。一段时间后，集群的吞吐量就会受到影响，因为命中这个服务器的请求都会变慢，这样会使其内存紧张的情况更加严重。

2. 增加region大小
   hbase.hregion.max.filesize 更大的region可以减少集群总的region数目。一般来说，管理较少的region可以让集群的运行更平稳。一个region变热点后，用户可以手动拆分大的region 并将负载分散到集群中。在默认情况下，region的大小是256MB。用户可以配置1GB或者更大的region。注意，该参数的大小要仔细评估，大的region也意味着在高负载的情况下合并的停顿时间更长。

3. 调整memstore 限制
   内存存储占用的堆大小用hbase.regionserver.global.memstore.upperLimit属性来配置，默认值为40%(设置为0.4)。此外，hbase.regionserver.global.memstore.lowerLimit属性（设置为35%或者0.35）用于控制当服务器清空memstore之后剩余的大小。将上限和下限设置得接近一些以避免过度刷写。
   **当用户主要在处理读请求时，其可以考虑同时减少memstore 的上下限来增加块缓存的空间。**另一方面，当用户在处理许多写请求时应该检查日志文件，如果刷写的数据量都很小，如5 MB，用户就有必要通过增加内存存储的限制来降低过度IO操作。

4. 减少最大日志文件限制
   设置hbase.regionserver.maxlogs属性使得用户能够控制基于磁盘的WAL文件数目，进而控制刷写频率。该参数的默认值是32，对于写压力比较大的应用来说这个值有点高。降低这个值会强迫服务器更频繁地将数据刷写到磁盘上，这样已经刷写到磁盘上的数据所对应的日志就可以被丢弃了。

标签：总结,文件,region,切分,compaction,HBase,数据
来源： https://blog.csdn.net/Zeroowt/article/details/116714384