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

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

Atlas平台介紹

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

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

問題與挑戰

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

計算平台的模型訓練資料存儲系統由多套 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，平台能夠感覺緩存，将之前需要很多人工的緩存操作，轉移到平台層智能化處理。

引入新架構後，我們在自研的模型訓練任務送出工具 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 量級的小檔案的壓縮打包、遷移與解壓需要耗費幾個小時，運用該特性使用者隻需要更改下任務中資料的存儲路徑無需修改源代碼，即可運作程式。

緩存預熱

平台中計算資源往往比存儲資源更緊缺，如果使用者啟動了 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 的實驗。

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

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

文字識别

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

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

讀取緩存相對于直接讀取底層存儲計算節點 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 模型加速。研究領域包括高性能計算、分布式檔案存儲、分布式緩存等。有多年的雲原生開源社群經驗。

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