HBase笔记

最新推荐文章于 2023-03-01 10:12:55 发布

liangzai2048

最新推荐文章于 2023-03-01 10:12:55 发布

阅读量144

点赞数

分类专栏： HBase hadoop Hive 文章标签： hbase big data 大数据

原文链接：https://blog.csdn.net/Kayleigh520/article/details/122030683

版权

hadoop 同时被 3 个专栏收录

46 篇文章 13 订阅

订阅专栏

Hive

21 篇文章 4 订阅

订阅专栏

HBase

8 篇文章 1 订阅

订阅专栏

HBase笔记

文章目录

- HBase笔记

HBase的特点

大：一个表可以有上亿行，上百万列。
面向列：面向列族（簇）的存储和权限控制，列（簇）独立检索。
稀疏：对于为空（NULL）的列，并不占用存储空间，因此，表可以设计的非常稀疏。
无模式（no Schema）：每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。
数据多版本：每个单元中的数据可以有多个版本，默认情况下，版本号自动分配，版本号就是单元格插入时的时间戳。
数据类型单一：HBase中的数据都是字节数组，没有类型。

RowKey

与 NoSQL 数据库一样，Row Key 是用来检索记录的主键。

访问 HBase table 中的行，只有三种方式：

直接通过单个RowKey
指定RowKey的范围
还可以指定跟RowKey有关的正则表达式等方式去访问

最大长度是64KB，实际应用中长度一般为 10 ~ 100bytes

按照字典顺序存储的（1 11 111 1111 2 22 3 4 5…）

列簇

属于表的Schema的一部分，在建表的时候必须指定至少一个Columns Family

HBase中的列归属于某一个列簇

HBase在储存、权限控制、版本控制都是在列簇层面上进行

一个列簇对应一个store

时间戳

就是一直提到的版本的概念，每条数据插入的时候都会记录插入时间（时间戳，64位整型）

如果有多个版本，会按照时间戳的倒序（时间戳越大，表示数据越新）储存数据，在获取的时候，如果不指定版本，那么会默认最新一条的数据

如果设置了TTL（Time to Live），那么HBase将会根据TTL以及数据的时间戳去删除过期的数据

Cell

Cell 是由 {row key，column(=< family> + < label>)，version} 唯一确定的单元。

Cell 中的数据是没有类型的，全部是字节码形式存储。

Region的分裂策略

region中存储的是一张表的数据，当region中的数据条数过多的时候，会直接影响查询效率。当region过大的时候，region会被拆分为两个region，HMaster会将分裂的region分配到不同的regionserver上，这样可以让请求分散到不同的RegionServer上，已达到负载均衡 , 这也是Hbase的一个优点。

ConstantSizeRegionSplitPolicy

0.94版本前，HBase region的默认切分策略

当region中最大的store大小超过某个阈值(hbase.hregion.max.filesize=10G)之后就会触发切分，一个region等分为2个region。

但是在生产线上这种切分策略却有相当大的弊端（切分策略对于大表和小表没有明显的区分）：
- 阈值(hbase.hregion.max.filesize)设置较大对大表比较友好，但是小表就有可能不会触发分裂，极端情况下可能就1个，形成热点，这对业务来说并不是什么好事。
- 如果设置较小则对小表友好，但一个大表就会在整个集群产生大量的region，这对于集群的管理、资源使用、failover来说都不是一件好事。
IncreasingToUpperBoundRegionSplitPolicy

0.94版本~2.0版本默认切分策略

总体看和ConstantSizeRegionSplitPolicy思路相同，一个region中最大的store大小大于设置阈值就会触发切分。
但是这个阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值，而是会在一定条件下不断调整，调整规则和region所属表在当前regionserver上的region个数有关系.

region split阈值的计算公式是：
- 设regioncount：是region所属表在当前regionserver上的region的个数
- 阈值 = regioncount^3 * 128M * 2，当然阈值并不会无限增长，最大不超过MaxRegionFileSize（10G),当region中最大的store的大小达到该阈值的时候进行region split
例如：
- 第一次split阈值 = 1^3 * 256 = 256MB
- 第二次split阈值 = 2^3 * 256 = 2048MB
- 第三次split阈值 = 3^3 * 256 = 6912MB
- 第四次split阈值 = 4^3 * 256 = 16384MB > 10GB，因此取较小的值10GB
- 后面每次split的size都是10GB了
特点
- 相比ConstantSizeRegionSplitPolicy，可以自适应大表、小表；
- 在集群规模比较大的情况下，对大表的表现比较优秀
- 对小表不友好，小表可能产生大量的小region，分散在各regionserver上
- 小表达不到多次切分条件，导致每个split都很小，所以分散在各个regionServer上
SteppingSplitPolicy

2.0版本默认切分策略

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

根据rowKey的前缀对数据进行分区，这里是指定rowKey的前多少位作为前缀，比如rowKey都是16位的，指定前5位是前缀，那么前5位相同的rowKey在相同的region中。
DelimitedKeyPrefixRegionSplitPolicy

保证相同前缀的数据在同一个region中，例如rowKey的格式为：userid_eventtype_eventid，指定的delimiter为 _ ，则split的的时候会确保userid相同的数据在同一个region中。
按照分隔符进行切分，而KeyPrefixRegionSplitPolicy是按照指定位数切分。
BusyRegionSplitPolicy

按照一定的策略判断Region是不是Busy状态，如果是即进行切分

如果你的系统常常会出现热点Region，而你对性能有很高的追求，那么这种策略可能会比较适合你。它会通过拆分热点Region来缓解热点Region的压力，但是根据热点来拆分Region也会带来很多不确定性因素，因为你也不知道下一个被拆分的Region是哪个。
DisabledRegionSplitPolicy

不启用自动拆分, 需要指定手动拆分

Compaction操作

Minor Compaction：

指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次 Minor Compaction 的结果是更少并且更大的StoreFile。

Major Compaction：

指将所有的StoreFile合并成一个StoreFile，这个过程会清理三类没有意义的数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。另外，一般情况下，major compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发major compaction功能，改为手动在业务低峰期触发。