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

背景簡介

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

資料平臺現狀及需求

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

• 基於 EBS 搭建的 HDFS 叢集成本很高
• Hadoop 叢集缺乏彈性伸縮能力

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

雲上自建 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 的物件儲存都會存在的問題。

從 HDFS 遷移到 S3 我們需要考慮什麼？

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

一致性模型（Consistency Model）

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

沒有真實的目錄

S3 中的「目錄」其實是通過物件名稱的字首模擬出來的，因此它並不等價於通常我們在 HDFS 中見到的目錄。例如當遍歷一個目錄時，S3 的實現是搜尋具有相同字首的物件。這會導致幾個比較嚴重的問題：

1. 遍歷目錄可能會很慢。遍歷的時間複雜度取決於目錄中的總檔案數。
2. 重新命名目錄也可能會很慢。跟遍歷目錄一樣，總檔案數是影響效能的重要因素。同時 S3 重新命名一個檔案其實是先拷貝到新路徑，再刪除原始檔案，這個過程也是比較耗時的。
3. 重新命名或者刪除目錄不是原子操作。HDFS 上只需要 O(1) 的操作，在 S3 上變成了 O(n)。如果操作過程中任務失敗，將會導致資料變成一個不可知的中間狀態。

認證模型（Authorization Model）

S3 的認證模型是在 S3 服務內部基於 IAM 實現的，這區別於傳統的檔案系統。因此當通過 Hadoop 訪問 S3 時會看到檔案的 owner 和 group 會隨著當前使用者的身份而動態變化，檔案的許可權都是 666，而目錄的許可權都是 777。這種與 HDFS 大相徑庭的認證模型會使得許可權管理複雜化，並且也顯得不夠通用，只能限定在 AWS 內使用。

JuiceFS 帶來了什麼？

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。

建立表

這裡以建立store_sales這個分割槽表為例

修復表分割槽

這裡以修復 store_sales這個表的分割槽為例

寫入資料

這裡以讀取store_sales這個分割槽表並插入臨時表為例

讀取純文字格式資料

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

讀取 ORC 格式資料

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

測試結果總結

對於建表和修復表分割槽這樣的操作，因為依賴對底層元資料的頻繁訪問（例如遍歷目錄），JuiceFS 的效能大幅領先於 S3A，最多有 60 倍的效能提升。

在寫入資料的場景，JuiceFS 的效能相對於 S3A 有 5 倍的提升。這對於 ETL 型別的任務來說非常重要，通常 ETL 任務都會涉及多個臨時表的生成和銷燬，這個過程會產生大量的元資料操作（例如重新命名、刪除）。

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

資料遷移

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

1. 將資料拷貝到 JuiceFS。這種方式的讀取效能最好，可以高效地利用本地磁碟快取和分散式快取，也能保證資料的強一致性。但是涉及資料拷貝，因此遷移成本比較高。
2. 通過 import 命令將 S3 的資料匯入。這種方式只涉及元資料的匯入，將 S3 上面的物件匯入到 JuiceFS 的目錄樹。這種方式無需拷貝資料，遷移速度快。但是沒有辦法保證強一致性，並且不能利用快取加速功能。
3. 通過符號連結將已有資料和新資料融合到一起。JuiceFS 不僅可以在檔案系統內部建立符號連結，也可以跨檔案系統建立符號連結。例如通過ln -s hdfs://dir /jfs/hdfs_dir這行命令可以建立一個指向 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 生態構建的大資料平臺的完美儲存方案。儲存計算分離是大資料平臺彈性伸縮的基礎，這一步的改造對環球易購資料平臺的架構設計來說也有著重要的意義，接下來環球易購的資料團隊將深入到叢集彈性伸縮、工作負載混合部署等研究和實踐中。

推薦閱讀： 百億級小檔案儲存，JuiceFS 在自動駕駛行業的最佳實踐

專案地址： Github （http://github.com/juicedata/juicefs）如有幫助的話歡迎關注我們喲！ (0ᴗ0✿)