Hbase教程

目录

前言

1.Hbase数据模型及架构详细

1.1.Hbase概述

1.2.HBase 数据模型

1.3.HBase 架构设计

2.基本命令操作

3.DDL数据定义与操作

4.DML操作

5.Hbase使用场景

5.1.以实体为中心的数据

5.2.以事件为中心的数据

参考来源

---

前言

本文主要对学习Hbase过程中知识点的总结，单机版hbase环境的搭建可以访问本人另一篇博客https://blog.csdn.net/luchenghui1/article/details/105242530，该博文详细讲解了Dbeaver连接Mysql,Hive和Hbase的配置。希望本文能对学习Hbase的同学有所帮助。

1.Hbase数据模型及架构详细

1.1.Hbase概述

HBase是Hadoop的生态系统，是建立在Hadoop文件系统（HDFS）之上的分布式、面向列的数据库，通过利用Hadoop的文件系统提供容错能力。HBase常被用来存放一些结构简单，但数据量非常大的数据(通常在TB级别以上)，如历史订单记录，日志数据，监控Metris数据等等，HBase提供了简单的基于Key值的快速查询能力。

Hbase数据库简述

• HBase 是一个高可靠性、高性能、面向列、可伸缩、实时读写的分布式数据库
• HBase 是一个利用 HDFS 来存储数据、利用 MapReduce 来处理数据、利用 Zookeeper 作为其分布式协同服务
• HBase 主要用于存储非结构化和半结构化的松散数据—NoSql 数据库
• HBase 的数据读写是将数据作标记，删除数据时并不是将数据直接在磁盘中删除，读取的时候是看标记

 Oracle/MySQL数据表存贮视图

 

Hbase数据表存贮视图

Hbase表的行由看似”杂乱无章”的列组成，行与行之间也无须遵循一致的定义，而这种定义恰好符合半结构化数据或非结构化数据的特点。本文所要讲述的HBase，就属于该派系的一个典型代表。这些”杂乱无章”的列所构成的多行数据，被称之为一个”稀疏矩阵”，而上图中的每一个”黑块块”，在HBase中称之为一个KeyValue。

1.2.HBase 数据模型

HBase通过表格的模式存储数据，每个表格由列和行组成，其中，每个列又被划分为若干个列族（row family），请参考下面的图：

HBase 数据模型是稀疏结构的数据，逻辑数据模型如下图所示：

如上图所示，以关系型数据的思维会感觉这是一张表，但是在 HBase 中这种理解是错误的，在 HBase 中上面的表格显示的只是一行数据；其中各单元格标题描述如下所示
1 RowKey

（1）决定一行数据的唯一标识

（2） RowKey 是按照字典顺序排序的

（3）RowKey 最多只能存储64k的字节数据，RowKey 设计越短越好

（4）Column Family列族（CF1、CF2、CF3） & qualifier列：

HBase表中的每个列都归属于某个列族，列族必须作为表模式(schema) 定义的一部分预先给出。如create ‘test’, ‘info’；列名以列族作为前缀，每个“列族”都可以有多个列成员(column，每个列族中可以存放几千~上千万个列)；如 CF1:q1, CF2:qw,新的列族成员（列）可以随后按需、动态加入，Family下面可以有多个 Qualifier，所以可以简单的理解为，HBase中的列是二级列,也就是说 Family 是第一级列，Qualifier 是第二级列。两个是父子关系，权限控制、存储以及调优都是在列族层面进行的。HBase把同一列族里面的数据存储在同一目录下，由几个文件保存，目前为止 HBase 的列族能够很好处理最多不超过3个列族。

2 时间戳（Timestamp）

（1）在 HBase 每个 cell存储单元对同一份数据可以有多个版本，根据唯一的时间戳来区分每个版本之间的差异，不同版本的数据按照时间倒序排序，最新的数据版本排在最前面。

（2）时间戳的类型是 64 位整型，一般由HBase(在数据写入时自动)赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值，如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。
3 列族（Column Family）

（1）HBase表中的每个列都归属于某个列族，列族必须作为表模式(schema)定义的一部分预先给出。如 create ‘tb’, ‘f’,

列名以列族作为前缀，每个“列族”都可以有多个列(column)；如f:a, f:b, 新的列族成员（列）可以随后按需、动态加入；

（2）权限控制、存储以及调优都是在列族层面进行的；

（3）HBase把同一列族里面的数据存储在同一目录下，由几个文件保存。
4 单元格（cell-细胞）

（1）cell（一个细胞） 由行和列的坐标交叉决定;

（2）单元格是有版本的；

（3）cell的内容是未解析的字节数组；

（4）cell 是由 {row key， column( = +)， version} 唯一确定的单元;

（5）cell 中的数据是无类型数据，全部以字节码形式存储。

5 Region

区别于Cassandra/DynamoDB的”Hash分区”设计，HBase中采用了”Range分区”，将Key的完整区间切割成一个个的”Key Range” ，每一个”Key Range”称之为一个Region。也可以这么理解：将HBase中拥有数亿行的一个大表，横向切割成一个个”子表“，这一个个”子表“就是Region：

6 Column Family

如果将Region看成是一个表的横向切割，那么，一个Region中的数据列的纵向切割，称之为一个Column Family。每一个列，都必须归属于一个Column Family，这个归属关系是在写数据时指定的，而不是建表时预先定义。

7 KeyValue

KeyValue的设计不是源自Bigtable，而是要追溯至论文”The log-structured merge-tree(LSM-Tree)”。每一行中的每一列数据，都被包装成独立的拥有特定结构的KeyValue，KeyValue中包含了丰富的自我描述信息:

看的出来，KeyValue是支撑”稀疏矩阵”设计的一个关键点：一些Key相同的任意数量的独立KeyValue就可以构成一行数据。但这种设计带来的一个显而易见的缺点：每一个KeyValue所携带的自我描述信息，会带来显著的数据膨胀。

1.3.HBase 架构设计

通过上图我们可以得出Hbase中的每张表都按照一定的范围被分割成多个子表（HRegion），默认一个HRegion超过 256M 就要被分割成两个，由 HRegionServer管理，管理哪些HRegion由HMaster分配。 

现在我们来介绍一下HBase中的一些组成部件以及它们起到的作用：

• Client：包含访问HBase的接口，并维护cache来加快对HBase的访问。

• Zookeeper：HBase依赖Zookeeper，默认情况下HBase管理Zookeeper实例（启动或关闭Zookeeper），Master与RegionServers启动时会向Zookeeper注册。Zookeeper的作用如下：

        (1)保证任何时候，集群中只有一个master

        (2)存储所有Region的寻址入口

        (3)实时监控Region server的上线和下线信息。并实时通知给master

        (4)存储HBase的schema和table元数据

• HMaster

(1)为 RegionServer 分配 Region

(2)负责 RegionServer 的负载均衡

(3)发现失效的 Region， HMaster 会重新分配到其他正常的 HRegionServer 上

(4)管理用户对 table 的增删改操作

• HRegionServer：用来维护master分配给他的region，处理对这些region的io请求；负责切分正在运行过程中变的过大的region。

• HRegion：HBase表在行的方向上分隔为多个Region。Region是HBase中分布式存储和负载均衡的最小单元，即不同的region可以分别在不同的Region Server上，但同一个Region是不会拆分到多个server上。Region按大小分隔，每个表一般是只有一个region，当region的某个列族达到一个阈值（默认256M）时就会分成两个新的region。

• Region

      (1)HBase自动把表水平划分成多个区域(region)，每个 region 会保存一个表 里面某段连续的数据；每个表一开始只有一个region，随着数据不断插 入表，region不断增大，当增大到一个阀值的时候，region就会等分会 两个新的region（裂变）；
      (2)当table中的行不断增多，就会有越来越多的 region。这样一张完整的表被保存在多个Regionserver上。
      (3)当Table随着记录数不断增加而变大后，会逐渐分裂成多份 splits，成为 regions，一个 region 由[startkey,endkey)表示，不同的 region 会被 Master 分配给相应的 RegionServer 进行管理，split 流程如下：

 

 

• Memstore 与 storefile

HBase 的存储核心是由MemStore和StoreFile组成，MemStore 是Sorted Memory Buffer。用户写入数据的流程，如下所示：

        (1)一个region由多个 store 组成，一个store对应一个CF（列族）

        (2)store 包括位于内存中的memstore和位于磁盘的storefile写操作先写入 memstore，当memstore中的数据达到某个阈值，hregionserver会启动 flashcache进程写入storefile，每次写入形成单独的一个storefile

        (3)当 storefile 文件的数量增长到一定阈值后，系统会进行合并（minor、 major compaction），在合并过程中会进行版本合并和删除工作 （majar），形成更大的 storefile。

        (4)当一个region所有storefile的大小和超过一定阈值后，会把当前的region 分割为两个，并由hmaster分配到相应的regionserver服务器，实现负载均衡。

        (5)客户端检索数据，先在 memstore 找，找不到再找 storefile

        (6)HRegion 是 HBase 中分布式存储和负载均衡的最小单元。最小单元就表 示不同的 HRegion 可以分布在不同的HRegion server上。

• Store：每一个Region由一个或多个Store组成，至少是一个Store，HBase会把一起访问的数据放在一个Store里面，即为每个ColumnFamily建一个Store，如果有几个ColumnFamily，也就有几个Store。一个Store由一个memStore和0或者多个StoreFile组成。Store的大小被HBase用来判断是否需要切分Region。

• StoreFile：memStore内存中的数据写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。 

• HLog：HLog记录数据的所有变更，可以用来恢复文件，一旦region server 宕机，就可以从log中进行恢复。HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是 HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和 region名字外，同时还包括sequence number和timestamp，timestamp是” 写入时间”，sequence number的起始值为0，或者是最近一次存入文件系 统中sequence number。HLog SequeceFile的Value是HBase的KeyValue对象，即对应HFile中的 KeyValue

• HFile

  如图：StoreFile 以 HFile 格式保存在HDFS上，HFile 格式如下所示：

      (1)HFile文件不定长，长度固定的块只有两个：Trailer 和 FileInfo
      (2)Trailer中指针指向其他数据块的起始点
      (3)File Info中记录了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等
      (4)Data Index和Meta Index块记录了每个Data块和Meta块的起始点
      (5)Data Block是HBase I/O的基本单元，为了提高效率，HRegionServer中有基于LRU的Block Cache机制
      (6)每个Data块的大小可以在创建一个Table的时候通过参数指定，大号的Block有利于顺序Scan，小号Block利于随机查询
      (7)每个 Data 块除了开头的 Magic 以外就是一个个 KeyValue 对拼接而成, Magic 内容就是一些随机数字，目的是防止数据损坏
      (8)HFile里面的每个 KeyValue 对就是一个简单的 byte 数组。这个byte数组里面包含了很多项，并且有固定的结构。

      (9)KeyLength 和 ValueLength：两个固定的长度，分别代表 Key 和 Value 的长度
      (10)Key 部分：Row Length 是固定长度的数值，表示 RowKey 的长度，Row 就是 RowKey,Column Family Length 是固定长度的数值，表示 Family 的长度,接着就是 Column Family，再接着是 Qualifier，然后是两个固定长度的数值，表示 Time Stamp 和 Key Type（Put/Delete,Value 是纯粹的二进制数据

• LogFlusher：一个LogFlusher的类是用来调用HLog.optionalSync()的。

2.基本命令操作

• status: 提供HBase的状态，例如，服务器的数量。

• version: 提供正在使用HBase版本。

• table_help: 表引用命令提供帮助。

里面有一些常用命令操作提示例子

• whoami: 提供有关用户的信息。

3.DDL数据定义与操作

下面列举HBase Shell支持的可以在表中操作的命令。

• namespace:用于创建命名空间，类似于database作用，常用操作有alter_namespace, create_namespace, describe_namespace, drop_namespace, list_namespace, list_namespace_tables。详细操作如下：

• create: 用于创建一个表。

再namespace空间下创建一个test_table,列族名为cf

• list: 用于列出HBase的所有表。

• disable: 用于禁用表。

• is_disabled: 用于验证表是否被禁用。

• enable: 用于启用一个表。

• is_enabled: 用于验证表是否已启用。

• describe: 用于提供了一个表的描述。

• alter: 用于改变一个表。

#增加列族
alter 'test_namespace:test_table','cf1'


#删除列族cf1,HBase 表至少要包含一个列族，因此当表中只有一个列族时，无法将其删除
alter 'test_namespace:test_table','delete'=>'cf1'
%或
alter 'test_namespace:test_table', { NAME => 'cf1', METHOD => 'delete' }

 

• exists: 用于验证表是否存在。

• drop: 用于从HBase中删除表。

• drop_all: 用于丢弃在命令中给出匹配“regex”的表。

4.DML操作

• put: 用于把指定列在指定的行中单元格的值在一个特定的表。

• get: 用于取行或单元格的内容。

• delete:用于删除表中的单元格值。

• deleteall: 用于删除给定行的所有单元格。

• scan: 用于扫描并返回表数据。

• count: 用于计数并返回表中的行的数目。

• truncate: 用于禁用、删除和重新创建一个指定的表。

• Java client API: 在此之前所有上述命令，Java提供了一个客户端API来实现DML功能，CRUD（创建检索更新删除）操作更多的是通过编程，在org.apache.hadoop.hbase.client包下。 在此包HTable 的 Put和Get是重要的类。

5.Hbase使用场景

HBase的数据模型比较简单，数据按照RowKey排序存放，适合HBase存储的数据，可以简单总结如下：

5.1.以实体为中心的数据

实体可以包括但不限于如下几种：

• 自然人／账户／手机号／车辆相关数据
• 用户画像数据（含标签类数据）
• 图数据（关系类数据）

    描述这些实体的，可以有基础属性信息、实体关系(图数据)、所发生的事件(如交易记录、车辆轨迹点)等等。

5.2.以事件为中心的数据

• 监控数据
• 时序数据
• 实时位置类数据
• 消息/日志类数据

上面所描述的这些数据，有的是结构化数据，有的是半结构化或非结构化数据。HBase的“稀疏矩阵”设计，使其应对非结构化数据存储时能够得心应手，但在我们的实际用户场景中，结构化数据存储依然占据了比较重的比例。由于HBase仅提供了基于RowKey的单维度索引能力，在应对一些具体的场景时，依然还需要基于HBase之上构建一些专业的能力，如：

• OpenTSDB 时序数据存储，提供基于Metrics+时间+标签的一些组合维度查询与聚合能力
• GeoMesa 时空数据存储，提供基于时间+空间范围的索引能力
• JanusGraph 图数据存储，提供基于属性、关系的图索引能力

HBase擅长于存储结构简单的海量数据但索引能力有限，而Oracle等传统关系型数据库(RDBMS)能够提供丰富的查询能力，但却疲于应对TB级别的海量数据存储，HBase对传统的RDBMS并不是取代关系，而是一种补充。

参考来源

https://blog.csdn.net/weixin_43129750/article/details/103147579

https://www.cnblogs.com/raphael5200/p/5229164.html