单独启动或停止 HMaster | HRegionServer 的进程、HBase架构图Plus 及 读写流程、BlockCache、HBase的特点、RowKey、列簇、时间戳、Cell、Region分裂策略、Compaction操作、通过Hive 整合 HBase

单独 启动 或 停止 HMaster、HRegionServer 的进程

hbase-daemon.sh start/stop master/regionserver

H -- 可以省略

HBase 架构图 Plus 及读写流程

BLockCache

BlockCache基于客户端对数据的访问频率,定义了三个不同的优先级,如下所示:

SINGLE:如果一个Block被第一次访问,则该Block被放在这一优先级队列中;

MULTI:如果一个Block被多次访问,则从single移到Multi中;

MEMORY:memory优先级由用户指定,一般不推荐,只用系统表才使用memory优先级;

HBase的特点

  1. 大:一个表可以有上亿行,上百万列。

  2. 面向列:面向列族(簇)的存储和权限控制,列(簇)独立检索。

  3. 稀疏:对于为空(NULL)的列,并不占用存储空间,因此,表可以设计的非常稀疏。

  4. 无模式(no Schema):每一行都有一个可以排序的主键和任意多的列,列可以根据需要动态增 加,同一张表中不同的行可以有截然不同的列。

  5. 数据多版本:每个单元中的数据可以有多个版本,默认情况下,版本号自动分配, 版本号就是单元格插入时的时间戳。

  6. 数据类型单一:HBase中的数据都是字节数组,没有类型。

RowKey

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

​ 访问 HBase table 中的行,只有三种方式:

  • 直接通过单个RowKey

    get

  • 指定RowKey的范围

    scan

  • 还可以指定跟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功能,改为手动在业务低峰期触发。

参考文档:https://cloud.tencent.com/developer/article/1488439

通过 Hive 整合 HBase

external -- 指定外部表
stored by 'org.apache.hadoop.hive.hbase.HBaseStorageHandler' -- 由 stored by 指定一个 由 HBase 提供的 专门处理 HBase 上面数据的 一个类
with serdeproperties -- with 后面加上一个属性 HBase 上面列的一个映射 "hbase.columns.mapping" ,这里的映射是按照位置顺序来映射的,并不是按照名字
tblproperties -- 这个属性指定了 HBase 中的表名
其实就是把 HBase 上的表 映射到 Hive 上去处理

create external table students_hbase
(
id string,
name string,
age string,
gender string, 
clazz string
)
stored by 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'
with serdeproperties ("hbase.columns.mapping" = "
:key,
info:name,
info:age,
info:gender,
info:clazz
")
tblproperties("hbase.table.name" = "default:stu");
posted @ 2022-02-28 20:35  赤兔胭脂小吕布  阅读(731)  评论(0编辑  收藏  举报