1. 重要工作机制
1.1 读数据流程
1.从zookeeper找到meta表的region的位置，然后读取meta表中的数据。而meta中又存储了用户表的region信息
ZK：/hbase/meta-region-server，该节点保存了meta表的region server数据
2.根据namespace、表名和rowkey根据meta表中的数据找到对应的region信息
hbase(main):014:0> scan "hbase:meta", { FILTER => "PrefixFilter('ORDER_DTL')"}
ORDER_DTL,,1599542264340.30b90c560200da7819da10dc27d8a6ca. column=info:state, timestamp=1599542721810, value=OPEN
ORDER_DTL,,1599542264340.30b90c560200da7819da10dc27d8a6ca. column=info:regioninfo, timestamp=1599542721810, value={ENCODED => 30b90c560200da7819da10dc27d8a6ca, NAME => 'ORDER_DTL,,1599542264340.30b90c560200da7819da10dc27d8a6ca.', STARTKEY => '', ENDKEY => '\x01'}
ORDER_DTL,,1599542264340.30b90c560200da7819da10dc27d8a6ca. column=info:server, timestamp=1599542721810, value=node3.itcast.cn:16020
3.找到对应的regionserver，查找对应的region
4.从MemStore找数据，再去BlockCache中找，如果没有，再到StoreFile上读
5.可以把MemStore理解为一级缓存，BlockCache为二级缓存，但注意scan的时候BlockCache意义不大，因为scan是顺序扫描
1.2 数据存储流程
1.HBase V2.x以前版本
写内存（MemStore）
二阶段StoreFiles合并
2.V2.x
In-memory compaction（带合并的写内存）
二阶段StoreFiles合并
HBase的数据存储过程是分为几个阶段的。写入的过程与HBase的LSM结构对应。
1.为了提高HBase的写入速度，数据都是先写入到MemStore（内存）结构中，V2.0 MemStore也会进行Compaction
2.MemStore写到一定程度（默认128M），由后台程序将MemStore的内容flush刷写到HDFS中的StoreFile
3.数据量较大时，会产生很多的StoreFile。这样对高效读取不利，HBase会将这些小的StoreFile合并，一般3-10个文件合并成一个更大的StoreFile
写入MemStore
- Client访问zookeeper，从ZK中找到meta表的region位置
- 读取meta表中的数据，根据namespace、表名、rowkey获取对应的Region信息
- 通过刚刚获取的地址访问对应的RegionServer，拿到对应的表存储的RegionServer
- 去表所在的RegionServer进行数据的添加
- 查找对应的region，在region中寻找列族，先向MemStore中写入数据
MemStore溢写合并
-
说明
当MemStore写入的值变多，触发溢写操作（flush），进行文件的溢写，成为一个StoreFile
当溢写的文件过多时，会触发文件的合并（Compact）操作，合并有两种方式（major，minor） -
触发条件
- 一旦MemStore达到128M时，则触发Flush溢出（Region级别）
<property> <name>hbase.hregion.memstore.flush.size</name> <value>134217728</value> <source>hbase-default.xml</source> </property>- MemStore的存活时间超过1小时（默认），触发Flush溢写（RegionServer级别）
<property> <name>hbase.regionserver.optionalcacheflushinterval</name> <value>3600000</value> <source>hbase-default.xml</source> </property>
模拟数据查看MemStore使用情况
注意：此处小数是无法显示的，只显示整数位的MB。
- 在资料/测试程序中有一个GenWaterBill代码文件，将它导入到之前创建的Java操作HBase中，然后运行。
- 打开HBase WebUI > Table Details > 「WATER_BILL」
- 打开Region所在的Region Server
点击Memory查看内存占用情况
In-memory合并
In-memory compaction介绍
In-memory合并是HBase 2.0之后添加的。它与默认的MemStore的区别：实现了在内存中进行compaction（合并）。
在CompactingMemStore中，数据是以段（Segment）为单位存储数据的。MemStore包含了多个segment。
- 当数据写入时，首先写入到的是Active segment中（也就是当前可以写入的segment段）
- 在2.0之前，如果MemStore中的数据量达到指定的阈值时，就会将数据flush到磁盘中的一个StoreFile
- 2.0的In-memory compaction，active segment满了后，将数据移动到pipeline中。这个过程跟以前不一样，以前是flush到磁盘，而这次是将Active segment的数据，移到称为pipeline的内存当中。一个pipeline中可以有多个segment。而In-memory compaction会将pipeline的多个segment合并为更大的、更紧凑的segment，这就是compaction
- HBase会尽量延长CompactingMemStore的生命周期，以达到减少总的IO开销。当需要把CompactingMemStore flush到磁盘时，pipeline中所有的segment会被移动到一个snapshot中，然后进行合并后写入到HFile
compaction策略
但Active segment flush到pipeline中后，后台会触发一个任务来合并pipeline中的数据。合并任务会扫描pipeline中所有的segment，将segment的索引合并为一个索引。有三种合并策略： - basic（基础型）
- Basic compaction策略不清理多余的数据版本，无需对cell的内存进行考核
- basic适用于所有大量写模式
- eager（饥渴型）
- eager compaction会过滤重复的数据，清理多余的版本，这会带来额外的开销
- eager模式主要针对数据大量过期淘汰的场景，例如：购物车、消息队列等
- adaptive（适应型）
- adaptive compaction根据数据的重复情况来决定是否使用eager策略
- 该策略会找出cell个数最多的一个，然后计算一个比例，如果比例超出阈值，则使用eager策略，否则使用basic策略
配置
1.可以通过hbase-site.xml来配置默认In Memory Compaction方式
<property>
<name>hbase.hregion.compacting.memstore.type</name>
<value><none|basic|eager|adaptive></value>
</property>
2.在创建表的时候指定
create "test_memory_compaction", {NAME => 'C1', IN_MEMORY_COMPACTION => "BASIC"}
StoreFile合并
- 当MemStore超过阀值的时候，就要flush到HDFS上生成一个StoreFile。因此随着不断写入，HFile的数量将会越来越多，根据前面所述，StoreFile数量过多会降低读性能
- 为了避免对读性能的影响，需要对这些StoreFile进行compact操作，把多个HFile合并成一个HFile
- compact操作需要对HBase的数据进行多次的重新读写，因此这个过程会产生大量的IO。可以看到compact操作的本质就是以IO操作换取后续的读性能的提高
minor compaction
说明
1.Minor Compaction操作只用来做部分文件的合并操作，包括minVersion=0并且设置ttl的过期版本清理，不做任何删除数据、多版本数据的清理工作
2.小范围合并，默认是3-10个文件进行合并，不会删除其他版本的数据
3.Minor Compaction则只会选择数个StoreFile文件compact为一个StoreFile
4.Minor Compaction的过程一般较快，而且IO相对较低
触发条件
1.在打开Region或者MemStore时会自动检测是否需要进行Compact（包括Minor、Major）
2.minFilesToCompact由hbase.hstore.compaction.min控制，默认值为3
3.即Store下面的StoreFile数量减去正在compaction的数量 >=3时，需要做compaction
http://node1.itcast.cn:16010/conf
<property>
<name>hbase.hstore.compaction.min</name>
<value>3</value>
<final>false</final>
<source>hbase-default.xml</source>
</property>
major compaction
说明
1.Major Compaction操作是对Region下的Store下的所有StoreFile执行合并操作，最终的结果是整理合并出一个文件
2.一般手动触发，会删除其他版本的数据（不同时间戳的）
触发条件
1.如果无需进行Minor compaction，HBase会继续判断是否需要执行Major Compaction
2.如果所有的StoreFile中，最老（时间戳最小）的那个StoreFile的时间间隔大于Major Compaction的时间间隔（hbase.hregion.majorcompaction——默认7天）
<property>
<name>hbase.hregion.majorcompaction</name>
<value>604800000</value>
<source>hbase-default.xml</source>
</property>
604800000毫秒 = 604800秒 = 168小时 = 7天
