作者： 数据源的TiDB学习之路
本文概述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