Utiliser les insights Dataflow

Vous pouvez utiliser les insights Dataflow pour optimiser les performances des tâches. Cet article explique comment interagir avec les insights Dataflow à l'aide de gcloud ou de l'API REST. Vous pouvez également consulter Insights dans la console Dataflow. Pour en savoir plus sur l'examen des insights dans la console, consultez la page Recommandations.

Présentation

La fonctionnalité Insights de Dataflow fournit des insights sur l'amélioration des performances des tâches, la réduction des coûts et le dépannage des erreurs. La fonctionnalité Insights de Dataflow fait partie du service de recommandation et est disponible via le type google.dataflow.diagnostics.Insight.

Lorsque vous travaillez avec les insights Dataflow, gardez à l'esprit que certaines recommandations peuvent ne pas être pertinentes pour votre cas d'utilisation.

Avant de commencer

Avant de commencer à utiliser les insights Dataflow, vous devez suivre la procédure ci-dessous.

  1. Activez l'API Recommender.
  2. Assurez-vous que votre compte dispose des autorisations suivantes.

    • recommender.dataflowDiagnosticsInsights.get
    • recommender.dataflowDiagnosticsInsights.list
    • recommender.dataflowDiagnosticsInsights.update

    Vous pouvez accorder ces autorisations individuellement ou attribuer l'un des rôles suivants :

    • roles/recommender.dataflowDiagnosticsViewer
    • roles/recommender.dataflowDiagnosticsAdmin
    • roles/dataflow.viewer
    • roles/dataflow.developer
    • roles/dataflow.admin

Demander des insights Dataflow

Vous pouvez répertorier les insights Dataflow comme indiqué ci-dessous. Pour les autres types d'interactions, consultez le guide sur les insights de l'API Recommender.

Répertorier les insights Dataflow

Pour répertorier tous les insights Dataflow de votre projet dans une région donnée, utilisez l'une des méthodes suivantes :

gcloud

Vous pouvez utiliser la commande gcloud recommender insights list pour afficher tous les insights Dataflow de votre projet dans une région spécifiée.

Avant d'exécuter la commande, remplacez les valeurs suivantes :

  • PROJECT_ID : ID du projet pour lequel vous souhaitez répertorier des insights.
  • REGION : région dans laquelle vos tâches Dataflow sont exécutées. Exemple : us-west1.
gcloud recommender insights list --insight-type=google.dataflow.diagnostics.Insight \
  --project=PROJECT_ID \
  --location=REGION

Le résultat affiche tous les insights Dataflow pour votre projet dans la région spécifiée.

REST

Vous pouvez utiliser la méthode insights.list de l'API Recommender pour répertorier tous les insights Dataflow de votre projet dans une région spécifiée.

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

  • PROJECT_ID : ID du projet pour lequel vous souhaitez répertorier des insights.
  • REGION : région dans laquelle vos tâches Dataflow sont exécutées. Exemple : us-west1.

Méthode HTTP et URL :

GET https://recommender.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/insightTypes/google.dataflow.diagnostics.Insight/insights

Pour envoyer votre requête à l'aide de curl (Linux, macOS ou Cloud Shell), exécutez la commande suivante :

curl -X GET \
  -H "Authorization: Bearer "$(gcloud auth application-default print-access-token) \
  "https://recommender.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/insightTypes/google.dataflow.diagnostics.Insight/insights"

Obtenir un seul insight Dataflow

Pour obtenir plus d'informations sur un seul insight, y compris sa description, son état et toutes les recommandations associées, utilisez l'une des méthodes suivantes :

gcloud

Pour afficher les informations sur un seul insight, exécutez la commande gcloud recommender insights describe avec l'ID de l'insight. Avant d'exécuter la commande, remplacez les valeurs suivantes :

  • INSIGHT_ID : ID de l'insight que vous souhaitez afficher.
  • PROJECT_ID : ID du projet pour lequel vous souhaitez répertorier des insights.
  • REGION : région dans laquelle vos tâches Dataflow sont exécutées. Exemple : us-west1.
gcloud recommender insights describe INSIGHT_ID \
  --insight-type=google.dataflow.diagnostics.Insight \
  --project=PROJECT_ID \
  --location=REGION

Le résultat affiche les détails de l'insight.

REST

La méthode insights.get de l'API Recommender permet d'obtenir un seul insight. Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

  • PROJECT_ID : ID du projet pour lequel vous souhaitez répertorier des insights.
  • REGION : région dans laquelle vos tâches Dataflow sont exécutées. Exemple : us-west1.
  • INSIGHT_ID : ID de l'insight que vous souhaitez afficher.

Méthode HTTP et URL :

GET https://recommender.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/insightTypes/google.dataflow.diagnostics.Insight/insights/INSIGHT_ID

Pour envoyer votre requête à l'aide de curl (Linux, macOS ou Cloud Shell), exécutez la commande suivante :

curl -X GET \
  -H "Authorization: Bearer "$(gcloud auth application-default print-access-token) \
  "https://recommender.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/insightTypes/google.dataflow.diagnostics.Insight/insights/INSIGHT_ID"

Interpréter les insights Dataflow

Après avoir obtenu un seul insight, vous pouvez consulter son contenu pour comprendre le modèle d'utilisation des ressources qu'il met en évidence. Outre les attributs d'insight standard, la fonctionnalité Insights de Dataflow fournit les sous-types suivants:

  • AUTOSCALING_NOT_ENABLED : l'autoscaling peut être activé. La tâche a une utilisation élevée du processeur et utilise le nombre maximal de nœuds de calcul définis. L'activation de l'autoscaling peut améliorer les performances.
  • HIGH_FAN_OUT : une rupture de fusion peut être insérée après une ou plusieurs transformations pour augmenter le parallélisme.
  • MAX_NUM_WORKERS : Autoscaling : le nombre maximal de nœuds de calcul peut être augmenté La tâche utilise l'autoscaling, dispose d'une utilisation élevée du processeur et utilise le nombre maximal de nœuds de calcul définis. L'augmentation du nombre maximal de nœuds de calcul peut améliorer les performances.
  • WORKER_OUT_OF_MEMORY : certains nœuds de calcul de la tâche ont échoué en raison d'un manque de mémoire, ce qui peut ralentir la tâche ou la provoquer.
  • PREBUILD_NOT_UTILIZED : utilisez le workflow de création de nœuds de calcul pour améliorer le temps de démarrage des nœuds de calcul et la fiabilité de l'autoscaling.
  • ACTIVE_KEYS (Bêta) : le nombre total de clés actives est inférieur au nombre total de cœurs et le scaling à la hausse ne résout pas le problème.
  • LONG_WORK_ITEM: le traitement par phase fusionnée prend trop de temps, ce qui indique une opération lente ou bloquée.

Pour en savoir plus sur la limitation des problèmes identifiés par les insights Dataflow, consultez la page Insights.

Les insights Dataflow fournissent également un champ content spécial contenant des sous-champs avec des informations et des métadonnées supplémentaires sur un insight. Selon votre cas d'utilisation, les sous-champs content suivants peuvent être utiles :

  • jobName : nom de la tâche Dataflow.
  • description : description de l'insight en anglais.
  • title : titre de l'insight en anglais.

Insights

Distribution ramifiée élevée détectée

Lorsque Dataflow détecte qu'une tâche possède une ou plusieurs transformations avec une distribution ramifiée élevée, le message suivant s'affiche :

High fan-out detected

Le message s'affiche lorsqu'une opération ParDo ayant un ratio d'éléments sortie-entrée élevé est fusionnée avec une opération ParDo ultérieure. Dans ce cas, la deuxième opération ParDo est exécutée de manière séquentielle avec la première, ce qui a pour effet de forcer tous les éléments de sortie d'une entrée donnée sur le même nœud de calcul, de réduire le parallélisme et de ralentir les performances.

Pour remédier à ce problème :

  • Insérez une fonction GroupByKey et dissociez le groupe après votre première opération ParDo. Le service Dataflow ne fusionne jamais les opérations ParDo sur une agrégation. Pour en savoir plus, consultez la section Optimisation de la fusion.
  • Transmettez la classe PCollection intermédiaire en tant qu'entrée secondaire à une autre opération ParDo. Le service Dataflow matérialise toujours les entrées secondaires.
  • Insérez une étape de rebrassage. Le rebrassage empêche la fusion, contrôle les données et reconfigure la stratégie de fenêtrage pour qu'aucune donnée ne soit supprimée. Le rebrassage des données est pris en charge par Dataflow, même s'il est marqué comme obsolète dans la documentation d'Apache Beam (notez que le rebrassage des données peut augmenter le coût d'exécution de votre pipeline).

Autoscaling : le nombre maximal de nœuds de calcul peut être augmenté

Lorsque Dataflow détecte qu'une tâche utilise le nombre maximal de nœuds de calcul autorisés, maxNumWorkers (ou max_num_workers), et que la tâche peut utiliser davantage de nœuds de calcul si cette valeur maximum était augmentée, le message suivant s'affiche :

maximum number of workers could be increased

Par exemple, cette recommandation s'applique à une tâche pour laquelle maxNumWorkers est défini sur 50 lorsque les 50 nœuds de calcul sont actifs et ont une utilisation moyenne de processeur supérieure à 80 %. Cette recommandation concerne également les jobs de traitement en flux continu dont le paramètre maxNumWorkers est défini sur 50 lorsque les 50 nœuds de calcul sont actifs avec une utilisation moyenne de processeur supérieure à 50 % et que la durée de traitement estimée du job est de deux minutes.

En règle générale, l'augmentation de maxNumWorkers augmente le débit du pipeline. Un pipeline par lots peut se terminer plus rapidement, mais un pipeline par flux peut gérer des pics de données plus importants et traiter plus d'éléments par seconde. Cela peut toutefois augmenter le coût. Pour en savoir plus, consultez la section Tarifs des ressources de calcul. Pour en savoir plus sur le fonctionnement de l'algorithme d'autoscaling et sur sa configuration, consultez le guide d'autoscaling.

Pour remédier à ce problème :

  • Augmentez ou supprimez l'option de pipeline maxNumWorkers. Sans l'option, Dataflow utilise les valeurs par défaut répertoriées dans le guide d'autoscaling.
  • Vous pouvez laisser les choses en l'état si les performances du pipeline sont satisfaisantes.
    • Pour les pipelines par lots, vérifiez que le temps d'exécution total répond à vos exigences.
    • Pour les pipelines de traitement en flux continu, consultez le graphique Fraîcheur des données dans l'onglet Métriques de tâche de la page de la tâche. Vérifiez que les valeurs du graphique n'augmentent pas en permanence et qu'elles se trouvent dans les limites acceptables.

Autoscaling : définir le nombre initial de nœuds de calcul peut améliorer les performances des jobs

Lorsque Dataflow détecte qu'un job utilise un certain nombre de nœuds de calcul pendant plus de 50 % du temps d'exécution, définir le nombre initial de nœuds de calcul sur la valeur recommandée peut améliorer les performances du job en réduisant le temps d'exécution des jobs par lot ou en empêchant l'augmentation du nombre de jobs en attente lors de la mise à jour d'un job de traitement en flux continu.

Les nœuds de calcul échouent avec des erreurs de type "OutOfMemory"

Lorsque Dataflow détecte que les nœuds de calcul d'une tâche échouent en raison d'erreurs de mémoire insuffisante, le message suivant s'affiche :

Some workers are out of memory

Certains nœuds de calcul pour la tâche ont échoué en raison d'une mémoire insuffisante. Bien qu'il soit possible que la tâche se termine, il est également possible que ces erreurs empêchent la tâche de se terminer correctement ou de ralentir les performances.

Suivez les conseils ci-dessous pour essayer de résoudre le problème :

Workflow pré-compilé non utilisé

Lorsque Dataflow détecte un pipeline dans lequel le workflow de pré-compilation de l'image de nœud de calcul n'est pas utilisé, le message suivant apparaît :

pre-build workflow not utilized

Lorsque le workflow de pré-compilation de l'image de nœud de calcul n'est pas utilisé, le pipeline comporte des dépendances installées de manière répétitive au moment de l'exécution. Cette configuration ralentit le démarrage des nœuds de calcul, ce qui dégrade le débit de la tâche et entraîne un comportement d'autoscaling peu fiable.

Pour résoudre ce problème, utilisez le workflow de création d'images de nœud de calcul lors du lancement du pipeline. Pour en savoir plus, consultez la section Dépendances Python prédéfinies.

Si un conteneur prédéfini personnalisé est déjà utilisé, pour éviter des installations inutiles, ajoutez l'option "--sdk_location=container" et supprimez les options suivantes :

  • '--setup_file'
  • '--requirements_file'
  • '--extra_package(s)'

Nombre de clés actives faible

Lorsque Dataflow détecte qu'un job est en retard car le nombre de clés actives est inférieur au nombre total de cœurs et que le scaling à la hausse ne résout pas le problème, le message suivant s'affiche :

Active keys can be increased

Pour exécuter du code utilisateur dans des jobs, Dataflow utilise des nœuds de calcul. Chaque thread correspond à une clé chargée d'un ensemble de données à traiter. Une clé ne peut être exécutée que sur un seul cœur à la fois pour des raisons d'exactitude.

Dans certains cas, certains cœurs sont surchargés tandis que d'autres sont inactifs. Pour résoudre ce problème, augmentez le nombre de clés, ce qui augmente également le nombre de threads actifs.

Solutions potentielles pour augmenter le nombre de clés : - Vous pouvez augmenter le nombre de clés en utilisant un type de clé plus spécifique. Par exemple, si le type de clé est IP address, moins de clés sont disponibles. Toutefois, si vous remplacez le type de clé par IP + [user identifier], d'autres clés sont disponibles, ce qui augmente le parallélisme. - Pour les pipelines qui écrivent dans BigQuery, où les récepteurs peuvent potentiellement être le goulot d'étranglement, reportez-vous à cet article. - Pour les autres sources ou récepteurs, vérifiez si un paramètre numShards est disponible et augmentez-le. En général, un segment correspond à une clé. - Pour obtenir des instructions plus générales sur notre modèle d'exécution, reportez-vous à cet article. - La fonction de distribution ramifiée peut être utilisée pour prendre une seule clé d'entrée et y ajouter un hachage afin de produire plusieurs clés de sortie. Reference

Temps d'une étape trop long pour le traitement

Lorsque Dataflow détecte que le traitement a souvent pris trop de temps, le message suivant s'affiche:

Stage spending too long on work

Dataflow envoie du travail aux étapes fusionnées dans des lots d'éléments à traiter, et chaque lot est considéré comme terminé une fois que tous les éléments et leurs résultats ont été traités pour l'étape. Les pipelines de traitement en flux continu sont optimisés autour de lots de travail qui prennent moins d'une minute à être traités. Par conséquent, des temps de traitement longs peuvent entraîner d'autres problèmes de performances dans les pipelines.

Ce problème peut être dû à des transformations utilisateur bloquées ou lentes. Ces transformations peuvent être identifiées par des avertissements émis dans Cloud Logging et dans son onglet "Diagnostic", avec les expressions clés "Opération en cours" ou "Traitement bloqué". Pour déterminer si ce problème est causé par une transformation utilisateur, utilisez Cloud Profiler pour inspecter les performances des transformations utilisateur. Examinez ensuite le code à l'origine du ralentissement et la fréquence à laquelle il le provoque. Pour en savoir plus, consultez la page Résoudre les erreurs Dataflow courantes.

Si des investigations révèlent que les temps de traitement longs ne sont pas causés par les transformations utilisateur, nous vous recommandons de contacter l'assistance Cloud et de décrire les étapes que vous avez effectuées.

Job bloqué sur un élément de travail

Lorsque Dataflow détecte qu'une clé est bloquée en raison de l'échec répété d'un élément de travail, puis de nouvelles tentatives, le message suivant s'affiche :

Job is stuck due to failed and retried work item

Dans Dataflow, tous les messages d'un pipeline sont traités sous une clé particulière. Lorsqu'une erreur se produit lors du traitement d'un message, ce message est réessayé. Il est acceptable qu'un message soit réessayé deux ou trois fois. Toutefois, si des erreurs se produisent à de nombreuses reprises, par exemple dix fois de suite, cela indique généralement un problème fondamental avec le code du pipeline. Lorsqu'un message particulier sur une clé est réessayé, les autres messages associés à la même clé ne peuvent pas progresser. Si un message échoue 10 fois ou plus, le problème ne sera probablement pas résolu seul. Cette défaillance de message peut entraîner des problèmes de pipeline, tels que les suivants :

  • retard du filigrane
  • accumulation des tâches en attente
  • impossibilité pour une opération de drainage de se terminer

Pour déboguer ce problème, examinez l'étape signalée par la recommandation et consultez les journaux pour identifier le code problématique. Ensuite, mettez à jour le job avec le nouveau code de pipeline pour le débloquer.

Streaming Engine n'est pas activé

Lorsque Dataflow détecte qu'un job de traitement en flux continu n'est pas activé, le message suivant s'affiche :

This job isn't using Streaming Engine. It might benefit from having Streaming Engine enabled.

L'utilisation de Streaming Engine présente divers avantages potentiels, y compris un meilleur autoscaling horizontal, une meilleure compatibilité et une réduction de l'utilisation des ressources de processeur, de mémoire et de disques persistants sur les VM de nœud de calcul. Streaming Engine est également compatible avec la facturation basée sur les ressources.