学习笔记HBase概念原理适用场景学习笔记

Posted 2022-07-15 棉花糖灬

一、HBase简介

HBase是 Google BigTable 的开源实现。它是一种分布式、可扩展、稀疏数据、准实时查询、支持海量数据存储的NoSQL数据库。

逻辑上，HBase的数据模型同关系型数据库很类似，数据存储在一张表中，有行有列。

1. 概念

• RowKey：行键，RowKey 是用来检索记录的主键。行键是有序存储的，因此为了提升查询效率可以把要同时读取的数据的行键设置的比较接近。访问 HBase Table 中的行，只有三种方式：

  • 通过单个 RowKey 访问

  • 通过 RowKey 的 Range（正则）

  • 全表扫描

• ColumnFamily：列族，必须在使用表之前定义，权限控制的最小单元。每个 ColumnFamily 都是物理上的一棵 LSM-Tree

• ColumnQualifier：列限定符

• Column：列，HBase中每个列都是由列族和列限定符进行限定

• Store：最小的存储单元，一个 Store 对应 HBase 表中的一个列族

• Region：域，类似于关系型数据库中表的概念。BigTable中称为Tablet，Region是数据分布与负载均衡的基本单元。Region由一个或者多个Store组成，每个 Store 保存一个 ColumnFamily

• Row：HBase中每行数据由一个RowKey和多个Column组成，数据按 RowKey 的字典序存储，查询数据时只能根据 RowKey 进行检索

• Cell：单元格，由 RowKey, ColumnFamily, ColumnQualifier, TimeStamp 唯一确定的单元，Cell中的数据没有类型的，都是以字节码形式存储

• TimeStamp：时间戳，每个 Cell 都保存着同一份数据的多个版本。版本通过时间戳来标识。不同版本的数据按照时间倒序排序，最新的数据版本排在最前面

从底层物理存储结构来看，HBase更像是一个多维 SortedMap：

table = map<row_key, map<column_family, map<column, map<version, value>>>> ;

2. 逻辑结构

高表是行数多，宽表是列数多，当行比较多时按Region进行切分，当列比较多时按Column Family切分，从而让表变得比较小。图中的Store是真正存储时的单元，Region可以理解为表的分片。

HBase表由行和列组成，每个行由行键RowKey标识，列划分为若干列族，一个列族中可以包含任意多个列，同一个列族里面的数据存储在一个文件中。当这个文件达到一定大小后，会进行分裂形成多个Region。一行可能包含多个列族，一个列族有多个列，对某一行而言，某列族文件中只存储了这一行键在列族中有值的那些列（列族可能有上百个列），没有不会存储（不存null）。

3. 物理结构

当在t4时间Put（插入）row_key1的phone数据时，原来t3的数据并不会马上被覆盖。当查询row_key1的phone时会返回时间戳最大的（最新的）t4那一个数据。删除时 Type 为 Delete。

二、HBase进阶

1. 架构原理

Hbase 是由 Client、Zookeeper、Master、HRegionServer、HDFS 等几个组件组成，HBase依赖于ZooKeeper和HDFS。

(1) ZooKeeper

• Master 的高可用，通过 ZoopKeeper 来保证集群中只有 1 个 Master 在运行，如果 Master 异常，会通过竞争机制产生新的 Master 提供服务。
• RegionServer 的监控，通过 ZoopKeeper 来监控 RegionServer 的状态，当 RegionSevrer 有异常的时候，通过回调的形式通知 Master RegionServer 上下线的信息。

(2) Master

• 表的创建、删除和修改
• 分配Regions到每个RegionServer
• 监控每个RegionServer的状态
• 负责Region server的负载均衡

(3) RegionServer

• 数据的增删改查
• 对Region进行合并和拆分

(4) HDFS

为 HBase 提供最终的底层数据存储服务，同时为HBase 提供高可用（HLog 存储在HDFS）的支持，具体功能概括如下：提供元数据和表数据的底层分布式存储服务，保证的高可靠和高可用性 （数据多副本）

(5) MemStore

内存缓存，达到一定缓存大小或者时间节点触发一次 Flush，文件系统中生成新的 HFile，每次 Flush 的最小单位是 Region。每个 ColumnFamily 维护一个 MemStore。

(6) Write-Ahead Logs（WAL，Hlog）

预写入日志，用来容灾。数据写入时会写写入到到预写入日志，再写入到磁盘。这样当系统发生故障时，就可以利用该日志文件重建。

(7) Region

HBase表的分片，HBase 表会根据 RowKey 值被切分成不同的 Region 存储在 RegionServer中，在一个 RegionServer 中可以有多个不同的 Region。同一个行键的 Region 不会被拆分到多个 Region 服务器上。 一个HBase表被划分成多个Region，开始只有一个Region，后台不断分裂。

(8) Meta表

描述HBase表的表，元数据表。一张从Region 到 RegionServer 的映射表。

(9) Store

HFile 存储在 Store 中，一个 Store 对应 HBase 表中的一个列族。

(10) HFile

这是在磁盘上保存原始数据的实际的物理文件，是实际的存储文件。StoreFile 是以 HFile的形式存储在 HDFS 的。

2. 写数据流程

• Client 先从 Meta Cache 中读取 Meta 表所在的 RegionServer 信息；
• 如果 Meta Cache 中没有，则向 ZooKeeper 请求 Meta 表所在的 RegionServer 信息，并将该信息写入 Meta Cache；
• 去对应的 RegionServer 读取 Meta 表；
• 根据 NameSpace、表名、 RowKey、ColumnFamily 和 Column 在 Meta 表查找 Region 所在的 RegionServer 信息；
• 将数据写入到 WAL，用来做容灾；
• 先将数据写入到 MemStore；
• 数据再从 MemStore（内存）刷写到 StoreFile（磁盘）。

3. 读数据流程

• Client 先从 Meta Cache 中读取 Meta 表所在的 RegionServer 信息；
• 如果 Meta Cache 中没有，则向 ZooKeeper 请求 Meta 表所在的 RegionServer 信息，并将该信息写入 Meta Cache；
• 去对应的 RegionServer 读取 Meta 表；
• 根据 NameSpace、表名、 RowKey、ColumnFamily 和 Column 在 Meta 表查找 Region 所在的 RegionServer 信息；
• 先从 MemStore 读取数据，若没有再从 StoreFile 中读取数据，根据数据的时间戳来确定所要的数据；
• 如果是从 StoreFile 里面读取的数据，还会写入 BlockCache 做缓存。

4. Compact流程

由于MemStore每次刷写都会生成一个新的HFile，且同一个字段的不同版本（TimeStamp）和不同类型（Put/Delete）有可能会分布在不同的HFile中，因此查询时需要遍历所有的HFile。为减少HFile的个数，以及清理过期和删除的数据，会进行 StoreFile Compaction。

Compaction分为Minor Compaction和Majar Compaction两种，前者会将临近的若干个较小的HFIle合并成一个较大的HFile，但不会清理过期和删掉的数据。后者会将一个Store下的所有的HFile合并成一个大的HFile，并且会清理过期和删除的数据。

5. Split流程

默认情况下，每个Table起初只有一个Region，随着数据的不断写入，Region会自动进行拆分。刚拆分时，两个Regiion都位于当前的RegionServer，但出于负载聚恒的考虑，Master有可能会将某个Region转移给其他的RegionServer。

Region Split的实际：

• 当1个Region中的某个Store下的StoreFile总和大小超过设定值时，该Region会进行拆分（0.94版本之前）
• 当1个Region中的某个Store下的StoreFile总和大小超过 Min(R^2 * 内存刷写大小, StoreFile文件最大值) 时，该Region会进行拆分。其中R为当前RegionServer中属于该Table的个数（0.94版本之后）

三、HBase优化

1. 高可用

自带高可用。中HBase中Master负责监控RegionServer的生命周期，均衡RegionServer的负载。如果Master挂了，那么整个HBase将陷入不健康的状态，并且此时的工作状态并不会维持太久。

2. 预分区

每个Region维护着StartRow和EndRow两个分区键，如果加入的数据符合某个Region维护的RowKey范围，则该数据交给这个Region维护。按照这个原则，我们可以将数据所要投放的分区提前大致规划好，以提高HBase的性能。

3. RowKey设计原则

设计RowKey的主要目的是让数据均匀的分布于所有的Region中，在一定程度上防止数据倾斜。

RowKey的设计应该满足：

• 散列性：提高数据均衡分布在每个RegionServer实现负载均衡的几率，避免产生所有数据都在一个RegionServer上堆积的热点现象
• 唯一性：必须在设计上保证其唯一性
• 长度原则：RowKey是一个二进制码流，可以是任意字符串，最大长度为64KB，由于RowKey的长度会影响存储空间，建议越短越好，建议控制在16字节内

四、使用场景

跟ES相比，HBase更适合于数据存储场景，但HBase的搜索功能的多样性不如ES。本处参考了：https://blog.csdn.net/u011598442/article/details/89891926

1、数据量规模非常庞大

单表数据量超过千万或者十亿百亿的时候，并且伴有较高并发，可以考虑使用HBase。这主要是充分利用分布式存储系统的优势，如果数据量比较小，单个节点就能有效存储的话则其他节点的资源就会存在浪费。

2、要求是实时的点查询

HBase是一个Key-Value数据库，默认对Rowkey即行键做了索引优化，所以即使数据量非常庞大，根据行键的查询效率依然会很高，这使得HBase非常适合根据行键做单条记录的查询。值得说明的是，允许根据行键的一部分做范围查询。

3、能够容忍NoSQL短板

如果业务场景是需要事务支持、复杂的关联查询等，不建议使用HBase。

4、数据分析需求并不多

虽然说HBase是一个面向列的数据库，但它有别于真正的列式存储系统比如Parquet、Kudu等，再加上自身存储架构的设计，使得HBase并不擅长做数据分析，或者说数据分析是HBase的弱项，所以如果主要的业务需求就是为了做数据分析，比如做报表，那么不建议直接使用HBase。