一、背景

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

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

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

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

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

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

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

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

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

3.1 架構(gòu)組件介紹

Fluid

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

Fluid通過 Kubernetes 服務(wù)提供的數(shù)據(jù)層抽象，可以讓數(shù)據(jù)像流體一樣在諸如 HDFS、OSS、Ceph 等存儲源和 Kubernetes 上層云原生應(yīng)用計算之間靈活高效地移動、復(fù)制、驅(qū)逐、轉(zhuǎn)換和管理。而具體數(shù)據(jù)操作對用戶透明，用戶不必再擔(dān)心訪問遠(yuǎn)端數(shù)據(jù)的效率、管理數(shù)據(jù)源的便捷性，以及如何幫助 Kuberntes 做出運(yùn)維調(diào)度決策等問題。用戶只需以最自然的 Kubernetes 原生數(shù)據(jù)卷方式（PV/PVC）直接訪問抽象出來的數(shù)據(jù)，剩余任務(wù)和底層細(xì)節(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)品，支持?jǐn)?shù)據(jù)緩存、元數(shù)據(jù)緩存等加速功能。JindoCache 能夠為不同文件路徑使用不同的 CacheSet 從而提供不同的讀寫策略，滿足數(shù)據(jù)湖的不同使用場景對訪問加速的需求。

JindoCache 可以用于如下場景：

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

KubeDL

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

項目整體架構(gòu)圖

3.2 使用基于 JindoCache 的 Fluid 的原因

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

3.3落地實踐

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

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

3.4 經(jīng)驗分享

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

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

3.5 實踐結(jié)果

讀樣本加速

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

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

以下為實驗結(jié)論：

LLaMa 13B預(yù)訓(xùn)練模型

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

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

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

Checkpoint加速

訓(xùn)練/離線推理場景

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

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

訓(xùn)練Spot場景（寫時落緩存）

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

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

04、總結(jié)與展望??

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

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

在充分利用JindoCache緩存加速能力的基礎(chǔ)上對使用方式和上層系統(tǒng)的對接進(jìn)行優(yōu)化，在軟硬件結(jié)合方向一起推動性能優(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 相關(guān)介紹請參考以上鏈接?

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

作者： 阿里技術(shù)