DataWorks:FAQ sur la synchronisation par lots

• Si le test de connectivité a déjà réussi auparavant, lancez-le à nouveau pour confirmer que le groupe de ressources et la base de données sont bien connectés actuellement (et qu'aucune modification n'a été apportée côté base de données).

• Vérifiez si le groupe de ressources ayant passé le test de connectivité est bien celui utilisé pour exécuter la tâche.

  Identifiez le groupe de ressources utilisé par la tâche :

  • Si la tâche s'exécute sur le groupe de ressources par défaut, les journaux contiennent l'information suivante : running in Pipeline[basecommon_ group_xxxxxxxxx]

  • Si la tâche s'exécute sur un groupe de ressources exclusif pour Data Integration, les journaux contiennent l'information suivante : running in Pipeline[basecommon_S_res_group_xxx]

  • Si la tâche s'exécute sur un groupe de ressources serverless, les journaux contiennent l'information suivante : running in Pipeline[basecommon_Serverless_res_group_xxx]

• Si la tâche échoue occasionnellement lors de la planification du matin mais réussit après une relance, vérifiez la charge de la base de données au moment où l'erreur s'est produite.

Si une tâche de synchronisation par lots échoue de manière intermittente, la cause peut être une configuration incomplète de la liste d'autorisation. Vérifiez que la liste d'autorisation de la base de données est correctement configurée.

Lors de l'utilisation d'un groupe de ressources exclusif pour Data Integration :

• Si vous avez précédemment ajouté les adresses IP de l'interface réseau élastique (ENI) du groupe de ressources exclusif pour Data Integration à la liste d'autorisation de la source de données, et que le groupe de ressources a depuis été étendu, mettez à jour la liste d'autorisation de la source de données pour inclure les adresses IP ENI du groupe étendu.

• Pour éviter de devoir mettre à jour la liste d'autorisation à chaque extension du groupe de ressources, nous vous recommandons d'ajouter le bloc CIDR du vSwitch associé au groupe de ressources exclusif pour Data Integration comme liste d'autorisation de la base de données. Pour plus d'informations, reportez-vous à Ajouter une liste d'autorisation.

Lors de l'utilisation d'un groupe de ressources serverless : reportez-vous à Connectivité réseau d'un groupe de ressources serverless pour vérifier la configuration de la liste d'autorisation du groupe de ressources et vous assurer que le réseau est correctement configuré.

Si la liste d'autorisation est correctement configurée, vérifiez si la charge de la base de données est trop élevée, ce qui pourrait entraîner des interruptions de connexion.

• Cause possible :

  Le niveau de concurrence est défini trop haut, ce qui entraîne une insuffisance des ressources.

• Solution :

  Réduisez la concurrence de la tâche de synchronisation par lots.

  • Si vous configurez la tâche de synchronisation par lots en mode assistant, réduisez la valeur de Expected Maximum Concurrency dans Channel Control. Pour plus d'informations, reportez-vous à Configurer le contrôle des canaux en mode assistant.

  • Si vous configurez la tâche de synchronisation par lots en mode script, réduisez la valeur du paramètre concurrent dans Channel Control. Pour plus d'informations, reportez-vous à Configurer le contrôle des canaux en mode script.

Pour résoudre cette erreur :

1. Si la configuration du plugin prend en charge des paramètres tels que batchsize ou maxfilesize, réduisez les valeurs correspondantes.

   Vous pouvez vérifier si chaque plugin prend en charge les paramètres mentionnés ci-dessus. Accédez à la rubrique Sources de données et lecteurs/writers pris en charge et cliquez sur le plugin correspondant pour consulter les détails des paramètres.

2. Réduisez la concurrence.

   • Si vous configurez la tâche de synchronisation par lots en mode assistant, réduisez la valeur de Expected Maximum Concurrency dans Channel Control. Pour plus d'informations, reportez-vous à Configurer le contrôle des canaux en mode assistant.

   • Si vous configurez la tâche de synchronisation par lots en mode script, réduisez la valeur du paramètre concurrent dans Channel Control. Pour plus d'informations, reportez-vous à Configurer le contrôle des canaux en mode script.

3. Si vous synchronisez des fichiers, tels que des fichiers OSS, réduisez le nombre de fichiers à lire.

4. Dans la section Running Resources de la configuration de la tâche, augmentez la valeur de Resource Usage (CU) de manière appropriée. Définissez la valeur CU avec précaution pour éviter d'impacter d'autres tâches en cours d'exécution.

• Message d'erreur : Error updating database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'cfc68cd0048101467588e97e83ffd7a8-0' for key 'uk_uk_op'.

• Cause possible : Data Integration n'autorise pas l'exécution simultanée de différentes instances du même nœud (c'est-à-dire des tâches de synchronisation partageant la même configuration JSON). Par exemple, si une tâche de synchronisation suit une planification toutes les 5 minutes et que des retards en amont provoquent le déclenchement simultané à 00:05 de l'instance de 00:00 et de celle de 00:05, l'une des instances ne pourra pas démarrer. Ce cas de figure peut également se produire lorsque vous rechargez des données ou relancez une instance alors que l'instance de la tâche est encore en cours d'exécution.

• Solution : Échelonnez les heures d'exécution des instances. Pour les tâches planifiées à des intervalles horaires ou minutaires, nous vous recommandons de définir une auto-dépendance afin que l'instance actuelle ne démarre qu'après l'achèvement de l'instance du cycle précédent. Pour la configuration dans l'ancien Data Studio, reportez-vous à Auto-dépendance. Pour la configuration dans le nouveau Data Studio, reportez-vous à Configurer l'auto-dépendance.

• Détails de l'erreur : Lors d'une tâche de synchronisation des données, la tâche échoue avec l'erreur suivante : MongoDBReader$Task - operation exceeded time limitcom.mongodb.MongoExecutionTimeoutException: operation exceeded time limit.

• Cause possible : Le volume de données à extraire en mode complet est trop important.

• Solution :

  • Augmentez le niveau de concurrence.

  • Réduisez la valeur du paramètre BatchSize.

  • Ajoutez la configuration cursorTimeoutInMs dans la section des paramètres du Reader et définissez une valeur élevée, par exemple 3600000 ms.

• Erreur de lecture

  • Symptôme :

    Lors de la lecture des données, l'erreur suivante se produit : Communications link failure The last packet successfully received from the server was 7,200,100 milliseconds ago. The last packet sent successfully to the server was 7,200,100 milliseconds ago. - com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

  • Cause possible :

    La base de données exécute lentement les requêtes SQL, ce qui provoque un délai d'expiration de lecture MySQL.

  • Solution :

    • Vérifiez si une condition de filtre where est configurée et assurez-vous que les colonnes de filtrage sont indexées.

    • Vérifiez si la table source contient un volume de données excessif. Le cas échéant, divisez la tâche en plusieurs sous-tâches.

    • Consultez les journaux pour identifier l'instruction SQL à l'origine du blocage et rapprochez-vous de l'administrateur de la base de données pour résoudre le problème.

• Erreur d'écriture

  • Symptôme :

    Lors de l'écriture des données, l'erreur suivante se produit : Caused by: java.util.concurrent.ExecutionException: ERR-CODE: [TDDL-4614][ERR_EXECUTE_ON_MYSQL] Error occurs when execute on GROUP 'xxx' ATOM 'dockerxxxxx_xxxx_trace_shard_xxxx': Communications link failure The last packet successfully received from the server was 12,672 milliseconds ago. The last packet sent successfully to the server was 12,013 milliseconds ago. More...

  • Cause possible :

    Une requête lente entraîne un SocketTimeout. Le délai SocketTimeout par défaut pour les connexions TDDL est de 12 secondes. Si l'exécution d'une instruction SQL sur MySQL dépasse 12 secondes, une erreur 4614 est signalée. Cette erreur peut survenir ponctuellement lorsque le volume de données est important ou que le serveur est fortement sollicité.

  • Solution :

    • Patientez jusqu'à la stabilisation de la base de données, puis relancez la tâche de synchronisation.

    • Contactez l'administrateur de la base de données pour ajuster la valeur du délai d'expiration.

Cause possible 2 : Attente des ressources d'exécution Data Integration

Solution 2 : Si les journaux indiquent un statut WAIT prolongé, le groupe de ressources exclusives pour Data Integration utilisé par la tâche actuelle ne dispose pas d'une concurrence disponible suffisante pour exécuter la tâche. Pour plus de détails sur la cause et la solution, reportez-vous à Résoudre les problèmes de concurrence des groupes de ressources.

• Exemple de scénario

  La requête SQL exécutée est la suivante :

  SELECT bid,inviter,uid,createTime FROM `relatives` WHERE createTime>='2016-10-2300:00:00' AND reateTime<'2016-10-24 00:00:00';

  L'exécution a commencé à 2016-10-25 11:01:24.875 et les résultats ont commencé à être retournés à 2016-10-25 11:11:05.489. Le programme de synchronisation attendait que la base de données retourne les résultats de la requête SQL, et MaxCompute a dû patienter longtemps avant de pouvoir poursuivre l'exécution.

• Analyse de la cause racine

  La colonne createTime dans la clause WHERE n'est pas indexée, ce qui provoque un scan complet de la table.

• Solution

  Il est recommandé d'utiliser des colonnes indexées dans la clause where pour améliorer les performances. Vous pouvez également ajouter des index selon vos besoins.

Ancien Data Studio :

Vous pouvez modifier le groupe de ressources utilisé pour le débogage sur la page de détails de la tâche de synchronisation par lots dans DataStudio. Vous pouvez également changer le groupe de ressources d'exécution des tâches Data Integration utilisé lors de la planification dans Operation Center. Pour plus d'informations, reportez-vous à Changer le groupe de ressources Data Integration.

Nouveau Data Studio :

Vous pouvez modifier le groupe de ressources utilisé pour le débogage des tâches Data Integration dans DataStudio. Vous pouvez également changer le groupe de ressources d'exécution des tâches Data Integration utilisé lors de la planification dans Operation Center. Pour plus d'informations, reportez-vous à Changer le groupe de ressources Data Integration.

Données sales : Enregistrement dont l'écriture dans la source de données de destination échoue en raison d'une exception.

La tâche cumule le nombre d'enregistrements de données sales pendant son exécution. Dès que ce nombre dépasse le seuil de données sales configuré, la tâche s'arrête immédiatement.

• Conservation des données : Les données écrites avec succès vers la destination avant l'arrêt de la tâche sont conservées. Aucune annulation (rollback) n'est effectuée.

• Politique de tolérance zéro : Lorsque le seuil de données sales est défini sur 0, le système applique une politique de tolérance zéro. Cela signifie que la tâche échoue et s'arrête immédiatement dès la détection du premier enregistrement de données sales.

• Message d'erreur :

  Si les données contiennent des caractères emoji, des erreurs de données sales peuvent survenir lors de la synchronisation : [13350975-0-0-writer] ERROR StdoutPluginCollector - Dirty data {"exception":"Incorrect string value: '\\xF0\\x9F\\x98\\x82\\xE8\\xA2...' for column 'introduction' at row 1","record":[{"byteSize":8,"index":0,"rawData":9642,"type":"LONG"}],"type":"writer"} .

• Cause possible :

  • L'encodage de la base de données n'est pas défini sur utf8mb4, ce qui provoque des erreurs lors de la synchronisation de caractères emoji.

  • Les données sources elles-mêmes contiennent des caractères illisibles.

  • L'encodage de la base de données et celui du client sont incohérents.

  • L'encodage du navigateur est différent, ce qui entraîne des échecs de prévisualisation ou des caractères illisibles.

• Solution :

  Choisissez la solution appropriée en fonction de la cause des caractères illisibles :

  • Si les données d'origine contiennent des caractères illisibles, corrigez les données avant d'exécuter la tâche de synchronisation.

  • Si les formats d'encodage de la base de données et du client sont incohérents, modifiez d'abord le format d'encodage.

  • Si l'encodage du navigateur ne correspond pas à celui de la base de données ou du client, uniformisez les formats d'encodage avant de prévisualiser les données.

  Vous pouvez essayer les opérations suivantes :

  1. Pour les sources de données ajoutées au format JDBC, modifiez utf8mb4 comme suit : jdbc:mysql://xxx.x.x.x:3306/database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45.

  2. Pour les sources de données ajoutées par ID d'instance, ajoutez ce qui suit au nom de la base de données : database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45.

  3. Modifiez le format d'encodage de la base de données en utf8mb4. Par exemple, modifiez le format d'encodage de la base de données RDS depuis la console RDS.

     Remarque

     Commande pour définir le format d'encodage de la source de données RDS : set names utf8mb4. Commande pour vérifier le format d'encodage de la base de données RDS : show variables like 'char%'.

• Scénario : Lors de la synchronisation de données vers MaxCompute (ODPS), la tâche échoue ou les données écrites sont tronquées parce qu'un champ source dépasse 8 Mo.

• Cause : Pour les tâches de synchronisation utilisant MaxCompute comme destination, MaxCompute (ODPS) Writer impose une limite de taille de 8 Mo par champ.

• Solution :

  • Dans les paramètres avancés de la configuration MaxCompute (ODPS) Writer, définissez la politique de gestion des champs trop longs (overLengthRule) pour spécifier le traitement des champs surdimensionnés : tronquer le champ à 8 Mo, définir le champ sur NULL, ou écrire le champ tel quel sans troncature.

  • Pour les scénarios impliquant des objets volumineux, tels que des fichiers ou des journaux, stockez les données brutes dans Object Storage Service (OSS) et conservez uniquement l'URL dans la base de données. Utilisez ensuite DataWorks pour synchroniser l'URL plutôt que l'objet volumineux lui-même.

  • En tant qu'étape de prétraitement, divisez un champ surdimensionné en plusieurs sous-champs plus petits à la source, par exemple en segments de 7 Mo. Synchronisez les sous-champs séparément et concaténez-les à nouveau à la destination.

Lors de la création d'une table de destination, DataWorks conserve uniquement les noms de colonnes, les types de données et les commentaires de la table source. Il ne conserve pas les valeurs par défaut ni les contraintes (y compris les contraintes non-null et les index).

Les tâches de synchronisation par lots ne prennent pas en charge l'utilisation d'une clé primaire composite comme clé de fractionnement.

• Scénario : Une tâche de synchronisation incrémentielle échoue avec une erreur indiquant que la colonne de clé de fractionnement configurée (splitPk) est invalide.

• Cause possible : La configuration de la clé de fractionnement ne répond pas aux exigences. Par exemple, plusieurs colonnes sont configurées comme clé de fractionnement, le type de données de la colonne configurée n'est pas pris en charge, ou la colonne configurée n'existe pas dans la table.

• Solution :

  1. Actualisez le mappage de la table source pour afficher la colonne de clé de fractionnement suggérée automatiquement par le système.

  2. Assurez-vous qu'une seule colonne est configurée comme clé de fractionnement et que son type de données est un entier. Comme décrit précédemment dans ce document, splitPk ne prend en charge que le partitionnement des données basé sur des entiers et ne gère pas les chaînes de caractères, les nombres à virgule flottante, les dates ou d'autres types.

  3. Si la colonne suggérée automatiquement ne remplit pas ces conditions, modifiez manuellement la clé de fractionnement pour utiliser une colonne unique de type entier conforme aux exigences.

Pour plus d'informations sur l'impact de la clé de fractionnement sur les performances de synchronisation, reportez-vous à Comment diagnostiquer une tâche de synchronisation par lots dont l'exécution est longue ?

Si des problèmes de qualité des données surviennent après la synchronisation, reportez-vous à Résoudre les problèmes de qualité des données après synchronisation pour un diagnostic détaillé.

Q : Comment traiter l'erreur « Task have SSRF attacks » ?

Cause : Pour garantir la sécurité du cloud, DataWorks interdit aux tâches d'accéder aux adresses réseau internes du cloud via des adresses IP publiques. Lorsqu'une URL dans la configuration du plugin (comme HTTP Reader) pointe vers une adresse IP interne ou un nom de domaine VPC, ce contrôle de sécurité est déclenché.

Approche correcte :

• N'utilisez pas d'adresses IP internes telles que 10.x.x.x ou 192.168.x.x dans la configuration.

• Acquérez un groupe de ressources serverless (recommandé) ou un groupe de ressources exclusives pour Data Integration et configurez la connectivité VPC pour accéder en toute sécurité aux sources de données internes.

Solution : Pour les tâches accédant à des sources de données internes, cessez d'utiliser le groupe de ressources partagées et basculez vers un groupe de ressources serverless sécurisé (recommandé) ou un groupe de ressources exclusives pour Data Integration.

Basculez la tâche de synchronisation en mode script et ajoutez la configuration suivante dans la section setting de la page de configuration de la tâche :

"common": {
  "column": {
    "dateFormat": "yyyyMMdd",
    "datetimeFormatInNanos": "yyyyMMdd HH:mm:ss.SSS"
  }
}

Où :

• dateFormat spécifie le format de date utilisé lors de la conversion des données source de type DATE (sans heure) vers du texte.

• datetimeFormatInNanos spécifie le format de date utilisé lors de la conversion des données source de type DATETIME/TIMESTAMP (avec heure) vers du texte. Vous pouvez spécifier une précision allant jusqu'aux millisecondes.

1. Vous pouvez saisir des constantes. Les valeurs doivent être entourées de guillemets simples, comme 'abc' et '123'.

2. Vous pouvez utiliser des paramètres de planification, tels que '${bizdate}'. Pour plus d'informations sur l'utilisation des paramètres de planification, reportez-vous à Configurer les paramètres de planification.

3. Vous pouvez saisir les colonnes de partition à synchroniser, telles que pt.

4. Si la valeur saisie ne peut pas être analysée, le type est affiché comme 'Custom'.

5. Les fonctions ODPS ne sont pas prises en charge.

6. Si une colonne ajoutée manuellement apparaît comme Custom (par exemple, une colonne de partition MaxCompute ou une colonne LogHub non visible dans l'aperçu des données), cela n'affecte pas l'exécution réelle de la tâche.

Dans la liste de mappage des colonnes, cliquez sur Add ou Create Field sous les colonnes de la table source, saisissez le nom de la colonne de partition (tel que pt), et configurez le mappage vers la colonne de la table de destination.

En configurant MaxCompute Writer, vous pouvez réaliser des opérations de filtrage de colonnes, de réorganisation et de remplissage par des valeurs null que MaxCompute lui-même ne prend pas en charge. Par exemple, pour importer toutes les colonnes, configurez "column": ["*"].

Si la table MaxCompute comporte trois colonnes a, b et c, et que vous souhaitez synchroniser uniquement les colonnes c et b, configurez la liste des colonnes comme suit : "column": ["c","b"]. Cela signifie que la première et la deuxième colonne du Reader sont importées dans les colonnes c et b de la table MaxCompute, et que la colonne a nouvellement insérée dans la table MaxCompute est définie sur null.

Pour garantir la fiabilité de l'écriture des données et éviter les problèmes de qualité des données causés par la perte de données de colonnes supplémentaires, MaxCompute Writer signale une erreur si des colonnes supplémentaires sont écrites. Par exemple, si la table MaxCompute comporte les colonnes a, b et c, et que MaxCompute Writer tente d'écrire plus de trois colonnes, une erreur est signalée.

• Scénario : Une tâche de synchronisation par lots écrivant vers MaxCompute (ODPS) échoue, et le diagnostic montre que la table de destination contient une colonne de type JSON.

• Cause possible : MaxCompute Writer peut ne pas prendre en charge l'écriture vers une colonne de destination de type JSON dans tous les cas.

• Solution : Vérifiez le schéma de la table MaxCompute de destination pour confirmer s'il contient une colonne de type JSON. Si c'est le cas, essayez l'une des méthodes suivantes :

  • Changez le type de la colonne en STRING côté MaxCompute, par exemple en exécutant ALTER TABLE ADD COLUMN ou une modification de schéma équivalente.

  • Excluez la colonne de type JSON du mappage des champs afin qu'elle ne soit pas écrite lors de la synchronisation.

MaxCompute Writer prend uniquement en charge l'écriture vers la partition de dernier niveau et ne permet pas le routage de partitions basé sur une colonne. Si une table comporte trois niveaux de partitions, vous devez spécifier exactement la partition de troisième niveau dans la configuration des partitions. Par exemple, pour écrire des données dans la partition de troisième niveau, configurez-la comme suit : pt=20150101, type=1, biz=2. Vous ne pouvez pas la configurer comme pt=20150101, type=1 ou pt=20150101.

MaxCompute Writer garantit l'idempotence de l'écriture en configurant "truncate": true. Lorsqu'une écriture échoue et est relancée, MaxCompute Writer efface les données précédentes et importe les nouvelles données, garantissant ainsi la cohérence des données après chaque réexécution. Si la tâche est interrompue en raison d'autres exceptions pendant l'exécution, l'atomicité des données n'est pas garantie. Les données ne sont ni annulées ni automatiquement réexécutées. Exploitez la fonctionnalité d'idempotence pour réexécuter la tâche et assurer l'intégrité des données.

• Message d'erreur :

  Code:DATAX_R_ODPS_005:Failed to read ODPS data, Solution:[Please contact the ODPS administrator]. RequestId=202012091137444331f60b08cda1d9, ErrorCode=StatusConflict, ErrorMessage=The download session is expired.

• Cause possible :

  Lorsque la synchronisation par lots lit des données MaxCompute, elle utilise la commande tunnel MaxCompute pour charger et télécharger des données. Une session Tunnel a une durée de vie côté serveur de 24 heures. Par conséquent, si une tâche de synchronisation par lots s'exécute pendant plus de 24 heures, elle échoue. Pour plus d'informations sur tunnel, reportez-vous à Vue d'ensemble de Tunnel.

• Solution :

  Augmentez la concurrence de la tâche de synchronisation par lots et planifiez adéquatement le volume de données pour garantir que la tâche se termine dans un délai de 24 heures.

• Message d'erreur :

  Code:[OdpsWriter-09], Description:[Failed to write data to the ODPS destination table.]. - Failed to write block:0 to the ODPS destination table, uploadId=[202012081517026537dc0b0160354b]. Please contact the ODPS administrator for assistance. - java.io.IOException: Error writing request body to server。

• Cause possible :

  • Cause possible 1 : Exception de type de données, signifiant que les données source ne sont pas conformes aux spécifications de type de données ODPS. Par exemple, écrire la valeur 4.2223 dans un type de données decimal(18,10) dans ODPS.

  • Cause possible 2 : Exception de bloc ODPS ou de communication.

• Solution :

  Convertissez les types de données et utilisez des données conformes aux spécifications de type de données.

• Scénario : Une tâche de synchronisation par lots de base de données complète vers MaxCompute échoue avec ErrorCode=MethodNotAllowed, ErrorMessage=cdc mode not supported.

• Cause possible : Les attributs transactionnels ou de capture de données modifiées (CDC) de la table MaxCompute de destination peuvent ne pas correspondre au mode d'écriture utilisé par la tâche de synchronisation.

• Solution : Vérifiez si la table de destination est créée avec des attributs CDC ou transactionnels incompatibles avec le mode d'écriture de la tâche de synchronisation actuelle. Si vous n'êtes pas certain des attributs de la table, contactez le support technique pour confirmation.

• Scénario : Lorsque vous configurez une tâche de synchronisation par lots avec MaxCompute comme destination, le sélecteur Tunnel resource group dans la configuration de la destination ne liste pas un Serverless resource group acheté.

• Cause : Le groupe de ressources Tunnel et le groupe de ressources qui exécute la tâche de synchronisation, tel qu'un groupe de ressources Serverless, sont deux éléments de configuration indépendants ayant des objectifs différents. Le groupe de ressources Tunnel est utilisé uniquement pour la transmission des chargements et téléchargements de données MaxCompute, et il utilise par défaut la ressource de transmission publique, c'est-à-dire le quota MaxCompute Tunnel. Le groupe de ressources qui exécute la tâche sert uniquement à exécuter la tâche de synchronisation elle-même, y compris la lecture de la source, le traitement des données et la planification. Étant donné que ces deux configurations servent des objectifs différents, elles sont indépendantes et ne peuvent pas être utilisées de manière interchangeable.

Reportez-vous au document suivant pour la configuration : Synchroniser des tables MySQL partitionnées vers MaxCompute.

Ajoutez la source de données à l'aide d'une chaîne de connexion. Nous vous recommandons de modifier l'URL JDBC comme suit : jdbc:mysql://xxx.x.x.x:3306/database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45. Pour plus d'informations, consultez Ajouter une source de données MySQL.

• Cause de l'erreur :

  • net_read_timeout : DataX divise les données MySQL en plusieurs instructions SELECT de taille égale en fonction du SplitPk. Lors de l'exécution, l'une des instructions SQL dépasse la durée d'exécution maximale autorisée côté RDS.

  • net_write_timeout : Le délai d'attente pour l'envoi d'un bloc au client est défini sur une valeur trop faible.

• Solution :

  Ajoutez le paramètre à l'URL de connexion de la source de données, définissez net_write_timeout/net_read_timeout sur une valeur plus élevée, ou ajustez le paramètre dans la console RDS.

• Suggestion d'amélioration :

  Si la tâche peut être relancée, configurez-la pour qu'elle s'exécute automatiquement en cas d'erreur.

Exemple : jdbc:mysql://192.168.1.1:3306/lizi?useUnicode=true&characterEncoding=UTF8&net_write_timeout=72000

Cause de l'erreur :

Le paramètre MySQL wait_timeout est défini par défaut à 8 heures. Si des données sont encore en cours de récupération lorsque ce délai est atteint, la tâche de synchronisation est interrompue.

Solution :

Modifiez le fichier de configuration MySQL my.cnf (ou my.ini sous Windows). Ajoutez le paramètre sous le module MySQL (en secondes) : wait_timeout=2592000 interactive_timeout=2592000. Redémarrez ensuite MySQL et connectez-vous, puis exécutez l'instruction suivante pour vérifier : show variables like '%wait_time%'.

Une utilisation normale du CPU mais une consommation mémoire élevée peuvent entraîner la fermeture de la connexion.

Si vous confirmez que la tâche peut être relancée automatiquement, nous vous recommandons d'activer Auto Rerun on Error. Pour plus d'informations, consultez Configurer la relance automatique.

• Scénario : Lorsque l'outil de synchronisation par lots synchronise des données PostgreSQL, l'erreur suivante se produit : org.postgresql.util.PSQLException: FATAL: terminating connection due to conflict with recovery

• Cause possible : Cette erreur survient lorsque l'extraction des données de la base prend trop de temps. Augmentez les valeurs de max_standby_archive_delay et max_standby_streaming_delay. Pour plus d'informations, consultez Standby Server Events.

• Scénario : Une tâche de synchronisation en temps réel depuis AWS PostgreSQL vers MaxCompute échoue car l'utilisateur PostgreSQL source ne dispose pas du privilège REPLICATION.

• Cause possible : L'utilisateur PostgreSQL source ne possède pas le privilège REPLICATION. Sur certaines instances AWS RDS PostgreSQL gérées, cet attribut ne peut pas être accordé via ALTER ROLE.

• Solution : La synchronisation par lots (hors ligne, planifiée) ne nécessite pas le privilège REPLICATION. Si vous ne pouvez pas accorder ce privilège sur votre instance AWS PostgreSQL, utilisez une tâche de synchronisation par lots avec une planification périodique au lieu de la synchronisation en temps réel comme solution de contournement.

• Scénario : Après avoir synchronisé une colonne PostgreSQL timestamp (sans fuseau horaire) vers une colonne MaxCompute DATETIME, la valeur résultante présente un décalage, par exemple de 2 heures, par rapport à la valeur attendue.

• Cause possible : Le type PostgreSQL timestamp (sans fuseau horaire) stocke la valeur de l'heure locale telle quelle. Le type MaxCompute DATETIME stocke les valeurs en UTC et les convertit pour l'affichage en fonction du fuseau horaire du projet ou de la session. Cette différence de comportement de stockage et de conversion peut provoquer un décalage de fuseau horaire.

• Solution :

  1. Vérifiez si le fuseau horaire du serveur PostgreSQL, que vous pouvez obtenir en exécutant SHOW timezone;, correspond au fuseau horaire du projet MaxCompute. Vous pouvez consulter le fuseau horaire du projet sur la page Basic Information du projet MaxCompute.

  2. Si les fuseaux horaires diffèrent, configurez le fuseau horaire dans les paramètres avancés de la tâche de synchronisation par lots. Définissez le fuseau horaire de la tâche de synchronisation pour qu'il corresponde à celui du serveur PostgreSQL afin que les valeurs timestamp soient analysées dans ce fuseau horaire avant d'être écrites dans MaxCompute, ce qui élimine le décalage.

     Une incompatibilité de fuseau horaire entre la source et la destination se manifeste généralement par un décalage fixe de N heures dans chaque champ temporel. Par exemple, les deux extrémités sont configurées sur Asia/Bangkok mais les valeurs synchronisées diffèrent d'une heure, ou bien le groupe de ressources s'exécute en Allemagne et utilise par défaut Europe/Berlin alors que votre activité exige que les valeurs soient stockées en UTC. Dans ces cas-là, sélectionnez le fuseau horaire souhaité dans les paramètres avancés de la tâche.

  Remarque

  La modification du fuseau horaire de planification n'affecte pas le fuseau horaire utilisé par le processus Data Integration. Ces deux paramètres sont indépendants. Si les colonnes de date renvoient toujours des valeurs inattendues après l'ajustement du fuseau horaire de planification, définissez également le fuseau horaire explicitement dans les paramètres avancés de la tâche de synchronisation par lots.

  Le paramètre de fuseau horaire est défini par défaut sur GMT+8. Conservez cette valeur lorsque les champs temporels se synchronisent correctement, et ne la modifiez pour utiliser le fuseau horaire attendu par votre activité qu'en cas de décalage horaire. En mode script, ce paramètre équivaut à la configuration suivante :

  "common":{"column":{"timeZone":"Asia/Bangkok"}}

• Scénario : Lorsque vous configurez une condition WHERE ou une instruction querySql personnalisée pour une synchronisation incrémentielle depuis PostgreSQL, vous devez convertir un paramètre temporel au format chaîne en timestamp pour effectuer la comparaison.

• Solution : Utilisez la fonction PostgreSQL standard TO_TIMESTAMP au lieu de la fonction MySQL STR_TO_DATE, car PostgreSQL et MySQL utilisent des dialectes SQL différents pour convertir les chaînes de date et d'heure. Par exemple :

  TO_TIMESTAMP('${start_time}', 'YYYYMMDDHH24')
  TO_TIMESTAMP('${end_time}', 'YYYYMMDDHH24')

  TO_TIMESTAMP convertit une chaîne au format spécifié en un objet timestamp, que vous pouvez ensuite utiliser pour filtrer les lignes dans une plage temporelle via la condition WHERE ou l'instruction querySql.

• Scénario : Lorsqu'une tâche de synchronisation par lots lit des données depuis Oracle avec une condition WHERE, la tâche échoue avec l'erreur ORA-00932: inconsistent datatypes.

• Cause possible : La clause WHERE compare directement une colonne Oracle DATE avec une valeur NUMBER, par exemple un littéral de date écrit sous forme de nombre brut. Cette comparaison provoque une incompatibilité de type de données dans Oracle.

• Solution : Convertissez explicitement la valeur numérique de la date en type DATE avant la comparaison. Par exemple, utilisez TO_DATE('20250611', 'YYYYMMDD') ou le littéral DATE '2025-06-11' dans la condition WHERE au lieu de comparer la colonne avec un nombre brut.

Lors de la connexion à Amazon RDS, si vous recevez l'erreur Host is blocked, désactivez la vérification d'état de l'équilibreur de charge Amazon. Une fois cette vérification désactivée, le problème de blocage ne se reproduira plus.

Lors de l'ajout d'une source de données MongoDB, utilisez un utilisateur créé dans la base de données contenant les tables à synchroniser. L'utilisateur root n'est pas pris en charge.

Par exemple, si vous souhaitez importer la table name et que celle-ci se trouve dans la base de données test, le nom de la base de données doit être test et vous devez utiliser le nom d'un utilisateur créé dans cette base de données test.

Vous pouvez utiliser un nœud d'affectation pour convertir d'abord une valeur de type date en timestamp, puis transmettre cette valeur comme paramètre d'entrée pour la tâche de synchronisation des données MongoDB. Pour plus d'informations, consultez Comment implémenter une synchronisation incrémentielle pour les colonnes de type timestamp MongoDB ?

Définissez le fuseau horaire dans la configuration du lecteur MongoDB. Pour plus d'informations, consultez MongoDB Reader.

Vous pouvez redémarrer la tâche après un délai sans modifier les conditions de requête, c'est-à-dire retarder l'heure d'exécution de la tâche tout en conservant la configuration inchangée.

Lors de la lecture des données, le Column.name configuré par l'utilisateur respecte la casse. Une configuration incorrecte entraîne des données lues nulles. Par exemple :

• Données source MongoDB :

  {
      "MY_NAME": "zhangsan"
  }

• Configuration des colonnes de la tâche de synchronisation :

  {
      "column":
      [
          {
              "name": "my_name"
          }
      ]
  }

Étant donné que la casse de la configuration des colonnes ne correspond pas aux données source, la lecture des données échoue.

Le paramètre de configuration du délai d'expiration est cursorTimeoutInMs, dont la valeur par défaut est de 600 000 ms (10 minutes). Ce paramètre spécifie le temps total que MongoDB Server consacre à l'exécution de la requête, hors temps de transfert des données. Si le volume de données à lire est important, l'erreur suivante peut survenir : MongoDBReader$Task - operation exceeded time limitcom.mongodb.MongoExecutionTimeoutException: operation exceeded time limit.

Actuellement, les tâches de synchronisation DataWorks ne prennent pas en charge la lecture des données depuis un nœud secondaire. Si vous configurez un nœud secondaire pour la lecture, l'erreur suivante se produit : no master.

• Analyse de la cause racine :

  Causée par l'expiration du délai d'attente du curseur.

• Solution :

  Augmentez la valeur du paramètre cursorTimeoutInMs.

Augmentez la concurrence des tâches et la taille du lot de lecture (BatchSize).

• Cause possible :

  Par défaut, la tâche de synchronisation utilise la commande splitVector pour le partitionnement des tâches. Certaines versions de MongoDB ne prennent pas en charge la commande splitVector, ce qui provoque l'erreur no such cmd splitVector.

• Solution :

  1. Accédez à la page de configuration de la tâche de synchronisation et cliquez sur le bouton Convert to Script situé en haut. Passez la tâche en mode script.

  2. Dans la configuration des paramètres MongoDB, ajoutez le paramètre suivant :

     "useSplitVector" : false

     Cela évite l'utilisation de splitVector.

• Message d'erreur :

  Dans la tâche de synchronisation, en prenant l'exemple du mode assistant, ce problème peut survenir lorsque Write Mode (Overwrite) est défini sur Yes et qu'une colonne autre que _id est configurée comme Business Key.

  Dans la configuration de destination de la tâche de synchronisation, sélectionnez la source de données MongoDB (nom de l'instance : xc_mongo_rds), définissez le nom de la collection sur xc_timestamp, activez le mode écrasement (définissez 'Overwrite' sur Yes) et spécifiez my_id comme clé primaire métier."

• Cause possible :

  Les données écrites contiennent des enregistrements où le champ _id ne correspond pas à la Business Key configurée (comme my_id dans l'exemple ci-dessus).

• Solution :

  • Option 1 : Modifiez la tâche de synchronisation par lots pour vous assurer que la Business Key configurée est identique au champ _id.

  • Option 2 : Utilisez _id comme clé primaire métier lors de la synchronisation des données.

• Cause :

  Lorsque Redis utilise le mode hash pour le stockage, les attributs et les valeurs du hash doivent apparaître par paires. Par exemple : odpsReader: "column":[ "id", "name", "age", "address" ]. Dans la destination, si RedisWriter est configuré comme suit : "keyIndexes":[ 0, 1], alors dans Redis, id et name servent de clé, age sert d'attribut et address sert de valeur dans le type hash. Si seules deux colonnes sont configurées sur la source ODPS, le mode hash ne peut pas être utilisé pour le stockage Redis et cette exception est levée.

• Solution :

  Si vous souhaitez utiliser uniquement deux colonnes, configurez le mode String de Redis pour le stockage. Si vous devez impérativement utiliser le mode hash, configurez au moins trois colonnes côté source.

• Symptôme :

  Lors de la configuration d'une tâche de synchronisation par lots pour lire des données depuis un stockage de fichiers tel que OSS ou FTP, si le fichier est au format CSV et utilise plusieurs caractères comme délimiteur de colonne (comme |,, ##, ou ;;), la tâche peut échouer avec une erreur de données sales. Dans le journal d'exécution, vous verrez une erreur IndexOutOfBoundsException accompagnée de données sales.

• Analyse de la cause racine :

  Le lecteur csv intégré ("fileFormat": "csv") dans DataWorks présente des limitations lors du traitement des délimiteurs multi-caractères, ce qui entraîne un découpage imprécis des colonnes pour les lignes de données.

• Solution :

  • Mode Assistant : Basculez le type de texte sur text et spécifiez explicitement le délimiteur multi-caractères.

  • Mode Script : Remplacez "fileFormat": "csv" par "fileFormat": "text" et définissez correctement le délimiteur : "fieldDelimiter":"<multi-char delimiter>", "fieldDelimiterOrigin":"<multi-char delimiter>".

La synchronisation par lots elle-même ne limite pas le nombre de fichiers lus par le plugin OSS Reader. La principale limitation provient des ressources CU consommées par la tâche. La lecture d'un trop grand nombre de fichiers simultanément peut facilement provoquer des erreurs de mémoire insuffisante. Par conséquent, nous vous déconseillons de configurer le paramètre objet sur : *, afin d'éviter les erreurs OutOfMemoryError: Java heap space .

OSS Writer écrit les noms de fichiers en simulant des répertoires à l'aide de noms d'objets. OSS impose des restrictions sur les noms d'objets. Lors de l'utilisation de "object": "datax", les objets écrits commencent par datax, suivis de suffixes de chaînes aléatoires. Le nombre de fichiers dépend du nombre réel de tâches fractionnées.

Si vous n'avez pas besoin de suffixes UUID aléatoires, configurez "writeSingleObject" : "true". Pour plus d'informations, consultez la description du paramètre writeSingleObject dans la documentation OSS Writer.

• Cause :

  L'AccessKey configuré pour la source de données ne dispose pas des permissions sur le bucket.

• Solution :

  Accordez des permissions de lecture sur le bucket au compte AccessKey configuré pour la source de données OSS.

• Analyse de la cause racine :

  Le paramètre mapred.task.timeout est peut-être défini sur une valeur trop faible, ce qui amène Hadoop à terminer la tâche et à nettoyer le répertoire temporaire, rendant les données temporaires indisponibles.

• Solution :

  Dans la section source de données de la tâche de synchronisation par lots, si Hive read methods est défini sur Read Data Based on Hive JDBC (Supports Conditional Filtering), définissez la valeur du paramètre mapred.task.timeout dans Session Configuration, par exemple mapred.task.timeout=600000.

• Message d'erreur :

  ERROR JobContainer - Exception when job runcom.alibaba.datax.common.exception.DataXException: Code:[DatahubWriter-04], Description:[Failed to write data.]. - com.aliyun.datahub.exception.DatahubServiceException: Record count 12498 exceed max limit 10000 (Status Code: 413; Error Code: TooLargePayload; Request ID: 20201201004200a945df0bf8e11a42)

• Cause possible :

  Cette erreur survient parce que le volume de données soumis par DataX à DataHub en un seul lot dépasse la limite de DataHub. Les principaux paramètres de configuration qui affectent le volume de données soumis à DataHub sont :

  • maxCommitSize : Spécifie la taille cumulée des données en mémoire tampon. Lorsque les données accumulées atteignent la valeur maxCommitSize (en Mo), elles sont soumises à la destination par lots. La valeur par défaut est de 1 Mo (1 048 576 octets).

  • batchSize : Spécifie le nombre cumulé d'enregistrements de données en mémoire tampon pour DataX-On-Flume. Lorsque le nombre d'enregistrements accumulés atteint la valeur batchSize, les données sont soumises à la destination par lots.

• Solution :

  Réduisez les valeurs des paramètres maxCommitSize et batchSize.

Ce plugin respecte la casse pour les noms de colonnes. Vérifiez la configuration des colonnes du LogHub Reader.

Data Integration utilise l'heure à laquelle les données entrent dans LogHub. Consultez la console LogHub pour vérifier si la colonne de métadonnées receive_time se situe dans la plage horaire configurée pour la tâche.

Si cela se produit, modifiez manuellement la configuration des colonnes dans l'interface utilisateur.

L'heure de début et l'heure de fin configurées dans la tâche de synchronisation par lots sont utilisées par le Reader pour appeler l'API SLS GetCursor afin de localiser les curseurs de début et de fin. Cette heure sert à déterminer la plage de lecture en fonction de l'heure de réception côté serveur SLS. La tâche lit effectivement les données dans la plage de curseurs, ce qui n'équivaut pas à un filtrage basé sur la colonne de sortie __time__.

La colonne de sortie __time__ provient de log.getTime() de chaque entrée de journal, représentant l'heure propre au journal. Les requêtes de la console SLS utilisent généralement la plage horaire de requête, les instructions de requête et les colonnes d'index pour les statistiques, en se basant couramment sur l'heure du journal __time__. Par conséquent, même si la tâche de synchronisation et la console utilisent les mêmes valeurs temporelles, la plage __time__ ou le nombre d'enregistrements peut différer si les deux parties utilisent des métriques temporelles différentes.

Scénarios courants :

1. Lorsque la collecte ou la livraison des journaux est retardée, que des journaux historiques sont réinjectés ou que les horloges des clients sont inexactes, l'heure du journal __time__ peut être antérieure ou postérieure à l'heure de réception côté serveur SLS. La tâche de synchronisation localise les curseurs en fonction de l'heure de réception côté serveur, tandis que la console effectue ses requêtes en fonction de __time__, ce qui peut produire des résultats différents.

2. Lorsque des données sont écrites dans un autre LogStore via la transformation de données SLS, si l'instruction de transformation ne définit pas explicitement __time__, le __time__ du journal cible conserve généralement l'heure du journal source plutôt que l'heure d'exécution de la transformation. Dans ce cas, la tâche de synchronisation peut lire ce lot de données dans la plage horaire où la transformation écrit dans le LogStore cible. Cependant, lors d'une requête sur la console du LogStore cible basée sur l'heure d'exécution de la transformation ou la plage horaire actuelle, ces journaux peuvent ne pas être trouvés. Vous devez effectuer une requête basée sur la plage __time__ réelle des journaux.

3. Lorsque l'instruction de requête de la console, les colonnes d'index, la plage horaire et l'instruction de filtrage par règle (SPL) dans la tâche de synchronisation sont incohérents, le nombre d'enregistrements peut différer même si les métriques temporelles sont identiques.

Suggestions de dépannage :

1. Vérifiez si la plage horaire de requête de la console, l'instruction de requête, les colonnes d'index ainsi que l'heure de début/fin et l'instruction de filtrage par règle (SPL) dans la tâche de synchronisation sont cohérents.

2. Incluez à la fois __time__ (heure du journal) et __tag__:__receive_time__ (le champ observable pour l'heure de réception côté serveur SLS, qui nécessite l'existence de ce champ dans les tags du journal) dans la configuration column pour comparer l'heure du journal avec l'heure de réception côté serveur.

3. Si les données proviennent d'une transformation de données SLS, vérifiez si l'instruction de transformation définit explicitement __time__, et ajustez la plage horaire de requête de la console dans le LogStore cible en fonction du __time__ réel.

4. Si une réconciliation stricte par heure de journal est requise en aval, filtrez ou agrégez par __time__ après l'écriture dans la destination.

Exemple : Le __time__ du journal source est 2026-06-01 10:00:00. Une tâche de transformation de données SLS écrit ce journal dans le LogStore cible à 2026-06-12 10:00:00 sans modifier explicitement __time__. Le __time__ du journal cible reste 2026-06-01 10:00:00. Si les heures de début et de fin de la tâche de synchronisation couvrent 2026-06-12 10:00:00, la tâche peut lire ce journal. Cependant, lors d'une requête sur le LogStore cible dans la console autour de 2026-06-12 10:00:00 avec __time__ comme filtre, ce journal peut ne pas être trouvé. Dans ce cas, ajustez l'heure de requête de la console autour de 2026-06-01 10:00:00, ou définissez explicitement le __time__ du journal cible lors de la transformation des données selon vos besoins.

Le Reader fait correspondre les noms de colonnes à partir des champs du contenu réel du journal extrait, des mappages de méta-champs intégrés du Reader et des LogTag en fonction de la configuration column. Les noms de colonnes respectent la casse. Si aucune correspondance n'est trouvée, null est généré sans erreur.

Les causes courantes incluent :

1. Le nom de colonne configuré dans column a une casse différente de celle de la clé de champ du journal d'origine.

2. La console affiche des alias provenant de l'analyse de requête, des champs d'index ou des champs JSON développés, qui diffèrent de la clé de journal d'origine que le Reader récupère réellement.

3. La colonne provient en réalité d'un LogTag et doit être configurée sous la forme __tag__:<tagKey>.

4. Après la configuration d'une instruction de filtrage par règle (SPL) ou d'une transformation, les noms de champs de sortie ne correspondent pas entièrement à la configuration column.

Lors du dépannage, vérifiez d'abord les colonnes de la table source et l'aperçu des données sur la page visuelle pour confirmer les champs que le Reader identifie réellement. En mode script, vous pouvez également définir temporairement column sur ["*"] pour voir les clés de champ de contenu de journal réelles récupérées par le Reader, puis configurer column en fonction des clés d'origine.

Le comportement est identique à la logique d'écriture de l'API : les données situées dans la même ligne et la même colonne sont écrasées, tandis que les autres données restent inchangées.

Récupérez le mapping de l'index ES à l'aide de la commande curl et extrayez toutes les colonnes du mapping.

• Commande Shell pour l'interrogation :

  //es7
  curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/_mapping'
  //es6
  curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/typename/_mapping'

• Récupération des colonnes à partir du résultat :

  {
      "indexname": {
          "mappings": {
              "typename": {
                  "properties": {
                      "field1": {
                          "type": "text"
                      },
                      "field2": {
                          "type": "long"
                      },
                      "field3": {
                          "type": "double"
                      }
                  }
              }
          }
      }
  }

  Les colonnes et les définitions d'attributs sous properties dans la réponse constituent l'ensemble des colonnes de l'index. Par exemple, l'index ci-dessus contient trois colonnes : field1, field2 et field3.

Vous pouvez ajouter des paramètres de planification de date à la configuration de l'index pour calculer automatiquement la chaîne d'index en fonction des différentes dates, permettant ainsi la modification automatique du nom de l'index Elasticsearch Reader. La configuration comprend trois étapes : la définition des paramètres de date, la configuration des paramètres d'index, ainsi que le déploiement et l'exécution de la tâche.

1. Définir les paramètres de date : Dans les paramètres de planification de la tâche de synchronisation, ajoutez des paramètres pour définir les paramètres de date. La configuration var1 suivante représente l'heure d'exécution de la tâche (jour actuel), et var2 représente la date métier (jour précédent).

2. Configurer les paramètres d'index : Passez la tâche en mode script et configurez l'index Elasticsearch Reader en utilisant le format : ${variable_name}, comme indiqué ci-dessous.

   {
       "type": "job",
       "version": "2.0",
       "steps": [
           {
               "stepType": "elasticsearch",
               "parameter": {
                   "retryCount": 30,
                   "scroll": "10m",
                   "column": [
                       "col18",
                       "col17"
   
                   ],
                   "index": "esstress_1_${var1}_${var2}",
                   "pageSize": 100,
                   "sort": {
                       "_id": "asc"
                   },

3. Déployer et exécuter la tâche : Après vérification, envoyez et déployez la tâche dans Operation Center, puis exécutez-la en tant que tâche planifiée périodiquement ou tâche de réinjection de données.

   1. Cliquez sur le bouton Running with Parameters pour exécuter directement la tâche à des fins de vérification. L'exécution avec paramètres remplace les paramètres du système de planification utilisés dans la configuration de la tâche. Après l'exécution, vérifiez les journaux pour vous assurer que l'index synchronisé répond aux attentes.

      Remarque

      Lors de l'exécution avec paramètres, saisissez directement les valeurs des paramètres pour effectuer des tests de remplacement.

   2. Si l'étape précédente confirme le bon fonctionnement, la configuration de la tâche est terminée. Cliquez sur Save puis sur Commit pour soumettre la tâche de synchronisation à l'environnement de production.

      Pour un espace de travail en mode standard, cliquez sur Deploy pour accéder au Deployment Center et déployer la tâche de synchronisation dans l'environnement de production.

4. Résultat : La configuration et le résultat d'exécution réel de l'index sont présentés ci-dessous.

   Configuration de l'index du script : "index": "esstress_1_${var1}_${var2}".

   Index résolu lors de l'exécution : esstress_1_20230106_20230105.

   ],
   "full":false,
   "gmtCreate":"2022-07-18 14:47:18",
   "gmtModified":"2022-07-18 14:47:18",
   "index":"esstress_1_20230106_20230105",
   "instanceId":"es-cn-2r42se1je001zwmt0",
   "ownerId":"1224800975333052",
   "pageSize":100,
   "password":"********",
   "privateNetworkIpWhiteList":[
       "0.0.0.0/0"
   ],

La synchronisation des propriétés de champs objet nécessite obligatoirement le mode script. Dans ce mode, configurez multi comme suit et spécifiez column en utilisant le format attribut.sous-attribut.

"multi":{
   "multi":true 
 }

Reportez-vous à l'exemple suivant pour la configuration :

#Example:
##Data in Elasticsearch
"hits": [
    {
        "_index": "mutiltest_1",
        "_type": "_doc",
        "_id": "7XAOOoMB4GR_1Dmrrust",
        "_score": 1.0,
        "_source": {
            "level1": {
                "level2": [
                    {
                        "level3": "testlevel3_1"
                    },
                    {
                        "level3": "testlevel3_2"
                    }
                ]
            }
        }
    }
]
##Reader configuration
"parameter": {
  "column": [
      "level1",
      "level1.level2",
      "level1.level2[0]"
  ],
  "multi":{
        "multi":true
    }
}
##Writer result: 1 row with 3 columns, column order matches reader configuration
COLUMN              VALUE
level1:             {"level2":[{"level3":"testlevel3_1"},{"level3":"testlevel3_2"}]}
level1.level2:      [{"level3":"testlevel3_1"},{"level3":"testlevel3_2"}]
level1.level2[0]:   {"level3":"testlevel3_1"}

1. Les guillemets doubles supplémentaires affichés avant et après les caractères résultent d'un problème d'affichage dans Kibana. Les données réelles ne contiennent pas ces guillemets doubles en début et en fin de chaîne. Utilisez la commande curl ou Postman pour consulter les données réelles. La commande curl permettant de récupérer les données est la suivante :

   //es7
   curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/_mapping'
   //es6
   curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/typename/_mapping'

2. Vous pouvez configurer le type de colonne d'écriture ES sur nested pour synchroniser des données de chaîne de type JSON depuis ODPS vers ES au format nested. L'exemple suivant synchronise la colonne name vers ES au format nested.

   • Configuration de la synchronisation : Définissez le type de name sur nested.

   • Résultat de la synchronisation : name est un type d'objet nested.

     "total": {
         "value": 1,
         "relation": "eq"
     },
     "max_score": 1.0,
     "hits": [
         {
             "_index": "test",
             "_type": "_doc",
             "_id": "bb5oqoUBlqHPyI16REEQ",
             "_score": 1.0,
             "_source": {
                 "name": [
                     {
                         "fields1": "value"
                     }
                 ]
             }
         }
     ]
     }

Deux méthodes permettent d'écrire des types tableau vers ES. Choisissez la méthode de synchronisation appropriée selon le format des données source.

• Écrivez vers ES en tant que type tableau en analysant les données source comme du JSON. Par exemple, si les données source sont "[1,2,3,4,5]", configurez json_array=true pour analyser les données source et les écrire dans la colonne ES sous forme de tableau. Configurez ColumnList avec json_array=true.

  • Configuration en mode assistant.

  • Configuration en mode script :

    "column":[
      {
        "name":"docs",
        "type":"keyword",
        "json_array":true
      }
    ]

• Écrivez vers ES en tant que type tableau en analysant les données source avec un délimiteur. Par exemple, si les données source sont "1,2,3,4,5", configurez un délimiteur splitter="," pour analyser et écrire les données dans la colonne ES sous forme de tableau.

  • Limitations :

    • Une tâche n'accepte qu'un seul délimiteur. Le splitter est globalement unique et ne permet pas d'utiliser des délimiteurs différents pour différentes colonnes de tableau. Par exemple, pour les colonnes source col1="1,2,3,4,5" , col2="6-7-8-9-10", il est impossible de configurer le splitter séparément pour chaque colonne.

    • Le splitter peut être configuré comme une expression régulière. Par exemple, si la valeur de la colonne source est "6-,-7-,-8+,*9-,-10", vous pouvez configurer splitter:".,.", ce qui est pris en charge en mode assistant.

  • Configuration en mode assistant : splitter prend la valeur par défaut "-,-".

  • Configuration en mode script :

    "parameter" : {
          "column": [
            {
              "name": "col1",
              "array": true,
              "type": "long"
            }
          ],
          "splitter":","
    }

• Analyse de la cause racine :

  HttpClient impose qu'à chaque établissement de connexion, une requête non authentifiée soit d'abord envoyée. Une fois que le serveur retourne l'exigence d'authentification (en spécifiant la méthode d'authentification basée sur la réponse), une requête authentifiée est alors effectuée. Étant donné que chaque écriture de données ES nécessite l'établissement d'une connexion, chaque opération génère une requête non authentifiée qui est ensuite enregistrée dans les journaux d'audit.

• Solution :

  Ajoutez la configuration "preemptiveAuth":true en mode script.

Deux méthodes permettent de configurer l'écriture de dates. Choisissez celle qui correspond à vos besoins.

• Écrivez directement dans la colonne Date ES en fonction du contenu lu par le Reader :

  • Configurez origin:true pour écrire le contenu lu directement dans ES.

  • Configurez "format" pour spécifier l'attribut de format de la colonne lors de la création du mapping via l'écriture ES.

    "parameter" : {
        "column": [
            {
                "name": "col_date",
                "type": "date",
                "format": "yyyy-MM-dd HH:mm:ss",
                "origin": true
            }
              ]
    }

• Conversion de fuseau horaire : Si Data Integration doit effectuer une conversion de fuseau horaire, ajoutez le paramètre Timezone.

  "parameter" : {
      "column": [
          {
              "name": "col_date",
              "type": "date",
              "format": "yyyy-MM-dd HH:mm:ss",
              "Timezone": "UTC"
          }
            ]
  }

• Le type type:version est configuré, mais ES ne prend pas en charge la spécification d'une version externe.

      "column":[
                              {
                                  "name":"id",
                                  "type":"version"
                              },
    ]

• Solution :

  Supprimez la configuration "type":"version". Elasticsearch Writer ne prend pas en charge la spécification de version externe.

• Analyse de la cause racine :

  Elasticsearch Reader ne parvient pas à analyser le format de date d'une colonne de type date car aucun format n'est configuré dans le mapping de la colonne de date ES correspondante.

• Solution :

  • Configurez le paramètre dateFormat avec le même format que celui de la colonne de date ES, en utilisant "||" comme séparateur. Le format doit inclure tous les formats de type date. Exemple :

    "parameter" : {
          "column": [
         			"dateCol1",
            	"dateCol2",
              "otherCol"
          ],
         "dateFormat" : "yyyy-MM-dd||yyyy-MM-dd HH:mm:ss",
    }

  • Définissez le format de mapping pour toutes les colonnes de date dans la base de données ES.

• Analyse de la cause racine :

  En raison des limitations de mots-clés de fastjson, l'index ou les colonnes peuvent contenir des mots-clés tels que $ref.

• Solution :

  Elasticsearch Reader ne prend pas en charge la synchronisation d'index contenant le mot-clé $ref dans les noms de colonnes. Pour plus d'informations, consultez Elasticsearch Reader.

• Analyse de la cause racine :

  Cela a déclenché le mécanisme de verrouillage optimiste d'ES. Le numéro de version actuel devrait avoir une valeur spécifique, mais le numéro de version transmis par la commande de mise à jour est différent, ce qui provoque un conflit de versions. Pendant la mise à jour, une autre opération supprimait des données d'index.

• Solution :

  1. Vérifiez si des opérations de suppression de données sont en cours.

  2. Modifiez la méthode de synchronisation de la tâche de Update à Index.

• Analyse de la cause racine :

  Lorsque vous configurez des attributs avancés tels que similarity et properties pour une colonne, other_params est nécessaire pour que le plugin puisse les reconnaître.

  "parameter":{
          "__datasource__type":"elasticsearch",
          "actionType":"index",
          "aliasMode":"append",
          "batchSize":1024,
          "cleanup":false,
          "column":[
              {
                  "name":"id",
                  "type":"long"
              },
              {
                  "name":"dim1_code",
                  "type":"keyword"
              },
              {
                  "analyzer":"china",
                  "name":"dim1_name",
                  "similarity":"len_similarity",
                  "type":"text"
              },
              {
                  "analyzer":"china",
                  "name":"dim1_val",
                  "similarity":"len_similarity",
                  "type":"text"
              },
              {
                  "name":"dim1_sort",
                  "type":"long"
              }

• Solution :

  Configurez other_params dans la configuration de la colonne, puis ajoutez similarity à l'intérieur de other_params, comme suit :

  {"name":"dim2_name",...,"other_params":{"similarity":"len_similarity"}}

• Analyse de la cause racine :

  Actuellement, l'écriture par synchronisation batch vers Elasticsearch ne prend pas en charge le type dense_vector. Seuls les types suivants sont pris en charge :

  ID,PARENT,ROUTING,VERSION,STRING,TEXT,KEYWORD,LONG,
  INTEGER,SHORT,BYTE,DOUBLE,FLOAT,DATE,BOOLEAN,BINARY,
  INTEGER_RANGE,FLOAT_RANGE,LONG_RANGE,DOUBLE_RANGE,DATE_RANGE,
  GEO_POINT,GEO_SHAPE,IP,IP_RANGE,COMPLETION,TOKEN_COUNT,OBJECT,NESTED;

• Solution :

  Pour les types non pris en charge par Elasticsearch Writer, procédez comme suit :

  • Il est déconseillé d'utiliser Elasticsearch Writer pour créer des mappings d'index. Utilisez plutôt un mapping personnalisé.

  • Remplacez le type correspondant par NESTED.

  • Modifiez la configuration comme suit : dynamic = true, cleanup=false.

• Cause :

  #Incorrect configuration
  "settings": {
    "index": {
      "number_of_shards": 1,
      "number_of_replicas": 0
    }
  }
  #Correct configuration
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 0
  }

• Solution :

  Les paramètres Settings ne prennent effet que lors de la création d'un index, ce qui couvre deux cas : l'index n'existe pas, ou cleanup=true. Lorsque cleanup=true, la configuration Settings n'a pas besoin d'inclure "index".

#Original mappings
{
  "name":"box_label_ret",
  "properties":{
    "box_id":{
      "type":"keyword"
    }
}
#After rebuilding with cleanup=true, it becomes
{
    "box_label_ret": {
      "properties": {
        "box_id": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }}}}
}

• Analyse de la cause racine :

  Pour les types nested, Elasticsearch Writer utilise uniquement les mappings de niveau supérieur et laisse ES adapter automatiquement les types complexes nested. Le changement du type d'attribut vers text avec l'ajout de fields:keyword correspond au comportement d'auto-adaptation d'ES et n'affecte pas son utilisation. Si vous avez besoin d'un format de mapping spécifique, consultez Elasticsearch Writer.

• Solution :

  Créez les mappings d'index ES attendus avant la synchronisation, puis définissez cleanup sur false dans la tâche de synchronisation ES et exécutez la tâche.

Kafka Reader lit les données par lots. Dans un lot de données, si des enregistrements dépassent endDateTime, la synchronisation s'arrête. Toutefois, les données du lot qui dépassent endDateTime sont tout de même écrites dans la source de données cible.

• Vous pouvez également utiliser la configuration skipExceedRecord pour indiquer s'il faut synchroniser les données excédentaires. Pour plus de détails, consultez Kafka Reader. [Il est déconseillé de désactiver cette synchronisation, car cela risque d'entraîner une perte de données.]

• Vous pouvez configurer le paramètre max.poll.records de Kafka pour spécifier la quantité de données récupérées à chaque lot. Combiné à la concurrence, cela permet de contrôler le volume de données susceptible de dépasser la limite. Le volume de données excédentaire < max.poll.records × concurrence.

• Analyse de la cause racine :

  Lorsque le volume de données est faible ou que les données sont réparties de manière inégale, certaines partitions Kafka peuvent ne recevoir aucune nouvelle donnée ou les nouvelles données peuvent ne pas atteindre l'offset de fin spécifié. Comme la condition de sortie de la tâche exige que toutes les partitions atteignent l'offset de fin spécifié, ces partitions « inactives » ne peuvent pas satisfaire cette condition, empêchant ainsi la tâche entière de se terminer normalement.

• Solution :

  Définissez la politique de fin de synchronisation sur 1 minute sans lecture de nouvelles données (en mode script, définissez stopWhenPollEmpty sur true et stopWhenReachEndOffset sur true). La tâche se termine après avoir lu les données du dernier offset de toutes les partitions, évitant ainsi une exécution inactive. Cependant, les enregistrements dont l'horodatage est antérieur à l'offset de fin configuré et qui sont écrits après la fin de la tâche ne seront pas consommés.

RestAPI Writer propose deux modes d'écriture. Lors de la synchronisation de plusieurs enregistrements, définissez dataMode sur multiData et ajoutez le paramètre dataPath:"data.list" dans le script. Pour plus d'informations, consultez RestAPI Writer.

1. La configuration d'OTS Writer doit respecter les deux exigences suivantes :

   "newVersion": "true",
   "enableAutoIncrement": "true",

2. Le nom de la colonne de clé primaire auto-incrémentée ne doit pas être configuré dans OTS Writer.

3. Le nombre d'entrées primaryKey + le nombre d'entrées column configurées dans OTS Writer doit être égal au nombre de colonnes dans les données OTS Reader en amont.

Exemple : Un enregistrement de données comporte trois tags : [phone=xiaomi, RAM=8G, camera=LEICA].

• Exemple d'exportation de données (OTS Reader)

  • Pour fusionner les tags ci-dessus en une seule colonne pour l'exportation, configurez comme suit :

    "column": [
          {
            "name": "_tags",
          }
        ],

    DataWorks exporte les tags sous forme d'une seule colonne de données au format suivant :

    ["phone=xiaomi","camera=LEICA","RAM=8G"]

  • Pour exporter le tag phone et le tag camera en tant que colonnes distinctes, configurez comme suit :

    "column": [
          {
            "name": "phone",
            "is_timeseries_tag":"true",
          },
          {
            "name": "camera",
            "is_timeseries_tag":"true",
          }
        ],

    DataWorks exporte deux colonnes de données au format suivant :

    xiaomi, LEICA

• Exemple d'importation de données (OTS Writer)

  La source de données en amont (Reader) contient deux colonnes de données :

  • Une colonne contient : ["phone=xiaomi","camera=LEICA","RAM=8G"].

  • L'autre colonne contient : 6499.

  Pour ajouter ces deux colonnes aux tags, le format attendu du champ tag après l'écriture est le suivant : Configurez comme suit :

  "column": [
        {
          "name": "_tags",
        },
        {
          "name": "price",
          "is_timeseries_tag":"true",
        },
      ],

  • La configuration de la première colonne importe ["phone=xiaomi","camera=LEICA","RAM=8G"] dans son ensemble dans le champ tag.

  • La configuration de la deuxième colonne importe price=6499 individuellement dans le champ tag.

Si vos noms de tables suivent un modèle régulier, tel que orders_20170310, orders_20170311 et orders_20170312, où les tables sont distinguées par date et partagent la même structure, vous pouvez utiliser des paramètres de planification (Configurer des tâches de synchronisation en mode script) pour personnaliser le nom de la table et lire automatiquement les données de la table de la veille depuis la base de données source chaque matin.

En mode script, remplacez le nom de la table source par une variable, telle que orders_${tablename}. Puisque les tables sont distinguées par date et que vous devez lire quotidiennement les données de la veille, attribuez la valeur de la variable dans la configuration des paramètres de la tâche comme suit : tablename=${yyyymmdd}.

Accédez à la page de configuration de la tâche de synchronisation, modifiez les mappages de colonnes pour mettre à jour les colonnes modifiées dans la configuration de la tâche, puis soumettez et exécutez à nouveau la tâche pour que les changements prennent effet.

Lors de la configuration d'un nœud de synchronisation batch, la section Source affiche par défaut uniquement les 25 premières tables de la source de données sélectionnée. S'il y a davantage de tables, saisissez le nom de la table pour effectuer une recherche ou utilisez le mode script pour le développement.

• Cause de l'erreur : La configuration de colonne contient des mots-clés réservés, ou elle contient des colonnes commençant par un chiffre.

• Solution : Basculez la tâche de synchronisation Data Integration en mode script et échappez les colonnes spéciales dans la configuration des colonnes. Pour configurer des tâches en mode script, consultez Configurer des tâches de synchronisation en mode script.

  • Le caractère d'échappement pour MySQL est keyword.

  • Le caractère d'échappement pour Oracle et PostgreSQL est "keyword".

  • Le caractère d'échappement pour SQL Server est [keyword].

  Exemple MySQL :

  {
      "stepType": "mysql",
      "parameter": {
          "envType": 0,
          "datasource": "wpw_test_mysql",
          "column": [
              "id",
              "`order`",
              "`add`"
          ],
          "connection": [
              {
                  "datasource": "wpw_test_mysql",
                  "table": [
                      "abc"
                  ]
              }

• Prenons une source de données MySQL comme exemple :

  1. Exécutez l'instruction suivante pour créer une table nommée aliyun : create table aliyun (

  2. Exécutez l'instruction suivante pour créer une vue et attribuer un alias à la colonne de la table : create view v_aliyun as select

     Remarque

     • table est un mot-clé MySQL. Lors de la synchronisation des données, le code concaténé provoque une erreur. Créez une vue et attribuez un alias à la colonne de la table.

     • Il est déconseillé d'utiliser des mots-clés comme noms de colonnes de table.

  3. Après avoir exécuté les instructions ci-dessus, utilisez la vue v_aliyun au lieu de la table aliyun lors de la configuration de la tâche de synchronisation.

Cette erreur peut survenir parce que le mappage de colonnes de la tâche de synchronisation n'est pas correctement configuré, ou que le plugin n'a pas de colonne correctement configurée.

1. Vérifiez si le mappage de colonnes est configuré.

2. Vérifiez si le plugin dispose d'une colonne correctement configurée.

• Symptôme :

  Lorsque vous cliquez sur Preview Data, un message similaire au suivant apparaît, indiquant que la taille en octets de la colonne dépasse la limite.

  Le message d'erreur est "Maximum column length of 1,000 exceeded in column 6 in record 1. Set the SafetySwitch property to false if you're expecting column lengths greater than 100,000 characters to avoid this error."

• Cause : Pour éviter les erreurs OOM, le service de source de données vérifie la longueur des colonnes lors du traitement des demandes d'aperçu de données. Si une seule colonne dépasse 1 000 octets, le message ci-dessus apparaît. Ce message n'affecte pas l'exécution réelle de la tâche. Vous pouvez ignorer cette erreur et exécuter directement la tâche de synchronisation batch.

  Remarque

  Si le fichier existe et que la connectivité est normale, les situations suivantes peuvent également provoquer l'échec de l'aperçu des données :

  • Une seule ligne du fichier dépasse la limite de taille en octets de 10 Mo. Dans ce cas, aucune donnée n'est affichée, avec un message similaire à celui ci-dessus.

  • Une seule ligne du fichier dépasse la limite de nombre de colonnes fixée à 1 000. Dans ce cas, seules les 1 000 premières colonnes sont affichées, avec un message apparaissant à la 1 001e colonne.

Le TTL est défini au niveau de la table. Il n'y a pas d'option TTL dans la configuration de la tâche de synchronisation.

La synchronisation basée sur l'API ne prend pas en charge l'utilisation de fonctions côté source. Traitez d'abord les données à l'aide de fonctions côté source avant de les importer.