Region概念解释
Region可以翻译为区域，在HBase里面，一个表中的数据，会按照行被横向划分为多个Region。
每个Region，按照存储的Rowkey的最小行键和最大行键指定的，使用区间[start Rowkey,end Rowkey)
解释：
- 如果一个文件中数据量很大的时候，从这个大文件中读取数据肯定会比较慢
- 打开一个小文件查找数据和打开一个大文件查找数据的效率是不一样的
看下面这个图：
在这个图里面，表t1刚创建的时候默认只有1个Region，后来数据量多了以后，Region会自动分裂，这样就产生了多个Region。
那么我们在查询数据的时候，首先要知道数据在哪个Region中，再从Region中读取数据。
如何知道数据在哪个Region中呢？
我们在向表中插入数据的时候，Rowkey是必须指定，不能缺少的，并且Rowkey在存储的时候是有序存储的。
那么我们在定位数据的时候，就可以拿Rowkey到对应的Region中进行对比，每个Region中都会有一个最小Rowkey和最大Rowkey，这样就能很快的判断出来我们要找的数据是不是在这个Region中了。
事实上，
其实每个Region中的最大Rowkey是有一个地方进行维护的，HBase内部默认提供了一个目录表来维护这个关系。
如果表t1有两个列族c1和c2，那么在存储的时候，列族c1中的数据是一个独立的文件，列族c2中的数据也会是一个独立的文件，也就是说，每一个列族中的数据在底层存储的时候都是一个单独的文件。
如下图所示，当表有多个Region的时候，每个Region内部的每个列族是一个单独的文件。
所以说我们在设计列族的时候，可以把经常读取的列存储到一个列族中，不经常读取的列放到另一个列族中。
这样我们在读取部分列的数据的时候，就只需要读取对应列族文件中的数据，提高读取效率。
在这里有几个问题：
- 如果一个列族中如果有2个列，那么这2个列会存储到2个列族文件中吗？不会的。
- 一行记录，会不会分到多个文件中存储？ 会
- 一个列族中的数据，会不会在多个Region中存储？会
- 一个Region中，会不会存储多个列族文件？会
HBase物理架构
主要包含以下内容：
- Zookeeper：为HBase集群提供基础服务。
- HBase Master：HBase集群的主节点。
- HBase Regionserver：HBase集群的从节点。
- Client：客户端节点。
Zookeeper
ZooKeeper为HBase集群提供协调服务，它管理着HMaster和HRegionServer的状态(available/alive等)，并且会在HRegionServer宕机时通知给HMaster。
ZooKeeper协调HBase集群所有节点的共享信息，在HMaster和HRegionServer连接到ZooKeeper后会创建Ephemeral（临时）节点，并使用心跳机制监控这个节点的存活状态，如果某个临时节点失效，则HMaster会收到通知，并做相应的处理，这块需要通过Watcher监视器实现。
另外，HMaster通过监听ZooKeeper中的临时节点(默认：/hbase/rs/*)来监控HRegionServer的加入和宕机。在第一个HMaster连接到ZooKeeper时会创建临时节点(默认：/hbasae/master)来表示Active的HMaster，后面加入进来的HMaster则监听该临时节点，如果当前Active的HMaster宕机，则该临时节点消失，因此其他HMaster会得到通知，然后将自身转换成Active的HMaster，在变为Active的HMaster之前，它会先在/hbase/back-masters/下创建自己的临时节点。
对Zookeeper的作用总结一下，一共有3点：
- Zookeeper维护HBase集群的信息
- HRegionserver启动的时候会在Zookeeper的/hbase/rs下面创建节点信息
- HMaster会在Zookeeper的/hbase下创建master节点 多余的HMaster会监听这个节点，发现这个节点失效的时候，会接管这个角色。
HMaster
HMaster是HBase集群的主节点，HBase集群支持多个HMaster节点，可以实现HA。
通过ZooKeeper的选举机制保证同时只有一个HMaster处于Active状态，其他的HMaster处于备份状态。一般情况下会启动两个HMaster，备份状态的HMaster会定期和Active HMaster通信以获取其最新状态，从而保证它是实时更新的，因此如果启动了多个HMaster反而增加了Active HMaster的负担。
HMaster主要有以下职责：
- 管理HRegionServer，实现其负载均衡。
- 管理和分配Region，比如在Region 分裂时分配新的Region；在HRegionServer退出时迁移里面的Region到其他HRegionServer上。
- 管理namespace和table的元数据（这些元数据实际存储在HDFS上面）
- 权限控制（ACL）
HRegionserver
HRegionserver是HBase集群的从节点。
HRegionServer一般建议和DataNode部署在同一台机器上，这样可以实现数据的本地化特性，因为DataNode是存储数据的，HBase的数据也是存储在HDFS上的，HRegionServer就是管理数据的，所以这样的话可以尽量保证HRegionServer读取本地的数据，只有磁盘IO，节省了网络IO。
HRegionServer里面的内容
HRegionServer里面有2块内容，一个是HLog ，另一个是HRegion(其实就是我们前面分析的Region，是同一个意思，Region是HRegion的简称)。
在一个HRegionServer里面，HLog只有一个，HRegion会有多个，这个框后面是有三个点，表示是多个的意思。
HLog是负责记录日志的，针对这个HRegionServer中的所有写操作，包括put、delete等操作，只要是会对数据产生变化的操作，都会记录到这个日志中，再把数据写到对应的HRegion中。
HRegion就是负责存储实际数据了。
看一下HRegion内部：
每一个Store对应一个列族，所以一个HRegion里面可能会有多个Store。
向HRegionserver中写数据的时候，会先写HLog，然后在把数据写入HRegion的时候，会根据指定的列族信息写入到不同的Store里面，我们之前在向表中put数据的时候，表名和列族名称都是必须要指定的。
Store里面包含两部分：MemStore 和 StoreFile。
用户写入的数据首先会放入MemStore【基于内存的Store】里面，当这个MemStore写满了以后，会把数据持久化到StoreFile中，每一次内存满了持久化的时候都会生成一个StoreFile，StoreFile底层对应的是一个HFile文件。
HFile文件会通过下面的DFS Client写入到HDFS中。
最终HLog和HFile都是用DFS Client写入到HDFS中的。
HBase物理存储模型
HBase中表的数据是存储在Region中的，表中的数据会越来越多，Region就会分裂，分裂出来的多个Region会分布到多个节点上面，因为单台机器的存储能力是有限的，这样对后期数据并行读取也有好处，有利于扩展。
这样就可以保证一个表能存储海量数据，存放Region的服务器称之为Region Server。
WAL(Write-Ahead Logging)预写日志系统
WAL最重要的作用是灾难恢复。和MySQL 的Binlog类似，它记录所有的数据改动。一旦服务器崩溃，通过重放log可以恢复崩溃之前的数据。这也就意味如果写入WAL失败，整个写入操作将认为失败。
HBase中，HLog是WAL的实现类。一个HRegionServer对应一个HLog实例。
WAL数据是存储在HDFS上面的，点进去可以看到是一个一个的文件。
采用这种模式，可以保证HRegionServer宕机后，我们依然可以从该log文件中恢复数据，而不至于数据丢失。
主要是因为数据写入到Memstore中，这个是基于内存的，如果节点宕机了，内存中的数据就没了，这个时候可以通过WAL恢复数据。如果数据从Memstore 持久化到HFile之后，其实就不需要WAL日志了。所以WAL日志不会保存所有的操作，只会保留一部分，这个日志也会有一个删除策略。
WAL这个日志文件会定期生成新的文件而删除旧的文件(那些已持久化到HFile中的数据对应的日志可以删除)。
HFile介绍
HFile是HBase中重要的一个存在，可以说是HBase架构中最小的结构，HBase的底层数据都在HFile中。
HFile从根本上来说是HDFS中的文件，只是它有自己特殊的格式。
HFile文件由6部分组成：
- Data(数据块): 保存表中的数据(key-value的形式)，这部分可以被压缩，每个数据块都有一个Magic头,负责存储偏移量和第一个Key。
- Meta(元数据块)：存储用户自定义的key-value。
- File Info：定长，记录了文件的一些元信息，例如：AVG_KEY_LEN，AVG_VALUE_LEN，LAST_KEY等
- Data Index(数据块索引)：记录了每个数据块（Data）的起始索引。
- Meta Index(元数据块索引)：记录了每个元数据块（Meta）的起始索引。
- Trailer：定长，用于指向其他数据块的起始点。
BloomFilter布隆过滤器
布隆过滤器是一种比较巧妙的概率型数据结构，可以用来告诉你 “某样东西一定不存在或者可能存在”。
也就是说它告诉你某样东西不存在的话就一定不存在。
如果它告诉你某样东西存在，也可能实际是不存在的。
布隆过滤器是hbase中的高级功能，它能够减少特定访问模式（get/scan）下的查询时间。进而提高HBase集群的吞吐率。
当我们随机查询数据时，如果采用HBase的块索引机制，HBase会加载很多块文件。如果采用布隆过滤器后，它能够准确判断该HFile的所有数据块中，是否含有我们查询的数据，从而大大减少不必要的块加载，进而提高HBase集群的吞吐率。
对于HBase而言，当我们选择采用布隆过滤器之后，HBase会在生成HFile时包含一份布隆过滤器结构的数据，开启布隆过滤器会有一定的存储及内存开销。但是在大多数情况下，这些负担相对于布隆过滤器带来的好处来说是可以接受的。
HFile compaction（合并）机制
当MemStore超过阀值的时候，就会持久化生成一个（StoreFile）HFile。
因此随着数据不断写入，HFile的数量将会越来越多，HFile数量过多会降低读性能，因为每次查询数据都需要加载多个HFile文件。为了避免对读性能的影响，可以对这些HFile进行合并操作，把多个HFile合并成一个HFile。
合并操作需要对HBase中的数据进行多次的重新读写，这个过程会产生大量的IO。因此可以发现合并机制的本质就是以IO操作换取后续读性能的提高。
合并操作分为major（大合并）和minor（小合并）两种。
- minor（小合并）：只做部分文件的合并操作，生成新文件设置成激活状态，然后删除老的HFile文件。小合并的过程一般较快，而且IO相对较低。
- major（大合并）：对Region下的所有HFile执行合并操作，最终的结果是合并出一个HFile文件。在生成新的HFile时，会忽略掉已经标记为删除的数据、ttl过期的数据、版本超过限定的数据。大合并会产生大量的IO操作，对HBase的读写性能产生较大影响。
注意：一般情况下，大合并会持续很长时间，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会关闭自动触发大合并功能，改为手动在业务低峰期触发。
Region Split（分裂）机制
前面我们分析了HFile文件的合并机制，当HFile文件合并多次之后，会导致Region中的数据过大，此时就需要涉及Region的分裂机制了。
当HBase中的一个表刚被创建的时候，HBase默认只会分配一个Region给这个表。也就是说这个时候，所有的读写请求都会访问到同一个RegionServer中的同一个Region中，出现读写热点问题。
并且当 Region管理的数据量过多，或 HFile 文件较大时，都会影响性能。
为了达到负载均衡，当Region达到一定的大小时就会将一个Region分裂成两个新的子 Region，并对父 Region 进行清除处理。
HMaster会根据Balance策略，重新分配Region所属的RegionServer，最大化的发挥分布式系统的优点。
触发Region Split的条件：
- ConstantSizeRegionSplitPolicy （0.94版本前）：
- 一个Region 中最大 HFile文件的大小大于设置的阈值（hbase.hregion.max.filesize）之后才会触发切分，HFile文件大小为压缩后的文件大小（针对启用压缩的场景），默认文件大小的阈值为10G。
- 这种策略简单粗暴，但是弊端相当大。
- 阈值设置偏大的话，对大表友好，小表可能不会触发分裂，极端情况下小表可能就只会有一个Region。
- 阈值设置偏小的话，对小表友好，但一个大表可能会在集群中产生大量的Region，对于集群管理来说不是好事。
- IncreasingToUpperBoundRegionSplitPolicy （0.94版本~2.x版本默认切分策略）：
- 一个Region中最大 HFile文件的大小大于设置的阈值就会触发切分，区别是这个阈值并不像 ConstantSizeRegionSplitPolicy是一个固定的值，这里的阈值是会不断调整的。调整规则和 Region所属表在当前 RegionServer上的 Region个数有关系 。
- 公式：调整后的阈值 = Region个数的3次方 flush_size 2
- 注意：这里的阈值不会无限增大，会通过hbase.hregion.max.filesize来进行限制，不能超过这个参数的大小。
- 这种策略能够自适应大小表，集群规模大的情况下，对大表很优秀，对小表会产生大量小Region（比第一种策略好一些）。
Region Balance(负载均衡策略)
Region分裂之后就会涉及到Region的负载均衡。
HBase的HMaster进程会自动根据指定策略挑选出一些Region，并将这些Region分配到负载比较低的RegionServer上。
由于HBase的所有数据都是写入到HDFS文件系统中的， 因此HBase的Region移动其实是非常轻量级。在做Region移动的时候，保持这个Region对应的HDFS文件位置不变，只需要将Region的元数据分配到对应的RegionServer中即可。
官方目前支持两种挑选Region的策略：
DefaultLoadBalancer 和 StochasticLoadBalancer。
- DefaultLoadBalancer：这种策略能够保证每个RegionServer中的Region个数基本上都相等。
- StochasticLoadBalancer ：这种策略非常复杂，简单来讲是一种综合权衡6个因素的均衡策略。
采用6个因素加权的方式算出一个代价值，这个代价值用来评估当前Region分布是否均衡，越均衡代价值越低。
- 每台服务器读请求数(ReadRequestCostFunction)
- 每台服务器写请求数(WriteRequestCostFunction)
- Region个数(RegionCountSkewCostFunction)
- 移动代价(MoveCostFunction)
- 数据Locality(TableSkewCostFunction)
- 每张表占据RegionServer中Region个数上限(LocalityCostFunction)
