Bonnes pratiques Dataproc pour la production

Ce document présente les bonnes pratiques Dataproc qui peuvent vous aider à exécuter des jobs de traitement de données fiables, efficaces et pertinents sur des clusters Dataproc dans des environnements de production.

Spécifier les versions d'image du cluster

Dataproc utilise des versions d'image pour regrouper le système d'exploitation, les composants big data et les connecteurs Google Cloud dans un package déployé sur un cluster. Si vous ne spécifiez pas de version d'image lorsque vous créez un cluster, Dataproc utilise par défaut la version d'image stable la plus récente.

Pour les environnements de production, associez votre cluster à une version d'image major.minor Dataproc spécifique, comme indiqué dans la commande gcloud CLI suivante. 

gcloud dataproc clusters create CLUSTER_NAME \
    --region=region \
    --image-version=2.0

Dataproc résout la version major.minor en la dernière version de correction (2.0 est résolu en 2.0.x). Remarque : Si vous devez vous appuyer sur une version de correction spécifique pour votre cluster, vous pouvez la spécifier (par exemple, --image-version=2.0.x). Pour en savoir plus, consultez Fonctionnement de la gestion des versions.

Versions d'image en préversion de Dataproc

De nouvelles versions mineures des images Dataproc sont disponibles dans une version preview avant leur publication dans le canal standard des versions mineures d'image. Utilisez une image d'aperçu pour tester et valider vos jobs par rapport à une nouvelle version mineure de l'image avant d'adopter la version mineure standard de l'image en production. Pour en savoir plus, consultez Gestion des versions Dataproc.

Utiliser des images personnalisées si nécessaire

Si vous devez ajouter des dépendances au cluster, telles que des bibliothèques Python natives, ou des logiciels de renforcement de la sécurité ou de protection antivirus, créez une image personnalisée à partir de la dernière image de votre version mineure cible. Cette pratique vous permet de répondre aux exigences de dépendance lorsque vous créez des clusters à l'aide de votre image personnalisée. Lorsque vous recréez votre image personnalisée pour mettre à jour les exigences de dépendance, utilisez la dernière version d'image mineure disponible dans la branche d'image mineure.

Envoyer des jobs au service Dataproc

Envoyez des tâches au service Dataproc avec un appel jobs.submit à l'aide de la CLI gcloud ou de la console Google Cloud . Définissez les autorisations pour les tâches et les clusters en attribuant des rôles Dataproc. Utilisez des rôles personnalisés pour séparer l'accès au cluster des autorisations d'envoi de jobs.

Voici les avantages de l'envoi de tâches au service Dataproc :

  • Aucun paramètre réseau compliqué n'est requis : l'API est largement accessible.
  • Gérez facilement les autorisations et les rôles IAM
  • Suivez facilement l'état des jobs, sans métadonnées de job Dataproc pour compliquer les résultats.

En production, exécutez les jobs qui ne dépendent que des dépendances au niveau du cluster avec une version mineure fixe de l'image (par exemple, --image-version=2.0). Regroupez les dépendances avec les jobs lors de leur envoi. Pour ce faire, il est courant d'envoyer un uber JAR à Spark ou MapReduce.

  • Exemple : Si un fichier JAR de job dépend de args4j et spark-sql, avec args4j spécifique au job et spark-sql une dépendance au niveau du cluster, regroupez args4j dans le fichier JAR uber du job.

Contrôler les emplacements des actions d'initialisation

Les actions d'initialisation vous permettent d'exécuter automatiquement des scripts ou d'installer des composants lorsque vous créez un cluster Dataproc (consultez le dépôt GitHub dataproc-initialization-actions pour découvrir les actions d'initialisation Dataproc courantes). Lorsque vous utilisez des actions d'initialisation de cluster dans un environnement de production, copiez les scripts d'initialisation dans Cloud Storage au lieu de les récupérer à partir d'un dépôt public. Cette pratique évite d'exécuter des scripts d'initialisation susceptibles d'être modifiés par d'autres utilisateurs.

Surveiller les notes de version de Dataproc

Dataproc publie régulièrement de nouvelles versions de correction des images. Consultez les notes de version Dataproc ou abonnez-vous-y pour connaître les dernières versions d'image Dataproc, ainsi que d'autres annonces, modifications et correctifs.

Afficher le bucket intermédiaire pour examiner les échecs

  1. Consultez le bucket de préproduction de votre cluster pour examiner les messages d'erreur liés au cluster et aux jobs. En règle générale, l'emplacement du bucket intermédiaire Cloud Storage est indiqué dans les messages d'erreur, comme le montre le texte en gras dans l'exemple de message d'erreur suivant :

    ERROR:
(gcloud.dataproc.clusters.create) Operation ... failed:
...
- Initialization action failed. Failed action ... see output in: 
gs://dataproc-<BUCKETID>-us-central1/google-cloud-dataproc-metainfo/CLUSTERID/<CLUSTER_ID>\dataproc-initialization-script-0_output

  2. Utilisez la gcloud CLI pour afficher le contenu du bucket intermédiaire : 

    gcloud storage cat gs://STAGING_BUCKET
    Exemple de résultat : 
    + readonly RANGER_VERSION=1.2.0
... Ranger admin password not set. Please use metadata flag - default-password

Obtenir de l'aide

Google Cloud prend en charge vos charges de travail de production OSS et vous aide à respecter vos SLA d'entreprise grâce à des niveaux d'assistance. De plus,les Google Cloud services de conseil peuvent vous fournir des conseils sur les bonnes pratiques à suivre pour les déploiements en production de votre équipe.

Pour en savoir plus