Container Compute Service:Accelerate data access with Fluid

Étape 1 : Préparez les données dans un compartiment OSS

1. Exécutez la commande suivante pour télécharger les données de test.

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

2. Téléchargez les données de test téléchargées vers un compartiment dans OSS.

   Important

   Cet exemple utilise une instance ECS exécutant Alibaba Cloud Linux 3.2104 LTS 64 bits pour montrer comment télécharger des données vers OSS. Pour obtenir des instructions concernant d'autres systèmes d'exploitation, consultez les rubriques Démarrage rapide d'ossutil et ossutil 1,0.

   1. Installez ossutil.

   2. Exécutez la commande suivante pour créer un compartiment nommé examplebucket.

      Remarque

      Si la commande renvoie ErrorCode=BucketAlreadyExists, le nom du compartiment est déjà utilisé. Étant donné que les noms de compartiments doivent être globalement uniques dans OSS, remplacez examplebucket par un nom unique.

      ossutil64 mb oss://examplebucket

      Sortie attendue :

      0.668238(s) elapsed

      Cette sortie confirme la création du compartiment nommé examplebucket.

   3. Téléchargez les données de test téléchargées vers le compartiment examplebucket.

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

   4. (Facultatif) Configurez les autorisations d'accès pour le compartiment et ses données. Pour plus d'informations, consultez la rubrique Présentation du contrôle d'accès.

3. Créez un fichier nommé mySecret.yaml avec le contenu suivant.

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

   Les paramètres fs.oss.accessKeyId et fs.oss.accessKeySecret spécifient l'AccessKey ID et l'AccessKey Secret utilisés pour accéder à OSS.

4. Exécutez la commande suivante pour créer le secret. Kubernetes encode automatiquement le secret créé pour éviter qu'il ne soit exposé en texte clair.

   kubectl create -f mySecret.yaml

Étape 2 : Créez un jeu de données et un JindoRuntime

1. Créez un fichier resource.yaml avec le contenu suivant :

   • Un jeu de données qui décrit le jeu de données distant et le système de fichiers sous-jacent (UFS).

   • Un JindoRuntime qui démarre un cluster JindoFS pour fournir des services de mise en cache.

   Remarque

   Vous pouvez exécuter la commande kubectl get pods --field-selector=status.phase=Running -n fluid-system pour vérifier si le dataset-controller et le jindoruntime-controller du composant ack-fluid s'exécutent correctement.

   Cet exemple utilise principalement la puissance de calcul CPU. Pour accélérer le chargement des services de grands modèles de langage (LLM), assurez-vous que la zone que vous sélectionnez lors de la création du cluster prend en charge les ressources GPU. Pour plus d'informations, consultez la rubrique Types d'instances de calcul accélérées par GPU.

   Développer pour afficher le contenu YAML

   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"

   Le tableau suivant décrit les paramètres.

   Paramètre	Description
   mountPoint	oss://<oss_bucket> spécifie le chemin de montage de l'UFS. <oss_bucket> est le nom de votre compartiment OSS. Par exemple : oss://examplebucket.
   fs.oss.endpoint	L'endpoint du compartiment OSS. Les endpoints publics et internes sont pris en charge. Par exemple : oss-cn-beijing-internal.aliyuncs.com. Pour plus d'informations, consultez la rubrique Régions et endpoints OSS.
   replicas	Le nombre de réplicas de nœuds de travail dans le cluster JindoFS.
   mediumtype	Le type de support de cache. JindoFS prend actuellement en charge uniquement l'un des types de cache suivants : HDD, SSD ou MEM.
   path	Le chemin de stockage. Un seul chemin est pris en charge. Lorsque MEM est le type de cache, vous devez spécifier un chemin local pour stocker des fichiers tels que les journaux.
   quota	La capacité maximale du cache, en GiB.
   high	Le seuil haut pour l'utilisation du stockage.
   low	Le seuil bas pour l'utilisation du stockage.

2. Créez le JindoRuntime et le jeu de données.

   kubectl create -f resource.yaml

3. Vérifiez l'état du déploiement du JindoRuntime et du jeu de données.

   1. Vérifiez l'état du déploiement du jeu de données.

      kubectl get dataset hadoop

      Sortie attendue :

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

   2. Vérifiez l'état du déploiement du JindoRuntime.

      kubectl get jindoruntime hadoop

      Sortie attendue :

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

      La sortie indique que le jeu de données et le JindoRuntime sont prêts.

4. Exécutez la commande suivante pour vérifier l'état de création du volume persistant (PV) et de la revendication de volume persistant (PVC). Fluid nomme le PVC d'après le jeu de données.

   kubectl get pv,pvc

   Sortie attendue :

   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

Étape 3 : Préchargez le jeu de données

Pour améliorer considérablement la vitesse de chargement des données et garantir l'exactitude de la logique de traitement des données, vous devez précharger le jeu de données.

1. Si les données dans OSS ne changent pas, créez un fichier dataload.yaml avec le contenu suivant pour effectuer un préchargement unique des données.

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

2. Si les données dans OSS sont mises à jour dynamiquement, configurez un préchargement périodique des données. Pour plus d'informations, consultez la rubrique Scénario 2 : Données en lecture seule avec mises à jour périodiques dans le stockage backend.

3. Créez la ressource DataLoad pour effectuer le préchargement unique.

   kubectl create -f dataload.yaml

4. Vérifiez l'état du préchargement des données.

   kubectl get dataload

   Sortie attendue :

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

Étape 4 : Créez un pod pour tester l'accélération

Vous pouvez tester le service d'accélération JindoFS en créant un pod d'application ou en soumettant une tâche d'apprentissage automatique. L'exemple suivant crée un pod qui accède plusieurs fois aux mêmes données. En comparant les temps d'accès, vous pouvez observer l'accélération fournie par JindoRuntime.

1. Créez un fichier nommé app.yaml avec le contenu suivant.

   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. Exécutez la commande suivante pour créer le pod d'application.

   kubectl create -f app.yaml

3. Testez la vitesse de copie de fichier sans accélération par cache JindoFS.

   1. Vérifiez la taille du fichier de test.

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

      Sortie attendue :

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

   2. Vérifiez le temps nécessaire pour copier le fichier.

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

      Sortie attendue :

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

      La copie du fichier a pris 1 883 seconde.

4. Vérifiez l'état du cache du jeu de données.

   kubectl get dataset hadoop

   Sortie attendue :

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

   La sortie indique que 100.0% des données sont désormais mises en cache dans JindoFS.

5. Supprimez le pod d'application exemple et vérifiez à nouveau le temps de copie du fichier.

   Remarque

   Le pod d'application est supprimé pour empêcher d'autres facteurs, tels que le cache de page, d'affecter les résultats du test. Si un cache local existe déjà dans le pod, l'opération de copie l'utilise par défaut.

   Exécutez les commandes suivantes pour vérifier le temps de copie du fichier.

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

   Sortie attendue :

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

   L'opération de copie prend désormais 0 203 seconde, soit environ 9 fois plus rapide que la première tentative. Cette augmentation de vitesse se produit parce que JindoFS sert le fichier depuis son cache.

   Important

   Les temps de copie fournis dans cette rubrique sont donnés à titre indicatif uniquement. Les résultats réels peuvent varier en fonction de votre environnement.