HBase框架学习之路

1 背景知识

1.1 解决问题

解决HDFS不支持单条记录的快速查找和更新的问题。

1.2 适用状况

• 存在亿万条记录的数据库，只有千万或者百万条记录使用RDBMS更加合适
• 确保你的应用不须要使用RDBMS的高级特性（第二索引，事务机制，高级查询语言等）
• 足够的硬件配置，即节点数，HDFS在少于5个节点时并不会表现得很好，HBase也存在相同状况。

2 设计理念

2.1 概述

2.1.1 简介

• 使用Java语言开发的NoSQL类型的分布式数据库
• 不支持RDBMS的一些高级特性，如事务机制，第二索引，高级查询语言等
• 支持线性和模块化扩展，能够经过在商用机器上增长RegionServer来线性提升性能

2.1.2 HBase特性：

• 强读写一致性：适合高速计数聚合操做
• 自动切分数据：分布式存储数据，随着数据增加进行自动切片
• RegionServer自动失效备援
• 与HDFS集成
• 支持MapReduce执行大规模并行操做
• 提供Java Client API
• 提供Thrift/REST API
• 针对大容量查询优化的块缓存和Bloom Fliter
• 可视化管理界面

2.1.3 劣势

• WAL的从新执行速度缓慢
• 故障恢复缓慢且复杂
• 主压缩会引发 I/O风暴（大量的I/O操做）

2.2 设计架构

2.2.1 基础概念

概念	中文	解释	备注	举例
Table	表	由多行组成	...
Row	行	由一个Key和一个或者多列组成
Column	列	由列族和列限定符组成	列族：列限定符 ；行与行之间的列能够相差不少
Column Family	列族	物理上存储多个列；为提升性能设计的；	表格建立时须要置顶	content
Column Qualifier	列限定符	列族中数据的索引	表格建立时不须要指定，能够在任什么时候候添加	content:html
Cell	单元	由行、列族、列限定符、值和表明版本的时间戳组成
TimeStamp	时间戳	用来表示数据的版本	可使用系统时间也能够本身指定

2.2.1.2 例子本例子取自官方文档

Row Key	Time Stamp	ColumnFamily contents	ColumnFamily anchor	ColumnFamily people
"com.cnn.www"	t9		anchor:cnnsi.com = "CNN"
"com.cnn.www"	t8		anchor:my.look.ca = "CNN.com"
"com.cnn.www"	t6	contents:html = "…​
"com.cnn.www"	t5	contents:html = "…​"
"com.cnn.www"	t3	contents:html = "…​
com.example.www	t5	contents:html: "..."		people:author: "John Doe"

说明：

1. 表格格式不是惟一和最精确的表达方式，还能够用Json格式来表达
2. 表格中的空白单元不会占用物理存储空间，只是概念上存在

2.2.1.3 操做

操做	API	注意点	与版本的关系
Get	Table.get	返回指定行的属性；Scan的第一行	若没有指定版本，则返回版本值最大（但可能不是最新的）的数据；能够经过设置MaxVersion的值修改返回的数据条数
Scan	Table.scan	返回知足条件的多行	同上
Put	Table.put	Key存在则更新Key不在则插入;经过 Table.put (写缓存) 或者Table.batch (没有写缓存)	默认使用系统时间;只要key、column和version相同就能够实现覆盖；插入时能够指定版本
Delete	Table.delete	1.删除指定列；2.删除列的全部版本；3.删除特定列族的全部列	1. 删除操做不会马上执行，而是给该数据设置墓碑标签，在空间清理的时候再执行死亡数据和墓碑的清除工做；2.经过在 hbase-site.xml.中hbase.hstore.time.to.purge.deletes属性来设置TTL（生存时间）

说明：

1. 版本数的最大值和最小值是能够指定的，而且会影响操做
2. 版本（时间戳）是用来管控数据的存活时间的，最好不要手动设置

2.2.1.4 局限

1）Delete操做会影响Put操做：缘由在于Delete操做并非马上执行，而是给死亡数据设置墓碑标签，那么若是当你执行了一个Delete版本低于等于T的操做，然后有插入Put了一个版本为T的数据，此时新Put的数据也会被打上标签，那么会在系统的下一次清理工做中将打上标签的数据所有清理掉，执行查询时则会获取不到新Put的数据，若是你不手动设置版本的话，版本采用系统默认时间，则不会出现这种状况。

2）清理工做会影响查询：建立三个版本为t1,t2,t3的单元，而且设置最大版本数为2.因此当咱们查询全部版本时，只会返回t2和t3。可是当你删除版本t2和t3的时候，版本t1会从新出现。显然，一旦重要精简工做运行以后，这样的行为就不会再出现。

查看更多关于数据模型的信息

2.2.2 架构

2.2.2.1 架构特色

1）主从架构
2）有三个组件：

组件名称	组件主要功能
HMaster	负责Region的分配和DDL操做（建立，删除表）
HRegionServer	RegionServer负责数据的读写;和客户端通信
ZooKeeper	维持集群的活动状态

3）底层储存是HDFS

2.2.2.2 组件

hbase:meta：全部region的信息

1）结构：

Key

• 格式：([table],[region start key],[region id])

Values

• info:regioninfo (序列化HRegionInfo实例)
• info:server (包含此Region的RegionServer的server:端口)
• info:serverstartcode (包含此Region的RegionServer的启动时间)

2）存储位置：ZooKeeper中

HMaster：控制者

• 分配Region：启动时分配，失效RegionServer上Region的再分配，Region切分时分配
• 监控集群中的全部RegionServer，实现其负载均衡
• DDL:Data Definition Language(表格的建立、删除和更新-列族的更新）
• 管理namespace和table的元数据
• 权限管理（ACL）
• HDFS上的垃圾文件回收

HRegionServer：HBase实际读写者

• 响应client的读写请求，进行I/O操做（直接绕过HMaster）
• 与HDFS交互，管理table数据
• 当Region的大小到达阀值时切分Region

本小节可参考Region Server详解

ZooKeeper：协调者

• 保证集群中有且只有一个HMaster为Active
• 存储hbase:meta，即全部Region的位置信息
• 存储HBase中表格的元数据信息
• 监控RegionServer状态，将RS的上下线状况汇报给HMaster
• ZooKeeper集群自己使用一致性协议(PAXOS协议)保证每一个节点状态的一致性

Region：Region是HBase数据存储和管理的基本单位

本小节可参考Region详解

2.3 相关流程

2.3.1 首次读写流程

本小节可参考Region Server详解中的首次读写流程

2.3.2 写流程

本小节可参考Region Server详解中的写流程

2.3.2 读流程

本小节可参考Region Server详解中的读流程

2.4 相关机制

2.4.1 Compaction机制(压缩合并)

2.4.1.1 次压缩

本小节可参考Region Server详解中的次压缩部分

2.4.1.2 主压缩

本小节可参考Region Server详解中的主压缩部分

2.4.2 WAL Replay机制

本小节可参考Region Server详解中的WAL Replay

2.5 版本更新内容

2.5.1 .META表 =>hbase:meta

2.5.1.1 -ROOT-和.META

在0.96.x以前是存在-ROOT-和.META两个表格来维持region的元数据

1）结构：

Key

• .META. region key (.META.,,1)

Values

• info:regioninfo (hbase:meta的序列化实例)
• info:server (存储 hbase:meta的RegionServer的server:port)
• info:serverstartcode (存储 hbase:meta的RegionServer的启动时间)

2）读取region位置信息的流程

1. 从ZooKeeper中读取-ROOT- Table所在HRegionServer
2. 从该HRegionServer中根据请求的TableName，RowKey读取.META. Table所在HRegionServer
3. 从该HRegionServer中读取.META. Table的内容而获取这次请求须要访问的HRegion所在的位置
4. 访问该HRegionSever获取请求的数据

2.5.1.2 hbase:meta

本小节可参考2.2.2.2 组件中的hbase:meta和2.3 相关流程中的首次读写流程进行比较

2.5.1.3 升级的目的

1）0.96.x版本以前是参考Goole的BigTable设计的，从读取数据请求发起到真正读取到数据要通过4个步骤，Google设计BigTable的目的在于它的数据量巨大，多层的schema结构可以存储更多的Region，可是随着而来的就是访问性能的降低。
2）通常公司的数据量没有Google那么大，因此去掉-ROOT-表，留下.META(hbase:meta)表，提升Region的大小，不只能够知足存储需求，并且访问性能获得提升。

2.5.2 HLog =>WAL

• 0.94.x 以前HBase中的WAL实现称为HLog，存储在/hbase/.logs/目录下
• 0.94.x以后改名为WAL，存储在/hbase/WALs/目录下

2.6 跟其余框架的联系

待续...

2.7 性能调优

待续...

2.8 高级特性

待续...

3 项目实战

3.1 入门指南

3.1.1 环境搭建

本小节可参考HBase部署入门指南

3.1.2 入门程序

本小节可参考HBase Shell 练习、HBase Java API 练习、使用MapReduce操做HBase

3.2 技术难点

待续...

3.3 开发中遇到的问题

待续...

3.4 应用

3.4.1 OpenTSDB开发

待续...

4 声明

待续部分将会后期不按期更新，敬请期待。

参考文章：

Apache HBase ™ Reference Guide
An In-Depth Look at the HBase Architecture

如有侵权，请联系我。