Cette page contient des questions fréquentes 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 sans serveur de Managed Service pour Apache Spark, et non aux déploiements de cluster.
Quand dois-je utiliser le déploiement sans serveur de Managed Service pour Apache Spark au lieu du déploiement de cluster Managed Service pour Apache Spark ?
Déploiement sans serveur de 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 l'infrastructure de votre charge de travail et de votre session interactive.
Déploiement de cluster Managed Service pour Apache Spark :
Compatible avec l'envoi de différents types de tâches Spark et de 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 de Managed Service pour Apache Spark ?
Exécuter des tâches de streaming à l'aide des bibliothèques de streaming Spark. Remarque : Le streaming n'est pas un service géré. Vous devez donc gérer la création de points de contrôle et les redémarrages.
Entraîner des modèles à l'aide de Spark MLlib.
Utiliser des notebooks SQL interactifs pour l'exploration de données, les graphiques, les séries temporelles et l'analyse géospatiale.
Orchestrer les charges de travail Managed Service pour Apache Spark avec Managed Service pour Apache Airflow, un service Apache Airflow géré.
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 une incidence sur votre Google Cloud quota de ressources. 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 de Managed Service pour Apache Spark ?
- Oui. Vous pouvez utiliser une image de conteneur personnalisée au lieu de l'image de conteneur par défaut. Consultez Utiliser des conteneurs personnalisés avec Managed Service pour Apache Spark.
Puis-je spécifier des ressources de mémoire et de disque pour les charges de travail Spark Managed Service pour Apache Spark ?
Oui. Vous pouvez spécifier des niveaux de calcul et de disque pour les exécuteurs et les pilotes premium, ainsi que la quantité de ressources de calcul et de disque à allouer pour les pilotes et les exécuteurs lorsque vous envoyez une charge de travail (consultez Propriétés d'allocation de 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 Spark et chaque exécuteur Spark d'une charge de travail Serverless Spark consomme une
adresse IP interne dans votre réseau VPC Managed Service pour Apache Spark.
/16 est une plage d'adresses
CIDR généralement 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 pour Apache Spark sélectionne-t-il une zone dans la région 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. Plusieurs envois par lot ne partagent ni ne réutilisent les ressources de calcul.
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 plusieurs charges de travail accèdent 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 abandons de Managed Service pour Apache Spark ?
Consultez les notes de version de Managed Service pour Apache Spark.
Les charges de travail simultanées sont-elles en concurrence pour 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 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 alloué ?
Les lots Managed Service pour Apache Spark consomment des Google Cloud ressources. Pour en savoir plus, consultez Quotas Dataproc sans serveur.
Dois-je configurer un serveur d'historique persistant Managed Service pour Apache Spark ?
La configuration d'un serveur d'historique persistant (PHS) à utiliser avec Managed Service pour 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 conservation de 90 jours (TTL) standard du bucket temporaire et de préparation Managed Service pour Apache Spark , et après.
Quels journaux Spark Managed Service pour Apache Spark sont disponibles ?
Les journaux des exécuteurs et des pilotes 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 pour Apache Spark, il fournit un accès persistant aux journaux d'événements Spark enregistrés dans Cloud Storage, qui donnent un aperçu de l'exécution des applications Spark, comme les événements DAG et d'exécuteur.
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
spark.executor.instances
propriété. 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. Elle exécutera également le même nombre de tâches pour une charge de travail comportant deux exécuteurs avec quatre cœurs chacun. Étant donné que le nombre de cœurs pour chaque charge de travail est le même, elles exécuteront le même nombre de tâches. Vous pouvez utiliser la
spark.executor.cores
propriété pour définir le nombre de cœurs par exécuteur pour votre charge de travail Managed Service pour 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 doit effectuer un scaling à la hausse ou à la baisse.
Consultez Autoscaling Managed Service pour Apache Spark.
Puis-je configurer le comportement d'autoscaling Managed Service pour Apache Spark à l'aide des propriétés Spark ?
Oui. L'autoscaling 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.instancesspark.dynamicAllocation.initialExecutorsspark.dynamicAllocation.minExecutorsspark.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 du pilote et du nœud de calcul fonctionnent en tant que processus JVM. Dans les langages JVM, le fichier JAR est le principal moyen d'empaqueter du code. Vous transmettez le fichier JAR à Managed Service pour Apache Spark lorsque vous envoyez une charge de travail.