HBase - 建表语句解析

像所有其他数据库一样,HBase也有表的概念,有表的地方就有建表语句,而且建表语句还很大程度上决定了这张表的存储形式、读写性能。比如我们熟悉的MySQL,建表语句中数据类型决定了数据的存储形式,主键、索引则很大程度上影响着数据的读写性能。虽然HBase没有主键、索引这些概念,但在HBase的世界里,有些东西和它们一样重要!

废话不说,直接奉上一条HBase建表语句,来为各位看官分解剖析:

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

上述建表语句表示创建一个表名为“NewsClickFeedback”的表,该表只包含一个列簇“Toutiao”。接下来重点讲解其他字段的含义以及如何正确设置。Note:因为篇幅有限本文并不讲解具体的工作原理,后续会有相关专题对其进行分析。


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缓存,默认开启。


SPLITS

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

范欣欣

就职于网易杭州研究院后台技术中心数据库技术组,从事HBase开发、运维,对HBase相关技术有浓厚的兴趣。邮箱:libisthanks@gmail.com

在 “HBase - 建表语句解析” 上有 7 条评论

  1. Thici Coelho comentou em 20 de agosto de 2011 às 18:43. se quiser matar um Petisquete de ataque do coração, é só fazer esse &#0ƒÃ8;P22”. me coração ta acelarado até agora. mas esse pá vicia, as vezes, me pego fazendo. kkk.

  2. 拜读。一处错别字:布隆过滤器,优化HBase的随即读取性能,应为“随机”读取性能。
    另IN_MEMORY章节的意思是meta表元数据是常驻内存的吗?关于hbase:meta我也有不太清楚的地方,希望得到指点:通过阅读源码,我认为hbase:meta表是会split但是不会分布在多个regionserver上。不知道这个结论是否正确?
    依据是源码中查找hbase:meta表位置的代码直接返回的是FIRSE_META_REGION的位置,有first region说明hbase:meta表是会split的,能用第一个region地址来表示整个表的位置,说明meta表的region都是在一个rs上的。zookeeper节点/hbase/meta-region-server也能说明meta表的region不会存在于多个rs上。但我也看到一种说法是first meta region是用来查找其他meta region的索引,不知道哪种说法是正确的?

    1. 谢谢,‘随机’已经更正过来。IN_MEMORY表示常驻内存,用户如果在列族设置该参数为true,表示该列族对应的数据会常驻内存,一般建议如果是业务元数据,可以设置为常驻内存,另外,hbase:meta数据是常驻内存的。至于hbase:meta能不能执行split,本人在实际环境实际执行命令:split ‘hbase:meta’,结果还是一个region,并没有出现多个region,目前还是认为hbase:meta不能执行split。如果有更明确的说法的话还望告知!

发表评论

电子邮件地址不会被公开。 必填项已用*标注