Hase 读写请求过程

读请求过程
客户端访问ZooKeeper 获取-ROOT-表或.META.表找到目标数据所在的 RegionServer(就是数据所在的 Region 的主机地址)

联系 RegionServer 查询目标数据

RegionServer 定位到目标数据所在的 Region，发出查询请求

Region 先在 Memstore 中查找，命中则返回

如果在 Memstore 中找不到，则在 Storefile 中扫描 为了能快速的判断要查询的数据在不在这个 StoreFile 中，应用了 BloomFilter
（BloomFilter，布隆过滤器：迅速判断一个元素是不是在一个庞大的集合内，但是他有一个弱点：它有一定的误判率）
（误判率：原本不存在与该集合的元素，布隆过滤器有可能会判断说它存在，但是，如果布隆过滤器，判断说某一个元素不存在该集合，那么该元素就一定不在该集合内）

5.3 写请求过程
HBase数据写入序列图

Client访问ZooKeeper 获取-ROOT-表或.META.表，根据 RowKey 找到对应的 Region 所在的 RegionServer

Client 向 RegionServer 提交写请求

RegionServer 找到目标 Region

Region 检查数据是否与 Schema 一致

如果客户端没有指定版本，则获取当前系统时间作为数据版本

将更新写入HLog

将更新写入 Memstore

如果 Hlog 和 Memstore 均写入成功，则这条数据写入成功。在此过程中，如果 Memstore达到阈值，会新开启一个Memstore，把旧的Memstore 中的数据放到一个队列（MapReduce中的实现是环形缓冲区）里面，按先进先出的原则将旧的Memstore依次flush 到 StoreFile（底层是HFile）中。

当 Storefile 越来越多，会触发 Compact 合并操作，把过多的 Storefile 合并成一个大的Storefile。当 Storefile 越来越大，Region 也会越来越大，达到阈值后，会触发 Split 操作，将 Region 一分为二。

StoreFile 是只读的，一旦创建后就不可以再修改。因此 HBase 的更新/修改其实是不断追加 的操作。
Client 写入 -> 存入 MemStore，一直到 MemStore 满 -> Flush 成一个 StoreFile，直至增长到 一定阈值 -> 触发 Compact 合并操作 -> 多个 StoreFile 合并成一个 StoreFile，同时进行版本 合并和数据删除 -> 当 StoreFiles Compact 后，逐步形成越来越大的 StoreFile -> 单个 StoreFile 大小超过一定阈值后，触发 Split 操作，把当前 Region Split 成 2 个 Region，Region 会下线， 新 Split 出的 2 个孩子 Region 会被 Master 分配到相应的 RegionServer 上，使得原先 1 个 Region 的压力得以分流到 2 个 Region 上由此过程可知，HBase 只是增加数据，有所得更新和删除操作，都是在 Compact 阶段做的，所以，用户写操作只需要进入到内存即可立即返回，从而保证 I/O 高性能。