HBase(一): HBase体系结构（1)

一、什么是HBase

       HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建大规模结构化的存储集群。HBase的目标是存储并处理大型数据，具体来说是仅需使用普通的硬件配置，就能够处理由成千上万的行和列所组成的大型数据。

        HBase是Google BigTable的开源实现，与Google BigTable利用GFS作为其文件存储系统类似，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理BigTable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；Google BigTable利用Chubby作为协同服务，HBase利用Zookeeper作为协同服务。
       

       与MapReduce的离线批处理计算框架不同，HBase是一个可以随机访问的存储和检索数据平台，弥补了HDFS不能随机访问数据的缺陷，适合实时性要求不是非常高的业务场景。HBase存储的都是Byte数组，它不介意数据类型，允许动态、灵活的数据模型。

       其中HBase位于结构化存储层，HDFS为HBase提供了高可靠性的底层存储支持， MapReduce为HBase提供了高性能的批处理能力，Zookeeper为HBase提供了稳定服务和failover机制，Pig和Hive为HBase提供了进行数据统计处理的高层语言支持，Sqoop则为HBase提供了便捷的RDBMS数据导入功能，使业务数据从传统数据库向HBase迁移变的非常方便。

二、HBase设计模型

       HBase中的每一张表就是所谓的BigTable。BigTable会存储一系列的行记录，行记录有三个基本类型的定义：

• RowKey

            是行在BigTable中的唯一标识。

• TimeStamp：

            是每一次数据操作对应关联的时间戳，可以看作SVN的版本。

• Column：

            定义为<family>:<label>，通过这两部分可以指定唯一的数据的存储列，family的定义和修改需要对HBase进行类似于DB的DDL操作。而label，不需要定义直接可以使用，这也为动态定制列提供了一种手段。family另一个作用体现在物理存储优化读写操作上，同 family 的数据物理上保存的会比较接近，因此在业务设计的过程中可以利用这个特性。

       1. 逻辑存储模型

        HBase以表的形式存储数据，表由行和列组成。列划分为若干个列簇，如下图所示：

         

       下面是对表中元素的详细解析：

        RowKey

            与NoSQL数据库一样，rowkey是用来检索记录的主键。访问HBase Table中的行，只有三种方式：

• 通过单个rowkey访问

• 通过rowkey的range

• 全表扫描        

          rowkey行键可以任意字符串（最大长度64KB，实际应用中长度一般为10-100bytes），在HBase内部RowKey保存为字节数组。存储时，数据按照RowKey的字典序（byte order）排序存储，设计key时，要充分了解这个特性，将经常一起读取的行存放在一起。需要注意的是：行的一次读写是原子操作（不论一次读写多少列）

        列簇

            HBase表中的每个列，都归属于某个列簇，列簇是表的 schema 的一部分（而列不是），必须在使用表之前定义。列名都以列簇作为前缀。例如：

            courses:history,  courses:math 都属于 courses 这个列簇。

            访问控制，磁盘和内存的使用统计都是在列簇层面进行的。

            实际应用中，列簇上的控制权限能帮助我们管理不同类型的应用：我们允许一些应用可以添加新的基本数据、 一些应用可以读取基本数据并创建继承的列簇、一些应用则只允许浏览数据（设置可能因为隐私的原因不能浏览所有数据）。

 

        时间戳

            HBase中通过row和columns确定的为一个存储单元称为cell。每个cell都保存着同一份数据的多个版本。版本通过时间戳来索引。

            时间戳的类型是64位整型。时间戳可以由HBase在写入时自动赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显示赋值。

            如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个cell中在不同版本的数据按照时间倒序排序，即最新的数据排在最前面。

            为了避免数据存在过多的版本造成的管理负担，HBase提供了两种数据版本回收方式。一是保存数据的最后 n个版本，二是保存最近一段时间内的版本（比如最近七天）。用户可以针对每个列簇进行设置。

 

        Cell

            由{row key, column(=+), version} 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存储。

 

 

       2. 物理存储模型

 

        Table在行的方向上分割为多个HRegion，每个HRegion分散在不同的RegionServer中。

    

            

 

        每个HRegion由多个Store构成，每个Store由一个MemStore和0或多个StoreFile组成，每个Store保存一个Columns Family

 

            

 

        StoreFile以HFile格式存储在HDFS中。

 

三、HBase存储架构

 

3.1 设计思路

       HBase是一个分布式的数据库，使用Zookeeper管理集群，使用HDFS作为底层存储。在架构层面上由HMaster（Zookeeper选举产生的Leader）和多个HRegionServer组成

       在HBase的概念中，HRegionServer对应集群中的一个节点，一个HRegionServer负责管理多个HRegion，而一个HRegion代表一张表的一部分数据。在HBase中，一张表可能会需要很多个HRegion来存储数据，每个HRegion中的数据并不是杂乱无章的。HBase在管理HRegion的时候会给每个HRegion定义一个Rowkey的范围，落在特定范围内的数据将交给特定的Region，从而将负载分摊到多个节点，这样就充分利用了分布式的优点和特性。另外，HBase会自动调节Region所处的位置，如果一个HRegionServer过热，即大量的请求落在这个HRegionServer管理的HRegion上，HBase就会把HRegion移动到相对空闲的其它节点，依次保证集群环境被充分利用。

 

2.2 基本架构

       HBase由HMaster和HRegionServer组成，同样遵从主从服务器架构。HBase将逻辑上的表划分成多个数据块即HRegion，存储在HRegionServer中。HMaster负责管理所有的HRegionServer，它本身并不存储任何数据，而只是存储数据到HRegionServer的映射关系（元数据）。集群中的所有节点通过Zookeeper进行协调，并处理HBase运行期间可能遇到的各种问题。HBase中的存储包括HMaster、HRegionSever、HRegion、HLog、Store、MemStore、StoreFile、HFile等，HBase的基本架构如下图所示：

 

       

  

Client：

       使用HBase的RPC机制与HMaster和HRegionServer进行通信，提交请求和获取结果。对于管理类操作，Client与HMaster进行RPC；对于数据读写类操作，Client与HRegionServer进行RPC。

HMaster：

       管理所有的HRegionServer，告诉其需要维护哪些HRegion，并监控所有HRegionServer的运行状态。当一个新的HRegionServer登录到HMaster时，HMaster会告诉它等待分配数据；而当某个HRegion死机时，HMaster会把它负责的所有HRegion标记为未分配，然后再把它们分配到其他HRegionServer中。HMaster没有单点问题，HBase可以启动多个HMaster，通过Zookeeper的选举机制保证集群中总有一个HMaster运行，从而提高了集群的可用性。

  HBase中的每张表都通过键按照一定的范围被分割成多个子表（HRegion），默认一个HRegion超过256M就要被分割成两个，这个过程由HRegionServer管理，而HRegion的分配由HMaster管理。

    HMaster的作用：

• 为HRegionServer分配HRegion
• 负责HRegionServer的负载均衡
• 发现失效的HRegionServer并重新分配
• HDFS上的垃圾文件回收
• 处理Schema更新请求

HRegionServer：

       HBase中的所有数据从底层来说一般都是保存在HDFS中的，用户通过一系列HRegionServer获取这些数据。集群一个节点上一般只运行一个HRegionServer，且每一个区段的HRegion只会被一个HRegionServer维护。HRegionServer主要负责响应用户I/O请求，向HDFS文件系统读写数据，是HBase中最核心的模块。HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了逻辑表中的一个连续数据段。HRegion由多个HStore组成，每个HStore对应了逻辑表中的一个列族的存储，可以看出每个列族其实就是一个集中的存储单元。因此，为了提高操作效率，最好将具备共同I/O特性的列放在一个列族中。

 HRegionServer的作用：

• 维护HMaster分配给它的HRegion，处理对这些HRegion的IO请求
• 负责切分正在运行过程中变得过大的HRegion

        可以看到，Client访问HBase上的数据并不需要HMaster参与，寻址访问ZooKeeper和HRegionServer，数据读写访问HRegionServer。HMaster仅仅维护 Table 和 Region 的元数据信息，Table的元数据信息保存在ZooKeeper上，负载很低。HRegionServer 存取一个子表时，会创建一个HRegion对象，然后对表的每个列簇创建一个Store对象，每个Store都会有一个MemStore和0或多个StoreFile与之对应，每个StoreFile都会对应一个HFile，HFile就是实际的存储文件。因此，一个HRegion有多少列簇就有多少个Store。

          一个 HRegionServer 会有多个 HRegion 和一个 HLog。

HRegion：

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

 

HStore：

       它是HBase存储的核心，由MemStore和StoreFiles两部分组成。MemStore是内存缓冲区，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile），当StoreFile的文件数量增长到一定阈值后，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除操作。因此，可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的Compact过程中进行的，这样使得用户的写操作只要进入内存就可以立即返回，保证了HBaseI/O的高性能。当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前的HRegion Split成2个HRegion，父HRegion会下线，新分出的2个子HRegion会被HMaster分配到相应的HRegionServer，使得原先1个HRegion的负载压力分流到2个HRegion上。

 

HLog：

       每个HRegionServer中都有一个HLog对象，它是一个实现了Write Ahead Log的预写日志类。在每次用户操作将数据写入MemStore的时候，也会写一份数据到HLog文件中，HLog文件会定期滚动刷新，并删除旧的文件（已持久化到StoreFile中的数据）。当HMaster通过Zookeeper感知到某个HRegionServer意外终止时，HMaster首先会处理遗留的 HLog文件，将其中不同HRegion的HLog数据进行拆分，分别放到相应HRegion的目录下，然后再将失效的HRegion重新分配，领取到这些HRegion的HRegionServer在加载 HRegion的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后Flush到StoreFiles，完成数据恢复。

 

2.3 ROOT表和META表

       HBase的所有HRegion元数据被存储在.META.表中，随着HRegion的增多，.META.表中的数据也会增大，并分裂成多个新的HRegion。为了定位.META.表中各个HRegion的位置，把.META.表中所有HRegion的元数据保存在-ROOT-表中，最后由Zookeeper记录-ROOT-表的位置信息。所有客户端访问用户数据前，需要首先访问Zookeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，如下图所示。

 

                                    ROOT表和META表

       -ROOT-表永远不会被分割，它只有一个HRegion，这样可以保证最多只需要三次跳转就可以定位任意一个HRegion。为了加快访问速度，.META.表的所有HRegion全部保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据，则询问相关.META.表的Region服务器，试图获取数据的位置，如果还是失败，则询问-ROOT-表相关的.META.表在哪里。最后，如果前面的信息全部失效，则通过ZooKeeper重新定位HRegion的信息。所以如果客户端上的缓存全部是失效，则需要进行6次网络来回，才能定位到正确的HRegion。

 

    2.4 Store 

        每一个HRegion由一个或多个Store组成，至少是一个Store，HBase会把一起访问的数据放在一个Store里面，即为每个ColumnFamily建一个Store，如果有几个ColumnFamily，也就有几个Store。一个Store由一个MemStore和0或者多个StoreFile组成。 HBase以Store的大小来判断是否需要切分HRegion。

 

    2.4 MemStore

        MemStore 是放在内存里的，保存修改的数据即keyValues。当MemStore的大小达到一个阀值（默认64MB）时，MemStore会被Flush到文件，即生成一个快照。目前HBase会有一个线程来负责MemStore的Flush操作。

　　

    2.5 StoreFile 

　    MemStore内存中的数据写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。

 

    2.6 HFile

　　 HBase中KeyValue数据的存储格式，是Hadoop的二进制格式文件。 首先HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。Trailer中有指针指向其他数据块的起始点，FileInfo记录了文件的一些meta信息。Data Block是HBase IO的基本单元，为了提高效率，HRegionServer中有基于LRU的Block Cache机制。每个Data块的大小可以在创建一个Table的时候通过参数指定（默认块大小64KB），大号的Block有利于顺序Scan，小号的Block利于随机查询。每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成，

        Magic内容就是一些随机数字，目的是防止数据损坏，结构如下。 

　  

   

    HFile结构图如下： 

    

 

Data Block段用来保存表中的数据，这部分可以被压缩。 Meta Block段（可选的）用来保存用户自定义的kv段，可以被压缩。 FileInfo段用来保存HFile的元信息，不能被压缩，用户也可以在这一部分添加自己的元信息。 Data Block Index段（可选的）用来保存Meta Blcok的索引。 Trailer这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先读取Trailer，Trailer保存了每个段的起始位置(段的Magic Number用来做安全check)，然后，DataBlock Index会被读取到内存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个 block读取到内存中，再找到需要的key。DataBlock Index采用LRU机制淘汰。 HFile的Data Block，Meta Block通常采用压缩方式存储，压缩之后可以大大减少网络IO和磁盘IO，随之而来的开销当然是需要花费cpu进行压缩和解压缩。（备注： DataBlock Index的缺陷。 a) 占用过多内存　b) 启动加载时间缓慢）

 

2.7 HLog 

　　HLog(WAL log)：WAL意为write ahead log，用来做灾难恢复使用，HLog记录数据的所有变更，一旦region server 宕机，就可以从log中进行恢复。 

 

2.8 LogFlusher  

　　定期的将缓存中信息写入到日志文件中 。

2.9 LogRoller　 

　 　对日志文件进行管理维护。

 

四、HBase读写流程

 

                                   HRegionServer数据存储关系图

       上文提到，HBase使用MemStore和StoreFile存储对表的更新。数据在更新时首先写入HLog和MemStore。MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到Flush队列，由单独的线程Flush到磁盘上，成为一个StoreFile。与此同时，系统会在Zookeeper中记录一个CheckPoint，表示这个时刻之前的数据变更已经持久化了。当系统出现意外时，可能导致MemStore中的数据丢失，此时使用HLog来恢复CheckPoint之后的数据。

       StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定阈值后，就会进行一次合并操作,将对同一个key的修改合并到一起，形成一个大的StoreFile。当StoreFile的大小达到一定阈值后，又会对 StoreFile进行切分操作，等分为两个StoreFile。

 

4.1 写操作流程

1. Client通过Zookeeper的调度，向HRegionServer发出写数据请求，在HRegion中写数据。

2. 数据被写入HRegion的MemStore，直到MemStore达到预设阈值。

3. MemStore中的数据被Flush成一个StoreFile。

4. 随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除。

5. StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile。

6. 单个StoreFile大小超过一定阈值后，触发Split操作，把当前HRegion Split成2个新的HRegion。父HRegion会下线，新Split出的2个子HRegion会被HMaster分配到相应的HRegionServer 上，使得原先1个HRegion的压力得以分流到2个HRegion上。

 

4.2 读操作流程

1. client访问Zookeeper，查找-ROOT-表，获取.META.表信息。

2. 从.META.表查找，获取存放目标数据的HRegion信息，从而找到对应的HRegionServer。

3. 通过HRegionServer获取需要查找的数据。

4. HRegionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。

 

5 、HBase使用场景

半结构化或非结构化数据：

       对于数据结构字段不够确定或杂乱无章，很难按一个概念去进行抽取的数据适合用HBase。如随着业务发展需要存储更多的字段时，RDBMS需要停机维护更改表结构，而HBase支持动态增加。

记录非常稀疏：

       RDBMS的行有多少列是固定的，为空的列浪费了存储空间。而HBase为空的列不会被存储，这样既节省了空间又提高了读性能。

多版本数据：

       根据RowKey和列标识符定位到的Value可以有任意数量的版本值（时间戳不同），因此对于需要存储变动历史记录的数据，用HBase将非常方便。

超大数据量：

       当数据量越来越大，RDBMS数据库撑不住了，就出现了读写分离策略，通过一个Master专门负责写操作，多个Slave负责读操作，服务器成本倍增。随着压力增加，Master撑不住了，这时就要分库了，把关联不大的数据分开部署，一些join查询不能用了，需要借助中间层。随着数据量的进一步增加，一个表的记录越来越大，查询就变得很慢，于是又得搞分表，比如按ID取模分成多个表以减少单个表的记录数。经历过这些事的人都知道过程是多么的折腾。采用HBase就简单了，只需要在集群中加入新的节点即可，HBase会自动水平切分扩展，跟Hadoop的无缝集成保障了数据的可靠性（HDFS）和海量数据分析的高性能（MapReduce）。

 

6 、HBase的MapReduce

 

       HBase中Table和Region的关系，有些类似HDFS中File和Block的关系。由于HBase提供了配套的与MapReduce进行交互的API如TableInputFormat和TableOutputFormat，可以将HBase的数据表直接作为Hadoop MapReduce的输入和输出，从而方便了MapReduce应用程序的开发，基本不需要关注HBase系统自身的处理细节。