Dépannage

Cette page explique comment résoudre les problèmes liés à Cloud Data Fusion.

Résoudre les problèmes liés aux pipelines de traitement par lot

Pipeline simultané bloqué

Dans Cloud Data Fusion, l'exécution de plusieurs pipelines de traitement par lot simultanés peut soumettre l'instance à une pression, ce qui bloque les tâches dans les états Starting, Provisioning ou Running. Par conséquent, les pipelines ne peuvent pas être arrêtés via l'interface Web ou des appels d'API. Lorsque vous exécutez plusieurs pipelines simultanément, l'interface Web peut devenir lente ou ne plus répondre. Ce problème est dû à l'envoi de plusieurs requêtes d'interface utilisateur au gestionnaire HTTP dans le backend.

Recommandation

Pour résoudre ce problème, contrôlez le nombre de nouvelles requêtes à l'aide du contrôle de flux Cloud Data Fusion, disponible dans les instances exécutées à partir de la version 6.6.

La connexion SSH expire lorsqu'un pipeline est en cours d'exécution

L'erreur suivante se produit lorsque vous exécutez un pipeline par lot:

`java.io.IOException: com.jcraft.jsch.JSchException:
java.net.ConnectException: Connection timed out (Connection timed out)`

Recommandation

Pour résoudre l'erreur, recherchez les problèmes suivants:

• Recherchez une règle de pare-feu manquante (généralement le port 22). Pour créer une règle de pare-feu, consultez la page Configuration du réseau d'un cluster Dataproc.
• Vérifiez que l'outil d'application Compute Engine autorise la connexion entre votre instance Cloud Data Fusion et le cluster Dataproc.

Code de réponse: 401. Erreur: erreur inconnue

L'erreur suivante se produit lorsque vous exécutez un pipeline par lot:

`java.io.IOException: Failed to send message for program run program_run:
Response code: 401. Error: unknown error`

Recommandation

Pour résoudre cette erreur, vous devez attribuer le rôle Cloud Data Fusion Runner (roles/datafusion.runner) au compte de service utilisé par Dataproc.

Échec du pipeline avec le plug-in BigQuery avec l'erreur Access Denied

Il existe un problème connu où un pipeline échoue et renvoie une erreur Access Denied lors de l'exécution de tâches BigQuery. Cela affecte les pipelines qui utilisent les plug-ins suivants:

• Sources BigQuery
• Récepteurs BigQuery
• Récepteurs multi-tables BigQuery
• Pushdown de transformation

Exemple d'erreur dans les journaux (peut varier en fonction du plug-in que vous utilisez) :

POST https://bigquery.googleapis.com/bigquery/v2/projects/PROJECT_ID/jobs
{
"code" : 403,
"errors" : [ {
"domain" : "global",
"message" : "Access Denied: Project xxxx: User does not have bigquery.jobs.create permission in project PROJECT_ID",
"reason" : "accessDenied"
} ],
"message" : "Access Denied: Project PROJECT_ID: User does not have bigquery.jobs.create permission in project PROJECT_ID.",
"status" : "PERMISSION_DENIED"
}

Dans cet exemple, PROJECT_ID correspond à l'ID de projet que vous avez spécifié dans le plug-in. Le compte de service du projet spécifié dans le plug-in n'est pas autorisé à effectuer au moins l'une des opérations suivantes:

• Exécuter une tâche BigQuery
• Lire un ensemble de données BigQuery
• Créer un bucket temporaire
• Créer un ensemble de données BigQuery
• Créer la table BigQuery

Recommandation

Pour résoudre ce problème, accordez les rôles manquants au projet (PROJECT_ID) que vous avez spécifié dans le plug-in :

• Pour exécuter une tâche BigQuery, attribuez le rôle d'utilisateur de tâche BigQuery (roles/bigquery.jobUser).

• Pour lire un ensemble de données BigQuery, attribuez le rôle de lecteur de données BigQuery (roles/bigquery.dataViewer).

• Pour créer un bucket temporaire, attribuez le rôle d'administrateur de l'espace de stockage (roles/storage.admin).

• Pour créer un ensemble de données ou une table BigQuery, attribuez le rôle d'éditeur de données BigQuery (roles/bigquery.dataEditor).

Pour en savoir plus, consultez la documentation de dépannage du plug-in (Dépannage de récepteur Google BigQuery multi-tables).

Le pipeline ne s'arrête pas au seuil d'erreur

Un pipeline peut ne pas s'arrêter après plusieurs erreurs, même si vous définissez le seuil d'erreur sur 1.

Le seuil d'erreur est destiné à toutes les exceptions générées par la directive en cas d'échec qui n'est pas traité d'une autre manière. Si l'instruction utilise déjà l'API emitError, le seuil d'erreur n'est pas activé.

Recommandation

Pour concevoir un pipeline qui échoue lorsqu'un certain seuil est atteint, utilisez la directive FAIL.

Chaque fois que la condition transmise à l'instruction FAIL est remplie, elle est comptabilisée dans le seuil d'erreur et le pipeline échoue une fois ce seuil atteint.

Le plug-in de source par lot Oracle convertit NUMBER en string

Dans les versions 1.9.0, 1.8.3 et antérieures de la source par lot Oracle, le type de données Oracle NUMBER, avec une précision et une échelle non définies, est mappé sur le type de données CDAP decimal(38,0).

Les versions de plug-in 1.9.1, 1.8.4 et 1.8.5 sont incompatibles avec les versions antérieures, et les pipelines qui utilisent des versions antérieures peuvent ne pas fonctionner après la mise à niveau vers les versions 1.9.1, 1.8.5 et 1.8.4 si une étape en aval du pipeline s'appuie sur le schéma de sortie de la source, car le schéma de sortie a changé. Si un schéma de sortie est défini pour le type de données Oracle NUMBER défini sans précision ni scaling dans la version précédente du plug-in, après la mise à niveau vers les versions 1.9.1, 1.8.5 ou 1.8.4, le plug-in de source par lot Oracle génère l'erreur de non-concordance de schéma suivante pour les types: Schema field '<field name>' is expected to have type 'decimal with precision <precision> and scale <scale> but found 'string'. Change the data type of field <field name> to string.

Les versions 1.9.1, 1.8.5 et 1.8.4 fonctionnent avec un schéma de sortie du type de données CDAP string pour le type de données Oracle NUMBER défini sans précision ni évolutivité. Si un type de données Oracle NUMBER est défini sans précision ni échelle dans le schéma de sortie source Oracle, nous vous déconseillons d'utiliser l'ancienne version du plug-in Oracle, car cela peut entraîner des erreurs d'arrondi.

Ce cas particulier se produit lorsque vous utilisez une macro pour le nom de la base de données, le nom du schéma ou le nom de la table et si vous n'avez pas spécifié manuellement un schéma de sortie. Le schéma est détecté et mappé au moment de l'exécution. L'ancienne version du plug-in Oracle de source par lot mappe le type de données NUMBER Oracle défini sans précision et effectue une mise à l'échelle sur le type de données CDAP decimal(38,0), tandis que les versions 1.9.1, 1.8.5 et 1.8.4 et ultérieures mappent les types de données avec string au moment de l'exécution.

Recommandation

Pour résoudre le problème de perte de précision lorsque vous utilisez des types de données NUMBER Oracle dont la précision et le scaling ne sont pas définis, mettez à niveau vos pipelines pour utiliser les versions 1.9.1, 1.8.5 ou 1.8.4 du plug-in de source par lot Oracle.

Après la mise à niveau, le type de données Oracle NUMBER défini sans précision ni échelle est mappé au type de données CDAP string au moment de l'exécution. Si une étape ou un récepteur en aval utilise le type de données CDAP decimal d'origine (auquel le type de données Oracle NUMBER défini sans précision ni échelle a été mappé), mettez-le à jour ou attendez-vous à ce qu'il consomme des données de chaîne.

Si vous comprenez le risque de perte de données possible en raison des erreurs d'arrondi, mais que vous choisissez d'utiliser le type de données Oracle NUMBER défini sans précision et sans scaling comme type de données CDAP decimal(38,0), déployez le plug-in Oracle version 1.8.6 (pour Cloud Data Fusion 6.7.3) ou 1.9.2 (pour Cloud Data Fusion 6.8.1) à partir du hub, puis mettez à jour les pipelines pour les utiliser à la place.

Pour en savoir plus, consultez la documentation de référence sur les sources de traitement par lot Oracle.

Supprimer un cluster Dataproc éphémère

Lorsque Cloud Data Fusion crée un cluster Dataproc éphémère lors du provisionnement de l'exécution du pipeline, ce cluster est supprimé une fois l'exécution du pipeline terminée. Dans de rares cas, la suppression du cluster échoue.

Fortement recommandé: passez à la version la plus récente de Cloud Data Fusion pour assurer une maintenance correcte du cluster.

Définir le temps d'inactivité maximal

Pour résoudre ce problème, configurez l'option Max Idle Time. Cela permet à Dataproc de supprimer automatiquement les clusters, même si un appel explicite à la fin du pipeline échoue.

Max Idle Time est disponible dans Cloud Data Fusion 6.4 et versions ultérieures.

Remarque :Dans Cloud Data Fusion 6.6 et versions ultérieures, Max Idle Time est défini sur 30 minutes par défaut et aucune configuration supplémentaire n'est nécessaire.

Recommandé: Pour les versions antérieures à la version 6.6, définissez manuellement Max Idle Time sur 30 minutes ou plus.

Supprimer les clusters manuellement

Si vous ne pouvez pas mettre à niveau votre version ou configurer l'option Max Idle Time, supprimez manuellement les clusters obsolètes:

1. Obtenez chaque ID de projet dans lequel les clusters ont été créés:

   1. Dans les arguments d'exécution du pipeline, vérifiez si l'ID de projet Dataproc est personnalisé pour l'exécution.

      

   2. Si aucun ID de projet Dataproc n'est spécifié explicitement, déterminez l'approvisionneur utilisé, puis recherchez un ID de projet:

      1. Dans les arguments d'exécution du pipeline, vérifiez la valeur system.profile.name.

         

      2. Ouvrez les paramètres de l'approvisionneur et vérifiez si l'ID de projet Dataproc est défini. Si le paramètre n'est pas présent ou que le champ est vide, le projet dans lequel l'instance Cloud Data Fusion est en cours d'exécution est utilisé.

   Important :Plusieurs exécutions de pipeline peuvent utiliser des projets différents. Veillez à obtenir tous les ID de projet.

2. Pour chaque projet:

   1. Ouvrez le projet dans la console Google Cloud, puis accédez à la page Clusters Dataproc.

      accéder aux clusters

   2. Triez les clusters par date de création, du plus ancien au plus récent.

   3. Si le panneau d'informations est masqué, cliquez sur Afficher le panneau d'informations, puis accédez à l'onglet Libellés.

   4. Pour chaque cluster qui n'est pas utilisé (par exemple, plus d'une journée s'est écoulée), vérifiez s'il dispose d'un libellé de version Cloud Data Fusion. Cela indique qu'il a été créé par Cloud Data Fusion.

   5. Cochez la case à côté du nom du cluster, puis cliquez sur Supprimer.

Impossible de créer une instance Cloud Data Fusion

Lors de la création d'une instance Cloud Data Fusion, vous pouvez rencontrer le problème suivant:

Read access to project PROJECT_NAME was denied.

Recommandation

Pour résoudre ce problème, désactivez et réactivez l'API Cloud Data Fusion. Ensuite, créez l'instance.

Les pipelines échouent lorsqu'ils sont exécutés sur des clusters Dataproc avec des nœuds de calcul secondaires

Dans les versions 6.8 et 6.9 de Cloud Data Fusion, un problème entraîne l'échec des pipelines qui s'exécutent sur des clusters Dataproc sur lesquels les nœuds de calcul secondaires sont activés:

ERROR [provisioning-task-2:i.c.c.i.p.t.ProvisioningTask@161] - PROVISION task failed in REQUESTING_CREATE state for program run program_run:default.APP_NAME.UUID.workflow.DataPipelineWorkflow.RUN_ID due to
Caused by: io.grpc.StatusRuntimeException: CANCELLED: Failed to read message.
Caused by: com.google.protobuf.GeneratedMessageV3$Builder.parseUnknownField(Lcom/google/protobuf/CodedInputStream;Lcom/google/protobuf/ExtensionRegistryLite;I)Z.

Recommandation

Pour résoudre ce problème, procédez comme suit pour supprimer les nœuds de calcul secondaires.

Si vous utilisez un approvisionneur Dataproc éphémère, procédez comme suit pour résoudre l'erreur:

1. Accédez à votre pipeline dans l'interface Web de Cloud Data Fusion.
2. Dans les arguments d'exécution du pipeline, définissez system.profile.properties.secondaryWorkerNumNodes sur 0.
3. Cliquez sur Enregistrer.
4. Si vous utilisez un espace de noms, désactivez les nœuds de calcul secondaires dans l'espace de noms :
   1. Cliquez sur Administrateur système > Espaces de noms, puis sélectionnez l'espace de noms.
   2. Cliquez sur Préférences > Modifier.
   3. Définissez la valeur de system.profile.properties.secondaryWorkerNumNodes sur 0.
   4. Cliquez sur Enregistrer et fermer.

Si vous utilisez un approvisionneur Dataproc existant, procédez comme suit pour résoudre l'erreur:

1. Dans la console Google Cloud, accédez à la page Clusters Dataproc.

   accéder aux clusters

2. Sélectionnez le cluster, puis cliquez sur Modifier.

3. Dans le champ Nœuds de calcul secondaires, saisissez 0.

4. Cliquez sur Enregistrer.