HBase学习详解大数据

HBase简介

HBase是Apache Hadoop的数据库，能够对大型数据提供随机、实时的读写访问，是Google的BigTable的开源实现。HBase的目标是存储并处理大型的数据，更具体地说仅用普通的硬件配置，能够处理成千上万的行和列所组成的大型数据库。
HBase是一个开源的、分布式的、多版本的、面向列的存储模型。可以直接使用本地文件系统也可使用Hadoop的HDFS文件存储系统。为了提高数据的可靠性和系统的健壮性，并且发挥HBase处理大型数据的能力，还是使用HDFS作为文件存储系统更佳。另外，HBase存储的是松散型数据，具体来说，HBase存储的数据介于映射（key/value）和关系型数据之间。如下图所示，HBase存储的数据从逻辑上看就是一张很大的表，并且它的数据列可以根据需要动态增加。每一个cell中的数据又可以有多个版本（通过时间戳来区别），从下图来看，HBase还具有“向下提供存储，向上提供运算”的特点。

HBase体系结构

HBase的服务器体系结构遵从简单的主从服务器架构，它由HRegion Server群和HBase Master服务器构成。HBase Master负责管理所有的HRegion Server，而HBase中的所有RegionServer都是通过ZooKeeper来协调，并处理HBase服务器运行期间可能遇到的错误。HBase Master Server本身并不存储HBase中的任何数据，HBase逻辑上的表可能会被划分成多个Region，然后存储到HRegion Server群中。HBase Master Server中存储的是从数据到HRegion Server的映射。因此HBase体系结构如下图所示。

1） Client
HBase Client使用HBase的RPC机制与HMaster和HRegion Server进行通信，对于管理类操作，Client与HMaster进行RPC；对于数据读写类操作，Client与HRegionServer进行RPC。
2）Zookeeper
Zookeeper Quorum中除了存储了-ROOT-表的地址和HMaster的地址，HRegionServer会把自己以Ephemeral方式注册到Zookeeper中，使得HMaster可以随时感知到各个HRegionServer的健康状态。此外，Zookeeper也避免了HMaster的单点问题。
3）HMaster
每台HRegionServer都会与HMaster进行通信，HMaster的主要任务就是要告诉每台HRegion Server它要维护哪些HRegion。
当一台新的HRegionServer登录到HMaster时，HMaster会告诉它等待分配数据。而当一台HRegion死机时，HMaster会把它负责的HRegion标记为未分配，然后再把它们分配到其他的HRegion Server中。
HBase已经解决了HMaster单点故障问题（SPFO），并且HBase中可以启动多个HMaster，那么它就能够通过Zookeeper来保证系统中总有一个Master在运行。HMaster在功能上主要负责Table和Region的管理工作，具体包括：

• 管理用户对Table的增删改查操作
• 管理HRegionServer的负载均衡，调整Region分布
• 在Region Split后，负责新Region的分配
• 在HRegionServer停机后，负责失效HRegionServer上的Region迁移

4）HRegion
当表的大小超过设置值得时候，HBase会自动地将表划分为不同的区域，每个区域包含所有行的一个子集。对用户来说，每个表是一堆数据的集合，靠主键来区分。从物理上来说，一张表被拆分成了多块，每一块就是一个HRegion。我们用表名+开始/结束主键来区分每一个HRegion，一个HRegion会保存一个表里面某段连续的数据，从开始主键到结束主键，一张完整的表格是保存在多个HRegion上面。

上图表示当Table随着记录数不断增加而变大后，会逐渐分裂成多份splits，成为regions，一个region由[startkey, endkey]表示，不同的region会被Master分配给响应的RegionServer进行管理。

5）HRegionServer
所有的数据库数据一般都是保存在Hadoop分布式文件系统上面的，用户通过一系列HRegion服务器获取这些数据，一台机器上面一般只运行一个HRegionServer，且每一个区段的HRegion也只会被一个HRegion服务器维护。如下图所示HRegion Server数据存储关系图。

HRegion Server主要负责响应用户的IO请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region，HRegion中由多个HStore组成。每个HStore对应了Table中的一个Column Family的存储，可以看出每个ColumnFamily其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个Column Family中，这样最高效。
HStore存储时HBas存储的核心了，其中由两部分组成，一部分是MemStore，一部分是StoreFiles。MemStore*是Sorted Memory Buffer，用户写入数据首先会放入MemStore，当MemStore满了以后会flush成一个*StoreFile（底层是HFile），当StoreFile文件数增长到一定阈值，会触发Compact合并操作，将多个StoreFile合并成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立刻返回，保证了HBase IO的高性能。当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定的阈值后，会触发Split操作，同时，会把当前的Region Split成2个Region，父Region会下线，新Split出的2个孩子Region会被HMaster分配到响应的HRegion Server上，使得原先1个Region的压力得以分流道2个Region上。下图描述了Compaction和Split的过程。

理解上述HStore的基本原理之后，必须了解一下HLog的功能，因为上述的HStore在系统正常工作的前提下是没有问题的，但是在分布式系统环境中，无法避免系统出错或者宕机，一次一旦HRegion Server意外退出，MemStore中的内存数据将会丢失，这就需要引入HLog了。每一个HRegionServer中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中，HLog文件定期会滚动出新的，并删除旧的文件，当HRegionServer意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应Region的目录下，然后再将失效的Region重新分配，领取到这些Region的HRegionServer在LoadRegion过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。
6）HBase存储格式
HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，包括上述提到的两种文件类型：

• HFile HBase中的KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级的包装，即StoreFile底层就是HFile。
• HLogFile，HBase中WAL（Write Ahead Log）的存储格式，物理上是Hadoop的Sequence File

7）ROOT表和META表
用户表的Regions元数据被存储在.META.表中，随着Region的增多，.META.表中的数据也会增大，并分裂成多个Regions。为了定位.META.表中各个Regions的位置，把.META.表中的所有Regions的元数据保存在-ROOT-表中，最后由Zookeeper记录-ROOT-表的位置信息。所有客户端访问用户数据前，需要首先访问Zookeeper获得-ROOT-的位置，然后方位-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，-ROOT-表永远不会被分割，它只有一个Region，这样可以保证最多需要三次跳转就可以定位任意一个Region。为了加快访问速度，.META.表的Regions全部保存在内存中，如果.META.表中的每一行在内存中占大约1KB，且每个Region限制为128M，下图中的三层结构可以保存Regions的数目为(128M/1KB)*(128/1KB)=2^34个。

HBase数据模型

HBase是一个类似于BigTable的分布式数据库，它是一个稀疏的长期存储的（存在硬盘上）、多维度的、排序的映射表。这张表的索引是行关键字、列关键字和时间戳。HBase的数据都是字符串，没有类型。
用户在表格中存储数据，每行都有一个可排序的主键和任意多的列。由于是系数存储，所以同一张表里面的每行数据都可以由截然不同的列。
列名字的格式是“<family>:<qualifier>”（<列簇>:<限定符>），都是有字符串组成的。每一张表有一个列簇（family）集合，这个集合是固定不变的，只能通过改变表结构来改变。但是限定符（qualifier）的值相对于每一行来说都是可以改变的。HBase把用一个列簇里面的数据存储在同一个目录底下，并且HBase的写操作时琐行的，每一行来说都是一个原子元素，都可以加锁。HBase所有数据库的更新都有一个时间戳标记，每个更新都是一个新的版本，HBase会保留一定数量的版本，这个值是可以设定的，客户端可以选择获取距离某个时间点最近的版本单元的值，或者一次获取所有版本单元的值。

1）逻辑模型
可以将表想象成一个大的映射关系，通过行健、行健+时间戳或者行健+列（列簇：列修饰符），就可以定位特定数据。由于HBase是稀疏存储数据的，所以某些列可以空白的。如下表，给出的是 www.cnn.com 网站的数据存放逻辑视图，表中仅有一行数据，行的唯一标识为”com.cnn.www” ，对这行数据的每一次逻辑修改都有一个时间戳关联对应。表中共有四列：contents:html、anchor:cnnsi.com、anchor:my.lock.ca、mime:type，每一行以前缀的方式给出其所属的列簇。

行健是数据行在表中的唯一标识，并作为检索记录的主键。在HBase中访问表中的行只有三种方式：通过当个行健访问；给定行健的范围访问；全表扫描。行健可以任意字符串（最大长度64KB）并按照字典序进行存储。对那些经常一起读取的行，需要对key值精心设计，以便它们能放在一起存储。

2）概念模型
HBase是按照列存储的稀疏行/列矩阵，物理模型实际上就是把概念模型中的一行进行切割，并按照列族存储，这点在进行数据设计和程序开发的时候必须牢记。上面的逻辑视图在物理存储的时候应该表现下面的样子：

从上图可以看出空值是不被存储的，所以查询时间戳为t8的“contents:html”将返回null，同样查询时间戳为t9,”anchor:my.lock.ca”的项也返回null。如果没有指明时间戳，那么应该返回指定列的最新数据，并且最新的值在表格里也是最先找到的，因为他们是按照时间排序的。所以，如果查询“contents”而不指明时间戳，将返回t6的数据，这种存储结构还有一个优势就是可以随时向表中的任何一个列族添加新列，而不需要事先说明。

转载出处：http://www.cnblogs.com/nexiyi/p/hbase_intro_94.html