HBase,一個最接近于關系型資料庫的Nosql非關系型資料庫
介紹
簡介
Hadoop Database,是一個高可靠性、高性能、面向列、可伸縮、實時讀寫的分布式資料庫;
Hadoop HDFS作為其檔案存盤系統,zookeeper作為其分布式協同服務 主要用來存盤非結構化和半結構化的松散資料
優點
-
容量大
-
面向列
-
多版本
-
稀疏性
-
拓展性
-
高可靠性
-
高性能
底層的LSM資料結構和RowKey有序排列等架構上的獨特設計,使得Hbase寫入性能非常高,
總結:資料量大,回應速度快
HBase資料結構
-
NameSpace
命名空間(相當于資料庫):為了保護表,創建的一個更高層級的單位;作為表的邏輯分組
-
Table
表(即為表): 存盤相同資料的一個邏輯單元
? 表有多個行資料組成,行有很多列組成
? Hbase是一個半結構的資料庫,所以每一行的列都有可能不同
-
RowKey
主鍵(一行資料的主鍵): Hbase按照列進行存盤,所以我們查詢資料的時候會看到很多RowKey相同的列RowKey可以看作為主鍵: 最多可以有64K位元組組成,一般能10-40個位元組即可
將來設計RowKey是HBase使用的重中之重? Rowkey存盤的時候默認以字典序排序
-
Column Family
列簇(多個列的集合): 方便佇列進行查找和管理
? 一個表的列簇需要在使用之前申明(創建表,后期維護表)
? 列隸屬于列簇,列簇隸屬于表
? 一個表中的列簇是固定的,但列簇中的列是不固定的
-
Column Qualifier
列:有可能有的資料行一個列簇中有3個列,有的資料行相同列簇有8個列
? 使用的時候必須是 列簇:列
-
TimeStamp
資料版本: 默認是時間戳,解決HDFS不能隨時修改資料的弊端
? 默認資料版本就是時間戳
? 查詢資料時默認顯示最新資料
-
Cell
資料:row,column family,column qualifier,version
所有的資料都是字串
HBase系統架構
-
Client
HBase的客戶端,可以向Hbase服務器發送請求
既可以是Shell,也可以是API
操作包括DDL,DML,DQL;HBase不支持多表關聯查詢
客戶端必要的時候會對資料進行一些快取
-
HMaster
HBase主節點,負責接收客戶端請求(僅限于DDL)
HMaster也可以實作高可用(active–standby),主備的切換由Zookeeper負責監督維護
但是HMasteri沒有聯邦機制,業務承載能力還是有限的
一個資料庫的表的結構很少會發生變化,絕大部分是CRUD操作,于是HBase的Master只負責DDL,DMLDQL由其他節點承擔
負責管理HRegionServer的健康狀況,上下線的監督----創建表的時候分配Region
-
HRegionServer
HBase的具體作業節點,一般一臺主機就是一個Regionserver
一個RegionServer包含很多的Region,HMaster負責分配Region
負責接收客戶端的DML和DQL請求,建立連接
-
HRegion
HBase表資料具體存盤位置
一個Region只隸屬于一張表,但是一張表可以含有多個Region
最開始宣告表的時候就會為這張表默認創建一個Region,隨著時間推移Region越來越大,將Region一分為二
-
Store
一個表中一個列簇對應一個Store
一個Store分為一個MemStore和N個StoreFile
Memstore:基于記憶體存放資料,每個Store大概分配128M記憶體空間
StoreFile:是檔案的硬碟存盤,直接存盤到HDFS,存到HDFS后稱為HFile
-
HLog
HBase的日志機制(WAL)
日志也會存到HDFS,在任何操作之前先存盤日志到HDFS
MemStore丟失資料或者RegionServer例外都能夠通過日志進行恢復
一個RegionServer對應一個HLog
-
Zookeeper
HBase協調服務
主備的選舉與切換
記錄當前集群的狀態資訊,當主備切換的時候,集群狀態可以被新主節點直接讀取到
記錄當前集群的資料存放資訊
存盤HBase的元資料資訊
HBase讀寫流程
HBase讀寫公共流程
1.HBase讀取資料/寫入資料
2.公共流程:
-
HBase0.96之前:首先系統維護了兩張表 -ROOT- .meta.
.meta. 表中存盤了 表 對應Region 對應的RegionServer RowKey的區間,但是 .meta.表也是一張普通的HBade表,也需要存放到RegionServer,
于是專門用-ROOT-表來記錄 .meta.的存放位置,認為ROOT表只需要一個Region即可,-ROOT-的Region資訊就被記錄到zookeeper
-
HBase0.96之后:系統只維護.meta. , Meta的位置資訊由Zookeeper守護
HBase讀取資料流程
-
尋址:RegionServer:node02/16020
-
開始和RegionServer建立連接
BlockCache,這是每個RegionServer內部共享的一塊區域
-
構建RegionScanner
優先從MemStore讀取資料
如果查找失敗,就去StoreFile中去查找
但是要注意,StoreFile有很多個,內部有序,外部無序
-
構建StoreScanner
MemStoreScanner
StoreFileScanner
HBase寫入資料流程
- 尋址:發現RowKey對應的RegionServer : node03/16020
- RegionServer:首先將操作寫入到日志
- 日志HLog:日志會存放到HDFS
- 將資料寫入到MemStore (new)
- 監聽器監聽MemStore狀態,判斷閾值(128M)
- 資料刷寫 MemStore(old)
- StoreFile
- 資料合并
- 資料切分
資料刷寫
刷寫時機
-
MemStore 記憶體閾值128M ;記憶體占用達512M(128M*4),阻塞客戶端寫入
-
RegionServer總記憶體的閾值
總記憶體 * 40% * 95%,整個RegionServer開始刷寫
-
Wal 日志閾值大小
插入資料——洗掉資料
-
自定義刷寫時間間隔
-
命令刷寫(手動刷寫)
刷寫策略
-
HBase1.1之前
MemStore刷寫是Region級別的,列簇不要超過三個
-
HBasw2.2之后
- Region中所有的MemStore都進行刷寫
- 設定一個閾值
- MemStore分兩類
刷寫流程
-
PrepareFlush
如果MemStore要進行刷寫,對記憶體中的資料進行拍攝快照,拍攝時間會非常短
拍攝期間記憶體中的資料會被鎖定,保證快照期間資料的安全
-
FlushCache
將快照的資料寫成一個臨時檔案到硬碟
將臨時檔案更名稱正式檔案存盤到對應列簇中
資料合并
合并的方式
-
minor(小型)
選取一些小的、相鄰的StoreFile將他們合并成一個更大的StoreFile
僅僅是合并不會處理被洗掉的或者失效的資料,但是會處理超過TTL的資料
一次Minor Compaction的結果是讓小的storefile變的更少并且產生更大的StoreFile
-
major(大型)
將所有的StoreFile合并成一個StoreFile
清理三類無意義資料:被洗掉的資料、TTL過期資料、版本號超過設定版本號的資料,
但是對整個集群影響較大,—般手動合并
合并時機
-
MemStoreFlush
Store的StoreFile檔案數進行判斷,判斷是否達到合并的閾值(檔案數量為10個)
-
周期性檢測
默認定義一個合并的周期1000os如果達到閾值也會檢查檔案的數目
如果檔案數目超過3個——>小合并
如果檔案不超過3個——>檢查最早一次合并的時間——>如果超過7天會進行大合并
-
手動觸發
低峰期手動觸發
執行完alter操作之后希望立刻生效,執行手動觸發major compaction
HBase管理員發現硬碟容量不夠的情況下手動觸發major compaction洗掉大量過期資料
合并策略
-
選擇執行緒
2 * maxFlilesToCompact * hbase.hregion.memstore.flush.size 2.5G
超過LongCompact
小于ShortCompact
-
Minor合并
RatioBasedCompactionPolicy
比較大一點的檔案不會參與到合并
ExploringCompactionPolicy
資料切分
切分方式
最開始一個表只有一個Region
對于這個表的查詢都會被定位到這—個RegionServer
當Region達到閾值的時候就會進行切分
單點壓力讀寫性能合并困難
切分時機
每次資料合并之后,發起一個requestSplit,然后開始檢查檔案的大小是否達到閾值
-
ConstantSizeRegionSplitPolicy
10G
-
lncreasingToUpperBoundRegionSplitPolicy
256M
2048M —,,,, —10G
切分策略
-
尋找切分點
先找最大的Store,然后再找最大的StoreFile,再找到中心位置的RowKey
-
切分流程
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/390611.html
標籤:其他
