HBase知识点总结
HBase简介
HBase 是一种分布式、可扩展、支持海量数据存储的 NoSQL 数据库。逻辑上，HBase 的数据模型同关系型数据库很类似，数据存储在一张表中，有行有列。 但从 HBase 的底层物理存储结构（K-V）来看，HBase 更像是一个 multi-dimensional map。
HBase架构
Client
Zookeeper：负责Master的HA，RegionServer的监控，元数据的入口以及集群配置的维护等工作
Master：
对于表的操作create、delete、alter；
对于RegionServer的操作：分配regions到每一个RegionServer，监控每一个RegionServer的状态，负载均衡和故障转移
RegionServer：
对于数据的操作：get、put、delete
对于Region的操作：splitRegion、compactRegion
HDFS：
为Hbase提供底层数据存储服务，同时为HBase提供高可用的支持
StoreFile：
保存实际数据的物理文件，StoreFile以HFile的形式存储在HDFS上。每一个Store会有一个或多个StoreFile，数据在每一个StoreFile中都是有序的
MenStore：
写缓存，由于HFile中的数据要求是有序的，所以数据是先存储在MemStore中，排好序后，等到达刷写时机才会刷写到HFile，每一次刷写都会形成一个新的HFile
WAL（HLog）：
由于数据要经过MemStore排序后才能刷写到HFile，但把数据保存在内存中会有很高的概率导致数据丢失，为了解决这个问题，数据会先写在一个叫做 Write-Ahead logfile 的文件 中，然后再写入 MemStore 中。所以在系统出现故障的时候，数据可以通过这个日志文件重建。
HBase读写流程
写流程
1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。
2）访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey， 查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以 及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。
3）与目标 Region Server 进行通讯；
4）将数据顺序写入（追加）到 WAL；
5）将数据写入对应的 MemStore，数据会在 MemStore 进行排序；
6）向客户端发送 ack；
7）等达到 MemStore 的刷写时机后，将数据刷写到 HFile。
MemStore 刷写时机
（1）当某个 memstroe 的大小达到了128M， 其所在 region 的所有 memstore 都会刷写。
当 memstore 的大小达到了128*4会阻止继续往该 memstore 写数据。
（2）当 region server 中 memstore 的总大小达到 java堆内存大小*0.4*0.95
region会按照其所有 memstore 的大小顺序（由大到小）依次进行刷写。直到 region server 中所有 memstore 的总大小减小到上述值以下。
当 region server 中 memstore 的总大小达到时java堆内存大小*0.4，会阻止继续往所有的 memstore 写数据。
（3）到达自动刷写的时间1h，也会触发 memstore flush。
当 WAL 文件的数量超过32个，region 会按照时间顺序依次进行刷写，直到 WAL 文件数量减小到 32个以下
读流程
1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。
2）访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey， 查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以 及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。
3）与目标 Region Server 进行通讯；
4）分别在 Block Cache（读缓存），MemStore 和 Store File（HFile）中查询目标数据，并将 查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本（time stamp）或者不 同的类型（Put/Delete）。
5） 将从文件中查询到的数据块（Block，HFile 数据存储单元，默认大小为 64KB）缓存到 Block Cache。
6）将合并后的最终结果返回给客户端。
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.当1个region中的某个Store下所有StoreFile的总大小超过hbase.hregion.max.filesize， 该 Region 就会进行拆分（0.94 版本之前）。
2. 当 1 个 region 中 的 某 个 Store 下所有 StoreFile 的 总 大 小 超 过 Min(R^2 * "hbase.hregion.memstore.flush.size",hbase.hregion.max.filesize")，该 Region 就会进行拆分，其 中 R 为当前 Region Server 中属于该 Table 的个数（0.94 版本之后）。
HBase API
HBaseAdmin
HTable
HBase优化
高可用
在 HBase 中 HMaster 负责监控 HRegionServer 的生命周期，均衡 RegionServer 的负载， 如果 HMaster 挂掉了，那么整个 HBase 集群将陷入不健康的状态，并且此时的工作状态并 不会维持太久。所以 HBase 支持对 HMaster 的高可用配置。
预分区
每一个 region 维护着 StartRow 与 EndRow，如果加入的数据符合某个 Region 维护的 RowKey 范围，则该数据交给这个 Region 维护。那么依照这个原则，我们可以将数据所要 投放的分区提前大致的规划好，以提高 HBase 性能。
RowKey设计
唯一原则(kv)、排序原则(字典顺序)、散列原则(region热点)、长度原则(不长不短、long)
MD5 + 主维度 + 维度标识 + 子维度1 + 时间维度 + 子维度2
例如：卖家ID的MD5前四位 + 卖家ID + app + 一级类目ID + ddd + 二级类目ID
以MD5的前四位作为rowkey的第一部分，可以把数据散列，让服务器整体负载是均衡的，避免热点问题。在上面的例子中，卖家ID属于主维度，在查数据时是必传的。每一个统计维度都会生成一个维度标识，以便在rowkey上做区分。
内存优化
HDFS配置
MapReduce配置
flush、compact、split 机制
RPC监听数量
HStore 文件大小
HBase 客户端缓存
