【雲原生AI】Fluid + JindoFS 助力微博海量小文件模型訓練速度提高 18 倍

簡介： 深度學習平臺在微博社交業務扮演着重要的角色。計算存儲分離架構下，微博深度學習平臺在數據訪問與調度方面存在性能低效的問題。本文將介紹微博內部設計實現的一套全新的基於 Fluid（內含 JindoRuntime）的新架構方案，顯著提高了海量小文件場景模型訓練的性能和穩定性，多機多卡分佈式訓練場景可將模型訓練的速度提高 18 倍。

做者 ｜
吳彤 微博深度學習平臺工程師
郝麗 微博深度學習平臺工程師

導讀：深度學習平臺在微博社交業務扮演着重要的角色。計算存儲分離架構下，微博深度學習平臺在數據訪問與調度方面存在性能低效的問題。本文將介紹微博內部設計實現的一套全新的基於 Fluid（內含 JindoRuntime）的新架構方案，顯著提高了海量小文件場景模型訓練的性能和穩定性，多機多卡分佈式訓練場景可將模型訓練的速度提高 18 倍。

背景​
​
新浪微博是中國最大的社交媒體平臺，天天上億條內容產生並在萬億級關係的社交網絡上進行傳播。下圖是微博的業務生態圖，經過優質用戶生產、傳播優質內容，普通用戶消費這些內容，進而關注本身喜歡的博主，創建聯繫，造成閉環生態。

微博機器學習平臺的主要做用是讓整個過程流轉得更高效流暢：經過理解優質內容，構建用戶畫像，把用戶感興趣的優質內容推給用戶，讓他們和內容生產者互動，進而刺激生產者生產更多更好的內容, 實現信息消費者和信息生產者的共贏。而隨着多媒體內容變成主流，深度學習技術就變得更爲重要。從多媒體的內容理解，到 CTR 任務的優化，都離不開深度學習技術的支持。
​

大規模深度學習模型訓練挑戰
​
隨着深度學習在微博業務場景中的普遍使用，微博深度學習平臺扮演了很是核心的角色。該平臺採用了存儲與計算分離的架構，使得計算資源得以與存儲資源解耦，從而實現了靈活的資源配比以及便捷的存儲擴展，而且下降了存儲成本。

然而，這種架構也帶來了一些挑戰，其中比較關鍵的問題體如今數據訪問性能和穩定性方面：
​

計算存儲分離架構致使數據訪問高延時，致使訓練慢：業務團隊使用的深度學習任務（圖像或語音模型）會訪問海量小文件。實驗代表，HDFS 讀取海量小文件場景與本地讀取對比性能相差近十倍甚至百倍。
Kubernetes 調度器數據緩存無感知，同一數據源屢次運行訪問依舊慢：相同模型、不一樣超參的；微調模型、相同輸入的；AutoML 等深度學習任務運行會不斷重複訪問同一數據，產生能夠複用的數據緩存。可是因爲原生的 Kubernetes 調度器沒法感知緩存，致使應用調度的結果不佳，緩存沒法重用，性能得不到提高。
多數深度學習框架並不支持 HDFS 接口，致使開發難：好比 PyTorch，MxNet 等框架只支持 POSIX 協議接口，HDFS 接口須要額外的對接開發。所以須要同時支持模型開發階段的 POSIX 接口以及模型訓練階段的 HDFS 接口，引入模型代碼適配不一樣存儲的複雜性。
HDFS 成爲數據併發訪問的瓶頸點，穩定性挑戰大：微博機器學習平臺上百臺 GPU 機器同時訓練都會併發訪問 HDFS 集羣，同時深度學習訓練的 IO 壓力比較大，HDFS 服務成爲了性能單點，這對 HDFS 的性能和穩定性提出了巨大的挑戰。一旦某個任務拖慢了 HDFS 系統，其餘的訓練任務也會受到影響。並且，一旦 HDFS 沒法工做，整個訓練集羣也會受到影響。
經過對微博深度學習平臺的監控分析，咱們發現：一方面因爲 IO 性能問題致使 GPU 等昂貴計算資源不能被充分利用；另外一方面，咱們也發現集羣中的內存和本地硬盤的水位很低，餘量較多而且穩定，這是因爲多數的深度學習任務並不使用本地磁盤，同時內存使用率也不高。所以咱們考慮若是可以充分利用集羣自身的內存和磁盤資源加速數據訪問會是一種更好的方案。

Fluid + JindoRuntime：爲微博深度學習平臺提供高效支撐
​
爲了能更好知足大規模深度學習模型訓練的計算需求，須要取得更好的數據本地性效果。所以，咱們但願達到如下目標：

計算可以充分利用本地化訪問數據，這樣數據就不需經過網絡反覆讀取，加速深度學習模型訓練的速度和提高集羣的 GPU 使用率。
下降 HDFS 負載壓力，經過應用對於部分數據的本地讀取，減少數據訪問延時和提高 HDFS 的可用性。
充分發揮熱點數據集的緩存節點優點，在對用戶無感知的前提下，智能的將任務調度到數據緩存節點上。讓經常使用的模型訓練程序愈來愈快。
經過 POSIX 接口讀取數據，這樣無需在模型開發和訓練階段使用不一樣的數據訪問接口，下降開發深度學習模型程序的成本。
爲了達到上述目標，咱們迫切但願找到 Kubernetes 上具備分佈式緩存加速能力的軟件。很幸運，咱們發現 CNCF Sandbox 項目 Fluid 正好能夠知足咱們的訴求。因而，咱們設計了基於 Fluid 的新架構方案，通過驗證比較，咱們選擇 JindoRuntime 做爲加速運行時。
​

1. 架構組件介紹
   ​

1）Fluid
​

Fluid[1] 是一個運行在 Kubernetes 上可擴展的分佈式數據編排和加速系統，它經過數據的編排和使用數據的應用調度，解決雲原生編排框架運行此類應用面臨數據訪問延時高、多數據源聯合分析難、應用使用數據過程複雜等痛點。
​

2）JindoRuntime
​

JindoRuntimed[2] 是 Fluid 一種分佈式緩存 Runtime 的實現，基於 JindoFS 分佈式緩存加速引擎。JindoFS 是阿里雲 EMR 團隊自研大數據存儲優化引擎，徹底兼容 Hadoop 文件系統接口，給客戶帶來更加靈活、高效的計算存儲方案。JindoRuntime 使用 JindoFS 的 Cache 模式進行遠端文件的訪問和緩存，支持 OSS、HDFS、標準 S3 協議等多種存儲產品的訪問和緩存加速。在 Fluid 上使用和部署 JindoRuntime 流程簡單、兼容原生 K8s 環境、能夠開箱即用。深度結合對象存儲特性，使用 Navite 框架優化性能，並支持免密、checksum 校驗等雲上數據安全功能。
​

2. 使用基於 JindoRuntime 的 Fluid 的緣由
   ​

Fluid 能夠將數據集編排在 Kubernetes 集羣中，實現數據和計算的同置，而且提供基於 Persistent Volume Claim 接口，實現 Kubernetes 上應用的無縫對接。同時 JindoRuntime 提供對 HDFS 上數據的訪問和緩存加速能力，而且能夠利用 FUSE 的 POSIX 文件系統接口實現能夠像本地磁盤同樣輕鬆使用 HDFS 上的海量文件，pytorch 等深度學習訓練工具可利用 POSIX 文件接口讀取訓練數據。
針對海量小文件的遠程數據訪問性能問題，JindoRuntime 對小文件的數據組織管理和訪問性能進行了大量針對性的優化，可以提供高效的小文件訪問性能，遠高於直接對 HDFS 的數據訪問性能。
提供元數據和數據分佈式分層緩存，以及高效小文件檢索。
提供數據預熱機制，避免在訓練時刻拉取數據形成的數據訪問競爭。
Slab allocation 方式組織文件數據，高效利用緩存空間。
經過 Fluid 的數據感知調度能力，用戶無需知道緩存節點信息就能夠將任務放置到有緩存數據的節點，實現數據訪問性能的優點最大化。
對於大文件和小文件提供不一樣的緩存策略和存儲方式，對於小文件 AI 訓練場景具備很好的自適應性，無需用戶配置。

3. 落地實踐
   ​

選擇合適的緩存節點：使用 JindoRuntime 能夠得到更好的數據本地性能，在實際生產中咱們也發現不是全部的節點都來作緩存性能就比較好。緣由是有些節點的磁盤和網絡 IO 性能不是很好，這個時候須要咱們可以把緩存節點儘可能選擇一些大容量磁盤和網絡較好的節點上去。Fluid 支持 dataset 的可調度性，換言之就是緩存節點的可調度性，咱們經過指定 dataset 的 nodeAffinity 來進行數據集緩存節點的調度，從而保證緩存節點可高效的提供緩存服務。
指定 Master 調度策略：JindoRuntime 由 master/worker/fuse 三部分組成，master 負責集羣的大腦，負責元數據和集羣緩存的管理，因此 master 節點得具備很強的可靠性和故障恢復速度。在生產過程當中咱們發如今不使用多 master 的條件下，單個 master 也具備很強的穩定性和故障恢復速度，影響 master 節點穩定性的重要因素仍是宿主機的穩定性，好比宿主機滿磁盤、通訊故障等，基於此咱們對 mater 節點使用 nodeselector 來選擇性能較好的宿主機做爲 master 容器的環境，進一步保證 master 環境的穩定性。
定時數據預熱：在進行訓練前的一個重要的步驟是進行元數據和數據的預熱，Fluid 提供了 CRD 的形式進行元數據和數據的緩存，在訓練前將訓練文件的元數據和數據緩存到本地，可大大加速訓練速度。可是存儲在 HDFS 上的訓練文件是天天一次更新，因而須要進行週期性定時的進行數據預熱流程，基於 dataload 的 CRD，咱們使用 cronJob 的形式進行週期性調度，使得在每次訓練前都可以完成元數據和數據的準備，從而進行高效訓練。固然 JindoRuntime 自己也支持增量同步的功能，因此每次只須要更新變化的文件便可，也大大加快了數據預熱的速度。

4. 性能測試方案
   ​
   爲了驗證以上方案的總體效果，咱們從穩定性、性能不一樣角度進行了驗證，這裏着重介紹性能測試方案，訓練的模型都是基於 mmaction 的視頻理解模型，採用的是 rawframes_train 方式，是擁有 400w 圖片的訓練數據集實驗，數據是從真實業務場景中提取的 40w 視頻中抽幀獲得，每一個場景下抽 10 幀圖片，因爲視頻清晰度各異，每張圖片大小由幾 KB 到十幾 M 各異，總計大小 780G 左右，每一個緩存節點提供 300G 的緩存空間；同時根據經驗通常在 50epoch 左右會實現模型收斂。
   ​
   而當咱們把測試的視頻數據量調整到 100w，總共的數據大小 2T，因爲數據量大和延時長，HDFS 接口的方式徹底不能工做；而經過 Fluid+JindoRuntime 則能夠知足業務的須要。
   ​
   測試的流程是會經過 Fluid JindoRuntime 進行數據預熱，以後進行模型訓練。
   ​
5. 性能測試結果
   ​
   結合 Fluid+JindoRuntime 方案，在數據預熱的前提下，咱們取得了很是明顯的訓練速度提高，從下圖能夠看到：在 3 機 12 卡的場景下，咱們發現基於 HDFS 接口讀取數據的實驗每每會由於網絡通訊等問題中斷，致使實驗不能跑完，增長異常處理後，workers 之間的等待時間加長，致使增長卡數並不能增長訓練速度，反而會拖慢。能夠觀察到 1 機 8 卡和 3 機 12 卡的場景整體訓練速度基本持平，計算資源的擴容。而經過新的方案，咱們發現相比於 HDFS 接口，1 機 4 卡能夠獲得 5 倍的加速，2 機 8 卡能夠獲得 9 倍的加速，3 機 12 卡能夠獲得 18 倍的加速。

因爲訓練的速度和穩定性獲得了保障，端到端的模型訓練時間也獲得了顯著的提高，訓練總時長由原來的 389 小時（16 天）縮短到了 16 小時。

總結：從兩週到 16 小時的訓練速度躍升
​
集成了 Fluid+JindoRuntime 後，顯著提高了小文件場景模型訓練的性能和穩定性，在多機多卡分佈式訓練的狀況下，能夠將模型訓練的速度提高 18 倍；將過去須要兩週才能完成的訓練縮減到了 16 個小時。更短的訓練時間和更小的 HDFS 壓力，也提高了訓練任務的穩定性，將訓練的成功率從 37.1% 提高到了 98.3%。目前咱們在生產環境的數據量是 4TB，同時隨着不斷迭代數據量還在持續增加。

微博 AI 訓練場景對於數據讀取有很高的性能要求，並且海量的小文件對於訪問延時也很是敏感，經過 JindoRuntime 的緩存能力能夠有效地對大數據存儲系統上的數據進行緩存加速，提供穩定可靠的高吞吐、低延時的數據訪問性能，同時也能夠有效地緩解對後端存儲系統的的壓力，保證後端存儲的穩定性。結合自身的具體場景，優化小文件讀取和緩存，不只能夠緩解 HDFS 集羣的 IO 壓力，也大大提升訓練效率。

展望
​
目前 Fluid+JindoRuntime 更像是殺手鐗，用來加速小文件場景，而很是規性武器對於全部數據集進行加速優化，咱們指望可以把彈性的數據加速做爲微博深度學習平臺的差別化能力，提高總體訓練任務速度和計算資源的利用率；另外一方面也幫助社區不斷演進，幫助到更多的開發者。具體來講：
​

支持定時任務支持動態擴縮容
數據預熱性能的提高和元數據備份機制的提供，實現快速重建數據集的能力
提供性能監控控制檯
支持 Runtime 元數據的高可用和鏡像升級
支持規模化 K8s 集羣中多數據集的全生命週期管理
致謝
​
感謝阿里雲 JindoFS 團隊的辰山、揚禮和容器團隊的車漾在整個方案設計和優化過程當中的巨大幫助，在幾乎沒有任何應用改造前提下，將數據加速能力賦予了現有應用；同時對於測試和生產環境中的需求和問題也及時專業的提供了支持。
​
相關連接

更多 Fluid 和 JindoFS 相關介紹請參考如下連接：

[1] Fluid：https://github.com/fluid-clou...
[2] JindoFS：https://github.com/aliyun/ali...

👇👇 戳下方連接，直達項目 GitHub 地址！

https://github.com/fluid-clou...