Container Compute Service:Accelerate data access with Fluid

Step 1: Prepare data in an OSS bucket

1. Run the following command to download the test data.

   wget https://archive.apache.org/dist/spark/spark-3.0.1/spark-3.0.1-bin-hadoop2.7.tgz

2. Upload the downloaded test data to a bucket in OSS.

   Important

   This example uses an ECS instance running Alibaba Cloud Linux 3.2104 LTS 64-bit to show how to upload data to OSS. For instructions on other operating systems, see ossutil quick start and ossutil 1.0.

   1. Install ossutil.

   2. Run the following command to create a bucket named examplebucket.

      Note

      If the command returns ErrorCode=BucketAlreadyExists, the bucket name is already in use. Because bucket names must be globally unique in OSS, replace examplebucket with a unique name.

      ossutil64 mb oss://examplebucket

      Expected output:

      0.668238(s) elapsed

      This output confirms the creation of the bucket named examplebucket.

   3. Upload the downloaded test data to the examplebucket bucket.

      ossutil64 cp spark-3.0.1-bin-hadoop2.7.tgz oss://examplebucket

   4. (Optional) Configure access permissions for the bucket and its data. For more information, see Overview of access control.

3. Create a file named mySecret.yaml with the following content.

   apiVersion: v1
   kind: Secret
   metadata:
     name: mysecret
   stringData:
     fs.oss.accessKeyId: xxx
     fs.oss.accessKeySecret: xxx

   The fs.oss.accessKeyId and fs.oss.accessKeySecret parameters specify the AccessKey ID and AccessKey Secret used to access OSS.

4. Run the following command to create the secret. Kubernetes automatically encodes the created secret to prevent it from being exposed as plaintext.

   kubectl create -f mySecret.yaml

Step 2: Create a dataset and a JindoRuntime

1. Create a resource.yaml file with the following content:

   • A dataset that describes the remote dataset and the underlying file system (UFS).

   • A JindoRuntime that starts a JindoFS cluster to provide caching services.

   Note

   You can run the kubectl get pods --field-selector=status.phase=Running -n fluid-system command to check if the dataset-controller and jindoruntime-controller in the ack-fluid component are running correctly.

   This example primarily uses CPU compute power. To accelerate the loading of Large Language Model (LLM) services, ensure the zone you select when creating the cluster supports GPU resources. For more information, see GPU-accelerated compute instance types.

   Expand to view YAML content

   apiVersion: data.fluid.io/v1alpha1
   kind: Dataset
   metadata:
     name: hadoop
   spec:
     placement: Shared
     mounts:
         ## To specify a subdirectory, use the format oss://<oss_bucket>/{oss_path}.
       - mountPoint: oss://<oss_bucket>       # Replace <oss_bucket> with your bucket name.
         options:
           fs.oss.endpoint: <oss_endpoint>    # Replace <oss_endpoint> with your 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:
     ## Must match the dataset name.
     name: hadoop
   spec:
     networkmode: ContainerNetwork
     ## Adjust as needed.
     replicas: 4
     master:
       podMetadata:
         labels:
           alibabacloud.com/compute-class: performance
           alibabacloud.com/compute-qos: default
     worker:
       podMetadata:
         labels:
           alibabacloud.com/compute-class: performance
           alibabacloud.com/compute-qos: default
       resources:
         requests:
           cpu: 24
           memory: 48Gi
         limits:
           cpu: 24
           memory: 48Gi
     tieredstore:
       levels:
         - mediumtype: MEM
           path: /dev/shm
           volumeType: emptyDir
           ## Adjust as needed.
           quota: 48Gi
           high: "0.99"
           low: "0.95"

   The following table describes the parameters.

   Parameter	Description
   mountPoint	oss://<oss_bucket> specifies the mount path of the UFS. <oss_bucket> is the name of your OSS bucket. For example: oss://examplebucket.
   fs.oss.endpoint	The endpoint of the OSS bucket. Both public and internal endpoints are supported. For example: oss-cn-beijing-internal.aliyuncs.com. For more information, see OSS regions and endpoints.
   replicas	The number of worker replicas in the JindoFS cluster.
   mediumtype	The type of cache medium. JindoFS currently supports only one of the following cache types: HDD, SSD, or MEM.
   path	The storage path. Only a single path is supported. When MEM is the cache type, you must specify a local path to store files such as logs.
   quota	The maximum cache capacity, in GiB.
   high	The high watermark for storage usage.
   low	The low watermark for storage usage.

2. Create the JindoRuntime and dataset.

   kubectl create -f resource.yaml

3. Check the deployment status of the JindoRuntime and dataset.

   1. Check the deployment status of the dataset.

      kubectl get dataset hadoop

      Expected output:

      NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
      hadoop   209.74MiB        0.00B    4.00GiB          0.0%                Bound   56s

   2. Check the deployment status of the JindoRuntime.

      kubectl get jindoruntime hadoop

      Expected output:

      NAME     MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
      hadoop   Ready          Ready          Ready        2m11s

      The output shows that the dataset and JindoRuntime are ready.

4. Run the following command to check the creation status of the persistent volume (PV) and persistent volume claim (PVC). Fluid names the PVC after the dataset.

   kubectl get pv,pvc

   Expected output:

   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

Step 3: Preload the dataset

To significantly improve data loading speed and ensure data processing logic is correct, you need to preload the dataset.

1. If the data in OSS does not change, create a dataload.yaml file with the following content to perform a one-time data preload.

   apiVersion: data.fluid.io/v1alpha1
   kind: DataLoad
   metadata:
     name: hadoop
   spec:
     dataset:
       name: hadoop
       namespace: default
     loadMetadata: true

2. If the data in OSS is updated dynamically, configure periodic data preloading. For more information, see Scenario 2: Read-only data with periodic updates in backend storage.

3. Create the DataLoad resource to perform the one-time preload.

   kubectl create -f dataload.yaml

4. Check the data preloading status.

   kubectl get dataload

   Expected output:

   NAME          DATASET    PHASE       AGE   DURATION
   hadoop        hadoop   Complete      92m   51s

Step 4: Create a pod to test acceleration

You can test the JindoFS acceleration service by creating an application pod or submitting a machine learning job. The following example creates a pod that accesses the same data multiple times. By comparing the access times, you can observe the acceleration provided by JindoRuntime.

1. Create a file named app.yaml with the following content.

   apiVersion: v1
   kind: Pod
   metadata:
     name: demo-app
     labels:
       # Mounting on ACS requires sidecar injection by the Fluid webhook. Add the following 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:
           ## The name of the Fluid dataset.
           claimName: hadoop
     nodeSelector:
       type: virtual-kubelet
     tolerations:
       - key: virtual-kubelet.io/provider
         operator: Equal
         value: alibabacloud
         effect: NoSchedule

2. Run the following command to create the application pod.

   kubectl create -f app.yaml

3. Test the file copy speed without JindoFS cache acceleration.

   1. Check the size of the test file.

      kubectl exec -it demo-app -c demo -- du -sh /data/spark-3.0.1-bin-hadoop2.7.tgz

      Expected output:

      210M    /data/spark-3.0.1-bin-hadoop2.7.tgz

   2. Check the time it takes to copy the file.

      time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null

      Expected output:

      real    0m1.883s
      user    0m0.001s
      sys     0m0.041s

      The file copy took 1.883 seconds.

4. Check the cache status of the dataset.

   kubectl get dataset hadoop

   Expected output:

   NAME     UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
   hadoop   209.74MiB        209.74MiB   4.00GiB          100.0%              Bound   64m

   The output shows that 100.0% of the data is now cached in JindoFS.

5. Delete the sample application pod and check the file copy time again.

   Note

   The application pod is deleted to prevent other factors, such as the page cache, from affecting the test results. If a local cache already exists in the pod, the copy operation uses it by default.

   Run the following commands to check the file copy time.

   kubectl exec -it demo-app -c demo -- bash
   time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null

   Expected output:

   real    0m0.203s
   user    0m0.000s
   sys     0m0.047s

   The copy operation now takes 0.203 seconds, roughly 9 times faster than the first attempt. This speed increase occurs because JindoFS serves the file from its cache.

   Important

   The copy times provided in this topic are for reference only. Actual results may vary depending on your environment.