將Hadoop遷移至雲端：存儲容量翻倍，運營成本降低

Yimian 是一家領先的AI驅動數據分析服務商，專注於數位商務數據。我們提供實時的商業策略、產品開發及數位商務運營洞察。許多客戶如寶潔、聯合利華和瑪氏等，均為個人護理、化妝品、食品飲料、寵物及汽車行業的領導者。

我們最初採用的是基於CDH（Cloudera Distributed Hadoop）構建的大數據集群，部署於本地數據中心。隨著業務擴張，數據量急劇增長，面臨擴展周期長、計算與存儲資源不匹配及維護成本高等挑戰。

為此，我們決定重構數據架構，遷移至雲端，採用計算與存儲分離策略。經過仔細評估，我們選擇了阿里雲彈性MapReduce（EMR） + JuiceFS + 阿里雲對象存儲服務（OSS）。

目前，借助JuiceFS，我們已實現計算與存儲解耦的架構，存儲容量翻倍，且未觀察到明顯的性能影響，運營成本大幅降低。

在本文中，我們將分享將Hadoop遷移至雲端的架構設計，闡述為何選擇JuiceFS+EMR+OSS，以及新架構帶來的益處。我們旨在透過此文，為面臨類似挑戰的讀者提供寶貴見解。

舊有架構與挑戰

為滿足日益增長的需求，我們從數百個大型網站爬取數據，目前數量已超過500個。隨著時間推移，我們積累了大量原始、中間及結果數據。隨著網站爬取範圍與客戶基礎的擴大，數據量急劇增長。因此，我們決定擴展硬件以應對日益增長的需求。

原始架構

下圖展示了我們先前的架構，一個基於CDH的大數據集群部署在數據中心內：

• 主要組件包括Hive、Spark及HDFS。
• 多個數據生產系統，其中Kafka為一例，將數據輸入集群。
• 我們還使用了其他存儲解決方案，如TiDB、HBase及MySQL，與Kafka並行。

Original architecture at Yimian

數據從上游應用系統及數據收集系統流入，並寫入Kafka。我們利用Kafka Connect集群將數據同步至HDFS。

在此架構基礎上，我們開發了名為OneWork的定制數據開發平台，用以管理各項任務。這些任務通過Airflow進行排程，並在任務隊列中處理。

我們的痛點

面臨的挑戰如下：

• 應用數據快速增長與擴展週期過長： 我們於2016年部署的CDH集群，至2021年已處理了數PB的數據。然而，數據增長常超出硬件規劃，導致每六個月須頻繁擴展，耗費大量資源與時間。
• 存儲與計算緊耦合及容量規劃困難： 傳統Hadoop架構中存儲與計算的緊密耦合，使得根據存儲或計算需求進行獨立擴展與規劃變得困難。例如，擴展存儲亦需購買不必要的計算資源，導致資源配置效率低下。
• 因CDH版本老舊而不敢升級： 我們的CDH版本過時，因擔憂穩定性與兼容性問題而猶豫升級。
• 高運營成本： 公司約有200名員工，僅配備一名全職運維人員，造成沉重工作負擔。為緩解此狀況，我們尋求更穩定且簡化的架構。
• 單一數據中心單點故障風險： 所有數據存於單一數據中心，長期存在風險。若遇電纜損壞或其他問題，單一數據中心即成為單點故障。

新架構需求

為應對挑戰並滿足日益增長的需求，我們決定進行架構調整。升級時考慮的主要方面包括：

• 雲端採用、彈性擴展性及運營靈活性：採用雲端服務能簡化運營。例如，利用基於雲端的儲存讓我們專注於應用程式，同時避免維護工作。此外，雲端資源實現了無需冗長硬體部署和系統配置的彈性擴展性。
• 儲存與計算脫鉤：我們旨在分離儲存和計算以實現更好的靈活性和效能。
• 偏好開源元件，避免供應商鎖定：儘管我們使用雲端服務，但我們力求減少對特定供應商的依賴。在使用 AWS Redshift 提供客戶服務的同時，我們傾向於開源元件用於內部運營。
• 與現有解決方案兼容，控制成本和風險：我們的目標是確保與當前解決方案的兼容性，以最小化開發成本並減少對我們應用程式的影響。

為何選擇 JuiceFS+EMR+OSS

在評估了多種解決方案後，我們選擇了 EMR+JuiceFS+OSS 來建立一個儲存與計算分離的大數據平台，並逐步將我們的本地數據中心遷移至雲端。

New architecture at Yimian

在此配置中，物件儲存取代了 HDFS，而 JuiceFS 作為協議層因其支援 POSIX 和 HDFS 協議。在其上，我們使用了一種半管理式 Hadoop 解決方案，EMR。它包含了 Hive、Impala、Spark、Presto/Trino 等元件。

阿里雲 vs. 其他公有雲

經過仔細評估，我們選擇了阿里雲而非 AWS 和 Azure，主要基於以下因素：

• 近接性: 阿里雲的可用區與我們的數據中心位於同一城市，確保了低延遲和降低的網絡成本。
• 全面的開源組件: 阿里雲EMR提供廣泛的Hadoop相關開源組件。除了我們大量使用的Hive、Impala、Spark和Hue外，它還提供與Presto、Hudi、Iceberg等無縫集成。在我們的研究中，發現只有EMR原生包含Impala，而AWS和Azure要么提供較低版本，要么需要手動安裝和部署。

JuiceFS vs. JindoFS

什麼是JuiceFS？

JuiceFS 是一個開源、雲原生、高性能的分佈式文件系統。它提供完整的POSIX兼容性，允許對象存儲跨不同平台和區域用作大型本地磁盤。

JuiceFS採用數據-元數據分離的架構，支持分佈式文件系統設計。使用JuiceFS存儲數據時，數據持久化在Amazon S3等對象存儲中，而元數據可以存儲在Redis、MySQL、TiKV、SQLite等數據庫中。

除了POSIX外，JuiceFS完全兼容HDFS SDK，允許無縫替換HDFS以實現存儲計算分離。

The JuiceFS architecture

為何我們選擇JuiceFS而非JindoFS

我們基於以下考慮選擇了JuiceFS而非JindoFS：

• 儲存設計： JuiceFS 採用數據與元數據分離的儲存架構，實現了分散式文件系統的設計。數據持久化於對象儲存中，而元數據則可存於 Redis、MySQL、TiKV、SQLite 等多種數據庫，提供更高的靈活性。相較之下，JindoFS 的元數據儲存於 EMR 集群的本地硬盤，使得維護、升級與遷移較為不便。
• 儲存靈活性： JuiceFS 提供多種儲存方案，支援不同方案間的在線遷移，增強了可攜性。JindoFS 塊數據僅支援 OSS。
• 開源社區支持： JuiceFS 基於開源社區，支援所有公有雲環境，有利於未來擴展至多雲架構。

整體架構設計

考慮到某些應用仍將保留在數據中心的 Hadoop 集群中，我們實際上採用了混合雲架構，如下圖所示。

A hybrid cloud architecture

在架構圖中：

• 頂部是 Airflow 和 OneWork，兩者均支援分散式部署，因此可以輕鬆進行水平擴展。
• 左側是 IDC，使用傳統的 CDH 架構及部分 Kafka 集群。
• 右側是在阿里雲上部署的 EMR 集群。

IDC 與 EMR 集群通過高速專線相連。

我們如何從新架構中獲益

儲存與計算分離的優勢

隨著存儲與計算解耦的實施，我們的總存儲容量已翻倍，而計算資源保持穩定。偶爾，我們會根據需要啟用臨時任務節點。在我們的場景中，數據量快速增長，而查詢需求保持穩定。自2021年以來，我們的數據量已翻倍。從初始階段至今，我們對計算資源的調整微乎其微，除了偶爾啟用彈性資源和臨時任務節點以應對特定的應用需求。

性能變化

對於我們主要涉及大規模批量處理的離線計算應用場景，性能並未受到顯著影響。但在概念驗證（PoC）階段，我們觀察到即席Impala查詢的響應時間有所改善。

在PoC階段，我們進行了一些簡單測試。然而，由於多種影響因素，準確解讀結果頗具挑戰：

• 從HDFS過渡到JuiceFS
• 組件版本升級
• Hive引擎的變更
• 集群負載的變化

這些因素使得與我們之前在裸金屬服務器上部署的CDH相比，關於性能差異的明確結論難以得出。

易用性與穩定性

我們在使用JuiceFS時未遇到問題。

在使用EMR時，我們遇到了一些小問題。總體而言，CDH被認為更穩定且用戶友好。

實施複雜度

在我們的場景中，最耗時的流程是增量雙寫和數據驗證。回顧過去，我們在驗證上投入過多，其實可以簡化。

多種因素影響複雜性：

• 應用場景（離線/實時、表/任務數量、上層應用）
• 組件版本
• 支持工具及儲備

未來計劃

我們的未來計劃包括：

• 繼續將剩餘應用遷移至雲端。
• 探索使用JuiceFS+OSS的冷/熱分層存儲策略。JuiceFS文件在OSS上完全拆解，使得實現文件級分層較為困難。我們目前的做法是將JuiceFS中的冷數據遷移至OSS，設為歸檔存儲，並在不影響使用的情況下修改Hive表或分區的LOCATION。
• 如果數據量增長，使用Redis有壓力，未來可能考慮轉向TiKV或其他引擎。
• 探索EMR的彈性計算實例，以降低使用成本同時滿足應用服務級別協議。