JindoRuntime是基於C++實現的支撐Dataset資料管理和緩衝的執行引擎，支援OSSObject Storage Service。Fluid通過管理和調度JindoRuntime實現資料集的可見度、Auto Scaling和資料移轉。本文介紹如何在ACS算力情境下使用Fluid實現資料加速訪問。
前提條件
已開通阿里雲Object Storage Service (OSS)服務。具體操作，請參見開通OSS服務。
已安裝ack-fluid組件，組件版本需要1.0.11-*及以上。具體操作，請參見使用Helm管理ACS應用。
已為ACS Pod開啟特權模式。
說明使用Fluid實現資料加速訪問需要開啟特權模式，請提交工單開啟。
操作步驟
步驟一：準備OSS Bucket的資料
執行以下命令，下載測試資料。
wget https://archive.apache.org/dist/spark/spark-3.0.1/spark-3.0.1-bin-hadoop2.7.tgz將下載的測試資料上傳到阿里雲OSS對應的Bucket中。
重要上傳到OSS的步驟以Alibaba Cloud Linux 3.2104 LTS 64位的ECS執行個體為例。其他動作系統的具體操作，請參見命令列工具ossutil命令參考和命令列工具ossutil 1.0。
輸入以下命令，建立名稱為
examplebucket的Bucket儲存空間。說明如果執行命令後返回
ErrorCode=BucketAlreadyExists，表示Bucket名稱已經存在。由於Bucket名稱在OSS範圍內必須全域唯一，請按實際情況修改examplebucket。ossutil64 mb oss://examplebucket預期輸出：
0.668238(s) elapsed以上輸出結果表明已成功建立
examplebucket。將下載的測試資料上傳到建立的
examplebucket中。ossutil64 cp spark-3.0.1-bin-hadoop2.7.tgz oss://examplebucket（可選）設定Bucket和資料的存取權限。具體內容，請參見許可權控制。
使用以下內容，建立
mySecret.yaml檔案。apiVersion: v1 kind: Secret metadata: name: mysecret stringData: fs.oss.accessKeyId: xxx fs.oss.accessKeySecret: xxx其中，
fs.oss.accessKeyId和fs.oss.accessKeySecret是用來訪問OSS的AccessKey ID和AccessKey Secret。執行以下命令，產生Secret。Kubernetes會對已建立的Secret使用加密編碼，避免將其明文暴露。
kubectl create -f mySecret.yaml
步驟二：建立Dataset和JindoRuntime
使用以下內容建立
resource.yaml檔案，內容包括：建立一個Dataset，描述遠端儲存資料集和UFS的資訊。
建立一個JindoRuntime，啟動一個JindoFS的叢集來提供快取服務。
說明通過
kubectl get pods --field-selector=status.phase=Running -n fluid-system命令可以檢查ack-fluid組件中的dataset-controller和jindoruntime-controller是否正常運行。本文樣本以CPU算力為主，若您想要加速LLM服務的載入速度，請確保建立叢集時選擇的可用性區域支援GPU資源。具體操作，請參見GPU型算力類型。
相關參數解釋如下表所示：
參數
說明
mountPoint
oss://<oss_bucket>表示掛載UFS的路徑，<oss_bucket>為OSS Bucket的名稱，例如：
oss://examplebucket。fs.oss.endpoint
OSS Bucket的Endpoint資訊，公網或私網地址均支援，例如：
oss-cn-beijing-internal.aliyuncs.com。更多資訊，請參見OSS地區和訪問網域名稱。replicas
表示建立JindoFS叢集的Worker數量。
mediumtype
表示緩衝類型。在建立JindoRuntime模板範例時，JindoFS暫時只支援
HDD/SSD/MEM中的一種緩衝類型。path
表示儲存路徑，暫時只支援單個路徑。當選擇
MEM作為緩衝時，需指定一個本地路徑來儲存Log等檔案。quota
表示緩衝最大容量，單位為Gi。
high
表示儲存容量上限大小。
low
表示儲存容量下限大小。
建立JindoRuntime和Dataset。
kubectl create -f resource.yaml查看JindoRuntime和Dataset的部署情況。
查看Dataset的部署情況。
kubectl get dataset hadoop預期輸出：
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE hadoop 209.74MiB 0.00B 4.00GiB 0.0% Bound 56s查看JindoRuntime的部署情況。
kubectl get jindoruntime hadoop預期輸出：
NAME MASTER PHASE WORKER PHASE FUSE PHASE AGE hadoop Ready Ready Ready 2m11s可以看到，Dataset和JindoRuntime已建立成功。
執行以下命令，查看PV和PVC的建立情況。PVC的名字即對應Dataset的名字。
kubectl get pv,pvc預期輸出：
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE persistentvolume/default-hadoop 100Pi ROX Retain Bound default/hadoop fluid <unset> 2m5s NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE persistentvolumeclaim/hadoop Bound default-hadoop 100Pi ROX fluid <unset> 2m5s
步驟三：建立Dataload預熱資料集
為了有效地提高資料載入速度，並確保資料處理邏輯正確，需要對Dataset進行預熱。
當OSS中的模型資料不會發生改變時，您可以使用以下內容建立dataload.yaml，用於進行一次性的預熱。
apiVersion: data.fluid.io/v1alpha1 kind: DataLoad metadata: name: hadoop spec: dataset: name: hadoop namespace: default loadMetadata: true如果OSS模型資料是動態更新的，則需要進行周期性的預熱。具體操作，請參見情境二：資料唯讀且後端儲存資料周期性規律變化。
以一次性預熱方式為例，建立DataLoad資源。
kubectl create -f dataload.yaml查看預熱狀態。
kubectl get dataload預期輸出：
NAME DATASET PHASE AGE DURATION hadoop hadoop Complete 92m 51s
步驟四：建立應用程式容器體驗加速效果
您可以通過建立應用程式容器，或者提交機器學習作業來體驗JindoFS加速服務。以下以建立一個應用程式容器多次訪問同一資料，並通過比較訪問時間來展示JindoRuntime的加速效果。
使用以下YAML檔案範例，建立名為app.yaml的檔案。
apiVersion: v1 kind: Pod metadata: name: demo-app labels: # ACS的掛載需要使用到Fluid Webhook的Sidecar注入，所以需要配置如下label alibabacloud.com/fluid-sidecar-target: acs spec: containers: - name: demo image: mirrors-ssl.aliyuncs.com/nginx:latest volumeMounts: - mountPath: /data name: hadoop resources: requests: cpu: 14 memory: 56Gi volumes: - name: hadoop persistentVolumeClaim: ## fluid dataset 名字 claimName: hadoop nodeSelector: type: virtual-kubelet tolerations: - key: virtual-kubelet.io/provider operator: Equal value: alibabacloud effect: NoSchedule執行以下命令，建立應用程式容器。
kubectl create -f app.yaml未使用JindoFS緩衝加速能力時，驗證檔案複製速度。
查看測試檔案大小。
kubectl exec -it demo-app -c demo -- du -sh /data/spark-3.0.1-bin-hadoop2.7.tgz預期輸出：
210M /data/spark-3.0.1-bin-hadoop2.7.tgz查看檔案的拷貝時間。
time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null預期輸出：
real 0m1.883s user 0m0.001s sys 0m0.041s上述輸出資訊顯示本次檔案拷貝時間消耗了1.883秒。
查看此時Dataset的緩衝情況。
kubectl get dataset hadoop預期輸出：
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE hadoop 209.74MiB 209.74MiB 4.00GiB 100.0% Bound 64m上述輸出資訊顯示
100.0%的資料都已經在JindoFS緩衝。刪除部署樣本應用Pod，再次查看檔案拷貝時間。
說明刪除應用Pod的目的是為了避免其他因素（例如：Page Cache）對結果造成影響，如果Pod中已經存在本機快取，拷貝操作會優先使用本機快取。
執行如下命令，查看檔案拷貝時間。
kubectl exec -it demo-app -c demo -- bash time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null預期輸出：
real 0m0.203s user 0m0.000s sys 0m0.047s可以看到，本次檔案拷貝時間消耗了0.203秒，比第一次縮短了約9倍。由於此時檔案已經被JindoFS緩衝，第二次訪問所需時間遠小於第一次。
重要本文中提供的拷貝時間資料僅為參考值，實際資料請以您的作業環境為準。
ACK Pro叢集彈ACS算力情境
本文基於ACS叢集，示範了使用JindoFS加速檔案複製的速度。您也可以在ACK託管叢集中使用ACS算力來完成本文中的操作。關於如何在ACK託管叢集中使用ACS算力，請參見通過ACK託管叢集Pro版使用ACS算力。
使用ACK託管叢集驗證本文內容，您只需要做以下調整：
ACK託管叢集同樣需要安裝ack-fluid組件。具體操作，請參見使用Helm簡化應用部署。
您需要使用以下內容來建立Dataset和JindoRuntime。
apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: hadoop spec: mounts: ## 如果是包含子目錄則 oss://<oss_bucket>/{oss_path} 配置 - mountPoint: oss://<oss_bucket> # 請按實際情況修改<oss_bucket> options: fs.oss.endpoint: <oss_endpoint> # 請按實際情況修改<oss_endpoint> name: hadoop path: "/" 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: 4 tieredstore: levels: - mediumtype: MEM path: /dev/shm volumeType: emptyDir quota: 48Gi high: "0.99" low: "0.95"與ACS叢集的差異：
由於ACS叢集使用的是虛擬節點，無法像ACK叢集那樣擴縮容節點數量，因此需要配置
.spec.placement: Shared和networkmode。Fluid worker需要依賴大頻寬環境來運行，因此ACS中需要通過指定配置大規格的資源來保證頻寬充足，如指定使用
compute-class: performance和通過resources配置確保使用的ACS Pod的頻寬滿足需求。