Hbase--高级shell的使用

Hbase–高级shell的使用

文章目录

Hbase--高级shell的使用1、 BLOOMFILTER2、 VERSIONS3、 COMPRESSION4、 TTL5、 alter6、 describe/desc7、 disable_all/enable_all/drop_all （禁用/启用/删除所有）8、 hbase 预分区命令方式API方式UI上查看结果

1、 BLOOMFILTER

是否使用布隆过虑及使用何种方式，布隆过滤可以每列族单独启用

使用 HColumnDescriptor.setBloomFilterType(NONE | ROW | ROWCOL) 对列族单独启用布隆

默认是 NONE ,不采用BLOOMFILTERDefault = ROW 对行进行布隆过滤对 ROW，行键的哈希在每次插入行时将被添加到布隆对 ROWCOL，行键 + 列族 + 列族修饰的哈希将在每次插入行时添加到布隆

使用方法:

create 'table',{BLOOMFILTER =>'ROW'}

作用：用布隆过滤可以节省读磁盘过程，可以有助于降低读取延迟

2、 VERSIONS

默认是 1 这个参数的意思是数据保留 1 个 版本，如果我们认为我们的数据没有这么大 的必要保留这么多，随时都在更新，而老版本的数据对我们毫无价值，那将此参数设为 1 能 节约 2/3 的空间

使用方法:

create 'table',{VERSIONS=>'2'}

附：MIN_VERSIONS => '0’是说在 compact 操作执行之后，至少要保留的版本

3、 COMPRESSION

默认值是 NONE 即不使用压缩，这个参数意思是该列族是否采用压缩，采用什么压缩算

法，使用方法:

create 'table',{NAME=>'info',COMPRESSION=>'SNAPPY'}

建议采用 SNAPPY 压缩算 法 ，HBase 中，在 Snappy 发布之前（Google 2011 年对外发布 Snappy），采用的 LZO 算法，

目标是达到尽可能快的压缩和解压速度，同时减少对 CPU 的消耗； 在 Snappy 发布之后，建议采用 Snappy 算法（参考《HBase: The Definitive Guide》），具体 可以根据实际情况对 LZO 和 Snappy 做过更详细的对比测试后再做选择

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pOZmVOhs-1572528532855)(D:\图片\压缩算法.png)]

如果建表之初没有压缩，后来想要加入压缩算法，可以通过 alter 修改 schema

4、 TTL

默认是 2147483647 即：Integer.MAX_VALUE 值大概是 68 年 ,这个参数是说明该列族数据的存活时间，单位是 s ,这个参数可以根据具体的需求对数据设定存活时间，超过存过时间的数据将在表中不在 显示，待下次 major compact 的时候再彻底删除数据

注意:

TTL 设定之后 ,MIN_VERSIONS=>‘0’ 这样设置之后，TTL 时间戳过期后，将全部 彻底删除该 family 下所有的数据，如果MIN_VERSIONS 不等于 0 那将保留最新的 MIN_VERSIONS 个版本的数据，其它的全部删除，比如 MIN_VERSIONS=>‘1’ 届时将保留一个 最新版本的数据，其它版本的数据将不再保存。

5、 alter

使用方法：

如修改压缩算法

disable 'table' alter 'table',{NAME=>'info',COMPRESSION=>'snappy'} enable 'table'

但是需要执行 major_compact ‘table’ 命令之后 才会做实际的操作。

6、 describe/desc

这个命令查看了 create table 的各项参数或者是默认值。

使用方式：

describe 'user_info'

7、 disable_all/enable_all/drop_all （禁用/启用/删除所有）

使用方式：一般配合模糊查询使用

disable_all 'toplist.*'

drop_all，enable_all和 disable_all 的使用方式是一样的

8、 hbase 预分区

默认情况下，在创建 HBase 表的时候会自动创建一个 region 分区，当导入数据的时候， 所有的 HBase 客户端都向这一个 region 写数据，直到这个 region 足够大了才进行切分，这样会导致这个region压力过大。一 种可以加快批量写入速度的方法是通过预先创建一些空的 regions，这样当数据写入 HBase 时，会按照 region 分区情况，在集群内做数据的负载均衡。

命令方式

create "test_split","info01","info02",SPLITS => ['rk10000','rk20000','rk30000']

SPLITS ：制定分区的分隔点 ，rk的分隔点 region0 <=rk10000 region1 rk10000-rk20000 region2 rk20000-rk30000 region3 >=rk30000

API方式

byte[][] splits={"rk10000".getBytes(),"rk20000".getBytes()}; admin.createTable(htd, splits); 或者 admin.createTable(htd,startkey,endkey,splitNum); admin.createTable(htd, splits);

UI上查看结果

这样就可以将表预先分为 4个区，减少数据达到 storefile 大小的时候自动分区的时间 消耗，并且还有以一个优势，就是合理设计 rowkey 能让各个 region 的并发请求平均分配(趋 于均匀) 使 IO 效率达到最高，但是预分区需要将 filesize 设置一个较大的值，设置参数 hbase.hregion.max.filesize 这个值默认是 10G 也就是说单个 region 默认大小是 10G

这个参数的默认值在 0.90 到 0.92 到 0.94.3 各版本的变化：256M–1G–10G

但是如果 MapReduce Input 类型为 TableInputFormat 使用 hbase 作为输入的时候，就要注意 了，每个 region 一个 map，如果数据小于 10G 那只会启用一个 map 造成很大的资源浪费， 这时候可以考虑适当调小该参数的值，或者采用预分配 region 的方式，并将检测如果达到 这个值，再手动分配 region