如何处理 HDInsight Hbase 主要压缩？发生主要压缩时无法访问 Hbase答案

【问题标题】：How to handle HDInsight Hbase Major compactions? Hbase is not reachable when the major compaction take place如何处理 HDInsight Hbase 主要压缩？发生主要压缩时无法访问 Hbase
【发布时间】：2016-09-16 06:27:36
【问题描述】：

我们安装了 HDInsight Hbase 集群，我们观察到，虽然正在进行主要的压缩，但客户端应用程序无法访问 Hbase。

请提出处理这种情况的最佳做法。

【问题讨论】：

标签： hbase azure-hdinsight

【解决方案1】：

关于 HDInsight HBase，我想在这里分享一些想法。

1) 基于时间的压缩被默认禁用，参见hbase.hregion.majorcompaction=0

2) 关于基于大小的压缩，默认压缩策略是ExploringCompactionPolicy，而hbase.hstore.compaction.max.size 设置为 10GB，因此不会发生大于 10GB 的压缩。

hbase.hregion.max.filesize 设置为 3GB，因此一旦某个区域的 HFiles 增长到超过此值，该区域将被拆分。这样设置的原因是 HBase 在 Azure Storage 中可以创建的最大 blob 最大为 12GB，因此如果压缩超过 12GB 的数据，压缩最终将失败。您绝对可以增加最大 blob 大小（记录的每个 Azure 存储最多 200GB，但这也会增加读/写延迟和压缩时间）。

这里有更多上下文，

虽然 Azure blob 存储对于单个 blob 有 200GB 的限制，（4MB*50k 块），但为了获得最佳性能，在 hadoop core-site.xml 中，我们将 fs.azure.read.request.size 和 fs.azure.write.request.size 限制为 256kb，因此最大HBase 集群中的 blob 将是 256KB*50k 大约 12GB。如果您设置为 4MB，那么它将是 200GB。但是 4MB 会增加每次读取/写入的延迟，并且您将允许 HBase 压缩多达 200GB 的数据，这将持续数小时。

3) 主要压缩的成本很高，尤其是对于基于云的 HBase。因为延迟高于本地磁盘/SSD。为了提高读取性能，您可以设置挂载在本地 VM SSD 上的存储桶缓存，在最新的 HDInsight HBase 集群上默认情况下应该已启用。

肯定还有更多的调整可以做，比如 VM 大小、集群大小、Memstore 大小等。

【讨论】：

【解决方案2】：

这取决于您的用例。

默认情况下，主要压缩每 24 小时进行一次。

如果您知道您的集群何时未使用，您可以禁用主要压缩并在那个时间（通常是晚上）运行。由 cron 调用并使用 hbase shell 启动主要压缩的脚本可以完成这项工作。

从 HBase 0.98.11 和 HBase 1.1.0 开始，您可以限制压缩吞吐量，更多信息请参见 Limit compaction speed JIRA。

启动major compaction 很重要，因为它通过合并StoreFile（删除磁盘上已删除的数据、按rowkey 对数据进行排序……）改进了HBase 磁盘访问。

hbase-site.xml：

<!-- Disable major compaction -->
<property> 
  <name>hbase.hregion.majorcompaction</name> 
  <value>0</value> 
</property>

手动运行主要压缩：

# Launch major compaction on all regions of table t1
$ echo "major_compact 't1'" | hbase shell
# Launch major compaction on region r1 
$ major_compact 'r1'

【讨论】：