DataWorks:Réguler la synchronisation par lots

Étape 1 : Attente des ressources de planification

Symptômes :

• Le journal de la tâche indique que la tâche attend la passerelle.

• La page des propriétés de l'instance affiche un temps d'attente des ressources élevé.

Cause : Le groupe de ressources de planification a atteint sa limite maximale de tâches. Les nouvelles tâches doivent attendre que les tâches en cours se terminent et libèrent les ressources.

Solution : Dans la console DataWorks, accédez à la page Operation Analysis pour voir quelles tâches utilisent les ressources pendant que la tâche actuelle est en attente.

Si vous utilisez des groupes de ressources partagés pour la planification, migrez vos tâches vers un groupe de ressources exclusif ou un groupe de ressources Serverless.

Étape 2 : Attente des ressources d'exécution

Symptôme : Le journal de la tâche affiche wait.

Cause : Le groupe de ressources d'intégration de données ne dispose pas de slots de concurrence disponibles suffisants pour la tâche.

Par exemple : un groupe de ressources prend en charge un maximum de 8 slots de concurrence. Si deux tâches s'exécutent avec une concurrence de 3 chacune, elles utilisent 6 slots, laissant 2 disponibles. Une troisième tâche nécessitant 3 slots de concurrence doit attendre.

Solution :

1. Accédez à la page Operation Analysis pour voir quelles tâches consomment des ressources.

2. Vérifiez si des tâches en cours sont bloquées ou anormalement lentes. Le cas échéant, arrêtez-les ou résolvez le problème en premier lieu.

3. Si les tâches s'exécutent normalement, attendez qu'elles se terminent et libèrent les ressources.

4. Coordonnez-vous avec les propriétaires des tâches pour réduire la concurrence des tâches concurrentes.

5. Réduisez la concurrence de la tâche actuelle et soumettez-la à nouveau.

6. Mettez à l'échelle le groupe de ressources. Pour plus d'informations, consultez Opérations de mise à l'échelle.

Le nombre maximal de slots de concurrence varie selon la spécification du groupe de ressources. Pour plus d'informations, consultez Métriques de performance et facturation .

Étape 3 : Lecture des données lente (WaitReaderTime élevé)

Symptôme : Le journal de la tâche affiche run avec une vitesse de 0. Le Detail log affiche une valeur élevée pour WaitReaderTime, indiquant que la tâche attend longtemps des données de la source.

Causes :

• La clé de partitionnement n'est pas correctement configurée, ce qui ralentit l'exécution de la requête SQL de récupération des données.

• Les paramètres where ou querySql ne sont pas indexés, provoquant une analyse complète de la table.

• La base de données source est fortement sollicitée au moment de la synchronisation.

• Problèmes de bande passante ou de latence réseau.

La vitesse de synchronisation via le réseau public ne peut pas être garantie.

Solution :

• Indexez les champs utilisés pour le filtrage des données afin d'éviter les analyses complètes de table.

• Évitez ou réduisez l'utilisation de fonctions complexes dans les instructions pre-SQL ou post-SQL. Si nécessaire, exécutez ces opérations dans la base de données avant le début de la synchronisation.

• Si la table source est très volumineuse, divisez la tâche en plusieurs tâches plus petites.

• Interrogez les journaux pour identifier l'instruction SQL bloquante et collaborez avec votre administrateur de base de données pour la résoudre.

• Vérifiez la charge de la base de données source au moment de la synchronisation.

Étape 4 : Écriture des données lente (WaitWriterTime élevé)

Symptôme : Le journal de la tâche affiche run avec une vitesse de 0. Le Detail log affiche une valeur élevée pour WaitWriterTime, indiquant que la tâche met beaucoup de temps à écrire dans la destination.

Causes :

• Les instructions preSql ou postSql du plug-in writer s'exécutent lentement.

• La base de données de destination est fortement sollicitée au moment de la synchronisation.

• Problèmes de bande passante ou de latence réseau.

La vitesse de synchronisation via le réseau public ne peut pas être garantie.

Solution :

• Examinez et optimisez les instructions preSql et postSql dans la configuration du plug-in writer.

• Vérifiez la charge de la base de données de destination au moment de la synchronisation.

Étape 5 : Vitesse non nulle mais progression globale lente

Symptôme : Le journal de la tâche affiche run avec une vitesse non nulle, mais la tâche de synchronisation prend beaucoup plus de temps que prévu.

Causes :

• La clé de partitionnement pour une tâche de base de données relationnelle n'est pas configurée ou est mal configurée, rendant le paramètre de concurrence inefficace. La tâche s'exécute avec un seul thread au lieu de la concurrence configurée.

• Le paramètre de concurrence est trop faible.

• Un volume important de données incorrectes est généré pendant la synchronisation.

• Les performances de la base de données sont insuffisantes pour supporter la concurrence configurée.

• Problèmes de bande passante ou de latence réseau.

La vitesse de synchronisation via le réseau public ne peut pas être garantie.

Solution :

1. Configurez correctement la clé de partitionnement. Pour les étapes de configuration, consultez Configurer une tâche dans l'interface sans code.

2. Augmentez la concurrence de la tâche. Dans la limite du quota de concurrence maximal pris en charge par le groupe de ressources, planifiez la concurrence pour toutes les tâches et augmentez la concurrence de la tâche actuelle si nécessaire. Configurez la concurrence dans l'interface sans code ou définissez-la directement dans l'éditeur de code. Pour les limites du groupe de ressources, consultez Métriques de performance et facturation. Pour les tâches distribuées, assurez-vous que : concurrence de la tâche ÷ nombre de machines dans le groupe de ressources ≤ concurrence maximale par machine

3. Gérez les données incorrectes. Pour plus d'informations, consultez Data Integration.

4. Utilisez un réseau privé pour la synchronisation inter-cloud ou inter-région. Pour les options de connectivité réseau, consultez Solutions de connectivité réseau.

5. Vérifiez la charge de la base de données au moment de la synchronisation.

"setting": {
  "speed": {
    "throttle": true,  // Set to true to enable rate limiting.
    "mbps": 1          // The rate limit in MB/s.
  }
}

JobContainer - Job set Channel-Number to 2 channels

[ResponseError]:

  AccessDenied
xxx
xxx

2020-09-07 00:26:15.462 [job-323683754] INFO  OdpsWriter$Job - blockSizeInMB=64.
2020-09-07 00:26:15.462 [job-323683754] INFO  JobContainer - jobContainer starts to do prepare ...
2020-09-07 00:26:15.463 [job-323683754] INFO  JobContainer - DataX Reader.Job [ossreader] do prepare work .
2020-09-07 00:26:15.491 [job-323683754] INFO  OssReader$Job - add object [user_log.txt] as a candidate to be read.
2020-09-07 00:26:15.493 [job-323683754] INFO  JobContainer - DataX Writer.Job [odpswriter] do prepare work .
2020-09-07 00:26:15.494 [job-323683754] INFO  IdAndKeyUtil - xxx
2020-09-07 00:26:15.494 [job-323683754] INFO  OdpsWriter$Job - xxx
2020-09-07 00:26:18.045 [job-323683754] INFO  OdpsUtil - Try to xxx
2020-09-07 00:26:19.435 [job-323683754] INFO  OdpsUtil - Try to xxx
alter table xc_ods_raw_log_d add IF NOT EXISTS partition(dt='20200906');
] .
2020-09-07 00:26:21.860 [job-323683754] INFO  JobContainer - jobContainer starts to do split ...
2020-09-07 00:26:21.860 [job-323683754] INFO  JobContainer - Job set Channel-Number to 2 channels.
2020-09-07 00:26:22.120 [job-323683754] INFO  UnstructuredSplitUtil - File to be read:[{"end" xxx ,"filePath":"user_lxxx
2020-09-07 00:26:22.121 [job-323683754] INFO  UnstructuredSplitUtil - File to be read:[{"end"
2020-09-07 00:26:22.121 [job-323683754] INFO  JobContainer - DataX Reader.Job [ossreader] splits to [2] tasks.

Concurrence et CPU

Dans un groupe de ressources exclusif, le ratio entre la concurrence et le vCPU est de 1:0,5. Une instance ECS avec 4 vCPU et 8 Go de mémoire offre un quota de concurrence de 8. Cela signifie :

• Jusqu'à 8 tâches de synchronisation hors ligne avec une concurrence de 1, ou

• Jusqu'à 4 tâches de synchronisation hors ligne avec une concurrence de 2.

Si une tâche nouvellement soumise nécessite plus de concurrence que le quota restant, elle attend que les tâches en cours se terminent et libèrent les ressources.

Concurrence et mémoire

L'utilisation de la mémoire par tâche dans un groupe de ressources exclusif suit cette formule :

Min{768 + (concurrency - 1) × 256, 8029} MB

Remplacez ceci dans l'éditeur de code en définissant le chemin JSON $.setting.jvmOption.

"setting": {
    "errorLimit": {
        "record": "0"
    },
    "speed": {
        "throttle": false,
        "concurrent": 1
    },
    "jvmOption": "-Xms1024m -Xmx1024m"
}

Pour maintenir la stabilité des tâches, la mémoire totale utilisée par toutes les tâches en cours doit rester inférieure d'au moins 1 Go à la mémoire totale de toutes les machines du groupe de ressources. Si ce seuil est dépassé, le tueur OOM Linux peut arrêter de force les tâches.

Si vous ne remplacez pas les paramètres de mémoire dans l'éditeur de code, seule la limite de quota de concurrence s'applique lors de la planification des soumissions de tâches.

Plug-ins writer

Plug-ins reader