深刻学习HBase架构原理

HBase定义

        HBase 是一个高可靠、高性能、面向列、可伸缩的分布式存储系统，利用Hbase技术可在廉价PC Server上搭建 大规模结构化存储集群。

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

HBase 的特色

        HBase 中的表通常有如下特色。

        1)大：一个表能够有上亿行，上百万列。

        2)面向列：面向列表（簇）的存储和权限控制，列（簇）独立检索。

        3)稀疏：对于为空（NULL）的列，并不占用存储空间，所以，表能够设计的很是稀疏。

HBase 访问接口

        HBase 支持不少种访问，访问HBase的常见接口以下。

        一、Native Java API，最常规和高效的访问方式，适合Hadoop MapReduce Job并行批处理HBase表数据。

        二、HBase Shell，HBase的命令行工具，最简单的接口，适合HBase管理使用。

        三、Thrift Gateway，利用Thrift序列化技术，支持C++，PHP，Python等多种语言，适合其余异构系统在线访问HBase表数据。

        四、REST Gateway，支持REST 风格的Http API访问HBase, 解除了语言限制。

        五、Pig，可使用Pig Latin流式编程语言来操做HBase中的数据，和Hive相似，本质最终也是编译成MapReduce Job来处理HBase表数据，适合作数据统计。

        六、Hive，当前Hive的Release版本尚没有加入对HBase的支持，但在下一个版本Hive 0.7.0中将会支持HBase，可使用相似SQL语言来访问HBase。

HBase 存储结构

        从HBase的架构图上能够看出，HBase中的存储包括HMaster、HRegionServer、HRegion、Store、MemStore、StoreFile、HFile、HLog等，本课程统一介绍他们的做用即存储结构。 如下是 HBase 存储架构图:

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

HMaster

        一、 为Region server分配region。

        二、 负责Region server的负载均衡。

        三、发现失效的Region server并从新分配其上的region。

        四、 HDFS上的垃圾文件回收。

        五、 处理schema更新请求。

HRegionServer

        一、 维护master分配给他的region，处理对这些region的io请求。

        二、 负责切分正在运行过程当中变的过大的region。

        能够看到，client访问hbase上的数据并不须要master参与（寻址访问zookeeper和region server，数据读写访问region server），master仅仅维护table和region的元数据信息（table的元数据信息保存在zookeeper上），负载很低。 HRegionServer存取一个子表时，会建立一个HRegion对象，而后对表的每一个列族建立一个Store实例，每一个Store都会有一个MemStore和0个或多个StoreFile与之对应，每一个StoreFile都会对应一个HFile， HFile就是实际的存储文件。所以，一个HRegion有多少个列族就有多少个Store。 一个HRegionServer会有多个HRegion和一个HLog。

HRegion

        table在行的方向上分隔为多个Region。Region是HBase中分布式存储和负载均衡的最小单元，即不一样的region能够分别在不一样的Region Server上，但同一个Region是不会拆分到多个server上。

        Region按大小分隔，每一个表通常是只有一个region。随着数据不断插入表，region不断增大，当region的某个列族达到一个阈值（默认256M）时就会分红两个新的region。

        每一个region由如下信息标识：

        一、< 表名,startRowkey,建立时间>

        二、由目录表(-ROOT-和.META.)记录该region的endRowkey

        HRegion定位：Region被分配给哪一个Region Server是彻底动态的，因此须要机制来定位Region具体在哪一个region server。

        HBase使用三层结构来定位region：

        一、 经过zk里的文件/hbase/rs获得-ROOT-表的位置。-ROOT-表只有一个region。

        二、经过-ROOT-表查找.META.表的第一个表中相应的region的位置。其实-ROOT-表是.META.表的第一个region；.META.表中的每个region在-ROOT-表中都是一行记录。

        三、经过.META.表找到所要的用户表region的位置。用户表中的每一个region在.META.表中都是一行记录。

        -ROOT-表永远不会被分隔为多个region，保证了最多须要三次跳转，就能定位到任意的region。client会将查询的位置信息保存缓存起来，缓存不会主动失效，所以若是client上的缓存所有失效，则须要进行6次网络来回，才能定位到正确的region，其中三次用来发现缓存失效，另外三次用来获取位置信息。

　　　　table 和region 的关系

　　　　　　table 默认最初只有一个region，随着记录数的不断增长而变大，起初的region会逐渐分裂成多个region，一个region有【startkey，endkey】表示，不一样的region会被master分配给相应的regionserver管理

 

　　　　　　region 是hbase分布式存储和负载均衡的最小单元，不一样的region分不到不一样的regionserver

 

　　　　注意：region 虽然是分布式存储的最小单元，但并非存储的最小单元

　　　　　　region 是由一个或者多个store 组成的，每一个store就是一个 column family

　　　　　　每一个stroe 又由一个memstore 和 1至多个store file组成（memstore 到一个阈值会刷新，写入到storefile，有hlog 来保证数据的安全性，一个 regionserver 有且只有一个hlog）

 

Store

       每个region由一个或多个store组成，至少是一个store，hbase会把一块儿访问的数据放在一个store里面，即为每一个ColumnFamily建一个store，若是有几个ColumnFamily，也就有几个Store。一个Store由一个memStore和0或者多个StoreFile组成。 HBase以store的大小来判断是否须要切分region。

MemStore

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

StoreFile

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

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进行压缩和解压缩。目标HFile的压缩支持两种方式：gzip、lzo。

         另外，针对目前针对现有HFile的两个主要缺陷：

        a) 占用过多内存

        b) 启动加载时间缓慢

        基于此缺陷，提出了HFile Version2设计。

HLog

        其实HLog文件就是一个普通的Hadoop Sequence File， Sequence File的value是key时HLogKey对象，其中记录了写入数据的归属信息，除了table和region名字外，还同时包括sequence number和timestamp，timestamp是写入时间，sequence number的起始值为0，或者是最近一次存入文件系统中的sequence number。 Sequence File的value是HBase的KeyValue对象，即对应HFile中的KeyValue。

        HLog(WAL log)：WAL意为write ahead log，用来作灾难恢复使用，HLog记录数据的全部变动，一旦region server 宕机，就能够从log中进行恢复。

LogFlusher

         前面提到，数据以KeyValue形式到达HRegionServer，将写入WAL以后，写入一个SequenceFile。看过去没问题，可是由于数据流在写入文件系统时，常常会缓存以提升性能。这样，有些本觉得在日志文件中的数据实际在内存中。这里，咱们提供了一个LogFlusher的类。它调用HLog.optionalSync(),后者根据 hbase.regionserver.optionallogflushinterval (默认是10秒)，按期调用Hlog.sync()。另外，HLog.doWrite()也会根据 hbase.regionserver.flushlogentries (默认100秒)按期调用Hlog.sync()。Sync() 自己调用HLog.Writer.sync()，它由SequenceFileLogWriter实现。

LogRoller

        Log的大小经过$HBASE_HOME/conf/hbase-site.xml 的 hbase.regionserver.logroll.period 限制，默认是一个小时。因此每60分钟，会打开一个新的log文件。长此以往，会有一大堆的文件须要维护。首先，LogRoller调用HLog.rollWriter()，定时滚动日志，以后，利用HLog.cleanOldLogs()能够清除旧的日志。它首先取得存储文件中的最大的sequence number，以后检查是否存在一个log全部的条目的“sequence number”均低于这个值，若是存在，将删除这个log。 每一个region server维护一个HLog，而不是每个region一个，这样不一样region（来自不一样的table）的日志会混在一块儿，这样作的目的是不断追加单个文件相对于同时写多个文件而言，能够减小磁盘寻址次数，所以能够提升table的写性能。带来麻烦的时，若是一个region server下线，为了恢复其上的region，须要将region server上的log进行拆分，而后分发到其余region server上进行恢复。

HBase 设计

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

        一、Row Key 是行在 BigTable 中的惟一标识。

        二、Time Stamp 是每次数据操做对应关联的时间戳，能够看作 SVN 的版本。

        三、Column 定义为< family>:< label>，经过这两部分能够指定惟一的数据的存储列，family 的定义和修改须要 对 HBase 进行相似于 DB 的 DDL 操做，而 label ，不须要定义直接可使用，这也为动态定制列提供了一种手段 。family 另外一个做用体如今物理存储优化读写操做上，同 family 的数据物理上保存的会比较临近，所以在业务设计的过程当中能够利用这个特性。

数据模型

        HBase 以表的形式存储数据。表由行和列组成。列划分为若干个列族（row family），以下图所示。

 

        一、 Row Key

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

        1)经过单个 Row Key 访问。

        2)经过 Row Key 的 range 全表扫描。

        3)Row Key 可使任意字符串（最大长度是64KB，实际应用中长度通常为 10 ~ 100bytes），在HBase 内部，Row Key 保存为字节数组。

        在存储时，数据按照 Row Key 的字典序（byte order）排序存储。设计 Key 时，要充分排序存储这个特性，将常常一块儿读取的行存储到一块儿（位置相关性）。

        注意 字典序对 int 排序的结果是 1，10,100,11,12,13,14,15,16,17,18,19,20,21，...， 9，91,92,93,94,95,96,97,98,99。要保存整形的天然序，Row Key 必须用 0 进行左填充。

        行的一次读写是原子操做（不论一次读写多少列）。这个设计决策可以使用户很容易理解程序在对同一个行进行并发更新操做时的行为。

        二、 列族

        HBase 表中的每一个列都归属于某个列族。列族是表的 Schema 的一部分（而列不是），必须在使用表以前定义。列名都以列族做为前缀，例如 courses:history、courses:math 都属于 courses 这个列族。

        访问控制、磁盘和内存的使用统计都是在列族层面进行的。在实际应用中，列族上的控制权限能帮助咱们管理不一样类型的应用， 例如，容许一些应用能够添加新的基本数据、一些应用能够读取基本数据并建立继承的列族、一些应用则只容许浏览数据（甚至可能由于隐私的缘由不能浏览全部数据）。

        三、 时间戳

        HBase 中经过 Row 和 Columns 肯定的一个存储单元称为 Cell。每一个 Cell 都保存着同一份数据的多个版本。 版本经过时间戳来索引，时间戳的类型是 64 位整型。时间戳能够由HBase（在数据写入时自动）赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也 能够由客户显示赋值。若是应用程序要避免数据版本冲突，就必须本身生成具备惟一性的时间戳。每一个 Cell 中，不一样版本的数据按照时间倒序排序，即最新的数据排在最前面。

        为了不数据存在过多版本形成的管理（包括存储和索引）负担，HBase 提供了两种数据版本回收方式。 一是保存数据的最后 n 个版本，二是保存最近一段时间内的版本（好比最近七天）。用户能够针对每一个列族进行设置。

        四、 Cell

        Cell 是由 {row key，column(=< family> + < label>)，version} 惟一肯定的单元。Cell 中的数据是没有类型的，所有是字节码形式存储。

物理存储

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

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

        StoreFile以HFile格式存储在HDFS中。