一、表压缩
1、HBase Sanppy
HBase Sanppy 1）配置Haodop压缩 [beifeng@hadoop-senior hadoop-2.5.0]$ bin/hadoop checknative 2）配置HBase >> hadoop-snappy jar -> 放入到HBASE的lib目录 [root@hadoop-senior lib]# cp hadoop-snappy-0.0.1-SNAPSHOT.jar /opt/modules/hbase-0.98.6-hadoop2/lib/ >> 需要将本地库native [root@hadoop-senior lib]# mkdir /opt/modules/hbase-0.98.6-hadoop2/lib/native [root@hadoop-senior native]# cd /opt/modules/hbase-0.98.6-hadoop2/lib/native/ [root@hadoop-senior native]# ln -s /opt/modules/hadoop-2.5.0/lib/native ./Linux-amd64-64 [root@hadoop-senior native]# ll 总用量 0 lrwxrwxrwx. 1 root root 36 5月 27 11:41 Linux-amd64-64 -> /opt/modules/hadoop-2.5.0/lib/native 3) 重启HBASE [root@hadoop-senior hbase-0.98.6-hadoop2]# bin/hbase-daemon.sh stop master [root@hadoop-senior hbase-0.98.6-hadoop2]# bin/hbase-daemon.sh stop regionserver [root@hadoop-senior hbase-0.98.6-hadoop2]# bin/hbase-daemon.sh start master [root@hadoop-senior hbase-0.98.6-hadoop2]# bin/hbase-daemon.sh start regionserver
2、测试
##regionserver启用snappy压缩，hbase-site.xml <property> <name>io.compression.codecs</name> <value>snappy</value> <description>A list of the compression codec classes that can be used for compression/decompression.</description> </property> ## hbase(main):002:0> create 't_snappy', {NAME => 'f1', COMPRESSION => 'SNAPPY'} 0 row(s) in 0.4710 seconds => Hbase::Table - t_snappy hbase(main):003:0> describe 't_snappy' DESCRIPTION ENABLED 't_snappy', {NAME => 'f1', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCOPE => '0', VERS true IONS => '1', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BL OCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true'} 1 row(s) in 0.0310 seconds
二、版本和BlockCache
1、Memstore & BlockCache
HBase上Regionserver的内存分为两个部分，一部分作为Memstore，主要用来写；另外一部分作为BlockCache，主要用于读。 写请求会先写入Memstore，Regionserver会给每个region提供一个Memstore，当Memstore满64MB以后，会启动flush刷新到磁盘。 当Memstore的总大小超过限制时（heapsize*hbase.regionserver.global.memstore.upperLimit*0.9），会强行启动flush进程，从最大的Memstore开始flush直到低于限制。 读请求先到Memstore中查数据，查不到就到BlockCache中查，再查不到就会到磁盘上读，并把读的结果放入BlockCache。 由于BlockCache采用的是LRU策略，因此BlockCache达到上限（heapsize*hfile.block.cache.size*0.85）后，会启动淘汰机制，淘汰掉最老的一批数据。 在注重读响应时间的应用场景下，可以将BlockCache设置大些，Memstore设置小些，以加大缓存的命中率。
参考博文：https://blog.51cto.com/12445535/2363376
背景： 1、缓存对于数据库来说极其的重要 2、最理想的情况是，所有数据都能够缓存到内存，这样就不会有任何文件IO请求，读写性能必然会提升到极致。 3、我们并不需要将所有数据都缓存起来，根据二八法则，80%的业务请求都集中在20%的热点数据上， 4、把20%的数据缓存起来，将这部分数据缓存起就可以极大地提升系统性能。 HBase在实现中提供了两种缓存结构：MemStore和BlockCache。 MemStore 1、其中MemStore称为写缓存 2、HBase执行写操作首先会将数据写入MemStore，并顺序写入HLog， //代码中这样，我们的理解为 先顺序写入HLog 再将数据写入MemStore 3、等满足一定条件后统一将MemStore中数据刷新到磁盘，这种设计可以极大地提升HBase的写性能。 4、MemStore对于读性能也至关重要，假如没有MemStore，读取刚写入的数据就需要从文件中通过IO查找，这种代价显然是昂贵的！ BlockCache 1、BlockCache称为读缓存 2、HBase会将一次文件查找的Block块缓存到Cache中，以便后续同一请求或者邻近数据查找请求，可以直接从内存中获取，避免昂贵的IO操作。 ## 1、BlockCache是Region Server级别的， 2、一个Region Server只有一个Block Cache，在Region Server启动的时候完成Block Cache的初始化工作。 3、到目前为止，HBase先后实现了3种Block Cache方案，LRUBlockCache是最初的实现方案，也是默认的实现方案；HBase 0.92版本实现了第二种方案SlabCache，见HBASE-4027；HBase 0.96之后官方提供了另一种可选方案BucketCache，见HBASE-7404。 4、这三种方案的不同之处在于对内存的管理模式， 5、其中LRUBlockCache是将所有数据都放入JVM Heap中，交给JVM进行管理。 6、SlabCache BucketCache 这两种采用了不同机制将部分数据存储在堆外，交给HBase自己管理。 7、这种演变过程是因为LRUBlockCache方案中JVM垃圾回收机制经常会导致程序长时间暂停，而采用堆外内存对数据进行管理可以有效避免这种情况发生。
LRUBlockCache
HBase默认的BlockCache实现方案 1、将内存从逻辑上分为了三块：single-access区、mutil-access区、in-memory区，分别占到整个BlockCache大小的25%、50%、25% 2、一次随机读中，一个Block块从HDFS中加载出来之后首先放入signle区， 3、后续如果有多次请求访问到这块数据的话，就会将这块数据移到mutil-access区。 3、而in-memory区表示数据可以常驻内存，一般用来存放访问频繁、数据量小的数据，比如Meta元数据，用户也可以在建表的时候通过设置 列族属性IN-MEMORY= true将此列族放入in-memory区。 //这一部分参考 HBase － 建表语句解析 http://hbasefly.com/2016/03/23/hbase_create_table/ 中 提到的 IN_MEMORY 参数； 4、很显然，这种设计策略类似于JVM中young区、old区以及perm区。 阶段小结： LRUBlockCache机制：类似于jvm的young区、old区以及perm区，他分为（single-access区、mutil-access区、in-memory区，分别占到整个BlockCache大小 的25%、50%、25%）在一次随机访问数据的时候从hdfs加载出来，放到single-access区，后续如果有多次请求这块的数据，就会放到 mutil-access区， 而in-memory区表示数据可以常驻内存，一般用来存放访问频繁、数据量小的数据，比如元数据。 //当BlockCache总量达到一定阈值之后就会启动淘汰机制，最少使用的Block会被置换出来，为新加载的Block预留空间。 缺点：使用LRUBlockCache缓存机制会因为CMS GC策略导致内存碎片过多，从而可能引发臭名昭著的Full GC，触发可怕的’stop-the-world’暂停，严重影响上层业务；
三、表的Compaction
1、Compaction
随着memstore中的数据不断刷写到磁盘中，会产生越来越多的HFile文件，HBase内部有一个解决这个问题的管家机制，即用合并将多个文件合并成一个较大的文件。 合并有两种类型：minor合并（minor compaction）和major压缩合并（majar compaction）。minor合并将多个小文件重写为数量较少的大文件，减少存储文件的数量， 这个过程实际上是个多路归并的过程。因为HFile的每个文件都是经过归类的，所以合并速度很快，只受到磁盘I/O性能的影响。 major 合并将一个region中一个列族的若干个HFile重写为一个新HFile，与minor合并相比，还有更独特的功能：major合并能扫描所有的键/值对，顺序重写全部的数据， 重写数据的过程中会略过做了删除标记的数据。断言删除此时生效，例如，对于那些超过版本号限制的数据以及生存时间到期的数据，在重写数据时就不再写入磁盘了。 ######## HRegoin Server的storefile文件是被后台线程监控的，以确保这些文件保持在可控状态。磁盘上的storefile的数量会随着越来越多的memstore被刷新而变的越来越多， 每次刷新都会生成一个storefile文件。当storefile数量满足一定条件时（可以通过配置参数类调整），会触发文件合并操作minor compaction，将多个比较小的storefile 合并成一个大的storefile文件，直到合并的文件大到超过单个文件配置允许的最大值时会触发一次region的自动分割，即region split操作，将一个region平分成2个。 ################ minor compaction 轻量级 将符合条件的最早生成的几个storefile合并生成一个大的storefile文件，它不会删除被标记为“删除”的数据和以过期的数据，并且执行过一次minor合并操作后还会有多个storefile文件。 major compaction 重量级 把所有的storefile合并成一个单一的storefile文件，在文件合并期间系统会删除标记为“删除“标记的数据和过期失效的数据，同时会block(阻塞)所有客户端对该操作所属的region的请求直到合并完毕，最后删除已合并的storefile文件。