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"

说明：

表格格式不是唯一和最精确的表达方式，还可以用Json格式来表达
表格中的空白单元不会占用物理存储空间，只是概念上存在

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（生存时间）

说明：

版本数的最大值和最小值是可以指定的，并且会影响操作
版本（时间戳）是用来管控数据的存活时间的，最好不要手动设置

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

HBase架构：图片来自Map-R网站

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的启动时间)

hbase:meta结构图，图片来自Map-R

2）存储位置：ZooKeeper中

HMaster：控制者

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

HMaster的功能：图片来自Map-R网站

HRegionServer：HBase实际读写者

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

HRegionServer：图片来自Map-R网站

本小节可参考Region Server详解

ZooKeeper：协调者

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

ZooKeeper，图片来自Map-R

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的启动时间)

-ROOT-与.META

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

从ZooKeeper中读取-ROOT- Table所在HRegionServer
从该HRegionServer中根据请求的TableName，RowKey读取.META. Table所在HRegionServer
从该HRegionServer中读取.META. Table的内容而获取此次请求需要访问的HRegion所在的位置
访问该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

HBase 框架学习之路

1 背景知识

1.1 解决问题

1.2 适用情况

2 设计理念

2.1 概述

2.1.1 简介

2.1.2 HBase特性：

2.1.3 劣势

2.2 设计架构

2.2.1 基础概念

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

2.2.1.3 操作

2.2.1.4 局限

2.2.2 架构

2.2.2.1 架构特点

2.2.2.2 组件

hbase:meta：所有region的信息

Key

Values

HMaster：控制者

HRegionServer：HBase实际读写者

ZooKeeper：协调者

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

2.3 相关流程

2.3.1 首次读写流程

2.3.2 写流程

2.3.2 读流程

2.4 相关机制

2.4.1 Compaction机制(压缩合并)

2.4.1.1 次压缩

2.4.1.2 主压缩

2.4.2 WAL Replay机制

2.5 版本更新内容

2.5.1 .META表 =>hbase:meta

2.5.1.1 -ROOT-和.META

1)结构：

Key

Values

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

2.5.1.2 hbase:meta

2.5.1.3 升级的目的

2.5.2 HLog =>WAL

2.6 跟其他框架的联系

2.7 性能调优

2.8 高级特性

3 项目实战

3.1 入门指南

3.1.1 环境搭建

3.1.2 入门程序

3.2 技术难点

3.3 开发中遇到的问题

3.4 应用

3.4.1 OpenTSDB开发

4 声明

参考文章：

你可能感兴趣的:(HBase 框架学习之路)