什麼是 Fluid
Fluid 是一個開源的 Kubernetes 原生的分散式資料集編排和加速引擎，主要服務於雲原生場景下的資料密集型應用，例如大資料應用、AI 應用等。透過 Kubernetes 服務提供的資料層抽象，可以讓資料像流體一樣在諸如 HDFS、OSS、Ceph 等儲存源和 Kubernetes 上層雲原生應用計算之間靈活高效地移動、複製、驅逐、轉換和管理。而具體資料操作對使用者透明，使用者不必再擔心訪問遠端資料的效率、管理資料來源的便捷性，以及如何幫助 Kuberntes 做出運維排程決策等問題。使用者只需以最自然的 Kubernetes 原生資料卷方式直接訪問抽象出來的資料，剩餘任務和底層細節全部交給 Fluid 處理。
Fluid 專案當前主要關注資料集編排和應用編排這兩個重要場景。資料集編排可以將指定資料集的資料快取到指定特性的 Kubernetes 節點，而應用編排將指定該應用排程到可以或已經儲存了指定資料集的節點上。這兩者還可以組合形成協同編排場景，即協同考慮資料集和應用需求進行節點資源排程。
然後介紹 Fluid 中 Dataset 的概念，資料集是邏輯上相關的一組資料的集合，會被運算引擎使用，比如大資料的 Spark，AI 場景的 TensorFlow，而關於資料集智慧的應用和排程會創造工業界的核心價值。Dataset 的管理實際上也有多個維度，比如安全性，版本管理和資料加速。
我們希望從資料加速出發，對於資料集的管理提供支援。在 Dataset 上面,我們透過定義 Runtime 這樣一個執行引擎來實現資料集安全性，版本管理和資料加速等能力，Runtime 定義了一系列生命週期的介面，可以透過實現這些介面來支援資料集的管理和加速，目前 Fluid 中支援的 Runtime 有 AlluxioRuntime 和 JindoRuntime 兩種。Fluid 的目標是為 AI 與大資料雲原生應用提供一層高效便捷的資料抽象，將資料從儲存抽象出來從而達到如下功能：
透過資料親和性排程和分散式快取引擎加速，實現資料和計算之間的融合，從而加速計算對資料的訪問。將資料獨立於儲存進行管理，並且透過 Kubernetes 的名稱空間進行資源隔離，實現資料的安全隔離。將來自不同儲存的資料聯合起來進行運算，從而有機會打破不同儲存的差異性帶來的資料孤島效應。什麼是 JindoRuntime如果要了解 Fluid 的 JindoRuntime，先要介紹 JindoFS。它是 JindoRuntime 的引擎層。
JindoFS 是阿里雲針對 OSS 開發的自研大資料儲存最佳化引擎，完全相容 Hadoop 檔案系統介面，給客戶帶來更加靈活、高效的計算儲存方案，目前已驗證支援阿里雲 EMR 中所有的計算服務和引擎：Spark、Flink、Hive、MapReduce、Presto、Impala 等。JindoFS 有兩種使用模式，塊儲存（Block）模式和快取（Cache）模式。Block 模式將檔案內容以資料塊的形式存放在 OSS 上並在本地可選擇使用資料備份來進行快取加速，使用本地的 namespace 服務管理元資料，從而透過本地元資料以及塊資料構建出檔案資料。Cache 模式將檔案儲存在 OSS 上，該模式相容現有的 OSS 檔案系統，使用者可以透過 OSS 訪問原有的目錄結構以及檔案，同時該模式提供資料以及元資料的快取，加速使用者讀寫資料的效能。使用該模式的使用者無需遷移資料到 OSS，可以無縫對接現有 OSS 上的資料，在元資料同步方面使用者可以根據不同的需求選擇不同的元資料同步策略。
在 Fluid 中，JindoRuntime 也是使用 JindoFS 的 Cache 模式進行遠端檔案的訪問和快取，如您需要在其他環境單獨使用 JindoFS 獲得訪問 OSS 的能力，您也可以下載我們的 JindoFS SDK 按照使用文件進行部署使用。JindoRuntime 來源於阿里雲 EMR 團隊自研 JindoFS 分散式系統，是支撐 Dataset 資料管理和快取的執行引擎實現。Fluid 透過管理和排程 Jindo Runtime 實現資料集的可見性、彈性伸縮、資料遷移、計算加速等。在 Fluid 上使用和部署 JindoRuntime 流程簡單、相容原生 K8s 環境、可以開箱即用。深度結合物件儲存特性，使用 Navite 框架最佳化效能，並支援免密、checksum 校驗等雲上資料安全功能。
JindoRuntime 的優勢JindoRuntime 提供對 Aliyun OSS 物件儲存服務的訪問和快取加速能力，並且利用 FUSE 的 POSIX 檔案系統介面實現可以像本地磁碟一樣輕鬆使用 OSS 上的海量檔案，具有以下特點：
1. 效能卓越OSS 的讀寫效能突出：深度結合 OSS 進行讀寫效率和穩定性的增強，透過 native 層最佳化對 OSS 訪問介面，最佳化冷資料訪問效能，特別是小檔案讀寫。分散式快取策略豐富：支援單 TB 級大檔案快取、元資料快取策略等。在大規模 AI 訓練和資料湖場景實測中有突出的效能優勢。2. 安全可靠認證安全：支援阿里雲上 STS 免密訪問和 K8s 原生的秘鑰加密。資料安全：checksum 校驗、客戶端資料加密等安全策略，保護雲上資料安全和使用者資訊等。3. 簡單易用支援原生 K8s 環境，利用自定義資源定義，對接資料卷概念。使用部署流程簡單，可以開箱即用。
4. 輕量級底層基於 c++ 程式碼，整體結構輕量化，各種 OSS 訪問介面額外開銷較小。
JindoRuntime 效能怎麼樣我們使用 ImageNet 資料集基於 Kubernetes 叢集並使用 Arena 在此資料集上訓練 ResNet-50 模型，基於 JindoFS 的 JindoRuntime 在開啟本地快取的情況下效能大幅度優於開源 OSSFS，訓練耗時縮短了 76%，該測試場景會在後續文章中進行詳細介紹。
如何快速上手使用 JindoRuntime使用 JindoRuntime 流程簡單，在準備好基本 K8s 和 OSS 環境的條件下，您只需要耗費 10 分鐘左右時間即可部署好需要的 JindoRuntime 環境，您可以按照下面的流程進行部署。
建立名稱空間kubectl create ns fluid-systemhelm install --set runtime.jindo.enabled=true fluid fluid-0.5.0.tgz$ kubectl get pod -n fluid-systemNAME READY STATUS RESTARTS AGEcsi-nodeplugin-fluid-2mfcr 2/2 Running 0 108scsi-nodeplugin-fluid-l7lv6 2/2 Running 0 108sdataset-controller-5465c4bbf9-5ds5p 1/1 Running 0 108sjindoruntime-controller-654fb74447-cldsv 1/1 Running 0 108s其中 csi-nodeplugin-fluid-xx 的數量應該與 K8s 叢集中節點 node 的數量相同。
建立 dataset 和 JindoRuntime在建立 dataset 之前，我們可以建立一個 secret 來儲存 OSS 的 fs.oss.accessKeyId 和 fs.oss.accessKeySecret 資訊，避免明文暴露出來，K8s 會對已建立的 secret 使用加密編碼，將 key 和 secret 資訊填入 mySecret.yaml 檔案中。
apiVersion: v1kind: Secretmetadata: name: mysecretstringData: fs.oss.accessKeyId: xxx fs.oss.accessKeySecret: xxx生成 secret：
kubectl create -f mySecret.yaml建立一個 resource.yaml 檔案裡面包含兩部分：
首先包含資料集及 ufs 的 dataset 資訊，建立一個 Dataset CRD 物件，其中描述了資料集的來源。接下來需要建立一個 JindoRuntime，相當於啟動一個 JindoFS 的叢集來提供快取服務。apiVersion: data.fluid.io/v1alpha1kind: Datasetmetadata: name: hadoopspec: mounts: - mountPoint: oss://<oss_bucket>/<bucket_dir> options: fs.oss.endpoint: <oss_endpoint> name: hadoop encryptOptions: - name: fs.oss.accessKeyId valueFrom: secretKeyRef: name: mysecret key: fs.oss.accessKeyId - name: fs.oss.accessKeySecret valueFrom: secretKeyRef: name: mysecret key: fs.oss.accessKeySecret---apiVersion: data.fluid.io/v1alpha1kind: JindoRuntimemetadata: name: hadoopspec: replicas: 2 tieredstore: levels: - mediumtype: HDD path: /mnt/disk1 quota: 100Gi high: "0.99" low: "0.8"kubectl create -f resource.yaml檢視 dataset 的情況：
$ kubectl get dataset hadoopNAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGEhadoop 210MiB 0.00B 180.00GiB 0.0% Bound 1h您可以透過建立應用容器來使用 JindoFS 加速服務，或者進行提交機器學習作業來進行體驗相關功能。
接下來，我們建立一個應用容器 app.yaml 來使用該資料集，我們將多次訪問同一資料，並比較訪問時間來展示 JindoRuntime 的加速效果。
apiVersion: v1kind: Podmetadata: name: demo-appspec: containers: - name: demo image: nginx volumeMounts: - mountPath: /data name: hadoop volumes: - name: hadoop persistentVolumeClaim: claimName: hadoop使用 kubectl 完成建立：
kubectl create -f app.yaml檢視檔案大小：
$ kubectl exec -it demo-app -- bash$ du -sh /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz 210M /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz進行檔案的 cp 觀察時間消耗了 18s：
$ time cp /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz /dev/nullreal 0m18.386suser 0m0.002ssys 0m0.105s檢視此時 dataset 的快取情況，發現 210MB 的資料已經都快取到了本地。
$ kubectl get dataset hadoopNAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGEhadoop 210.00MiB 210.00MiB 180.00GiB 100.0% Bound 1h為了避免其他因素（比如 page cache）對結果造成影響，我們將刪除之前的容器，新建相同的應用，嘗試訪問同樣的檔案。由於此時檔案已經被 JindoFS 快取，可以看到第二次訪問所需時間遠小於第一次。
kubectl delete -f app.yaml && kubectl create -f app.yaml進行檔案的複製觀察時間，發現消耗 48ms，整個複製的時間縮短了 300 倍。
$ time cp /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz /dev/nullreal 0m0.048suser 0m0.001ssys 0m0.046skubectl delete jindoruntime hadoopkubectl delete dataset hadoop以上透過一個簡單的例子完成 JindoFS on Fluid 的入門體驗和理解，並最後進行環境的清理，更多 Fluid JindoRuntime 的功能使用後續文章會進行詳細介紹。
Fluid 專案 GitHub 地址：https://github.com/fluid-cloudnative/fluid
Fluid 專案主頁：http://pasa-bigdata.nju.edu.cn/fluid/index.html