HBase理论介绍--1

1. Hbase简介

    Hbase是按照谷歌的Bigtable的设计模型实现的一种非关系型（NoSQL）列式数据库。

    列式数据库以列为单位聚合数据，然后将列值顺序地存入磁盘，这种方式不同于行式存储的传统数据库，行式数据库连续地存储整行。列式数据库的出现基于这样一个假设：对于特定的查询，并非所有的值都是必须的，尤其是对分析型数据库来说更是如此。这种设计至少有以下优点：减少I/O，基于列存储的压缩算法可以进一步提高压缩比，降低网络传输的宽带消耗。

2. 什么是NoSQL

   NoSQL是Not Only SQL的简称，其出现的初衷在于与关系型数据库进行补充，并非是取代关系型数据库。因为关系型数据库在存储有模式的、结构化数据和即时查询与修改方面变现更为出色，尤其适合事务性操作，而非关系型数据库则更适合于存储非结构化、半结构化的数据，见长于超大规模的（BIG DATA）的数据分析处理。因为超大规模的查询需要进行大范围的数据记录扫描或全表扫描，RDBMS在一台服务器上做查询的响应时间，会远远超过用户可接收的合理响应时间。垂直扩展服务器性能，即增加CPU核数和磁盘数目，不仅仅会导致运营费用的几何级增长，而且会导致运维工作量和工作难度的提升，在后期业务发展或者变更时等等情况下，也无法解决相应的问题；或者水平扩展服务器性能，即增加服务器数量，对数据进行分区、读写分离可以暂时解决问题，但当数据量增大时分区的难度增加及关系型数据库的一致性问题也难以解决。

3. Hbase的数据模型

   Hbase中最基本的单位是列，一列或多列组成一行，并由唯一的行健来确定存储。并且，每列可能有多个版本，在每一个单元格中储存了不同的值，这一点是通过时间戳来实现的。所有的行按照行健值进行字典序排序：

 与关系型数据库一样，Hbase中的行健也是唯一的。

   一行由若干列组成，若干列又构成一个列族，一个列族的所有列存储在同一个底层的存储文件里，这个 存储文件叫HFile。列族需要在表创建时就定义好，并且修改的不能太频繁，数量也不能太多。

所有的行和列都会通过列族在表中定义，每一个单元格的值都具有时间戳，默认可由系统指定，也可以由用户显示设置。时间戳可以被用来区分不同的版本值，一个单元格的不同版本的值按照降序排列，访问时可优先读取最新的值。用户可以指定每个值所保存的最大版本的分数。如此，Hbase可以总结为：按照BigTable模型实现的，一个稀疏的、分布式的、持久化的、多维映射结构并由行健、列和时间戳索引的数据存储。由上可知，我们可以根据其维度存读数据：

    [Table, RowKey, Family, Column, Timestamp]  --> Value

加入时间戳，其数逻辑结构可表现为下图：

   行数据的存取操作是原子的，可以读写任何数目的列，目前尚不支持跨行事物和跨表事物，即Hbase具有强一致性。

 

   Hbase中扩展和负载均衡的基本单元成为region，region本质上是以行健排序的连续存储的区间。如果region太大，系统就会把它们动态拆分，相反地，也可以把多个region合并，以减少存储文件数量。Hbase中的region可以被分配到若干物理服务器上以均摊负载，因此提供了较强的扩展性。

   一张表初始时只有一个region，用户开始向表中插入数据时，系统会检查这个region的大小，以确保其不超过配置的最大值。如果超过了限制，系统会在中间键处将这个region拆分为两个大小大致相等的子region。每一个region只能由一台region服务器加载，每一台region服务器可以同时加载多个region。region服务器加载region集合的逻辑视图如下：

BigTable的论文指出，每台服务器中region的最佳加载数量是10-1000，每个region的最佳大小是100MB-200MB，这个标准是以2006年的硬件配置为基准参数建议的。按照Hbase和现在的硬件能力，每台服务器的最佳加载数量还是10-1000，但每个region的最佳大小可达到1GB-2GB。

   region拆分和服务相当于自动分区功能，当一个服务器出现故障以后，该服务器上的region可以快速回复，并获得细粒度的负载均衡，因为当加载某个region的服务器负载过大、发生错误或者被停止使用导致region不可用时，系统会将该regino转移到其他服务器上。

4. API

   Hbase的API提供了建表、删表、增加列族和删除列族操作，同时还提供了修改表和列族元数据的功能。此外，它还提供了客户端对给定的行健值进行增、删、查操作。Hbase在0.91.0版本中加入了协处理器。

   最后，系统通过提供包装器集成了MapReduce框架，将表转换成MapReduce作业的输入源和输出目标。

   与RDBMS不同的是，Hbase没有提供特定的类SQL的查询语言，数据存储都以API的形式进行操作。

5. Hbase的数据存储

   Hbase数据存储在存储文件中，成为Hfile，Hfile中存储的是经过排序的键值映射结构。文件内部由连续的块组成，块的索引信息存储在文件的尾部。当把Hfile打开并加载到内存中时，索引信息会有限加载到内存中，每个块的默认大小是64KB，可以根据需要进行配置。

   每个Hfile都有一个块索引，通过一个磁盘查找就可以实现查询。首先在内存的块索引中进行二分查找，确定可能包含给定键的块，然后读取磁盘找到实际要找的键。存储文件通常保存在Hadoop分布式文件系统(HDFS)中，HDFS提供了一个可扩展的、持久的、冗余的Hbase存储层。存储文件通过将更改写入到可配置数据的物理服务器中，以保证不丢失数据。每次更新数据时，都会先将数据记录在提交日志（commit log）中，在Hbase中这叫做预写日志（write-ahead log，WAL），然后才会将这些数据写入内存中的memstore中。一旦内存保存的写入数据的累计大小超过了一个给定的最大值，系统就会将这些数据移出内存作为Hfile文件刷写到磁盘中。数据移出内存之后，系统会丢弃对应的提交日志，只保留未持久化到磁盘中的提交日志。在系统将数据移出memstore写入磁盘的过程中，可以不必阻塞系统的读写，通过滚动内存中的memstore就能实现这个目的，即用空的新memstore获取更新数据，将满的旧memstore转换成一个文件。此处须注意的是，memstore中的数据已经按照行健排序，持久化在磁盘的Hfile也是按照这个顺序排列的，所有不需要进行排序或其他处理。

   因为存储文件是不可改变的，所以无法通过移除某个键/值来简单地删除值，可行的办法是做个删除标记（delete marker，又称墓碑标记），表明给定行已被删除的事实。在检索的过程中，客户端读不到被标记的数据。

   读回的数据是两部分数据合并的结果，一部分是memstore中还没有写入磁盘的数据，另一部分是磁盘上的存储文件。值得注意的是，数据检索时用不着WAL，只有服务器内存中的数据在服务器崩溃前没有写入到磁盘，而后需要进行数据恢复时才会用到WAL。

   随着memstore中的数据不断刷写到磁盘中，会产生越来越多的Hfile文件，Hbase内部有一个解决这个问题的管家机制，即合并--将多个文件合并成一个较大的文件。合并有两种类型：minor合并（minor compaction）和major压缩合并（major compaction）。minor合并将多个小文件重写成数量较少的大文件，减少存储文件的数量。由于Hfile的每个文件都经过归类排序，所以合并速度极快，只受到磁盘I/O的影响。major合并将一个region中一根列族的若干个Hfile重写为一个新Hfile，与minor合并相比，它还有一个更独特的功能：major合并能扫描所有的键值对，顺序重写全部的数据，重写数据的过程中会忽略做了删除标记的数据。断言删除此时生效。

   Hbase中有三个主要组件：客户端、一台主服务器、多台region服务器。我们可以动态增加和移除服务器，以适应不断变化的负载。主服务器主要负责利用zookeeper为region服务器分配region。Apache zookeeper是一个可靠的、高可用的、持久化的分布式协调系统。

   master服务器负责夸region服务器的全局region的负载均衡，将繁忙的服务器中的region移动到负载较轻的服务器中。主服务器不是实际数据存储或检索路径的组成部分，它仅提供了负载均衡和集群管理，不为region服务器或客户端提供任何的数据服务。此外，主服务器还提供了元数据的管理操作，例如建表和删除列族。

   region服务器负责为他们服务器的region提供读写请求，也提供了拆分超过配置大小的region的接口。客户端则直接与region服务器通信，处理所有数据相关的操作。

 

注：

本系列总结来自于《Hbase权威指南》和《Hbase实战》两书，仅作学习交流使用，不得用于任何商业性的用途。

下一节：Hbase的关键配置和设置--2