擁抱雲原生，Fluid 結合 JindoFS：阿里雲 OSS 加速利器

做者| 王濤（揚禮）、車漾（必嘫）
來源|阿里巴巴雲原生公衆號

什麼是 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-system

• 下載 fluid-0.5.0.tgz

**

• 使用 Helm 安裝 Fluid

helm install --set runtime.jindo.enabled=true fluid fluid-0.5.0.tgz

• 查看 Fluid 的運行狀態

$ kubectl get pod -n fluid-system
NAME                                         READY   STATUS    RESTARTS   AGE
csi-nodeplugin-fluid-2mfcr                   2/2     Running   0          108s
csi-nodeplugin-fluid-l7lv6                   2/2     Running   0          108s
dataset-controller-5465c4bbf9-5ds5p          1/1     Running   0          108s
jindoruntime-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: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  fs.oss.accessKeyId: xxx
  fs.oss.accessKeySecret: xxx

生成 secret：

kubectl create -f mySecret.yaml

建立一個 resource.yaml 文件裏面包含兩部分：

1. 首先包含數據集及 ufs 的 dataset 信息，建立一個 Dataset CRD 對象，其中描述了數據集的來源。

2. 接下來須要建立一個 JindoRuntime，至關於啓動一個 JindoFS 的集羣來提供緩存服務。

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: hadoop
spec:
  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/v1alpha1
kind: JindoRuntime
metadata:
  name: hadoop
spec:
  replicas: 2
  tieredstore:
    levels:
      - mediumtype: HDD
        path: /mnt/disk1
        quota: 100Gi
        high: "0.99"
        low: "0.8"

1. mountPoint：oss://<oss_bucket>/<bucket_dir> 表示掛載 UFS 的路徑，路徑中不須要包含 endpoint 信息。

2. fs.oss.endpoint：oss bucket 的 endpoint 信息，公網或內網地址皆可。

3. replicas：表示建立 JindoFS 集羣的 worker 的數量。

4. mediumtype：JindoFS 暫只支持 HDD/SSD/MEM 中的一種。

5. path：存儲路徑，暫只支持一塊盤，當選擇 MEM 作緩存也須要一塊盤來存儲 log 等文件。

6. quota：緩存最大容量，單位 Gi。

7. high：水位上限大小 / low：水位下限大小。

kubectl create -f resource.yaml

查看 dataset 的狀況：

$ kubectl get dataset hadoop
NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
hadoop        210MiB       0.00B    180.00GiB              0.0%          Bound   1h

• 建立應用容器體驗加速效果

您能夠經過建立應用容器來使用 JindoFS 加速服務，或者進行提交機器學習做業來進行體驗相關功能。

接下來，咱們建立一個應用容器 app.yaml 來使用該數據集，咱們將屢次訪問同一數據，並比較訪問時間來展現 JindoRuntime 的加速效果。

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
spec:
  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/null

real  0m18.386s
user  0m0.002s
sys 0m0.105s

查看此時 dataset 的緩存狀況，發現 210MB 的數據已經都緩存到了本地。

$ kubectl get dataset hadoop
NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
hadoop   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/null

real  0m0.048s
user  0m0.001s
sys 0m0.046s

• 環境清理

  • 刪除應用和應用容器

  • 刪除 JindoRuntime

kubectl delete jindoruntime hadoop

• 刪除 dataset

kubectl 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

做者簡介

王濤，花名揚禮，阿里巴巴計算平臺事業部 EMR 開發工程師，目前從事開源大數據存儲計算方面的開發和優化工做。車漾，花名必嘫**，阿里巴巴雲原生應用平臺高級技術專家，從事 Kubernetes 和容器相關產品的開發。尤爲關注利用雲原生技術構建機器學習平臺系統，是 GPU 共享調度的主要做者和維護者。