Le SparkAISummit, une rencontre dont le succès se confirme par les chiffres :
3 jours
2300 ‘visiteurs’ [dév, data scientists, architectes, gourous], des salles pleines,
plus de 60 nationalités réunies !
Des keynotes avec des invités stars :
- Les concepteurs de l’IA qui a battu Starcraft (équipe de DeepMind @Google),
- Katie Bouman : la scientifique qui a mis au jour la première image d’un trou noir.
Des entreprises à la pointe des problématiques Data, qui dépassent de loin ce que le commun des entreprises peut croiser : le CERN (rien de moins que 10Po en plus par mois… après filtrage), Facebook, Zalando… qui partagent leurs meilleures pratiques dans l’utilisation de Apache Spark. Attention, tout le monde ne croise pas de tels monstres de données !
Mais pourquoi le succès de Spark ne se dément pas ?
Parce qu’il est à la croisée des chemins de la Data Science & Data Ingénierie (et même plus que jamais avec les annonces de cette édition) :
La data science se développe, la valeur qui en est retirée est tangible, encore faut-il :
- Faciliter la vie des Data Scientists dans leurs cycles de vie des algorithmes et la manipulation des données. [Koalas, ML Flow].
- Développer les points de convergence avec les data ingénieurs qui structurent et optimisent les traitements de captation et préparation des données. [ML Flow, Delta Lake].
On-premise, Cloud:
- En s’exprimant dans les deux environnements, il permet de se reposer sur une technologie commune. Alors que les entreprises ont souvent un pied de chaque côté, et que la stratégie définitive n’est pas encore arrêtée, autant reposer sur une technologie ubiquitaire.
- Par ailleurs, il est présent dans tous les fournisseurs de clouds (Google, Azure, AWS, OVH…), ce qui en fait un dénominateur technologique très valable (surtout pour des stratégies multi cloud).
Hadoop (Yarn), Standalone, Mesos… dont l’adoption est confidentielle parce que supplantée par les promesses de : Kubernetes
- Spark peut s’exécuter dans différents réceptacles, ou socles d’exécution. Qui peut véritablement dire qui gagnera la bataille ? cette polyvalence est là encore un atout en attendant de voir les vainqueurs se détacher.
Polyglotte : Python, Scala, Java, R, et d’une certaine manière SQL.
Chaque entreprise (par ses compétences historiques), chaque équipe (plutôt Data Science, plutôt Data Ingénierie), chaque projet ( Machine Learning, Streaming, Data Warehousing, ETL) trouve le cadre de développement qui lui convient avec l’outillage qui permet de l’étendre.
Un écosystème qui se renforce avec des annonces majeures :
Koalas : développer en python selon la philosophie Panda de manipulation des dataframes en profitant de la puissance et scalabilité de Spark.
https://github.com/databricks/koalas
Cette création acte et prolonge le succès de Python comme langage de développement de projets Spark.
L’avantage très significatif est de réduire la barrière d’entrée du développement Spark pour les Data Scientists: ils n’ont pas besoin d’entrer dans les fonctions arcanes du code spark (au moins jusqu’à un niveau de tuning élevé).
Le code a plus de chances d’être spontanément performant, et par conséquent requiert moins de reprise par une équipe de data ingénieurs.
voici un exemple qui associe Koala avec l’algorithme de prédiction de séries temporelles Prophet (de Facebook), mais également Delta Lake et MLFlow :
https://databricks-prod-cloudfront.cloud.databricks.com/public/4027ec902e239c93eaaa8714f173bcfc/8266758089056472/3786652143501164/5693546805547978/latest.html
Le travail est en cours, à l’heure où nous écrivons l’API est en version 0.20 et progresse à un rythme très soutenu. Notre conseil : à adopter dès que stabilisé !
ML Flow :
Nous avons précédemment évoqué la nécessité d’industrialiser les travaux de Data Science. il faut répondre à de nombreux points de souffrance :
- Mesurer la qualité des modèles déployés,
- Tracer l’historique des versions de modèle.
- Logger les métriques pour prendre les décisions, auditer les activités.
Voici quelques slides qui posent les constats récurrents des projets Data Science, et les réponses apportées par ML Flow :
La Société Générale a fait une présentation instructive de leur utilisation de MLFlow pour organiser les contributions de leurs équipes de Data Science partout dans le monde : https://databricks.com/session_eu19/machine-learning-at-scale-with-mlflow-and-apache-spark
Nos travaux actuels sur MLFlow nous font apprécier les gains retirés d’une telle industrialisation, nous y reviendrons prochainement sur ce blog :
Instrumenter sa mesure des performances :
au delà de l’interface web des historiques d’exécution, des initiatives du CERN et de Linkedin facilitent l’optimisation de grands patrimoines Spark :
sparkMeasures : https://github.com/LucaCanali/sparkMeasure , utilisé au CERN.
Les principes d’utilisation sont :
- shell ou notebook,
- un mode ‘flight record’ qui n’implique pas de changement de code, (pour le trouble shooting ou pour les chaînes de CI/CD)
- des appels invoqués depuis le code Scala, Python, Java
La mise en oeuvre est réduite à un léger enrichissement du code, qui permet de restituer des rapports.
Les bénéfices principaux sont la collecte de toutes les métriques (IO, garbage collection, shuffle…) et une facilité à identifier les goulets d’étranglement.
Doctor Elephant (LinkedIn) : permet de mesurer la performance de Spark et de processus Hadoop: https://github.com/linkedin/dr-elephant
Delta Lake:
Pour solutionner un grand nombre de problèmes rencontrés dans la constitution et la maintenance d’un Data lake :
- Incohérence des écritures,
- Pas de schéma, (et cohabitation de versions de données incompatibles)
- Réconciliation difficile des approches batch et streaming.
Delta Lake est en mode beta, mais avance à marche forcée.
Les APIS Scala/Java sont servies en premier, mais la v0.4.0 va remettre python en bonne position.
Le maître mot est la fiabilité et la performance.
Certaines limites ont été partagées néanmoins : Attention à ne pas considérer cette offre comme une base de données … les update peuvent entraîner des merge difficilement maîtrisés.
Quand facebook parle d’optimisations :
… une session trop ultime ! l’assistance s’est rapidement clairsemée. Tout le monde n’a pas besoin de modifier dynamiquement le plan d’exécution des requêtes.
Data Science :
Présence et keynote du créateur de SciKit Learn :
Cela a été l’occasion d’un tour d’horizon des principaux défis rencontrés dans un projet de Data Science :
Performances et bonnes pratiques
Ceci a été notre fil conducteur durant ces deux jours, parce qu’il est bon d’avoir une explication ‘du terrain’ pour conforter ses propres analyses, et y voir clair dans les multiples combinaisons possibles de paramétrage d’un job Spark:
L’allocation dynamique de ressource (aussi élégante soit-elle) ne peut être intéressante que dans certains cas précis de topologie de clusters Spark et de partage de ressources.
ceci vous demandera de bien comprendre et maîtriser les paramètres de shuffle.
On découvre ou redécouvre les domaines d’applications de tuning telles que spark.speculation, à manipuler avec précautions parce qu’il se pourrait qu’il relance plusieurs fois les tâches les plus lentes, aboutissant au résultat exactement opposé à celui recherché (un raccourcissement des temps de calcul).
Quelques chiffres au travers des retours d’expérience : 17Tb à écrire dans S3, délégués à 1000 (!) noeuds :
Petite réflexion : les APIs de spark sont de haut niveau. mais les subtilités (optimisation d’infrastructure mobilisée, temps d’exécution) requièrent de maitriser : distribution, JVM, IO, CPU, Mémoire, Réseau.
Partitioning :
on y retrouve les bonnes pratiques de Datawarehousing en vigueur sur les architectures relationnelles historiques : nombre de colonnes limité, cardinalité des colonnes modéré, sans quoi les calculs et le stockage vont en souffrir !
la recherche de performances, un processus itératif :
Notre petit regret personnel ? ne pas avoir pu assister aux sessions présentant les tentatives (parce que très récentes) d’utilisation de GPUs pour accélérer les traitements Spark.
Heureusement, les sessions vidéos des conférences ont été mises en lignes : https://databricks.com/sparkaisummit/europe/schedule
