Une étincelle au chtijug

Et c’est reparti pour un tour, cette fois-ci sur du Big Data, je crois …

J’avais entendu parler de Spark dans l’interview de Sam Bessalah chez les castcodeurs, et Duy Hai Doan est venu préciser les idées.

Et Duy Hai a été sympa pour rendre les slides disponibles sur le web

Ainsi que sa présentation pour Spark avec Cassandra

En nous expliquant d’abord que Spark est bien plus concis que Hadoop (en partie parce qu’en Scala), et bien plus rapide (parce que stockant ses données en mémoire, plutôt que sur disque, comme Hadoop). En bonus, Spark traite les données en graphe (d’ailleurs, de façon amusante, Blueprints n’est pas listée dans les API de graphe Big Data), en SQL, ou via des flux.

Cool, non ?
Petit détour par les RDD, qui reprennent, conceptuellement, ce que toute personne ayant implémenté un processeur de requête comprendra : il n’interprète les requêtes qu’au dernier moment. Par exemple, un filter suivi par un groupBy ne sera évalué que si, à la fin, l’utilisateur du RDD tente de récupérer, d’une façon ou d’une autre, les données sur son poste. D’une façon intéressante, certaines opérations vont redistribuer les données sur le réseau (typiquement, un groupBy) à cause de notions compliquées de « hashcode » de données. D’ailleurs, curieusement, on ne distingue pas les opérateurs impliquant un brassage (groupBy) des autres, ni d’ailleurs des actions démarrant le processus. Et personnellement, je trouve ça moche pour une raison bien simple : le développeur peut (et va) écrire du code inefficace, simplement parce qu’il ne saura pas comment distinguer le code efficace du code inefficace.
On passe ensuite aux API.

Spark supporte le SQL, le streaming, et le mapping d’objets. Pas mal … Sauf bien sûr qu’il y a toujours ces histoires de redistributions de données temporaires, que je vois come le vrai défaut de Spark. Je m’explique …

Comme les opérations brassant les données peuvent les envoyer n’importe où, si on en écrit « par accident », on risque de passer d’un code très rapide (parce qu’en mémoire) par un code très lent (parce que sur le réseau). Et Spark ne fournit aucun moyen de distinguer les deux, malheureusement.

Et ça empire si on utilise Cassandra comme couche de stockage, à cause de la nature multi-datacenter de l’outil, qui va certes permettre de survivre à des accidents nucléaires, au prix de coûts de transferts de données.

Pour troller, Spark, c’est bien, pour faire du SQL distribué.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s