Fluid 是雲原生基金會 CNCF 下的雲原生資料編排和加速專案，由南京大學、阿里雲及 Alluxio 社群聯合發起並開源。本文主要介紹雲知聲 Atlas 超算平臺基於 Fluid + Alluxio 的計算加速實踐，以及 Fluid 是如何為 Atlas 帶來全新的資料集管理方式的。

# Atlas平臺介紹

雲知聲是一家專注物聯網人工智慧服務公司。雲知聲的 AI 技術棧涵蓋了訊號、語音、影像、文字的感知和表達能力，知識、理解、分析、決策等認知技術，並朝著多模態人工智慧系統方向發展。雲知聲 Atlas 超算平臺作為底層基礎架構，支援著公司在 AI 各個領域的模型訓練與推理服務的開展。雲知聲很早就開始佈局建設業界領先的 GPU/CPU 異構 Atlas 計算平臺和分散式檔案儲存系統，該計算叢集可為 AI 計算提供高效能運算和海量資料的儲存訪問能力。

雲知聲團隊基於 Kubernetes 開源架構之上，進行了相應的核心功能研發，成功構建了浮點處理能力超過10 PFLOPS（一億億次／秒）的 AI 超級計算服務平臺。該平臺支援主流機器學習架構，開發者能夠實現語音、語言、大資料、多模態等核心技術的高效研發。平臺也開放了相應的算力與儲存，為中小微企業和院校機構提供定製化計算服務。

# 問題與挑戰

Atlas 計算平臺採用是計算與儲存分離的架構，目前整個平臺的儲存伺服器、計算伺服器之間以及計算與儲存伺服器之間的底層網路架構是由 100GB 的 InfiniBand 進行互聯。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/34c6fe37b4d94724b3d7218fe75214c0~tplv-k3u1fbpfcp-zoom-1.image)

計算平臺的模型訓練資料儲存系統由多套 PB 量級的高效能分散式檔案系統 Lustre 組成。Lustre 分散式檔案系統相容 POSIX 介面，多種深度學習框架能夠直接進行資料讀取。計算與儲存分離的架構使計算跟儲存能夠獨立進行擴容，整體架構較為靈活。但是之前平臺也遇到了資料訪問效率低與底層儲存頻寬瓶頸等問題：

### 儲存寬頻瓶頸

在儲存資源相對固定的情況下，隨著平臺使用者的增加，其頻寬、後設資料負載以及伺服器的負載都呈現出來較大的上升。叢集存在多個單機任務執行在同一個 GPU 節點，造成 IO 資源的競爭，由於 IO 的競爭導致了整個訓練週期拉長了，大大降低了研發影響效率。

### 海量小檔案

第二個問題是模型訓練資料集本身的特點問題。在降噪場景中有使用者的任務存在接近  TB 量級的小檔案，導致底層分散式檔案系統的的後設資料服務壓力很大。大量的小檔案使得程式本身讀資料的效率較低，資料讀取緩慢造成 GPU 大部分時間在等資料，整體 GPU 的整體利用率較低，延長了模型的訓練週期。

### 資料種類多

由於平臺支援的業務型別較廣，使用者的資料型別較多，檔案大小型別也不同，很難透過調優一套儲存的引數來適配多種業務型別。結合使用者的業務型別分析，我們發現平臺資料主要還是用來做模型訓練佔的比重比較大，其餘部分主要進行模型的推理與 CPU 密集型資料生成任務。

### 資料冗餘

在平臺中存在資料集重疊的問題，同一個組內或者不同組有使用到相同的資料集，但是卻儲存了多份，造成了儲存空間的浪費。

# 早期解決方案

如何透過最小的預算與架構改動來應對儲存總頻寬的瓶頸以及減少後設資料伺服器的壓力，雲知聲 Atlas 也進行一系列的探索與研發。

### 寬頻限制

考慮到大量的併發讀取會造成儲存頻寬達到極限，造成儲存卡頓或者儲存系統癱瘓。平臺透過限制每個計算節點的客戶端頻寬以及每個使用者的 UID/GID 限制頻寬，但是該方法存在不夠靈活、沒辦法充分利用 GPU 的計算能力的問題，當有 2 個大 IO 的訓練任務分配到了同一個節點，由於節點的頻寬限制，2個訓練任務的 IO 都有上限，資料讀取的速度限制導致 GPU 沒辦法充分發揮並行讀取的優勢，透過監控發現該型別的 GPU 利用率在 40% 左右，嚴重浪費了硬體資源。

### 聚合大檔案

考慮到平臺的小檔案太多，會對後設資料造成較大的壓力，我們進行了相應的措施，首先透過檢測每個使用者的 inode 數量與儲存總量判斷使用者的小檔案數量，限制使用者小檔案的數量。第二是推行一系列資料聚合的工具，讓使用者將小檔案聚合成 lmdb、tfrecord 之類的大檔案格式。

### 任務排程器重構

為了避免任務都聚集在同一個節點上，我們透過定製任務排程器外掛，增加排程策略，判斷節點的計算資源的使用情況，優先將任務排程到空閒節點，避免多個任務跑在同一個節點造成的 IO 競爭，但是該方案在平臺的計算資源出現滿載的情況下還是不可避免。

### 多級快取

為了充分利用空閒的硬體以及減輕底層儲存系統的壓力，在最早期平臺研發了第一版本的快取方案作作為過渡。該方法能夠一定程度緩解儲存的壓力，但是其對於資料的管理還是不夠自動化,這隻能作為我們過渡到新架構的一個臨時替代解決的方案。

# 全新的架構

雲知聲在 2020 年開始調研 Alluxio並進行了一系列的測試，包括功能的適配與效能測試等，發現 Alluxio 能夠滿足目前雲知聲需求，能夠較為快速並且以較低的成本解決我們存在的幾個痛點：

- Alluxio Fuse 提供了 POSIX 檔案系統介面，使用者能夠無縫的使用分散式快取，程式無需做更改；
- Alluxio 支援對多種檔案系統的支援，包括分散式檔案系統、物件儲存等，當我們平臺後續引入新的儲存，Alluxio 快取都能很好的進行支援，保證我們整個快取架構的穩定性；
- Alluxio 提供較好的快取管理，Alluxio 的層次化儲存機制能夠充分利用記憶體、固態硬碟或者磁碟，降低具有彈性擴張特性的資料驅動型應用的成本開銷；
- 支援以 Kubernetes 或者容器的方式部署到平臺中，與現有的技術棧較為一致；
- Alluxio 提供了 HA 支援，保證了分散式快取系統的高可用性。

相比早前的計算與儲存分離的架構，Alluxio 在計算與儲存之間引入一層 Cache 層，將底層儲存的壓力轉移到各個計算節點的記憶體或者本地硬碟中，使用者的任務能享受本地儲存帶來的速度提升優勢，整個平臺能夠相容分散式檔案系統與本地硬碟兩者的優勢。

在使用 Alluxio 進行業務端整合時，我們遇到了許可權控制、以及資料掛載等問題。Fluid 提供了一種更加雲原生的方式來使用 Alluxio, 其提供了一種全新的資料集管理方式，快取資料集跟雲原生的資源一樣，能夠被 kubernetes 進行相應的分配與排程，有效的解決早期快取與 kubernetes 使用方式獨立的問題。

最終我們的架構是使用 Alluxio 作為 Fluid 的快取加速引擎，其負責做底層分散式檔案系統到計算節點本地快取介質的資料遷移以及快取的管理，為平臺的應用程式提供了資料加速的功能。而 Fluid 負責快取與應用的編排，基於 Fluid，平臺能夠感知快取，將之前需要很多人工的快取操作，轉移到平臺層智慧化處理。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d88c6289c18040db877bc7c051af2409~tplv-k3u1fbpfcp-zoom-1.image)

引入新架構後，我們在自研的模型訓練任務提交工具 atlasctl 將 fluid 功能進行整合，儘可能的為使用者遮蔽一些複雜的概念，使用者透過 atlasctl  cache create 並指定新增一些引數資訊例如快取的大小，快取介質等即可建立快取資料集。該工具的整合為使用者遮蔽了負載的快取機制資訊，讓他們更加關注與資料與業務本身。

# 業務適配

Fluid + Alluxio 為叢集引入了全新的架構，但是在具體場景適配的方面我們還是遇到了一些問題，這些問題我們第一時間與社群反饋，社群都第一時間解決了我們的需求，這裡主要講下幾個比較重要的特性支援：

### hostpath 與 nonroot 的支援

在 Atlas 平臺中，我們對分散式檔案系統設定了 nonroot,客戶端的 root 是沒有許可權操作使用者的目錄的。如果在 Alluxio 快取引擎使用 root 使用者訪問底層 UFS 會出現許可權問題，Fluid 還提供了 nonroot 支援，支援在快取引擎與資料集分別設定使用者的 UID  與 GID，快取引擎的使用者資訊保證 Allluxio 能夠成功讀取到底層 UFS 的資料，如果使用者在資料集設定相同的 UID 與 GID 就可以實現任務端資料的讀取，如果將資料集的 UID  與 GID 設定成別的使用者資訊，就可以實現資料集的共享，該特性很好的解決了平臺遇到的許可權控制相關的問題以及資料儲存冗餘的問題。

### 多個掛載點的支援

由於使用者的任務的資料通常是由不同的資料集組成，這裡的不同資料集可以是同一個儲存系統的不同目錄或者是不同儲存系統。Alluxio 能夠為應用程式提供統一名稱空間。透過統一名稱空間的抽象，應用程式可以透過統一名稱空間和介面來訪問多個獨立的儲存系統。相比於連線每個獨立的儲存系統進行通訊，應用程式可以只連線到 Alluxio ，透過 Alluxiofuse 讓使用者能夠使用 POXIS 介面訪問不同底層儲存的快取資料。

透明命名機制保證了Alluxio和底層儲存系統名稱空間身份一致性。不同的底層儲存的目錄與檔名都能夠在 Alluxio 進行對映。

基於該特性使用者的可以同時在同一個訓練任務中為 2 個儲存系統的資料進行快取加速。該特效能夠避免使用者進行大量的資料遷移工作，在 Atlas 平臺中，TB 量級的小檔案的壓縮打包、遷移與解壓需要耗費幾個小時，運用該特性使用者只需要更改下任務中資料的儲存路徑無需修改原始碼，即可執行程式。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/da92c9b0e6814c03a009d5ab8ffacc32~tplv-k3u1fbpfcp-zoom-1.image)

### 快取預熱

平臺中計算資源往往比儲存資源更緊缺，如果使用者啟動了 TB 量級的小檔案訓練任務，底層儲存系統與快取系統之間的後設資料同步以及資料的同步需要耗費大量時間。Alluxio 提供了 loadMetadata 與 loaddata 的功能，Fluid 將 2 個功能進行了整合，使用者能夠提前將遠端儲存系統中的資料拉取到靠近計算結點的分散式快取引擎中，使得消費該資料集的應用能夠在首次執行時即可享受到快取帶來的加速效果。該功能能夠有效的增加叢集的 GPU 利用率，避免在首次快取時進行後設資料同步的時候，造成的耗時，使得程式一開始執行就具有較好的 IO 讀取速度，整體的 GPU 利用率上升了。

### 引數調優

Alluxio 提供了較多的調優引數，平臺根據業務的特點進行相應的引數配置與調優，針對幾乎全是讀的場景，進行了一些通用引數的調優以及一些針對不同資料集的調優。

通用引數：

- 開啟 kernel_cache 以及將 alluxio.user.metadata.cache.enabled 設定為 true, 在客戶端開啟檔案及目錄後設資料快取。對於全讀的場景可以配置 alluxio.user.metadata.cache.max.size 和 alluxio.user.metadata.cache.expiration.time以調整最多快取檔案及目錄後設資料快取量和有效時間。
- 透過設定 alluxio.user.file.passive.cache.enabled=false 與 alluxio.user.file.readtype.default=CACHE 來避免頻繁逐出（Cache Eviction）造成快取抖動。

# 業務測試

我們將業務按照資料集的大小分成了 3 種，第一種是小檔案，單個檔案的大小在 1M 以下的。第二種是中大型資料資料量在幾百 G 左右的，第三種是 T 級別大檔案。

### 語音降噪場景

本次測試的模型是基於 Pytorch 框架搭建的 DLSE 模型，資料檔案數在 50 萬左右 ,資料總大小是 183 GB，採用記憶體作為 Alluxio 的快取介質。

本次實驗採用單機10卡的任務，基於 Pytorch 原生的 DDP 框架進行多卡的通訊，對比測試了直接從分散式檔案系統、從 Alluxio 快取讀取以及進行一輪預熱之後再從 Alluxio 的實驗。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/85ea7b11f7214b3897ad3873d708a844~tplv-k3u1fbpfcp-zoom-1.image)

透過第一輪的時間可以看出，進行了 warmup 的快取任務相比於直接從底層檔案系統讀取或者 Alluxio 的第一輪讀取速度有了接近 10 倍的提速。Alluxio 在第一輪訓練的時候由於資料需要做後設資料同步與快取資料，因此在第一輪資料讀取的時候快取的優勢還體現不出來。但是當第二輪讀取的時候，由於資料已經全部落入快取介質中，這時候考驗的就是 Alluxio 本身的快取命中率，透過上面的實驗結果也可以看出，增速非常明顯。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e1f5b1745ab648628514afe18d6491d7~tplv-k3u1fbpfcp-zoom-1.image)

資料讀取效率提升之後，整體 GPU 利用率也得到了提升，透過監控 GPU 的利用率發現採用 WarmUp 的 Alluxio 快取，GPU 的利用率基本穩定在 90%  左右，同時我們看到資料快取在記憶體中能夠有效的降低底層儲存的負載。

# 文字識別

本次實驗採用基於 CRNN 的文字識別模型，採用 Pytorch 的框架進行模型的構建，資料來源採用的是自採集的 125GB 的影像資料，影像資料轉換成了一個 lmdb 的大檔案，我們做了3 個對比測試，直接從底層檔案系統讀取、從沒有進行預熱的 Alluxio 讀取以及採用進行了預熱的 Alluxio 讀取。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1be4dcad5062417a9b9bc21549cb8849~tplv-k3u1fbpfcp-zoom-1.image)

我們發現採用預熱的 Alluxio 節點的 IO 頻寬流量相比於直接從底層分散式儲存讀取從 1300Mb/s 降為基本為0，對於我們的平臺收益是非常大的，在不增加底層儲存硬體的情況下，這是最快而且相對廉價的降低儲存系統頻寬使用的方法。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d0d48afb689c4b81b2ea6a5cec7d2a16~tplv-k3u1fbpfcp-zoom-1.image)

讀取快取相對於直接讀取底層儲存計算節點 GPU平均使用率由 69.59% 提升到 91.46%，表明消除 I/O 瓶頸可以提高大檔案訓練任務資源使用效率。

# 結論

透過引入 Fluid + Alluxio 的新架構，平臺取得了一系列的收益。

- 加速模型訓練：透過上述的測試結果我們看到對於任務的提速效果非常明顯，能夠直接利用本地儲存的速度優勢避免因為網路傳輸與資源競爭，從而有效的加速模型訓練過程中資料讀取的耗時。
- 降低底層儲存負載：新架構可以透過本地快取分擔底層儲存系統的頻寬與 IOPS 壓力，大幅度減少底層儲存系統的負載，有效的提高了底層儲存系統的可用性。
- 增加叢集 GPU 利用率：透過高效的  IO 讀取，消除使用者程式資料讀取的瓶頸， 避免了 GPU 空轉等待資料的現象，提高了 GPU 的利用率，從而提高了整個叢集 GPU 使用率。
- 避免同節點 IO 競爭：新架構充分解決了我們早期遇到的同節點 IO 資源競爭、儲存系統存在頻寬瓶頸以及模型的訓練效率不高的痛點。
- 更加高效的快取管理：採用新架構以一種更加雲原生的方式管理快取，工程師從之前單純將資料載記憶體到現在快取轉變成可以管理與監控的資源，Kubernetes 排程能夠感知快取，進行相應的策略分配，使得任務能夠更加高效的執行。

# 後續規劃

Fluid + Alluxio 為我們帶來了很大的收益，目前我們也跟社群緊密持續合作中，後續我們將在以下幾個方面繼續深入研究：

- 持續反饋測試結果與問題以及提供更豐富的使用場景給社群，不斷的迭代最佳化 Alluxio 的效能；
- 總結與測試更多的資料型別，提供引數調優實踐反饋給社群；
- 增加 fluid 快取智慧化排程功能。

戳原文，檢視 Fluid 開源專案 github 主頁！！

*本文作者：*

*呂鼕鼕：雲知聲超算平臺架構師， 負責大規模分散式機器學習平臺架構設計與功能研發，負責深度學習演算法應用的最佳化與 AI 模型加速。研究領域包括高效能運算、分散式檔案儲存、分散式快取等。有多年的雲原生開源社群經驗。*

*劉青松：雲知聲演算法研究員，負責機器學習平臺和應用演算法研發，研究領域包括雲原生架構研究、高效能運算、語音和視覺應用、機器學習演算法等。*

雲知聲 Atlas 超算平臺: 基於 Fluid + Alluxio 的計算加速實踐

相關文章