簡介： 深度學習平臺在微博社交業(yè)務(wù)扮演著重要的角色。計算存儲分離架構(gòu)下，微博深度學習平臺在數(shù)據(jù)訪問與調(diào)度方面存在性能低效的問題。本文將介紹微博內(nèi)部設(shè)計實現(xiàn)的一套全新的基于 Fluid（內(nèi)含 JindoRuntime）的新架構(gòu)方案，顯著提升了海量小文件場景模型訓練的性能和穩(wěn)定性，多機多卡分布式訓練場景可將模型訓練的速度提升 18 倍。

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

導讀：深度學習平臺在微博社交業(yè)務(wù)扮演著重要的角色。計算存儲分離架構(gòu)下，微博深度學習平臺在數(shù)據(jù)訪問與調(diào)度方面存在性能低效的問題。本文將介紹微博內(nèi)部設(shè)計實現(xiàn)的一套全新的基于 Fluid（內(nèi)含 JindoRuntime）的新架構(gòu)方案，顯著提升了海量小文件場景模型訓練的性能和穩(wěn)定性，多機多卡分布式訓練場景可將模型訓練的速度提升 18 倍。

背景?
?
新浪微博是中國最大的社交媒體平臺，每天上億條內(nèi)容產(chǎn)生并在萬億級關(guān)系的社交網(wǎng)絡(luò)上進行傳播。下圖是微博的業(yè)務(wù)生態(tài)圖，通過優(yōu)質(zhì)用戶生產(chǎn)、傳播優(yōu)質(zhì)內(nèi)容，普通用戶消費這些內(nèi)容，進而關(guān)注自己喜歡的博主，建立聯(lián)系，形成閉環(huán)生態(tài)。

微博機器學習平臺的主要作用是讓整個過程流轉(zhuǎn)得更高效流暢：通過理解優(yōu)質(zhì)內(nèi)容，構(gòu)建用戶畫像，把用戶感興趣的優(yōu)質(zhì)內(nèi)容推給用戶，讓他們和內(nèi)容生產(chǎn)者互動，進而刺激生產(chǎn)者生產(chǎn)更多更好的內(nèi)容, 實現(xiàn)信息消費者和信息生產(chǎn)者的雙贏。而隨著多媒體內(nèi)容變成主流，深度學習技術(shù)就變得更為重要。從多媒體的內(nèi)容理解，到 CTR 任務(wù)的優(yōu)化，都離不開深度學習技術(shù)的支持。
?

大規(guī)模深度學習模型訓練挑戰(zhàn)
?
隨著深度學習在微博業(yè)務(wù)場景中的廣泛使用，微博深度學習平臺扮演了非常核心的角色。該平臺采用了存儲與計算分離的架構(gòu)，使得計算資源得以與存儲資源解耦，從而實現(xiàn)了靈活的資源配比以及便捷的存儲擴展，并且降低了存儲成本。

然而，這種架構(gòu)也帶來了一些挑戰(zhàn)，其中比較關(guān)鍵的問題體現(xiàn)在數(shù)據(jù)訪問性能和穩(wěn)定性方面：
?

計算存儲分離架構(gòu)導致數(shù)據(jù)訪問高延時，導致訓練慢：業(yè)務(wù)團隊使用的深度學習任務(wù)（圖像或語音模型）會訪問海量小文件。實驗表明，HDFS 讀取海量小文件場景與本地讀取對比性能相差近十倍甚至百倍。
Kubernetes 調(diào)度器數(shù)據(jù)緩存無感知，同一數(shù)據(jù)源多次運行訪問依舊慢：相同模型、不同超參的；微調(diào)模型、相同輸入的；AutoML 等深度學習任務(wù)運行會不斷重復訪問同一數(shù)據(jù)，產(chǎn)生可以復用的數(shù)據(jù)緩存。但是由于原生的 Kubernetes 調(diào)度器無法感知緩存，導致應(yīng)用調(diào)度的結(jié)果不佳，緩存無法重用，性能得不到提升。
多數(shù)深度學習框架并不支持 HDFS 接口，導致開發(fā)難：比如 PyTorch，MxNet 等框架只支持 POSIX 協(xié)議接口，HDFS 接口需要額外的對接開發(fā)。因此需要同時支持模型開發(fā)階段的 POSIX 接口以及模型訓練階段的 HDFS 接口，引入模型代碼適配不同存儲的復雜性。
HDFS 成為數(shù)據(jù)并發(fā)訪問的瓶頸點，穩(wěn)定性挑戰(zhàn)大：微博機器學習平臺上百臺 GPU 機器同時訓練都會并發(fā)訪問 HDFS 集群，同時深度學習訓練的 IO 壓力比較大，HDFS 服務(wù)成為了性能單點，這對 HDFS 的性能和穩(wěn)定性提出了巨大的挑戰(zhàn)。一旦某個任務(wù)拖慢了 HDFS 系統(tǒng)，其他的訓練任務(wù)也會受到影響。而且，一旦 HDFS 無法工作，整個訓練集群也會受到影響。
通過對微博深度學習平臺的監(jiān)控分析，我們發(fā)現(xiàn)：一方面由于 IO 性能問題導致 GPU 等昂貴計算資源不能被充分利用；另一方面，我們也發(fā)現(xiàn)集群中的內(nèi)存和本地硬盤的水位很低，余量較多并且穩(wěn)定，這是由于多數(shù)的深度學習任務(wù)并不使用本地磁盤，同時內(nèi)存使用率也不高。因此我們考慮如果能夠充分利用集群自身的內(nèi)存和磁盤資源加速數(shù)據(jù)訪問會是一種更好的方案。

Fluid + JindoRuntime：為微博深度學習平臺提供高效支撐
?
為了能更好滿足大規(guī)模深度學習模型訓練的計算需求，需要取得更好的數(shù)據(jù)本地性效果。因此，我們希望達到以下目標：

計算能夠充分利用本地化訪問數(shù)據(jù)，這樣數(shù)據(jù)就不需通過網(wǎng)絡(luò)反復讀取，加速深度學習模型訓練的速度和提升集群的 GPU 使用率。
降低 HDFS 負載壓力，通過應(yīng)用對于部分數(shù)據(jù)的本地讀取，減小數(shù)據(jù)訪問延時和提升 HDFS 的可用性。
充分發(fā)揮熱點數(shù)據(jù)集的緩存節(jié)點優(yōu)勢，在對用戶無感知的前提下，智能的將任務(wù)調(diào)度到數(shù)據(jù)緩存節(jié)點上。讓常用的模型訓練程序越來越快。
通過 POSIX 接口讀取數(shù)據(jù)，這樣無需在模型開發(fā)和訓練階段使用不同的數(shù)據(jù)訪問接口，降低開發(fā)深度學習模型程序的成本。
為了達到上述目標，我們迫切希望找到 Kubernetes 上具有分布式緩存加速能力的軟件。很幸運，我們發(fā)現(xiàn) CNCF Sandbox 項目 Fluid 正好可以滿足我們的訴求。于是，我們設(shè)計了基于 Fluid 的新架構(gòu)方案，經(jīng)過驗證比較，我們選擇 JindoRuntime 作為加速運行時。
?

架構(gòu)組件介紹
?

1）Fluid
?

Fluid[1] 是一個運行在 Kubernetes 上可擴展的分布式數(shù)據(jù)編排和加速系統(tǒng)，它通過數(shù)據(jù)的編排和使用數(shù)據(jù)的應(yīng)用調(diào)度，解決云原生編排框架運行此類應(yīng)用面臨數(shù)據(jù)訪問延時高、多數(shù)據(jù)源聯(lián)合分析難、應(yīng)用使用數(shù)據(jù)過程復雜等痛點。
?

2）JindoRuntime
?

JindoRuntimed[2] 是 Fluid 一種分布式緩存 Runtime 的實現(xiàn)，基于 JindoFS 分布式緩存加速引擎。JindoFS 是阿里云 EMR 團隊自研大數(shù)據(jù)存儲優(yōu)化引擎，完全兼容 Hadoop 文件系統(tǒng)接口，給客戶帶來更加靈活、高效的計算存儲方案。JindoRuntime 使用 JindoFS 的 Cache 模式進行遠端文件的訪問和緩存，支持 OSS、HDFS、標準 S3 協(xié)議等多種存儲產(chǎn)品的訪問和緩存加速。在 Fluid 上使用和部署 JindoRuntime 流程簡單、兼容原生 K8s 環(huán)境、可以開箱即用。深度結(jié)合對象存儲特性，使用 Navite 框架優(yōu)化性能，并支持免密、checksum 校驗等云上數(shù)據(jù)安全功能。
?

使用基于 JindoRuntime 的 Fluid 的原因
?

Fluid 可以將數(shù)據(jù)集編排在 Kubernetes 集群中，實現(xiàn)數(shù)據(jù)和計算的同置，并且提供基于 Persistent Volume Claim 接口，實現(xiàn) Kubernetes 上應(yīng)用的無縫對接。同時 JindoRuntime 提供對 HDFS 上數(shù)據(jù)的訪問和緩存加速能力，并且可以利用 FUSE 的 POSIX 文件系統(tǒng)接口實現(xiàn)可以像本地磁盤一樣輕松使用 HDFS 上的海量文件，pytorch 等深度學習訓練工具可利用 POSIX 文件接口讀取訓練數(shù)據(jù)。
針對海量小文件的遠程數(shù)據(jù)訪問性能問題，JindoRuntime 對小文件的數(shù)據(jù)組織管理和訪問性能進行了大量針對性的優(yōu)化，能夠提供高效的小文件訪問性能，遠高于直接對 HDFS 的數(shù)據(jù)訪問性能。
提供元數(shù)據(jù)和數(shù)據(jù)分布式分層緩存，以及高效小文件檢索。
提供數(shù)據(jù)預熱機制，避免在訓練時刻拉取數(shù)據(jù)造成的數(shù)據(jù)訪問競爭。
Slab allocation 方式組織文件數(shù)據(jù)，高效利用緩存空間。
通過 Fluid 的數(shù)據(jù)感知調(diào)度能力，用戶無需知道緩存節(jié)點信息就可以將任務(wù)放置到有緩存數(shù)據(jù)的節(jié)點，實現(xiàn)數(shù)據(jù)訪問性能的優(yōu)勢最大化。
對于大文件和小文件提供不同的緩存策略和存儲方式，對于小文件 AI 訓練場景具有很好的自適應(yīng)性，無需用戶配置。
3. 落地實踐
?

選擇合適的緩存節(jié)點：使用 JindoRuntime 可以獲得更好的數(shù)據(jù)本地性能，在實際生產(chǎn)中我們也發(fā)現(xiàn)不是所有的節(jié)點都來做緩存性能就比較好。原因是有些節(jié)點的磁盤和網(wǎng)絡(luò) IO 性能不是很好，這個時候需要我們能夠把緩存節(jié)點盡量選擇一些大容量磁盤和網(wǎng)絡(luò)較好的節(jié)點上去。Fluid 支持 dataset 的可調(diào)度性，換言之就是緩存節(jié)點的可調(diào)度性，我們通過指定 dataset 的 nodeAffinity 來進行數(shù)據(jù)集緩存節(jié)點的調(diào)度，從而保證緩存節(jié)點可高效的提供緩存服務(wù)。
指定 Master 調(diào)度策略：JindoRuntime 由 master/worker/fuse 三部分組成，master 負責集群的大腦，負責元數(shù)據(jù)和集群緩存的管理，所以 master 節(jié)點得具有很強的可靠性和故障恢復速度。在生產(chǎn)過程中我們發(fā)現(xiàn)在不使用多 master 的條件下，單個 master 也具有很強的穩(wěn)定性和故障恢復速度，影響 master 節(jié)點穩(wěn)定性的重要因素還是宿主機的穩(wěn)定性，比如宿主機滿磁盤、通信故障等，基于此我們對 mater 節(jié)點使用 nodeselector 來選擇性能較好的宿主機作為 master 容器的環(huán)境，進一步保證 master 環(huán)境的穩(wěn)定性。
定時數(shù)據(jù)預熱：在進行訓練前的一個重要的步驟是進行元數(shù)據(jù)和數(shù)據(jù)的預熱，Fluid 提供了 CRD 的形式進行元數(shù)據(jù)和數(shù)據(jù)的緩存，在訓練前將訓練文件的元數(shù)據(jù)和數(shù)據(jù)緩存到本地，可大大加速訓練速度。但是存儲在 HDFS 上的訓練文件是每天一次更新，于是需要進行周期性定時的進行數(shù)據(jù)預熱流程，基于 dataload 的 CRD，我們使用 cronJob 的形式進行周期性調(diào)度，使得在每次訓練前都能夠完成元數(shù)據(jù)和數(shù)據(jù)的準備，從而進行高效訓練。當然 JindoRuntime 本身也支持增量同步的功能，所以每次只需要更新變化的文件即可，也大大加快了數(shù)據(jù)預熱的速度。
4. 性能測試方案
?
為了驗證以上方案的整體效果，我們從穩(wěn)定性、性能不同角度進行了驗證，這里著重介紹性能測試方案，訓練的模型都是基于 mmaction 的視頻理解模型，采用的是 rawframes_train 方式，是擁有 400w 圖片的訓練數(shù)據(jù)集實驗，數(shù)據(jù)是從真實業(yè)務(wù)場景中提取的 40w 視頻中抽幀得到，每個場景下抽 10 幀圖片，由于視頻清晰度各異，每張圖片大小由幾 KB 到十幾 M 各異，總計大小 780G 左右，每個緩存節(jié)點提供 300G 的緩存空間；同時根據(jù)經(jīng)驗一般在 50epoch 左右會實現(xiàn)模型收斂。
?
而當我們把測試的視頻數(shù)據(jù)量調(diào)整到 100w，總共的數(shù)據(jù)大小 2T，由于數(shù)據(jù)量大和延時長，HDFS 接口的方式完全不能工作；而通過 Fluid+JindoRuntime 則可以滿足業(yè)務(wù)的需要。
?
測試的流程是會通過 Fluid JindoRuntime 進行數(shù)據(jù)預熱，之后進行模型訓練。
?

性能測試結(jié)果
?
結(jié)合 Fluid+JindoRuntime 方案，在數(shù)據(jù)預熱的前提下，我們?nèi)〉昧朔浅Ｃ黠@的訓練速度提升，從下圖可以看到：在 3 機 12 卡的場景下，我們發(fā)現(xiàn)基于 HDFS 接口讀取數(shù)據(jù)的實驗往往會因為網(wǎng)絡(luò)通信等問題中斷，導致實驗不能跑完，增加異常處理后，workers 之間的等待時間加長，導致增加卡數(shù)并不能增加訓練速度，反而會拖慢。可以觀察到 1 機 8 卡和 3 機 12 卡的場景總體訓練速度基本持平，計算資源的擴容。而通過新的方案，我們發(fā)現(xiàn)相比于 HDFS 接口，1 機 4 卡可以得到 5 倍的加速，2 機 8 卡可以得到 9 倍的加速，3 機 12 卡可以得到 18 倍的加速。

由于訓練的速度和穩(wěn)定性得到了保障，端到端的模型訓練時間也得到了顯著的提升，訓練總時長由原來的 389 小時（16 天）縮短到了 16 小時。

總結(jié)：從兩周到 16 小時的訓練速度躍升
?
集成了 Fluid+JindoRuntime 后，顯著提升了小文件場景模型訓練的性能和穩(wěn)定性，在多機多卡分布式訓練的情況下，可以將模型訓練的速度提升 18 倍；將過去需要兩周才能完成的訓練縮減到了 16 個小時。更短的訓練時間和更小的 HDFS 壓力，也提升了訓練任務(wù)的穩(wěn)定性，將訓練的成功率從 37.1% 提升到了 98.3%。目前我們在生產(chǎn)環(huán)境的數(shù)據(jù)量是 4TB，同時隨著不斷迭代數(shù)據(jù)量還在持續(xù)增長。

微博 AI 訓練場景對于數(shù)據(jù)讀取有很高的性能要求，而且海量的小文件對于訪問延時也非常敏感，通過 JindoRuntime 的緩存能力可以有效地對大數(shù)據(jù)存儲系統(tǒng)上的數(shù)據(jù)進行緩存加速，提供穩(wěn)定可靠的高吞吐、低延時的數(shù)據(jù)訪問性能，同時也可以有效地緩解對后端存儲系統(tǒng)的的壓力，保證后端存儲的穩(wěn)定性。結(jié)合自身的具體場景，優(yōu)化小文件讀取和緩存，不僅可以緩解 HDFS 集群的 IO 壓力，也大大提高訓練效率。

展望
?
目前 Fluid+JindoRuntime 更像是殺手锏，用來加速小文件場景，而非常規(guī)性武器對于所有數(shù)據(jù)集進行加速優(yōu)化，我們期望能夠把彈性的數(shù)據(jù)加速作為微博深度學習平臺的差異化能力，提升整體訓練任務(wù)速度和計算資源的利用率；另一方面也幫助社區(qū)不斷演進，幫助到更多的開發(fā)者。具體來說：
?

支持定時任務(wù)支持動態(tài)擴縮容
數(shù)據(jù)預熱性能的提升和元數(shù)據(jù)備份機制的提供，實現(xiàn)快速重建數(shù)據(jù)集的能力
提供性能監(jiān)控控制臺
支持 Runtime 元數(shù)據(jù)的高可用和鏡像升級
支持規(guī)模化 K8s 集群中多數(shù)據(jù)集的全生命周期管理
致謝
?
感謝阿里云 JindoFS 團隊的辰山、揚禮和容器團隊的車漾在整個方案設(shè)計和優(yōu)化過程中的巨大幫助，在幾乎沒有任何應(yīng)用改造前提下，將數(shù)據(jù)加速能力賦予了現(xiàn)有應(yīng)用；同時對于測試和生產(chǎn)環(huán)境中的需求和問題也及時專業(yè)的提供了支持。
?
相關(guān)鏈接

更多 Fluid 和 JindoFS 相關(guān)介紹請參考以下鏈接：

[1] Fluid：https://github.com/fluid-cloudnative/fluid
[2] JindoFS：https://github.com/aliyun/alibabacloud-jindofs

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。