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