Container Compute Service:Uso de Fluid para acelerar el acceso a los datos

Paso 1: Preparar los datos en un bucket de OSS

1. Ejecute el siguiente comando para descargar los datos de prueba.

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

2. Cargue los datos de prueba descargados en un bucket de OSS.

   Importante

   Este ejemplo usa una instancia de ECS que ejecuta Alibaba Cloud Linux 3.2104 LTS de 64 bits para mostrar cómo cargar datos en OSS. Para consultar las instrucciones correspondientes a otros sistemas operativos, consulte ossutil quick start y ossutil 1.0.

   1. Install ossutil.

   2. Ejecute el siguiente comando para crear un bucket llamado examplebucket.

      Nota

      Si el comando devuelve ErrorCode=BucketAlreadyExists, significa que el nombre del bucket ya está en uso. Dado que los nombres de los buckets deben ser únicos a nivel global en OSS, reemplace examplebucket por un nombre único.

      ossutil64 mb oss://examplebucket

      Salida esperada:

      0.668238(s) elapsed

      Esta salida confirma la creación del bucket llamado examplebucket.

   3. Cargue los datos de prueba descargados en el bucket examplebucket.

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

   4. (Opcional) Configure los permisos de acceso del bucket y de sus datos. Para obtener más información, consulte Overview of access control.

3. Cree un archivo llamado mySecret.yaml con el siguiente contenido.

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

   Los parámetros fs.oss.accessKeyId y fs.oss.accessKeySecret especifican el AccessKey ID y el AccessKey Secret que se usan para acceder a OSS.

4. Ejecute el siguiente comando para crear el secreto. Kubernetes codifica automáticamente el secreto creado para evitar que quede expuesto como texto sin formato.

   kubectl create -f mySecret.yaml

Paso 2: Crear un conjunto de datos y un JindoRuntime

1. Cree un archivo resource.yaml con el siguiente contenido:

   • Un conjunto de datos que describe el conjunto de datos remoto y el sistema de archivos subyacente (UFS).

   • Un JindoRuntime que inicia un clúster de JindoFS para proporcionar servicios de caché.

   Nota

   Puede ejecutar el comando kubectl get pods --field-selector=status.phase=Running -n fluid-system para comprobar si dataset-controller y jindoruntime-controller del componente ack-fluid se están ejecutando correctamente.

   Este ejemplo utiliza principalmente capacidad de cómputo de CPU. Para acelerar la carga de servicios de modelos de lenguaje extensos (LLM), asegúrese de que la zona seleccionada al crear el clúster sea compatible con recursos de GPU. Para obtener más información, consulte 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"

   En la siguiente tabla se describen los parámetros.

   Parámetro	Descripción
   mountPoint	oss://<oss_bucket> especifica la ruta de montaje del UFS. <oss_bucket> es el nombre de su bucket de OSS. Por ejemplo: oss://examplebucket.
   fs.oss.endpoint	El endpoint del bucket de OSS. Se admiten tanto endpoints públicos como internos. Por ejemplo: oss-cn-beijing-internal.aliyuncs.com. Para obtener más información, consulte OSS regions and endpoints.
   replicas	El número de réplicas de worker en el clúster de JindoFS.
   mediumtype	El tipo de medio de caché. Actualmente, JindoFS solo es compatible con uno de los siguientes tipos de caché: HDD, SSD o MEM.
   path	La ruta de almacenamiento. Solo se admite una única ruta. Cuando el tipo de caché es MEM, debe especificar una ruta local para almacenar archivos como los registros.
   quota	La capacidad máxima de la caché, en GiB.
   high	La marca de agua alta para el uso de almacenamiento.
   low	La marca de agua baja para el uso de almacenamiento.

2. Cree el JindoRuntime y el conjunto de datos.

   kubectl create -f resource.yaml

3. Compruebe el estado de despliegue del JindoRuntime y del conjunto de datos.

   1. Compruebe el estado de despliegue del conjunto de datos.

      kubectl get dataset hadoop

      Salida esperada:

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

   2. Compruebe el estado de despliegue del JindoRuntime.

      kubectl get jindoruntime hadoop

      Salida esperada:

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

      La salida muestra que el conjunto de datos y el JindoRuntime están listos.

4. Ejecute el siguiente comando para comprobar el estado de creación del volumen persistente (PV) y de la solicitud de volumen persistente (PVC). Fluid asigna al PVC el mismo nombre que al conjunto de datos.

   kubectl get pv,pvc

   Salida esperada:

   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

Paso 3: Precargar el conjunto de datos

Para mejorar significativamente la velocidad de carga de los datos y garantizar que la lógica de procesamiento sea correcta, es necesario precargar el conjunto de datos.

1. Si los datos en OSS no cambian, cree un archivo dataload.yaml con el siguiente contenido para llevar a cabo una precarga de datos única.

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

2. Si los datos en OSS se actualizan de forma dinámica, configure una precarga de datos periódica. Para obtener más información, consulte Scenario 2: Read-only data with periodic updates in backend storage.

3. Cree el recurso DataLoad para realizar la precarga única.

   kubectl create -f dataload.yaml

4. Compruebe el estado de la precarga de datos.

   kubectl get dataload

   Salida esperada:

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

Paso 4: Crear un pod para probar la aceleración

Puede probar el servicio de aceleración de JindoFS mediante la creación de un pod de aplicación o el envío de un trabajo de aprendizaje automático. En el siguiente ejemplo se crea un pod que accede varias veces a los mismos datos. Al comparar los tiempos de acceso, podrá observar la aceleración que proporciona JindoRuntime.

1. Cree un archivo llamado app.yaml con el siguiente contenido.

   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. Ejecute el siguiente comando para crear el pod de la aplicación.

   kubectl create -f app.yaml

3. Pruebe la velocidad de copia del archivo sin la aceleración de la caché de JindoFS.

   1. Compruebe el tamaño del archivo de prueba.

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

      Salida esperada:

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

   2. Compruebe el tiempo que tarda en copiarse el archivo.

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

      Salida esperada:

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

      La copia del archivo tardó 1,883 segundos.

4. Compruebe el estado de la caché del conjunto de datos.

   kubectl get dataset hadoop

   Salida esperada:

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

   La salida muestra que ahora el 100.0% de los datos está en la caché de JindoFS.

5. Elimine el pod de la aplicación de ejemplo y vuelva a comprobar el tiempo de copia del archivo.

   Nota

   Se elimina el pod de la aplicación para evitar que otros factores, como la caché de páginas, afecten los resultados de la prueba. Si ya existe una caché local en el pod, la operación de copia la usará de forma predeterminada.

   Ejecute los siguientes comandos para comprobar el tiempo de copia del archivo.

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

   Salida esperada:

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

   Ahora la operación de copia tarda 0,203 segundos, aproximadamente 9 veces menos que en el primer intento. Este aumento de velocidad se produce porque JindoFS sirve el archivo desde su caché.

   Importante

   Los tiempos de copia proporcionados en este tema son solo de referencia. Los resultados reales pueden variar según su entorno.