一、HBase 简介

1.HBase 概述

HBase 是一个构建在HDFS之上的，分布式的、面向列的开源数据库
HBase 是 Google BigTable的开源实现，它主要用于存储海量数据

个人理解：
分布式：采用分而治之的思想，比如说我们要将10个G的数据全部写入到HBase，对于这样的一个任务我们可以通过10个节点来处理（并行处理），这样可以大大的提高执行效率。

面向列：一个表中是有很多行很多列，面向列的存储就是将多个列存储在一块，HBase里是通过列族来组织的，实际开发中我们查询可能只会查询某几个列，面向列存储后，会减少磁盘和网络IO的开销从而提高效率。面向列是无模式的，即列可以根据实际情况任意添加。

2.HBase 的特点

(1).大：一个表可以有上百万、上百亿行列（列多时，插入变慢）

(2).面向列：数据构成是列族，列族中包含N个列

(3).稀疏：在HBase中列的值为null时，是不占存储空间的，而关系型数据库占用

(4).数据类型单一：HBase 中的数据类型只有一种String

(5).无模式：每行数据对应的列可以不相同，创建表时不需要指定列，插入数据时列可以任意添加

(6).数据多版本：列中的数据可以有多个版本，查询时可以通过指定版本号获取（版本号不同，获取到的数据不同）

3.HBase 与 RDBMS对比

传统数据库遇到的问题：
1）数据量很大的时候无法存储
2）没有很好的备份机制
3）数据达到一定数量开始缓慢，很大的话基本无法支撑

HBASE优势：
1）线性扩展，随着数据量增多可以通过节点扩展进行支撑
2）数据存储在hdfs上，备份机制健全
3）通过zookeeper协调查找数据，访问速度块。

4.HBase 与 HDFS 区别

二、HBase 数据模型及物理模型

1.数据模型

HBase 数据模型图如下

逻辑数据模型对应物理数据模型

HBase 核心术语介绍

Row Key（行健）

与nosql数据库们一样,row key是用来检索记录的主键。访问HBASE table中的行，只有三种方式：
1.通过单个row key访问
2.通过row key的range（正则）
3.全表扫描
row key行键 (Row key)可以是任意字符串(最大长度 是 64KB，实际应用中长度一般为 10-100bytes)，在HBASE内部，row key保存为字节数组。存储时，数据按照row key的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。(位置相关性)

Columns Family（列族）

列簇 ：HBASE表中的每个列，都归属于某个列族（表中的每个列都保存到某一个文件中，即一个列族对应一个文件）。列族是表的schema的一部 分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如 courses:history，courses:math都属于courses 这个列族。

Cell（列）

由{row key, columnFamily, version} 唯一确定的单元。cell中 的数据是没有类型的，全部是字节码形式存储。
关键字：无类型、字节码

Time Stamp（时间戳）

hbase 中 每保存一条数据，它会默认为生成一个时间戳，也可以自己设置。每个 cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面

2.物理模型

对于HBase 的物理模型我们分别从Table的分割、Region的拆分、Region的分布，Region的构成四个部分介绍，下图为HBase的物理模型图

Table的分割

Table 中的所有行都按照 rowkey 的字典序排列，Table 在行的方向上分割为多个Region，一个Region在同一时刻只能被同一个RegionServer管理，RegionServer可以管理多个Region（一对多）

Region的拆分

Region是按大小分割的，新创建的表只有一个region（数据为空），随着数据增多，region不断增大，当增大到一个阀值时，region就会拆分为两个新的region，之后会有越来越多的region。

那么region为什么要进行拆分呐？随着数据越来越多，region越来越多，那么对region的管理就比较麻烦，在我们的大数据环境下，经常会面临大量的数据处理，拆分region是为了并行处理，提高效率。

Region 的分布

Region 是 HBase 中分布式存储和负载均衡的最小单元，不同的Region分布到不同的RegionServer上，如下图Table1、Table2中均有多个Region，这些Region分布在不同的RegionServer中

Region的构成

Region虽然是分布式分布式存储的最小单元，但并不是存储的最小单元，Store是存储的最小单元

Region由一个或者多个Store组成，每个Store会保存一个Column Family；每个Store又由一个MemStore或0至多个StoreFile组成；MemStore存储在内存中，StoreFile存储在HDFS中，下图为Region的构成，当我们向HBase插入数据时，会先存放到memStore（内存）中，然后再从内存中存放到磁盘文件StoreFile中，磁盘文件满了之后再存放到HDFS中

三、HBase 架构及工作原理

1.HBase 架构

HBase 仍然采用Master/Slave架构，它隶属于Hadoop生态系统。HBase将逻辑上的表划分成多个数据块即HRegion，存储在HRegionServer中。

HMaster负责管理所有的HRegionServer，它本身并不存储任何数据，而只是存储数据到HRegionServer的映射关系（元数据）。集群中的所有节点通过Zookeeper进行协调，并处理HBase运行期间可能遇到的各种问题。HBase 架构图如下

各个组件的作用如下

Client
Client 数量为一个或多个，HBase Client 使用 HBase 的 RPC 机制与HMaster和HRegionServer进行通信。
(1).对于管理类操作Client与HMaster进行RPC通信
(2).对于数据读写操作Client与HRegionServer进行RPC通信

Zookeeper
(1).保证集群中只有一个正在运行的HMaster，如果HMaster挂了，通过Zookeeper的选举机制保证集群中总有一个HMaster运行，避免单点问题
(2).通过将集群各节点状态信息注册到Zookeeper中，使得HMaster可随时感知各个HRegionServer的健康状态

HMaster
(1).为HRegionServer分配Region，调整Region的分布，管理HRegionServer的负载均衡
(2).HMaster中记录了Region在哪台Hregion server上，它管理所有的HRegionServer并告诉HRegionServer维护那些Region
(3).在HRegion Server宕机后，将失效HRegion Server 上的Regions迁移到其它的HRegionServer

HRegionServer
(1).维护Region，处理并响应这些Region的IO请求及响应
(2).HRegionServer管理了很多Table的分区，即Region，负责对超过阀值的Region进行切分(split)

HRegion
当表的大小超过预设值的时候，HRegion会自动按行对rowkey对应的数据进行拆分

HLog
HLog 是一个实现了WAL（Write Ahead Log）的预写日志类，其内部是一个简单的顺序日志。每个HRegionServer上都有一个HLog，类似于mysql中的binlog。该日志只会追加内容，用于记录操作日志，能用来做灾难恢复（数据回滚到初始状态）。

HStore
它是HBase的存储核心，存储的最小单元，由MemStore或0至多个StoreFile组成。
MemStore是内存缓冲区，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile，是HBase存储数据的文件组织形式），当StoreFile的文件数量增长到一定阈值后，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除操作。

因此，可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的Compact过程中进行的，这样使得用户的写操作只要进入内存就可以立即返回，保证了HBaseI/O的高性能。

数据flush过程如下：
(1).当memstore数据达到阈值（默认是64M），将数据刷到硬盘，将内存中的数据删除，同时删除Hlog中的历史数据。
(2).并将数据存储到hdfs中。
(3).在hlog中做标记点。

数据Compact合并过程如下：
(1).当数据块达到4块，hmaster将数据块加载到本地，进行合并
(2).当合并的数据超过256M，进行拆分，将拆分后的region分配给不同的hregionserver管理
(3).当hregionser宕机后，将hregionserver上的hlog拆分，然后分配给不同的hregionserver加载，修改.META.（HBase 的内置表，存储HBase 内部的系统信息——Region的分布情况以及每个Region的详细信息）
(4).注意：hlog会同步到hdfs

HBase 容错
(1).HMaster 容错
通过Zookeeper实现，如果HMaster挂掉，通过Zookeeper的选举机制重新选择一个新的HMaster

(2).HRegionServer容错
RegionServer会定时向Zookeeper发送心跳，如果一段时间内未出现心跳，Master将该RegionServer上的Region重新分配到其他RegionServer上。

(3).Zookeeper容错
zookeeper是为其它分布式框架提供分布式协调服务的，本身并不是单点，一般都是奇数个zk组成的集群，如果某一个挂掉后，zk会通过选举机制重新选择一个leader。

1.HBase 工作原理

写数据流程：

(1).client向hregionserver发送写请求。
(2).Regionserver找到目标Region。
(3).Region会检查数据是否与Schema一致。
(4).若客户端没有指定时间戳，默认取当前时间。
(5).hregionserver将数据写到hlog（write ahead log）。为了数据的持久化和恢复。
(7).hregionserver将数据写到内存memstore（判断Memstore是否需要Flush为Storefile文件）
(8).响应客户端Client请求

读数据流程：

(1).Client访问ZK，查找-ROOT-表，获取.META.表信息
(2).从.META.表查找，获取存放目标数据的HRegion信息，从而找到对应的HRegionServer
(3).通过HRegionServer获取需要查找的数据
(4).Region会先从Memstore中查询，命中则返回（先查Memstore的好处是在内存中，查询快）。
(5).若Memstore没有，则扫描StoreFile（这个过程可能会扫描很多StoreFIle），数据从内存和硬盘合并后缓存到内存中的数据块中最后响应给客户端

读取数据时zookeeper如何定位到Region，返回给Client数据？

-ROOT-和.META.是HBase内置的两张表，存储了HBase内部的一些系统信息，.META.存储Region的元数据（Region的分布情况以及每个Region的详细信息），随着HRegion的增多，.META.表中的数据也会增大，并拆分成多个新的HRegion。为了定位.META.表中各个HRegion的位置，把.META.表中所有HRegion的元数据保存在-ROOT-表中。

所有客户端访问用户数据前，需要首先访问Zookeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，查找到用户数据，最后放回给Client，流程图如下