![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/7b9b0c8052864f7e991b1f4d3c8ba84e.png)

作者 | 顧榮  南京大學 PASALab
_（注：本文基於作者公開演講報告內容整理完成）_
_來源 | _[_阿里巴巴雲原生公眾號_](https://mp.weixin.qq.com/s/aXb-PE0cfzaXXXs2GJ3PuA)

得益於計算成本低、易於擴充套件、部署便捷、運維高效等多方面的優勢，雲端計算平臺吸引了越來越多的資料密集型應用在上面執行。如今，以 Kubernetes 為代表的雲原生架構，因其靈活的資源可負載性以及高效的應用編排排程，在很多AI/大資料等資料密集型場景中應用廣泛。然而，雲原生環境和資料密集應用計算框架在早先設計理念和機制上存在天然分歧。因此，如何幫助資料密集型應用在雲原生場景下高效、安全、便捷地訪問資料，是一個既有理論意義又具應用價值的重要問題。

為了解決大資料、AI 等資料密集型應用在雲原生計算儲存分離場景下，存在的資料訪問延時高、聯合分析難、多維管理雜等痛點問題，南京大學 PASALab、阿里巴巴、Alluxio 在 2020 年 9 月份聯合發起了開源專案 Fluid。Fluid 本質上是一個雲原生環境下的資料密集型應用的高效支撐平臺。本文將向大家介紹 Fluid 專案是如何將資料密集型應用更高效地執行於 K8s 環境中的。

# 專案背景簡介
## 1. 技術發展背景
過去十年**雲端計算、大資料、人工智慧等技術**發展突飛猛進。

- **雲端計算平臺領域**：以 Docker、Kubernetes 為代表的容器及其編排的雲原生技術，在應用服務部署自動化運維的浪潮當中得到了長足的發展。
- **大資料處理領域**：以 Hadoop、Spark、Alluxio 為代表的大資料平行計算與分散式儲存技術，在眾多行業領域大資料處理與儲存的應用落地中幾乎形成了主流生態。
- **人工智慧框架領域**：PyTorch、Tensorflow、Caffe 等知名 AI 訓練框架，在廣大 AI 應用開發者反覆使用和參與當中，發展日益成熟。

其中，大資料應用和 AI 應用通常需要圍繞大規模資料展開計算分析，是典型的資料密集型應用，而云計算平臺得益於其計算成本和易於規模擴充套件的優勢，以及容器化在高效部署和敏捷迭代方面的長處，吸引了越來越多的資料密集型應用在上面部署執行。

大資料應用、AI、雲端計算三者的融合正在成為下一個重要的發展趨勢。Gartner 預測，到 2023 年，70% 以上的 AI workloads 都將以應用容器化的方式部署執行，然後透過 Serverless 程式設計模型在雲原生環境下進行構建。Spark 3.0.1 版本也開始支援 Kubernetes scheduler，擁抱雲原生環境。

- 詳情見 Gartner 報告：

[_https://www.gartner.com/en/conferences/emea/data-analytics-switzerland/featured-topics/topic-ai-machine-learning_](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_](https://spark.apache.org/docs/latest/running-on-kubernetes.html)

## 2. 面臨的問題
從使用者的實際體驗來看，現有云原生編排框架對資料密集型應用支援不夠友好，主要體現在執行效率低下和資料管理複雜兩方面。

![1.jpg](https://ucc.alicdn.com/pic/developer-ecology/7d525384c4f249d4a014db9c74ac04d8.jpg)

**執行效率低下**：如上圖所示，訓練一個 RestNet50 神經網路，如果基於本地記憶體執行，大概每秒鐘能訓練近 1 萬張圖片；然而，在雲原生環境下執行，基於 Cloud Storage 儲存架構每秒訓練的圖片只能達到約 3000 張/秒，效能下降比較明顯。

**資料管理複雜**：**資料版本的多變、資料介面的多樣、資料型別的抽象以及資料儲存的異構**，都給雲原生環境下面向資料密集型應用支撐帶來了挑戰。

## 3. 問題的原因分析
雲原生環境和資料密集處理框架在設計理念和機制上存在天然分歧，這兩部分技術的早先產生和發展過程是相互獨立的。我們可以看到，為了兼顧資源擴充套件的靈活性和使用成本，**計算和儲存分離**的基本架構在雲原生環境中大行其道；反觀之，以大資料!

[2.jpg](https://ucc.alicdn.com/pic/developer-ecology/5a37f1e39dd24a6ea17f8d9d367197f7.jpg)

和 AI 訓練為代表的資料密集型應用框架，為了減少資料傳輸，設計理念更多需要考慮**資料本地化架構**，兩者在設計上存在分歧。

另外，我們發現在雲原生環境中，應用通常是以無狀態（stateless）微服務化的方式進行部署，透過 FaaS（Function as a Service）方式串聯。而在資料密集型框架應用中，是以資料抽象為中心開展，並進行任務分配執行，比如在 Spark 裡都是圍繞 RDD 構建整個大資料處理應用，中間加上運算元。然而，無狀態微服務並不是以資料為中心，這也存在設計上的分歧。

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/614f93c0266c4a42a8c5a87aae019b4b.jpg)

以上問題導致以 Kubernetes 為代表的雲原生編排框架對於資料密集型應用，尤其是 AI 和大資料應用的支援還不夠友好，具體體現在前面所述的執行效率低下、資料操作管理複雜等方面。

我們縱觀 Fluid 出現之前的雲原生基金會（CNCF）全景圖，涵蓋了從應用交付 - 運維管理 - 底層儲存的方方面面，但是缺少資料高效支撐元件這塊重要拼圖（注：Fluid近期剛進入CNCF 全景圖，側面反映本文理念得到了認可）。然而，這塊拼圖的缺失，就會造成大資料密集型應用在雲原生環境下執行時，面臨資料訪問低效、資料隔離性弱、多資料來源聯合訪問複雜方面的技術挑戰。

## 4. 雲原生環境下的資料支撐挑戰
**具體地，雲原生環境下資料支撐的挑戰主要分為三個方面**：

- 第一：**雲平臺計算儲存分離架構導致資料訪問延時高**。為了監控資源靈活性滿足本地無依賴的要求，雲原生應用大多采用計算儲存分離架構。但是從訪問效率的角度來看，要求用雲網路傳輸頻寬，當資料密集型應用在雲上執行時，會造成資料訪問瓶頸、效能下降。
- 第二：**混合雲場景下跨儲存系統的聯合分析困難**。大多公司/組織通常基於不同儲存管理資料支撐多樣化應用，具備其各自的特點。Ceph、GlusterFS、HDFS 都會被廣泛使用，資料也通常會散落在這些異構儲存當中。然而，當需要聯合資料進行綜合性分析時，會增加資料移動成本，必然導致在雲原生環境下需要面對網路費用、等待延時、人工操作等比較複雜的問題。
- 第三：**雲環境中資料安全治理與多維度管理複雜**。資料是很多公司的生命線，資料洩露、誤操作、生命週期管理不當都會造成巨大損失。如何在雲原生環境中保障資料的隔離，保護好使用者的資料生命週期，都存在較大挑戰。

## 5. Kubernetes 生態中缺失的一塊抽象
綜上所述，我們可以總結出一種現象：Kubernetes 生態中目前缺少資料密集型應用高效支撐的這塊拼圖。現有 Kubernetes 環境能對很多資源進行很好的抽象，包括將資源物件計算抽象成 Pod、將儲存抽象成了 PV/PVC、將網路抽象成了 Service。雲原生領域還有一些儲存抽象主要面向資料持久化進行工作，提供物件和檔案的持久化儲存管理。但這些軟體的功能缺乏以應用為中心的資料抽象及相關生命週期管理。

## 6. 商店購物模式演變的聯想
為了更好地理解這些問題，我們可以做一些聯想性的思考。如下圖所示，引入商品購物模式，我們將**商品、超市、客戶**類比為**資料、儲存、應用**。

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/dde3ca4b4c5f46e4b818cde262569e24.jpg)

- **商品**和**資料**都會被消費，商品會被消費者購買掉，資料會被應用讀走，兩者有一定類似性。

- **超市**和**儲存**類似，都起到貯藏與供應的功能。商品平時會貯藏在超市的貨架上，當購買時扮演到供應的角色；對於儲存而言，我們平時貯藏的資料都會被持久化到儲存裝置裡，當應用需要時提供給使用者。

- **客戶**和**應用**類似，客戶會到商店消費購買商品。類似的，應用會到儲存讀取資料。

**商品、超市（商鋪） 、客**戶模式，在過去幾千年裡發展得非常成熟，非常穩定。直到 2000 年之後發生了顛覆性的變化，這就是電商的產生。電商發明了線上購物模式，其特點體現在不再以店鋪為中心而是以客戶為中心，商品貯藏在倉庫，客戶可以線上上虛擬商鋪挑選商品，最後由現代化物流將商品交付到客戶，交易過程**高效便捷、交易量更大**。商品直接放在倉庫裡，倉庫可以進行規範化、獨立化管理，之後客戶到電商平臺上購買貨物，會非常便捷、方便。客戶不需要到店鋪，在地鐵上、車上、辦公室、家裡都可以用手機、電腦進行購物，而且不會存在商品尋找低效的情況，因為客戶是在網際網路上購物，都可以透過檢索方式查詢海量商品；線上購物的另一個優勢是交易頻次變得更高，交易量變得更大；客戶也不需要必須去店裡提貨，快遞可以直接送貨上門，非常方便。

![5.jpg](https://ucc.alicdn.com/pic/developer-ecology/969b3d1bbe6e455080504284d0f8522e.jpg)

電商模式的成功有很多因素，其中有兩大因素非常關鍵，一是如支付寶這樣的第三方數字化支付工具的出現，二是如菜鳥這樣專業化的物流系統產生，構建起四通八達的物流網路，使快速的商品寄送模式得以實現。反觀回到現在計算機系統中，在現代雲架構下，資料貯存在雲端儲存系統中，資料密集型應用也以pod等各種各樣資源描述符的方式在雲原生環境下執行，但中間卻缺乏一個高效的資料交付、資料遞送的方式。也就是說，在雲原生架構下面，資料貯藏在雲端儲存系統當中，應用還是根據需要去訪問資料，但由於類似的資料**“物流系統”的缺失，導致資料密集型應用消費訪問資料在雲平臺上比較低效**。

![6.jpg](https://ucc.alicdn.com/pic/developer-ecology/b64f0e7a96474951aa9b36a3d845d061.jpg)

# Fluid 核心理念
基於以上的分析，以及從觀察中得到的聯想，下面來介紹 Fluid 的核心理念。

## 1. Fluid 扮演雲原生的“資料物流系統”角色
![7.jpg](https://ucc.alicdn.com/pic/developer-ecology/bd02d08f88d341eaa8b46984d988d800.jpg)

我們可以將 Fluid 所扮演角色理解為雲原生環境下“資料物流系統”。回顧一下，在早先的大資料平臺中，資料的訪問儘量都是透過本地化進行。當使用者寫一個 MapReduce Job，Job 裡包含很多 Task， 其中關注比較多的就是 MapTask 處理資料時是儘量將 Task 排程到使用者要處理的資料所在的節點上執行。這種情況下，當使用者訪問資料時，儘管該資料是在 HDFS 這個分散式系統中，但本質上相當於從分散式系統中的本地節點上獲取，我們稱之為 Data Fetch。

隨著大資料生態系統的迅速發展，其上的應用框架變得越來越多，底層儲存系統也變得越來越豐富，各種上層應用要訪問不同種類、多樣化系統的痛點越來越明顯，於是出現了 Alluxio 這樣一個優秀的開源專案，來統一管理底層不同儲存系統，為上層提供統一化的標準介面，對上層應用遮蔽不同儲存的差異。而且 Alluxio 提供記憶體快取，加速資料訪問。這個過程就解耦了本地化的情況，儲存就可以實現分離。這種分離架構在部署好之後通常還是靜態的，實現從 Data Fetch 變成 Data Access 的過程。

Fluid 是在 Alluxio 基礎之上，在雲原生環境的排程層面上進行進一步的研究和擴充，希望獲取雲原生環境下資料節點以及應用的動態變化資訊，讓這一類靜態的快取等中介軟體動態、靈活地調動起來，從而讓應用靈活性變得更強，實現資料智慧化遞送到應用的效果，即動態彈性（Data Delivery） 。

在進行專案設計時，我們希望 Fluid 從視角、思路、理念三個層次帶來一些革新：

- **新視角**：從雲原生資源排程結合與資料密集型處理兩個方面，重新綜合審視雲原生場景的資料抽象與支撐訪問。
- **新思路**：針對容器編排缺乏資料感知，資料編排缺乏對雲上架構變化的感知，提出了協同編排、多維管理、智慧感知的一系列理念和創新方法；從而形成一套雲原生環境下資料密集型應用的高效支撐平臺。
- **新理念**：透過 Fluid 這個專案，希望**讓資料可以像流體一樣在雲平臺中**、在資源編排層和資料處理層之間能夠靈活高效地被訪問、轉換和管理。

## 2. 核心理念
簡單來說，Fluid 的核心理念，可以分為“一個抽象”和“兩個編排”。

首先在雲原生環境裡，抽象出了資料集的概念，它能夠提供一個對底層儲存的包裝，對上層也能提供各種各樣的支撐和訪問能力，從而透過 API 的方式來簡單地在 K8s 下實現對資料的操作。

在這個基礎之上，Fluid 提供了兩個編排的能力：

首先是對於資料集進行編排，具體是指基於容器排程管理的資料進行編排。傳統的方式只對資料本身進行管理，而 Fluid 的資料集編排則轉為對承載資料的引擎進行編排和管理。透過對資料引擎進行合理的擴容、縮容和排程操作，和資料引擎的互動，從而實現對資料的遷移、快取以及資料在 K8s 平臺下靈活排程的管理和變化。

第二個編排是對使用和消費這類資料集的應用進行編排。我們需要處理這些應用的排程，在排程時儘量使其感知快取資料集，這樣就可以在這排程應用的時候合理選擇節點，從而高效地進行相關計算。

總結來講，Fluid 具有以下三大功能：

### **1）提供雲平臺資料集抽象的原生支援**

資料密集型應用所需基礎支撐能力功能化，實現資料高效訪問並降低多維成本。

### **2）基於容器排程管理的資料集編排**

透過資料集快取引擎與 Kubernetes 容器排程和擴縮容能力的相互配合，實現資料集可遷移性。

### **3）面向雲上資料本地化的應用排程**

Kubernetes 排程器透過與快取引擎互動獲得節點的資料快取資訊，將使用該資料的應用以透明的方式排程到包含資料快取的節點，最大化快取本地性的優勢。

# Fluid 架構功能
## 1. Fluid 系統架構

![8.jpg](https://ucc.alicdn.com/pic/developer-ecology/6c977dd887bd41dd8ddd01ae68a8de85.jpg)

Fluid 是構建在 K8s 上的系統，對原生 K8s 具備良好的相容性，無需修改任意程式碼。如上圖所示，使用者需要定義兩個 CRD，分別是 Dataset 和 Runtime。Dataset 是資料集的通用定義，這是我們提供的 K8s 資源物件，需要寫 YAML 檔案來定義資料集從哪兒來，以及想要放到哪兒去；Runtime 是儲存這些資料集的快取引擎，目前使用的是開源的分散式快取系統 Alluxio。這裡要注意的是 Dataset 和 Runtime 定義的時候，它通常是要具有相同 Namespace，從而實現很好的繫結。

Fluid Operator 是 Fluid 專案的核心，它分為兩部分。第一部分是 Fluid-controller-manager，包含很多 Controller；另一部分為 Fluid-Scheduler。這兩個元件完成了編排排程的操作。Fluid-controller-manager 做的工作就是對資料進行編排，包括三個 Controller。這三個 Controller 從邏輯上它們是獨立的，可以去做單程式。但為了降低複雜性，很多 Controller 的功能編譯時被合併成一個和多個可執行檔案，所以在真正執行起來時，也是一個程式。

- 資料集的 Dataset Controller 負責整個資料集的生命週期管理，包括資料集的建立，以及要和哪個 Runtime 進行繫結。
- Runtime Controller 負責資料集如何在雲原生平臺上被排程與快取，應該放在哪些節點上，要有多少副本。
- Volume Controller：由於 Fluid 是基於 K8s 執行，因此需要和 K8s 進行對接，這裡我們使用的是 PVC（資料持久卷）協議，這是 K8s 本地儲存棧的協議，使用非常廣泛，Fluid 與 PVC 的對接非常流暢。

最下面為 Cache Runtime Engine，是真正完成快取資料具體工作的地方。
圖中右邊部分的 Fluid-Scheduler 主要是基於定義好的 dataset、runtime controller 等具體資訊，對 K8s 的排程器做一些擴充套件。這裡麵包含兩個 Plugin：

- Cache co-locality Plugin：Cache co-locality Plugin 做的事就是結合前面資料編排的資訊，把應用排程到最合適的節點上，然後儘量能夠讓使用者去讀到快取節點裡面的資訊。
- Prefetch Plugin：當使用者叢集還沒有快取流入資料情況之下，且知道應用肯定是要讀哪一類資料時，尤其在應用排程和編排執行之前，可以做 Prefetch 的排程，將這個資料從最底下的儲存卷當中快取到資料快取裡面，可以手動觸發。

再往下就是標準 K8s。透過 K8s 可以對接底層不同的儲存，具體的對接方式可透過 K8s 的 PVC 完成。由於透過 Alluxio 進行了抽象，可以直接支援 Alluxio 本身支援的儲存型別。

## 2. Fluid 的功能概念
Fluid 不是全儲存加速和管理，而是以應用為中心資料集加速和管理。

**三個重要概念**：

- Dataset：資料集是邏輯上相關的一組資料的集合，不同資料集的特性和最佳化都是不一樣的，所以對於資料集是要分開管理的，一致的檔案特性，會被同一運算引擎使用。
- Runtime：真正實現資料集安全性，版本管理和資料加速等能力的執行引擎的介面，包括如何建立、生命週期如何管理等等，定義了一系列生命週期的方法。
- AlluxioRuntime：來自 Alluxio 社群，是支撐 Dataset 資料管理和快取的執行引擎高效實現。

透過以上概念與架構，實現了以下功能：

### **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.

透過 K8s 提供了這個很好的可觀測性，我們能夠知道我們的快取容量和當前狀態，進一步地我們就可以很靈活的去遷移和擴充套件快取，然後按需增加快取容量。並且在擴充套件和遷移過程當中會充分考慮 co-locality，即本地性。將資料和計算在編排和排程時放在一起，從而實現加速目的。

### **2）資料卷介面，統一訪問不同儲存**
從對接上面，支援資料卷介面，從而統一訪問不同的儲存，且 K8s 的任何資料卷都可以包裝成 Fluid-Dataset 來進行使用加速。

### **3）隔離**
隔離機制使得對資料集的訪問可以在不同儲存加速間進行隔離，並且實現許可權控制管理。

## 3. 如何使用 Fluid
![9.jpg](https://ucc.alicdn.com/pic/developer-ecology/b2720c00e88a4645882faac3bd19de96.jpg)

以上圖為例，使用者在使用場景中需要使用來自兩個不同地方的資料，假設一個來自阿里雲，另外一個是本地儲存 Ceph。在 Fluid 裡面我們可以很容易地描述這樣的資料集，透過建立一個自定義 K8s 資源物件 Dataset，對應的 mountPoint 可以載入兩個，分別是阿里雲和 Ceph。

建立好就可以執行，這個過程中 Fluid 會建立一個 Dataset，並自動將它變成一個 PVC。當使用者需要用這個資料時建立一個 Pod，以 PVC 掛載的方式，將 Dataset 關聯到執行中的 Pod 中對資料進行訪問。甚至 Pod 根本都不知道 PVC 後臺執行的是 Fluid，而不是其他的儲存，例如 NFS。整個過程和背後的原理對使用者都是透明的，這使得對遺留程式的對接非常友好。

## 4. 如何檢查和觀測 dataset 狀態
![10.jpg](https://ucc.alicdn.com/pic/developer-ecology/309cb0e8823c4db1b4f5f03ad9ff7ae1.jpg)

當真正執行起來時有很多可觀測的東西，我們在 Dataset CRD 裡定義了很多 metrics。如上圖所以，快取總容量為 200GB，實際需要的容量為 84.29GB，無需擴容，後續可根據實際需求靈活擴容。透過這個工具，使用者可以有效查詢儲存容量與使用量，從而實現可觀測性。

## 5. 根據資料集本地性排程作業
![11.jpg](https://ucc.alicdn.com/pic/developer-ecology/e46c7e66fd6a4de7b6583e2da18dd835.jpg)

對於使用資料集應用的編排也很容易，只需要使用 PVC 模式把 Fluid 資料集掛載到應用當中，然後 K8s 排程器就會和 Fluid 排程器進行互動。

如上圖例子所示，掛載之後進行互動，根據排程策略安排 Pod 在對應的節點上執行。K8s 排程器和 Fluid 排程器互動時會看見三個節點，其中有兩個有 Alluxio 快取節點。我們知道經典的 K8s 排程包括兩個很重要的階段，一個是過濾階段，另一個是優選階段。在過濾階段就會將第三個節點直接過濾掉，而在優選階段可以利用一些內建優選的策略來選擇更合適的節點，例如快取空間量大小，這裡面有很多未來可以擴充最佳化實現的空間。

# Fluid 效能評估
![12.jpg](https://ucc.alicdn.com/pic/developer-ecology/d8037ed39f7e4bec9a64aab9c4a1563a.jpg)

如上圖所示，我們發現卡數量越來越多的時候，使用 Fluid 會帶來巨大的效能提升。這其中的本質原因是當 GPU 數量變得越來越多（或 GPU 算力越來越強）時，訪問大規模資料已經成為整個訓練任務的瓶頸。從上圖是訓練結果來看，使用 Fluid 訓練的端到端的效能最後提升約1倍，減少成本並提升了使用者體驗。

![13.jpg](https://ucc.alicdn.com/pic/developer-ecology/411e49307bed43ff8137f174f3c49c71.jpg)

我們在專案 github 主頁上提供了許多 Demo 演示，具體詳情可以點選觀看影片：[https://developer.aliyun.com/live/246068](https://developer.aliyun.com/live/246068)，或參見：[_https://github.com/fluid-cloudnative/fluid#qucik-demo_](https://github.com/fluid-cloudnative/fluid#qucik-demo)

# 加入 Fluid 社群
想要了解更多關於 Fluid 的資訊，請訪問 Fluid 專案 Github 地址或檢視 Fluid 專案主頁。也歡迎大家加入 Fluid 社群交流釘釘群，與更多使用者和開發者深入交流專案技術及其實際使用場景。

- Fluid 專案 GitHub 地址：[_https://github.com/fluid-cloudnative/fluid_](https://github.com/fluid-cloudnative/fluid)
- Fluid 專案主頁：[_http://pasa-bigdata.nju.edu.cn/fluid/index.html_](http://pasa-bigdata.nju.edu.cn/fluid/index.html)

Fluid — 雲原生環境下的高效“資料物流系統”

相關文章