Hadoop学习笔记—15.HBase框架学习（基础知识篇）
HBase是Apache Hadoop的数据库，能够对大型数据提供随机、实时的读写访问。HBase的目标是存储并处理大型的数据。HBase是一个开源的，分布式的，多版本的，面向列的存储模型，它存储的是松散型数据。
一、HBase：BigTable的开源实现
1.1 HBase出现的背景
（1）随着数据规模越来越大，大量业务场景开始考虑数据存储水平扩展，使得存储服务可以增加/删除，而目前的关系型数据库更专注于一台机器。
（2）海量数据量存储成为瓶颈，单台机器无法负载大量数据。
（3）单台机器IO读写请求成为海量数据存储时候高并发，大规模请求的瓶颈。
（4）当数据进行水平扩展时候，如何解决数据IO高一致性问题。结合Map/Reduce计算框架进行海量数据的离线分析。
1.2 BigTable成就了HBase
Google这个神奇的公司以其不保守的态度以学术论文的方式公开了其云计算的三大法宝：GFS、MapReduce和BigTable，其中对于BigTable的开源实现HBase则是由Doug Cutting完成的。
HBase是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。
HBase中的表一般有这样的特点：
（1） 大：一个表可以有上亿行，上百万列
（2） 面向列：面向列(族)的存储和权限控制，列(族)独立检索。
（3） 稀疏：对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏。
PS：什么是列存储？
列存储不同于传统的关系型数据库，其数据在表中是按行存储的，列方式所带来的重要好处之一就是，由于查询中的选择规则是通过列来定义的，因此整个数据库是自动索引化的。按列存储每个字段的数据聚集存储，在查询只需要少数几个字段的时候，能大大减少读取的数据量，一个字段的数据聚集存储，那就更容易为这种聚集存储设计更好的压缩/解压算法。下图讲述了传统的行存储和列存储的区别：
1.3 HBase在Hadoop项目中的位置
与FUJITSU Cliq等商用大数据产品不同，HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable利用 Chubby作为协同服务，HBase利用Zookeeper作为对应。
下图展示了HBase在Hadoop生态系统体系结构中所处的位置：
上图描述了Hadoop生态系统中的各层系统。其中，HBase位于结构化存储层，Hadoop HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和失效转移（FailOver）机制。
此外，Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。 Sqoop则为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。
二、HBase的数据模型
HBASE中的每一张表，就是所谓的BigTable，一张稀疏表。RowKey 和 ColumnKey 是二进制值byte[]，按字典顺序排序；Timestamp 是一个 64 位整数；value 是一个未解释的字节数组byte[]。表中的不同行可以拥有不同数量的成员。即支持“动态模式“模型。
2.1 逻辑模型
Table & Column Family
HBase以表的形式存储数据。表有行和列组成。列划分为若干个列族(row family)，如下图所示：
Ø Row Key: 行键，Table的主键，Table中的记录按照Row Key排序
Ø Timestamp: 时间戳，每次数据操作对应的时间戳，可以看作是数据的version number
Ø Column Family：列簇，Table在水平方向有一个或者多个Column Family组成，一个Column Family中可以由任意多个Column组成，即Column Family支持动态扩展，无需预先定义Column的数量以及类型，所有Column均以二进制格式存储，用户需要自行进行类型转换。
2.2 物理模型
（1）物理存储表示
将逻辑模型中的一个Row分割为根据Column family存储的物理模型，如下图所示：
（2）Table & Region
当Table随着记录数不断增加而变大后，会逐渐分裂成多份splits，成为regions，一个region由[startkey,endkey)表示，不同的region会被Master分配给相应的RegionServer进行管理，如下图所示：
由上可知，HBase的伸缩性主要依赖于其可分裂的HRegion及可伸缩的分布式文件系统HDFS，下面介绍一下HBase如何实现伸缩性：
①HBase中数据以HRegion为单位进行管理，也就是说应用程序如果想要访问一个数据，必须先找到HRegion，然后将数据读写操作提交给HRegion，由HRegion完成存储层面的数据操作。
②每个HRegion中存储一段Key区间（例如：[Key1,Key2)）的数据，HRegionServer是物理服务器，每个HRegionServer上可以启动多个HRegion实例。当一个HRegion中写入的数据太多，达到配置的阀值时，HRegion会分裂成两个HRegion，并将HRegion在整个集群中进行迁移，以使HRegionServer的负载均衡。
③所有的HRegion的信息都（例如：存储的Key值区间、所在HRegionServer的IP地址和端口号等）记录在HMaster服务器上。同时为了保证高可用，HBase启动了多个HMaster，并通过ZooKeeper（一个支持分布式一致性的数据管理服务）选举出一个主服务器，通过这个主HMaster服务器获得Key值所在的HRegionServer，最后请求该HRegionServer上的HRegion实例，获得需要的数据。其具体的数据寻址访问流程如下图所示：
三、HBase的系统架构
3.1 Client
包含访问hbase的接口，Client维护着一些cache来加快对hbase的访问，比如regione的位置信息。
3.2 ZooKeeper
（1） 保证任何时候，集群中只有一个master
（2） 存贮所有Region的寻址入口。
（3） 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master
（4） 存储Hbase的schema,包括有哪些table，每个table有哪些column family
3.3 HMaster
（1）为Region Server分配Region
（2）负责Region Server的负载均衡
（3）发现失效的Region Server并重新分配其上的Region
（4）GFS上的垃圾文件回收
（5）处理Schema更新请求
HMaster主要作用在于，通过HMaster维护系统表-ROOT-,.META.，记录regionserver所对应region变化信息。此外还负责监控处理当前hbase cluster中regionserver状态变化信息。
PS：两张神奇的表：-ROOT-和.META
① .META.：记录了用户表的Region信息，.META.可以有多个regoin② -ROOT-：记录了.META.表的Region信息，-ROOT-只有一个regionZookeeper中记录了-ROOT-表的location
Client访问用户数据之前需要首先访问Zookeeper，然后访问-ROOT-表，接着访问.META.表，最后才能找到用户数据的位置去访问：
3.4 Region Server
（1）Region Server维护HMaster分配给它的Region，处理对这些Region的IO请求
（2）Region Server负责切分在运行过程中变得过大的Region
可以看出，client 访问hbase 上数据的过程并不需要master 参与，寻址访问zookeeper 和region server，数据读写访问regioneserver。HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。
参考资料
（1）奥特MAN，《HBase入门篇》：http://www.uml.org.cn/sjjm/201212141.asp
（2）加俊，《HBase简介》：http://jiajun.iteye.com/blog/899632
（3）百度百科，《HBase》：http://baike.baidu.com/view/1993870.htm
（4）reck for zhou，《HBase介绍》：http://www.cnblogs.com/reckzhou/archive/2012/03/22/2412002.html
