基本概念：

HBase是列簇式Key-Value存儲系統，構建在HDFS之上的、支持隨機插入和刪除。

總結Hbase的架構核心，就兩個字“有序” 。

磁盤的讀寫，隨機與順序，相差3個數量級（也就是300倍左右）【注意這里與存儲介質無關】

邏輯上：

rowkey（行鍵）：唯一標識一行數據。 （等同于RDMS中主鍵）

column family（列簇）：包含多個列，組成一個簇。

column qualifier（列標識）：表的每列數據可通過family:qualifier唯一標識

timestamp（數據版本）：cell內部數據是多版本的，時間戳作為版本號。（默認最大保留三個版本，如果讀取數據時未指定版本號，只會返回最新版本的值）

可以將[rowkey, column family, coluomn qualifier, timestamp]看做key，cell的值為value。

物理上：

Hbase 是由三種類型的 server 組成的的主從式（master-slave）架構：

Region Server 負責處理數據的讀寫請求，客戶端請求數據時直接和 Region Server 交互。（每個 Region Server 可以管理約 1000 個 regions（它們可能來自一張表或者多張表））

HBase Master 負責 Region 的分配，DDL（創建，刪除 table）等操作。

Zookeeper，作為 HDFS 的一部分，負責維護集群狀態。

---

存儲結構：

rowkey

按照rowkey的范圍[startKey, endKey]，將數據劃分成多個region(類似于分區)，每個 region 的默認大小為 1GB。

HBase 表中的數據是按照rowkey數據字典順序升序排列。

rowkey既要方便查找和定位，又要保證數據均衡分布在RegionServer上(分區均勻)，避免數據熱點、數據傾斜。

column family

相同的列簇的數據會分開存儲在不同的目錄下。

Region Server的內存主要分為兩部分

Memstore，主要用作寫緩存；（每個 Region 的每個 Column Family 都會有一個 MemStore）

BlockCache，主要用作讀緩存；（Block是HBase中最小的數據存儲單元，默認為64K，HBase會將一次文件查找的Block塊緩存到Cache中，以便后續同一請求或者鄰近數據查找請求）

默認情況下，BlockCache和Memstore的配置各占40%。

---

為何如此快

順序寫入，與順序讀取，是最重要的。

推數快（write）：

• WAL：（Write Ahead Log） 是分布式文件系統上的一個文件，用于存儲新的還未被持久化存儲的數據，它被用來做故障恢復。
• MemStore：（寫緩存），在內存中存儲了新的還未被持久化到硬盤的數據。當被寫入硬盤時，數據會首先被排序，注意每個 Region 的每個 Column Family 都會有一個 MemStore。
• 視覺層面的快，內部并未持久化：

新數據會被追加到 WAL 文件尾部；

然后加入Memstore，停駐內存中；（Region Server會給每個region提供一個Memstore）

觸發持久化兩種情況：

溢出：當Memstore滿128M(hbase.hregion.memstore.flush.size)以后，會啟動flush刷新到磁盤。

當Memstore的總大小超過限制時（heapsizehbase.regionserver.global.memstore.upperLimit0.9），會強行啟動flush進程，從最大的Memstore開始逐個flush。

取數快（read）：

• • Meta table（它其實是一張特殊的 HBase 表），包含了集群中所有 regions 的位置信息。Zookeeper 保存了這個 Meta table 的位置
  • 因為使用了LSM樹型結構。
  • 客戶端讀寫數據，實際上分了兩步（強一致性保證）
    • 定位：從 Meta table 獲取 rowkey 屬于哪個 Region Server 管理。
    • 取數：去相應的 Region Server 讀寫數據。

從 Block Cache 讀取 cells。（最近讀取的 KeyValue 都被緩存在這里，這是 一個 LRU 緩存）

若取不到，則讀MemStore，即寫緩存。（包含了最近更新的數據）

沒有在 Block Cache 和 Mem Store 都沒找到對應的 cells，則 HBase 會使用 Block Cache 中的索引和布隆過濾器來加載對應的 HFile 到內存，查找到請求的 row cells。

---

內部優化：

內存孔洞問題，MemStore刷寫數據到磁盤，產生的問題：
RegionServer內存碎片增多，當生存時間較長的數據從堆的老年代空間刷寫到磁盤，內存碎片增多，連續存儲空間減少，就會產生內存孔洞。

解決方案： 啟用本地memstore分配緩存區（Memstore-Local Allocation Buffers，MSLAB），也就是允許從堆中分配相同大小的對象，一旦這些對象分配并且最終被回收，就會在堆中留下固定大小的孔洞，這些孔洞可被重復利用，GC就無需使應用程序進程停頓來回收內存空間

2. 讀放大（read amplification），每個 MemStore 可能會有多個 HFile：

解決方案：minor compaction，HBase 會自動合并一些小的 HFile，重寫成少量更大的 HFiles，它使用歸并排序算法，將小文件合并成大文件，有效減少 HFile 的數量。

3.寫放大（Write Amplification），major compaction 會重寫所有的 HFile，會產生大量的硬盤 I/O 和網絡開銷，它會將那些遠方的數據重新移回到離 region server 節點附近的地方。

4. region分裂（split）

一開始每個 table 默認只有一個 region。當一個 region 逐漸變得很大時，它會分裂（split）成兩個子 region，每個子 region 都包含了原來 region 一半的數據。

這兩個子 region 并行地在原來這個 region server 上創建，這個分裂動作會被報告給 HMaster。處于負載均衡的目的，HMaster 可能會將新的 region 遷移給其它 region server。

5. 字段占用空間，盡量小：

每行數據中不同版本的cell value會重復保存【rowkey,column family,column qualifier】，數據在進行持久化到HFile文件時、讀緩存(BlockCache)、寫緩存(MemStore)都會用這幾個字段，為了節省存儲空間、內存空間和網絡傳輸數據量，這幾個字段值應盡可能短。

rowkey的設計就要在讀寫性能、數據熱點、范圍掃描之間進行取舍的藝術。

---

3種Block Cache方案：

1. LRUBlockCache是最初的實現方案，也是默認的實現方案。

a. 將所有數據都放入JVM Heap中，交給JVM進行管理。

b. 將內存從邏輯上分為了三塊：single-access區、mutil-access區、in-memory區，分別占到整個BlockCache大小的25%、50%、25%。

c. 一次隨機讀中，一個Block塊從HDFS中加載出來之后首先放入signle區。

d. 后續如果有多次請求訪問到這塊數據的話，就會將這塊數據移到mutil-access區。

e. 而in-memory區表示數據可以常駐內存，一般用來存放訪問頻繁、數據量小的數據，比如元數據，用戶也可以在建表的時候通過設置列族屬性IN-MEMORY= true將此列族放入in-memory區。

2. SlabCache，HBase 0.92版本實現了第二種方案。(已廢棄)

a. SlabCache BucketCache 這兩種采用了不同機制將部分數據存儲在堆外，交給HBase自己管理

3. BucketCache， HBase 0.96之后官方提供了另一種可選方案。（阿里提供的方案）

a. 這種演變過程是因為LRUBlockCache方案中JVM垃圾回收機制經常會導致程序長時間暫停，而采用堆外內存對數據進行管理可以有效避免這種情況發生。

b. 在初始化的時候就申請了一片固定大小的內存作為緩存，緩存淘汰不再由 JVM管理，數據Block的緩存操作只是對這片空間的訪問和覆蓋，因而大大減少了內存碎片的出現，降低了Full GC發生的頻率。

總結

以上是生活随笔為你收集整理的hbase中为何不能向表中插入数据_Hbase快速入门（超精炼总结）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。