一、背景

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

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

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

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

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

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

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

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

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

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

Fluid

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

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

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

JindoCache

JindoCache（前身為JindoFSx）是阿里云數(shù)據(jù)湖管理提供的云原生數(shù)據(jù)湖加速產(chǎn)品，支持?jǐn)?shù)據(jù)緩存、元數(shù)據(jù)緩存等加速功能。JindoCache 能夠?yàn)椴煌募窂绞褂貌煌?CacheSet 從而提供不同的讀寫策略，滿足數(shù)據(jù)湖的不同使用場(chǎng)景對(duì)訪問(wèn)加速的需求。

JindoCache 可以用于如下場(chǎng)景：

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

KubeDL

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

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

3.2 使用基于 JindoCache 的 Fluid 的原因

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

3.3落地實(shí)踐

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

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

3.4 經(jīng)驗(yàn)分享

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

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

3.5 實(shí)踐結(jié)果

讀樣本加速

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

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

以下為實(shí)驗(yàn)結(jié)論：

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

監(jiān)控?cái)?shù)據(jù)-無(wú)緩存直連。

監(jiān)控?cái)?shù)據(jù)-開(kāi)啟緩存。

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

Checkpoint加速

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

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

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

訓(xùn)練Spot場(chǎng)景（寫時(shí)落緩存）

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

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

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

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

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

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

參考鏈接?

[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)介紹請(qǐng)參考以上鏈接?

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

作者： 阿里技術(shù)