近日，Pinterest 品趣志的工程团队最近公布了弃用 HBase 集群的流程规划，理由是该方案基础设施建设与维护成本过高、HBase 专业人才难寻以及产品功能不足。而随着 Pinterest 也转向 Druid/StarRocks、Goku、KVStore、TiDB 等数据库技术，技术社区开始质疑在 Hadoop 和 HDFS 之上运行非关系数据库的作法是否正迅速衰落。

全球最大的 HBase 部署体系已经逃离 HBase

Pinterest 曾经拥有全世界规模最大的 HBase 生产部署体系，其峰值体量涵盖约 50 个集群、9000 个 AWS EC2 实例并容纳超过 6 PB 数据。典型的生产部署由一个主集群加一个备用集群组成，两端通过 write-ahead-logs（WAL）实现相互复制，借此实现更高的可用性。在线请求首先会被路由到主集群，而离线工作流和资源密集型集群操作（例如日常备份）则在备用集群上进行。一旦主集群发生故障，系统将执行故障转移以切换主集群与备用集群。

Pinterest 公司高级软件工程师 Alberto Ordonez Pereira 及高级工程经理 Lianghong Xu，解释了这家设计灵感分享平台从由 HBase 支持的多项在线存储服务，过渡至具有新型数据存储与统一存储服务的全新架构的过程。

于 2013 年上线的 HBase 是 Pinterest 采用的首个 NoSQL 数据存储方案。随着 NoSQL 的日益普及，HBase 迅速成为 Pinterest 内部使用最广泛的存储后端之一。自那时起，它也成为 Pinterest 技术栈中的基础设施构建块，为一系列内部及开源系统提供支持，具体包括公司的图形服务 Zen、宽列存储 UMS、监控存储 OpenTSDB、指标报告 Pinalytics、事务数据库 Omid/Sparrow、索引数据存储 Ixia 等。这些系统共同支持多种用例，使得 Pinterest 能够显著扩展自身业务，并在过去 10 年间不断扩大用户规模并改进产品体验。

具体影响范围涵盖智能反馈、URL 爬虫、用户消息、pinner 通知、广告索引、购物目录、Statsboard 监控、实验指标等等。

Pinterest 的 HBase 生态系统。HBase 为多种服务提供存储后端，也为整个公司内的广泛应用程序提供支持。

为什么弃用 HBase？

HBase 项目起源于 2007 年，是 Apache Hadoop 的一个子项目，并于 2010 年 2 月发布第一个独立版本。从那时起，它不断发展，每个新版本的稳定性和可扩展性都得到了增强。

HBase 的灵感来源于谷歌的 Bigtable 项目，由 Java 编写而成，是一套基于 HDFS 构建并供 Apache Hadoop 使用的键值存储方案。根据 Pereira 和 Xu 的解释，HBase 是 Pinterest 的第一套 NoSQL 数据存储方案，也是这家图像共享与社交媒体厂商使用最广泛的存储后端之一。

自从在 Pinterest 上线以来，HBase 已经凭借实际表现证明了自身的耐用性、可扩展性以及还算过得去的性能。然而经过全面评估并从利益相关方处收集大量反馈之后，公司于 2021 年底决定放弃这项技术，具体原因他们写道：

HBase 的维护成本已经高得令人望而却步，这主要是受到多年技术债及其可靠性风险的拖累。由于种种历史原因，我们的 HBase 版本落后上游五年，缺少关键性 bug 修复与改进内容。而且由于长期遗留的构建 / 部署 / 配置管线与兼容性问题，Pinterest 内部的 HBase 版本升级又成为一个缓慢且痛苦的过程。

维护成本高

到评估时，HBase 的维护成本已经高得令人望而却步，而这主要是受到多年技术债及其可靠性风险的拖累。由于种种历史原因，Pinterest 的 HBase 版本落后上游五年，缺少关键性 bug 修复与改进内容。而且由于长期遗留的构建 / 部署 / 配置管线与兼容性问题，Pinterest 内部的 HBase 版本升级又成为一个缓慢且痛苦的过程（上次从 0.94 升级至 1.2 版本耗费了近两年时间）。此外，为 HBase 寻找领域专家变得越来越困难，而新工程师的培养门槛也极不友好。

功能缺失

HBase 强调提供相对简单的 NoSQL 接口。虽然能够满足 Pinterest 内部的多种用例，但其有限的功能配置也确实难以满足客户们在强一致性、分布式事务、全局二次索引、丰富查询功能等实践方面不断变化的需求。举例来说，HBase 缺少分布式事务导致 Pinterest 的内部图形服务 Zen 发生多种 bug 和意外事件，原因是局部更新失败可能导致图形效果无法保持一致。调试此类问题往往既困难又耗时，严重影响到服务管理者及客户的情绪和工作 / 使用体验。

系统复杂性过高

为了向客户提供更多高级功能，Pinterest 过去几年间也尝试在 HBase 之上构建了几项新服务。例如，Pinterest 在 HBase 和 Manas realtime 上建立起 Ixia，用以支持 HBase 中的全局二级索引。我们还在 Apache Phoenix Omid 之上构建起 Sparrow，用于支持 HBase 之上的分布式事务。虽然当时根本没有更好的替代方案能够满足业务需求，但这些系统本身也已经造成了巨大的开发成本并成为维护负担的新源头。

夸张的基础设施成本

生产级 HBase 集群通常要借助具有 6 个数据副本的主 - 备用设置以实现快速灾难恢复。但在 Pinterest 的业务规模之下，这会带来极高的基础设施成本。如果能够将 HBase 迁移至数据副本成本较低的数据存储方案，显然有望大大降低基础设施的整体运营开销。举例来说，通过对副本及部署机制的精心设计，TiDB、Rickstore 和 MySQL 都能在保持可用性 SLA 不受太大影响的前提下，实现三副本灾难恢复。

行业使用率与社区使用率双双下降

过去几年来，Pinterest 观察到行业内对于 HBase 的使用率及其社区活跃度似乎稳步下滑，许多同行企业也都在寻求更好的解决方案以替代生产环境下的 HBase 实现。这种趋势反过来又造成人才供应萎缩、准入门槛提高，导致新人工程师们越来越不愿意学习并培养自己的 HBase 业务技能。

弃用 HBase 之路

在 Pinterest，彻底弃用 HBase 曾被认为是一项不可能完成的任务，因为它深深扎根于 Pinterest 现有的技术栈中。然而，Pereira 和 Xu 的团队并不是 Pinterest 内部唯一一个意识到 HBase 在处理不同类型工作负载时存在各种缺点的团队。例如，Pereira 和 Xu 的团队发现 HBase 的表现比最先进的 OLAP 工作负载解决方案更差。它无法跟上不断增长的时间序列数据量，这给可扩展性、性能和维护负载带来了重大挑战。与 KVStore （一种基于 RocksDB 和Rocksplicator 构建的内部键值存储）相比，它的性能和基础效率也不高。因此，在过去几年中，Pereira 和 Xu 的团队启动了多项计划，用更适合这些用例场景的技术取代 HBase。

具体来说，在线分析工作负载将迁移到 Druid / StarRocks，时间序列数据将迁移到 Goku（一种内部时间序列数据存储），键值用例将迁移到 KVStore。经过一系列尝试，该团队找到了在 Pinterest 彻底弃用 HBase 的可行途径。

为了满足其余的 HBase 使用情况，他们还需要一种新技术，它既能提供像 NoSQL 数据库一样的出色可扩展性，又能支持像传统 RDBMS 一样强大的查询功能和 ACID 语义。因此该团队最终选择了 TiDB，算是彻底逃离了 HBase 了。

HBase 是否正走向消亡？

Pinterest 弃用 HBase 的消息在社区中引发了剧烈讨论。在《Pinterest 为何弃用 HBase？HBase 是否正走向消亡》一文中，Shivang Sarawagi 强调称过去五年来 HBase 在谷歌引擎上的搜索量始终稳步下降。文章提到：

虽然 HBase 仍在行业内占有一席之地，但多年来，随着云原生服务的出现，已经有多种替代性解决方案可用于支撑特定系统用例。

在 Hacker News 网站上的一条热门帖中，用户 dehrmann 评论称：

我曾在一家大量采用 HBase 的企业工作。他们从 AWS 迁移到 GCP 就是为了向 BigTable 靠拢……HBase 和 HDFS 的管理强度很高，而且非常不可靠，迫使大家只能随时设置一套故障转移集群。有趣的是，迁移过程中还出现了单元 / 表退化，这可能也是造成可靠性问题的部分原因。

Pinterest 之前曾分享过他们如何将部分工作负载从 HBase 迁移至 TiDB，且不造成任何停机。Sarawagi 补充道：随着现代数据库的出现，业界的关注焦点正逐渐从 HBase 身上移开。然而，还不能说这项技术已经就此过时。

参考链接：

https://www.infoq.com/news/2024/06/pinterest-deprecates-hbase/

https://medium.com/pinterest-engineering/online-data-migration-from-hbase-to-tidb-with-zero-downtime-43f0fb474b84

本文来自公众号：谈数据