一、HBase在实际业务场景中的应用
HBase是一个构建在HDFS上的分布式列存储系统；HBase是Apache Hadoop生态系统中的重要一员，主要用于海量结构化数据存储
HBase能做什么？
海量数据存储
准实时查询
举例说明HBase在实际业务场景中的应用
交通
金融
电商
移动
二、HBase的特点
容量大：HBase单表可以有百亿行，百万列，数据矩阵横向和纵向两个纬度所支持的数据量级别都非常具有弹性
稀疏性：为空的列并不占用存储空间，表可以设计的非常稀疏
多版本：HBase每一列的数据存储有多个Version
面向列：HBase是面向列的存储和权限控制，并支持独立检索。列式存储，其数据在表中是按照某列存储的，这样在查询只需要少数几个字段的时候，能大大减少读取的数据量。
扩展性：底层依赖于HDFS
高可靠性：WAL机制保证了数据写入时不会因集群异常而导致写入数据丢失：Replication机制保证了在集群出现严重的问题时，数据不会发生丢失或损坏。而HBase底层使用HDFS，HDFS本身也有备份。
高性能：底层的LSM数据结构和RowKey有序排列等架构上的独特设计，使得HBase具有非常的写入性能。region切分、主键索引和缓存机制使得HBase在海量数据下具备一定的随机读取性能，该性能针对Rowkey的查询能够达到毫秒级。
三、HBase数据模型并举例说明
（1）逻辑存储模型
RowKey：Hbase使用Rowkey来唯一的区分某一行的数据。
Column Family（列族）：Hbase通过列族划分数据的存储，列族下面可以包含任意多的列，实现灵活的数据存取。Hbase的列族不是越多越好，官方推荐的是列族最好小于或者等于3。我们使用的场景一般是1个列族。
Time Stamp（时间戳）：TimeStamp对Hbase来说至关重要，因为它是实现Hbase多版本的关键。在Hbase中使用不同的timestame来标识相同rowkey行对应的不通版本的数据。
Cell：HBase 中通过 rowkey 和 columns 确定的为一个存储单元称为 cell。每个 cell 都保存着同一份 数据的多个版本。版本通过时间戳来索引。
（2）物理存储模型
Hbase的Table中的所有行都按照row key的字典序排列。Table 在行的方向上分割为多个Region。Region按大小分割的，每个表开始只有一个region，随 着数据增多，region不断增大，当增大到一个阀值的时候， region就会等分会两个新的region，之后会有越来越多的 region。
Region是HBase中分布式存储和负载均衡的最小单元。 不同Region分布到不同RegionServer上。
Region虽然是分布式存储的最小单元，但并不是存储 的最小单元。Region由一个或者多个Store组成，每个store保存一个 columns family。每个Strore又由一个memStore和0至多个StoreFile组成。memStore存储在内存中，StoreFile存储在HDFS上。
四、HBase基本架构
包括了HMaster、HRegionSever、HRegion、HLog、Store、MemStore、StoreFile、HFile等。HBase底层依赖HDFS，通过DFS Cilent进行HDFS操作。HMaster负责把HRegion分配给HRegionServer，每一个HRegionServer可以包含多个HRegion，多个HRegion共享HLog，HLog用来做灾难恢复。每一个HRegion由一个或多个Store组成，一个Store对应表的一个列族，每个Store中包含与其对应的MemStore以及一个或多个StoreFile（是实际数据存储文件HFile的轻量级封装），MemStore是在内存中的，保存了修改的数据，MemStore中的数据写到文件中就是StoreFile。
（1）HMaster
HMaster的主要功能有：
把HRegion分配到某一个RegionServer。
有RegionServer宕机了，HMaster可以把这台机器上的Region迁移到active的RegionServer上。
对HRegionServer进行负载均衡。
通过HDFS的dfs client接口回收垃圾文件（无效日志等）
注：HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行。
（2）HRegionServer
HRegionServer的主要功能有：
维护HMaster分配给它的HRegion，处理对这些HRegion的IO请求，也就是说客户端直接和HRegionServer打交道。（从图中也能看出来）
负责切分正在运行过程中变得过大的HRegion
（3）基本架构
HBase构建在HDFS之上，其组件包括 Client、zookeeper、HDFS、Hmaster以及HRegionServer。Client包含访问HBase的接口，并维护cache来加快对HBase的访问。Zookeeper用来保证任何时候，集群中只有一个master，存贮所有Region的寻址入口以及实时监控Region server的上线和下线信息。并实时通知给Master存储HBase的schema和table元数据。HMaster负责为Region server分配region和Region server的负载均衡。如果发现失效的Region server并重新分配其上的region。同时，管理用户对table的增删改查操作。Region Server 负责维护region，处理对这些region的IO请求并且切分在运行过程中变得过大的region。
HBase 依赖ZooKeeper，默认情况下，HBase 管理ZooKeeper 实例。比如， 启动或者停止ZooKeeper。Master与RegionServers 启动时会向ZooKeeper注册。因此，Zookeeper的引入使得 Master不再是单点故障。
Client每次写数据库之前，都会首先血Hlog日志。记录写操作。如果不做日志记录，一旦发生故障，操作将不可恢复。HMaster一旦故障，Zookeeper将重新选择一个新的Master 。无Master过程中，数据读取仍照常进行。但是，无master过程中，region切分、负载均衡等无法进行。RegionServer出现故障的处理原理是定时向Zookeeper汇报心跳，如果一旦时 间内未出现心跳HMaster将该RegionServer上的Region重新分配到其他RegionServer上。失效服务器上“预写”日志由主服务器进行分割并派送给新的 RegionServer 。Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例。
寻找RegionServer定位的顺序是ZooKeeper --ROOT-(单Region) -.META. -用户表 。如上图所示。-ROOT- 表包含.META.表所在的region列表，该表只会有一 个Region。 Zookeeper中记录了-ROOT-表的location。 .META. 表包含所有的用户空间region列表，以及 RegionServer的服务器地址。
五、HBase读写流程
（1）写流程
client首先会去读zookeeper上的meta-region-server表信息，获取hbase:meta 表位于哪个Region Server；
访问对应的Region Server，获取hbase:meta 表，此meta表信息记录了HBase所有表region信息
根据读请求的namespace:table/rowkey，查询 出目标数据位于哪个Region Server 中的哪个Region 中
并将该table 的region 信息以及meta 表 的位置信息缓存在客户端的meta cache，方便下次访问。
与目标Region Server 进行通讯
将数据顺序写入（追加）到WAL
将数据写入对应的MemStore，数据会在MemStore 进行排序
向客户端发送ack
等达到MemStore 的刷写时机后，将数据刷写到HFile
（2）读流程
client首先会去读zookeeper上的meta-region-server表信息，获取hbase:meta 表位于哪个Region Server；
访问对应的Region Server，获取hbase:meta 表，此meta表信息记录了HBase所有表region信息
根据读请求的namespace:table/rowkey，查询 出目标数据位于哪个Region Server 中的哪个Region 中
并将该table 的region 信息以及meta 表 的位置信息缓存在客户端的meta cache，方便下次访问。
与目标Region Server 进行通讯
分别在Block Cache（读缓存），MemStore 和Store File（HFile）中查询目标数据，并将查到的 所有数据进行合并。此处所有数据是指同一条数据的不同版本（time stamp）或者不同的类型 （Put/Delete）。
将从文件中查询到的数据块（Block，HFile 数据存储单元，默认大小为64KB）缓存到Block Cache。
将合并后的最终结果返回给客户端。
六、Flush
MemStore的刷写时机
当某个memstroe 的大小达到了hbase.hregion.memstore.flush.size（默认值128M），其所 在region的所有memstore 都会刷写。当memstore 的大小达到了hbase.hregion.memstore.flush.size（默认值128M）hbase.hregion.memstore.block.multiplier（默认值4）时，会阻止继续往该memstore 写数 据。
当region server中memstore的总大小达到hbase.regionserver.global.memstore.size（默认值0.4）hbase.regionserver.global.memstore.size.lower.limit（默认值0.95），region 会按照其所有memstore 的大小顺序（由大到小）依次进行刷写。直到region server中所 有memstore 的总大小减小到上述值以下。当region server 中memstore 的总大小达到hbase.regionserver.global.memstore.size（默认值0.4）时，会阻止继续往 所有的memstore 写数据。
到达自动刷写的时间，也会触发memstore flush。自动刷新的时间间隔由以下参数决定 hbase.regionserver.optionalcacheflushinterval（默认1 小时）。
当WAL 文件的数量超过hbase.regionserver.max.logs，region 会按照时间顺序依次进行刷 写，直到WAL 文件数量减小到hbase.regionserver.max.log 以下（该属性名已经废弃，现无需手 动设置，最大值为32）。
七、StoreFile Compaction
由于memstore 每次刷写都会生成一个新的HFile，且同一个字段的不同版本（timestamp）和不同类 型（Put/Delete）有可能会分布在不同的HFile 中，因此查询时需要遍历所有的HFile。
为了减少HFile 的个数，以及清理掉过期和删除的数据，会进行StoreFile Compaction。Compaction 分为两种分别是Minor Compaction 和Major Compaction。
Minor Compaction会将临近的若干个较小的HFile 合并成一个较大的HFile，但不会清理过期和删 除的数据。
Major Compaction 会将一个Store 下的所有的HFile 合并成一个大HFile，并且会清理掉过期和删 除的数据。
八、Region Split
默认情况下，每个Table 起初只有一个Region，随着数据的不断写入，Region 会自动进行拆分。刚拆 分时，两个子Region 都位于当前的Region Server，但处于负载均衡的考虑，HMaster 有可能会将某个 Region 转移给其他的Region Server。
Region Split 时机：
当1 个region 中的某个Store 下所有StoreFile 的总大小超过hbase.hregion.max.filesize， 该Region 就会进行拆分（0.94 版本之前）。
当1 个region 中的某个Store 下所有StoreFile 的总大小超过Min(R^2 *“hbase.hregion.memstore.flush.size”，hbase.hregion.max.filesize")，该Region 就 会进行拆分，其中R 为当前Region Server 中属于该Table 的个数（0.94 版本之后）。
