分布式数据库HBase

皮皮大卫

于 2020-09-02 13:39:14 发布

阅读量885

点赞数 1

分类专栏：大数据文章标签： hadoop hbase

本文链接：https://blog.youkuaiyun.com/wu_l_v/article/details/108356500

版权

大数据专栏收录该内容

2 篇文章

订阅专栏

1、HBase是什么？

HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库，是谷歌BigTable的开源实现，主要用来存储非结构化和半结构化的松散数据。HBase的目标是处理非常庞大的表，可以通过水平扩展的方式，利用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表。Hadoop安装以后，不包含HBase组件，需要另外安装。

（1）HBase和BigTable的底层技术对应关系

（2）HBase的必要性（与HDFS和MapReduce的区别）：

• Hadoop 可以很好地解决大规模数据的离线批量处理问题，但是，受限于 Hadoop MapReduce 编程框架的高延迟数据处理机制，使得 Hadoop 无法满足大规模数据实时处理应用的需求

• HDFS 面向批量访问模式，不是随机访问模式

• 传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题（分库分表也不能很好解决）

• 传统关系数据库在数据结构变化时一般需要停机维护；空列浪费存储空间

• 因此，业界出现了一类面向半结构化数据存储和处理的高可扩展、低写入 / 查询延迟的系统，例如，键值数据库、文档数据库和列族数据库（如 BigTable 和 HBase 等）

• HBase 已经成功应用于互联网服务领域和传统行业的众多在线式数据分析处理系统中

HBase 与传统的关系数据库的区别主要体现在以下几个方面：

（ 1 ）数据类型：关系数据库采用关系模型，具有丰富的数据类型和存储方式， HBase 则采用了更加简单的数据模型，它把数据存储为未经解释的字符串

（ 2 ）数据操作：关系数据库中包含了丰富的操作，其中会涉及复杂的多表连接。 HBase 操作则不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等，因为 HBase 在设计上就避免了复杂的表和表之间的关系

（ 3 ）存储模式：关系数据库是基于行模式存储的。 HBase 是基于列存储的，每个列族都由几个文件保存，不同列族的文件是分离的

2、HBase访问接口

类型	特点	场合
Native Java API	最常规和高效的访问方式	适合Hadoop MapReduce作业并行批处理HBase表数据
HBase Shell	HBase的命令行工具，最简单的接口	适合HBase管理使用
Thrift Gateway	利用Thrift序列化技术，支持C++、PHP、Python等多种语言	适合其他异构系统在线访问HBase表数据
REST Gateway	解除了语言限制	支持REST风格的Http API访问HBase
Pig	使用Pig Latin流式编程语言来处理HBase中的数据	适合做数据统计
Hive	简单	当需要以类似SQL语言方式来访问HBase的

3、Hbase数据模型

（1）Hbase数据模型的基本概念

• HBase 是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限定符和时间戳

• 每个值是一个未经解释的字符串，没有数据类型

• 用户在表中存储数据，每一行都有一个可排序的行键和任意多的列

• 表在水平方向由一个或者多个列族组成，一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起

• 列族支持动态扩展，可以很轻松地添加一个列族或列，无需预先定义列的数量以及类型，所有列均以字符串形式存储，用户需要自行进行数据类型转换

• HBase 中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留（这是和 HDFS 只允许追加不允许修改的特性相关的）

（2）数据模型相关概念

• 表： HBase 采用表来组织数据，表由行和列组成，列划分为若干个列族

• 行：每个 HBase 表都由若干行组成，每个行由行键（ row key ）来标识。

• 列族：一个 HBase 表被分组成许多“列族”（ Column Family ）的集合，它是基本的访问控制单元

• 列限定符：列族里的数据通过列限定符（或列）来定位

• 单元格：在 HBase 表中，通过行、列族和列限定符确定一个“单元格”（ cell ），单元格中存储的数据没有数据类型，总被视为字节数组 byte[]

时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引

（3）数据坐标

•HBase中需要根据行键、列族、列限定符和时间戳来确定一个单元格，因此，可以视为一个“四维坐标”，即[行键, 列族, 列限定符, 时间戳]

键	值
[“201505003”, “Info”, “email”, 1174184619081]	“xie@qq.com”
[“201505003”, “Info”, “email”, 1174184620720]	“you@163.com”

（4）HBase数据的概念视图

行键	时间戳	列族contents	列族anchor
"com.cnn.www"	t5		anchor:cnnsi.com=”CNN”
	t4		anchor:my.look.ca="CNN.com"
	t3	contents:html="<html>..."
	t2	contents:html="<html>..."
	t1	contents:html="<html>..."

（5） HBase数据的物理视图

列族contents

行键	时间戳	列族contents
"com.cnn.www"	t3	contents:html="<html>..."
	t2	contents:html="<html>..."
	t1	contents:html="<html>..."

列族anchor

行键	时间戳	列族anchor
"com.cnn.www"	t5	anchor:cnnsi.com=”CNN”
"com.cnn.www"	t4	anchor:my.look.ca="CNN.com"

（6）面向列式存储

行式数据库和列式数据库示意图

SQL模式

行式存储结构和列式存储结构

4、HBase的实现原理

（1）HBase功能组件

• HBase 的实现包括三个主要的功能组件：

– （ 1 ）库函数：链接到每个客户端

– （ 2 ）一个 Master 主服务器

– （ 3 ）许多个 Region 服务器

• 主服务器Master负责管理和维护HBase表的分区信息，维护 Region 服务器列表，分配 Region ，负载均衡

• Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求

• 客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据

• 客户端并不依赖 Master ，而是通过 Zookeeper 来获得 Region 位置信息，大多数客户端甚至从来不和 Master 通信，这种设计方式使得 Master 负载很小

（2）表和Region

• 开始只有一个 Region ，后来不断分裂

• Region 拆分操作非常快，接近瞬间，因为拆分之后的 Region 读取的仍然是原存储文件，直到“合并”过程把存储文件异步地写到独立的文件之后，才会读取新文件

• 每个 Region 默认大小是 100MB 到 200MB （ 2006 年以前的硬件配置）

• 每个 Region 的最佳大小取决于单台服务器的有效处理能力

• 目前每个 Region 最佳大小建议 1GB-2GB （ 2013 年以后的硬件配置）

• 同一个 Region 不会被分拆到多个 Region 服务器

• 每个 Region 服务器存储 10-1000 个 Region

图：不同的Region可以分布在不同的Region服务器上

（3）Region的定位

• 元数据表，又名 .META. 表，存储了 Region 和 Region 服务器的映射关系

• 当 HBase 表很大时， .META. 表也会被分裂成多个 Region

• 根数据表，又名 -ROOT- 表，记录所有元数据的具体位置

• -ROOT- 表只有唯一一个 Region ，名字是在程序中被写死的

• Zookeeper 文件记录了 -ROOT- 表的位置

图： HBase 的三层结构

层次	名称	作用
第一层	Zookeeper文件	记录了-ROOT-表的位置信息
第二层	-ROOT-表	记录了.META.表的Region位置信息 -ROOT-表只能有一个Region。通过-ROOT-表，就可以访问.META.表中的数据
第三层	.META.表	记录了用户数据表的Region位置信息，.META.表可以有多个Region，保存了HBase中所有用户数据表的Region位置信息

表： HBase的三层结构中各层次的名称和作用

• 为了加快访问速度， .META. 表的全部 Region 都会被保存在内存中

• 假设 .META. 表的每行（一个映射条目）在内存中大约占用 1KB ，并且每个 Region 限制为 128MB ，那么，上面的三层结构可以保存的用户数据表的 Region 数目的计算方法是：

• （ -ROOT- 表能够寻址的 .META. 表的 Region 个数）×（每个 .META. 表的 Region 可以寻址的用户数据表的 Region 个数）

• 一个 -ROOT- 表最多只能有一个 Region ，也就是最多只能有 128MB ，按照每行（一个映射条目）占用 1KB 内存计算， 128MB 空间可以容纳 128MB/1KB=2 17 行，也就是说，一个 -ROOT- 表可以寻址 2 17 个 .META. 表的 Region 。

• 同理，每个 .META. 表的 Region 可以寻址的用户数据表的 Region 个数是 128MB/1KB=2 17 。

• 最终，三层结构可以保存的 Region 数目是 (128MB/1KB) × (128MB/1KB) = 2 34 个 Region

客户端访问数据时的“三级寻址”

•为了加速寻址，客户端会缓存位置信息，同时，需要解决缓存失效问题

•寻址过程客户端只需要询问Zookeeper服务器，不需要连接Master服务器

5、HBase运行机制

（1）HBase系统架构

图：HBase的系统架构

• 1. 客户端

– 客户端包含访问 HBase 的接口，同时在缓存中维护着已经访问过的 Region 位置信息，用来加快后续数据访问过程

• 2. Zookeeper 服务器

– Zookeeper 可以帮助选举出一个 Master 作为集群的总管，并保证在任何时刻总有唯一一个 Master 在运行，这就避免了 Master 的“单点失效”问题

• 3. Master

• 主服务器 Master 主要负责表和 Region 的管理工作：

– 管理用户对表的增加、删除、修改、查询等操作

– 实现不同 Region 服务器之间的负载均衡

– 在 Region 分裂或合并后，负责重新调整 Region 的分布

– 对发生故障失效的 Region 服务器上的 Region 进行迁移

• 4. Region 服务器

– Region 服务器是 HBase 中最核心的模块，负责维护分配给自己的 Region ，并响应用户的读写请求

（2）Region服务器工作原理

图 Region服务器向HDFS文件系统中读写数据

1. 用户读写数据过程

• 用户写入数据时，被分配到相应 Region 服务器去执行

• 用户数据首先被写入到 MemStore 和 Hlog 中

• 只有当操作写入 Hlog 之后， commit() 调用才会将其返回给客户端

• 当用户读取数据时， Region 服务器会首先访问 MemStore 缓存，如果找不到，再去磁盘上面的 StoreFile 中寻找

2、缓存的刷新

• 系统会周期性地把 MemStore 缓存里的内容刷写到磁盘的 StoreFile 文件中，清空缓存，并在 Hlog 里面写入一个标记

• 每次刷写都生成一个新的 StoreFile 文件，因此，每个 Store 包含多个 StoreFile 文件

• 每个 Region 服务器都有一个自己的 HLog 文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入 MemStore ，再刷写到 StoreFile ，最后删除旧的 Hlog 文件，开始为用户提供服务

3. StoreFile 的合并

• 每次刷写都生成一个新的 StoreFile ，数量太多，影响查找速度

• 调用 Store.compact () 把多个合并成一个

• 合并操作比较耗费资源，只有数量达到一个阈值才启动合并

（3）Store工作原理

•Store是Region服务器的核心

•多个StoreFile合并成一个

•单个StoreFile过大时，又触发分裂操作，1个父Region被分裂成两个子Region

图 StoreFile的合并和分裂过程

（4）HLog工作原理

• Zookeeper 会实时监测每个 Region 服务器的状态，当某个 Region 服务器发生故障时， Zookeeper 会通知 Master

• Master 首先会处理该故障 Region 服务器上面遗留的 HLog 文件，这个遗留的 HLog 文件中包含了来自多个 Region 对象的日志记录

• 系统会根据每条日志记录所属的 Region 对象对 HLog 数据进行拆分，分别放到相应 Region 对象的目录下，然后，再将失效的 Region 重新分配到可用的 Region 服务器中，并把与该 Region 对象相关的 HLog 日志记录也发送给相应的 Region 服务器

• Region 服务器领取到分配给自己的 Region 对象以及与之相关的 HLog 日志记录以后，会重新做一遍日志记录中的各种操作，把日志记录中的数据写入到 MemStore 缓存中，然后，刷新到磁盘的 StoreFile 文件中，完成数据恢复

• 共用日志优点：提高对表的写操作性能；缺点：恢复时需要分拆日志