Spark Summit Europe : Les technos BigData d’aujourd’hui et de demain

 

spark summit

 

J’ai pu participer à cette première édition européenne du Spark Summit. Une excellente conférence, où l’on a pu rencontrer les « rock-stars » des technologies Big Data open-source (les créateurs de Spark, de Scala, de Tachyon, de Zeppelin… ainsi que de nombreux commiters), et croiser les aficionados de Spark, des nouvelles architectures, des nouvelles approches de l’analyse des données.

Voici ce que je retiens de cette conférence.

Spark : un projet qui bouge vite.

Croissance du nombre de contributeurs aux sources, meetups Spark partout dans le monde, l’adoption de Spark est générale dans le paysage Big Data. Spark a tué le bon vieux Map-Reduce par ses gains de performance et par la qualité de son API, et l’histoire n’est pas terminée. L’année 2015 aura été témoin d’une évolution majeure de Spark, avec les Dataframes de la v1.5 et le projet Tungsten, qui seront encore améliorés à la fin de l’année avec l’API Dataset (dataframes typés). Spark avance à un rythme effréné, tout en gardant une grande cohérence de roadmap (cf la présentation de Reynold Xin) ce qui est assez impressionnant, il faut le souligner.

 

Spark : aujourd’hui incontournable et polyvalent

Spark est capable de traiter des données en provenance de tous types de sources (hdfs, cassandra, s3, sql, kafka…), il peut fonctionner sur plusieurs technologies de clusters (mesos, hadoop-yarn, ou en standalone), est utilisable pour différentes typologies de traitements (SQL/datawarehouse, machine-learning, graph-processing, streaming), et enfin est multi-langage (scala, python, R, avec des performances équivalentes depuis la v1.5).

Cette polyvalence est clairement un atout majeur de Spark. Il suffit de voir la démo d’un use-case relativement sophistiqué mêlant ces différentes fonctionnalités construit simplement. Cela se reflète dans l’usage qui est fait de Spark dans le marché selon Cloudera.

Cela fait plusieurs années que bien des acteurs de la sphère big-data se sont attaqués au sujet du requêtage SQL, avec des résultats parfois bons (Cloudera Impala, Presto) et parfois moins (Hive, Stinger… ). Avec les Dataframes, Catalyst (optimiseur de plan d’exécution), Tungsten (contournement de la JVM pour certaines opérations clé) Spark a réussi là où les autres ont échoué. SQL est maintenant au coeur même de Spark, et c’est bientôt multi-modal : les requêtes SQL en streaming (c’est-à-dire comme avec un CEP genre Esper), ou sur du graphe, sont à venir prochainement.

Il paraît que le support des Dataframes (= le mécanisme interne de traitement SQL) pour le langage Python a été ajouté en un week-end. C’est dire la qualité de l’API qui a été contruite. Si l’ajout de langages utilisateurs de l’API Dataframe est aussi simple, d’autres langages ne tarderont pas à faire leur apparition, renforçant ainsi l’ecosystème de Spark.

 

La puissance de la communauté et de l’open source

En parlant d’écosystème : l’effet joue à plein avec Spark. Le créateur de Scala, Martin Odersky himself, est monté sur scène expliquer pourquoi les RDD (Resilient Distributed Datasets, l’abstraction au cœur de Spark) fonctionnent aussi bien. C’est qu’ils reposent sur des bases théoriques solides, très proches des collections de Scala. A son tour, la roadmap de Scala va s’enrichir des bonnes idées de Spark (notamment : des collections lazy avec caching ; et également un équivalent des RDD key-value). C’est une nouvelle preuve, s’il en est, de la qualité du framework !

Martin Odersky a également annoncé des améliorations à venir de Scala, qui bénéficieront fortement à Spark :

  • L’utilisation des lambdas, des default-methods et des streams de java8
  • Un meilleur contrôle du périmètre des closures avec les « Spores »
  • Le compiler « dotty » amené à améliorer le bytecode produit, fusionner et optimiser les closures (ce que Spark fait à son niveau avec le pipeling dans les Dataframes).

 

Au-delà de Scala, ce Spark Summit a été l’occasion de voir la quantité de projets se rapportant de près ou de loin à Spark :

 

Les nouvelles architectures

De nouveaux paradigmes et architectures émergent autour de Spark, voici quelques idées notables.

Le « JIT datawarehouse » (just-in-time datawarehouse)

La formule est du CEO de Databricks, Ion Stoica. Les ETLs, plus personne n’en veut. Longs à développer, pénibles à maintenir, et c’est un paradigme d’architecture des années ’90. L’idée est d’importer les données directement depuis les systèmes opérationnels, et de profiter des fonctions de caching de Spark pour la performance. Si l’ETL n’est pas encore mort, le sens de l’histoire est bien à la disparition progressive de la frontière entre systèmes opérationnels et analytiques.

 

L’architecture SMACK

L’idée de construire des architectures analytiques capables de gérer aussi bien les données les plus récentes que toute la profondeur historique, fait son chemin. Il y a déjà plus de 3 ans, Nathan Marz proposait la lambda-architecture qui tentait de réconcilier les 2 facettes de l’analytique au prix d’une architecture élégante mais sophistiquée, reposant sur une duplication des traitements. Vu les performances et la polyvalence de Spark, et ses capacités en streaming, une alternative voit le jour.

L’architecture SMACK allie :

  • Les paradigmes « réactifs » de Scala et Akka
  • La mise en cluster à l’aide de Mesos
  • La scalabilité linéaire de Cassandra
  • Le streaming, avec Kafka pour gérer des scalables  avec capacité de reprise, et Spark traitement en continu.

Plusieurs acteurs se sont lancés dans ce type d’architecture, on a pu en voir un aperçu chez TupleJump, ou ING.

 

Les notebooks

L’utilisation de notebooks est omniprésente. Que ça soit pour le data-scientist lors de l’exploration des données, et l’évaluation des modèles, ou pour le data-engineer qui doit prototyper ses traitements et vérifier rapidement comment ils se comportent, le notebook est incontournable dans le paysage.

Beaucoup d’initiatives concurrentes existent déjà, il y aura sans doute une consolidation prochaine, qui renforcera les survivants. Mention spéciale pour le produit de Databricks (non open-source toutefois) qui tue toute la complexité « ops » de l’intégration avec un cluster, et permet le déploiement automatisé à la demande dans votre compte Amazon de clusters Spark de toute taille. Bien joué.

 

Le futur

Ces 8 dernières années ont vu l’essor d’Hadoop, dont la fonction essentielle est de paralléliser les I/O disque et réseau, et qui a rendu les architectures fortement parallélisées robustes, polyvalentes et financièrement abordables.

Spark a pris le contrepied de l’utilisation (trop) intensive des disques dans les architectures Hadoop/Map-Reduce, et a tout misé, avec raison, sur l’utilisation de la mémoire. Une partie importante de l’effort de R&D consiste en le déchargement du CPU des tâches I/O ou de sérialisation/déserialisation. Autrement dit, mieux utiliser la mémoire pour que le temps CPU soit utilisé pour du traitement et pas autre chose.

Aujourd’hui, n’importe quelle machine de développeur a 16 GB de RAM, Amazon est sur le point de lancer commercialement le modèle X1 avec 2TB de RAM, et Intel a dévoilé une révolution dans le paysage des barettes de RAM : la 3D-XPoint est une mémoire non-volatile ayant des performances proches de celles d’une RAM, pour une capacité qui pourrait être similaire à celle d’un SSD…

Dans ce contexte, les bases de données du futur seront intégralement en mémoire, les disques ne servant que de stockage froid de secours, comme ont pu l’être autrefois les bandes magnétiques.

Le nouveau « cool kid » de la côte Ouest à surveiller de près est le projet Tachyon. Lui aussi issu du AMPLab comme Spark, il a pour vocation de fournir un genre de « RAM-disk » distribué. C’est un stockage à plusieurs niveaux, à l’instar des baies de disques SSD+HDD d’aujourd’hui, mais ayant la performance de la RAM. Il fournit au système utilisateur une abstraction unifiée au-dessus de données fichier (S3, HDFS, Swift, Ceph, NFS…). Tachyon est un projet en plein essor, la communauté explose, et ils viennent de lever 2.5M$…

Nous allons beaucoup entendre parler du couple Tachyon + Spark. Ils sont d’ailleurs au cœur de la bien nommée BDAS (Berkeley Data Analytics Stack) du AMPlab.