Apache Spark, initialement développé à l’université de Californie à Berkeley par AMPLab, est un framework de traitement de données distribuées pour effectuer des analyses complexes à grande échelle. Dans un écosystème riche, il a su se hisser parmi les produits les plus utilisés en Big Data. Il a permis de nombreuses avancées pour la recherche et l’ingénierie. Mais il a surtout su réunir une vraie communauté qui possède depuis plusieurs années sa propre conférence: le Spark Summit.
Le Spark Summit est organisé par Databricks. L’édition européenne s’est tenue cette année à Londres les 3 et 4 octobre. Depuis l’an dernier elle a été renommée en Spark+AI Summit. Comme lors de l’édition précédente, la conférence était l’occasion de mettre en avant la façon dont Apache Spark et sa communauté favorisent les avancés en intelligence artificielle à grande échelle. Le rendez-vous entre des développeurs, chercheurs et autres utilisateurs du framework a été un temps d’échange et de retours d’expérience sur l’avenir de Spark. Nous y étions et cet article a pour but de recueillir quelques points marquants de l’événement qui a réuni plus de 1400 passionnés de Data Science et de Engineering.
Les keynotes
C’est Kat Hawkins, présentatrice d’une émission technologique sur la BCC qui donne le coup d’envoi de la conférence et qui introduit chaque keynote. Elle est reconnue pour s’être investie dans des sujets tournant autour de l’IA et la société. En particulier dans son rôle pour le secteur médical et l’aide aux personnes invalides. Sa présence renvoie un message fort sur la valeur ajoutée des progrès récents en IA.
Unifying State-of-the-Art AI and Big Data in Apache Spark – Reynold Xin
Lors de cette présentation sur l’évolution de Spark, Reynold Xin revient sur la création du framework. Il résume son origine (de manière très réductrice) à la participation de Lester Mackey au Netflix Prize. Il retrace à partir de là, les évolutions qui nous ont amenés jusqu’à un nouveau composant : Hydrogene. Ce projet repose sur deux principes.
- Les vectorized UDFs, qui ont pour but de vectoriser les échanges de données entre le monde Spark et les frameworks extérieurs.
- Les Barriers, qui permettront de regrouper sous un stage certaines tâches dépendantes entre elles et induites par d’autres librairies.
Ces deux points sont adressés pour favoriser l’utilisation des frameworks de Deep Learning en complément de Spark. Les frameworks comme TensorFlow, Pytorch ou MXNet sont de plus en plus nombreux. Hydrogene vient donc aider Spark à unifier le traitement de données Big Data et l’entraînement distribué de modèles.
MLflow: Infrastructure for a Complete Machine Learning Life Cycle – Matei Zaharia
C’est ensuite à Matei Zaharia, Chief Technologist chez Databricks (et premier développeur de Spark) de prendre la parole pour nous parler de MLflow. MLflow est une Machine Learning Platform, au même titre que FBLearner, TFX, et Michelangelo. Respectivement crées par Facebook, Google et Uber. Ces plateformes complètent le cadre de développement en interne pour des projets Data Science. MLflow se distingue donc en étant open source, utilisable avec n’importe quelle librairie de Machine Learning et agnostique à l’écosystème Big Data. Au-delà de la présentation de MLflow, ce talk a été l’occasion de faire l’annonce de la release 0.7.0. Elle apporte le support du langage R, plusieurs fonctionnalités sur l’interface web et de nombreux bugfix. L’outil renforce le cycle de vie des projets Data Sciences et espère bien briser les silos entre Data Scientistes et Ingénieurs.
Cette plateforme vient combler un gap entre Data Scientists et Data Engineers et nous avons eu envie de l’essayer : ne manquez pas notre retour d’expérience sur MLflow à la XebiCon’18 « MLflow and the Machine Learning Lifecycle ».
The Power of Unified Analytics – Ali Ghodsi
Dans cette présentation, Ali Ghodsi, CEO de Databricks, nous explique comment ses équipes se sont inspirées des GAFAs et de leurs plateformes de traitement de données. À l’époque on constate que seulement 1% des entreprises profitent des techniques d’intelligence artificielle. Le but de Databricks devient donc de démocratiser ce qui a été mis en place chez Twitter, Google ou Facebook en proposant du Spark “on demand”. Il présente ensuite les challenges qu’ils restent et les nouveaux produits pour les adresser :
- Data is not ready for AI
Une fois les Datalakes construits, l’application de techniques de Machine Learning reste compliquée, voire impossible, sur les données qu’ils contiennent. Pour répondre à ce challenge Databricks Delta, ajoute des notions d’intégrité de données et de Lineage à la plateforme.
- Data and AI technology silos
La diversité et vitesse d’évolution des librairies de Machine Learning rend difficile l’adaptation des équipes. Databricks Runtime For Machine Learning est proposé sur la plateforme cloud et permet de profiter des dernières versions des outils les plus connus.
- Data scientist and engineer are in silos
Enfin, la fonctionnalité Time-Travel est présentée pour fluidifier le déploiement des modèles. Il rend possible les rollbacks sur les modèles ou encore la recherche d’erreurs de traitement passées. Pour ce faire, Time-Travel fait un lien entre Databricks Delta et MLflow.
Toutes ces avancés suivent le thème général de la conférence: Unifying data science and engineering.
Premier jour
Après avoir assisté aux premières keynotes dans le ICC Audithorium, nous sommes invités à rejoindre les différentes salles de conférence. Chaque salle est associée une track particulière: Data Sciences, Developer, Spark Use Case, AI, Research, Enterprise et Technical Deep Dive. Les choses sérieuses vont commencer.
Patterns for successful DS projects – Bill Chambers
Bill Chambers, développeur d’Apache Spark depuis toujours et co-auteur de “Spark: The Definitive Guide” avec Matei Zaharia, nous a présenté des patterns pour amener au succès des projets Data Science. Il en a décrit six, trois organisationnels et trois techniques.
Le premier pattern organisationnel est la VALEUR, dans le sens où pour bien réussir il faut que le projet Data Science apporte de la valeur à l’entreprise. Dans ce cadre il a cité l’exemple de Stitch Fix, une start-up américaine qui a fait de la Data Science le coeur de son business : la Data Science n’a pas été juste collée à sa culture, c’est sa culture et vise à répondre aux besoins de ses clients.
Le deuxième pattern c’est l’ALIGNEMENT entre ce que le management dit vouloir faire et les ressources réellement allouées. Nous vivons dans un cadre industriel où tout le monde se dit qu’il faut faire de la Data Science mais ces questions se posent : « Est-ce que les projets DS sont concrètement priorisés par le management ? Est-ce que l’entreprise possède l’infrastructure et l’équipe nécessaires à mettre en production des projets DS ? »
Le troisième pattern c’est la DISCIPLINE. L’idée est de s’imposer un formalisme qui permette d’évaluer objectivement si un produit DS apporte ou pas de la valeur. Cela se fait seulement quand le produit est dans les mains du client et en évaluant son feedback. La discipline est nécessaire pour ne pas tomber dans la tentation de manipuler la donnée pour qu’elle confirme des convictions a priori. En fait en cherchant ce que l’on veut on va finir par trouver mais on ne saura pas s’il y a une vrai valeur ajoutée.
 |
 |
Concernant les patterns techniques, il a commencé par la HIÉRARCHIE. Dans sa réflexion il est parti du Maslow’s hierarchy of needs pour développer la pyramide des besoins d’un projet Data Science. Il n’est pas le seul à y avoir pensé (The AI hierarchy of needs), l’idée est d’avoir des bases solides pour pouvoir arriver jusqu’à la mise en production. Comme cela peut être long et demander beaucoup de ressources pour avoir la pyramide complète, son conseil est de commencer avec un seul use case mais de le mener de bout en bout.
 |
 |
Cette hiérarchie peut aussi aider à éviter les pipelines jungles décrites dans cet article NIPS 2015.
Le cinquième pattern est la SIMPLICITÉ. Le principe du K.I.S.S. (keep it simple stupid) qui vient du design et qui est appliqué ici aux projets Data Science. “Simple” ne veut pas dire “facile” mais il faut garder en tête que le code conçu par un Data Scientist va potentiellement être « déboguer » par d’autres profils et plus la structure est compliquée, plus difficile devient son entretien. Mais ce n’est pas que cela, en suivant les règles d’un très connu article sur les bonnes pratiques en Data Science, la simplicité peut aussi être utilisée pour construire une pipeline complète avant de la complexifier et procéder ainsi de façon itérative au développement.
Le dernier pattern c’est la TRAÇABILITÉ. Les Data Scientists le savent, la partie du projet qui prend le plus de temps ce n’est pas le modèle mais tout le travail d’exploration et transformation de données qui précède. Dans ce cadre, savoir exactement quel traitement a été utilisé pour obtenir un tel résultat est essentiel et Databricks avec MLflow essaie d’adresser ce point.
Bill Chambers et ses Patterns for successful DataSciences projects au Spark+AI Summit 2018
Deep Dive into Query Execution in Spark SQL 2.3.1 – Jacek Laskowski
Jacek Laskowski, consultant indépendant et formateur sur les sujets Apache Spark & Apache Kafka, nous offre un technical deep dive sur deux sessions. Vous avez peut-être découvert cette présentation lors du DataXDay ;). Ce talk a en effet déjà été donné en mai à Paris. Il entre dans le détail de l’exécution de requêtes SQL sur les Data Frames Spark. Comment sont elles « parsées », interprétées puis optimisées. Alors qu’est-ce qui change cette fois ? Pas de démo live. À la place Jacek aborde quelques nouveautés de la version 2.3.1. Notamment les SparkSessions Extentions qui permettent l’injection de règles d’exécution spécifiques. La méthode .withExtensions(???) de SparkSession.Builder prend en paramètre une instance de SparkSessionExtensions, grâce à laquelle on peut injecter un Analyzer, un Optimizer, des Planning Strategies ou un Customized Parser.
SparkSession.builder()
.master("...")
.conf("...", true)
.withExtensions { extensions =>
extensions.injectResolutionRule { session =>
...
}
extensions.injectParser { (session, parser) =>
...
}
}
.getOrCreate()
Query Execution in Spark 2.3.1, un talk par Jacek Laskowski
Lessons from the Field, Episode II: Applying Best Practices to Your Apache Spark Applications – Silvio Fiorito
Silvio Fiorito de Databricks a fait un retour d’expérience sur comment écrire des applications fiables et avec des bonnes performances. Selon lui, la clé est de comprendre les mécanismes de fonctionnement de Spark liés à :
- les points de force et de faiblesse de chaque type de source de données
- comment les données sont distribuées ; comment le shuffling est exécuté ; comment la parallélisation est gérée
- comment l’interface graphique et le graphe d’exécution peuvent aider à debugger
Les différents formats supportés par Spark (CSV, JSON, Parquet, Avro, ORC, etc.) ont tous des avantages et des contraintes qu’il faut connaître pour mieux s’adapter aux cas d’usages mais, indépendamment du format, un des paramètres de lecture est inferSchema. Si sa valeur est True, la lecture peut prendre beaucoup de temps car Spark dans le pire de cas va devoir scanner l’intégralité de données pour définir le type. L’idéal serait de passer le schéma si on le connaît ou de ne pas cocher l’inférence. Néanmoins, il vaut mieux être précis avec les types spécifiés car la taille de shuffling dépend du type.
En outre, tous les formats ne sont pas distribuables. La parallélisation de l’opération de lecture n’est donc pas possible. Pour la même raison, l’optimisation adoptée avec les fichiers Parquet de predicate (ou filter) pushdown n’est pas toujours possible.
Concernant la Spark UI et le graphe d’exécution le message est clair : ils nous donnent des informations très utiles pour comprendre comment l’exécution marche et par conséquent comment améliorer les performances d’une application. C’est grâce à ces outils que l’on peut s’apercevoir que l’ordre des opérations compte (filtre et sélection avant d’autres transformations) et que les aller-retours entre data frames et RDD sont peu performantes. Dans les deux cas l’idée est de pouvoir profiter du predicate pushdown qui n’est pas possible si le lineage est interrompu. D’autres exemples sont les self-joins et les opérations d’union répétées : elles impliquent une lecture double et un incrément de complexité.
 |
 |
 |
Pour résumer, ses recommandations (Pandas UDFs vs PySpark UDFs) :
Deuxième jour
Une soirée dédiée à l’échange entre les participants est organisée après la première journée de conférence. Quelques rencontres, deux ou trois hors-d’œuvre et une pause bien méritée qui nous permettra d’attaquer la deuxième journée.
Pitfalls of Apache Spark at Scale – Cesar Delgado et DB Tsai
Ce talk nous est présenté par deux développeurs d’Apple qui travaillent pour le service Siri avec Apache Spark. Comme les données auxquelles Siri accède sont très hétérogènes, ils ont fait le choix de les organiser de façon relationnelle imbriquée : il y a que 5 colonnes principales qui imbriquent quelque 2000 champs. Les données ainsi organisées sont stockées en format parquet partitionné par jour. Pour garantir la cohérence de données, ils ont choisi d’utiliser les Datasets et ses propriétés de typage plutôt que les Dataframes.
Dans ce contexte nombreux sont les inconvénients :
- les Datasets sont moins rapides que le Dataframes
- les utilisateurs finaux de données n’ont pas besoin d’accéder à tous les champs imbriqués en même temps, mais plutôt à des sous-ensembles
- le schema pruning et le predicate pushdown fonctionnent mal sur les champs imbriqués dans Spark
À partir de ce constat, ils ont développé des optimisations [SPARK-4502], [SPARK-25363], [SPARK-25556], qui permettent d’améliorer les performances sur un benchmark :
- temps d’exécution 21x plus rapide
- 8x moins de données lues
Ces contributions sont open-source et deux d’entre elles sont déjà disponibles dans la version de Spark 2.4.0 sortie fin octobre.
Pitfalls of Apache Spark at Scale: les supports de présentation
A Tale of Three Deep Learning Frameworks: TensorFlow, Keras, & PyTorch – Jules Damji et Brooke Wenig
Jules et Brooke on fait un tour d’horizon des principaux frameworks de Deep Learning disponibles en Python. Ils ont montré à travers des exemples de code les spécificités de chacun pour enfin donner quelques critères de choix.
TensorFlow, le framework historique développé par Google, se base sur du backend C/C++ et est disponibles avec trois APIs C++, Go et Python. Il a un fonctionnement similaire à Spark dans le sens où l’on crée d’abord un graphe d’exécution qui est exécuté dans un second temps au lancement (lazy execution). La courbe d’apprentissage peut être abrupte tant il est bas niveau et propose un paramétrage très complet. L’un des points forts de TF est sûrement la disponibilité d’outils additionnels tels que TensorBoard et TFX pour le déploiement de modèles entraînés.
Keras, maintenant sous l’égide de Google, est beaucoup plus haut niveaux que TF ce qui facilite sa prise en main et son utilisation. Il marche avec plusieurs backends : TensorFlow, CNTK et Theano.
PyTorch, issu de Facebook, est le plus pythonic des trois, le code ressemble beaucoup à du code Python et les habitués vont plus facilement s’y trouver. En effet, avec TF et Keras l’instantiation du graph d’exécution se fait en suivant une structure de code ad hoc. Avec PyTorch l’instantiation est faite avec de classes classiques Python. C’est assez facile à debugger et il est intégré avec Tensorborad.
Les trois frameworks sont intégrés avec Horovod, un framework créé par Uber qui permet l’entraînement distribué. Enfin, chacun à ses particularités et selon les usages l’un peut-être préférable aux autres.
Présentation de Jules Damji et Brooke Wenig au Spark+AI Summit Europe 2018
Bucketing in Spark SQL 2.3 – Jacek Laskowsky
Jacek nous propose une toute nouvelle présentation, il nous parle cette fois d’une technique d’optimisation le : bucketing, disponible dès la version 2.1 de Spark. Elle consiste à contrôler l’emplacement de données pour réduire le shuffling et améliorer ainsi les performances d’une jointure. L’opération revient à réaliser un pré-shuffle suivi d’un sort par les clés de jointures avant le stockage. Le bucketing se fait au moment de sauvegarder les données avec la commande .bucketBy(???) en spécifiant le nombre de buckets. Cette commande implique un shuffling de données, certes, mais cela permet d’éviter d’autres shuffles plus importants par la suite. La clé est donc de bien connaître les données pour choisir proprement la colonne de bucketing et le nombre de buckets le plus approprié. Enfin Jacek nous montre en image comment Spark, en s’appuyant sur la data locality, est alors capable de supprimer toute une tâche d’échange de données :
Présentation de Jacek Laskowsky au Spark+AI Summit Europe 2018
Passe sur le bucketing du livre de Jacek Laskowsky
Using Spark ML on Spark Errors – What Do the Clusters Tell Us? – Holden Karau
Holden Karau, Developer Advocate chez Google nous a proposé un talk sur la correction des erreurs Spark avec une expérience simple et un peu folle : et si nous construisions des bots pour corriger nos erreurs Spark ? Pour sensibiliser l’audience à cette problématique, elle débute en décrivant le travail acharné que fournissent quelques grands contributeurs, que ce soit sur les Mailing List, Slack, Stackoverflow ou autres. Puis elle sonde le public pour savoir qui est déjà tombé sur quelques erreurs classiques. “Répondre aux questions d’inconnus sur internet” n’est pas une fin en soi. Il doit être possible de tirer de l’intelligence de toutes les réponses existantes depuis l’existence de Spark. On se lance donc dans un exercice de text processing classique au bout duquel on arrive à segmenter les posts en différents clusters. Les maigres résultats nous ramènent à nouveau sur l’importance des humains dans l’animation de la communauté. Plutôt qu’un focus technique, cette présentation était un tour d’horizon intéressant sur l’importance de la communauté Apache Spark, les différents outils qu’elle utilise et les moyens d’y prendre part.
Présentation de Holden Karau au Spark+AI Summit Europe 2018
Conclusion
Databricks croit dans l’importance d’effacer la frontière entre Data Science et Data Engineering, et dans ce cadre, propose ses solutions telles que MLflow, Delta et Hydrogene.
Nous avons apprécié cette conférence même s’il nous a manqué quelques choses : quid de la mise en prod de ML. Il n’y a pas eu beaucoup de détails techniques dans les présentations sur ce point.
On attend la prochaine version avec des REX sur l’utilisation de MLflow en entreprise.