Résoudre les problèmes liés à Cloud Data Fusion

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

Le conseil suivant s'applique aux pipelines de traitement par lot.

Le pipeline simultané est 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 de traitement 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 de traitement 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 "Exécuteur Cloud Data Fusion (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-lui le rôle Utilisateur de tâche BigQuery (roles/bigquery.jobUser).

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

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

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

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

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é aux exceptions générées à partir de la directive en cas d'échec qui n'est pas géré autrement. 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 à la directive FAIL est remplie, elle est comptabilisée dans le seuil d'erreur et le pipeline échoue une fois le 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, dont la précision et l'échelle ne sont pas définies, est mappée au 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. 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 repose sur le schéma de sortie de la source, car le schéma de sortie a changé. Lorsqu'un schéma de sortie est défini pour le type de données Oracle NUMBER 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 Oracle de source par lot génère l'erreur de non-correspondance 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 évolutivité 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 source par lot Oracle mappe le type de données NUMBER Oracle défini sans précision et s'adapte au 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 sur string au moment de l'exécution.

Recommandation

Pour résoudre l'éventuel problème de perte de précision lorsque vous utilisez des types de données NUMBER Oracle dont la précision et l'échelle ne sont pas définies, 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 évolutivité 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 (vers lequel le type de données Oracle NUMBER défini sans précision et sans échelle a été mappé), mettez-le à jour ou attendez 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 que vous effectuez le scaling en tant que type de données CDAP decimal(38,0), déployez les versions 1.8.6 du plug-in Oracle (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 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, le 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 garantir une maintenance correcte du cluster.

Définir la durée d'inactivité maximale

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.

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 de l'environnement d'exécution du pipeline, vérifiez si l'ID du projet Dataproc est personnalisé pour l'exécution.

      Vérifier 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. Vérifiez la valeur system.profile.name dans les arguments de l'environnement d'exécution du pipeline.

        Obtenir le nom de l'approvisionneur dans les arguments d'exécution

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

  2. Pour chaque projet:

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

      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

Lorsque vous créez 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 s'ils 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 le problème, mettez à niveau la version de correctif 6.8.3.1, 6.9.2.1 ou ultérieure. Si vous ne pouvez pas effectuer de mise à niveau, supprimez les nœuds de calcul secondaires comme suit.

Si vous utilisez un approvisionneur Dataproc éphémère, résolvez l'erreur en procédant comme suit:

  1. Accédez à votre pipeline dans l'interface Web de Cloud Data Fusion.
  2. Dans les arguments de l'environnement d'exécution du pipeline, définissez system.profile.properties.secondaryWorkerNumNodes sur 0. Définir l'argument de l'environnement d'exécution
  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. Désactivez les nœuds de calcul secondaires dans un espace de noms.
    4. Cliquez sur Enregistrer et fermer.

Si vous utilisez un approvisionneur Dataproc existant, résolvez l'erreur en procédant comme suit:

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

    accéder aux clusters

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

  3. Dans le champ Nœuds de calcul secondaires, saisissez 0. Modifiez les nœuds de calcul secondaires dans la console.

  4. Cliquez sur Enregistrer.