作者： 数据源的 TiDB 学习之路原文来源：https://tidb.net/blog/e7ff8748

本文概述 HBase 在 Pinterest 公司的使用情况，为什么从 HBase 迁移到 TiDB，以及迁移的大致执行路径。

HBase 在 Pinterest 的整体情况

HBase 于 2013 年推出，是 Pinterest 的第一个 NoSQL 数据存储。随着 NoSQL 的日益流行，HBase 迅速成为 Pinterest 最广泛使用的存储后端之一。自此以后，它一直是 Pinterest 技术栈中基础架构的核心组成部分，支持了包括图形服务（Zen）、宽列存储（UMS）、监控存储（OpenTSDB）、指标报告（Pinalytics）、事务数据库（Omid/Sparrow）、索引数据存储（Ixia）等在内的众多内部和开源系统。这些系统共同支持了无数用例，使 Pinterest 能够在过去 10 年中随着用户基数的增长和产品的发展而显著扩展其业务。示例包括智能推送、URL 爬虫、用户消息、Pinner 通知、广告索引、购物目录、Statsboard（监控）、实验指标等。下图展示了 Pinterest 围绕 HBase 构建的庞大生态系统。

Pinterest 托管了世界上最大规模的 HBase 生产部署之一。在其使用高峰期，拥有约 50 个集群、9000 个 AWS EC2 实例和超过 6 PB 的数据。典型的生产部署包括一个主集群和一个备用集群，它们之间使用预写日志（WALs）进行相互复制以提高可用性。在线请求被路由到主集群，而离线工作流和资源密集型的集群操作（例如，每日备份）则在备用集群上执行。当主集群出现故障时，会执行集群级别的故障转移以切换主集群和备用集群。

为什么要放弃 HBase

自从在 Pinterest 引入以来，HBase 被证明是持久、可扩展且通常性能良好的技术。然而，在 2021 年底，Pinterest 经过慎重的评估之后决定弃用这项技术，原因主要有以下几点。

维护成本高，版本升级缓慢而又痛苦

由于多年的技术债务和可靠性风险，HBase 的维护成本变得非常高昂。由于历史原因，HBase 版本比上游版本落后了五年，错过了关键的错误修复和改进。然而，由于遗留的构建 / 部署 / 供应管道和兼容性问题（从 0.94 版升级到 1.2 版就花了将近两年时间），HBase 的版本升级是一个缓慢且痛苦的过程。此外，越来越难以找到 HBase 领域的专家，对于新工程师来说，入门门槛也非常高。

功能缺失，不支持强一致性、分布式事务、全局二级索引等功能

HBase 被设计用来提供一个相对简单的 NoSQL 接口。虽然满足了客户许多用例的需求，但很难满足对更强一致性、分布式事务、全局二级索引、丰富的查询能力等方面的要求。以具体例子来说，HBase 缺乏分布式事务导致了客户内部图形服务 Zen 的多个错误和事故，因为部分失败的更新可能使图形处于不一致的状态。调试此类问题通常既困难又耗时，给服务所有者和他们的客户带来了挫败感。

系统复杂度越来越高，为弥补 HBase 功能不足增加更多的系统

为了给客户提供一些高级功能，Pinterest 在 HBase 之上构建了几个新服务，比如在 HBase 之上构建了 Ixia 和 Manas 实时服务以支持 HBase 中的全局二级索引。在 Apache Phoenix Omid 之上构建了 Sparrow，以在 HBase 之上支持分布式事务。由于当时也没有更好的选择来满足业务需求，但这些系统产生了显著的开发成本，并增加了维护负担。

基础设施成本高，生产需采用主备集群部署共 6 副本

生产中的 HBase 集群通常使用主备设置，具有六个数据副本以进行快速灾难恢复，但由于集群规模很大导致带来了极高的基础设施成本。将 HBase 迁移到每个唯一数据副本成本更低的其他数据存储将带来巨大的基础设施节省机会。例如，通过合理的副本复制和放置机制，TiDB、Rockstore 或 MySQL 可能使用三个副本而不牺牲太多可用性 SLA。

行业使用率和社区支持减少，人才库缩小、入门门槛更高

在过去的几年里，HBase 的使用和行业社区活动在稳步下降，许多同行公司都在寻找更好的替代方案来替换他们生产环境中的 HBase。这反过来又导致了人才库的缩小、更高的入门门槛以及新工程师成为 HBase 主题专家的激励减少。

替换路径

在 Pinterest，完全弃用 HBase 曾被视为一项不可能完成的任务，因为它已深深扎根于现有的技术栈中。但公司内部有很多团队都逐渐意识到 HBase 在处理不同类型工作负载时存在各种缺点。例如，他们发现 HBase 在 OLAP 工作负载上的表现不如最先进的解决方案。它无法跟上不断增长的时间序列数据量，这导致了在可扩展性、性能和维护负载方面的重大挑战。与基于 RocksDB 和 Rocksplicator 构建的内部键值存储 KVStore 相比，HBase 在性能和基础设施效率方面也不尽如人意。因此，在过去的几年中，Pinterest 开始了几项计划，以使用更适合这些用例场景的技术替换 HBase。具体来说，在线分析工作负载将迁移到 Druid/StarRocks，时间序列数据将迁移到内部时间序列数据存储 Goku，键值用例将迁移到 KVStore。

为了容纳剩余的 HBase 用例，Pinterest 需要一种新技术，它既能像 NoSQL 数据库一样提供出色的可扩展性，又能像传统 RDBMS 一样支持强大的查询能力和 ACID 语义。最终，他们选择了 TiDB，TiDB 满足了他们大部分需求。

注：本文引用自 https://medium.com/pinterest-engineering/hbase-deprecation-at-pinterest-8a99e6c8e6b7