标签：概述   ttl   数据存储   大量   关机   元数据   物理   hba   eve   

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 基础概念

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

说明：

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

2.2.1.3 操作

说明：

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）有三个组件：

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 声明

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

HBase框架学习之路

标签：概述   ttl   数据存储   大量   关机   元数据   物理   hba   eve   

原文地址：http://www.cnblogs.com/zhangyuliang/p/6782287.html