摘要： 在小米，HBase 作为分布式宽表服务，同时支持离线和在线场景。然而，内部仍有 40% 的节点运行在 0.98 版本上，由于需要支持双版本，导致维护成本高昂。将版本统一到 2.3 对于提高开发效率至关重要。此外，2.3 版本本身也面临稳定性挑战，如 GC 问题和集群级停机恢复失败。本次演讲将分享小米在应对这些挑战方面的实践经验。

大纲：

第一部分：发展历程与挑战 HBase 在小米有着悠久的历史，但也积累了技术债务。主要挑战包括：

• 版本碎片化：2.3 版本的升级历时 3 年，双版本维护消耗了大量资源。
• 2.3 版本稳定性问题：存在 GC 瓶颈和集群级停机无法恢复等问题。

第二部分：解决方案与实施 2.1 版本统一 历史上的升级失败削弱了对跨版本升级的信心，导致统一进程延迟。为解决这一问题：

• 优化了日志分割（Log-split），确保数据仅由同版本服务器处理，防止数据丢失。
• 增强了复制（Replication）功能，允许并发同步和升级，解决了升级过程中的关键障碍。 成功完成了所有共享集群的平滑升级，实现了全版本统一。

2.2 GC 优化 迁移到 2.3 版本后，由于 jmx-to-Prometheus 转换，采用 Prometheus 监控增加了 HBase 内存使用，导致生产环境中频繁触发 Full GC 和长期 Young GC。解决方案包括：

• 调整 G1 参数以缓解 GC 导致的延迟峰值。
• 升级到 JDK 17 并在部分集群上启用 ZGC，将 GC 暂停时间减少到 <10ms，并稳定了延迟。

2.3 服务增强 为进一步提高稳定性，进行了以下优化：

• 元数据请求隔离、Zookeeper 弱依赖、Balancer 升级。
• 解决 RegionServer 请求/重启阻塞问题，采用 ZSTD 压缩，并自动化服务检查/故障恢复。 这些努力实现了 99.95% 的可用性，满足了业务需求。

第三部分：总结与未来方向

• 小米在过去一年中投入了大量精力来稳定 HBase。未来目标包括：
  • 多数据中心灾难恢复。
  • 秒级集群扩展。
  • 多模型引擎集成（如时序、图）。 旨在满足不断变化的成本效率、稳定性和功能需求。

讲师:

Zhiwen Deng，小米分布式系统研发工程师，参与了消息队列和 HBase 的设计与实现，同时也是 Apache RocketMQ 的提交者。