Questions fréquentes sur le déploiement sans serveur de Managed Service pour Apache Spark

Cette page contient des questions fréquemment posées sur le déploiement sans serveur de Managed Service pour Apache Spark, ainsi que leurs réponses. Sauf indication contraire, ces informations ne s'appliquent qu'aux déploiements Managed Service for Apache Spark sans serveur, et non aux déploiements de clusters.

Quand dois-je utiliser le déploiement sans serveur Managed Service pour Apache Spark au lieu du déploiement de cluster Managed Service pour Apache Spark ?

  • Déploiement sans serveur Managed Service pour Apache Spark :

    • Compatible avec les charges de travail par lot Spark et les sessions interactives dans les notebooks Jupyter du noyau PySpark.
    • Crée et gère votre charge de travail et votre infrastructure de session interactive.
  • Déploiement de clusters Managed Service pour Apache Spark :

    • Permet d'envoyer différents types de tâches Spark et des tâches basées sur d'autres composants Open Source, tels que Flink, Hadoop, Hive, Pig, Presto, etc.

    • Ne crée ni ne gère l'infrastructure. Vous créez et gérez vos clusters Managed Service pour Apache Spark.

Que puis-je faire avec le déploiement sans serveur Managed Service pour Apache Spark ?

Comment configurer un plan d'exécution de charge de travail ?

Vous pouvez exécuter des charges de travail simultanément ou de manière séquentielle. Votre plan d'exécution a un impact sur votre quota de ressources Google Cloud . Vous pouvez exécuter autant de charges de travail en parallèle que vos quotas de ressources par lot le permettent.

Puis-je utiliser une image personnalisée avec le déploiement sans serveur Managed Service pour Apache Spark ?

Puis-je spécifier des ressources de mémoire et de disque pour les charges de travail Spark de Managed Service pour Apache Spark ?

Oui. Vous pouvez spécifier les niveaux de calcul et de disque des exécuteurs et des pilotes Premium, ainsi que la quantité de ressources de calcul et de disque des pilotes et des exécuteurs à allouer lorsque vous envoyez une charge de travail (consultez Propriétés d'allocation des ressources).

Comment spécifier la plage d'adresses IP pour mon réseau VPC Managed Service pour Apache Spark ?

Les charges de travail Managed Service pour Apache Spark s'exécutent dans votre environnement. Chaque pilote et exécuteur Spark d'une charge de travail Serverless Spark consomme une adresse IP interne dans votre réseau VPC Managed Service for Apache Spark. /16 est une plage d'adresses CIDR typique spécifiée par l'utilisateur pour un réseau VPC Managed Service pour Apache Spark. Vous pouvez limiter la plage d'adresses IP de votre réseau en fonction du nombre de charges de travail simultanées que vous prévoyez d'exécuter.

Managed Service pour Apache Spark est-il compatible avec la résidence des données ?

Oui. Vous spécifiez la région dans laquelle votre charge de travail est traitée. Localisez vos ensembles de données d'entrée et de sortie dans la région spécifiée.

Comment Managed Service for Apache Spark sélectionne-t-il une zone dans la région que vous avez spécifiée pour exécuter la charge de travail ?

Managed Service pour Apache Spark sélectionne la zone Compute Engine dans laquelle il exécute une charge de travail en fonction de la capacité et de la disponibilité. Si une zone devient indisponible après le démarrage d'une charge de travail, celle-ci échoue et vous devez la renvoyer.

Comment les charges de travail Managed Service pour Apache Spark utilisent-elles les ressources de calcul ?

Chaque charge de travail s'exécute sur ses propres ressources de calcul. Les ressources de calcul ne sont pas partagées ni réutilisées entre plusieurs envois par lot.

Bonnes pratiques :

  • Optimisez votre charge de travail pour les tâches de durée moyenne, et non pour les tâches de courte durée.

  • Conservez les données auxquelles accèdent plusieurs charges de travail dans Cloud Storage.

Où puis-je trouver des informations sur les annonces, les fonctionnalités, les corrections de bugs, les problèmes connus et les obsolescences concernant Managed Service pour Apache Spark ?

Consultez les notes de version de Managed Service pour Apache Spark.

Les charges de travail simultanées se disputent-elles les ressources ?

Les charges de travail Managed Service pour Apache Spark ne sont en concurrence pour les ressources que si votre quota de ressources est insuffisant pour exécuter toutes les charges de travail en cours d'exécution simultanément. Sinon, les charges de travail sont complètement isolées les unes des autres.

Comment le quota Managed Service pour Apache Spark est-il attribué ?

Les lots Managed Service pour Apache Spark consomment des ressources Google Cloud . Pour en savoir plus, consultez la page Quotas de Dataproc sans serveur.

Dois-je configurer un serveur d'historique persistant Managed Service pour Apache Spark ?

La configuration d'un Persistent History Server (PHS) à utiliser avec Managed Service for Apache Spark est facultative.Vous pouvez utiliser le PHS pour afficher les événements Spark et d'autres journaux dans un bucket Cloud Storage spécifié jusqu'à la période de rétention (TTL) de 90 jours du bucket temporaire et de préparation Managed Service for Apache Spark et au-delà.

Quels journaux Spark Managed Service pour Apache Spark sont disponibles ?

Les journaux des pilotes et des exécuteurs Spark sont disponibles dans Cloud Logging pendant et après l'exécution de la charge de travail Spark. De plus, les applications Spark sont visibles dans l'interface Web du serveur d'historique persistant (PHS) pendant l'exécution de la charge de travail (sélectionnez PHS > Applications incomplètes dans l'UI PHS).

Si vous configurez un PHS Managed Service for Apache Spark, il fournit un accès permanent aux journaux d'événements Spark enregistrés dans Cloud Storage, qui fournissent des informations sur l'exécution des applications Spark, telles que les événements DAG et d'exécution.

Puis-je définir le nombre d'exécuteurs pour ma charge de travail Spark ?

Oui. Vous pouvez définir le nombre d'exécuteurs pour une charge de travail Spark à l'aide de la propriété spark.executor.instances. Toutefois, le nombre total de cœurs qu'une charge de travail peut utiliser est plus important que le nombre d'exécuteurs, car Spark exécute une tâche par cœur. Par exemple, si une charge de travail comporte quatre exécuteurs avec deux cœurs chacun, elle exécutera 4 * 2 = 8 tâches en même temps. Il exécutera également le même nombre de tâches pour une charge de travail comportant deux exécuteurs avec quatre cœurs chacun. Comme le nombre de cœurs est le même pour chaque charge de travail, elles exécuteront le même nombre de tâches. Vous pouvez utiliser la propriété spark.executor.cores pour définir le nombre de cœurs par exécuteur pour votre charge de travail Managed Service for Apache Spark.

Quelles métriques Spark Managed Service pour Apache Spark utilise-t-il pour l'autoscaling ?

Managed Service pour Apache Spark examine les métriques d'allocation dynamique maximum-needed et running de Spark pour déterminer s'il faut augmenter ou réduire la capacité. Consultez Autoscaling Managed Service pour Apache Spark.

Puis-je configurer le comportement d'autoscaling de Managed Service pour Apache Spark à l'aide des propriétés Spark ?

Oui. L'autoscaling de Managed Service pour Apache Spark est basé sur l'allocation dynamique Spark et est activé par défaut. Vous pouvez ajuster les propriétés Spark et les propriétés d'allocation dynamique Spark suivantes :

  • spark.executor.instances
  • spark.dynamicAllocation.initialExecutors
  • spark.dynamicAllocation.minExecutors
  • spark.dynamicAllocation.maxExecutors

Pourquoi dois-je empaqueter mon code dans un fichier JAR pour envoyer ma charge de travail Spark ?

Spark est écrit en Scala, ce qui signifie que les processus de pilote et de nœud de calcul fonctionnent en tant que processus JVM. Dans les langages JVM, le fichier JAR est le principal moyen d'empaqueter le code. Vous transmettez le fichier JAR à Managed Service pour Apache Spark lorsque vous envoyez une charge de travail.