HBase-建表语句

最新推荐文章于 2024-09-25 22:35:39 发布

cm_chenmin

最新推荐文章于 2024-09-25 22:35:39 发布

阅读量1w

点赞数

分类专栏： hbase 文章标签： hbase 建表 create table

本文链接：https://blog.csdn.net/cm_chenmin/article/details/52849891

版权

hbase 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

建表语句：

create 'NewsClickFeedback',{NAME=>'Toutiao',VERSIONS=>1,BLOCKCACHE=>true,BLOOMFILTER=>'ROW',COMPRESSION=>'SNAPPY',
TTL => '259200', DATA_BLOCK_ENCODING => 'PREFIX_TREE', BLOCKSIZE => '65536'},
{SPLITS => ['1','2','3','4','5','6','7','8','9','a','b','c','d','e','f']}

上述建表语句表示创建一个表名为“NewsClickFeedback”的表，该表只包含一个列簇“Toutiao”。接下来重点讲解其他字段的含义以及如何正确设置。

VERSIONS

数据版本数，HBase数据模型允许一个cell的数据为带有不同时间戳的多版本数据集，VERSIONS参数指定了最多保存几个版本数据，默认为1。假如某个用户想保存两个历史版本数据，可以将VERSIONS参数设置为2，再使用如下Scan命令就可以获取到所有历史数据：

scan 'NewsClickFeedback',{VERSIONS => 2}

BLOOMFILTER

布隆过滤器，优化HBase的随即读取性能，可选值NONE|ROW|ROWCOL，默认为NONE，该参数可以单独对某个列簇启用。启用过滤器，对于get操作以及部分scan操作可以剔除掉不会用到的存储文件，减少实际IO次数，提高随机读性能。Row类型适用于只根据Row进行查找，而RowCol类型适用于根据Row+Col联合查找，如下：

Row类型适用于：get ‘NewsClickFeedback’,’row1′

RowCol类型适用于：get ‘NewsClickFeedback’,’row1′,{COLUMN => ‘Toutiao’}

对于有随机读的业务，建议开启Row类型的过滤器，使用空间换时间，提高随机读性能。

COMPRESSION

数据压缩方式，HBase支持多种形式的数据压缩，一方面减少数据存储空间，一方面降低数据网络传输量进而提升读取效率。目前HBase支持的压缩算法主要包括三种：GZip | LZO | Snappy，Snappy的压缩率最低，但是编解码速率最高，对CPU的消耗也最小，目前一般建议使用Snappy

TTL

数据过期时间，单位为秒，默认为永久保存。对于很多业务来说，有时候并不需要永久保存某些数据，永久保存会导致数据量越来越大，消耗存储空间是其一，另一方面还会导致查询效率降低。如果设置了过期时间，HBase在Compact时会通过一定机制检查数据是否过期，过期数据会被删除。用户可以根据具体业务场景设置为一个月或者三个月。示例中TTL => ‘259200’设置数据过期时间为三天

IN_MEMORY

数据是否常驻内存，默认为false。HBase为频繁访问的数据提供了一个缓存区域，缓存区域一般存储数据量小、访问频繁的数据，常见场景为元数据存储。默认情况，该缓存区域大小等于Jvm Heapsize * 0.2 * 0.25 ，假如Jvm Heapsize = 70G，存储区域的大小约等于3.2G。需要注意的是HBase Meta元数据信息存储在这块区域，如果业务数据设置为true而且太大会导致Meta数据被置换出去，导致整个集群性能降低，所以在设置该参数时需要格外小心。

BLOCKCACHE

是否开启block cache缓存，默认开启。

BLOCKSIZE

块大小是HBase的一个重要配置选项，默认块大小为64M。对于不同的业务数据，块大小的合理设置对读写性能有很大的影响,如果业务请求以Get请求为主，可以考虑将块大小设置较小；如果以Scan请求为主，可以将块大小调大；默认的64M块大小是在Scan和Get之间取得的一个平衡

Compress/DeCompress

数据压缩是HBase提供的另一个特性，HBase在写入数据块到HDFS之前会首先对数据块进行压缩，再落盘，从而可以减少磁盘空间使用量。而在读数据的时候首先从HDFS中加载出block块之后进行解压缩，然后再缓存到BlockCache，最后返回给用户
设计原则：
1. 在任何场景下开启prefix_tree编码都是安全的
2. 在任何场景下都不要同时开启snappy压缩和prefix_tree编码
3. 通常情况下snappy压缩并不能比prefix_tree编码获得更好的优化结果，如果需要使用snappy需要针对业务数据进行实际测试

SPLITS

region预分配策略。通过region预分配，数据会被均衡到多台机器上，这样可以一定程度上解决热点应用数据量剧增导致系统自动split引起的性能问题。HBase数据是按照rowkey按升序排列，为避免热点数据产生，一般采用hash + partition的方式预分配region，比如示例中rowkey首先使用md5 hash，然后再按照首字母partition为16份，就可以预分配16个region。

本文参考：
http://codecloud.net/14132.html
http://www.th7.cn/db/nosql/201603/181519.shtml