hbase建表create高级属性 //hbase 表预分区也就是手动分区 这个很重要

2019/2/19 星期二

hbase建表create高级属性 //hbase 表预分区也就是手动分区 这个很重要

下面几个shell 命令在后续的hbase 操作中可以起到很到的作用，且主要体现在建表的过程中，看下面几个create 属性
1、BLOOMFILTER 默认是NONE 是否使用布隆过虑使用何种方式
布隆过滤可以每列族单独启用。使用HColumnDescriptor.setBloomFilterType(NONE |ROW | ROWCOL) 对列族单独启用布隆。Default = NONE 没有布隆过滤。对ROW，行键的哈希在每次插入行时将被添加到布隆。对ROWCOL，行键+ 列族+ 列族修饰的哈希将在每次插入行时添加到布隆
使用方法: create 'table',{BLOOMFILTER =>'ROW'}
启用布隆过滤可以节省必须读磁盘过程，可以有助于改进读取延迟

2、VERSIONS 默认是3 这个参数的意思是数据保留三个版本，如果我们认为我们的数据没有这么大的必要保留这么多，随时都在更新，而老版本的数据对我们毫无价值，那将此参数设为1 能节约2/3 的空间
使用方法: create 'table',{VERSIONS=>'2'}

3、COMPRESSION 默认值是NONE 即 不使用压缩
这个参数意思是该列族是否采用压缩，采用什么压缩算法
使用方法: create 'table',{NAME=>'info',COMPRESSION=>'SNAPPY'}
我建议采用SNAPPY 压缩算法，个压缩算法的比较网上比较多，我从网上摘抄一个表格作为参考，具体的snappy 的安装后续会以单独章节进行描述。
这个表是Google 几年前发布的一组测试数据，实际测试Snappy 和下表所列相差无几。HBase 中，在Snappy 发布之前（Google 2011 年对外发布Snappy），采用的LZO 算法，
目标是达到尽可能快的压缩和解压速度，同时减少对CPU 的消耗；在Snappy 发布之后，建议采用Snappy 算法（参考《HBase: The Definitive Guide》），具体可以根据实际情况对LZO 和Snappy 做过更详细的对比测试后再做选择。
Algorithm（算法） % remaining（剩余） Encoding（编码） Decoding（解码）
GZIP 13.4% 21 MB/s 118 MB/s
LZO 20.5% 135 MB/s 410 MB/s
Zippy/Snappy 22.2% 172 MB/s 409 MB/s
如果建表之初没有压缩，后来想要加入压缩算法，怎么办hbase 有另外的一个命令alter

4、alter
使用方法：
如修改压缩算法
disable 'table'
alter 'table',{NAME=>'info',COMPRESSION=>'snappy'}
enable 'table'
删除列族
disable 'table'
alter 'table',{NAME=>'info',METHOD=>'delete'}
enable 'table'
但是这样修改之后发现表数据还是那么大，并没有发生多大变化。怎么办
major_compact 'table' 命令之后才会做实际的操作。

5、TTL 默认是2147483647 即:Integer.MAX_VALUE 值大概是68 年
这个参数是说明该列族数据的存活时间也就是数据的生命周期单位是s 默写文章写的单位是ms 是错误的。
这个参数可以根据具体的需求对数据设定存活时间，超过存过时间的数据将在表中不在显示，待下次major compact 的时候再彻底删除数据
为什么在下次major compact 的时候删除数据，后面会具体介绍到。
注意的是TTL 设定之后MIN_VERSIONS=>'0' 这样设置之后，TTL 时间戳过期后，将全部彻底删除该family 下所有的数据，如果MIN_VERSIONS 不等于0 那将保留最新的MIN_VERSIONS 个版本的数据，其它的全部删除，比如MIN_VERSIONS=>'1' 届时将保留一个最新版本的数据，其它版本的数据将不再保存。

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

7、disable_all 'toplist.*' disable_all 支持正则表达式，并列出当前匹配的表的如下：
toplist_a_total_1001
toplist_a_total_1002
toplist_a_total_1008
toplist_a_total_1009
toplist_a_total_1019
toplist_a_total_1035
...
Disable the above 25 tables (y/n)? 并给出确认提示

8、drop_all 这个命令和disable_all 的使用方式是一样的

9、hbase 表预分区也就是手动分区
默认情况下，在创建HBase 表的时候会自动创建一个region 分区，当导入数据的时候，所有的HBase 客户端都向这一个region 写数据，直到这个region 足够大了才进行切分。一种可以加快批量写入速度的方法是通过预先创建一些空的regions，这样当数据写入HBase时，会按照region 分区情况，在集群内做数据的负载均衡。
使用方法:create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
也可以使用api 的方式
hbase org.apache.hadoop.hbase.util.RegionSplitter test_table HexStringSplit -c 10 -f info
参数很容易看懂test_table 是表名HexStringSplit 是split 方式 -c 是分10 个region -f 是family（列族）

这样就可以将表预先分为10个区，减少数据达到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 的方式，并将
hbase.hregion.max.filesize 设为一个相对比较大的值，不容易达到的值比如1000G，检测如果达到这个值，再手动分配region。

前面说到了compact 为什么设置了TTL 超过存活时间的数据就消失了，是如何消失的呢？是删除了吗？通过哪些参数删除的。
后面将要说到hbase compact

例如建表语句为： //生产上，可以用于这样去创建hbase表
hbase(main):009:0> create 'NewsClickFeedback',{NAME=>'Toutiao',VERSIONS=>1,BLOCKCACHE=>true,BLOOMFILTER=>'ROW',COMPRESSION=>'SNAPPY',TTL => 2592000 },{SPLITS => ['1','2','a','b']}

提示：NAME=>'Toutiao' 列族为 Toutiao ；VERSIONS=>1 版本号为1 ；是否开启block cache缓存，默认开启。；
BLOOMFILTER=>'ROW' 布隆过滤器，优化HBase的随机读取性能，可选值NONE|ROW|ROWCOL，默认为NONE，该参数可以单独对某个列簇启用。COMPRESSION=>'SNAPPY' 压缩；过期时间 TTL => 2592000 为30天
{SPLITS => ['1','2','a','b']} 分区；一般采用hash + partition的方式预分配region，比如示例中rowkey首先使用md5 hash，然后再按照首字母partition为4份，就可以预分配4个region。

插入数据
put 'NewsClickFeedback', '1', 'Toutiao:name', 'zhangsan'
put 'NewsClickFeedback', '01', 'Toutiao:name', 'lisi'
put 'NewsClickFeedback', '100', 'Toutiao:name', 'wangwu'
put 'NewsClickFeedback', '4', 'Toutiao:name', 'liuliu'

IN_MEMORY
数据是否常驻内存，默认为false。HBase为频繁访问的数据提供了一个缓存区域，缓存区域一般存储数据量小、访问频繁的数据，常见场景为元数据存储。默认情况，该缓存区域大小等于Jvm Heapsize 0.2 0.25 ，假如Jvm Heapsize = 70G，存储区域的大小约等于3.2G。需要注意的是HBase Meta元数据信息存储在这块区域，如果业务数据设置为true而且太大会导致Meta数据被置换出去，导致整个集群性能降低，所以在设置该参数时需要格外小心。
//
IN_MEMORY表示常驻内存，用户如果在列族设置该参数为true，表示该列族对应的数据会常驻内存，一般建议如果是业务元数据，可以设置为常驻内存，另外，hbase:meta数据是常驻内存的。至于hbase:meta能不能执行split，本人在实际环境实际执行命令:split ‘hbase:meta’，结果还是一个region，并没有出现多个region，目前还是认为hbase:meta不能执行split。
HBase BlockCache系列 – 走进BlockCache http://hbasefly.com/2016/04/08/hbase-blockcache-1/ 在此链接中提到了IN_MEMORY=true
//而in-memory区表示数据可以常驻内存，一般用来存放访问频繁、数据量小的数据，比如元数据，用户也可以在建表的时候通过设置列族属性IN-MEMORY= true将此列族放入in-memory区。

blocksize
HFile会被切分为多个大小相等的block块，每个block的大小可以在创建表列簇的时候通过参数blocksize ＝> ‘65535’进行指定，默认为64k，大号的Block有利于顺序Scan，小号Block利于随机查询，因而需要权衡。
//如果业务请求以Get请求为主，可以考虑将块大小设置较小；如果以Scan请求为主，可以将块大小调大；默认的64K块大小是在Scan和Get之间取得的一个平衡

参考链接为：HBase － 建表语句解析 http://hbasefly.com/2016/03/23/hbase_create_table/
HBase(八): 表结构设计优化：https://www.cnblogs.com/tgzhu/archive/2016/09/11/5862299.html