Schedule periodic dataset updates with DataLoad - Container Service for Kubernetes

Prérequis

Avant de commencer, assurez-vous d'avoir :

Un cluster managé ACK Édition Pro, version 1.18 ou ultérieure. Pour plus d'informations, consultez Créer un cluster managé ACK Édition Pro.
La suite AI cloud-native installée, avec le composant ack-fluid (version 1.0.3) déployé.

Important
Si vous avez installé Fluid open source, désinstallez-le avant de déployer ack-fluid. Pour installer ack-fluid, consultez Installer la suite AI cloud-native, ou déployez-le depuis la page Cloud-native AI Suite dans la console ACK.
kubectl configuré pour se connecter à votre cluster. Pour plus d'informations, consultez Se connecter à un cluster à l'aide de l'outil kubectl.
ossutil installé et un bucket OSS créé. Pour plus d'informations, consultez Installer ossutil.

Étape 1 : Préparer les données dans un bucket OSS

Téléchargez le fichier de test.

wget https://archive.apache.org/dist/hbase/2.5.2/RELEASENOTES.md

Chargez le fichier dans votre bucket OSS.

ossutil64 cp RELEASENOTES.md oss://<bucket>/<path>/RELEASENOTES.md

Étape 2 : Créer un Dataset et un JindoRuntime

Créez un fichier nommé mySecret.yaml avec le contenu suivant pour stocker vos identifiants OSS.

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  fs.oss.accessKeyId: ****** # Enter your AccessKey ID.
  fs.oss.accessKeySecret: ****** # Enter your AccessKey secret.

Créez le Secret.

kubectl create -f mySecret.yaml

Résultat attendu :

secret/mysecret created

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

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo
spec:
  mounts:
    - mountPoint: oss://<bucket-name>/<path>
      options:
        fs.oss.endpoint: <oss-endpoint>
      name: hbase
      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
  accessModes:
    - ReadOnlyMany
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: demo
spec:
  replicas: 1
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        quota: 2Gi
        high: "0.99"
        low: "0.8"
  fuse:
   args:
    - -okernel_cache
    - -oro
    - -oattr_timeout=60
    - -oentry_timeout=60
    - -onegative_timeout=60

Le tableau suivant décrit les paramètres clés.

Ressource	Paramètre	Description
Dataset	`mountPoint`	Le chemin d'accès au système de fichiers sous-jacent (UFS), au format `oss://<bucket>/<path>`. Le chemin n'inclut pas les informations d'endpoint.
Dataset	`fs.oss.endpoint`	L'endpoint du bucket OSS. Les endpoints publics et privés sont pris en charge.
Dataset	`accessModes`	Le mode d'accès du Dataset.
JindoRuntime	`replicas`	Le nombre de nœuds de travail dans le cluster JindoFS.
JindoRuntime	`mediumtype`	Le support de stockage du cache. Valeurs valides : `HDD`, `SSD`, `MEM`.
JindoRuntime	`path`	Le chemin de stockage local. Si `mediumtype` est `MEM`, spécifiez un chemin local pour les fichiers tels que les journaux.
JindoRuntime	`quota`	La capacité maximale du cache. Définissez cette valeur en fonction de la taille des données dans l'UFS.
JindoRuntime	`high`	Le seuil haut pour la capacité de stockage du cache.
JindoRuntime	`low`	Le seuil bas pour la capacité de stockage du cache.
JindoRuntime	`fuse.args`	Paramètres de montage optionnels du client FUSE. La configuration dépend du mode d'accès du Dataset : - ReadOnlyMany : Activez `kernel_cache` pour utiliser le cache du noyau afin d'améliorer les performances en lecture. Définissez `attr_timeout` (cache des attributs de fichier), `entry_timeout` (cache de recherche de nom de fichier) et `negative_timeout` (cache des recherches de nom de fichier ayant échoué). La valeur par défaut pour tous est de 7 200 s. - ReadWriteMany : Utilisez la configuration par défaut : `-oauto_cache`, `-oattr_timeout=0`, `-oentry_timeout=0`, `-onegative_timeout=0`. L'option `auto_cache` invalide le cache lorsque la taille du fichier ou l'heure de modification change.

Déployez dataset.yaml pour créer le Dataset et le JindoRuntime.

kubectl create -f dataset.yaml

Résultat attendu :

dataset.data.fluid.io/demo created
jindoruntime.data.fluid.io/demo created

Vérifiez que le Dataset est prêt.

kubectl get dataset

Résultat attendu :

NAME    UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
demo    588.90KiB        0.00B       10.00GiB         0.0%                Bound   2m7s

Le champ PHASE affiche Bound, ce qui signifie que le Dataset est prêt.

Étape 3 : Créer une tâche DataLoad planifiée

Par défaut, une tâche DataLoad charge toutes les données du Dataset cible. Pour un contrôle plus fin, comme le chargement d'un chemin spécifique uniquement ou la synchronisation des métadonnées avant le chargement, consultez Configurations DataLoad avancées.

DataLoad prend en charge deux politiques d'exécution :

Once : La tâche s'exécute une seule fois.
Cron : La tâche s'exécute selon un calendrier récurrent.

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

apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: cron-dataload
spec:
  dataset:
    name: demo
    namespace: default
  policy: Cron
  schedule: "*/2 * * * *" # Run every 2 min

Le tableau suivant décrit les paramètres.

Paramètre	Description
`dataset`	Le nom et l'espace de noms du Dataset à charger.
`policy`	La politique d'exécution. Définissez-la sur `Cron` pour une tâche planifiée.
`schedule`	L'expression cron pour le calendrier de la tâche. Pour plus d'informations, consultez Syntaxe des planifications Cron.

Déployez la tâche DataLoad.

kubectl apply -f dataload.yaml

Résultat attendu :

dataload.data.fluid.io/cron-dataload created

Vérifiez l'état de la tâche DataLoad.

kubectl get dataload

Lorsque PHASE affiche Complete, les données ont été chargées dans le cache.

NAME            DATASET   PHASE      AGE   DURATION
cron-dataload   demo      Complete   68s   8s

Confirmez que les données sont mises en cache.

kubectl get dataset

Résultat attendu :

NAME    UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
demo    588.90KiB        588.90KiB   10.00GiB         100.0%              Bound   5m50s

Une valeur de CACHED PERCENTAGE à 100 % confirme que toutes les données d'OSS sont chargées dans le cache.

Étape 4 : Accéder aux données depuis un pod d'application

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

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: demo-vol
  volumes:
    - name: demo-vol
      persistentVolumeClaim:
        claimName: demo

Créez le pod d'application.
```
kubectl create -f app.yaml
```
Résultat attendu :
```
pod/nginx created
```

Une fois le pod prêt, listez les données dans OSS.

kubectl exec -it nginx -- ls -lh /data

Résultat attendu :

total 589K
-rwxrwxr-x 1 root root 589K Jul 31 04:20 RELEASENOTES.md

Ajoutez une ligne à RELEASENOTES.md pour simuler une mise à jour.
```
echo "hello, crondataload." >> RELEASENOTES.md
```

Rechargez le fichier mis à jour dans OSS.

ossutil64 cp RELEASENOTES.md oss://<bucket-name>/<path>/RELEASENOTES.md

Lorsque vous y êtes invité, saisissez y pour confirmer. Résultat attendu :

cp: overwrite "oss://<bucket-name>/<path>/RELEASENOTES.md"(y or N)? y
Succeed: Total num: 1, size: 21. OK num: 1(upload 1 files).

Attendez la prochaine exécution planifiée de DataLoad, puis vérifiez l'état de la tâche.

kubectl describe dataload cron-dataload

Résultat attendu (champs pertinents) :

Status:
  Conditions:
    Last Probe Time:       2023-08-24T06:44:08Z
    Last Transition Time:  2023-08-24T06:44:08Z
    Status:                True
    Type:                  Complete
  Duration:                8s
  Last Schedule Time:      2023-08-24T06:44:00Z # The time when the last DataLoad job was scheduled.
  Last Successful Time:    2023-08-24T06:44:08Z # The time when the last DataLoad job was completed.
  Phase:                   Complete

Confirmez que le fichier mis à jour est mis en cache.

kubectl get dataset

Résultat attendu :

NAME    UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
demo    588.90KiB        1.15MiB     10.00GiB         100.0%              Bound   10m

La valeur CACHED a augmenté, reflétant le fichier mis à jour chargé dans le cache.

Vérifiez que le pod d'application peut lire le contenu mis à jour.
```
kubectl exec -it nginx -- tail /data/RELEASENOTES.md
```
Résultat attendu :
```
hello, crondataload.
```

Configurations DataLoad avancées

Les configurations suivantes vous permettent de contrôler le comportement de DataLoad au-delà des valeurs par défaut.

Synchroniser les métadonnées avant le chargement

Lorsque les fichiers dans OSS ont changé, JindoFS peut servir des données obsolètes car sa vue des métadonnées n'est pas synchronisée. Définissez loadMetadata: true pour synchroniser les métadonnées avant l'exécution de la tâche DataLoad.

spec:
  ...
  loadMetadata: true

Charger uniquement un chemin spécifique

Par défaut, DataLoad charge toutes les données du Dataset. Pour ne charger qu'un sous-ensemble, spécifiez un ou plusieurs chemins cibles.

spec:
  ...
  target:
    - path: <path1>
      replicas: 1
    - path: <path2>
      replicas: 2

Le champ replicas sous chaque cible définit le nombre de réplicas mis en cache pour ce chemin.

Configuration avancée combinée

L'exemple suivant montre tous les champs avancés réunis à titre de référence.

apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: cron-dataload
spec:
  dataset:
    name: demo
    namespace: default
  policy: Cron
  schedule: "* * * * *"
  loadMetadata: true
  target:
    - path: <path1>
      replicas: 1
    - path: <path2>
      replicas: 2

(Facultatif) Nettoyer

Si vous n'avez plus besoin de la configuration d'accélération des données, supprimez le pod d'application et le Dataset.

kubectl delete -f app.yaml
kubectl delete -f dataset.yaml

Résultat attendu :

pod "nginx" deleted
dataset.data.fluid.io "demo" deleted
jindoruntime.data.fluid.io "demo" deleted