Hbase架構設計
HMaster
- 負責HBASE table和Region的元數據管理，包含表的創建、修改等
- 維護整個集羣的負載均衡
- 爲RegionServer分配Region
- 發現失效的region，並將失效的region分配到正常的RegionServer
- 當RegionServer失效時，協調對應Hlog的拆分
HRegionServer
- 負責數據的路由，數據的讀寫和持久化
- 是HBase的數據處理及計算的單元
- 管理master爲其分配的region
- 和底層HDFS進行數據存儲的交互
- Region變大以後的拆分以及StoreFile的合併
- regionserver要和DN一起部署
hregionserver內部管理了一系列的hregion對象，每個hregion對應table的一個region。hregion是多個store組成，是通過CF劃分的，則是一個store管理一個region上的一個CF。每個store是包含 1個memstore 0個或多個storefile組成。
Zookeeper
- 存儲meta表的地址，而不是內容！
- RegionServer主動向ZK註冊，使得master可隨時感知各個rs的健康狀態
- 避免master的單點故障（SPOF）
HbaseClient
- RPC機制
- client和master進行ddl管理類通信 和rs進行數據的dml操作類通信
Hlog
預寫日誌
MemStore
寫緩存
StoreFile
storefiles 合併後逐步形成越來越大的storefile文件，
當region內所有的storefile(hfile)的總大小超過 hbase.hregion.max.filesize觸發split,一個region變爲2個。 父region下線，新的split的2個region被hmaster分配到合適的rs機器上。
使得原先1個region的壓力分流到2個region上。
BlockCache
讀緩存，是rs級別 ，一個rs只有一個blockcache ,在rs啓動時 完成blockcache的初始化工作。
Meta表
首先說明存儲位置是記錄在zookeeper上的。
hbase(main):026:0> scan 'hbase:meta'
ROW COLUMN+CELL
hbase:namespace,,159 column=info:regioninfo, timestamp=1590821040270, value={ENC
0821039635.0be1ccc4d ODED => 0be1ccc4de45f61db028e2081d5d673b, NAME => 'hbase:na
e45f61db028e2081d5d6 mespace,,1590821039635.0be1ccc4de45f61db028e2081d5d673b.',
73b. STARTKEY => '', ENDKEY => ''}
hbase:namespace,,159 column=info:seqnumDuringOpen, timestamp=1590821040270, valu
0821039635.0be1ccc4d e=\x00\x00\x00\x00\x00\x00\x00\x02
e45f61db028e2081d5d6
73b.
hbase:namespace,,159 column=info:server, timestamp=1590821040270, value=xxx:60020
0821039635.0be1ccc4d
e45f61db028e2081d5d6
73b.
hbase:namespace,,159 column=info:serverstartcode, timestamp=1590821040270, value
0821039635.0be1ccc4d =1590821031895
e45f61db028e2081d5d6
73b.
xxx:orderinfo, column=info:regioninfo, timestamp=1590827295617, value={ENC
,1590826706747.2ce50 ODED => 2ce500c927ace1d96d365f4bdb3930c3, NAME =>
0c927ace1d96d365f4bd 'xxx:orderinfo,,1590826706747.2ce500c927ace1d96d365f4bdb3930c3
xxx:orderinfo,,15908 b3930c3. ', STARTKEY => '', ENDKEY => ''}
26706747.2ce500c927a column=info:seqnumDuringOpen, timestamp=1590827295617,
ce1d96d365f4bdb3930c value=\x00\x00\x00\x00\x00\x00\x00\x11
3.
xxx:orderinfo,,15908 column=info:server, timestamp=1590827295617, value=xxx:60020
26706747.2ce500c927a
ce1d96d365f4bdb3930c
3.
xxx:orderinfo,,15908 column=info:serverstartcode, timestamp=1590827295617, value
26706747.2ce500c927a =1590821031895
ce1d96d365f4bdb3930c3.
2 row(s) in 0.0260 seconds
hbase(main):027:0>
通過上面兩行的元數據信息，我們可以知道：
rowkey組成: ns:table,region start key,region id
region start key： 是region的第一個rowkey，這裏需要注意
a.這個地方爲空，就表明table是第一個region，並且這個region的start key end key 都是空，說明這個表只有一個region
b.在meta表，start key 靠前的region 會排在start key靠後的region的前面。
hbase的key是按照字段的順序來存放的 字典排序region id: 是region創建的時候的timestamp+.+region id
value組成:regioninfo 包含 start key end key
server 是分配在哪個rs節點上
寫流程
1、client先去zk獲取hbase:meta表所在的rs節點，在hbase:meta表根據rk確定所在的目標rs節點和region
2、hbase client將寫的請求進行預處理，並根據元數據寫入所在的rs節點；將請求發送給對應的rs,rs接收到寫的請求將數據進行解析：
先寫wal-->再寫對應的region的store的memstore，當memstore達到閾值，會異步的flush，將內存的數據寫入HFile文件注意： memstore是一個內存結構 是一個CF只有1個memstore，其中memstore裏面的數據也是對rk進行字典排序的
hbase是採取LSM樹架構，【天生的適合重寫輕讀的場景】
注意:
對hbase來說 put（更新）、delete操作，在服務端看來 都是寫操作。
put更新 是寫一條 最新版本數據
delete 是寫一條標記爲deleted的kv的數據
讀流程
a.先去zk獲取hbase:meta表所在的rs節點，在hbase:meta表根據讀rk確定所在的目標rs節點和region
b.將讀請求封裝，發送給目標的rs節點，進行處理。
先到memstore查數據，查不到再去blockcache查，再查不到就訪問磁盤的HFile讀數據。