Ce n’est pas ‘Mobile Spark’, mais c’est proche

(dolphfyn/Shutterstock)

Le 1er avril 2015, Reynold Xin, membre d’Apache Spark PMC, a écrit un blog passionnant détaillant les plans de livraison d’une version mobile de Spark. C’était une blague, bien sûr : Spark était un morceau de code lourd conçu pour les systèmes distribués (bien que le le journal Wall Street apparemment mordu). Mais avec le lancement de Spark Connect cette semaine, la vision mobile de Spark mobile est en fait de retour, mais avec une tournure intéressante.

Les applications de données ont échappé au centre de données, et maintenant Spark est sur le point de faire de même avec Spark Connect, selon Xin, co-fondateur et architecte en chef de Databriks, qui organise son premier sommet Data + AI en personne en trois ans. semaine à San Francisco.

“Spark est souvent associé à de gros calculs, à de grands clusters, à des milliers de machines, à de grandes applications”, a déclaré Xin lors de son discours d’ouverture au Moscone Center le 28 juin. “Mais la réalité est que les applications de données ne vivent plus seulement dans des centres de données . Ils peuvent être partout.

Les applications de données peuvent être trouvées dans des environnements interactifs, comme les ordinateurs portables et les IDE, a déclaré Xin. “Ils peuvent se produire dans les applications Web”, a-t-il déclaré. “Ils peuvent se produire dans des appareils de pointe”, tels que Raspberry Pis et même votre iPhone.

Alors que Spark est devenu un calculateur de nombres omniprésent sur des clusters massifs avec des milliers de nœuds, il reste pour la plupart coupé de la révolution des applications de données qui se produit à la périphérie. Pourquoi? Xin a expliqué que c’était le résultat du maquillage de Spark.

Reynold Xin est le principal contributeur au projet Apache Spark et l’architecte en chef de Databriks

“Vous zoomez, vous réalisez que Spark a un pilote monolithique”, a déclaré Xin. Ce pilote monolithique exécute non seulement le code de l’application, mais également le code Spark. La combinaison du code d’application des clients avec les composants Spark, tels que les optimiseurs et le moteur d’exécution, rend difficile l’exécution de Spark sur des appareils plus petits. Les racines Java de Spark et son énorme appétit pour la mémoire dans la JVM jouent également un rôle.

Mais il existe des solutions de contournement potentielles. Pourquoi ne pas simplement conserver Spark sur le serveur et les données du serveur sur le client via SQL ? Cela pourrait fonctionner, a déclaré Xin, mais quelque chose serait perdu dans la traduction. “SQL ne capture pas réellement toute l’expressivité de Spark”, a-t-il déclaré. “C’est juste un sous-ensemble beaucoup plus limité.”

Une autre voie possible pourrait être de se superposer à des produits tels que les ordinateurs portables Jupyter, qui sont livrés avec des environnements d’exécution mobiles qui se connectent à des clusters backend. Mais le potentiel de conflits de code JVM est tout simplement trop grand.

“Vous rencontrez toute une série de problèmes opérationnels multi-locataires”, a déclaré Xin. “Le problème fondamental ici est le manque d’isolement. Une application consomme trop de mémoire et ne se comporte pas.

La communauté Spark a navigué autour de ces problèmes épineux avec Spark Connect, un nouveau composant Spark qui permet aux applications exécutées n’importe où d’exploiter toute la puissance de Spark, a déclaré Xin.

Spark Connect a introduit une architecture découplée pour le développement de Spark, a déclaré Xin. Un composant central de Spark Connect est un protocole client-serveur qui est utilisé pour envoyer des plans de requête non résolus créés sur l’application de données s’exécutant sur un périphérique périphérique et Spark lui-même s’exécutant sur le serveur, qui sert les données. Le protocole, basé sur gRPC et Apache Arrow, peut fonctionner avec n’importe quel langage pris en charge par Spark.

Lorsque le serveur exécutant Spark reçoit le plan de requête non résolu, il l’exécute à l’aide du pipeline d’exécution d’optimisation de requête standard, puis renvoie les résultats à l’application de données, a déclaré Xin.

Cela fonctionne de la même manière que les chaînes SQL sont envoyées via les protocoles JDBC ou ODBC, a déclaré Xin, mais avec une distinction importante. “Il y a bien plus qu’un simple envoi de SQL, car vous disposez de toute la puissance de l’API dataframe dans Spark”, a-t-il déclaré.

«Ainsi, avec ce protocole et avec des clients légers… vous pouvez désormais intégrer Spark dans tous ces appareils, y compris ceux dont la puissance de calcul est très limitée», a poursuivi Xin. “De tels appareils peuvent en fait piloter et orchestrer tous les programmes et décharger l’exécution lourde sur le cloud à l’arrière.”

Cette architecture atténue de nombreux problèmes de fonctionnement et de mémoire qui surviendraient si l’on essayait d’exécuter l’environnement Spark complet sur un pilote mobile, a déclaré Xin. Étant donné que Spark est contenu dans son propre client, il réduit la probabilité qu’il ait un impact sur d’autres applications. Cela simplifie également le débogage et les mises à niveau, a-t-il déclaré.

“Spark Connect… dans mon esprit est le changement le plus important apporté au projet depuis le début du projet”, a déclaré Xin.

Et ce n’est pas une blague.

Articles connexes:

Databriks remporte les prix ACM SIGMOD pour Spark et Photon

Databriks ouvre son Delta Lakehouse au sommet Data + AI

Apache Spark est génial, mais ce n’est pas parfait