近日，Pinterest 品趣志的工程團隊最近公布了棄用 HBase 集群的流程規(guī)劃，理由是該方案基礎設施建設與維護成本過高、HBase 專業(yè)人才難尋以及產(chǎn)品功能不足。而隨著 Pinterest 也轉向 Druid/StarRocks、Goku、KVStore、TiDB 等數(shù)據(jù)庫技術，技術社區(qū)開始質疑在 Hadoop 和 HDFS 之上運行非關系數(shù)據(jù)庫的作法是否正迅速衰落。

全球最大的 HBase 部署體系 已經(jīng)逃離 HBase

Pinterest 曾經(jīng)擁有全世界規(guī)模最大的 HBase 生產(chǎn)部署體系，其峰值體量涵蓋約 50 個集群、9000 個 AWS EC2 實例并容納超過 6 PB 數(shù)據(jù)。典型的生產(chǎn)部署由一個主集群加一個備用集群組成，兩端通過 write-ahead-logs（WAL）實現(xiàn)相互復制，借此實現(xiàn)更高的可用性。在線請求首先會被路由到主集群，而離線工作流和資源密集型集群操作（例如日常備份）則在備用集群上進行。一旦主集群發(fā)生故障，系統(tǒng)將執(zhí)行故障轉移以切換主集群與備用集群。

Pinterest 公司高級軟件工程師 Alberto Ordonez Pereira 及高級工程經(jīng)理 Lianghong Xu，解釋了這家設計靈感分享平臺從由 HBase 支持的多項在線存儲服務，過渡至具有新型數(shù)據(jù)存儲與統(tǒng)一存儲服務的全新架構的過程。

于 2013 年上線的 HBase 是 Pinterest 采用的首個 NoSQL 數(shù)據(jù)存儲方案。隨著 NoSQL 的日益普及，HBase 迅速成為 Pinterest 內部使用最廣泛的存儲后端之一。自那時起，它也成為 Pinterest 技術棧中的基礎設施構建塊，為一系列內部及開源系統(tǒng)提供支持，具體包括公司的圖形服務 Zen、寬列存儲 UMS、監(jiān)控存儲 OpenTSDB、指標報告 Pinalytics、事務數(shù)據(jù)庫 Omid/Sparrow、索引數(shù)據(jù)存儲 Ixia 等。這些系統(tǒng)共同支持多種用例，使得 Pinterest 能夠顯著擴展自身業(yè)務，并在過去 10 年間不斷擴大用戶規(guī)模并改進產(chǎn)品體驗。

具體影響范圍涵蓋智能反饋、URL 爬蟲、用戶消息、pinner 通知、廣告索引、購物目錄、Statsboard 監(jiān)控、實驗指標等等。

Pinterest 的 HBase 生態(tài)系統(tǒng)。HBase 為多種服務提供存儲后端，也為整個公司內的廣泛應用程序提供支持。

為什么棄用 HBase？

HBase 項目起源于 2007 年，是 Apache Hadoop 的一個子項目，并于 2010 年 2 月發(fā)布第一個獨立版本。從那時起，它不斷發(fā)展，每個新版本的穩(wěn)定性和可擴展性都得到了增強。

HBase 的靈感來源于谷歌的 Bigtable 項目，由 Java 編寫而成，是一套基于 HDFS 構建并供 Apache Hadoop 使用的鍵值存儲方案。根據(jù) Pereira 和 Xu 的解釋，HBase 是 Pinterest 的第一套 NoSQL 數(shù)據(jù)存儲方案，也是這家圖像共享與社交媒體廠商使用最廣泛的存儲后端之一。

自從在 Pinterest 上線以來，HBase 已經(jīng)憑借實際表現(xiàn)證明了自身的耐用性、可擴展性以及還算過得去的性能。然而經(jīng)過全面評估并從利益相關方處收集大量反饋之后，公司于 2021 年底決定放棄這項技術，具體原因他們寫道：

HBase 的維護成本已經(jīng)高得令人望而卻步，這主要是受到多年技術債及其可靠性風險的拖累。由于種種歷史原因，我們的 HBase 版本落后上游五年，缺少關鍵性 bug 修復與改進內容。而且由于長期遺留的構建 / 部署 / 配置管線與兼容性問題，Pinterest 內部的 HBase 版本升級又成為一個緩慢且痛苦的過程。

 維護成本高

到評估時，HBase 的維護成本已經(jīng)高得令人望而卻步，而這主要是受到多年技術債及其可靠性風險的拖累。由于種種歷史原因，Pinterest 的 HBase 版本落后上游五年，缺少關鍵性 bug 修復與改進內容。而且由于長期遺留的構建 / 部署 / 配置管線與兼容性問題，Pinterest 內部的 HBase 版本升級又成為一個緩慢且痛苦的過程（上次從 0.94 升級至 1.2 版本耗費了近兩年時間）。此外，為 HBase 尋找領域專家變得越來越困難，而新工程師的培養(yǎng)門檻也極不友好。

功能缺失

HBase 強調提供相對簡單的 NoSQL 接口。雖然能夠滿足 Pinterest 內部的多種用例，但其有限的功能配置也確實難以滿足客戶們在強一致性、分布式事務、全局二次索引、豐富查詢功能等實踐方面不斷變化的需求。舉例來說，HBase 缺少分布式事務導致 Pinterest 的內部圖形服務 Zen 發(fā)生多種 bug 和意外事件，原因是局部更新失敗可能導致圖形效果無法保持一致。調試此類問題往往既困難又耗時，嚴重影響到服務管理者及客戶的情緒和工作 / 使用體驗。

系統(tǒng)復雜性過高

為了向客戶提供更多高級功能，Pinterest 過去幾年間也嘗試在 HBase 之上構建了幾項新服務。例如，Pinterest 在 HBase 和 Manas realtime 上建立起 Ixia，用以支持 HBase 中的全局二級索引。我們還在 Apache Phoenix Omid 之上構建起 Sparrow，用于支持 HBase 之上的分布式事務。雖然當時根本沒有更好的替代方案能夠滿足業(yè)務需求，但這些系統(tǒng)本身也已經(jīng)造成了巨大的開發(fā)成本并成為維護負擔的新源頭。

夸張的基礎設施成本

生產(chǎn)級 HBase 集群通常要借助具有 6 個數(shù)據(jù)副本的主 - 備用設置以實現(xiàn)快速災難恢復。但在 Pinterest 的業(yè)務規(guī)模之下，這會帶來極高的基礎設施成本。如果能夠將 HBase 遷移至數(shù)據(jù)副本成本較低的數(shù)據(jù)存儲方案，顯然有望大大降低基礎設施的整體運營開銷。舉例來說，通過對副本及部署機制的精心設計，TiDB、Rickstore 和 MySQL 都能在保持可用性 SLA 不受太大影響的前提下，實現(xiàn)三副本災難恢復。

行業(yè)使用率與社區(qū)使用率雙雙下降

過去幾年來，Pinterest 觀察到行業(yè)內對于 HBase 的使用率及其社區(qū)活躍度似乎穩(wěn)步下滑，許多同行企業(yè)也都在尋求更好的解決方案以替代生產(chǎn)環(huán)境下的 HBase 實現(xiàn)。這種趨勢反過來又造成人才供應萎縮、準入門檻提高，導致新人工程師們越來越不愿意學習并培養(yǎng)自己的 HBase 業(yè)務技能。

棄用 HBase 之路

在 Pinterest，徹底棄用 HBase 曾被認為是一項不可能完成的任務，因為它深深扎根于 Pinterest 現(xiàn)有的技術棧中。然而，Pereira 和 Xu 的團隊并不是 Pinterest 內部唯一一個意識到 HBase 在處理不同類型工作負載時存在各種缺點的團隊。例如，Pereira 和 Xu 的團隊發(fā)現(xiàn) HBase 的表現(xiàn)比最先進的 OLAP 工作負載解決方案更差。它無法跟上不斷增長的時間序列數(shù)據(jù)量，這給可擴展性、性能和維護負載帶來了重大挑戰(zhàn)。與 KVStore （一種基于 RocksDB 和Rocksplicator 構建的內部鍵值存儲）相比，它的性能和基礎效率也不高。因此，在過去幾年中，Pereira 和 Xu 的團隊啟動了多項計劃，用更適合這些用例場景的技術取代 HBase。

具體來說，在線分析工作負載將遷移到 Druid / StarRocks，時間序列數(shù)據(jù)將遷移到 Goku（一種內部時間序列數(shù)據(jù)存儲），鍵值用例將遷移到 KVStore。經(jīng)過一系列嘗試，該團隊找到了在 Pinterest 徹底棄用 HBase 的可行途徑。

為了滿足其余的 HBase 使用情況，他們還需要一種新技術，它既能提供像 NoSQL 數(shù)據(jù)庫一樣的出色可擴展性，又能支持像傳統(tǒng) RDBMS 一樣強大的查詢功能和 ACID 語義。因此該團隊最終選擇了 TiDB，算是徹底逃離了 HBase 了。

HBase 是否正走向消亡？

Pinterest 棄用 HBase 的消息在社區(qū)中引發(fā)了劇烈討論。在《Pinterest 為何棄用 HBase？HBase 是否正走向消亡》一文中，Shivang Sarawagi 強調稱過去五年來 HBase 在谷歌引擎上的搜索量始終穩(wěn)步下降。文章提到：

雖然 HBase 仍在行業(yè)內占有一席之地，但多年來，隨著云原生服務的出現(xiàn)，已經(jīng)有多種替代性解決方案可用于支撐特定系統(tǒng)用例。

在 Hacker News 網(wǎng)站上的一條熱門帖中，用戶 dehrmann 評論稱：

我曾在一家大量采用 HBase 的企業(yè)工作。他們從 AWS 遷移到 GCP 就是為了向 BigTable 靠攏……HBase 和 HDFS 的管理強度很高，而且非常不可靠，迫使大家只能隨時設置一套故障轉移集群。有趣的是，遷移過程中還出現(xiàn)了單元 / 表退化，這可能也是造成可靠性問題的部分原因。

Pinterest 之前曾分享過他們如何將部分工作負載 從 HBase 遷移至 TiDB，且不造成任何停機。Sarawagi 補充道：隨著現(xiàn)代數(shù)據(jù)庫的出現(xiàn)，業(yè)界的關注焦點正逐漸從 HBase 身上移開。然而，還不能說這項技術已經(jīng)就此過時。

參考鏈接：

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

被全球最大用戶棄用！曾經(jīng)的數(shù)據(jù)庫霸主 HBase 正在消亡_hbase 替代-CSDN博客