hbase2

一、原理

1、详细架构图

a、zk：client端的DML请求经过zk，zk路由到具体的reginServer
b、master：client端的DDL请求经过master，如：创建表、nameSpace
c、hlog：相当于mysql的redo-log
d、store：存储的是列族
e、mem-store：会定时将内容flush到storefile
f、storeFile：存储hbase真正的内容

2、写流程

注：读比写慢

a、client先访问zk，获取hbase:meta表位于哪个regionServer
b、访问对应的RegionServer，获取hbase:meta表，从hbase:meta中获取目标table属于哪个RegionServer
c、client与目标RegionServer进行通信
d、将数据写到hlog--->写到内存mem-store--->hlog同步(注：如果同步失败，内存中的数据也会回滚)
e、hbase向客户端发送ack
f、等达到MemStore的刷写时机后，将数据刷写到HFile。

3、flush流程

触发flush的操作：
a、当某个store中的memstore的大小达到了hbase.hregion.memstore.flush.size（默认值128M）,其所在region的所有memstore都会flush到Hdfs。并会阻止client往memstore写数据。
b、当region server中memstore的总大小达到heap的0.38会flush到Hdfs。达到heap的0.4的时候，会组织所有client向memstore写数据。
c、默认1小时memstore向Hdfs写一次

4、读流程

a、client先访问zk，获取hbase:meta表位于哪个regionServer
b、访问对应的RegionServer，获取hbase:meta表，从hbase:meta中获取目标table属于哪个RegionServer
c、client与目标RegionServer进行通信
d、分别在BlockCache（读缓存），MemStore和StoreFile（HFile）中查询目标数据，并将查到的所有数据进行合并（要根据数据的timeStamp进行合并）。所以读比写慢。
e、将从文件中查询到的数据块缓存到Block Cache。将合并后的最终结果返回给客户端。

5、合并流程

a、由于memstore每次刷写都会生成一个新的HFile，且同一个字段的不同版本（timestamp）和不同类型（Put/Delete）有可能会分布在不同的HFile中，因此查询时需要遍历所有的HFile。为了减少HFile 的个数，以及清理掉过期和删除的数据，会进行StoreFile Compaction。
b、Compaction分为两种，分别是MinorCompaction和MajorCompaction。MinorCompaction会将临近的若干个较小的HFile合并成一个较大的HFile，但不会清理过期和删除的数据。MajorCompaction会将一个Store下的所有的HFile合并成一个大HFile，并且会清理掉过期和删除的数据。

 

6、数据删除的时机
a、过期数据的删除
flush：两条数据在同一个memstore中，timestamp小的会被删除
MajorCompaction：过期的数据会被删除
b、delete标识的数据
flush：被delete标识的数据不会被删除
MajorCompaction：被delete标识的数据会被删除

 

7、region split

存在分割后的region存储的数据数量有大有小，数据分部不均的情况

 

8、hbase的delete-api

 

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

2、预分区
a、解决数据倾斜的问题
b、分区规则：分区按照数据量和机器规模(一台机器最好有2~3个分区)
c、startKey < rowKey < endKey【分区键】

3、rowKey设计
a、原则：散列行、唯一性、长度(70~100)
b、举例：电话记录存储
13112341234 ->13823452345 2019-12-12 12:12:21 777
a、有多少个分区？300
b、分区键的创建：000|~298|
c、将一个人同一个月份的电话放在同一个分区中，rowKey设计：xxx_13112341234_2019-12-12 12:12:12   xxx=（手机号+201912）%299
d、查询一个人二月份的通话记录：scan操作的startRow=xxx_13112341234_2019-02，scan操作的endRow=xxx_13112341234_2019-03  xxx=（手机号+201902）%299

4、内存优化
因为GC过程持续太久会导致RegionServer处于长期不可用状态

5、基础优化
a、优化HBase客户端缓存，可以减少RPC调用次数，但是会消耗更多内存
b、优化数据的写入效率，增加数据压缩

三、预分区

1、hbase为何要预分区？
增加数据读写效率
负载均衡，防止数据倾斜，使得读写请求均衡分布在每台RegionServer的Regions上。
方便集群容灾调度region
优化Map数量

2、分区车策略
a、KeyPoint（固定前缀）
      如果对rowkey加前缀盐处理，可以选择固定前缀预分区，分区规则形如 "10|", "20|", "30|", "40|", "50|", "60|", "70|", "80|", "90|"
      为什么后面会跟着一个"|"？  HBase中的行是按照Rowkey的ASCII字典顺序进行全局排序的。是因为在ASCII码中，"|"的值是124，大于所有的数字和字母等符号，当然也可以用“~”（ASCII-126）。

b、HexStringSplit （ASCII码预拆分策略：适用于十六进制字符的为前缀的rowkey）
    只需要传入一个要拆分的Region的数量，HexStringSplit会将数据从"00000000"到"FFFFFFFF"之间的数据长度按照n等分之后算出每一段的起始rowkey和结束rowkey，以此作为拆分点。

c、UniformSplit （字节码预拆分策略：适用于随机字节数组的rowkey）
      只需要传入一个要拆分的Region的数量
      与ASCII码预拆分不同的是，起始结束不是String而是byte[]
      起始rowkey是ArrayUtils.EMPTY_BYTE_ARRAY
      结束rowkey是new byte[]{xFF,xFF,xFF,xFF,xFF,xFF,xFF,xFF}
      长度n等分，然后取每一段的起始和结束作为拆分点