Bonnes pratiques Dataproc pour la production

Ce document présente les bonnes pratiques Dataproc qui peuvent vous aider à exécuter des tâches de traitement de données fiables, efficaces et pertinentes 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 Google Cloud les connecteurs dans un package déployé sur un cluster. Si vous ne spécifiez pas de version d'image lors de la création d'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 Dataproc spécifique major.minor, comme illustré 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 dans la dernière version mineure (2.0 est résolu en 2.0.x). Remarque : Si vous devez vous appuyer sur une version mineure spécifique pour votre cluster, vous pouvez la spécifier : par exemple, --image-version=2.0.x. Pour en savoir plus, consultez la section Fonctionnement de la gestion des versions.

Versions d'image en préversion de Dataproc

Les nouvelles versions mineures des images Dataproc sont disponibles en version preview avant d'être publiées dans la version d'image mineure standard. Utilisez une image en préversion pour tester et valider vos tâches par rapport à une nouvelle version d'image mineure avant d'adopter la version d'image mineure standard en production. Pour en savoir plus, consultez la section 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 contre les virus, créez une image personnalisée à partir de la dernière image de votre version d'image 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 version d'image mineure.

Envoyer des tâches au service Dataproc

Envoyez des tâches au service Dataproc avec un jobs.submit à l'aide de la CLI gcloud ou de la Google Cloud console. Définissez les autorisations de tâche et de cluster 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 tâches.

Avantages de l'envoi de tâches au service Dataproc :

  • Aucun paramètre réseau complexe n'est requis : l'API est largement accessible.
  • Gestion facile des autorisations et des rôles IAM
  • Suivi facile de l'état des tâches : aucune métadonnée de tâche Dataproc ne complique les résultats.

En production, exécutez des tâches qui ne dépendent que des dépendances au niveau du cluster dans une version d'image mineure fixe (par exemple, --image-version=2.0). Regroupez les dépendances avec les tâches lors de leur envoi. L'envoi d'un uber jar à Spark ou MapReduce est une méthode courante pour ce faire.

  • Exemple : Si un fichier JAR de tâche dépend de args4j et spark-sql, avec args4j spécifique à la tâche et spark-sql une dépendance au niveau du cluster, regroupez args4j dans l'uber jar de la tâche.

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 connaître 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 personnes.

Surveiller les notes de version de Dataproc

Dataproc publie régulièrement de nouvelles versions d'image mineures. Consultez ou abonnez-vous aux notes de version de Dataproc pour être informé des dernières versions d'image Dataproc et d'autres annonces, modifications et correctifs.

Afficher le bucket de préproduction pour examiner les échecs

  1. Consultez le bucket de préproduction de votre cluster pour examiner les messages d'erreur du cluster et des tâches. En règle générale, l'emplacement Cloud Storage du bucket de préproduction est indiqué dans les messages d'erreur, comme illustré 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 CLI gcloud pour afficher le contenu du bucket de préproduction : 

    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 OSS de production et vous aide à respecter vos contrats de niveau de service (SLA) grâce à différents niveaux d'assistance. De plus, Google Cloud les services de conseil peuvent vous fournir des conseils sur les bonnes pratiques pour les déploiements de production de votre équipe.

Pour en savoir plus