Azure HDInsight中的 Apache HBase 公告

本文介绍了几个建议，可帮助你优化 Azure HDInsight 中的 Apache HBase 性能。

优化 HBase 以读取最近写入的数据

如果你的用例涉及读取来自 HBase 的最近写入的数据，则此建议可帮助到你。 为了实现高性能，最好是将 HBase 的读取操作从 memstore 提供，而不是从远程存储提供。

查询建议指出，对于表中的给定列族，75% 的读取量是从 > 提供的 memstore。 此指示器表明，即使 memstore 上发生刷新，也需要访问最近的文件，并且这些文件需要放入缓存中。 首先将数据写入 memstore，系统会在其中访问最近数据。 内部 HBase 刷新线程可能会检测到给定区域已达到 128M（默认）大小，并可能触发刷新。 这种情况甚至会发生在当 memstore 的大小约为 128M 时写入的最新数据上。 因此，稍后读取这些近期记录可能需要从文件中读取，而不是从 memstore 读取。 因此最好进行优化，确保最近刷新的数据也可以驻留在缓存中。

若要优化缓存中的最新数据，请考虑以下配置设置：

  1. 将 hbase.rs.cacheblocksonwrite 设置为 true。 HDInsight HBase 中的此默认配置为 true，因此请检查其是否未被重置为 false。

  2. 增加 hbase.hstore.compactionThreshold 值，以避免开始时压缩。 默认情况下，此值为 3。 可以将其更改为一个更大的值，如 10。

  3. 如果遵循步骤 2 并设置 compactionThreshold，则将 hbase.hstore.compaction.max 更改为较大的值（例如 100），并将配置 hbase.hstore.blockingStoreFiles 的值更改为更大的值（例如 300）。

  4. 如果确定只需读取最近的数据，请将 hbase.rs.cachecompactedblocksonwrite 配置设置为“启用”。 此配置告知系统，即使发生压缩，数据仍保留在缓存中。 还可以在族级别设置配置。

    在 HBase Shell 中，运行以下命令以设置 hbase.rs.cachecompactedblocksonwrite 配置：

    alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}

  5. 可以禁用表中给定系列的块缓存。 请确保对具有最近数据读取的家庭已将其设置为“打开”。 默认情况下，已为表中的所有系列启用块缓存。 如果您已禁用列族的块缓存，并且需要再次启用，请使用 hbase shell 中的 alter 命令。

    这些配置有助于确保数据在缓存中可用，并且最近的数据不会受到压缩。 如果你的场景中可以使用 TTL，请考虑使用日期分层压缩。 有关详细信息，请参阅 Apache HBase 参考指南：日期分层压缩

优化清空队列

此建议表明 HBase 刷盘可能需要优化。 刷新处理程序的当前配置可能不够高，无法处理写入流量，这可能会导致刷新速度变慢。

在区域服务器 UI 中，请注意刷新队列是否增长到 100 以上。 此阈值表示刷新速度很慢，您可能需要调整 hbase.hstore.flusher.count 配置。 默认情况下，该值为 2。 请确保最大刷新线程数不超过 6。

此外，看看有没有关于调整区域数量的建议。 如果有，建议你尝试进行区域优化，看看这是否有助于提高刷新速度。 否则，调整刷新线程可能会对您有所帮助。

区域计数调优

区域计数优化建议指示 HBase 已阻止更新，并且区域计数可能超过受支持的堆大小上限。 你可以调整堆大小、memstore 大小和区域数量。

下面是一个示例场景：

  • 假设区域服务器的堆大小为 10 GB。 默认情况下，hbase.hregion.memstore.flush.size 为 128M。 hbase.regionserver.global.memstore.size 的默认值为 0.4。 这意味着在 10 GB 中，4 GB 分配给 memstore（全局）。

  • 假设所有区域的写入负载分布均匀，并且每个区域只增加到 128 MB，则此设置中的最大区域数为 32 个区域。 如果给定的区域服务器配置为具有 32 个区域，则系统最好避免阻止更新。

  • 设置到位后，区域数为 100。 4GB 全球 memstore 现在划分为 100 个区域。 因此，实际上每个区域只能获得 40 MB 的 memstore。 如果写入是均匀的，系统会频繁刷新，且顺序的大小通常小于 40 MB。 拥有多个刷新线程可能会提高刷新速度 hbase.hstore.flusher.count。

建议意味着，可能需要重新考虑每台服务器的区域数量、堆大小、全局 memstore 大小配置，以及优化刷新线程，以避免更新被阻止。

压缩队列优化

如果 HBase 压缩队列增长到 2000 以上并且定期发生，则可将压缩线程数更改为一个更大的值。

当需要整理的文件过多时，可能会导致与这些文件如何与Azure文件系统交互相关的堆使用增加。 因此，最好尽快完成压缩。 在较旧的群集中，有时与节流相关的压实配置可能会导致压实速率变慢。

查看配置 hbase.hstore.compaction.throughput.lower.bound 和 hbase.hstore.compaction.throughput.higher.bound。 如果它们已设置为 50M 和 100M，请将其保持原样。 但是，如果将这些设置配置为较低的值（较旧的群集就是这种情况），请将限制分别更改为 50M 和 100M。

配置 hbase.regionserver.thread.compaction.small 和 hbase.regionserver.thread.compaction.large（每个默认值为 1）。 此配置的最大值上限为小于 3。

全表扫描

全表扫描建议显示，发出的扫描中有超过 75% 是全表扫描或全区域扫描。 可重新考虑代码调用扫描的方式，以提高查询性能。 请考虑以下做法：

  • 为每次扫描设置正确的开始和停止行。

  • 使用 MultiRowRangeFilter API，以便你可以在一次扫描调用中查询不同的范围。 有关详细信息，请参阅 MultiRowRangeFilter API 文档。

  • 如果需要进行完整的表或区域扫描，请检查是否可以避免这些查询使用缓存，这样使用缓存的其他查询就不会逐出那些频繁访问的数据块。 为确保扫描不使用缓存，请在代码中使用带有 setCaching(false) 选项的扫描 API：

    scan#setCaching(false)

后续步骤

使用 Ambari 优化 Apache HBase

  • Last updated on