環球易購資料平台如何做到既提速又省錢？

環球易購建立于 2007 年，緻力于打造惠通全球的 B2C 跨境電商新零售生态，2014 年通過與百圓褲業并購完成上市，上市公司「跨境通（SZ002640）」是 A 股上市跨境電商第一股。經過多年的努力，在海外市場建立了廣闊的銷售網絡，得到了美國、歐洲等多國客戶的廣泛認可，公司業務多年來一直保持着 100% 的增長速度。

環球易購提供面向全球的跨境電商服務，選擇 AWS 作為雲服務商。基于 EC2 和 EBS 自建 CDH 叢集，計算引擎使用了 Hive 和 Spark。當時的環球易購大資料平台面臨這麼幾個問題：

基于 EBS 搭建的 HDFS 叢集成本很高

Hadoop 叢集缺乏彈性伸縮能力

是以希望能夠在降低 HDFS 存儲成本的同時，不會在性能上造成太大損失。說到降低成本那麼很自然地會聯想到 S3，S3 在提供高達 11 個 9 的資料持久性的同時也能夠做到足夠低廉的存儲成本。但是大資料叢集存儲由 HDFS 遷移到 S3 是唯一選擇麼？遷移和使用中會遇到哪些問題呢？這些我們在後面都會詳細介紹，不過首先來看看為什麼 EBS 自建的 HDFS 叢集成本很高。

EBS 是一種易于使用的高性能資料塊存儲服務，通過挂載到 EC2 上來提供近乎無限容量的存儲空間。為了保證 EBS 上資料的可用性，所有資料都會自動在同一可用區内進行複制，防止資料丢失。

HDFS 是目前大資料領域最常使用的分布式檔案系統，每個檔案由一系列的資料塊組成。同樣的，為了保證資料的可用性，HDFS 預設會将這些資料塊自動複制到叢集中的多個節點上，例如當設定副本數為 3 時同一資料塊在叢集中将會有 3 份拷貝。

通過以上介紹可以看到 EBS 和 HDFS 都會通過複制資料來保證可用性，差別在于 EBS 是隻針對每塊存儲卷（即磁盤）的資料進行複制，而 HDFS 是針對整個叢集的資料。這種雙重備援的機制其實有些多餘，也變相增加了存儲成本。同時 HDFS 的多副本特性使得叢集的實際可用容量會小很多，例如當副本數為 3 時實際可用容量其實隻有總磁盤空間大小的 1/3，再加上通常會在叢集空間到達一定水位時就進行擴容，這會進一步壓縮可用容量。Z基于以上原因，在雲上通過 EBS 自建 HDFS 叢集的存儲成本通常會高達￥1000/TB/月。Hadoop 社群版預設已經支援從 S3 讀寫資料，即通常所說的「S3A」。但是如果你去看 S3A 的官方文檔，會在最開始看到幾個大大的警告，裡面列舉了一些類 S3 的對象存儲都會存在的問題。

Hadoop 社群版預設已經支援從 S3 讀寫資料，即通常所說的「S3A」。但是如果你去看 S3A 的官方文檔，會在最開始看到幾個大大的警告，裡面列舉了一些類 S3 的對象存儲都會存在的問題。

S3 的一緻性模型是最終一緻性，也就是說當建立了一個新檔案以後，并不一定能立即看到它；當對一個檔案執行删除或者更新操作後，有可能還是會讀到舊的資料。這些一緻性問題會導緻程式崩潰，比如常見的 java.io.FileNotFoundException，也可能導緻錯誤的計算結果，更麻煩的是這種錯誤很難發現。我們在測試過程中就因為 S3 的一緻性問題使得執行 DistCp 任務頻繁報錯，導緻資料遷移受到嚴重影響。

S3 中的「目錄」其實是通過對象名稱的字首模拟出來的，是以它并不等價于通常我們在 HDFS 中見到的目錄。例如當周遊一個目錄時，S3 的實作是搜尋具有相同字首的對象。這會導緻幾個比較嚴重的問題：

周遊目錄可能會很慢。周遊的時間複雜度取決于目錄中的總檔案數。

重命名目錄也可能會很慢。跟周遊目錄一樣，總檔案數是影響性能的重要因素。同時 S3 重命名一個檔案其實是先拷貝到新路徑，再删除原始檔案，這個過程也是比較耗時的。

重命名或者删除目錄不是原子操作。HDFS 上隻需要 O(1) 的操作，在 S3 上變成了 O(n)。如果操作過程中任務失敗，将會導緻資料變成一個不可知的中間狀态。

S3 的認證模型是在 S3 服務内部基于 IAM 實作的，這差別于傳統的檔案系統。是以當通過 Hadoop 通路 S3 時會看到檔案的 owner 和 group 會随着目前使用者的身份而動态變化，檔案的權限都是 666，而目錄的權限都是 777。這種與 HDFS 大相徑庭的認證模型會使得權限管理複雜化，并且也顯得不夠通用，隻能限定在 AWS 内使用。

JuiceFS 基于對象存儲實作了一個強一緻性的分布式檔案系統，一方面保持了 S3 彈性伸縮無限容量，99.999999999% 的資料持久性安全特性，另一方面前面提到的 S3 的種種「問題」都能完美解決。同時 JuiceFS 完整相容 Hadoop 生态的各種元件，對于使用者來說可以做到無縫接入。認證模型上 JuiceFS 遵循與 HDFS 類似的 user/group 權限控制方式，保證資料的安全性，也能對接 Hadoop 生态中常用的如 Kerberos、Ranger、Sentry 這些元件。更加重要的是，相比環球易購現有的基于 EBS 的存儲方案，使用 JuiceFS 以後每 TB 每月的存儲成本将會至少節省 70%。

存儲成本大幅下降的同時，性能表現又如何呢？下面分享一下相關的測試結果。

測試環境是 AWS 上自建的 CDH 叢集，CDH 版本為 5.8.5。測試的計算引擎包括 Hive 和 Spark，資料格式包括純文字和 ORC，使用 TPC-DS 20G 和 100G 這兩個規模的資料集。對比的存儲系統有 S3A、HDFS 及 JuiceFS。

這裡以建立<code>store_sales</code>這個分區表為例

這裡以修複 <code>store_sales</code>這個表的分區為例

這裡以讀取<code>store_sales</code>這個分區表并插入臨時表為例

分别使用 Spark 測試了 20G 和 100G 這兩個資料集，取 TPC-DS 前 10 個查詢，資料格式為純文字。

分别使用 Spark 測試了 20G 和 100G 這兩個資料集，取 TPC-DS 前 10 個查詢，資料格式為 ORC。

對于建表和修複表分區這樣的操作，因為依賴對底層中繼資料的頻繁通路（例如周遊目錄），JuiceFS 的性能大幅領先于 S3A，最多有 60 倍的性能提升。

在寫入資料的場景，JuiceFS 的性能相對于 S3A 有 5 倍的提升。這對于 ETL 類型的任務來說非常重要，通常 ETL 任務都會涉及多個臨時表的生成和銷毀，這個過程會産生大量的中繼資料操作（例如重命名、删除）。

當讀取類似 ORC 這種列式存儲格式的資料時，差別于純文字檔案的順序讀取模式，列式存儲格式會産生很多随機通路，JuiceFS 的性能再次大幅領先 S3A，最高可達 63 倍。同時相比于 HDFS，JuiceFS 也能有最多 2 倍的性能提升。

環球易購的大資料平台經過長期的發展已經積攢大量的資料和業務，怎麼從現有方案遷移到新的方案也是評估新方案是否合适的重要因素。在這方面，JuiceFS 提供了多種資料遷移方式：

将資料拷貝到 JuiceFS。這種方式的讀取性能最好，可以高效地利用本地磁盤緩存和分布式緩存，也能保證資料的強一緻性。但是涉及資料拷貝，是以遷移成本比較高。

通過 import 指令将 S3 的資料導入。這種方式隻涉及中繼資料的導入，将 S3 上面的對象導入到 JuiceFS 的目錄樹。這種方式無需拷貝資料，遷移速度快。但是沒有辦法保證強一緻性，并且不能利用緩存加速功能。

通過符号連結将已有資料和新資料融合到一起。JuiceFS 不僅可以在檔案系統内部建立符号連結，也可以跨檔案系統建立符号連結。例如通過<code>ln -s hdfs://dir /jfs/hdfs_dir</code>這行指令可以建立一個指向 HDFS 的符号連結。基于這種方式，可以将曆史資料直接連結到 JuiceFS 中，然後通過統一的 JuiceFS 命名空間通路其它所有 Hadoop 檔案系統。

結合測試結果以及綜合成本分析，全面對比了 HDFS、S3 和 JuiceFS 的方案，環球易購認為 JuiceFS 相比另外兩個方案有顯著的性能和成本優勢，決定用 JuiceFS 替換自建的 HDFS。這些優勢具體展現為以下 3 個方面：

首先，JuiceFS 可以實作從 HDFS 的平滑遷移，對上遊的計算引擎可以做到全面相容，對現有的權限管理體系可以保持一緻，同時性能上沒有任何下降。這幾點對資料平台的遷移可以說是至關重要的，沒有這樣的基礎，資料平台的遷移将是一場耗時耗力的戰役。而有了這樣的基礎，客戶隻用不到一個月的時間就完成了業務和資料的遷移。

第二，在成本方面，「雲上自建 HDFS 的痛點」一節中已經有過說明，基于 EBS 自建 HDFS 單獨計算磁盤成本就大約有￥1000/TB/月，而 JuiceFS 僅為 27%。這還不是 TCO 成本，TCO 還應該包括 HDFS 所消耗的 CPU、記憶體、運維管理投入的人力成本，按經驗值來說至少翻倍。而 JuiceFS 客戶使用全托管服務，沒有任何運維管理的投入。這樣從 TCO 角度看，可以節省近 90% 的成本。

最後，也是最重要的一點。大資料平台的存儲引擎從 HDFS 換成 JuiceFS 後，整個平台就實作了存儲計算分離。現在 JuiceFS 作為完全相容 HDFS 的雲原生檔案系統，已經是基于 Hadoop 生态建構的大資料平台的完美存儲方案。存儲計算分離是大資料平台彈性伸縮的基礎，這一步的改造對環球易購資料平台的架構設計來說也有着重要的意義，接下來環球易購的資料團隊将深入到叢集彈性伸縮、工作負載混合部署等研究和實踐中。