Fluid — 雲原生環境下的高效「數據物流系統」

做者 | 顧榮  南京大學 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 項目 Github 地址或查看 Fluid 項目主頁。

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