一、背景

時間步入了2024年，新的技術趨勢，如大模型/AIGC/多模態(tài)等技術，已經(jīng)開始與實際業(yè)務相結合，并開始生產(chǎn)落地。這些新的技術趨勢不僅提高了算力的需求，也給底層基礎設施帶來了更大的挑戰(zhàn)。

在計算方面，以GPU和FPGA等異構硬件為例，他們通過短周期的迭代和演進來適應不斷變化的需求。阿里集團通過統(tǒng)一調(diào)度、統(tǒng)一資源池以及全面彈性等調(diào)度手段滿足了復雜的計算需求。

在存儲方面，經(jīng)典的微服務應用通過云原生化的方式，兼顧了性能和效率。但對于計算量增量最大的分布式AI訓練、大數(shù)據(jù)等計算密集型應用，data locality直接影響了計算作業(yè)的運行效率與吞吐，網(wǎng)絡I/O的消耗還間接拉高了帶寬成本，且在可預見的場景中，數(shù)據(jù)集規(guī)模的還會以較高的速率保持增長，如何通過合理的數(shù)據(jù)緩存親和性技術加速數(shù)據(jù)訪問，將是提升計算任務運行效率的同時降成本的關鍵。

大模型訓練/多媒體等場景的數(shù)據(jù)集以圖片和音頻文件為主，天然適合將數(shù)據(jù)托管在OSS對象存儲上，也是目前線上大多數(shù)計算作業(yè)的存儲選型，以訓練場景為例，具有以下讀數(shù)據(jù)的特征：1）數(shù)據(jù)集順序的隨機化處理造成傳統(tǒng)的單機緩存策略失效；2) 多個epoch會對數(shù)據(jù)集進行多輪讀??；3) 作業(yè)間可能復用同個數(shù)據(jù)集。

綜上，阿里巴巴集團內(nèi)部多個AI平臺業(yè)務面臨的現(xiàn)狀中，天然適合用分布式緩存/文件系統(tǒng)的形式進行I/O層面的加速。

二、面臨的挑戰(zhàn)

1. 計算存儲分離架構提升了數(shù)據(jù)訪問與計算水平擴展的靈活度，但導致了數(shù)據(jù)訪問高延時，對于訓練等對數(shù)據(jù)緩存親和性有顯著訴求的場景延遲不友好：業(yè)務團隊使用的機器學習任務在訓練過程中要實時頻繁訪問OSS上的數(shù)據(jù)（以樣本數(shù)據(jù)集與checkpoint為主），在OSS帶寬受限或者壓力較大時，訪問OSS上數(shù)據(jù)速度比訪問本地文件速度要慢1~2個數(shù)量級，且占據(jù)了用戶大量的帶寬成本；
2. Kubernetes調(diào)度器數(shù)據(jù)緩存無感知，同一數(shù)據(jù)源多次運行訪問依舊慢: 在現(xiàn)實應用中深度學習任務運行會不斷重復訪問同一數(shù)據(jù)，包括相同模型不同超參的任務、微調(diào)模型相同輸入的任務、以及AutoML任務等。這種深度學習任務的重復數(shù)據(jù)訪問就產(chǎn)生了可以復用的數(shù)據(jù)緩存。然而，由于原生Kubernetes調(diào)度器無法感知緩存，導致應用調(diào)度的結果不佳，緩存無法重用，性能難以提升；
3. OSS成為數(shù)據(jù)并發(fā)訪問的瓶頸點，穩(wěn)定性挑戰(zhàn)大: 大量機器學習任務在同時訓練時都會并發(fā)訪問后端OSS存儲。這種并發(fā)機器學習訓練造成的IO壓力比較大，OSS服務成為了性能單點，一旦OSS帶寬出現(xiàn)瓶頸則會影響所有機器學習任務；
4. 訓練文件分散，元數(shù)據(jù)壓力: 機器學習任務的訓練數(shù)據(jù)文件通常會分散在不同路徑下，讀取文件需要耗費大量的時間在list操作上。對象存儲的list操作性能較差，在進行大規(guī)模list時對OSS元數(shù)據(jù)壓力很大，經(jīng)常出現(xiàn)超時或者list失敗的情況；
5. IO穩(wěn)定性對業(yè)務運行有直接影響：導致業(yè)務表現(xiàn)不穩(wěn)定，甚至造成任務失敗。基于FUSE的存儲客戶端更容易發(fā)生這樣的問題，一旦這些問題無法自動修復，則可能中斷集群訓練任務。時刻保持IO的穩(wěn)定性是保證業(yè)務順利運行的關鍵途徑之一。

在現(xiàn)實應用中，通過對于以上典型數(shù)據(jù)訪問pattern的分析，我們發(fā)現(xiàn)IO性能問題會導致GPU等昂貴計算資源不能被充分利用。機器學習自身訓練的特點導致了數(shù)據(jù)文件訪問較分散，元數(shù)據(jù)壓力較大。如果能夠精細化地緩存元數(shù)據(jù)和文件數(shù)據(jù)，那么一方面可以提高緩存效率和磁盤利用率，另一方面也可以解決文件查找操作帶來的元數(shù)據(jù)損耗。

三、面向深度學習任務的高效緩存調(diào)度加速系統(tǒng)

3.1 架構組件介紹

Fluid

Fluid是一個開源可擴展的分布式數(shù)據(jù)編排和加速系統(tǒng)，以Kubernetes標準和對用戶透明的方式為AI和大數(shù)據(jù)等數(shù)據(jù)密集型應用提供數(shù)據(jù)訪問能力，其目標為構建云原生環(huán)境下數(shù)據(jù)密集型應用的高效支撐平臺。

Fluid通過 Kubernetes 服務提供的數(shù)據(jù)層抽象，可以讓數(shù)據(jù)像流體一樣在諸如 HDFS、OSS、Ceph 等存儲源和 Kubernetes 上層云原生應用計算之間靈活高效地移動、復制、驅(qū)逐、轉(zhuǎn)換和管理。而具體數(shù)據(jù)操作對用戶透明，用戶不必再擔心訪問遠端數(shù)據(jù)的效率、管理數(shù)據(jù)源的便捷性，以及如何幫助 Kuberntes 做出運維調(diào)度決策等問題。用戶只需以最自然的 Kubernetes 原生數(shù)據(jù)卷方式（PV/PVC）直接訪問抽象出來的數(shù)據(jù)，剩余任務和底層細節(jié)全部交給 Fluid 處理。

Fluid支持多種Runtime，包括Jindo，Alluxio，JuiceFS和GooseFS；其中能力、性能和穩(wěn)定性比較突出的是JindoRuntime，有比較多的真實落地場景。JindoRuntime是 Fluid一種分布式緩存 Runtime 的實現(xiàn)，基于 JindoCache 分布式緩存加速引擎。

JindoCache

JindoCache（前身為JindoFSx）是阿里云數(shù)據(jù)湖管理提供的云原生數(shù)據(jù)湖加速產(chǎn)品，支持數(shù)據(jù)緩存、元數(shù)據(jù)緩存等加速功能。JindoCache 能夠為不同文件路徑使用不同的 CacheSet 從而提供不同的讀寫策略，滿足數(shù)據(jù)湖的不同使用場景對訪問加速的需求。

JindoCache 可以用于如下場景：

• OLAP（Presto查詢），提高查詢性能，減少查詢時間；
• DataServing（HBase），顯著降低P99延遲，減少request費用；
• 大數(shù)據(jù)分析（Hive/Spark 報表），減少報表產(chǎn)出時間，優(yōu)化計算集群成本；
• 湖倉一體，減少request費用，優(yōu)化catalog延遲；
• AI，加速訓練等場景，減少AI集群使用成本，提供更全面的能力支持。

KubeDL

一套基于K8S（ASI）的AI工作負載編排系統(tǒng)，負責管理分布式AI工作負載的生命周期、與一層調(diào)度的交互、容錯與故障恢復、數(shù)據(jù)集、運行時加速等，高效支撐了集團統(tǒng)一資源池中不同平臺的AI訓練任務，包括但不限于淘系、阿里媽媽、達摩院等業(yè)務域，日均支撐1w+訓練任務的穩(wěn)定運行。

項目整體架構圖

3.2 使用基于 JindoCache 的 Fluid 的原因

1. Fluid 可以將數(shù)據(jù)集編排在 Kubernetes 集群中，實現(xiàn)數(shù)據(jù)和計算的同置，并且提供基于 Persistent Volume Claim 接口，實現(xiàn) Kubernetes 上應用的無縫對接。同時 JindoRuntime 提供對 OSS 上數(shù)據(jù)的訪問和緩存加速能力，并且可以利用 FUSE 的 POSIX 文件系統(tǒng)接口實現(xiàn)可以像本地磁盤一樣輕松使用 OSS 上的海量文件，pytorch 等深度學習訓練工具可利用 POSIX 文件接口讀取訓練數(shù)據(jù)；
2. 提供元數(shù)據(jù)和數(shù)據(jù)分布式緩存，可單獨進行元數(shù)據(jù)緩存預熱；
3. 提供元數(shù)據(jù)緩存預熱，避免訓練文件在OSS上大量元數(shù)據(jù)操作、提供數(shù)據(jù)預熱機制，避免在訓練時刻拉取數(shù)據(jù)造成的數(shù)據(jù)訪問競爭；
4. 通過KubeDL調(diào)用Fluid數(shù)據(jù)親和性調(diào)度能力，用戶無需感知緩存存放的節(jié)點位置，以及彈性場景中不斷隨時可能遷移的節(jié)點環(huán)境，將有數(shù)據(jù)依賴的任務和已緩存的節(jié)點進行感知調(diào)度，實現(xiàn)盡可能的短路short-circuit讀，最大化性能優(yōu)勢；
5. JindoCache 提供多種分布式緩存能力，可以根據(jù)業(yè)務需要選擇合適的緩存策略。在當前場景中我們選擇Cache-Aside (Lazy Loading)的讀緩存策略：當應用程序需要讀取數(shù)據(jù)時，它首先檢查緩存以確定數(shù)據(jù)是否可用。如果數(shù)據(jù)可用（緩存命中），則返回緩存的數(shù)據(jù)。如果數(shù)據(jù)不可用（緩存未命中），則會在底層存儲查詢數(shù)據(jù)，然后用從底層讀取的數(shù)據(jù)填充緩存，并將數(shù)據(jù)返回給調(diào)用者。寫緩存策略選擇 Write-Through 即寫時落緩存策略，應用程序向底層文件系統(tǒng)寫入的文件，同時也會被寫入緩存系統(tǒng)中，好處是下一次讀取這部分數(shù)據(jù)的時候就可以直接從緩存系統(tǒng)中讀取，大大提升了讀取效率。
6. Fluid支持FUSE掛載點自愈能力，可以自動檢查并恢復因OOM等異常原因?qū)е碌腇USE掛載點斷裂問題，避免數(shù)據(jù)訪問異常，保障AI平臺在線業(yè)務穩(wěn)定運行。

3.3落地實踐

在集團場景的實踐中，我們基于KubeDL的作業(yè)編排能力，結合Fluid+JindoRuntime的緩存引擎能力，同時充分利用了集團龐大異構計算資源池中閑置的內(nèi)存/高性能磁盤等本地資源，端到端地為AI平臺提供了數(shù)據(jù)I/O的加速能力。

1. 集團龐大的統(tǒng)一異構資源池提供了差異化SLO的資源售賣等級，運行著高保障、Spot Instance、潮汐離線、普通離線 等多種不同等級的資源，以及搭配了多種代系的機型、SSD、高性能網(wǎng)卡等硬件，通過合理搭配JindoCache的多級緩存介質(zhì)，我們能充分利用好統(tǒng)一資源池的閑置資源；
2. 結合JindoCache緩存集群的組成特點，我們使用高保障的計算資源運行元數(shù)據(jù)服務，利用彈性的離線資源來運行Cache緩存節(jié)點服務（IO  Bound類型），在充分結合了集團資源池調(diào)度特點的同時最小化了用戶成本；
3. 結合KubeDL的分布式訓練任務管理與Fluid數(shù)據(jù)集管理能力，我們針對不同用戶的相同數(shù)據(jù)源自動進行數(shù)據(jù)集的跨作業(yè)復用，甚至不同平臺的相同數(shù)據(jù)源也可以在統(tǒng)一資源池中自動復用，并且基于作業(yè)的引用計數(shù)，KubeDL可以自動回收閑置的數(shù)據(jù)集以幫助用戶主動節(jié)約成本；

3.4 經(jīng)驗分享

根據(jù)實踐，我們總結了以下五個方面的經(jīng)驗供大家參考。

1. 選擇合適的緩存節(jié)點: 使用 JindoRuntime 可以獲得更好的數(shù)據(jù)本地性能，在實際生產(chǎn)中我們發(fā)現(xiàn)不是所有節(jié)點都來做緩存性能就比較好。原因是有些節(jié)點的磁盤和網(wǎng)絡 IO 性能不是很好，這個時候需要我們能夠把緩存節(jié)點盡量選擇到一些大容量磁盤和網(wǎng)絡較好的節(jié)點上。Fluid 支持 dataset 的可調(diào)度性，換言之，就是緩存節(jié)點的可調(diào)度性，我們通過指定 dataset 的 nodeAffinity 來進行數(shù)據(jù)集緩存節(jié)點的調(diào)度，從而保證緩存節(jié)點可高效的提供緩存服務。
2. 配置緩存容量與路徑: 通過 dataset 的 Mounts 和 JindoRuntime 的 tieredstore 可以設定數(shù)據(jù)的掛載目錄。同時，為避免數(shù)據(jù)量過多而導致緩存量過于龐大，可手動配置 JindoRuntime 的 tieredstore 來約束緩存的最大容量與水位線（超過水位線的數(shù)據(jù)會被自動丟棄），tieredstore 也包含對緩存存放路徑的設定與存儲層（SSD/MEM/HDD）的設定，以滿足各種場景的需要。對于多節(jié)點的場景，使用dataset 的 replacement 可以支持在同一集群上部署多個dataset。
3. 設定緩存安全策略: 在Fluid中創(chuàng)建Dataset時，有時候我們需要在mounts中配置一些敏感信息，如 oss 賬號的 accessKeyId、accessKeySecret 。為了保證安全，F(xiàn)luid提供使用Secret來配置這些敏感信息的能力。通過創(chuàng)建Secret，dataset 以 EncryptOptions 字段指定 Secret 的 name，實現(xiàn)對敏感信息的綁定。
4. 數(shù)據(jù)預加載: 對于已經(jīng)創(chuàng)建完成的 dataset 和 jindoruntime，第一次訪問掛載的數(shù)據(jù)會經(jīng)歷一次下載數(shù)據(jù)目錄下全部文件的過程，這就產(chǎn)生了一個問題：若數(shù)據(jù)所在的目錄存在無需使用的其他數(shù)據(jù)，會造成無意義的空間資源與網(wǎng)絡資源浪費。為避免這種問題，F(xiàn)luid 既支持對數(shù)據(jù)的預加載，同時也支持元數(shù)據(jù)緩存。通過創(chuàng)建 dataload讀取所要預加載數(shù)據(jù)路徑信息，可以動態(tài)將數(shù)據(jù)注入。dataload 支持緩存元數(shù)據(jù)與屏蔽非預加載數(shù)據(jù)的訪問，這樣就大大降低的數(shù)據(jù)訪問效率。
5. 啟用Fluid FUSE掛載點自愈能力：在線業(yè)務運行過程中，F(xiàn)USE進程可能因為內(nèi)存資源不足以及其他原因崩潰重啟，造成業(yè)務容器內(nèi)FUSE掛載點斷聯(lián)，出現(xiàn)數(shù)據(jù)訪問異常并影響在線業(yè)務可用性。通過啟用Fluid FUSE掛載點自愈能力，F(xiàn)luid自動檢測并修復此類斷聯(lián)掛載點，持續(xù)保障在線業(yè)務穩(wěn)定運行。

3.5 實踐結果

讀樣本加速

以生產(chǎn)環(huán)境中的真實用戶作業(yè)為基礎，我們對JindoCache的效果進行了一次端到端的驗證。

• 目標任務：LLAMA 13B的預訓練任務
• 實驗環(huán)境：
• 集群&機型：高性能網(wǎng)絡集群A800服務器，搭載RDMA網(wǎng)卡與Nvme高速硬盤；
• JindoCache規(guī)格：默認值為24*32Gi Cache Worker，以Nvme盤為存儲介質(zhì)（相對內(nèi)存的性價比更高）；

以下為實驗結論：

LLaMa 13B預訓練模型

監(jiān)控數(shù)據(jù)-無緩存直連。

監(jiān)控數(shù)據(jù)-開啟緩存。

整機的平均GPU利用率同樣接近100%，但是各卡的負載較為均勻，都接近100%。

Checkpoint加速

訓練/離線推理場景

分布式訓練任務在每次重啟任務時都會load checkpoint模型文件以繼續(xù)訓練，模型大小從幾百MB到幾十GB不等；除此之外還有大量的離線推理任務，大量使用了統(tǒng)一資源池中的Spot Instance彈性GPU資源，每個推理任務都會隨時被搶占，并在FailOver之后重新加載模型做離線推理，因此會有大量Job在“生生滅滅”中加載同一個Checkpoint文件。

通過JindoCache的分布式緩存加速，我們將“多次遠端讀”變成了“單次本地讀”，極大加速了Job FailOver速度的同時還為用戶節(jié)約了多次反復讀的帶寬成本，在典型的大模型場景中，7b參數(shù)量搭配fp16精度，模型文件的體積約20Gb，通過JindoCache加速我們將用戶每次加載模型的耗時從 10min縮短到了約30s。

訓練Spot場景（寫時落緩存）

分布式訓練的Spot場景中，同步訓練任務通常會在被搶占之后FailOver重新全局重啟并續(xù)跑，KubeDL會與一層調(diào)度配合，以交互式搶占的方式通知到訓練任務的Rank 0節(jié)點做一次on-demand checkpoint以保存最新的訓練進度，并能夠在重啟后reload最新的checkpoint及時續(xù)跑，享受Spot彈性低成本的同時最小化訓練中斷的代價。

通過最新版本的JindoCache寫時落緩存能力，原先重新后從遠端重新被動load最新的模型文件，變成了重啟后即時從本地緩存集群load最新的模型文件，端到端FailOver的中止時間從平均10min縮短到了平均2min，節(jié)約了80%的閑置寶貴算力損失。

04、總結與展望??

綜上，使用JindoCache在集團大規(guī)模機器學習模型訓練中發(fā)揮了重要作用。在讀樣本加速場景中，使用JindoCache大大提升了系統(tǒng)的吞吐，GPU負載利用更加均衡。CheckPoint加速中使得端到端的模型加載速度也有了質(zhì)的飛躍，使用較低成本完成了性能的巨大提升。未來我們會繼續(xù)進行更多場景的嘗試以及對現(xiàn)有功能的拓展，例如:

• 基于引用計數(shù)，自動回收閑置DataSet數(shù)據(jù)集；
• 數(shù)據(jù)預熱，基于任務訪問數(shù)據(jù)pattern的自動預熱，按目錄優(yōu)先級預熱/驅(qū)逐和并行預熱（按目錄拆解預熱任務)；
• 啟用rdma來加速集群內(nèi)的worker傳輸吞吐，利用好集團高性能網(wǎng)絡基礎設施。

在充分利用JindoCache緩存加速能力的基礎上對使用方式和上層系統(tǒng)的對接進行優(yōu)化，在軟硬件結合方向一起推動性能優(yōu)化和對新硬件支持。

參考鏈接?

[01]Fluid

https://github.com/fluid-cloudnative/fluid

[02] JindoCache

https://github.com/aliyun/alibabacloud-jindodata/blob/master/docs/user/6.x/6.2.0/jindo_fluid/jindo_fluid_overview.md

更多 Fluid 和 JindoCache 相關介紹請參考以上鏈接?

本文轉(zhuǎn)載自： ??阿里技術??

作者： 阿里技術