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 模型加速。研究領域包括高性能計算、分布式文件存儲、分布式緩存等。有多年的云原生開源社區經驗。

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

總結

以上是生活随笔為你收集整理的云知声 Atlas 超算平台: 基于 Fluid + Alluxio 的计算加速实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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