DataWorks:Dépannage des problèmes de qualité des données lors de la synchronisation par lots

Cause

Description

Solution

write mode mal configuré

Le writer plugin écrit les données source dans la destination en utilisant le mode d'écriture sélectionné. Si les données source entrent en conflit avec les contraintes de la table de destination, cela peut entraîner des échecs d'insertion (données incorrectes), des rejets silencieux ou le remplacement d'enregistrements.

Sélectionnez le mode d'écriture approprié pour votre cas d'utilisation. Pour plus d'informations, consultez Annexe : Modes d'écriture pour les bases de données relationnelles.

Seuil de données incorrectes atteint

La quantité de données incorrectes, causée par des problèmes tels que des incompatibilités de type de données ou un contenu trop volumineux, dépasse le seuil configuré, ce qui entraîne l'échec de la tâche et empêche l'écriture de certaines données.

Identifiez la cause des données incorrectes et résolvez le problème. Vous pouvez également déterminer si les données incorrectes peuvent être tolérées et ignorées.

Interrogation des données trop précoce

Les données sont interrogées avant la fin de la tâche de synchronisation. Pour certaines sources de données, telles que Hive et MaxCompute (configurable), les données peuvent être partiellement ou totalement indisponibles jusqu'à la fin de la tâche.

Vérifiez toujours les données dans la table cible après avoir confirmé que l'instance de la tâche de synchronisation s'est exécutée avec succès.

Dépendance de nœud manquante

Si aucune dépendance explicite de graphe acyclique dirigé (DAG) n'est configurée entre une tâche d'analyse en aval et une tâche de synchronisation en amont, la tâche en aval peut démarrer prématurément et lire des données incomplètes.

Dans DataStudio, configurez une dépendance explicite parent-enfant entre les tâches en amont et en aval. Évitez d'utiliser des dépendances faibles, telles que max_pt.

Plusieurs tâches de synchronisation écrivent simultanément dans la même table ou partition, provoquant des interférences.

Exécution concurrente non sécurisée des tâches de synchronisation.

• Pour MaxCompute et Hologres, si deux tâches écrivent dans la même partition et sont configurées pour tronquer la partition avant l'écriture, la deuxième tâche peut effacer les données écrites par la première.

• Pour les bases de données relationnelles, si des instructions SQL pré- ou post-exécution sont configurées, les instructions SQL d'une deuxième tâche peuvent interférer avec les données écrites par la première.

• Si le conflit est causé par plusieurs instances périodiques du même nœud, configurez une auto-dépendance pour garantir que la prochaine instance ne démarre qu'après l'achèvement de la précédente.

• Évitez de concevoir des tâches qui écrivent simultanément dans la même destination.

Tâche non configurée pour une exécution idempotente

La tâche n'est pas idempotente, ce qui signifie que plusieurs exécutions produisent des résultats différents. La réexécution de la tâche peut entraîner l'insertion de données en double ou l'écrasement incorrect des données.

1. Dans la mesure du possible, concevez la tâche pour qu'elle soit idempotente. Par exemple, utilisez le mode REPLACE INTO.
2. Si vous ne pouvez pas rendre la tâche idempotente, faites preuve de prudence lors de sa réexécution et configurez des alertes de réussite pour éviter les nouvelles tentatives inutiles.

Expression de partition incorrecte

Dans MaxCompute, la plupart des tables de données sont partitionnées et les valeurs de partition sont souvent des paramètres de planification DataWorks comme $bizdate. Les erreurs courantes incluent :

• Le paramètre de planification n'est pas correctement remplacé. Par conséquent, les données sont écrites dans une partition portant un nom littéral tel que ds=$bizdate au lieu de la date métier réelle, telle que ds=20230118.

• Une requête en aval utilise une expression de partition qui n'est pas évaluée correctement, ce qui amène la requête à lire les données de la mauvaise partition.

Vérifiez les expressions de variables dans la tâche de synchronisation des données. Assurez-vous que la configuration du paramètre de planification est correcte et que les paramètres d'exécution dans l'instance de tâche sont évalués aux valeurs attendues.

Incompatibilité de type de données ou de fuseau horaire

Des types de données ou des paramètres de fuseau horaire incohérents entre la source et la destination peuvent entraîner la troncature des données, une conversion incorrecte ou des écarts lors des comparaisons.

• Confirmez les différences de type de données et de fuseau horaire entre la source et la destination.

• Décidez s'il faut accepter l'état actuel ou modifier les paramètres de type de données et de fuseau horaire à la destination.

Données de destination modifiées par d'autres processus

Si d'autres applications modifient simultanément la source de données de destination, son contenu peut devenir incohérent avec les données source.

Assurez-vous qu'aucun autre processus n'écrit dans la table de destination pendant la fenêtre de synchronisation. Si les écritures simultanées sont un comportement attendu, vous devez accepter les écarts de données résultants.

Type de protocole

Mode d'écriture

Comportement en cas de conflit

Comportement sans conflit

Quand l'utiliser

Protocole général/MySQL

insert into

L'insertion échoue et génère des données incorrectes.

Insère de nouvelles données.

Ajouter des données pour une synchronisation complète ou incrémentielle sans écraser ni modifier les enregistrements existants.

replace into

Remplace l'ancienne ligne en la supprimant d'abord, puis en insérant la nouvelle ligne.

Insère de nouvelles données.

Écraser complètement les anciens enregistrements avec les dernières données.

insert into ... on duplicate key update

Met à jour l'ancienne ligne en mettant à jour uniquement les champs spécifiés avec les nouvelles données.

Insère de nouvelles données.

Mettre à jour des champs spécifiques dans un enregistrement tout en conservant les autres, tels qu'un horodatage de création.

insert ignore into

Ignore la nouvelle ligne sans l'écrire ni générer d'erreur.

Insère de nouvelles données.

Insérer uniquement les données qui n'existent pas déjà et ne prendre aucune mesure sur les enregistrements existants.

PostgreSQL

insert on conflict do nothing

Ignore la nouvelle ligne sans l'écrire ni générer d'erreur.

Insère de nouvelles données.

Insérer uniquement les données qui n'existent pas déjà et ne prendre aucune mesure sur les enregistrements existants.

insert on conflict do update

Met à jour l'ancienne ligne en mettant à jour les champs spécifiés dans la ligne en conflit avec les nouvelles données.

Insère de nouvelles données.

Mettre à jour des champs spécifiques dans un enregistrement tout en conservant les autres, tels qu'un horodatage de création.

copy on conflict do nothing

Rejette les lignes en conflit. Utilise le protocole haute performance COPY et ignore les nouvelles données en cas de conflit sans générer de données incorrectes.

Insère en masse de nouvelles données.

Ajouter efficacement de grands lots de données tout en permettant d'ignorer les enregistrements en double.

copy on conflict do update

Met à jour les lignes en conflit. Utilise le protocole COPY et écrase les anciennes données avec les nouvelles en cas de conflit.

Insère en masse de nouvelles données.

Synchroniser efficacement de grands lots de données en écrasant les anciens enregistrements avec les dernières données.

-

merge into

Non pris en charge.

Cause

Description

Solution

Modifications simultanées des données source

• Des applications externes peuvent encore modifier les données source pendant l'opération de lecture. Par conséquent, la tâche de synchronisation capture un instantané des données au moment de la lecture, et non l'état absolu le plus récent des données.

• Pour permettre la lecture parallèle, un job de synchronisation est divisé en plusieurs tasks qui émettent des requêtes de base de données indépendantes. En raison de l'isolation des transactions de la base de données, chaque task récupère un instantané des données à un moment différent. Par conséquent, le job ne peut pas capturer les modifications de données qui se produisent après le démarrage de toutes ses tasks.

Acceptez ce comportement comme un résultat attendu d'une synchronisation de données à haut débit. La réexécution de la tâche peut donner des résultats différents en raison des modifications en temps réel des données source.

Conditions de filtrage incorrectes

• Pour MySQL, vous pouvez configurer une clause WHERE pour filtrer les données extraites. Si la clause contient un paramètre de planification, comme dans gmt_modify >= ${bizdate}, une erreur courante est le remplacement incorrect des paramètres. Par exemple, la tâche peut filtrer seulement un jour de données alors que deux jours sont requis.

• Pour MaxCompute, lorsque vous lisez des données à partir d'une table partitionnée, des expressions de variables sont souvent configurées pour les paramètres de partition, telles que pt=${bizdate}. Ces paramètres peuvent être facilement mal configurés ou ne pas être remplacés.

Vérifiez les expressions de variables de planification dans la tâche de synchronisation des données. Assurez-vous que la configuration du paramètre de planification est correcte et que les valeurs des paramètres sont remplacées comme prévu au moment de l'exécution.

Données incorrectes côté reader

Un échec d'analyse se produit lors de la lecture des données source. Cela est rare dans les bases de données structurées, mais peut se produire avec des sources de données semi-structurées, telles que des fichiers CSV ou JSON dans OSS. Des erreurs de format peuvent entraîner l'ignorance de certains enregistrements.

• Vérifiez le journal d'exécution de la tâche pour détecter des erreurs d'analyse ou des exceptions de format, puis corrigez les fichiers de données source.

• Ajustez la configuration de tolérance aux données incorrectes.