一、Hbase的讀寫流程
1.元件說明
https://blog.csdn.net/m0_45993982/article/details/116424086
2.寫資料流程
- Client通過Zookeeper的排程，向RegionServer發出寫資料請求，在Region中寫資料。
- 資料被寫入Region的MemStore，知道MemStore達到預設閥值。
- MemStore的資料被Flush成一個StoreFile。
- 随着StoreFile檔案不斷增多，當數量增長到一定閥值後，出發Compact合并操作，将多個StoreFile合并成一個StoreFile，同時進行版本合并和資料删除。
- StoreFiles通過不斷的Compact合并操作，逐漸形成越來越大的StoreFile。
- 單個Storefile大小超過一定閥值後，觸發Split操作，把目前Region Split成2個新的Region。父Region會下線，新Split出的2個子Region會被HMaster配置設定到相應的RegionServer上，使得原先1個Region的壓力得以分流到2個Region上。
3.讀資料流程
- Client通路Zookeeper，查找Root表，擷取.META.表資訊
- 從.META.表查找，擷取存放目标資料的Region資訊，進而找到對應的RegionServer
- 通過RegionServer擷取需要查找的資料
- 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，擷取所需要的資料。