NB : Cet article a été co-écrit avec Romain Sagean, SRE chez Alma
Les données TPC-DS
Le Transaction Processing Performance Council (TPC) est un organisme qui met à disposition des scénarios de benchmark standard. Cela permet de comparer tout ce que l’on veut via un référentiel commun.
Pour Spark, il est commun d’utiliser le jeu de données TPC-DS. Il a été conçu pour des benchmarks de traitement SQL. Il est donc idéal pour Spark et sa bibliothèque Spark SQL.
Plusieurs méthodes existent pour obtenir le jeu de données du benchmark TPC-DS dont de multiples projets open source. Les jeux de données sont également présents intégralement sur des stockages publics.
Il est également possible de choisir la taille du jeu de données que nous souhaitons utiliser. Cela peut aller de 1Go à 100To.
Objectif du benchmark
La première question que nous nous sommes posés est : quel impact y a-t-il à choisir Yarn ou Kubernetes sur le temps de traitement d’un job Spark ?
À partir de là nous avons réfléchi à des objectifs plus précis pour un benchmark et nous en avons retenus 3 :
- Qui est le plus rapide / résilient pour un shuffle entre Kubernetes et Hadoop ?
- Qui est le plus performant pour la création et la maintenance de dizaines d’executeurs en parallèle ?
- Quel est l’impact d’un stockage décentralisé comme un Object Storage par rapport à HDFS dans un cluster Hadoop ?
Préparer son jeu de données
Si nous voulons tester les différences entre deux exécutions à plusieurs dizaines d’executors, nous avons besoin de choisir un jeu de données assez volumineux. Notre première idée a été de nous lancer avec le plus gros volume possible de donnée : 100To.
Générer 100To de données est une tâche qui coûterait très cher en infrastructure et prendrait beaucoup de temps. C’est pourquoi nous avons choisi de récupérer la donnée venant d’un Bucket S3 public d’AWS, dans lequel la donnée est disponible pour 3To, 10To, 30To ou 100To.
Nous avons choisi Scaleway comme Cloud Provider. Pour en savoir plus sur ce choix, je vous redirige vers notre article sur les limites de l'Object Storage de Scaleway face à Spark qui est à paraitre prochainement.
Le service managé Object Storage de Scaleway est compatible avec l'API S3 d’AWS. Cela signifie que nous pouvons nous en servir comme si c'était un bucket S3 d’AWS mais configuré sur une autre région avec d'autres credentials. Et pour cela Scaleway nous suggère un outil nommé Rclone qui permet de migrer facilement le contenu d’un Object Storage vers un autre, peu importe le Cloud Provider. Sa vraie plus-value dans notre cas est la façon dont Rclone va gérer nos credentials à notre place puisque nous devons nous authentifier à AWS et Scaleway en même temps. Pour accéder au bucket S3 public d'AWS, n'importe quel credential correspondant à un compte AWS suffit.
Une fois que nous avons suivi le tutoriel de Scaleway pour configurer Rclone, il ne reste plus qu'à lancer notre commande de clonage :
<code class="code-element">rclone copy --progress aws:redshift-downloads/TPC-DS/2.13/100TB/ scaleway:datalake-spark-benchmark/data/TPC/100TB</code>
Bien choisir son volume de données
Quand nous avons lancé la commande la première fois, nous avons été surpris du débit de transfert de fichier entre les deux systèmes de stockage. Environ 6 mo/s en moyenne. À ce rythme là, pour 100To de données, nous y étions encore 1 an plus tard.
Il s’avère que Rclone utilise notre connexion internet pour transférer les données d'un bucket à un autre. Ce n'est pas grave, nous pouvons louer une VM GP1-XL de chez Scaleway qui offre 10 Gb/s de bande passante, ce qui devrait prendre 22 heures tout au plus pour les 100To. Pourtant, une fois lancé sur la GP1-XL de Scaleway nous plafonnons à 100 mo/s.
Le problème, c’est qu’un stockage objet comme S3 et celui de Scaleway ont un coût en temps non fractionnable lorsque l'on souhaite écrire un fichier. Que celui-ci fasse 1mo ou 100Go, il y a toujours un temps de synchronisation entre chaque écriture de fichier. Dans notre cas, les différents fichiers du jeu de données fournis par AWS ont été découpés en morceaux de 128mo. Il y a donc des dizaines de milliers et que pour 1 seconde passée à copier un fichier, nous perdons quelques secondes à communiquer avec notre stockage objet et la vitesse moyenne affichée plafonne à 100 mo/s.
Nous avons donc à nouveau réfléchi à nos ambitions et nos objectifs pour notre benchmark. Nous savons que nous avons besoin d’un gros jeu de données, et par défaut nous voulions le plus gros. Mais est-ce vraiment nécessaire pour obtenir de bons résultats d’avoir 100To de données ? Si on y repense, cela prendrait énormément de temps même avec des centaines d’executors de traiter autant de données. De plus nous avons estimé que quelques dizaines d’executors en parallèle nous suffisaient pour pouvoir répondre à nos questions.
C’est pourquoi nous avons finalement choisi de partir sur 10To de données pour le TPC-DS. Cela nous a pris une journée pour le télécharger avec une GP1-XL de Scaleway.
Ce que nous retenons
Le TPC met à notre disposition des scénarios de benchmark. Celui qui nous intéresse pour Spark et tout traitement basé sur une logique SQL est le TPC-DS.
Nous avons choisi la taille de notre jeu de données en fonction des réponses que nous cherchons avec notre benchmark. 10To de données nous parait suffisant pour justifier de lancer des jobs Spark de plusieurs dizaines d’executors, et donc être capables de déterminer s'il y a un impact entre l'utilisation de Yarn ou Kubernetes lorsque l'on a besoin de beaucoup d'executors.
Nous aurions pu utiliser plus de données, mais il a également fallu être réaliste avec les moyens que nous avions à notre disposition. Nous avons estimé que l’apport sur les résultats n’aurait pas été à la hauteur des coûts mis en place pour traiter 100To de données.
Rclone nous a permis de cloner facilement toute la donnée mise à disposition par AWS vers notre Object Storage chez Scaleway. Il faut quand même faire attention parce que l'outil utilise notre bande passante pour transférer les données. C'est pourquoi nous avons loué une VM chez Scaleway pour cette tache.
La prochaine étape est de réussir à exécuter une requête du benchmark TPC-DS avec Spark sur la donnée que nous avons récupéré. Pour cela, il faudra attendre le prochain épisode.
