HBase基本概念（一）

HBase的基本定义

HBase是Apache Hadoop中的一个子项目，HBase依托于Hadoop的HDFS作为最基本存储基础单元，通过使用Hadoop的dfs工具就可以看到这些数据。存储文件夹的结构，还可以通过Map/Reduce的框架（算法）对HBase进行操作。

HB使用场景

HBase 不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库.所谓非结构化数据存储就是说HBase是基于列的而不是基于行的模式，这样方面读写你的大数据内容。

HBase是介于Map Entry(key & value)和DB Row之间的一种数据存储方式。就点有点类似于现在流行的Memcache，但不仅仅是简单的一个key对应一个 value，你很可能需要存储多个属性的数据结构，但没有传统数据库表中那么多的关联关系，这就是所谓的松散数据。

简单来说，你在HBase中的表创建的可以看做是一张很大的表，而这个表的属性可以根据需求去动态增加，在HBase中没有表与表之间关联查询。你只需要 告诉你的数据存储到Hbase的那个column families 就可以了，不需要指定它的具体类型：char,varchar,int,tinyint,text等等。但是你需要注意HBase中不包含事务此类的功 能。

Apache HBase 和Google Bigtable 有非常相似的地方，一个数据行拥有一个可选择的键和任意数量的列。表是疏松的存储的，因此用户可以给行定义各种不同的列，对于这样的功能在大项目中非常实用，可以简化设计和升级的成本。

Hbase与Hadoop的关系

1.HDFS为HBase提供高可靠底层存储支持

2.MapReduce为HBase提供高性能计算能力

3.HBase架构

HBase核心功能模块

Client-RPC

    客户端Client是整个HBase系统的入口

    客户端使用RPC远程过程调用协议与HMaster和RegionServer进行通信

    对于管理类操作Client与HMaster进行RPC通信

    对于数据读写类操作Client与RegionServer进行RPC交互

    客户端可以是多个，如JAVA API接口，SHELL 命令行接口 AVRO等

Zookeeper-Quorum,协调通信

    Zookeeper消息协调通信 

    Zookeeper是一个高可用的分布式数据管理与系统协调框架

    基于对Paxos算法的实现，使该框架保证了分布式环境中的一致性。

    HBase中 Zookeeper实例负责协调工作

        保证HBase中只有一个HMaster

        保存root region的位置 即存储所有region的寻址入口

        实时监控regionserver的状态，将regionserver的上线和下线信息实时通知给Master

        存储HBase的 schema，包括有哪些table，每个table有哪些column family

HMaster - table/region的管理

    管理用户对Table的增、删、改、查操作

    管理HReginServer的负载均衡，调整Region分布

    在Region Split后，负责新Region的分配

    在HRegionServer停机后，负责失效HRegionServer上的Regions迁移

HRegionServer 主要负责响应用户I/O，向HDFS读写数据，是HBase最核心的模块

    HRegionServer内部管理了一系列HRegion对象

    每个HRegion对应了Table中的一个Region

    HRegion中由多个HStore组成

    每个HStore对应了Table中的一个Column Family的存储

HRegionServer-HStore    

        HStore存储是HBase存储核心，其中由两部分组成

        MemStore:Stored Memory Buffer, 用户写入的数据首先会放入MemStore，

        StoreFile:当MemStore满了或者到了一定的时间以后会Flush成一个StoreFile（底层实现是HFile)

        当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile,合并过程中会进行版本合并和数据删除。

        HBase其实是有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，保证了HBase的高性能。

        StoreFile在触发Compact操作后，会逐步形成越大的StoreFile，当单个StoreFile大小超过一定阈值，会触发 Split操作，同时把当前 Region分裂成2个Region，父Region会下线，新分裂的2个字Region会被

HMaster分配到相应的HRegionServer上，使得原来的1个Region的负载压力得以分流到2个Region上。

HRegionServer-WAL

    client 向 regionserver端提交数据的时候，会优先写WAL日志（Hlog)，只有当WAL日志写成功后，client才会告诉提交数据成功，如果写WAL失败会告知客户端提交失败。

    一个regionserver上所有的region共享一个HLog,一次数据的提交首先写入WAL，在写入memstore,如果memstore数据丢失可以通过HLog 进行恢复

    实现了WAL类的叫做HLog，每个regionserver中都有一个HLog对象，每次操作写入数据到memstore时，也会写一份到HLog文件中，HLog文件定期会更新删除旧的文件（已经持久化到StoreFile中的数据）

HBase使用场景

    存储大量的数据（>TB）

    需要很高的写吞吐量

    大规模数据集很好性能的随机访问（按列）

    需要进行优雅的数据扩展

    结构化和半结构化的数据

    不需要全部的关系数据库特性，例如交叉列，交叉表，事务，连接等等。

    增量数据存储

    增量用户社交交互数据

    搜索引擎应用

  核心概念

列族不能过多的原因：

   1、 HBase的表由一到多个Region组成，Region是由一个到多个HStore组成的；HStore是由一个到多个StoreFile和一个MemStore组成，当单个StoreFile文件大小大于阈值时，会触发Split操作，同时把当前的Region分裂成2个Region。这样的话 如果之前Region有多个列族 而且 数据比例差别很大，这样的话很少的数据却要跨越不同的Region这样不方便查询。

    2、数据在写入的时候首先会写入到memstore中，当memstore满了以后才会flush到storefile中。如果列族过多，则flush的时间会很长。

META:记录了用户表的Region信息，META 可以有多个Region

ROOT:记录了META表的Region信息 ROOT只有一个Region

存储基本结构--元数据表

    Zookeeper 中记录了 -ROOT表的location

    META 表的Region全部保存在内存中   

    客户端会将查询过的位置信息缓存起来，且缓存不会主动失效 除非region信息发生变化

HBase工作流程

    新的客户端查找某个特定的行键

    首先要连接ZookeeperQurom

    从Zookeeper检索持有ROOT Region的服务器名，获得拥有root的Region的RegionServer，得到持有

    对应行键的META表Region的服务器名，操作结果都会被缓存下来

    查询META服务器，检索包含给定行键的Region所在的服务器，

    在启动Hbase时，Hmaster负责把Region分配给每个HRegionServer 包括 ROOT META。

HDFS文件

    HBase在HDFS上有一个可配置的根目录 “/home"

    使用hadoop fs -lsr / 来查看HBase存储到HDFS上的各种文件

        HBase文件可以分为两类

            一：是直接位于HBase根目录下面的文件

                日志文件，HLog实例处理的WAL文件

                表，每个表都有它自己的目录，位于HBase根目录下

            二：是位于目录下面的文件

                Region,在每个表目录内，每个列族都会有一个单独的目录

                通过Master的web UI 访问  http://Master:60010 TableRegions

Region 切分

    1，当一个Region内的存储文件大于 hbase.hregion.max.filesize时，该Region就需要split为两个，每个

          只持有原始Region一半的内容

    2，RegionServer通过在父Region内创建切分目录来完成，之后，它会关闭该Region,此Region就

           不在接收任何请求

    3，META 表会进行更新，指明该Region已经被切分，以及自Region分别的名称和位置信息

    4，原始Region最终会被清楚，会从META表中删除它

    5，Region切分条件的设置默认大小为 10G，根据实际情况可调整。

合并。

    MemStore的flush操作会逐步增加磁盘上的文件数目

    当数目足够多的时候，合并进程会将他们合并成规模更少但是更大的文件，当这些文件中最大的那个超过

    最大存储文件的大小，这时会触发一个Region切分过程

   小合并：

    小合并负责将一些小文件合并成一个更大的文件

     合并文件数hbase.hstore.compaction.min 默认值为3 

     一个小合并所包含的最大文件数10 hbase.hstore.compaction.max

     设置hbase.store.compaction.min.size(设定为该Region的对应的Memstore的flush容量大小）

          和hbase.hstore.xompaction.max.size(默认是Long.MAX_VALUE)来减少需要进行小合并的文件列表

     任何大于最大的compaction值的文件都会排除在外。最小的compaction值是作为阈值而不是一个限制            达到单词compaction允许的文件数上限之前，那些小于该阈值的文件都会被包含在内。

  大合并：

       他会将所有的文件合并成一个

       该过程的运行是通过执行合并检查自动确定的

        当MemStore被flush到磁盘，执行了compact或者major_compact命令或产生了相关API调用，

                或运行后台线程，就会触发该检查。

        如果用户调用magor_compact命令或者majorCompact()API调用都会强制大合并进行

        服务器通过查看距离上次大合并运行是否满足一定时间，默认是24小时，进而自动执行大合并操作

HFile（HBase File) 是 HBase使用的一种文件存储格式的抽象

    附带索引的数据格式

    HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级的包装，即StoreFile底层就是HFile

     

HFile附带索引的数据格式

    HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo

    Trailer中有指针指向其他数据块的起始点

    FileInfo中记录了文件的一些Meta信息，例如：AVG_KEY_LEN AVG_VALUE_LEN 等

    Data Index 和 Meta Index 块记录了 每个Data块和 Meta块的起始点。

    每个Data块除了开头的Megic以外就是一个个keyvalue对拼接而成，

    Megic内容就是一些随机数字，目的是防止数据损坏，

HFile中 keyvalue的底层结构

    HFile里面的每个keyvalue对就是一个简单的byte数组，但是这个byte数组里包含了很多项，并且有固定的结构，

    开始是两个固定长度的数值，分别表示Key的长度和value的长度

    Key: 开始是固定长度的数值，表示RowKey的长度，RowKey，然后固定长度的数值，表示Family长度，然后是Family,qualifier,两个固定长度值，表示Time stamp 和 sky的type(put/delete)

    value 部分没有这个复杂的结构，就是纯粹的二进制数据

客户端流程解析：

    1、用户提交put请求后，HBase客户端会将put请求添加到本地buffer中，符合一定条件就会通过

    AsyncProcess一部批量提交。HBase默认设置autoflush=true,表示put请求直接回提交给服务器进行处理

    用户可以设置autoflush=false，这样的话put请求会首先放到本地buffer,等到本地buffer大小超过一定

    阈值（默认是2M）之后才会提交，很显然，后者采用group commit机制提交请求，可以极大的提交写入

    性能，但是因为没有保护机制，如果客户端崩溃的话会导致提交的请求丢失。

    2、在提交之前，HBase会在元数据表 meta 中根据rowkey 找到他们归属的region server,这个定位的过

     程是通过 HConnection的HRegionLocation分组，每个分组对应一次RPC请求。

    3、 HBase会为每个HRegionLocation构造一个远程RPC请求

        MultiServerCallable，然后通过 rpcCallerFactory.

        newCaller()执行调用，忽略掉失败重新提交和错误处理，客户端的提交操作到

        此结束。

服务器端流程解析：

服务器端RegionServer接收到客户端的写入请求

        首先会反序列化为Put对象，然后执行各种检查操作，

        比如检查region是否是只读、memstore大小是否超

        过blockingMemstoreSize等。检查完成之后，就会

        执行如下核心操作

1、获取行锁、Region更新共享锁： HBase中使用行锁保证对同一行数据

的更新都是互斥操作，用以保证更新的原子性，要么更新成功，要么失败

2、开始写事务：获取write number，用于实现MVCC，实现数据的非锁定

读，在保证读写一致性的前提下提高读取性能。

3、Append HLog：HBase使用WAL机制保证数据可靠性，即首先写日志再写缓存，即使发

生宕机，也可以通过恢复HLog还原出原始数据。该步骤就是将数据构造为WALEdit对象，然后

顺序写入HLog中，此时不需要执行sync操作。0.98版本采用了新的写线程模式实现HLog日志

的写入，可以使得整个数据更新性能得到极大提升

4、释放行锁以及共享锁

5、写缓存memstore：HBase中每列都会对应一个store，用来存储该列数

据。每个store都会有个写缓存memstore，用于缓存写入数据。HBase并不会

直接将数据落盘，而是先写入缓存，等缓存满足一定大小之后再一起落盘

6 、Sync HLog：HLog真正sync到HDFS，在释放行锁之后执行sync操作是为了尽量减少持

锁时间，提升写性能。如果Sync失败，执行回滚操作将memstore中已经写入的数据移除。

7、结束写事务：此时该线程的更新操作才会对其他读请求可见，更新才实际生效。

8）flush memstore：当写缓存满64M之后，会启动flush线程将数据刷新到硬盘。

定位Region:

    HBase 有两个元数据表 ROOT META

    ROOT 用于保存 META表所有的Region信息

    META表用于存放实际的用户表的Region位置信息

    三层的B+树查找模式

        第一层存储在Zookeeper中，保存ROOT表的Region信息

        第二层到ROOT 表中查询匹配到的META表的Region

        第三层到META 表中检索用户表的Region信息

过滤器：

     带有过滤器条件的RPC查询请求会把过滤器分发到各个 RegionServer（服务器端的过滤器）可以

    降低网络传输的压力

过滤器的两类参数

     一类是抽象的操作符

            − LESS, LESS_OR_EQUAL,EQUAL,NOT_EQUAL,GREATER_OR,EQUAL,GREATER,NO_OP

     另一类是比较器Comparator，代表具体的比较逻辑。

     比较器作为过滤器的核心组件之一，用于处理具体的比 较逻辑，如字节级的比较、字符串级的比较