Hadoop基础(五) :非关系型数据库HBase理论基础

1.什么是HBase？

• HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库（因为是建立在HDFS之上），利用HBase技术可在廉价PC上搭建起大规模非结构化存储集群。
• HBase 是Google Bigtable 的开源实现，与Google Bigtable 利用GFS作为其文件存储系统类似，HBase 利用Hadoop HDFS 作为其文件存储系统；Google 运行MapReduce 来处理Bigtable中的海量数据， HBase 同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable 利用Chubby作为协同服务， HBase 利用Zookeeper作为对应。
• HBase还是一种非关系性数据库，即NOSQL数据库。

2.HBase架构

HBase总体架构图：

HBase储存结构

2.1 zookeeper

• 储存HBase中的-ROOT-表（根数据表）和.MATA.(元数据表)，HBase必须通过zookeeper读取这两个表才能实现数据读取
• HRegionServer把自己以Ephedral方式注册到Zookeeper中，HMaster随时感知各个HRegionServer的健康状态
• zookeeper避免了HBase的单点问题，通过实时监控HMaster的健康状态，当Active HMaster宕机时，会立即协调Standy HMaster取代已经宕机的Active HMaster，并且启动一个新的Standy HMaster
• 保证任何时候，集群中只有一个Active HMaster
• 储存所有Region的寻址入口

2.2 HMaster

主节点服务，管理HRegionserver

• 协调数据库源数据变化
• 监控HRegionServer节点
• 管理HRegionServer的负载均衡
• 失败HRegionServer重启
• 分配region到RegionServer，在HRegionServer推出时签意其内的HRegion到其他HRegionServer上
• 执行Admin职能，Table的新建、删除、修改的实现

2.3 HRegionServer

• 储存和管理regions
• 处理读取/写入的请求，向HDFS中读写数据
• 当region数据过多是，自动分割为region
• 表操作直接和客户端连接
• 一个节点上只能运行一个HRegionServer，每个region由一个HRegionServer复制，一个HRegionServer复制多个region

2.4 Region

• HBase表被分割为多个region，每个region包含多个行数据
• Region包含region名字，开始rowkey和结束rowkey

  每个HRegion由多个Store构成，每个Store保存一个列族（Columns Family），表有几个列族，则有几个Store，每个Store由一个MemStore和多个StoreFile组成，MemStore是Store在内存中的内容，写到文件后就是StoreFile。StoreFile底层是以HFile的格式保存

2.5 HLong

  HLog(WAL log)：WAL意为write ahead log（预写日志），用来做灾难恢复使用，HLog记录数据的变更，包括序列号和实际数据，所以一旦region server 宕机，就可以从log中回滚还没有持久化的数据。

2.6 HFile

  HFile是HBase中重要的一个存在，可以说是HBase架构中最小的结构，HBase的数据都在HFile中。我们知道HBase隶属于Hadoop生态系统，HFile从根本上来说是hdfs中的文件，只是他有自己特殊的格式。

2.7 HBase写入过程

1. Client访问ZK，根据ROOT表获取meta表所在Region的位置信息，并将该位置信息写入Client Cache。（注：为了加快数据访问速度，我们将元数据、Region位置等信息缓存在Client Cache中。）

2. Client读取meta表，再根据meta表中查询得到的Namespace、表名和RowKey等相关信息，获取将要写入Region的位置信息（此过程即Region三层定位，如下图），最后client端会将meta表写入Client Cache。

3. Client向上一步HRegionServer发出写请求，HRegionServer先将操作和数据写入HLog（预写日志，Write Ahead Log，WAL），再将数据写入MemStore，并保持有序。
   （联想：HDFS中也是如此，EditLog写入时机也是在真实读写之前发生）

4. 当MemStore的数据量超过阈值时，将数据溢写磁盘，生成一个StoreFile文件。

5. 当Store中StoreFile的数量超过阈值时，将若干小StoreFile合并（Compact）为一个大StoreFile。当Region中最大Store的大小超过阈值时，Region分裂（Split），等分成两个子Region。

2.8 数据储存模式

  HBase表的储存模式可以理解成一个三维的表，由RowKey和列簇（ColumnFamily）作为X、Y轴，以TimeStamp作为Z轴，组成了一个带有版本信息的数据表

3.HBase特点

• 1.海量储存
    HBase适合储存PB级别的海量数据，在PB级别的数据以及采用廉价PC储存的情况下，能在几十到百毫秒内返回数据。这与HBase的极易扩展性息息相关。正是因为HBase良好的扩展性，才为海量数据的储存提供了便利。
• 2.列式储存
    这里的列示储存其实说的是列族储存，HBase是根据列族来储存数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指定，而列不必在创建时指定。
• 3.极易扩展
    HBase的扩展性主要体现在两个方面，一个是基于上层处理能力（HRegionServer）的扩展，一个是基于储存的扩展（HDFS)。其实两个方面都是旨在增加节点机器来达到扩展的效果
• 4.高并发
    由于目前大部分使用HBase的架构，都是采用廉价PC，因此单个IO的延迟其实并不小，一般在即使到上百毫秒之间。这里说的高并发，主要是在并发的情况下，HBase的单个IO延迟下降并不多。能获得高并发、低延迟的服务。
• 5.稀疏
    稀疏主要是针对HBase列的灵活性，在列族中，你可以指定任意多的列，在列数据为空的情况下，是不会占用储存空间的。

4.HBase的设计优化

1. 列族的数量设置得越少越好，两个或者两个一下。因为HBase是按列族储存的，如果有多个列族的话，会产生数量巨大的小文件，不便于管理。
2. 避免使用时序或者单调递增（递减）的RowKey（避免热点问题）。优化方法有：增加随机数前缀、哈希、反转RowKey，使用反转的时间戳作为RowKey的一部分
3. 尽量最小化RowKey和列族的大小
4. 控制版本数量