一、Hbase的读写流程

1.组件说明

https://blog.csdn.net/m0_45993982/article/details/116424086

2.写数据流程

1. Client通过Zookeeper的调度，向RegionServer发出写数据请求，在Region中写数据。
2. 数据被写入Region的MemStore，知道MemStore达到预设阀值。
3. MemStore的数据被Flush成一个StoreFile。
4. 随着StoreFile文件不断增多，当数量增长到一定阀值后，出发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除。
5. StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile。
6. 单个Storefile大小超过一定阀值后，触发Split操作，把当前Region Split成2个新的Region。父Region会下线，新Split出的2个子Region会被HMaster分配到相应的RegionServer上，使得原先1个Region的压力得以分流到2个Region上。

3.读数据流程

1. Client访问Zookeeper，查找Root表，获取.META.表信息
2. 从.META.表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer
3. 通过RegionServer获取需要查找的数据
4. Regionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查找数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。

Hbase的所有region元数据被存储在.META表中，随着region的增多，.META表中的数据 也会增大，并分裂成多个新的region。
为了定位.META表中各个region的位置，把.META表中 的所有region的元数据保存在-ROOT-表中(1.0之后转移到zk的master目录)，最后由 zookeeper记录-ROOT-表的位置信息。所有的客户端访问数据之前，需要首先访问 zookeeper获取-ROOT-的位置，然后访问-ROOT-表获得.META表的位置，最后根据.META表中 的信息确定用户数据存放的位置。
-ROOT-表永远不会被分割，它只有一个region，这样可以保证最多只需要三次跳转就可 以定位任意一个region。为了加快访问速度，.META表的所有region全部保存在内存中。客 户端会将查询过的位置信息缓存起来，且缓存不会主动失效。
如果客户端根据缓存信息还访问 不到数据，则询问相关.META表的region服务器，试图获取数据的位置，如果还是失败，则询 问-ROOT-表相关的.META表在哪里。最后，如果前面的信息全部失效，则通过zookeeper重新 定位region的信息。所以如果客户端上的缓存全部失效，则需要进行6次网络来定位，才能定位到正确的region。

二、API操作

1.HBASE服务的连接

1.下载maven并导入maven依赖

<dependency> 
	<groupId>org.apache.hbase</groupId> 
	<artifactId>hbase-client</artifactId> 
	<version>1.2.1</version> 
</dependency>

2.修改hosts文件

https://blog.csdn.net/m0_45993982/article/details/116462100?spm=1001.2014.3001.5501

3.HBase服务连接代码

/*** 连接到HBase的服务 */ 
public class Demo1_Conn { 
	public static void main(String[] args) throws IOException { 
		//1. 获取连接配置对象 
		Configuration configuration = new Configuration(); 
		//2. 设置连接hbase的参数 
		configuration.set("hbase.zookeeper.quorum", "hdp01,hdp02,hdp03"); 
		//3. 获取Admin对象 
		HBaseAdmin hBaseAdmin = new HBaseAdmin(configuration); 
		//4. 检验指定表是否存在，来判断是否连接到
		hbase boolean flag = hBaseAdmin.tableExists("ns1:user_info"); 
		//5. 打印 
		System.out.println(flag); 
	} 
}

三、布隆过滤器

1. 布隆过滤器由来

Bloom filter 是由 Howard Bloom 在 1970 年提出的二进制向量数据结构，它具有很 好的空间和时间效率，被用来检测一个元素是不是集合中的一个成员。如果检测结果为是，该 元素不一定在集合中；但如果检测结果为否，该元素一定不在集合中。因此Bloom filter具有 100%的召回率。这样每个检测请求返回有“在集合内（可能错误）”和“不在集合内（绝对不在 集合内）”两种情况，可见 Bloom filter 是牺牲了正确率以节省空间。

2.布隆过滤器应用场景

3.布隆过滤器原理

它的时间复杂度是O(1)，但是空间占用取决其优化的方式。它是布隆过滤器的基础。 布隆过滤器（Bloom Filter）的核心实现是一个超大的位数组（或者叫位向量）和几个 哈希函数。假设位数组的长度为m，哈希函数的个数为k

以上图为例，具体的插入数据和校验是否存在的流程：
假设集合里面有3个元素{x, y, z}，哈希函数的个数为3。
Step1：将位数组初始化，每位都设置为0。
Step2：对于集合里面的每一个元素，将元素依次通过3个哈希函数进行映射，每次映射都会 产生一个哈希值，哈希值对应位数组上面的一个点，将该位置标记为1。
Step3：查询W元素是否存在集合中的时候，同样的方法将W通过哈希映射到位数组上的3个 点。
Step4：如果3个点的其中有一个点不为1，则可以判断该元素一定不存在集合中。反之，如果 3个点都为1，则该元素可能存在集合中。注意：此处不能判断该元素是否一定存在集合中，可 能存在一定的误判率。
可以从图中可以看到：假设某个元素通过映射对应下标为4，5，6这3个点。虽然这3个点 都为1，但是很明显这3个点是不同元素经过哈希得到的位置，因此这种情况说明元素虽然不在 集合中，也可能对应的都是1，这是误判率存在的原因。

四、寻址方式

第 1 步：Client 请求 ZooKeeper 获取.META.所在的 RegionServer 的地址。
第 2 步：Client 请求.META.所在的 RegionServer 获取访问数据所在的 RegionServer 地址，Client 会将.META.的相关信息 cache 下来，以便下一次快速访问。
第 3 步：Client 请求数据所在的 RegionServer，获取所需要的数据。