分布式结构化存储系统-HBase基本架构

　　　　　　　　　　　　　　分布式结构化存储系统-HBase基本架构

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰

版权声明：原创作品，谢绝转载！否则将追究法律责任。

　　在大数据领域中，除了直接以文件形式保存数据外，还有大量结构化和半结构化的数据，这类数据通常需要支持更新操作，比如随机插入和删除，这使得分布式文件系统HDFS很难满足要求。

　　为了方便用户存取海量的结构化和半结构化数据，HBase应运而生。它是一个分布式列式存储系统，具有良好的扩展性，容错性以及易用的API。HBase是构建在分布式文件系统之上的，支持随机插入和删除的列族式存储系统，它可被简单理解为一个具有持久化能力的分布式多维有序映射表。

　　尽管HBase随机读写性能较高，但数据扫描速度较慢，难以适用于OLAP场景，为此，Cloudera提出了Kudu项目，他能很好的坚固吞吐率和延迟。

一.分布式结构化存储系统背景

    长久以来，传统关系型数据库（比如MySQL）因其易懂的关系模型，高效的查询引擎和易用的查询语言二倍广泛应用与大量数据存储和处理场景中，但在一些互联网应用场景中，数据量膨胀速度过快，基于关系型数据库的方案很难满足系统扩展性需求。

    具有关资料显示，Facebook在2010年时，MySQL实例数据已经达到4000（在业务层进行数据分片）。为了更好的应对海量数据的扩容问题，需要引入扩展性极好的分布式存储系统，相比于关系型数据库，这类系统有以下几个特点：
        （1）极好的扩展性
　　　　　　　　　　随着数据量增加，架构应支持自动水平扩展以满足存储要求。
        （2）弱化ACID需求
　　　　　　　　　　关系型数据库的一个有点是支持ACID，而在不少大数据应用场景中，对事务的要求较低，可选择支持。

        （3）良好的容错性
　　　　　　　　　　大数据存储应用倾向于选择成本较低的横向扩展方案，这就要求数据存储软件具有良好的故障和自动处理能力。
　　
　　HBase便是为了满足以上阿几个特点而设计的分布式结构化存储系统，它是Google的BigTable的开源实现，具有良好的扩展性和容错性，非常适合存储海量结构化或半结构化数据。 

二.HBase数据模型

    接下来我们将从两个方面介绍HBase数据模型：逻辑数据模型和物理数据存储，其中逻辑数据模型是用户从数据库所看到的模型，它直接与HBase数据建模相关；物理数据模型是面向计算机物理表示的模型，描述了HBase数据在存储介质（包括内存和磁盘）上的组织结构。

1>.逻辑数据模型

    类似于数据库中的database和table逻辑概念，HBase将之称为namespace和table，一个namespace中包含一组table，HBase内置了两个默认的namespace：
        hbase：
　　　　　　　　系统内建表，包括namespace和meta表。
        default：
　　　　　　　　用户创建时未指定namespace的表都创建在此。
　　

　　HBase表由一个系列行构成，每行数据有一个rowkey，以及若干column family构成，每个column family可包含无限制，具体如上图所示。
　　　　（1）rowkey：
　　　　　　　　HBase表中的数据是以rowkey作为标识的，rowkey类似于关系型数据库中的“主键”，每行数据有一个rowkey，唯一标识该行，是定位该行数据的索引。同一张表内，rowkey是全局有序的。rowkey是没有数据类型的，以字节数组(byte[])形式保存。rowkey可以支持64k的存储空间。

　　　　（2）column family：
　　　　　　　　HBase表中数据是按照colum family组织的，每行数据拥有相同大的column family属于schema的一部分，定义表时必须指定好，但每个column family可包含无数个动态列。column family是访问控制的基本单位，同一个column family中的数据在物理上会存储在一个文件中。column family名称的类型是字符串，由一系列组合Linux路径名称规划的字符构成。

　　　　（3）column qualifier:
　　　　　　　　column family内部列标识，HBase每列数据可通过family:qualifier（比如CF1:col1）唯一标识，qualifier不属于schema的一部分，可以动态指定，且每行数据可以有不同的quealifier。跟rowkey一样，column qualifier也是没有数据类型的，以字节数(byte[])组形式存储。

　　　　（4）cell：
　　　　　　　　通过rowkey，colum family和column qualifier可唯一定位一个cell，它内部保存了多个版本的数值，默认情况下，每个数值的版本号是写入时间戳。cell内的数值也是没有数据类型的，以数组形式保存。

　　　　（5）timestamp：
　　　　　　　　cell内部的数据是多版本的，默认将写入时间戳作为版本号，用户可根据自己的业务需求设置版本号（数据类型为log）。每个column family保存最大版本数可单独配置，默认是3，如果读数据时未指定版本号，HBase只会返回最新版本的数值；如果一个cell内数据数目超过最大版本数，则旧的版本将自动被删除。

    可从另外一个角度理解HBase的逻辑数据模型：将HBase表看出一个有序多维映射表，比如将第一张图中所示的数据可表示成第二张图所示的多维度映射表。

    HBase也可以看作是一个key/value存储系统，其中，rowkey是key，其他部分是value，也可以将[row key,column family,column qualifier, timestamp]看作key，Cell中的值对应value，举例如下：
　　　　axx -> {CF1:{A:{timestamp1:val}},
　　　　　　　　　CF2:{col A:{timestampl:val1,timestamp2:val2},col C:{timestamp1:val}}　}
　　　　axx,CF1,col A,timestamp1 -> val
　　　　axx,CF2,col A,timestamp1 -> val1
　　　　axx,CF2,col A,timestamp2 -> val2
　　　　axx,CF2,col A,timestamp1 -> val

2>.物理数据模型

　　HBase是列族式存储引擎，它以column family为单位存储数据，每个column family内部数据是以key value格式保存的，key value组成如下：
　　　　[row key,column family,column qualifier,timestamp] => value

　　数据存储在存储介质中按照如下图所示的形式保存。

    从格式上可以看出，每行数据中不同版本的cell value会重复保存rowkey，colum family和colum qualifier，因此，为了节省存储空间，这几个字段值在保证业务易理解的前提下，应尽可能段。

    在HBase中，同一表中的数据是按照rowkey升序排列的，同一行中的不同列是按照column qualifier升序排列的，同一cell中的数值是按照版本好（时间戳）降序排列的，如下图所示为一个HBase表从逻辑视图到物理视图的映射。

3>.HBase是列式存储引擎吗？

　　列式存储格式是指以列为单位存储数据的存储格式，相比于传统的行式存储格式，它具有压缩比高，读取IO少（此处指可避免无意义的IO）等优点，目前被广泛应用于各种存储引擎中。

　　对于HBase而言，它并不是一个列式存储引擎，而是列簇式存储引擎，即同一列簇中的数据会单独存储，但列簇内数据是行式存储的。为了将HBase改造成列式存储引擎，进一步提高读写性能，Cloudera公司开源了分布式数据库Kudu。

　　　　
　　Kudu官网：https://kudu.apache.org/。

三.HBase基本架构

    为了将数据分布到集群中以提供并行读写服务，HBase按照rowkey将数据划分成多个固定大小的有序分区，每个分区被称为一个“region”，这些“region”会被均衡地存放在不用节点上。

    HBase是构建在HDFS之上的，所有的“region”均会以文件的形式保存到HDFS上，以保存这些数据的高可靠存储。

    HBase采用了经典的master/slave架构，如上图所示，与HDFS不同的是，它的master与slave不直接互联，而是通过引入zookeeper让两类服务解耦，这使得HBase master变得完全无状态，进而避免了master宕机导致整个集群不可用，HBase各个服务功能如下：

1>.Hmaster

    HMaster可以存在多个，主HMaster由zookeeper动态选举产生，当主HMaster出现故障后，系统可由zookeeper动态选举出新的HMaster接管。HMaster本身是五状态的（所有状态信息均保存在zookeeper中），主HMaster挂掉后，不会影响正常的读写服务。HMaster主要有以下职责：
　　　　（1）协调RegionServer
　　　　　　　　包括为RegionServer为分配region，均衡各RegionServer的负载，发现失效的RegionServer并重新分配其上的region。

　　　　（2）元信息管理
　　　　　　　　为用户提供table的增删该查操作。Client读写操作过程是不需要与HMaster进行交互的，而是直接与RegionServer通信来完成。

2>.RegionServer

　　RegionServer负责单个Region的存储和管理（比如Region切分），并与Clinet交互，处理读写请求。

3>.zookeeper

    zookeeper内部存储这有关HBase的重要元信息和状态信息，担任着Master与RegionServer之间的服务协调角色，具体职责如下：
        （1）保证任何适合，集群中只有一个master；
        （2）存储所有Region的寻址入口；
        （3）实时监控Region Server的上线和下线信息，并实时通报给Master；
        （4）存储HBase的schema和table元数据。

4>.Client

    Client提供HBase访问接口，与RegionServer交互读写数据，并维护cache加快对HBase的访问速度。

四.HBase内部原理

    HBase是构建在HDFS之上的，它利用HDFS可靠性存储数据文件，其内部则包含Region定位，读写流程管理和文件管理等实现。接下里我们就从这几个方面来剖析一下啊HBase内部原理。

1>.Region定位

    HBase支持put,get,delete和scan等基础操作，所有这些操作等基础是region定位：给定一个rowkey或rowkey区间，如何获取rowkey所在等RegionServer地址？

    如上图所示，region定位基本步骤如下：
　　　　（1）客户端与zookeeper交互，找到hbase:meta系统表所在的RegionServer，hbase：meta表维护了每个哟哦那个户表中rowkey区间的Region存放位置的映射关系，具体如下：
　　　　　　　　rowkey:table name,start key,region id，value:RegioServer对象（保存了RegionServer位置信息等）
　　　　（2）客户端与hbase:meta系统表所在RegionServer交互，获取rowkey所在等RegionServer。
　　　　（3）客户端与rowkey所在的RegionServer交互，执行该rowkey相关操作。

　　需要注意的是，客户端首次执行读写操作时才需要定位hbase:meta表的位置，之后将其缓存到本地，除非因region移动导致缓存失效，客户端才会重新读取hbase:meta表位置，并更新缓存。

　　关于hbase:meta表的说明：HBase 0.96.0之前版本存在两个系统表，分别为“-ROOT-”和“.META”，其中“-ROOT-”表记录了“.META”表的位置信息，但考虑到“.META”表只有一个region足够，从0.96.0版本开始，”-ROOT-“表被移除，”.META.“表被重命名为hbase:meta。　　　　

2>.RegionServer内部关键组件

    RegionServer内部关键组件如上图所示，其主要功能如下：
　　　　（1）BlockCache
　　　　　　　　读缓存，负责缓存频繁读取的数据，采用了LRU置换策略。
　　　　（2）MemsStore
　　　　　　　　写缓存，负责暂时缓存未写入磁盘的数据，并在写入磁盘前对数据排序。每个region内的每个column family拥有一个Memstore。
　　　　（3）HFile
　　　　　　　　一种支持多级索引的数据存储格式，用户保存HBase表中实际的数据。所有的HFile均保存在HDFS中。　　
　　　　（4）WAL　　
　　　　　　　　即Write Ahead Log，保存在HDFS上的日志文件，用户保存那些为持久化到HDFS的HBase数据，以便RegionServer宕机后恢复这些数据。
　

3>.RegionServer读写操作

　　HBase中最重要的两个操作是写操作和读操作，如上图所示。具体流程如下：

　　写流程
　　　　为了提升HBase写效率，避免随机写性能地下，RegionServer将所有收到的请求暂时写入内存，之后在顺序刷新到磁盘上，进而将随机写转换成顺序写以提升性能，具体流程如下：
            （1）RegionServer收到写请求后，将写入的数据以追加的方式写入HDFS上的日志文件，该日志文件被成为“Write Ahead Log”（WAL）。WAL主要作用是当RegionServer突然宕机后重新恢复丢失的数据。
            （2）RegionServer将数据写入内存数据结构MemStore中，之后通知客户端数据写入成功。当Memesotre所占内存达到一定阈值后，RegionServer会将数据顺序刷新到HDFS中，保存成HFile（一种多级索引的文件格式）格式的文件。

　　读流程
　　　　由于写历程可能使数据位于内存或者磁盘上，因此读取数据时，需要从多个数据存放位置中寻找数据，包括读缓存BlockCache，写缓存Memstore，以及磁盘上的HFile文件（可能有多个），并将读到的数据合并在一起返回给用户，具体流程如下：
　　　　　　　（1）扫描器查找读缓存BlockCache，它内部缓存了最近读取过的数据。
　　　　　　　（2）扫描器查找写缓存MemStore，它内部缓存了最近写入的数据。
　　　　　　　（3）如果在BlockCache和MemStore中未找到目标数据，HBase将读取HFile中的数据，以获取需要的数据。

4>.Memstore与HFile组织结构

    MemStore负责将最近写入的数据缓存到内存中，它是一个有序key/Value内存存储格式，每个colum family拥有一个MemStore，它的格式如下图所示。

    MemStore中的数据量达到一定阈值后，会被刷新到HDFS文件中，保存成HFile格式。HFile是Google SSTable（Sorted String Table，Google BigTable中用到的存储格式）的开源实现，他是一种有序key/Value磁盘存储格式，带有多级索引，以便定位数据，HFile中的多级索引类似于B+树。

    HFile格式可参考官方链接：https://hbase.apache.org/book.html#_hfile_format_2。

    HFile如上图所示。
        （1）数据按照key以升序排列；
        （2）文件由若干64KB的block构成，每个block包含一系列Key/Value；
        （3）每个block拥有自己的索引，称为“leaf index”，索引是按照key构建的；
        （4）每个block的最后一个key被放到“intermediate index”中；
        （5）每个HFile文件包含一个“root index”，指向“intermediate index”；
        （6）每个文件末尾包含一个trailer域，记录了block meta，bloom filter等信息。