这是个挺典型的S3作为HBase底层存储时遇到的一致性相关问题，结合你使用的EMR 5.8.0版本，我来拆解下可能的根因和对应的配置调整方向：

可能的故障原因 #

1. S3的最终一致性特性限制 #

HBase设计时默认依赖底层存储的强一致性，但S3是典型的最终一致存储系统。当Region Server意外终止后，新节点重放WAL到S3时，可能出现「WAL已写入但Region数据文件未完全同步」的情况——此时查询请求可能读取到未更新的旧数据文件，导致看起来数据丢失。而HDFS是强一致的，所以不会出现这类问题。

2. EMR 5.8.0默认配置未适配S3场景 #

EMR 5.x早期版本（比如5.8.0）对HBase on S3的适配不够完善，默认配置没有针对S3的特性做优化：

• 未开启S3一致性模式，导致HBase无法处理S3的读写延迟
• WAL同步到S3的策略不够激进，可能存在未同步的WAL条目
• Phoenix的查询缓存可能缓存了旧数据，掩盖了实际恢复情况

3. WAL重放过程中的隐性问题 #

虽然你能看到新节点目录下的WAL文件，但重放过程可能因为以下原因失败：

• 新扩容节点的IAM角色权限不足，无法完整读取S3上的WAL文件
• S3的文件列表延迟，导致WAL重放程序未识别到部分WAL条目
• WAL文件本身因为网络问题出现损坏，无法被正常解析

对应的解决建议 #

1. 调整HBase针对S3的核心配置 #

在hbase-site.xml中添加或修改以下属性，重启HBase集群生效：

<!-- 开启S3一致性模式，适配S3的最终一致性特性 -->
<property>
  <name>hbase.s3.consistent</name>
  <value>true</value>
</property>
<!-- 强制WAL写入S3时同步，避免数据丢失 -->
<property>
  <name>hbase.s3.wal.sync</name>
  <value>true</value>
</property>
<!-- 增加WAL同步线程数，提升S3写入可靠性 -->
<property>
  <name>hbase.regionserver.hlog.syncer.count</name>
  <value>3</value>
</property>
<!-- 缩短WAL同步间隔，减少未同步数据量 -->
<property>
  <name>hbase.regionserver.wal.sync.interval</name>
  <value>5000</value>
</property>

2. 绕过Phoenix查询缓存验证 #

执行Phoenix查询时，添加/*+ NO_CACHE */提示绕过缓存，确认是否是缓存导致的数据看不到：

SELECT /*+ NO_CACHE */ * FROM your_table WHERE ...;

如果验证有效，可以修改Phoenix的缓存TTL配置phoenix.query.cache.ttl（单位毫秒），缩短缓存过期时间，比如设置为300000（5分钟）。

3. 检查WAL重放日志 #

查看新启动的Region Server日志（路径：/var/log/hbase/hbase-hbase-regionserver-<hostname>.log），搜索WALReplayer关键词，确认是否有重放失败的报错，比如权限错误、文件损坏等信息，这些日志能直接定位重放问题。

4. 确认扩容节点的S3权限 #

确保EMR自动扩容的EC2实例使用的IAM角色和原集群节点完全一致，拥有S3存储桶的读写权限，尤其是HBase WAL目录（默认在${hbase.rootdir}/wal路径下）的访问权限。

如果以上调整后问题仍存在，可以提供HBase Region Server的关键日志片段，以及hbase-site.xml的完整配置，方便进一步排查。

内容的提问来源于stack exchange，提问作者Nandakishore