簡介： 爲了解決大數據、AI 等數據密集型應用在雲原生計算存儲分離場景下，存在的數據訪問延時高、聯合分析難、多維管理雜等痛點問題，南京大學 PASALab、阿里巴巴、Alluxio 在 2020 年 9 月份聯合發起了開源項目 Fluid。Fluid 本質上是一個雲原生環境下的數據密集型應用的高效支撐平臺。本文將向大家介紹 Fluid 項目是如何將數據密集型應用更高效地運行於 K8s 環境中的。
作者 | 顧榮 南京大學 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 報告：
- Spark3.0.1 runs on K8s：
https://spark.apache.org/docs/latest/running-on-kubernetes.html
2. 面臨的問題
從用戶的實際體驗來看，現有云原生編排框架對數據密集型應用支持不夠友好，主要體現在運行效率低下和數據管理複雜兩方面。
運行效率低下：如上圖所示，訓練一個 RestNet50 神經網絡，如果基於本地內存運行，大概每秒鐘能訓練近 1 萬張圖片；然而，在雲原生環境下運行，基於 Cloud Storage 存儲架構每秒訓練的圖片只能達到約 3000 張/秒，性能下降比較明顯。
數據管理複雜：數據版本的多變、數據接口的多樣、數據類型的抽象以及數據存儲的異構，都給雲原生環境下面向數據密集型應用支撐帶來了挑戰。
3. 問題的原因分析
雲原生環境和數據密集處理框架在設計理念和機制上存在天然分歧，這兩部分技術的早先產生和發展過程是相互獨立的。我們可以看到，爲了兼顧資源擴展的靈活性和使用成本，計算和存儲分離的基本架構在雲原生環境中大行其道；反觀之，以大數據!
和 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
- 社區交流釘羣：
本文爲阿里雲原創內容，未經允許不得轉載。