Java-Hbase介绍-CSDN博客

1.1. 概念 

base 是分布式、面向列的开源数据库其实准确的说是面向列族。HDFS 为 Hbase 提供可靠的
底层数据存储服务MapReduce 为 Hbase 提供高性能的计算能力Zookeeper 为 Hbase 提供
稳定服务和 Failover 机制因此我们说 Hbase 是一个通过大量廉价的机器解决海量数据的高速存
储和读取的分布式数据库解决方案。

1.2. 列式存储

列方式所带来的重要好处之一就是由于查询中的选择规则是通过列来定义的因此整个数据库
是自动索引化的。

 这里的列式存储其实说的是列族存储Hbase 是根据列族来存储数据的。列族下面可以有非常多
的列列族在创建表的时候就必须指定。为了加深对 Hbase 列族的理解下面是一个简单的关系
型数据库的表和 Hbase 数据库的表

 1.3. Hbase 核心概念

1.3.1. Column Family 列族

Column Family 又叫列族Hbase 通过列族划分数据的存储列族下面可以包含任意多的列实
现灵活的数据存取。Hbase 表的创建的时候就必须指定列族。就像关系型数据库创建的时候必须
指定具体的列是一样的。Hbase的列族不是越多越好官方推荐的是列族最好小于或者等于3。我
们使用的场景一般是 1 个列族。

1.3.2. Rowkey Rowkey 查询Rowkey 范围扫描全表扫描

Rowkey 的概念和 mysql 中的主键是完全一样的Hbase 使用 Rowkey 来唯一的区分某一行的数
据。Hbase 只支持 3 中查询方式基于 Rowkey 的单行查询基于 Rowkey 的范围扫描全表扫
描。

1.3.3. Region 分区

RegionRegion 的概念和关系型数据库的分区或者分片差不多。Hbase 会将一个大表的数
据基于 Rowkey 的不同范围分配到不通的 Region 中每个 Region 负责一定范围的数据访问
和存储。这样即使是一张巨大的表由于被切割到不通的 region访问起来的时延也很低。

1.3.4. TimeStamp 多版本

TimeStamp 是实现 Hbase 多版本的关键。在 Hbase 中使用不同的 timestame 来标识相同
rowkey 行对应的不通版本的数据。在写入数据的时候如果用户没有指定对应的
timestampHbase 会自动添加一个 timestamptimestamp 和服务器时间保持一致。在
Hbase 中相同 rowkey 的数据按照 timestamp 倒序排列。默认查询的是最新的版本用户
可同指定 timestamp 的值来读取旧版本的数据。

1.4. Hbase 核心架构

Hbase 是由 Client、Zookeeper、Master、HRegionServer、HDFS 等几个组建组成。

 1.4.1. Client

Client 包含了访问 Hbase 的接口另外 Client 还维护了对应的 cache 来加速 Hbase 的
访问比如 cache 的.META.元数据的信息。

1.4.2. Zookeeper

Hbase 通过 Zookeeper 来做 master 的高可用、RegionServer 的监控、元数据的入口
以及集群配置的维护等工作。具体工作如下
1. 通过 Zoopkeeper 来保证集群中只有 1 个 master 在运行如果 master 异
常会通过竞争机制产生新的 master 提供服务
2. 通过 Zoopkeeper 来监控 RegionServer 的状态当 RegionSevrer 有异常的
时候通过回调的形式通知 Master RegionServer 上下限的信息
3. 通过 Zoopkeeper 存储元数据的统一入口地址。

1.4.3. Hmaster

 master 节点的主要职责如下
1. 为 RegionServer 分配 Region
2. 维护整个集群的负载均衡
3. 维护集群的元数据信息发现失效的 Region并将失效的 Region 分配到正常
RegionServer 上当 RegionSever 失效的时候协调对应 Hlog 的拆分

1.4.4. HregionServer

HregionServer 直接对接用户的读写请求是真正的“干活”的节点。它的功能概括如
下
1. 管理 master 为其分配的 Region

2. 处理来自客户端的读写请求
3. 负责和底层 HDFS 的交互存储数据到 HDFS
4. 负责 Region 变大以后的拆分
5. 负责 Storefile 的合并工作

1.4.5. Region 寻址方式通过 zookeeper .META

第 1 步Client 请求 ZK 获取.META.所在的 RegionServer 的地址。
第 2 步Client 请求.META.所在的 RegionServer 获取访问数据所在的 RegionServer 地
址client 会将.META.的相关信息 cache 下来以便下一次快速访问。
第 3 步Client 请求数据所在的 RegionServer获取所需要的数据。

 1.4.6. HDFS

HDFS 为 Hbase 提供最终的底层数据存储服务同时为 Hbase 提供高可用Hlog 存储在
HDFS的支持。

1.5. Hbase 的写逻辑

1.5.1. Hbase 的写入流程

 从上图可以看出氛围 3 步骤
获取 RegionServer
第 1 步Client 获取数据写入的 Region 所在的 RegionServer
请求写 Hlog
第 2 步请求写 Hlog, Hlog 存储在 HDFS当 RegionServer 出现异常需要使用 Hlog 来
恢复数据。
请求写 MemStore
第 3 步请求写 MemStore,只有当写 Hlog 和写 MemStore 都成功了才算请求写入完成。
MemStore 后续会逐渐刷到 HDFS 中。

1.5.2. MemStore 刷盘

为了提高 Hbase 的写入性能当写请求写入 MemStore 后不会立即刷盘。而是会等到一
定的时候进行刷盘的操作。具体是哪些场景会触发刷盘的操作呢总结成如下的几个场景

全局内存控制
1. 这个全局的参数是控制内存整体的使用情况当所有 memstore 占整个 heap 的最大比
例的时候会触发刷盘的操作。这个参数是
hbase.regionserver.global.memstore.upperLimit默认为整个 heap 内存的 40%。
但这并不意味着全局内存触发的刷盘操作会将所有的 MemStore 都进行输盘而是通过
另外一个参数 hbase.regionserver.global.memstore.lowerLimit 来控制默认是整个
heap 内存的 35%。当 flush 到所有 memstore 占整个 heap 内存的比率为 35%的时
候就停止刷盘。这么做主要是为了减少刷盘对业务带来的影响实现平滑系统负载的
目的。
MemStore 达到上限
2. 当 MemStore 的大小达到 hbase.hregion.memstore.flush.size 大小的时候会触发刷
盘默认 128M 大小
RegionServer 的 Hlog 数量达到上限
3. 前面说到 Hlog 为了保证 Hbase 数据的一致性那么如果 Hlog 太多的话会导致故障
恢复的时间太长因此 Hbase 会对 Hlog 的最大个数做限制。当达到 Hlog 的最大个数
的时候会强制刷盘。这个参数是 hase.regionserver.max.logs默认是 32 个。
手工触发
4. 可以通过 hbase shell 或者 java api 手工触发 flush 的操作。
关闭 RegionServer 触发
5. 在正常关闭 RegionServer 会触发刷盘的操作全部数据刷盘后就不需要再使用 Hlog 恢
复数据。
Region 使用 HLOG 恢复完数据后触发
6. 当 RegionServer 出现故障的时候其上面的 Region 会迁移到其他正常的
RegionServer 上在恢复完 Region 的数据后会触发刷盘当刷盘完成后才会提供给
业务访问。

1.6. HBase vs Cassandra