如何处理HDInsight Hbase主要压缩？进行主要压缩时，无法访问Hbase_Hbase_Azure Hdinsight

如何处理HDInsight Hbase主要压缩？进行主要压缩时，无法访问Hbase

hbase

如何处理HDInsight Hbase主要压缩？进行主要压缩时，无法访问Hbase,hbase,azure-hdinsight,Hbase,Azure Hdinsight,我们已经安装了HDInsight Hbase cluster，并且我们观察到，虽然正在进行大型压缩，但客户端应用程序无法访问Hbase 请建议处理此场景的最佳实践。这取决于您的用例默认情况下，每24小时提供一次午餐如果您知道何时不使用集群，则可以禁用主压缩并在该时间运行（通常是晚上）。cron调用的脚本可以使用hbase shell启动主要压缩由于HBase 0.98.11和HBase 1.1.0，您可以限制压缩吞吐量，有关的详细信息启动主要压缩非常重要，因为它通过合并StoreFile

我们已经安装了HDInsight Hbase cluster，并且我们观察到，虽然正在进行大型压缩，但客户端应用程序无法访问Hbase

请建议处理此场景的最佳实践。

这取决于您的用例

默认情况下，每24小时提供一次午餐

如果您知道何时不使用集群，则可以禁用主压缩并在该时间运行（通常是晚上）。cron调用的脚本可以使用hbase shell启动主要压缩

由于HBase 0.98.11和HBase 1.1.0，您可以限制压缩吞吐量，有关的详细信息

启动主要压缩非常重要，因为它通过合并StoreFile（删除磁盘上已删除的数据，按rowkey排序数据，…）改进了HBase磁盘访问

hbase-site.xml：

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

这取决于您的用例

默认情况下，每24小时提供一次午餐

如果您知道何时不使用集群，则可以禁用主压缩并在该时间运行（通常是晚上）。cron调用的脚本可以使用hbase shell启动主要压缩

由于HBase 0.98.11和HBase 1.1.0，您可以限制压缩吞吐量，有关的详细信息

启动主要压缩非常重要，因为它通过合并StoreFile（删除磁盘上已删除的数据，按rowkey排序数据，…）改进了HBase磁盘访问

hbase-site.xml：

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

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

1） deafult禁用基于时间的压缩，请参见

hbase.hregion.majorcompaction=0

2）关于基于大小的压缩，默认压缩策略是

ExploringCompactionPolicy

，而

hbase.hstore.compression.max.size

设置为10GB，因此不会发生大于10GB的压缩

hbase.hregion.max.filesize

设置为3GB，因此，一旦某个区域的HFiles增长到执行此值，该区域将被分割。设置这些设置的原因是Azure存储中可以创建的最大blob HBase高达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。如果设置为4MB，则将为200GB。但4MB将增加每次读/写的延迟，您将允许HBase压缩多达200GB的数据，这将持续数小时

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

当然，可以进行更多的调整，如VM大小、集群大小、Memstore大小等。