一、背景

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

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

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

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

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

二、面臨的挑戰

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

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

三、面向深度學習任務的高效緩存調度加速系統

3.1 架構組件介紹

Fluid

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

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

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

JindoCache

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

JindoCache 可以用于如下場景：

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

KubeDL

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

項目整體架構圖

3.2 使用基于 JindoCache 的 Fluid 的原因

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

3.3落地實踐

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

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

3.4 經驗分享

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

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

3.5 實踐結果

讀樣本加速

以生產環境中的真實用戶作業為基礎，我們對JindoCache的效果進行了一次端到端的驗證。

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

以下為實驗結論：

LLaMa 13B預訓練模型

監控數據-無緩存直連。

監控數據-開啟緩存。

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

Checkpoint加速

訓練/離線推理場景

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

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

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

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

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

04、總結與展望??

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

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

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

參考鏈接?

[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 相關介紹請參考以上鏈接?

本文轉載自： ??阿里技術??

作者： 阿里技術