作者 | 顧榮? 南京大學?PASALab
（注：本文基于作者公開演講報告內容整理完成）
_來源 | _阿里巴巴云原生公眾號

得益于計算成本低、易于擴展、部署便捷、運維高效等多方面的優勢，云計算平臺吸引了越來越多的數據密集型應用在上面運行。如今，以 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

• Spark3.0.1 runs on K8s：

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

2. 面臨的問題

從用戶的實際體驗來看，現有云原生編排框架對數據密集型應用支持不夠友好，主要體現在運行效率低下和數據管理復雜兩方面。

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

數據管理復雜：數據版本的多變、數據接口的多樣、數據類型的抽象以及數據存儲的異構，都給云原生環境下面向數據密集型應用支撐帶來了挑戰。

3. 問題的原因分析

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

2.jpg

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

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

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

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

4. 云原生環境下的數據支撐挑戰

具體地，云原生環境下數據支撐的挑戰主要分為三個方面：

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

5. Kubernetes 生態中缺失的一塊抽象

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

6. 商店購物模式演變的聯想

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

• 商品和數據都會被消費，商品會被消費者購買掉，數據會被應用讀走，兩者有一定類似性。

• 超市和存儲類似，都起到貯藏與供應的功能。商品平時會貯藏在超市的貨架上，當購買時扮演到供應的角色；對于存儲而言，我們平時貯藏的數據都會被持久化到存儲設備里，當應用需要時提供給用戶。

• 客戶和應用類似，客戶會到商店消費購買商品。類似的，應用會到存儲讀取數據。

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

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

Fluid 核心理念

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

1. Fluid 扮演云原生的“數據物流系統”角色

我們可以將 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 系統架構

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

以上圖為例，用戶在使用場景中需要使用來自兩個不同地方的數據，假設一個來自阿里云，另外一個是本地存儲 Ceph。在 Fluid 里面我們可以很容易地描述這樣的數據集，通過創建一個自定義 K8s 資源對象 Dataset，對應的 mountPoint 可以加載兩個，分別是阿里云和 Ceph。

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

4. 如何檢查和觀測 dataset 狀態

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

5. 根據數據集本地性調度作業

對于使用數據集應用的編排也很容易，只需要使用 PVC 模式把 Fluid 數據集掛載到應用當中，然后 K8s 調度器就會和 Fluid 調度器進行交互。

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

Fluid 性能評估

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

我們在項目 github 主頁上提供了許多 Demo 演示，具體詳情可以點擊觀看視頻：https://developer.aliyun.com/live/246068，或參見：https://github.com/fluid-cloudnative/fluid#qucik-demo

加入 Fluid 社區

想要了解更多關于 Fluid 的信息，請訪問 Fluid 項目 Github 地址或查看 Fluid 項目主頁。也歡迎大家加入 Fluid 社區交流釘釘群，與更多用戶和開發者深入交流項目技術及其實際使用場景。

• Fluid 項目 GitHub 地址：https://github.com/fluid-cloudnative/fluid
• Fluid 項目主頁：http://pasa-bigdata.nju.edu.cn/fluid/index.html
• 社區交流釘群：

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。