簡介： 深度學習平臺在微博社交業務扮演著重要的角色。計算存儲分離架構下，微博深度學習平臺在數據訪問與調度方面存在性能低效的問題。本文將介紹微博內部設計實現的一套全新的基于 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）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 校驗等云上數據安全功能。
?

使用基于 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 進行數據預熱，之后進行模型訓練。
?

性能測試結果
?
結合 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-cloudnative/fluid
[2] JindoFS：https://github.com/aliyun/alibabacloud-jindofs

下方鏈接，直達項目 GitHub 地址！
https://github.com/fluid-cloudnative/fluid

總結

以上是生活随笔為你收集整理的【云原生AI】Fluid + JindoFS 助力微博海量小文件模型训练速度提升 18 倍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。