优化 Amazon EMR 上 Apache HBase 可用性（下）：诊断与调优 Compaction

本文介绍如何在 Apache HBase on Amazon EMR 上诊断和调优 compaction。Compaction 是合并 store 文件的后台进程。当它在高峰时段与你的工作负载争抢资源时，你可能会看到更高的读写延迟、写入停顿以及 RegionTooBusyException 错误。在 Amazon Simple Storage Service (Amazon S3) 上的 Amazon EMR 中，当你提高集群的请求速率时，还可能看到更多 503 Slow Down 响应。

这是关于在 Amazon EMR 上运行 Apache HBase 的两部分系列文章中的第二篇：

• 第 1 部分介绍了三级排查模型和三个可用性问题：HBase coordinator 无法完成初始化、RegionServer 意外停止，以及 HBase region 停留在 transition 状态（RIT）。
• 第 2 部分（本文）介绍性能方面：如何确认 compaction 是原因、应先调优哪些参数，以及何时联系 AWS Support。

本文涵盖以下内容：

• compaction 如何影响性能。
• 如何确认延迟是否由 compaction 引起。
• 需要调优的 compaction 参数、其默认值以及每个参数的作用。
• 减少 compaction 工作量的实践。
• 何时停止并联系 AWS Support，以及提交支持案例时应提供哪些信息。

本文不涵盖以下内容：

• Coordinator 启动、RegionServer 意外停止以及处于 transition 状态的 region，这些内容在本系列的第 1 部分中介绍。
• compaction 算法内部机制或编写自定义 compaction 策略。
• Schema 设计和 row key 分布（减少 compaction 工作量的实践一节会介绍它们如何影响 compaction）。

本文面向运营团队、数据工程师、HBase 管理员和站点可靠性工程师（SRE），他们在 Amazon EMR 上的 HBase 中，于 compaction 期间会反复遇到延迟尖峰、写入停顿、RegionTooBusyException 错误或高 Amazon S3 请求速率。

术语

Apache HBase 将协调集群的进程命名为 HMaster，Amazon EMR 在主节点上运行该进程。本文将其称为 HBase coordinator。包含 master 的名称（例如 hbase-master 服务和 hbase-hbase-master-*.log 日志文件）仅出现在命令和日志输出中，此时你需要使用确切名称。

在 HBase 中，region 是表中的一段行范围，而 RegionServer 是服务 region 的进程。二者均与 AWS Region 无关。

先决条件

• 阅读 本系列的第 1 部分，特别是三级排查和快速参考两节。
• 确认你可以访问 HBase Web UI（coordinator 位于端口 16010，RegionServer 位于端口 16030）。
• 确认你可以通过 SSH 访问主节点和核心节点。
• 了解你的集群使用 Hadoop Distributed File System (HDFS) 还是 Amazon S3 作为存储模式，以及如何通过 Amazon EMR 中的 hbase-site classification 应用配置更改。有关存储模式的详细信息，请参阅 HBase on Amazon S3。
• 熟悉 HBase 中的 minor compaction 和 major compaction。

compaction 如何影响性能

默认情况下，HBase 大约每七天运行一次 major compaction，并使用 0.5 的抖动因子来分散启动时间，以免 HBase region 同时进行 compaction。有关 Amazon EMR 的具体指导，请参阅 Amazon EMR 最佳实践指南中的 HBase 最佳实践。

major compaction 会读取并重写 region 中的所有 store 文件。它会提升读取性能并删除已删除和过期的单元格，但当它在高峰时段运行时，会与客户端请求争抢资源并可能增加延迟。调优 compaction 意味着控制 major compaction 的运行时机及其使用的 I/O 量。

compaction 决策流程

在更改任何参数之前，请使用以下决策流程来识别原因。

图 1：compaction 决策流程

该流程包含以下步骤：

• 如果延迟较高，请检查受影响的 RegionServer 上是否正在运行 compaction。如果没有，请改为排查垃圾回收（GC）、磁盘和网络。
• 如果正在运行 compaction，请检查 compaction 队列是否在增长。如果没有，请检查 GC 暂停。
• 在 Amazon EMR 7.10 至 7.13 的 HBase on Amazon S3 上，请在更改任何 compaction 参数之前，将 S3A 读取策略设置为 sequential。参见诊断 compaction 压力中的步骤 3。
• 降低吞吐量上限（hbase.hstore.compaction.throughput.*），以减少 compaction 从客户端请求中占用的 I/O。限制较低时队列可能增长。当任一 store 达到 hbase.hstore.blockingStoreFiles 时，HBase 会移除该限制，因此该限制不会让 store 一直处于阻塞阈值。
• 如果延迟仍然较高，请调优 compaction 频率（hbase.hstore.compaction.min、hbase.hstore.compaction.max 和 hbase.hstore.compaction.min.size）。
• 如果延迟仅在高峰时段较高，请设置非高峰时段（hbase.offpeak.start.hour 和 hbase.offpeak.end.hour），以便更多 compaction 工作在这些时段之外运行。
• 如果 compaction 仍然影响高峰流量，请关闭自动 major compaction（hbase.hregion.majorcompaction=0）并自行安排其运行。
• 如果这些步骤均无法解决问题，请联系 AWS Support。原因可能是集群容量或 schema 设计。

注意：更改上述配置需要重启 EMR HBase。有关重新配置行为，请参阅 Reconfiguration behaviors（位于 Amazon EMR Management Guide 中）。

compaction 压力的迹象

以下症状表明存在 compaction 压力。它们不会同时全部出现。请从最初两项开始，因为你可以在 HBase Web UI 中确认它们：

• 某些 RegionServer 上的读写延迟上升，而其他 RegionServer 则没有。受影响的集合会随时间变化，因为不同 region 会进入各自的 compaction 窗口。
• 受影响的 RegionServer 上的 compaction 队列长度持续增加。
• 长时间运行的读取（报告生成、Apache Spark 表扫描）会暂停然后恢复。
• 客户端收到 RegionTooBusyException、调用超时或重试。RegionServer 日志显示 Region is too busy due to exceeding memstore size limit针对相同区域的警告。
• 写入会周期性停顿。当某个存储达到hbase.hstore.blockingStoreFiles个存储文件时，HBase 会延迟 MemStore 刷写，直到压缩将数量减少，最长延迟时间为hbase.hstore.blockingWaitTime（默认 90 秒）。如果在此期间 MemStore 超过hbase.hregion.memstore.flush.size乘以hbase.hregion.memstore.block.multiplier，HBase 会阻止对该区域的更新。
• 在 HBase on Amazon S3 上，当集群对某个 Amazon S3 前缀的请求速率很高时，会有更多请求返回 503 Slow Down。这些响应要求你的集群降低请求速率。压缩会读取并重写 Amazon S3 中的存储文件，因此会增加该速率。
• 在 Amazon EMR 7.10 至 7.13 上使用 HBase on Amazon S3 时，压缩、扫描和批量加载的运行速度低于预期，并且 HFile 数量持续增加。请参阅诊断压缩压力中的步骤 3。
• 该模式以每周一次的节奏重复出现，这与默认的七天主压缩间隔相符。

诊断压缩压力

请按顺序执行以下步骤。步骤 1 使用 HBase Web UI（级别 1）。步骤 2 和步骤 3 使用日志、操作系统工具和配置文件（级别 2）。这些检查均不会更改集群。

步骤 1（级别 1）：检查 HBase Web UI

• 在 HBase Web UI 中，按请求数和存储文件数对 RegionServer 排序，以找出异常项。存储文件数明显更高的服务器可能正在运行压缩，或正在等待压缩。
• 在受影响服务器的 RegionServer Web UI 上，检查每个区域的压缩队列长度和存储文件数。持续增长的队列意味着压缩无法跟上写入量，因此请增加容量或调整配置。
• 检查 BlockCache 命中率。较低的命中率也会增加延迟。在 HBase on Amazon S3 上，RegionServer 会在 BlockCache（内存）和 BucketCache（本地磁盘）中缓存读取内容。缓存未命中会从 Amazon S3 读取存储文件，其延迟高于本地读取。如果压缩开始时命中率下降，则压缩可能正在替换缓存中频繁读取的数据。

步骤 2（级别 2）：检查日志和操作系统

确认压缩正在运行，以及正在哪些 HBase 区域上运行：

grep -E "Starting compaction|Completed (major )?compaction|too many store files" \
/var/log/hbase/hbase-hbase-regionserver-*.log | tail -40

排除 GC 作为原因，因为重度压缩和堆压力对客户端来说看起来相同：

grep -E "JvmPauseMonitor|Detected pause in JVM" \
/var/log/hbase/hbase-hbase-regionserver-*.log | tail -20

检查主机上的 CPU、内存和磁盘使用情况：

free -m                  # check free memory
top -b -n1 | head -20    # CPU
df -h                    # disk capacity

使用 canary 工具测量每个 HBase 区域的读取延迟。该工具会将结果写入控制台和/var/log/hbase/hbase.log。将输出保存为基线，以便在每次更改后进行比较：

sudo -u hbase hbase canary my_table

检查表的存储文件布局，查看它是有许多小文件（来自频繁刷写）还是少数大文件。存储文件位于 HBase 根目录下，具体在 HDFS 或 Amazon S3 中，取决于你的存储模式。在 Amazon EMR 7.4 及更高版本的 HBase on Amazon S3 上，HBase 会在每个存储目录中的元文件里跟踪其读取的存储文件，而不是依赖目录列表，因此请使用 RegionServer Web UI 中的存储文件数作为活动文件数：

grep -A1 hbase.rootdir /etc/hbase/conf/hbase-site.xml   # find the HBase root directory
sudo -u hbase hbase hfile -f <hbase.rootdir>/data/default/my_table/<region>/<cf>/<hfile> -m -s

步骤 3（级别 2）：检查 S3A 读取策略（Amazon EMR 7.10 至 7.13）

从 Amazon EMR 7.10 开始，HBase on Amazon S3 使用 S3A 文件系统客户端，并且fs.s3a.experimental.input.fadvise默认值为normal。在此模式下，即使 HBase 继续顺序读取，S3A 也可能切换到随机读取策略，从而减慢压缩、扫描和批量加载。请对 Amazon EMR 7.10、7.11、7.12 和 7.13 使用推荐设置。症状与压缩压力相似：压缩缓慢、HFile 数量不断增加，以及被阻塞的刷写返回RegionTooBusyException。

检查发布标签和当前设置：

aws emr describe-cluster --cluster-id <cluster-id> --query 'Cluster.ReleaseLabel'
grep -A1 fs.s3a.experimental.input.fadvise /etc/hbase/conf/hbase-site.xml

如果发布版本为 7.10 至 7.13，且该属性未设置，或设置为normal，请在调整压缩之前将其设置为sequential，位于hbase-site分类中。更改该设置需要重启，因此这是级别 3 操作：

[
    {
        "Classification": "hbase-site",
        "Properties": {
            "fs.s3a.experimental.input.fadvise": "sequential"
        }
    }
]

将该设置应用于所有节点上的hbase-site.xml，然后重启 HBase 协调器和 RegionServer 进程。改为在单个命令上设置该属性不会改善压缩和扫描性能。有关更多信息，请参阅HBase on Amazon S3（位于 Amazon EMR 发布指南中）。

压缩调优参数

下表列出了本文涵盖的压缩参数。请通过 Amazon EMR 中的hbase-site配置分类应用更改。更改这些参数属于级别 3 操作。请一次更改一个参数，并将结果与步骤 2 中的 canary 基线进行比较，因为其中多个参数会相互影响。

注意：Amazon EMR 列列出了HBase on Amazon S3文档中的默认值。如果那里未列出默认值，请检查集群上 /etc/hbase/conf/hbase-site.xml中的有效值，并在Amazon EMR 发布组件页面上验证组件版本。例如，hbase.hstore.blockingStoreFiles在 Apache HBase 2.x 中为 16，但 Amazon EMR 针对 HBase on Amazon S3 将其设置为 10。

警告：如果您关闭自动 major compaction（hbase.hregion.majorcompaction=0），则需要由您负责安排它。Minor compaction 仍会合并 store 文件，但删除标记和已删除的单元格会保留在 store 文件中，直到 major compaction 运行为止。这会减慢读取速度并延迟回收存储空间。如果您将其关闭：

• 请在维护窗口内按表自行安排major_compact。仅在主集群上运行，因为只读副本集群不得运行手动 compaction。在低于 7.4.0 的 Amazon EMR 版本上，还需在只读副本集群上关闭 compaction（hbase.regionserver.compaction.enabled=false）。从 7.4.0 起，store 文件跟踪使此操作不再必要。
• 当任何 store 的 store 文件数量接近 hbase.hstore.blockingStoreFiles 时（例如达到该值的 80%）发出告警，以便在写入被延迟之前注意到计划是否出现偏差。

使用以下 HBase shell 命令运行 major compaction 并检查其进度：

hbase> major_compact 'my_table'
hbase> major_compact 'my_table', 'cf1'   # a single column family
hbase> compaction_state 'my_table'       # check progress

减少 compaction 工作量的实践

调优可以限制 compaction 对工作负载的影响。以下实践可减少集群必须执行的 compaction 工作量：

• 限制 Region 大小和每个 RegionServer 的 Region 数量。 大 Region 会使 major compaction 开销高昂，因为 major compaction 会重写该 Region 中的每个 store 文件。当 Region 达到 hbase.hregion.max.filesize（在 HBase on Amazon S3 上默认为 10737418240 字节，即 10 GB）时，HBase 会拆分该 Region。在可以预测键分布的情况下，使用 HBase shell SPLITS 选项的 create 命令或 RegionSplitter 工具预先拆分表。
• 在行键层面解决热点问题。 将写入集中到一个 Region 的行键（顺序时间戳、单调递增的 ID）会导致单个 RegionServer 上频繁刷写和反复 compaction。要将写入分散到各个 HBase Region，可对键进行加盐、哈希或反转。
• 减少小规模刷写。 许多小的 MemStore 刷写会产生许多小的 store 文件，从而增加 compaction 工作量。将 MemStore 刷写大小（hbase.hregion.memstore.flush.size）与您的写入模式进行比较。如果 Region 每隔几秒就刷写一次，则刷写大小可能太小，或者 RegionServer 可能面临内存压力。在 HBase on Amazon S3 上，考虑增大 hbase.hregion.memstore.flush.size 和 hbase.hregion.memstore.block.multiplier。这会增加 compaction 之间的时间间隔，但如果您使用只读副本集群，也会增加复制延迟。请确保 RegionServer 堆能够容纳更大的 MemStore。
• 为 HBase on Amazon S3 设置 BucketCache 大小。 BucketCache 将读取数据存储在每个 RegionServer 的本地实例存储和 Amazon EBS 卷上。它容纳的数据集越多，发往 Amazon S3 的读取就越少，因此 compaction 与客户端读取的竞争也就越小。增大 hbase.bucketcache.size（默认 8,192 MB），并选择具有足够实例存储的实例类型。请参阅 Amazon EMR 最佳实践指南中的 HBase on Amazon S3 和 Amazon S3 最佳实践。
• 使用多个主节点。 在具有多个主节点的 Amazon EMR 集群上，如果集群中的一个主节点停止，HBase 协调器会继续运行，因此 Region 分配和拆分流程会继续进行。请参阅 规划和配置主节点。
• 对 compaction 指标设置告警。 针对 compaction 队列长度和每个 Region 的 store 文件数量设置告警，这些指标会随着 compaction 落后而增加。同时针对 Java 虚拟机 (JVM) 暂停频率和已停止的 RegionServer 数量设置告警。有关可用的指标，请参阅 Amazon EMR 最佳实践指南中的可观测性指导。

何时停止并联系 AWS Support

某些修复操作会更改集群元数据且难以逆转。当以下任一情况成立时，请停止操作并向 AWS Support 提交案例：

• 您的下一步是使用 HBCK2 bypass 或 setRegionState。 两者都可能使 procedure 或 Region 处于不一致状态，之后您必须进行纠正，并且 bypass 可能需要重启协调器才能释放锁。AWS Support 可以在您运行命令之前验证您的诊断并确认该命令。
• 您的下一步是删除 znode。 删除 /hbase 子节点会丢弃 HBase 保存在 ZooKeeper 中的状态，例如 hbase:meta 的位置、RegionServer 注册信息，以及在 Amazon EMR 上的 store 文件跟踪数据。这会使问题更难解决。不要将删除 znode 作为第一步。
• 某个 procedure 卡住，且您无法从日志中确定原因。如果三份线程转储和协调器日志仍未解释是什么阻塞了该过程，AWS Support 可以帮助查明原因。
• 多个 RegionServer 同时停止。在您的集群中查找 RegionServer 共有的原因，例如集群节点之间的网络配置、ZooKeeper 集群或 HDFS。
• 您已调整压缩参数两次，但延迟仍未改善。原因可能是表结构设计、行键分布或集群容量，进一步调优可能只会掩盖问题而无法解决它。
• 堆栈跟踪中包含您不认识的异常。如果该错误未出现在本文或 Apache HBase 参考指南中，它可能是已在后续版本中修复的 Apache HBase 问题。请查看 Amazon EMR 发布指南和 Apache HBase JIRA，然后再继续调试。

提交支持案例时应提供的内容

在创建案例之前，请收集以下信息：

提前提供这些信息可减少 AWS Support 的后续请求次数。

快速参考：压缩日志特征

在下表中搜索每个特征的首次出现位置，该位置显示该状况何时开始。除非表中另有说明，这些特征出现在 RegionServer 日志中。例如：

grep -m1 -n "too many store files" /var/log/hbase/hbase-hbase-regionserver-*.log

结论和后续步骤

在本文中，您学习了如何确认压缩是否导致 Amazon EMR 上的 HBase 延迟，以及如何调优，从侵入性最小的更改开始。

有关协调器启动、RegionServer 意外停止以及处于转换中的 region 的信息，请参阅本系列的第 1 部分。

后续步骤

• 将两篇文章中的分诊流程添加到您团队的运行手册中，并使用您自己的告警名称、仪表板和待命程序。
• 设置“减少压缩工作量的实践”中描述的告警。
• 立即在集群上为您的 HBase 版本暂存 HBCK2 jar，以便在需要之前就准备就绪。
• 记录压缩基线。在为期一周的 RegionServer 日志中运行 grep -E "Completed (major )?compaction"，以了解您表的正常持续时间和频率，从而能够识别异常行为。
• 查阅 Amazon EMR 最佳实践指南中 HBase 最佳实践和故障排除部分的指导。