第一节. 概述
第二节. HBase访问接口
第三节.HBase数据模型
第四节. HBase的实现原理
第五节.HBase运行机制
第六节.应用方案
第七节.HBase编程实践
一、概述
1.简介
HBase是谷歌BigTable的开源实现。
HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库。
HBase主要用来存储非结构化和半结构化的松散数据。
Hbase架构在HDFS之上，HDFS是存储完全非结构化数据
HBase的目标是处理非常庞大的表，可以通过水平扩展的方式，利用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表。
2.HBase与传统的关系数据库的区别主要体现在以下几个方面：
（1）数据类型：关系数据库采用关系模型，具有丰富的数据类型和存储方式；HBase则采用了更加简单的数据模型，它把数据存储为未经解释的字符串，在java中就是字节数组Bytes；
（2）数据操作：关系数据库中包含了丰富的操作，其中会涉及复杂的多表连接。HBase操作则不存在复杂的多表连接，只有简单的插入、查询、删除、清空等，因为HBase在设计上就避免了复杂的多表连接；
（3）存储模式：关系数据库是基于行模式存储的。HBase是基于列存储的，每个列族都由几个文件保存，不同列族的文件是分离的。
（4）数据索引：关系数据库通常可以针对不同列构建复杂的多个索引，以提高数据访问性能。HBase只有一个索引——行键，通过巧妙的设计，HBase中的所有访问方法，或者通过行键访问，或者通过行键扫描，从而使得整个系统不会慢下来。
（5）数据维护：在关系数据库中，更新操作会用最新的当前值去替换记录中原来的旧值，旧值被覆盖后就不会存在。而在HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留。
（6）可伸缩性：关系数据库很难实现水平扩展，纵向扩展的空间也比较有限。相反，HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的，能够轻易地通过在分布式集群中增加或者减少硬件数量来实现性能的伸缩。
二、 HBase访问接口
三.HBase数据模型
1.数据模型概述
（1）HBase是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限定符（列）和时间戳。
Hbase中，每个值是一个未经解释的字符串，没有数据类型；
（2）每个行有一个行键和任意多个列；
（3）表在水平方向由一个或者多个列族组成，一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起；
（4）列族支持动态扩展；
（5）更新操作时，保留旧版本；
2.数据模型相关概念
表：HBase采用表来组织数据，表由行和列族组成，列族包含若干个列；
行：每个HBase表都由若干行组成，每个行由行键 （row key）来标识；
列族：一个HBase表被分组成许多“列族”（Column Family）的集合，它是基本的访问控制单元（存储单元）；
列限定符（列）：列族里的数据通过列限定符（或列）来定位，列可以动态增加和减少；
单元格：在HBase表中，通过行、列族和列限定符确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte[]；
时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引。
3.数据坐标
关系数据库：二维定位
HBase：四维定位
4、概念视图
四、HBase的实现原理
HBase功能组件
（1）HMaster服务器
对HBase表中分区信息的维护和管理；
维护Region服务器列表；
知道整个集群中有哪些Region服务器在工作；
负责对Region进行分配；
负载均衡。
（2）Region
在一个Hbase表中可能包含的行的数量非常庞大，无法存储到一台机器上，需要分布存储在多台机器上；
需要根据行键的值对表中的行进行分区，每个行区间构成一个分区，被称为“Region”。
五、HBase运行机制
- 客户端
客户端包含访问HBase的接口，同时在缓存中维护着已经访问过的Region位置信息，用来加快后续数据访问过程 - Zookeeper服务器
Zookeeper可以帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这就避免了Master的“单点失效”问题
Zookeeper是一个很好的集群管理工具，被大量用于分布式计算，提供配置维护、域名服务、分布式同步、组服务等。 - Master
主服务器Master主要负责表和Region的管理工作：
管理用户对表的增加、删除、修改、查询等操作
实现不同Region服务器之间的负载均衡
在Region分裂或合并后，负责重新调整Region的分布
对发生故障失效的Region服务器上的Region进行迁移 - Region服务器
Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求。
5.Region服务器工作原理
（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()把多个合并成一个
合并操作比较耗费资源，只有数量达到一个阈值才启动合并。
6.Store工作原理
Store是Region服务器的核心
多个StoreFile合并成一个
单个StoreFile过大时，又触发分裂操作，1个父Region被分裂成两个子Region。