![](http://img.blog.itpub.net/blog/2021/06/05/0f76d5c2c432360d.png?x-oss-process=style/bb)

作者 ｜
吳彤  微博深度學習平臺工程師
郝麗  微博深度學習平臺工程師
 
導讀：深度學習平臺在微博社交業務扮演著重要的角色。計算儲存分離架構下，微博深度學習平臺在資料訪問與排程方面存在效能低效的問題。本文將介紹微博內部設計實現的一套全新的基於 Fluid（內含 JindoRuntime）的新架構方案，顯著提升了海量小檔案場景模型訓練的效能和穩定性，多機多卡分散式訓練場景可將模型訓練的速度提升 18 倍。

# 背景

新浪微博是中國最大的社交媒體平臺，每天上億條內容產生並在萬億級關係的社交網路上進行傳播。下圖是微博的業務生態圖，透過優質使用者生產、傳播優質內容，普通使用者消費這些內容，進而關注自己喜歡的博主，建立聯絡，形成閉環生態。

![](http://img.blog.itpub.net/blog/2021/06/05/9317f1c9bf9f08db.png?x-oss-process=style/bb)

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

# 大規模深度學習模型訓練挑戰

隨著深度學習在微博業務場景中的廣泛使用，微博深度學習平臺扮演了非常核心的角色。該平臺採用了儲存與計算分離的架構，使得計算資源得以與儲存資源解耦，從而實現了靈活的資源配比以及便捷的儲存擴充套件，並且降低了儲存成本。

![](http://img.blog.itpub.net/blog/2021/06/05/e7a38503ed5448a9.png?x-oss-process=style/bb)

然而，這種架構也帶來了一些挑戰，其中比較關鍵的問題體現在資料訪問效能和穩定性方面：

1. **計算儲存分離架構導致資料訪問高延時，導致訓練慢**：業務團隊使用的深度學習任務（影像或語音模型）會訪問海量小檔案。實驗表明，HDFS 讀取海量小檔案場景與本地讀取對比效能相差近十倍甚至百倍。

1. **Kubernetes 排程器資料快取無感知，同一資料來源多次執行訪問依舊慢**：相同模型、不同超參的；微調模型、相同輸入的；AutoML 等深度學習任務執行會不斷重複訪問同一資料，產生可以複用的資料快取。但是由於原生的 Kubernetes 排程器無法感知快取，導致應用排程的結果不佳，快取無法重用，效能得不到提升。

1. **多數深度學習框架並不支援 HDFS 介面，導致開發難**：比如 PyTorch，MxNet 等框架只支援 POSIX 協議介面，HDFS 介面需要額外的對接開發。因此需要同時支援模型開發階段的 POSIX 介面以及模型訓練階段的 HDFS 介面，引入模型程式碼適配不同儲存的複雜性。

1. **HDFS 成為資料併發訪問的瓶頸點，穩定性挑戰大**：微博機器學習平臺上百臺 GPU 機器同時訓練都會併發訪問 HDFS 叢集，同時深度學習訓練的 IO 壓力比較大，HDFS 服務成為了效能單點，這對 HDFS 的效能和穩定性提出了巨大的挑戰。一旦某個任務拖慢了 HDFS 系統，其他的訓練任務也會受到影響。而且，一旦 HDFS 無法工作，整個訓練叢集也會受到影響。

透過對微博深度學習平臺的監控分析，我們發現：一方面由於 IO 效能問題導致 GPU 等昂貴計算資源不能被充分利用；另一方面，我們也發現叢集中的記憶體和本地硬碟的水位很低，餘量較多並且穩定，這是由於多數的深度學習任務並不使用本地磁碟，同時記憶體使用率也不高。因此我們考慮如果能夠充分利用叢集自身的記憶體和磁碟資源加速資料訪問會是一種更好的方案。

# Fluid + JindoRuntime：為微博深度學習平臺提供高效支撐

為了能更好滿足大規模深度學習模型訓練的計算需求，需要取得更好的資料本地性效果。因此，我們希望達到以下目標：

1. 計算能夠充分利用本地化訪問資料，這樣資料就不需透過網路反覆讀取，加速深度學習模型訓練的速度和提升叢集的 GPU 使用率。

1. 降低 HDFS 負載壓力，透過應用對於部分資料的本地讀取，減小資料訪問延時和提升 HDFS 的可用性。

1. 充分發揮熱點資料集的快取節點優勢，在對使用者無感知的前提下，智慧的將任務排程到資料快取節點上。讓常用的模型訓練程式越來越快。

1. 透過 POSIX 介面讀取資料，這樣無需在模型開發和訓練階段使用不同的資料訪問介面，降低開發深度學習模型程式的成本。

為了達到上述目標，我們迫切希望找到 Kubernetes 上具有分散式快取加速能力的軟體。很幸運，我們發現 CNCF Sandbox 專案 Fluid 正好可以滿足我們的訴求。於是，我們設計了基於 Fluid 的新架構方案，經過驗證比較，我們選擇 JindoRuntime 作為加速執行時。

![](http://img.blog.itpub.net/blog/2021/06/05/ef9ae9b2e0559602.png?x-oss-process=style/bb)

## 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 的原因

1. Fluid 可以將資料集編排在 Kubernetes 叢集中，實現資料和計算的同置，並且提供基於 Persistent Volume Claim 介面，實現 Kubernetes 上應用的無縫對接。同時 JindoRuntime 提供對 HDFS 上資料的訪問和快取加速能力，並且可以利用 FUSE 的 POSIX 檔案系統介面實現可以像本地磁碟一樣輕鬆使用 HDFS 上的海量檔案，pytorch 等深度學習訓練工具可利用 POSIX 檔案介面讀取訓練資料。

1. 針對海量小檔案的遠端資料訪問效能問題，JindoRuntime 對小檔案的資料組織管理和訪問效能進行了大量針對性的最佳化，能夠提供高效的小檔案訪問效能，遠高於直接對 HDFS 的資料訪問效能。

1. 提供後設資料和資料分散式分層快取，以及高效小檔案檢索。

1. 提供資料預熱機制，避免在訓練時刻拉取資料造成的資料訪問競爭。

1. Slab allocation 方式組織檔案資料，高效利用快取空間。

1. 透過 Fluid 的資料感知排程能力，使用者無需知道快取節點資訊就可以將任務放置到有快取資料的節點，實現資料訪問效能的優勢最大化。

1. 對於大檔案和小檔案提供不同的快取策略和儲存方式，對於小檔案 AI 訓練場景具有很好的自適應性，無需使用者配置。

## 3. 落地實踐

1. **選擇合適的快取節點**：使用 JindoRuntime 可以獲得更好的資料本地效能，在實際生產中我們也發現不是所有的節點都來做快取效能就比較好。原因是有些節點的磁碟和網路 IO 效能不是很好，這個時候需要我們能夠把快取節點儘量選擇一些大容量磁碟和網路較好的節點上去。Fluid 支援 dataset 的可排程性，換言之就是快取節點的可排程性，我們透過指定 dataset 的 nodeAffinity 來進行資料集快取節點的排程，從而保證快取節點可高效的提供快取服務。

1. **指定 Master 排程策略**：JindoRuntime 由 master/worker/fuse 三部分組成，master 負責叢集的大腦，負責後設資料和叢集快取的管理，所以 master 節點得具有很強的可靠性和故障恢復速度。在生產過程中我們發現在不使用多 master 的條件下，單個 master 也具有很強的穩定性和故障恢復速度，影響 master 節點穩定性的重要因素還是宿主機的穩定性，比如宿主機滿磁碟、通訊故障等，基於此我們對 mater 節點使用 nodeselector 來選擇效能較好的宿主機作為 master 容器的環境，進一步保證 master 環境的穩定性。

1. **定時資料預熱**：在進行訓練前的一個重要的步驟是進行後設資料和資料的預熱，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 倍的加速。

![](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21156609/1622775429479-38121367-126b-4599-8279-5ad990d092bc.png#clientId=u6a9db2eb-43fd-4&from=paste&height=304&id=ua7e70b78&margin=%5Bobject%20Object%5D&originHeight=607&originWidth=1080&originalType=url&status=done&style=none&taskId=u55f331bf-10d3-4e61-a6e0-88cf7c35d93&width=540)

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

![](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21156609/1622775429446-973d92d5-fc85-491a-b979-36cb3a1135ae.png#clientId=u6a9db2eb-43fd-4&from=paste&height=296&id=u23960994&margin=%5Bobject%20Object%5D&originHeight=591&originWidth=1080&originalType=url&status=done&style=none&taskId=u52e3e915-c316-481d-b220-e71f5294661&width=540)

# 總結：從兩週到 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_](https://github.com/fluid-cloudnative/fluid)

- [2] JindoFS：[_https://github.com/aliyun/alibabacloud-jindofs_](https://github.com/aliyun/alibabacloud-jindofs)

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

相關文章