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

1、什麼是 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 與大數據雲原生應用提供一層高效便捷的數據抽象，將數據從存儲抽象出來從而達到如下功能：

1、通過數據親和性調度和分佈式緩存引擎加速，實現數據和計算之間的融合，從而加速計算對數據的訪問。

2、將數據獨立於存儲進行管理，並且通過 Kubernetes 的命名空間進行資源隔離，實現數據的安全隔離。

3、將來自不同存儲的數據聯合起來進行運算，從而有機會打破不同存儲的差異性帶來的數據孤島效應。

2、什麼是 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 校驗等雲上數據安全功能。

3、JindoRuntime 的優勢

JindoRuntime 提供對 Aliyun OSS 對象存儲服務的訪問和緩存加速能力，並且利用 FUSE 的 POSIX 文件系統接口實現可以像本地磁盤一樣輕鬆使用 OSS 上的海量文件，具有以下特點：

1、性能卓越

OSS的讀寫性能突出：深度結合 OSS 進行讀寫效率和穩定性的增強，通過 native 層優化對 OSS 訪問接口，優化大數據訪問性能，特別是小文件讀寫
分佈式緩存策略豐富：支持單TB級大文件緩存、元數據緩存策略等。在大規模AI訓練和數據湖場景實測中有突出的性能優勢。

2、安全可靠

認證安全：支持阿里雲上 STS 免密訪問和K8s原生的祕鑰加密
數據安全：checksum 校驗、客戶端數據加密等安全策略，保護雲上數據安全和用戶信息等。

3、簡單易用

支持原生 k8s 環境，利用自定義資源定義，對接數據卷概念。使用部署流程簡單，可以開箱即用。

4、輕量級

底層基於 c++ 代碼，整體結構輕量化，各種 OSS 訪問接口額外開銷較小。

4、JindoRuntime 性能怎麼樣

我們使用 ImageNet 數據集基於 Kubernetes 集羣並使用 Arena 在此數據集上訓練 ResNet-50 模型，基於 JindoFS 的 JindoRuntime 在開啓本地緩存的情況下性能大幅度優於開源 OSSFS，訓練耗時縮短了76%，該測試場景會在後續文章中進行詳細介紹。

5、如何快速上手使用 JindoRuntime

使用 JindoRuntime 流程簡單，在準備好基本 k8s 和 OSS 環境的條件下，您只需要耗費10分鐘左右時間即可部署好需要的 JindoRuntime 環境，您可以按照下面的流程進行部署。

1、創建命名空間

kubectl create ns fluid-system

2、下載 fluid-0.5.0.tgz

3、使用 Helm 安裝 Fluid

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

4、查看 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的數量相同。

5、創建 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

6、創建應用容器體驗加速效果

您可以通過創建應用容器來使用 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

7、環境清理

1、刪除應用和應用容器

2、刪除 JindoRuntime

kubectl delete jindoruntime hadoop

3、刪除 dataset

kubectl delete dataset hadoop

以上通過一個簡單的例子完成 JindoFS on Fluid 的入門體驗和理解，並最後進行環境的清理，更多Fluid JindoRuntime 的功能使用後續文章會進行詳細介紹

作者：

王濤，花名揚禮，阿里巴巴計算平臺事業部 EMR 開發工程師，目前從事開源大數據存儲計算方面的開發和優化工作。

車漾，花名必嘫，阿里巴巴雲原生應用平臺高級技術專家，從事 Kubernetes 和容器相關產品的開發。尤其關注利用雲原生技術構建機器學習平臺系統，是 GPU 共享調度的主要作者和維護者。

原文鏈接

本文爲阿里雲原創內容，未經允許不得轉載。

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

1、什麼是 Fluid

2、什麼是 JindoRuntime

3、JindoRuntime 的優勢

4、JindoRuntime 性能怎麼樣

5、如何快速上手使用 JindoRuntime

6、創建應用容器體驗加速效果

7、環境清理

鯤鵬平臺的銀河麒麟，修復音頻

定時清理服務器上log文件，清理docker日誌文件

安裝筆記本應用商店的pycharm，再安排pandas等模塊，說是沒有打包工具?

智能測試持續加碼，大模型引領軟件測試新生態

DevExpress Office File API中文教程 - 如何用OpenAI模型增強Office文檔可訪問性？

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結