选择方案及依据
- 方案：选择采用分层BlockCache，例如采用两级分层BlockCache（默认的L1和L2）。
- 依据：
- 读多写少场景：BlockCache主要用于缓存读数据，在这种场景下能充分发挥其加速读操作的作用。对于热数据，频繁读取的数据可以被缓存起来，下次读取时直接从缓存获取，大大提高读取速度。
- 冷热数据特征：分层BlockCache能够很好地适应这种特征。L1 BlockCache可设置为较小的内存空间，用于缓存最热点的数据，它的访问速度快。L2 BlockCache则分配较大内存空间，用于缓存相对热度稍低的数据。这样可以根据数据的冷热程度进行分级缓存，提高缓存命中率。
- 数据量庞大：两级分层结构可以有效管理不同热度数据，不至于让热点数据被大量冷数据挤出缓存，同时也能利用较大的L2空间缓存一定量的非最热点数据，满足读请求。
具体配置思路
- L1 BlockCache配置：
- 内存大小：根据预估的最热点数据量和服务器内存情况，一般可设置为总堆内存的2% - 5%。例如，如果总堆内存为16GB，L1 BlockCache可设置为320MB - 800MB。
- 缓存策略：通常采用LRU（最近最少使用）策略，保证最常访问的数据留在缓存中。
- L2 BlockCache配置：
- 内存大小：分配剩余可用于BlockCache的大部分内存，例如总堆内存的10% - 40%。以16GB总堆内存为例，L2 BlockCache可设置为1.6GB - 6.4GB。
- 缓存策略：同样采用LRU策略，但由于L2缓存的数据相对不那么热，其淘汰机制会相对L1更宽松一些，以保证热点数据在L1不被轻易挤出。
- 其他配置：
在
hbase - site.xml文件中进行如下配置：
<property>
<name>hfile.block.cache.size</name>
<value>0.4</value> <!-- 假设总堆内存的40%用于BlockCache，具体比例根据上述配置调整 -->
</property>
<property>
<name>hbase.block.cache.l1.size</name>
<value>0.03</value> <!-- 假设L1占总堆内存的3%，具体比例根据上述配置调整 -->
</property>
<property>
<name>hbase.regionserver.global.memstore.size</name>
<value>0.4</value> <!-- 合理分配写缓存内存，假设占总堆内存40%，根据实际调整 -->
</property>
监控和评估方案对综合性能提升效果
- 监控指标：
- 缓存命中率：通过HBase的JMX指标
Hadoop:service = HBase,name = RegionServer,sub = Cache下的BlockCacheHitRatio获取。缓存命中率越高，说明从缓存中读取数据的比例越大，方案效果越好。如果缓存命中率持续较低，可能需要调整缓存大小或策略。
- 读请求响应时间：使用HBase自带的性能监控工具或在业务代码中添加计时逻辑。对比采用新BlockCache方案前后的读请求响应时间，如果响应时间明显缩短，说明方案有效提升了读性能。
- 内存使用情况：通过操作系统的内存监控工具（如
top、free等命令）以及HBase的JMX指标监控BlockCache实际使用的内存量，确保没有因为缓存设置过大导致内存溢出，同时也保证缓存空间得到充分利用。
- 评估方法：
- 对比测试：在采用新方案前后，使用相同的测试数据集和负载进行性能测试，对比上述监控指标的变化。例如，使用
HBase Benchmark工具进行读性能测试，观察读吞吐量和响应时间的变化。
- 长期监控：在实际生产环境中，长期监控上述指标，观察其随时间的变化趋势。例如，观察缓存命中率在一天或一周内的波动情况，以及读请求响应时间的峰值和平均值，及时发现可能出现的性能问题并调整方案。
