hbase是一種分布式、可擴展、支持海量數據存儲的nosql數據庫。分布式是因為hbase底層使用hdfs存儲數據,可擴展也是基于hdfs的橫向擴展能力,作為大數據的存儲當然支持海量數據的存儲,nosql非關系型數據庫表結構和關系型數據庫(如mysql)的邏輯結構、物理結構很不一樣,性質特點、應用場景也不一樣。
1、邏輯結構
1)name space
命名空間,類似于關系型數據庫的 databbase 概念,每個命名空間下有多個表。hbase有兩個自帶的命名空間,分別是 hbase 和 default,hbase 中存放的是 hbase 內置的表,default 表是用戶默認使用的命名空間。
2)region
類似于關系型數據庫的表概念。不同的是,hbase 定義表時只需要聲明列族即可,不需要聲明具體的列。這意味著,往 hbase 寫入數據時,字段可以動態、按需指定。因此,和關系型數據庫相比,hbase 能夠輕松應對字段變更的場景。
3)row
hbase 表中的每行數據都由一個 rowkey 和多個 column(列)組成,數據是按照 rowkey的字典順序存儲的,并且查詢數據時只能根據 rowkey 進行檢索,所以 rowkey 的設計十分重要。
4)column
hbase 中的每個列都由 column family(列族)和 column qualifier(列限定符)進行限定,例如 info:name,info:age。建表時,只需指明列族,而列限定符無需預先定義。
5)time stamp
用于標識數據的不同版本(version),每條數據寫入時,如果不指定時間戳,系統會自動為其加上該字段,其值為寫入 hbase 的時間。
6)cell
由{rowkey, column family:column qualifier, time stamp} 唯一確定的單元。cell 中的數據是沒有類型的,全部是字節碼形式存貯。
2、物理結構
1)region server
region server 為 region 的管理者,其實現類為 hregionserver,主要作用如下:對于數據的操作:get, put, delete;對于 region 的操作:splitregion、compactregion。
2)master
master 是所有 region server 的管理者,其實現類為 hmaster,主要作用如下:對于表的操作:create, delete, alter對于 regionserver的操作:分配 regions到每個regionserver,監控每個 regionserver的狀態,負載均衡和故障轉移。
3)zookeeper
hbase 通過 zookeeper 來做 master 的高可用、regionserver 的監控、元數據的入口以及集群配置的維護等工作。
4)hdfs
hdfs 為 hbase 提供最終的底層數據存儲服務,同時為 hbase 提供高可用的支持。
3、增刪改查
初學或者測試階段對hbase操作可以使用hbase shell
。增刪改查等基本命令如下:
(1)創建表
1
|
create 'test' , 'cf' |
test是表名,cf是列族名,你會發現hbase的表在新建的時候并沒有地方讓你定義列(和關系型數據庫很不一樣吧)。這是因為hbase中的列全部都是靈活的,可以隨便定義的。列只有在你插入第一條數據的時候才會生成。那么表的屬性在哪里定義呢?其實hbase的所有數據屬性都是定義在列族上的。
(2)查看表屬性
1
|
describe 'test' |
輸出:
hbase(main):002:0> desc 'test'
table test is enabled
test, {table_attributes => {durability => 'use_default', metadata => {'is_root'
=> 'false', 'lindorm_table_attrs' => '\x00\x08\x00\x00\x00\x16wal_edit_with_full
_row\x05false\x00\x00\x00\x0bconsistency\x08eventual\x00\x00\x00\x16leader_balan
ce_enabled\x01\xff\x00\x00\x00\x1ffull_row_edit_carry_latest_data\x04true\x00\x0
0\x00\x0fdynamic_columns\x04true\x00\x00\x00\x0fallow_filtering\x01\x00\x00\x00\
x00\x13leader_balance_type\x06single\x00\x00\x00\x12deferred_log_flush\x05false'
, 'tablemetaversion' => '`\xe4n\x0f'}}
column families description
{name => 'cf', versions => '1', evict_blocks_on_close => 'false', new_version_be
havior => 'false', keep_deleted_cells => 'false', cache_data_on_write => 'false'
, data_block_encoding => 'diff', ttl => 'forever', min_versions => '0', replicat
ion_scope => '0', bloomfilter => 'row', cache_index_on_write => 'false', in_memo
ry => 'false', cache_blooms_on_write => 'false', prefetch_blocks_on_open => 'fal
se', compression => 'zstd', blockcache => 'true', blocksize => '65536', metadata
=> {'storage_policy' => 'default', 'compress_tags' => 'true', 'dfs_replication'
=> '2', 'chs_promote_on_major' => 'true'}}
1 row(s)
took 0.2150 seconds
可以看出對表的描述不多,大量的是對列族的描述,列族更像是傳統關系數據庫中的表,而表本身反倒變成只是存放列族的空殼了。
(3)查看表
list
輸出:
hbase(main):001:0> list
table
test
test1
test2
test_ls
4 row(s)
took 0.6370 seconds
=> ["test", "test1", "test2", "test_ls"]
(4)插入數據
1
|
put 'test' , 'row1' , 'cf:name' , 'jack' |
這條語句的意思就是:往test表插入一個單元格。這個單元格的rowkey為row1,也就是說它是屬于row1這個行中的一個列。該單元格的列族為cf。該單元格的列名為name。數據值為jack。可見列是在插入數據的時候產生的,hbase中列可以自由擴展。表的結構中某一行可能沒有某個列,但數據并不以null替代,而是壓根沒有該單元格。這樣以稀疏k-v方式存儲數據可以大大壓縮數據存儲容量。
(5)掃描數據
1
|
scan 'test' |
輸出:
hbase(main):011:0> scan 'test'
row column+cell
row1 column=cf:name, timestamp=1625911358767, value=jack
1 row(s)
took 0.5670 seconds
scan命令類似于mysql中的select * from test
。
(6)查看數據
scan命令是批量讀取數據,查詢某個單元格的數據可以用get命令,
1
|
get 'test' , 'row1' , 'cf:name' |
由于hbase底層使用鍵值對存儲數據,查詢一個單元格的數據非常快,這和mysql也完全不同。
(7)刪除數據
1
|
delete 'test' , 'row1' , 'cf:name' |
hbase刪除記錄并不是真的刪除了數據,而是放置了一個墓碑標記(tombstone marker),把這個版本連同之前的版本都標記為不可見了。
(8)停用表
1
|
disable 'test' |
表刪除之前要停用表
(9)刪除表
1
|
drop 'test' |
4、應用場景
hbase采用的是key/value的存儲方式,這意味著,即使隨著數據量增大,也幾乎不會導致查詢的性能下降。凡事都不可能只有優點而沒有缺點。數據分析是hbase的弱項,因為對于hbase乃至整個nosql生態圈來說,基本上都是不支持表關聯的。
不適用的場景:主要需求是數據分析,比如做報表。單表數據量不超過千萬。建議使用mysql或者oracle數據庫。
適用的場景:單表數據量超千萬,而且并發還挺高。數據分析需求較弱,或者不需要那么靈活或者實時。
5、參考資料
到此這篇關于hbase列式存儲入門的文章就介紹到這了,更多相關hbase列式存儲內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家!
原文鏈接:https://blog.csdn.net/Andytl/article/details/118638776