开发规范（JAVA部分）
IN_MEMORY参数的默认值是false。因为HBase除了在数据块缓存里保存这个列族相比其他列族更激进之外并不提供额外的保证，该参数在实践中设置为true不会变化太大。
创建表的时候，可以通过HColumnDescriptor.setInMemory(true)将表放到RegionServer的缓存中，保证在读取的时候被cache命中。
5.2.7 布隆过滤器（Bloom filters）
数据块索引提供了一个有效的方法，在访问一个特定的行时用来查找应该读取的HFile的数据块。但是它的效用是有限的。HFile数据块的默认大小是64KB，这个大小不能调整太多。
如果你要查找一个短行，只在整个数据块的起始行键上建立索引无法给你细粒度的索引信息。例如，如果你的行占用100字节存储空间，一个64KB的数据块包含(64 * 1024)/100 = 655.53 = ~700行，而你只能把起始行放在索引位上。你要查找的行可能落在特定数据块上的行区间里，但也不是肯定存放在那个数据块上。这有多种情况的可能，或者该行在表里不存在，或者存放在另一个HFile里，甚至在MemStore里。这些情况下，从硬盘读取数据块会带来IO开销，也会滥用数据块缓存。这会影响性能，尤其是当你面对一个巨大的数据集并且有很多并发读用户时。
布隆过滤器允许你对存储在每个数据块的数据做一个反向测试。当某行被请求时，先检查布隆过滤器看看该行是否不在这个数据块。布隆过滤
本文档仅限内部使用，未经双方许可，请勿扩散到第三方。
第 30 页 共 40 页
开发规范（JAVA部分）
器要么确定回答该行不在，要么回答它不知道。这就是为什么我们称它是反向测试。布隆过滤器也可以应用到行里的单元上。当访问某列标识符时先使用同样的反向测试。
布隆过滤器也不是没有代价。存储这个额外的索引层次占用额外的空间。布隆过滤器随着它们的索引对象数据增长而增长，所以行级布隆过滤器比列标识符级布隆过滤器占用空间要少。当空间不是问题时，它们可以帮助你榨干系统的性能潜力。
你可以在列族上打开布隆过滤器，如下所示： hbase(main)> create
'mytable',{NAME=>'colfam1',BLOOMFILTER=>'ROWCOL'} BLOOMFILTER参数的默认值是NONE。一个行级布隆过滤器用ROW打开，列标识符级布隆过滤器用ROWCOL打开。行级布隆过滤器在数据块里检查特定行键是否不存在，列标识符级布隆过滤器检查行和列标识符联合体是否不存在。ROWCOL布隆过滤器的开销高于ROW布隆过滤器。
5.2.8 生存时间（TTL）
应用系统经常需要从数据库里删除老数据。由于数据库很难超过某种规模，所以传统上数据库内建了许多灵活处理办法。例如，在TwitBase里你不愿意删除用户在使用应用系统期间生成的任何推帖。这些都是用户生成数据，将来有一天当你执行一些高级分析时可能有用。但是并不
本文档仅限内部使用，未经双方许可，请勿扩散到第三方。
第 31 页 共 40 页
开发规范（JAVA部分）
需要保存所有推帖用于实时访问。所以早于某个时间的推帖可以归档存放到平面文件里。
HBase可以让你在数秒内在列族级别设置一个TTL。早于指定TTL值的数据在下一次大合并时会被删除。如果你在同一单元上有多个时间版本，早于设定TTL的版本会被删除。你可以关闭TTL或者通过设置其值为INT.MAX_VALUE (2147483647)来让它永远打开（这是默认值）。你可以在建表时设置TTL，如下所示： hbase(main)> create
'mytable',{NAME=>'colfam1',TTL=>'18000'}
该命令在colfam1列族上设置TTL为18,000秒=5小时。colfam1里超过5小时的数据将会在下一次大合并时被删除。
5.2.9 数据压缩
HFile可以被压缩并存放在HDFS上。这有助于节省硬盘IO，但是读写数据时压缩和解压缩会抬高CPU利用率。压缩是表定义的一部分，可以在建表或模式改变时设定。除非你确定不会从压缩中受益，我们推荐你打开表的压缩。只有在数据不能被压缩或者因为某种原因服务器的CPU利用率有限制要求的情况下，有可能会关闭压缩特性。
HBase可以使用多种压缩编码，包括LZO、Snappy和GZIP。LZO[1]和Snappy[2]是其中最流行的两种。Snappy由Google在2011年发布，发布不久Hadoop和HBase项目开始提供支持。在此之前，选
本文档仅限内部使用，未经双方许可，请勿扩散到第三方。
第 32 页 共 40 页
开发规范（JAVA部分）
择的是LZO编码。Hadoop使用的LZO原生库受GPLv2版权控制，不能放在Hadoop和Hbase的任何发行版里；它们必须单独安装。另一方面，Snappy拥有BSD许可（BSD-licensed），所以它更容易和Hadoop和HBase发行版捆绑在一起。LZO和Snappy的压缩比例和压缩/解压缩速度差不多。
当建表时你可以在列族上打开压缩，如下所示： hbase(main)> create
'mytable',{NAME=>'colfam1',COMPRESSION=>'SNAPPY'} 注意数据只在硬盘上是压缩的。在内存里（MemStore或BlockCache）或网络传输时是没有压缩的。
改变压缩编码的做法不应该经常发生，但是如果你的确需要改变某个列族的压缩编码，直接做就可以。你需要更改表定义，设定新压缩编码。此后合并时，生成的HFile全部会采用新编码压缩。这个过程不需要创建新表和复制数据。但你要确保直到改变编码后所有老HFile被合并后才能从集群中删除老编码函数库。
5.2.10 数据分割
在HBase中，数据在更新时首先写入WAL 日志(HLog)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。
本文档仅限内部使用，未经双方许可，请勿扩散到第三方。
第 33 页 共 40 页
开发规范（JAVA部分）
于此同时， 系统会在zookeeper中记录一个redo point，表示这个时刻之前的变更已经持久化了(minor compact)。
StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并(major compact)，将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对 StoreFile进行分割(split)，等分为两个StoreFile。 由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部的StoreFile和MemStore，将它们按照row key进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，通常合并过程还是比较快的。
实际应用中，可以考虑必要时手动进行major compact，将同一个row key的修改进行合并形成一个大的StoreFile。同时，可以将StoreFile设置大些，减少split的发生。
5.2.11 单元时间版本
HBase在默认情况下每个单元维护三个时间版本。这个属性是可以设置的。如果你只需要一个版本，推荐你在设置表时只维护一个版本。这样系统就不会保留更新单元的多个时间版本。时间版本也是在列族级设置的，可以在表实例化时设定：
本文档仅限内部使用，未经双方许可，请勿扩散到第三方。
第 34 页 共 40 页