Vous en avez assez de passer des nuits blanches à faire tourner un pipeline sur Hadoop ? Retrouvez le sommeil grâce à Dataproc !

Vous êtes data engineer ou data scientist ? Vous utilisez l’écosystème Hadoop sur site (on-premise) et souhaitez à la fois le rendre plus facile à gérer et faire baisser vos factures ?

C’était mon cas : j’ai cherché des solutions et expérimenté Dataproc.

Dataproc est un service proposé par Google Cloud Platform (GCP), créé en 2016. Il est entièrement géré (managed) et permet d’exécuter Spark et Hadoop. Il permet de tirer pleinement parti des outils de données open source pour les traitements batch, les requêtes, le streaming et le machine learning.

Cet article présente en détails les fonctionnalités de la solution et les moyens d’optimiser son usage, pour avoir un vrai impact sur les coûts, directs et indirects.

Pourquoi Dataproc ?

1. Un service entièrement managé qui accélère la création d’un cluster et facilite sa gestion.
2. Le principe de migration Lift and Shift des clusters Hadoop permet de migrer votre application Spark ou Hadoop vers GCP sans changer son architecture.
3. Optimise l’évolutivité et l’efficacité du Cloud : sépare les ressources de calcul et de stockage avec Cloud Storage et vous permet de réduire les coûts liés à Hadoop en désactivant les clusters lorsque vous n’en avez pas besoin.
4. Avec moins de temps et d’argent consacrés à l’administration, vous pouvez vous concentrer sur ce qui compte le plus : vos données !

Comment migrer des jobs Spark/Hadoop vers Dataproc ?

Le schéma suivant montre comment migrer un job Spark/Hadoop vers Dataproc selon les recommandations de Google Cloud.

Selon Google, pour la majorité des jobs Spark/Hadoop, le serveur HDFS peut être remplacé par le service Cloud Storage.

Dans un premier temps, il est nécessaire de créer un cluster Dataproc.

En parallèle, vous devez copier vos données résidentes dans le serveur HDFS sur site vers Google Cloud Storage, puis vous devrez changer le chemin des fichiers dans votre code d’application Spark/Hadoop de hdfs:// à gs://.

Ensuite, vous pouvez lancer votre job et suivre l’avancement de son exécution.

Comment créer et configurer un cluster Dataproc

Un cluster Dataproc peut être créé de différentes manières :

• avec Google Cloud Console
• avec l’outil de ligne de commande gcloud du SDK Cloud
• avec l’API REST Dataproc
• avec des bibliothèques clientes Cloud dans le langage de son choix : Python, Java, Nodes.js, etc.

Création et configuration d’un cluster avec Google Cloud Console (cf. illustration ci-dessous) :

ouvrez la page Dataproc intitulée créer un cluster

plusieurs panneaux sont proposés avec des champs remplis de valeurs par défaut. Vous pouvez changer de panneau, et garder ou modifier les valeurs pré-remplies pour personnaliser le cluster.

Ensuite, validez la création de votre cluster en cliquant sur CRÉER.

(En général, il faut compter 90 secondes pour le provisionnement d’un cluster Dataproc.)

Choix des images

Cloud Dataproc fournit des “images avec versions gérées pour regrouper le système d’exploitation, les composants big data et les connecteurs Google Cloud Platform en un seul package déployé sur votre cluster”

On peut choisir l’une des images standard proposé par Dataproc ou créer sa propre image personnalisée.

Ajouter des composantes supplémentaires

Vous avez la possibilité d’ajouter une ou plusieurs composantes supplémentaires (Jupyter Notebook, Presto,..) parmi la liste des composantes prises en charge par Dataproc

Si vous voulez ajouter une composante indisponible tel que Apache Livy — un service qui permet d’interagir facilement avec un cluster Spark via une API REST — le mécanisme Actions d’initialisation vous permet de fournir un script à exécuter sur tous les noeuds du cluster Dataproc au moment de provisionnement du cluster.

Créez votre fichier exécutable et importez-le dans Google Cloud Storage, puis fournissez le chemin du script dans la section Action d’initialisation (comme illustré dans l’image suivante).

Type de cluster

3 types de clusters Dataproc sont proposés :

• Standard (1 nœud maître, N nœuds de calcul)
• Un seul nœud (1 nœud maître, 0 nœud de calcul)
• Haute disponibilité (3 nœuds maîtres, N nœuds de calcul)

Le choix du cluster dépend de plusieurs paramètres : type des jobs exécutés, le besoin des équipes, etc.

Il existe deux classes de jobs Spark / Hadoop:

• Job batch : destiné à traiter un lot de données finies.
• Job streaming : destiné à traiter des données streaming infinies. L’exécution n’a théoriquement pas de fin.

Il peut y avoir différents besoins de vos équipes, voici quelques exemples :

• Démonstration de faisabilité d’une application
• Avoir un Notebook Spark toujours actif afin de développer et exécuter vos applications

Ainsi, certains besoins nécessitent un cluster de longue durée toujours actifs et d’autres nécessitent un cluster éphémère.

Selon les recommandations de Google :

• Utilisez des clusters Standards éphémères pour l’exécution de jobs de type batch avec un cluster par job. Chaque cluster est provisionné immédiatement avant l’exécution du job et détruit juste après.
• Optez pour le choix de Haute disponibilité pour un cluster de longue durée toujours actif afin d’assurer une tolérance aux pannes.

Les avantages d’un service comme Dataproc sont manifestes : un cluster peut être détruit à la fin de l’exécution d’un job, ce qui est inimaginable dans un cluster sur site (on-premise) où on ne peut pas simplement éteindre les machines.

Comment gérer le stockage de données avec Dataproc

Classiquement, un job Spark/Hadoop nécessite un serveur de stockage de données comme HDFS (Hadoop distributed file system) et un metastore tel que Hive metastore pour enregistrer les métadonnées des différentes tables et vues.

Pour avoir un HDFS au sein d’un cluster Dataproc, on doit ajouter un Persistent Disk (PD) aux noeuds du cluster. Ce disque persistant provoque des coûts supplémentaires, nécessite une gestion additionnelle et implique un couplage physique entre le calcul et le stockage. L’arrêt du cluster entraîne alors la perte des données.

Pour pallier ce problème, on opte plutôt pour l’utilisation de Cloud Storage : hautement scalable et durable, il permet de réaliser des opérations fortement cohérentes. Pour passer de HDFS à Cloud Storage, il suffit de corriger le chemin des fichiers dans le code de l’application de hdfs:// à gs://.

Indépendamment du choix de persistance, vous devez avoir un Hive metastore central pour l’ensemble des clusters Dataproc : Cloud SQL répond à ce besoin.

Traitement de données

Une fois que le cluster Dataproc est prêt et que les données sont en place et accessibles, il est possible de soumettre des jobs Spark, Hadoop, Hive,.. via la console ou en ligne de commande.

gcloud dataproc jobs submit pyspark \
 gs://dataproc-examples/pyspark/hello-world/hello-world.py \
 — cluster=cluster-name \
 — region=region

La commande ci-dessus, est un exemple de soumission d’un job PySpark au cluster Dataproc. Le script PySpark hello-world.py a été préalablement importé dans Cloud Storage.

L’image suivante synthétise l’ensemble des services Google Cloud impliqués dans une architecture d’exécution d’un job Dataproc.

Surveillance et sécurité

Le service de gestion des identités et des accès (Identity and Access Management) IAM, permet de configurer les permissions et les accès de chaque utilisateur. Cela assure un accès au strict minimum aux ressources requises pour une tâche donnée.

Afin de surveiller votre cluster Dataproc, Google Cloud nous met à disposition deux services intéressants :

• Cloud Logging : c’est l’endroit où se trouvent les logs, il permet également de définir un sink de données tel que Cloud Storage, Big Query ou un topic PubSub.
• Cloud Monitoring : c’est un dashboard rassemblant toutes les métriques comme l’utilisation de CPU, la mémoire consommée. Il est également possible de définir des alertes ou même utiliser les métriques dans une politique de redimensionnement du cluster Dataproc.

Optimisation des coûts

En appliquant les recommandations de Google en termes de stockage, nous séparons la couche de persistance (Cloud Storage) de la couche de traitement (nœuds du cluster Dataproc). Ainsi, on rend possible la création de clusters éphémères à la demande : on les crée immédiatement avant l’exécution d’un job et on les détruit juste après.

Les clusters éphémères n’étant pas actifs en permanence, cela permet de faire des économies. Il est possible de réduire encore les coûts en utilisant des nœuds de calcul secondaires.

Les VM de nœuds de calcul secondaires sont préemptives par défaut : elles peuvent être récupérées, supprimées du cluster, si elles sont requises par Google Cloud pour d’autres tâches. Une VM préemptive coûte jusqu’ à 80% moins cher qu’une VM non-préemptive, mais sa durée de vie ne dépasse pas 24 heures — ce qui peut parfois affecter la stabilité des jobs. On utilisera donc des VM préemptives plutôt pour traiter des données non critiques ou avoir des clusters de très grande taille à un coût réduit.

Il est difficile d’estimer le nombre de nœuds nécessaires pour effectuer une tâche. Le scaling du cluster permet d’ajuster le nombre noeuds en fonction de la charge de travail. Dataproc fournit une mise à l’échelle manuelle ainsi qu’une mise à l’échelle automatique grâce à l’API AutoscalingPolicies en se basant sur les métriques du cluster telles que l’utilisation de CPU.

Avec une politique de mise à l’échelle bien établie, on garantit une taille de cluster adaptée à la charge de travail et on évite ainsi le gaspillage des ressources.

Conclusion

L’usage d’un service comme Dataproc permet de réduire les coûts opérationnels, dans des proportions qui ne sont pas négligeables, pour traiter des données dans un environnement Spark/Hadoop.

Bien que cet article se focalise sur GCP Dataproc, il existe des services analogues proposés par les autres fournisseurs de Cloud comme AWS EMR et Azure HDInsight.

Dans d’autres environnements techniques que Spark/Hadoop, on pourra plutôt utiliser le service Dataflow : un service serverless pour traiter des données streaming et par lot qui se base sur le framework Apache Beam. Chez Neoxia, on recommande fortement son usage : on vous dira pourquoi bientôt dans un nouvel article !