恁困呢......
HBase
HBase 概述
HBase 与传统关系数据库的对比
- 数据类型
- 数据操作
- 存储模式
- 数据索引
- 数据维护
- 可伸缩性
HBase 访问接口
Native Java API
- 最常规和高效的访问方式
HBase Shell
- HBase 的命令行工具
Thrift Gateway
- 利用 Thrift 序列化技术,支持 C++、PHP、Python 等多种语言
REST Gateway
- 解除了语言限制
Pig
- 使用了 Pig Latin 流形编程语言来处理 HBase 中的数据
Hive
HBase 数据模型
概述
- HBase 是一个稀疏、多维度、排序的映射表。这张表的索引是行键、列族、列限定符和时间戳
- 每一个值都是未经解释的字符串,没有数据类型
- 执行更新操作时,不会删除数据旧的版本,而是生成一个新的版本,旧版本仍然保留
数据模型相关概念
-
表
- HBase 采用表来组织数据,表由行和列组成,列划分为若干个列族
-
行
-
每个表由若干行组成,每行由行键(Row Key)来识别
-
访问表中的行方式
- 通过单个行键
- 通过一个行键区间
- 通过全表扫描
-
-
-
列族
- 一个 HBase 表被份组成许多“列族”的集合,它时基本的访问控制单元
-
列限定符
- 列族里的数据通过列限定符(或列)来定位
-
单元格
- 通过行、列族、列限定符来确定一个“单元格”(Cell),一个单元格种可以保存一份数据的多个版本,通过时间戳来进行索引
-
时间戳
- 每个单元格中的不同版本的同一份数据,使用时间戳来进行索引
数据坐标
-
在 HBase 中,通过“四维坐标”来定位表中数据
- 行键
- 列族
- 列限定符
- 时间戳
概念视图
- 在 HBase 的概念视图中,一个表可以视为一个稀疏、多维的映射关系
物理视图
- HBase 采用基于列存储方式,而不是像传统关系数据库那样采用基于行的存储方式
面向列和面向行存储
-
面向行存储(行式数据库)
- 使用 NSM (N-ary Storage Model) 存储模型
- 一个元组(或行)会被连续地存储在磁盘页中
- 适合小批量的数据处理
-
面向列存储(列式数据库)
- 使用 DMS (Decomposition Storage Model)存储模型
- DSM 会对关系进行垂直分解,并为每个属性分配一个子关系,每个子关系单独存储,即: DSM 是以关系数据库中的属性或列为单位进行存储,关系中多个元组的同时属性值(同一列值)会被存储在一起,而一个元组中不同属性值则通常会被分别存放于不同的磁盘页中
-
适合批量数据处理和即席查询(Ad-Hoc Query)
- 即席查询是用户根据自己的需求,灵活的选择查询条件,系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的,而即席查询是由用户自定义查询条件的
-
优点
- 降低 I/0 开销,支持大量并发用户查询
- 具有较高的数据压缩比
-
DSM 的缺陷
- 执行连接操作时需要昂贵的元组重构代价
严格从关系数据库角度来看,HBase 并不是一个列示存储数据库,因为 HBase 是以列族为单位(列族中可以包含多个列)进行分解,而不是每个列都单独存储,但是 HBase 借鉴和利用了磁盘上的这种存储格式,所以从这个角度上来说,HBase 可以被视为列示数据库
HBase的实现原理
HBase 的功能组件
- 库函数,负责链接到每个客户端
-
一个 Master 主服务器
- 负责管理和维护 HBase 表的分区信息
- 维护 Region 服务器列表
- 实时监测集中中的 Region 服务器,分配 Region,并维护负载均衡
- Region 服务器故障时将服务器内存储的 Region 重新分配至其他 Region 服务器
- 处理模式变化
-
许多个 Region 服务器
- 负责存储和维护分配给自己的 Region ,处理来自客户端的读写请求
表和 Region
- HBase 表根据行键的值对表中的行进行分区,每个行区间构成一个分区,被称为“Region”,包含了位于某个至于区间内的所有数据,它是负载均衡和数据分发的基本单位,这些 Rrgion 会被分发到不同的 Region 服务器上
Region 的定位
-
Region 标识符
- 表名+开始主键+RegionID
-
HBase三层结构
-
Zookeeper 文件
- 记录了 -ROOT- 表信息
-
-ROOT- 表
- 记录了 .MYTA 表的 Region 位置信息, -ROOT- 表只能有一个 Region 。通过 -ROOT- 表就可以访问 .META. 表中的数据
-
.META. 表
- 记录用户数据表的 Region 位置信息, .META. 表可以有多个 Region ,保存了 HBase 中所有用户数据表的 Region 位置信息
-
-
三层结构可以保存的用户数据表的 Region 数目的计算方法是:
- ( -ROOT- 表能够寻址的 .META. 表的 Region 个数)X(每个 .META. 表的 Region 可以寻址的用户数据表的 Region geshu)
-
三级寻址
- 访问 Zookeeper 获取 -ROOT- =>访问 -ROOT- 获取 .META.=>访问 .META. 获取 Region 服务器=>访问 Region 服务器=>获取 Region
- 为了加速寻址过程,一般会把查询过的位置信息作为缓存储存在客户端,而不是每一次都经历一次"三级寻址",如果缓存信息中不能正常寻址,则会再次经历“三级寻址”
HBase 运行机制
HBase 系统架构
-
客户端
- 包含访问 HBase 的接口,同时在缓存中维护着已经访问过的 Region 位置信息,用来加快后续数据访问过程
-
Zookeeper 服务器
- Zookeeper 服务器并非一台单一的机器,可能是由多台机器构成的集群来提供稳定可靠的协同服务
- 实时检控每一个 Region 服务器的状态并通知给 Master
- 在有多个 Master被启动时,保证任何时刻总有唯一一个 Master 在运行,避免 “单点失效”问题
- 保存 -ROOT- 表和 Master 的地址,客户端可以通过访问 Zookeeper 获得 -ROOT- 表的地址
-
Master
- 管理用户对标的增删改查等操作
- 实现不同 Region 服务器之间的负载均衡
- 在 Region 分裂或合并后,负责重新调整 Region 的分布
- 对发生故障失效的 Region 服务器上的 Region 进行迁移
-
Region 服务器
- HBase 中最核心的模块
- 负责维护分配给自己的 Region
- 响应用户的读写请求
- 一个 Region 只能分配给一个 Region 服务器
Region 服务器的工作原理
-
用户读写数据的过程
- 当用户写入数据时,就会被分配到相应的 Region 服务器去执行操作,用户数据首先被写入 MemStore 和 HLog 中,当操作写入 HLog 后,coommit()调用才会返回给客户端
- 当用户读取数据时,Region 服务器会首先访问 MemStore 缓存,如果数据不在缓存中,则在磁盘上的 StoreFile中寻找
-
缓存的刷新
- 系统会周期性的调用 Region .flushcache()把 MemStore 缓存里面的内容写到磁盘的 StoreFile中,清空缓存并在HLog中写入一个标记,表示缓存已被写入 StoreFile中
-
StoreFile 的合并
- 每次 MemStore 缓存的刷新操作都会生成一个新的 StoreFile,当Store 文件的数量达到阈值就会触发合并操作
Store 的工作原理
- Store 是 Region 服务器的核心
- 每个 Store 对应了表中的一个列族存储
- 每个 Store 包含一个 MemStore 缓存和若干个 StoreFile 文件
- 当承载用户写入数据的缓存 MemStore 满了之后,就会刷新到一个 StoreFile 中,当 StoreFile 文件数量达到阈值,就会触发合并操作:多个 StoreFile 被合并为一个较大的 StoreFile ,当 单个StoreFile 文件大小超过阈值时,就会触发文件分裂操作,同时当前的一个父 Region 会分裂出2个子 Region ,然后父 Region 下线,两个子 Region 被分配到对应的 Region 服务器上
HLog的工作原理
- HBase 采用 HLog 来保证系统发生故障时能够恢复到正确的状态
- 每个 Region 服务器都配置了一个 HLog 文件,它时一种预写式日志(Write Ahead Log)
-
每个 Region 服务器 只需要维护一个HLog文件,所有 Region 对象共用一个 HLog
-
优点
- 减少磁盘寻址次数,提高对表的写操作性能
-
缺点
- 如果一个 Region 服务器发生故障,为了恢复其上的 Region 对象,需要将 Region 服务器上的 HLog 按照所属的 Region 对象进行拆分,然后分发到其他 Region 服务器上执行恢复操作
-
XMind - Trial Version