作者 | 顧榮? 南京大學(xué)?PASALab
（注：本文基于作者公開演講報(bào)告內(nèi)容整理完成）
_來(lái)源 | _阿里巴巴云原生公眾號(hào)

得益于計(jì)算成本低、易于擴(kuò)展、部署便捷、運(yùn)維高效等多方面的優(yōu)勢(shì)，云計(jì)算平臺(tái)吸引了越來(lái)越多的數(shù)據(jù)密集型應(yīng)用在上面運(yùn)行。如今，以 Kubernetes 為代表的云原生架構(gòu)，因其靈活的資源可負(fù)載性以及高效的應(yīng)用編排調(diào)度，在很多AI/大數(shù)據(jù)等數(shù)據(jù)密集型場(chǎng)景中應(yīng)用廣泛。然而，云原生環(huán)境和數(shù)據(jù)密集應(yīng)用計(jì)算框架在早先設(shè)計(jì)理念和機(jī)制上存在天然分歧。因此，如何幫助數(shù)據(jù)密集型應(yīng)用在云原生場(chǎng)景下高效、安全、便捷地訪問(wèn)數(shù)據(jù)，是一個(gè)既有理論意義又具應(yīng)用價(jià)值的重要問(wèn)題。

為了解決大數(shù)據(jù)、AI 等數(shù)據(jù)密集型應(yīng)用在云原生計(jì)算存儲(chǔ)分離場(chǎng)景下，存在的數(shù)據(jù)訪問(wèn)延時(shí)高、聯(lián)合分析難、多維管理雜等痛點(diǎn)問(wèn)題，南京大學(xué) PASALab、阿里巴巴、Alluxio 在 2020 年 9 月份聯(lián)合發(fā)起了開源項(xiàng)目 Fluid。Fluid 本質(zhì)上是一個(gè)云原生環(huán)境下的數(shù)據(jù)密集型應(yīng)用的高效支撐平臺(tái)。本文將向大家介紹 Fluid 項(xiàng)目是如何將數(shù)據(jù)密集型應(yīng)用更高效地運(yùn)行于 K8s 環(huán)境中的。

項(xiàng)目背景簡(jiǎn)介

1. 技術(shù)發(fā)展背景

過(guò)去十年云計(jì)算、大數(shù)據(jù)、人工智能等技術(shù)發(fā)展突飛猛進(jìn)。

• 云計(jì)算平臺(tái)領(lǐng)域：以 Docker、Kubernetes 為代表的容器及其編排的云原生技術(shù)，在應(yīng)用服務(wù)部署自動(dòng)化運(yùn)維的浪潮當(dāng)中得到了長(zhǎng)足的發(fā)展。
• 大數(shù)據(jù)處理領(lǐng)域：以 Hadoop、Spark、Alluxio 為代表的大數(shù)據(jù)并行計(jì)算與分布式存儲(chǔ)技術(shù)，在眾多行業(yè)領(lǐng)域大數(shù)據(jù)處理與存儲(chǔ)的應(yīng)用落地中幾乎形成了主流生態(tài)。
• 人工智能框架領(lǐng)域：PyTorch、Tensorflow、Caffe 等知名 AI 訓(xùn)練框架，在廣大 AI 應(yīng)用開發(fā)者反復(fù)使用和參與當(dāng)中，發(fā)展日益成熟。

其中，大數(shù)據(jù)應(yīng)用和 AI 應(yīng)用通常需要圍繞大規(guī)模數(shù)據(jù)展開計(jì)算分析，是典型的數(shù)據(jù)密集型應(yīng)用，而云計(jì)算平臺(tái)得益于其計(jì)算成本和易于規(guī)模擴(kuò)展的優(yōu)勢(shì)，以及容器化在高效部署和敏捷迭代方面的長(zhǎng)處，吸引了越來(lái)越多的數(shù)據(jù)密集型應(yīng)用在上面部署運(yùn)行。

大數(shù)據(jù)應(yīng)用、AI、云計(jì)算三者的融合正在成為下一個(gè)重要的發(fā)展趨勢(shì)。Gartner 預(yù)測(cè)，到 2023 年，70% 以上的 AI workloads 都將以應(yīng)用容器化的方式部署運(yùn)行，然后通過(guò) Serverless 編程模型在云原生環(huán)境下進(jìn)行構(gòu)建。Spark 3.0.1 版本也開始支持 Kubernetes scheduler，擁抱云原生環(huán)境。

• 詳情見 Gartner 報(bào)告：

https://www.gartner.com/en/conferences/emea/data-analytics-switzerland/featured-topics/topic-ai-machine-learning

• Spark3.0.1 runs on K8s：

https://spark.apache.org/docs/latest/running-on-kubernetes.html

2. 面臨的問(wèn)題

從用戶的實(shí)際體驗(yàn)來(lái)看，現(xiàn)有云原生編排框架對(duì)數(shù)據(jù)密集型應(yīng)用支持不夠友好，主要體現(xiàn)在運(yùn)行效率低下和數(shù)據(jù)管理復(fù)雜兩方面。

運(yùn)行效率低下：如上圖所示，訓(xùn)練一個(gè) RestNet50 神經(jīng)網(wǎng)絡(luò)，如果基于本地內(nèi)存運(yùn)行，大概每秒鐘能訓(xùn)練近 1 萬(wàn)張圖片；然而，在云原生環(huán)境下運(yùn)行，基于 Cloud Storage 存儲(chǔ)架構(gòu)每秒訓(xùn)練的圖片只能達(dá)到約 3000 張/秒，性能下降比較明顯。

數(shù)據(jù)管理復(fù)雜：數(shù)據(jù)版本的多變、數(shù)據(jù)接口的多樣、數(shù)據(jù)類型的抽象以及數(shù)據(jù)存儲(chǔ)的異構(gòu)，都給云原生環(huán)境下面向數(shù)據(jù)密集型應(yīng)用支撐帶來(lái)了挑戰(zhàn)。

3. 問(wèn)題的原因分析

云原生環(huán)境和數(shù)據(jù)密集處理框架在設(shè)計(jì)理念和機(jī)制上存在天然分歧，這兩部分技術(shù)的早先產(chǎn)生和發(fā)展過(guò)程是相互獨(dú)立的。我們可以看到，為了兼顧資源擴(kuò)展的靈活性和使用成本，計(jì)算和存儲(chǔ)分離的基本架構(gòu)在云原生環(huán)境中大行其道；反觀之，以大數(shù)據(jù)!

2.jpg

和 AI 訓(xùn)練為代表的數(shù)據(jù)密集型應(yīng)用框架，為了減少數(shù)據(jù)傳輸，設(shè)計(jì)理念更多需要考慮數(shù)據(jù)本地化架構(gòu)，兩者在設(shè)計(jì)上存在分歧。

另外，我們發(fā)現(xiàn)在云原生環(huán)境中，應(yīng)用通常是以無(wú)狀態(tài)（stateless）微服務(wù)化的方式進(jìn)行部署，通過(guò) FaaS（Function as a Service）方式串聯(lián)。而在數(shù)據(jù)密集型框架應(yīng)用中，是以數(shù)據(jù)抽象為中心開展，并進(jìn)行任務(wù)分配執(zhí)行，比如在 Spark 里都是圍繞 RDD 構(gòu)建整個(gè)大數(shù)據(jù)處理應(yīng)用，中間加上算子。然而，無(wú)狀態(tài)微服務(wù)并不是以數(shù)據(jù)為中心，這也存在設(shè)計(jì)上的分歧。

以上問(wèn)題導(dǎo)致以 Kubernetes 為代表的云原生編排框架對(duì)于數(shù)據(jù)密集型應(yīng)用，尤其是 AI 和大數(shù)據(jù)應(yīng)用的支持還不夠友好，具體體現(xiàn)在前面所述的運(yùn)行效率低下、數(shù)據(jù)操作管理復(fù)雜等方面。

我們縱觀 Fluid 出現(xiàn)之前的云原生基金會(huì)（CNCF）全景圖，涵蓋了從應(yīng)用交付 - 運(yùn)維管理 - 底層存儲(chǔ)的方方面面，但是缺少數(shù)據(jù)高效支撐組件這塊重要拼圖（注：Fluid近期剛進(jìn)入CNCF 全景圖，側(cè)面反映本文理念得到了認(rèn)可）。然而，這塊拼圖的缺失，就會(huì)造成大數(shù)據(jù)密集型應(yīng)用在云原生環(huán)境下運(yùn)行時(shí)，面臨數(shù)據(jù)訪問(wèn)低效、數(shù)據(jù)隔離性弱、多數(shù)據(jù)源聯(lián)合訪問(wèn)復(fù)雜方面的技術(shù)挑戰(zhàn)。

4. 云原生環(huán)境下的數(shù)據(jù)支撐挑戰(zhàn)

具體地，云原生環(huán)境下數(shù)據(jù)支撐的挑戰(zhàn)主要分為三個(gè)方面：

• 第一：云平臺(tái)計(jì)算存儲(chǔ)分離架構(gòu)導(dǎo)致數(shù)據(jù)訪問(wèn)延時(shí)高。為了監(jiān)控資源靈活性滿足本地?zé)o依賴的要求，云原生應(yīng)用大多采用計(jì)算存儲(chǔ)分離架構(gòu)。但是從訪問(wèn)效率的角度來(lái)看，要求用云網(wǎng)絡(luò)傳輸帶寬，當(dāng)數(shù)據(jù)密集型應(yīng)用在云上運(yùn)行時(shí)，會(huì)造成數(shù)據(jù)訪問(wèn)瓶頸、性能下降。
• 第二：混合云場(chǎng)景下跨存儲(chǔ)系統(tǒng)的聯(lián)合分析困難。大多公司/組織通常基于不同存儲(chǔ)管理數(shù)據(jù)支撐多樣化應(yīng)用，具備其各自的特點(diǎn)。Ceph、GlusterFS、HDFS 都會(huì)被廣泛使用，數(shù)據(jù)也通常會(huì)散落在這些異構(gòu)存儲(chǔ)當(dāng)中。然而，當(dāng)需要聯(lián)合數(shù)據(jù)進(jìn)行綜合性分析時(shí)，會(huì)增加數(shù)據(jù)移動(dòng)成本，必然導(dǎo)致在云原生環(huán)境下需要面對(duì)網(wǎng)絡(luò)費(fèi)用、等待延時(shí)、人工操作等比較復(fù)雜的問(wèn)題。
• 第三：云環(huán)境中數(shù)據(jù)安全治理與多維度管理復(fù)雜。數(shù)據(jù)是很多公司的生命線，數(shù)據(jù)泄露、誤操作、生命周期管理不當(dāng)都會(huì)造成巨大損失。如何在云原生環(huán)境中保障數(shù)據(jù)的隔離，保護(hù)好用戶的數(shù)據(jù)生命周期，都存在較大挑戰(zhàn)。

5. Kubernetes 生態(tài)中缺失的一塊抽象

綜上所述，我們可以總結(jié)出一種現(xiàn)象：Kubernetes 生態(tài)中目前缺少數(shù)據(jù)密集型應(yīng)用高效支撐的這塊拼圖。現(xiàn)有 Kubernetes 環(huán)境能對(duì)很多資源進(jìn)行很好的抽象，包括將資源對(duì)象計(jì)算抽象成 Pod、將存儲(chǔ)抽象成了 PV/PVC、將網(wǎng)絡(luò)抽象成了 Service。云原生領(lǐng)域還有一些存儲(chǔ)抽象主要面向數(shù)據(jù)持久化進(jìn)行工作，提供對(duì)象和文件的持久化存儲(chǔ)管理。但這些軟件的功能缺乏以應(yīng)用為中心的數(shù)據(jù)抽象及相關(guān)生命周期管理。

6. 商店購(gòu)物模式演變的聯(lián)想

為了更好地理解這些問(wèn)題，我們可以做一些聯(lián)想性的思考。如下圖所示，引入商品購(gòu)物模式，我們將商品、超市、客戶類比為數(shù)據(jù)、存儲(chǔ)、應(yīng)用。

• 商品和數(shù)據(jù)都會(huì)被消費(fèi)，商品會(huì)被消費(fèi)者購(gòu)買掉，數(shù)據(jù)會(huì)被應(yīng)用讀走，兩者有一定類似性。

• 超市和存儲(chǔ)類似，都起到貯藏與供應(yīng)的功能。商品平時(shí)會(huì)貯藏在超市的貨架上，當(dāng)購(gòu)買時(shí)扮演到供應(yīng)的角色；對(duì)于存儲(chǔ)而言，我們平時(shí)貯藏的數(shù)據(jù)都會(huì)被持久化到存儲(chǔ)設(shè)備里，當(dāng)應(yīng)用需要時(shí)提供給用戶。

• 客戶和應(yīng)用類似，客戶會(huì)到商店消費(fèi)購(gòu)買商品。類似的，應(yīng)用會(huì)到存儲(chǔ)讀取數(shù)據(jù)。

商品、超市（商鋪） 、客戶模式，在過(guò)去幾千年里發(fā)展得非常成熟，非常穩(wěn)定。直到 2000 年之后發(fā)生了顛覆性的變化，這就是電商的產(chǎn)生。電商發(fā)明了線上購(gòu)物模式，其特點(diǎn)體現(xiàn)在不再以店鋪為中心而是以客戶為中心，商品貯藏在倉(cāng)庫(kù)，客戶可以在線上虛擬商鋪挑選商品，最后由現(xiàn)代化物流將商品交付到客戶，交易過(guò)程高效便捷、交易量更大。商品直接放在倉(cāng)庫(kù)里，倉(cāng)庫(kù)可以進(jìn)行規(guī)范化、獨(dú)立化管理，之后客戶到電商平臺(tái)上購(gòu)買貨物，會(huì)非常便捷、方便。客戶不需要到店鋪，在地鐵上、車上、辦公室、家里都可以用手機(jī)、電腦進(jìn)行購(gòu)物，而且不會(huì)存在商品尋找低效的情況，因?yàn)榭蛻羰窃诨ヂ?lián)網(wǎng)上購(gòu)物，都可以通過(guò)檢索方式查找海量商品；線上購(gòu)物的另一個(gè)優(yōu)勢(shì)是交易頻次變得更高，交易量變得更大；客戶也不需要必須去店里提貨，快遞可以直接送貨上門，非常方便。

電商模式的成功有很多因素，其中有兩大因素非常關(guān)鍵，一是如支付寶這樣的第三方數(shù)字化支付工具的出現(xiàn)，二是如菜鳥這樣專業(yè)化的物流系統(tǒng)產(chǎn)生，構(gòu)建起四通八達(dá)的物流網(wǎng)絡(luò)，使快速的商品寄送模式得以實(shí)現(xiàn)。反觀回到現(xiàn)在計(jì)算機(jī)系統(tǒng)中，在現(xiàn)代云架構(gòu)下，數(shù)據(jù)貯存在云存儲(chǔ)系統(tǒng)中，數(shù)據(jù)密集型應(yīng)用也以pod等各種各樣資源描述符的方式在云原生環(huán)境下運(yùn)行，但中間卻缺乏一個(gè)高效的數(shù)據(jù)交付、數(shù)據(jù)遞送的方式。也就是說(shuō)，在云原生架構(gòu)下面，數(shù)據(jù)貯藏在云存儲(chǔ)系統(tǒng)當(dāng)中，應(yīng)用還是根據(jù)需要去訪問(wèn)數(shù)據(jù)，但由于類似的數(shù)據(jù)**“物流系統(tǒng)”的缺失，導(dǎo)致數(shù)據(jù)密集型應(yīng)用消費(fèi)訪問(wèn)數(shù)據(jù)在云平臺(tái)上比較低效**。

Fluid 核心理念

基于以上的分析，以及從觀察中得到的聯(lián)想，下面來(lái)介紹 Fluid 的核心理念。

1. Fluid 扮演云原生的“數(shù)據(jù)物流系統(tǒng)”角色

我們可以將 Fluid 所扮演角色理解為云原生環(huán)境下“數(shù)據(jù)物流系統(tǒng)”。回顧一下，在早先的大數(shù)據(jù)平臺(tái)中，數(shù)據(jù)的訪問(wèn)盡量都是通過(guò)本地化進(jìn)行。當(dāng)用戶寫一個(gè) MapReduce Job，Job 里包含很多 Task， 其中關(guān)注比較多的就是 MapTask 處理數(shù)據(jù)時(shí)是盡量將 Task 調(diào)度到用戶要處理的數(shù)據(jù)所在的節(jié)點(diǎn)上運(yùn)行。這種情況下，當(dāng)用戶訪問(wèn)數(shù)據(jù)時(shí)，盡管該數(shù)據(jù)是在 HDFS 這個(gè)分布式系統(tǒng)中，但本質(zhì)上相當(dāng)于從分布式系統(tǒng)中的本地節(jié)點(diǎn)上獲取，我們稱之為 Data Fetch。

隨著大數(shù)據(jù)生態(tài)系統(tǒng)的迅速發(fā)展，其上的應(yīng)用框架變得越來(lái)越多，底層存儲(chǔ)系統(tǒng)也變得越來(lái)越豐富，各種上層應(yīng)用要訪問(wèn)不同種類、多樣化系統(tǒng)的痛點(diǎn)越來(lái)越明顯，于是出現(xiàn)了 Alluxio 這樣一個(gè)優(yōu)秀的開源項(xiàng)目，來(lái)統(tǒng)一管理底層不同存儲(chǔ)系統(tǒng)，為上層提供統(tǒng)一化的標(biāo)準(zhǔn)接口，對(duì)上層應(yīng)用屏蔽不同存儲(chǔ)的差異。而且 Alluxio 提供內(nèi)存緩存，加速數(shù)據(jù)訪問(wèn)。這個(gè)過(guò)程就解耦了本地化的情況，存儲(chǔ)就可以實(shí)現(xiàn)分離。這種分離架構(gòu)在部署好之后通常還是靜態(tài)的，實(shí)現(xiàn)從 Data Fetch 變成 Data Access 的過(guò)程。

Fluid 是在 Alluxio 基礎(chǔ)之上，在云原生環(huán)境的調(diào)度層面上進(jìn)行進(jìn)一步的研究和拓展，希望獲取云原生環(huán)境下數(shù)據(jù)節(jié)點(diǎn)以及應(yīng)用的動(dòng)態(tài)變化信息，讓這一類靜態(tài)的緩存等中間件動(dòng)態(tài)、靈活地調(diào)動(dòng)起來(lái)，從而讓應(yīng)用靈活性變得更強(qiáng)，實(shí)現(xiàn)數(shù)據(jù)智能化遞送到應(yīng)用的效果，即動(dòng)態(tài)彈性（Data Delivery） 。

在進(jìn)行項(xiàng)目設(shè)計(jì)時(shí)，我們希望 Fluid 從視角、思路、理念三個(gè)層次帶來(lái)一些革新：

• 新視角：從云原生資源調(diào)度結(jié)合與數(shù)據(jù)密集型處理兩個(gè)方面，重新綜合審視云原生場(chǎng)景的數(shù)據(jù)抽象與支撐訪問(wèn)。
• 新思路：針對(duì)容器編排缺乏數(shù)據(jù)感知，數(shù)據(jù)編排缺乏對(duì)云上架構(gòu)變化的感知，提出了協(xié)同編排、多維管理、智能感知的一系列理念和創(chuàng)新方法；從而形成一套云原生環(huán)境下數(shù)據(jù)密集型應(yīng)用的高效支撐平臺(tái)。
• 新理念：通過(guò) Fluid 這個(gè)項(xiàng)目，希望讓數(shù)據(jù)可以像流體一樣在云平臺(tái)中、在資源編排層和數(shù)據(jù)處理層之間能夠靈活高效地被訪問(wèn)、轉(zhuǎn)換和管理。

2. 核心理念

簡(jiǎn)單來(lái)說(shuō)，Fluid 的核心理念，可以分為“一個(gè)抽象”和“兩個(gè)編排”。

首先在云原生環(huán)境里，抽象出了數(shù)據(jù)集的概念，它能夠提供一個(gè)對(duì)底層存儲(chǔ)的包裝，對(duì)上層也能提供各種各樣的支撐和訪問(wèn)能力，從而通過(guò) API 的方式來(lái)簡(jiǎn)單地在 K8s 下實(shí)現(xiàn)對(duì)數(shù)據(jù)的操作。

在這個(gè)基礎(chǔ)之上，Fluid 提供了兩個(gè)編排的能力：

首先是對(duì)于數(shù)據(jù)集進(jìn)行編排，具體是指基于容器調(diào)度管理的數(shù)據(jù)進(jìn)行編排。傳統(tǒng)的方式只對(duì)數(shù)據(jù)本身進(jìn)行管理，而 Fluid 的數(shù)據(jù)集編排則轉(zhuǎn)為對(duì)承載數(shù)據(jù)的引擎進(jìn)行編排和管理。通過(guò)對(duì)數(shù)據(jù)引擎進(jìn)行合理的擴(kuò)容、縮容和調(diào)度操作，和數(shù)據(jù)引擎的交互，從而實(shí)現(xiàn)對(duì)數(shù)據(jù)的遷移、緩存以及數(shù)據(jù)在 K8s 平臺(tái)下靈活調(diào)度的管理和變化。

第二個(gè)編排是對(duì)使用和消費(fèi)這類數(shù)據(jù)集的應(yīng)用進(jìn)行編排。我們需要處理這些應(yīng)用的調(diào)度，在調(diào)度時(shí)盡量使其感知緩存數(shù)據(jù)集，這樣就可以在這調(diào)度應(yīng)用的時(shí)候合理選擇節(jié)點(diǎn)，從而高效地進(jìn)行相關(guān)計(jì)算。

總結(jié)來(lái)講，Fluid 具有以下三大功能：

1）提供云平臺(tái)數(shù)據(jù)集抽象的原生支持

數(shù)據(jù)密集型應(yīng)用所需基礎(chǔ)支撐能力功能化，實(shí)現(xiàn)數(shù)據(jù)高效訪問(wèn)并降低多維成本。

2）基于容器調(diào)度管理的數(shù)據(jù)集編排

通過(guò)數(shù)據(jù)集緩存引擎與 Kubernetes 容器調(diào)度和擴(kuò)縮容能力的相互配合，實(shí)現(xiàn)數(shù)據(jù)集可遷移性。

3）面向云上數(shù)據(jù)本地化的應(yīng)用調(diào)度

Kubernetes 調(diào)度器通過(guò)與緩存引擎交互獲得節(jié)點(diǎn)的數(shù)據(jù)緩存信息，將使用該數(shù)據(jù)的應(yīng)用以透明的方式調(diào)度到包含數(shù)據(jù)緩存的節(jié)點(diǎn)，最大化緩存本地性的優(yōu)勢(shì)。

Fluid 架構(gòu)功能

1. Fluid 系統(tǒng)架構(gòu)

Fluid 是構(gòu)建在 K8s 上的系統(tǒng)，對(duì)原生 K8s 具備良好的兼容性，無(wú)需修改任意代碼。如上圖所示，用戶需要定義兩個(gè) CRD，分別是 Dataset 和 Runtime。Dataset 是數(shù)據(jù)集的通用定義，這是我們提供的 K8s 資源對(duì)象，需要寫 YAML 文件來(lái)定義數(shù)據(jù)集從哪兒來(lái)，以及想要放到哪兒去；Runtime 是存儲(chǔ)這些數(shù)據(jù)集的緩存引擎，目前使用的是開源的分布式緩存系統(tǒng) Alluxio。這里要注意的是 Dataset 和 Runtime 定義的時(shí)候，它通常是要具有相同 Namespace，從而實(shí)現(xiàn)很好的綁定。

Fluid Operator 是 Fluid 項(xiàng)目的核心，它分為兩部分。第一部分是 Fluid-controller-manager，包含很多 Controller；另一部分為 Fluid-Scheduler。這兩個(gè)組件完成了編排調(diào)度的操作。Fluid-controller-manager 做的工作就是對(duì)數(shù)據(jù)進(jìn)行編排，包括三個(gè) Controller。這三個(gè) Controller 從邏輯上它們是獨(dú)立的，可以去做單進(jìn)程。但為了降低復(fù)雜性，很多 Controller 的功能編譯時(shí)被合并成一個(gè)和多個(gè)可執(zhí)行文件，所以在真正運(yùn)行起來(lái)時(shí)，也是一個(gè)進(jìn)程。

• 數(shù)據(jù)集的 Dataset Controller 負(fù)責(zé)整個(gè)數(shù)據(jù)集的生命周期管理，包括數(shù)據(jù)集的創(chuàng)建，以及要和哪個(gè) Runtime 進(jìn)行綁定。
• Runtime Controller 負(fù)責(zé)數(shù)據(jù)集如何在云原生平臺(tái)上被調(diào)度與緩存，應(yīng)該放在哪些節(jié)點(diǎn)上，要有多少副本。
• Volume Controller：由于 Fluid 是基于 K8s 運(yùn)行，因此需要和 K8s 進(jìn)行對(duì)接，這里我們使用的是 PVC（數(shù)據(jù)持久卷）協(xié)議，這是 K8s 本地存儲(chǔ)棧的協(xié)議，使用非常廣泛，Fluid 與 PVC 的對(duì)接非常流暢。

最下面為 Cache Runtime Engine，是真正完成緩存數(shù)據(jù)具體工作的地方。
圖中右邊部分的 Fluid-Scheduler 主要是基于定義好的 dataset、runtime controller 等具體信息，對(duì) K8s 的調(diào)度器做一些擴(kuò)展。這里面包含兩個(gè) Plugin：

• Cache co-locality Plugin：Cache co-locality Plugin 做的事就是結(jié)合前面數(shù)據(jù)編排的信息，把應(yīng)用調(diào)度到最合適的節(jié)點(diǎn)上，然后盡量能夠讓用戶去讀到緩存節(jié)點(diǎn)里面的信息。
• Prefetch Plugin：當(dāng)用戶集群還沒有緩存流入數(shù)據(jù)情況之下，且知道應(yīng)用肯定是要讀哪一類數(shù)據(jù)時(shí)，尤其在應(yīng)用調(diào)度和編排運(yùn)行之前，可以做 Prefetch 的調(diào)度，將這個(gè)數(shù)據(jù)從最底下的存儲(chǔ)卷當(dāng)中緩存到數(shù)據(jù)緩存里面，可以手動(dòng)觸發(fā)。

再往下就是標(biāo)準(zhǔn) K8s。通過(guò) K8s 可以對(duì)接底層不同的存儲(chǔ)，具體的對(duì)接方式可通過(guò) K8s 的 PVC 完成。由于通過(guò) Alluxio 進(jìn)行了抽象，可以直接支持 Alluxio 本身支持的存儲(chǔ)類型。

2. Fluid 的功能概念

Fluid 不是全存儲(chǔ)加速和管理，而是以應(yīng)用為中心數(shù)據(jù)集加速和管理。

三個(gè)重要概念：

• Dataset：數(shù)據(jù)集是邏輯上相關(guān)的一組數(shù)據(jù)的集合，不同數(shù)據(jù)集的特性和優(yōu)化都是不一樣的，所以對(duì)于數(shù)據(jù)集是要分開管理的，一致的文件特性，會(huì)被同一運(yùn)算引擎使用。
• Runtime：真正實(shí)現(xiàn)數(shù)據(jù)集安全性，版本管理和數(shù)據(jù)加速等能力的執(zhí)行引擎的接口，包括如何創(chuàng)建、生命周期如何管理等等，定義了一系列生命周期的方法。
• AlluxioRuntime：來(lái)自 Alluxio 社區(qū)，是支撐 Dataset 數(shù)據(jù)管理和緩存的執(zhí)行引擎高效實(shí)現(xiàn)。

通過(guò)以上概念與架構(gòu)，實(shí)現(xiàn)了以下功能：

1）加速

• Observation: know the cache capacity easily.
• Portableand Scalable: adjust the cache capacity on demand.
• Co-locality: ?bring data close to compute, and bring compute close to data.

通過(guò) K8s 提供了這個(gè)很好的可觀測(cè)性，我們能夠知道我們的緩存容量和當(dāng)前狀態(tài)，進(jìn)一步地我們就可以很靈活的去遷移和擴(kuò)展緩存，然后按需增加緩存容量。并且在擴(kuò)展和遷移過(guò)程當(dāng)中會(huì)充分考慮 co-locality，即本地性。將數(shù)據(jù)和計(jì)算在編排和調(diào)度時(shí)放在一起，從而實(shí)現(xiàn)加速目的。

2）數(shù)據(jù)卷接口，統(tǒng)一訪問(wèn)不同存儲(chǔ)

從對(duì)接上面，支持?jǐn)?shù)據(jù)卷接口，從而統(tǒng)一訪問(wèn)不同的存儲(chǔ)，且 K8s 的任何數(shù)據(jù)卷都可以包裝成 Fluid-Dataset 來(lái)進(jìn)行使用加速。

3）隔離

隔離機(jī)制使得對(duì)數(shù)據(jù)集的訪問(wèn)可以在不同存儲(chǔ)加速間進(jìn)行隔離，并且實(shí)現(xiàn)權(quán)限控制管理。

3. 如何使用 Fluid

以上圖為例，用戶在使用場(chǎng)景中需要使用來(lái)自兩個(gè)不同地方的數(shù)據(jù)，假設(shè)一個(gè)來(lái)自阿里云，另外一個(gè)是本地存儲(chǔ) Ceph。在 Fluid 里面我們可以很容易地描述這樣的數(shù)據(jù)集，通過(guò)創(chuàng)建一個(gè)自定義 K8s 資源對(duì)象 Dataset，對(duì)應(yīng)的 mountPoint 可以加載兩個(gè)，分別是阿里云和 Ceph。

創(chuàng)建好就可以運(yùn)行，這個(gè)過(guò)程中 Fluid 會(huì)創(chuàng)建一個(gè) Dataset，并自動(dòng)將它變成一個(gè) PVC。當(dāng)用戶需要用這個(gè)數(shù)據(jù)時(shí)創(chuàng)建一個(gè) Pod，以 PVC 掛載的方式，將 Dataset 關(guān)聯(lián)到運(yùn)行中的 Pod 中對(duì)數(shù)據(jù)進(jìn)行訪問(wèn)。甚至 Pod 根本都不知道 PVC 后臺(tái)運(yùn)行的是 Fluid，而不是其他的存儲(chǔ)，例如 NFS。整個(gè)過(guò)程和背后的原理對(duì)用戶都是透明的，這使得對(duì)遺留程序的對(duì)接非常友好。

4. 如何檢查和觀測(cè) dataset 狀態(tài)

當(dāng)真正運(yùn)行起來(lái)時(shí)有很多可觀測(cè)的東西，我們?cè)?Dataset CRD 里定義了很多 metrics。如上圖所以，緩存總?cè)萘繛?200GB，實(shí)際需要的容量為 84.29GB，無(wú)需擴(kuò)容，后續(xù)可根據(jù)實(shí)際需求靈活擴(kuò)容。通過(guò)這個(gè)工具，用戶可以有效查詢存儲(chǔ)容量與使用量，從而實(shí)現(xiàn)可觀測(cè)性。

5. 根據(jù)數(shù)據(jù)集本地性調(diào)度作業(yè)

對(duì)于使用數(shù)據(jù)集應(yīng)用的編排也很容易，只需要使用 PVC 模式把 Fluid 數(shù)據(jù)集掛載到應(yīng)用當(dāng)中，然后 K8s 調(diào)度器就會(huì)和 Fluid 調(diào)度器進(jìn)行交互。

如上圖例子所示，掛載之后進(jìn)行交互，根據(jù)調(diào)度策略安排 Pod 在對(duì)應(yīng)的節(jié)點(diǎn)上運(yùn)行。K8s 調(diào)度器和 Fluid 調(diào)度器交互時(shí)會(huì)看見三個(gè)節(jié)點(diǎn)，其中有兩個(gè)有 Alluxio 緩存節(jié)點(diǎn)。我們知道經(jīng)典的 K8s 調(diào)度包括兩個(gè)很重要的階段，一個(gè)是過(guò)濾階段，另一個(gè)是優(yōu)選階段。在過(guò)濾階段就會(huì)將第三個(gè)節(jié)點(diǎn)直接過(guò)濾掉，而在優(yōu)選階段可以利用一些內(nèi)置優(yōu)選的策略來(lái)選擇更合適的節(jié)點(diǎn)，例如緩存空間量大小，這里面有很多未來(lái)可以拓展優(yōu)化實(shí)現(xiàn)的空間。

Fluid 性能評(píng)估

如上圖所示，我們發(fā)現(xiàn)卡數(shù)量越來(lái)越多的時(shí)候，使用 Fluid 會(huì)帶來(lái)巨大的性能提升。這其中的本質(zhì)原因是當(dāng) GPU 數(shù)量變得越來(lái)越多（或 GPU 算力越來(lái)越強(qiáng)）時(shí)，訪問(wèn)大規(guī)模數(shù)據(jù)已經(jīng)成為整個(gè)訓(xùn)練任務(wù)的瓶頸。從上圖是訓(xùn)練結(jié)果來(lái)看，使用 Fluid 訓(xùn)練的端到端的性能最后提升約1倍，減少成本并提升了用戶體驗(yàn)。

我們?cè)陧?xiàng)目 github 主頁(yè)上提供了許多 Demo 演示，具體詳情可以點(diǎn)擊觀看視頻：https://developer.aliyun.com/live/246068，或參見：https://github.com/fluid-cloudnative/fluid#qucik-demo

加入 Fluid 社區(qū)

想要了解更多關(guān)于 Fluid 的信息，請(qǐng)?jiān)L問(wèn) Fluid 項(xiàng)目 Github 地址或查看 Fluid 項(xiàng)目主頁(yè)。也歡迎大家加入 Fluid 社區(qū)交流釘釘群，與更多用戶和開發(fā)者深入交流項(xiàng)目技術(shù)及其實(shí)際使用場(chǎng)景。

• Fluid 項(xiàng)目 GitHub 地址：https://github.com/fluid-cloudnative/fluid
• Fluid 項(xiàng)目主頁(yè)：http://pasa-bigdata.nju.edu.cn/fluid/index.html
• 社區(qū)交流釘群：

總結(jié)

以上是生活随笔為你收集整理的Fluid — 云原生环境下的高效“数据物流系统”的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。