这篇文章将为大家详细讲解有关 HBase 有哪些特性，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
1
可配置的数据块大小
HFile 数据块大小可以在列族层次设置。这个数据块不同于之前谈到的 HDFS 数据块。其默认值是
65,536 字节，或 64KB。数据块索引存储每个 HFile 数据块的起始键。数据块大小设置影响到数据块索引的大小。数据块越小，索引越大，从而占用更大内存空间。同时因为加载进内存的数据块更小，随机查找性能更好。但是如果你需要更好的序列扫描性能，那么一次能够加载更多 HFile 数据进入内存则更为合理，这意味着数据块应该设置为更大的值。相应地索引变小，你将在随机读性能上付出代价。
你可以在表实例化时设置数据块大小，如下所示：
hbase(main):002:0
create mytable ,
{NAME = colfam1 , BLOCKSIZE = 65536}
2 数据块缓存
把数据放进读缓存，但工作负载却经常不能从中获得性能提升——例如，如果一张表或表里的列族只被顺序化扫描访问或者很少被访问，你不会介意 Get 或 Scan 花费时间是否有点儿长。在这种情况下，你可以选择关闭那些列族的缓存。
如果你只是执行很多顺序化扫描，你会多次倒腾缓存，并且可能会滥用缓存把应该放进缓存获得性能提升的数据给排挤出去。如果关闭缓存，你不仅可以避免上述情况发生，而且可以让出更多缓存给其他表和同一表的其他列族使用。
数据块缓存默认是打开的。你可以在新建表或者更改表时关闭它：
hbase(main):002:0
create mytable ,
{NAME = colfam1 , BLOCKCACHE = false’}
3 激进缓存
你可以选择一些列族，赋予它们在数据块缓存里有更高的优先级（LRU 缓存）。如果你预期一个列族比另一个列族随机读更多，这个特性迟早用得上。这个配置也是在表实例化时设定：
hbase(main):002:0
create mytable ,
{NAME = colfam1 , IN_MEMORY = true}
IN_MEMORY 参数的默认值是 false。因为 HBase 除了在数据块缓存里保存这个列族相比其他列族更激进之外并不提供额外的保证，该参数在实践中设置为 true 不会变化太大。
4 布隆过滤器（Bloom filters）
数据块索引提供了一个有效的方法，在访问一个特定的行时用来查找应该读取的 HFile 的数据块。但是它的效用是有限的。HFile 数据块的默认大小是 64KB，这个大小不能调整太多。
如果你要查找一个短行，只在整个数据块的起始行键上建立索引无法给你细粒度的索引信息。例如，如果你的行占用 100 字节存储空间，一个 64KB 的数据块包含 (64 * 1024)/100 = 655.53 = ~700 行，而你只能把起始行放在索引位上。你要查找的行可能落在特定数据块上的行区间里，但也不是肯定存放在那个数据块上。这有多种情况的可能，或者该行在表里不存在，或者存放在另一个 HFile 里，甚至在 MemStore 里。这些情况下，从硬盘读取数据块会带来 IO 开销，也会滥用数据块缓存。这会影响性能，尤其是当你面对一个巨大的数据集并且有很多并发读用户时。
布隆过滤器允许你对存储在每个数据块的数据做一个反向测试。当某行被请求时，先检查布隆过滤器看看该行是否不在这个数据块。布隆过滤器要么确定回答该行不在，要么回答它不知道。这就是为什么我们称它是反向测试。布隆过滤器也可以应用到行里的单元上。当访问某列标识符时先使用同样的反向测试。
布隆过滤器也不是没有代价。存储这个额外的索引层次占用额外的空间。布隆过滤器随着它们的索引对象数据增长而增长，所以行级布隆过滤器比列标识符级布隆过滤器占用空间要少。当空间不是问 ti 时，它们可以帮助你榨干系统的性能潜力。
你可以在列族上打开布隆过滤器，如下所示：
hbase(main):007:0
create mytable ,
{NAME = colfam1 , BLOOMFILTER = ROWCOL}
BLOOMFILTER 参数的默认值是 NONE。一个行级布隆过滤器用 ROW 打开，列标识符级布隆过滤器用 ROWCOL 打开。行级布隆过滤器在数据块里检查特定行键是否不存在，列标识符级布隆过滤器检查行和列标识符联合体是否不存在。ROWCOL 布隆过滤器的开销高于 ROW 布隆过滤器。
5 生存时间（TTL）
应用系统经常需要从数据库里删除老数据。由于数据库很难超过某种规模，所以传统上数据库内建了许多灵活处理办法。例如，在 TwitBase 里你不愿意删除用户在使用应用系统期间生成的任何推帖。这些都是用户生成数据，将来有一天当你执行一些高级分析时可能有用。但是并不需要保存所有推帖用于实时访问。所以早于某个时间的推帖可以归档存放到平面文件里。
HBase 可以让你在数秒内在列族级别设置一个 TTL。早于指定 TTL 值的数据在下一次大合并时会被删除。如果你在同一单元上有多个时间版本，早于设定 TTL 的版本会被删除。你可以关闭 TTL 或者通过设置其值为 INT.MAX_VALUE (2147483647) 来让它永远打开（这是默认值）。你可以在建表时设置 TTL，如下所示：
hbase(main):002:0
create mytable , {NAME = colfam1 , TTL = 18000}
该命令在 colfam1 列族上设置 TTL 为 18,000 秒 = 5 小时。colfam1 里超过 5 小时的数据将会在下一次大合并时被删除。
6 压缩
HFile 可以被压缩并存放在 HDFS 上。这有助于节省硬盘 IO，但是读写数据时压缩和解压缩会抬高 CPU 利用率。压缩是表定义的一部分，可以在建表或模式改变时设定。除非你确定不会从压缩中受益，我们推荐你打开表的压缩。只有在数据不能被压缩或者因为某种原因服务器的 CPU 利用率有限制要求的情况下，有可能会关闭压缩特性。
HBase 可以使用多种压缩编码，包括 LZO、Snappy 和 GZIP。LZO[1] 和 Snappy[2] 是其中最流行的两种。Snappy 由 Google 在 2011 年发布，发布不久 Hadoop 和 HBase 项目开始提供支持。在此之前，选择的是 LZO 编码。Hadoop 使用的 LZO 原生库受 GPLv2 版权控制，不能放在 Hadoop 和 Hbase 的任何发行版里；它们必须单独安装。另一方面，Snappy 拥有 BSD 许可（BSD-licensed），所以它更容易和 Hadoop 和 HBase 发行版捆绑在一起。LZO 和 Snappy 的压缩比例和压缩 / 解压缩速度差不多。
当建表时你可以在列族上打开压缩，如下所示：
hbase(main):002:0 create mytable ,
{NAME = colfam1 , COMPRESSION = SNAPPY}
注意数据只在硬盘上是压缩的。在内存里（MemStore 或 BlockCache）或网络传输时是没有压缩的。
改变压缩编码的做法不应该经常发生，但是如果你的确需要改变某个列族的压缩编码，直接做就可以。你需要更改表定义，设定新压缩编码。此后合并时，生成的 HFile 全部会采用新编码压缩。这个过程不需要创建新表和复制数据。但你要确保直到改变编码后所有老 HFile 被合并后才能从集群中删除老编码函数库。
7 单元时间版本
HBase 在默认情况下每个单元维护三个时间版本。这个属性是可以设置的。如果你只需要一个版本，推荐你在设置表时只维护一个版本。这样系统就不会保留更新单元的多个时间版本。时间版本也是在列族级设置的，可以在表实例化时设定：
hbase(main):002:0 create mytable , {NAME = colfam1 , VERSIONS = 1}
你可以在同一个 create 语句里为列族指定多个属性，如下所示：
hbase(main):002:0 create mytable ,
{NAME = colfam1 , VERSIONS = 1, TTL = 18000}
你也可以指定列族存储的最少时间版本数，如下所示：
hbase(main):002:0 create mytable , {NAME = colfam1 , VERSIONS = 5,
MIN_VERSIONS = 1 }
在列族上同时设定 TTL 也是迟早有用的。如果当前存储的所有时间版本都早于 TTL，至少 MIN_VERSION 个最新版本会保留下来。这样确保在你的查询以及数据早于 TTL 时有结果返回。
关于“HBase 有哪些特性”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
六了个六
6666