Streaming de données : Databricks supervise la réfection du moteur Spark

Spark Connect : un découplage nécessaire

« Pour beaucoup de gens, Spark est synonyme de grosses capacités de calcul, de clusters contenant des milliers de machines pour servir des applications à large échelle », déclare Reynold Xin, cofondateur et chief architect chez Databricks. « Or les applications ne vivent plus seulement dans les data centers, mais dans de multiples environnements ».

« Pour beaucoup de gens, Spark est synonyme de grosses capacités de calcul, de clusters contenant des milliers de machines pour servir des applications à large échelle ».

En ce sens, lors de la conférence Data+AI Summit, l’éditeur a d’abord présenté Spark Connect. Ce projet en développement s’appuie sur une API afin d’exécuter des traitements sur une instance Spark depuis des applications, des IDEs, des notebooks ou des SDKs liés au langage de programmation Go, R et Python. En clair, il serait possible de lancer des traitements Spark à distance depuis des appareils mobiles ou des objets connectés.

Ici, Databricks et la communauté tentent de résoudre un problème connu de longue date. « Si vous regardez de plus près, Spark s’appuie sur un driver monolithique. Ce driver exécute les applications des utilisateurs et le code Spark. Cela inclut l’analyseur, l’optimiseur et le moteur d’exécution full flash », explique Reynold Xin. « Ce couplage rend difficile l’exécution de Spark dans des environnements distants. En fait, c’est même le contraire qui se produit : vous devez embarquer l’application sur le cluster Spark ».

L’architecte en chef évoque plusieurs tentatives infructueuses pour tenter de régler ce problème. Certains ingénieurs ont essayé d’envoyer des requêtes SQL vers une passerelle embarquée dans le moteur, mais cela limite l’utilité de Spark, habituellement taillé pour traiter des charges de travail de machine learning.

« D’autres projets ont apporté un protocole maison pour envoyer du code via des notebooks Jupyter, par exemple », relate le Chief Architect. « Or, cela s’avère très difficile à débugger et pour les langages de programmation qui n’ont pas de méthode d’interrupts pour la JVM, vous pouvez à peine le faire fonctionner ».

Et si un protocole de ce type peut fonctionner, il provoquerait un ensemble de problèmes dus aux manques d’isolation entre les jobs concurrents. Un projet incubé comme Apache Livy, créé par Microsoft et Cloudera, devait répondre aux mêmes enjeux, mais il semble à l’abandon depuis 2020.

De son côté, Spark Connect s’appuiera sur une API Dataframe. Cette API permet d’envoyer des Dataframes, à savoir des collections de données organisées en colonnes, enrichies pour Spark. Cette interface peut être habituellement écrite dans les langages de programmation Scala, Java, Python, R.

Pour l’instant, le prototype de Spark Connect prend en charge Python. Spark Connect utilise des points de terminaisons gRPC et le protocole de sérialisation Protobuf pour faire la liaison entre le client et le serveur. « L’API est agnostique des langages de programmation. Une fois appelée, elle génère des plans de requêtes logiques non résolus en s’appuyant sur protobuf et envoie ce code via gRPC au serveur », explique Reynold Xin. « Le serveur peut exécuter ces plans de requêtes en utilisant le pipeline d’exécution standard d’optimisation de requête et il renvoie un résultat ». Les résultats envoyés par le service gRPC coté serveur arrivent sous forme de batch Arrow au client.

« L’idée, c’est de pouvoir appeler Spark à la demande depuis des applications distantes, qui ne résident pas sur le même cluster ».

« L’idée, c’est de pouvoir appeler Spark à la demande depuis des applications distantes, qui ne résident pas sur le même cluster », résume Matei Zaharia, cofondateur et CTO de Databricks, auprès du MagIT. « L’autre avantage subtil, c’est de permettre de séparer la mise à jour de l’API de celle du serveur Spark ».

Il reste maintenant à mettre en pratique cette fonctionnalité. Elle a été présentée à la communauté le 25 mai dernier et proposée officiellement le 3 juin 2022.

Projet Lightspeed : un turbo pour Spark Structured Streaming

En ce qui concerne le streaming de données, Databricks mise sur le projet Lightspeed.

Le projet Lightspeed consiste en une évolution de Spark Structured Streaming. Ce moteur de traitement en streaming est bâti sur Spark SQL. Introduit à partir de la version de Spark 2.0, il permet d’exprimer la logique de traitement via SQL ou l’API DataFrame. « Structured Streaming se charge d’exécuter le pipeline de manière incrémentielle ou en continu tout en mettant à jour les résultats au fur et à mesure de l’arrivée des données », renseignent les ingénieurs de Databricks.

Tolérant aux pannes, flexible, capable de gérer les données arrivées en retard, Structured Streaming présente de sérieux avantages pour la gestion des flux de données en quasi-temps réel. Si bien que la technologie est désormais exploitée pour la maintenance proactive d’applications, le suivi d’état de microservices ou bien encore le maintien en condition opérationnelle d’équipements tels des ascenseurs.

Or, ces nouvelles applications exposent les limites de Structured Streaming, selon Karthik Ramasamy, responsable du streaming chez Databricks et fondateur de Streamlio, une startup rachetée par Splunk. Pour rappel, Streamlio était l’un des contributeurs principaux au projet Apache Pulsar. 

D’abord, la technologie repose sur un moteur de traitement en microbatch. Très populaire dans les systèmes de streaming, cette approche a pour désavantage de générer de la latence. Aujourd’hui, chaque microbatch est exécuté en séquence. Un offset (ou marqueur) est enregistré au début et à la fin du traitement vers un espace de stockage externe. Les offset sont liés aux sources de données et servent de point de restauration. Les ingénieurs de Databricks ont démontré que la gestion des offsets représentait 30 à 50 % du temps d’exécution d’un pipeline. En rendant ce mécanisme d’enregistrement d’offset asynchrone, les lancements des microbatchs peuvent se chevaucher. Résultat, cela permettrait de diviser par deux la latence. Lors des premiers tests, Karthil Ramasamy a observé que la latence d’un microbatch passait de 440 millisecondes à 120 millisecondes.

De même, le mécanisme de restauration sauvegarde les données de manière synchrone après le traitement d’un groupe d’enregistrements. Ce nouveau mécanisme asynchrone permettrait là encore de gagner en performance.

Dans la même veine, le support des opérations I/O asynchrones via une API, devrait faciliter les usages ETL de Structured Streaming. Pour surveiller les changements d’état des pipelines synchrones et asynchrones, les responsables de Databricks suggèrent d’ajouter une interface de programmation afin de superviser le tout depuis un outil de monitoring.

Outre des limites de performance, le moteur ne supporte l’exécution que d’un seul opérateur stateful par pipeline. D’autres technologies autorisent plusieurs agrégations chaînées de données temporelles ou encore des jointures d’intervalles. « Permettre l’utilisation de multiples opérateurs au sein d’un pipeline dans Structured Streaming ouvrira de nombreux cas d’usage supplémentaires et permettra d’être sur un pied d’égalité avec les autres moteurs de traitement de flux », peut-on lire dans la description jointe à la proposition SPIP (Spark Project Improvement Proposal).

Et si Spark Structured Streaming prend en charge les transformations sur des fenêtres de données, elles sont en réalité limitées. Une nouvelle API sera introduite pour définir des logiques de traitements avancées.

Aussi, Databricks veut faire en sorte que l’API PySpark dispose du même niveau support que celles dédiées à Scala et Java.

Enfin, l’éditeur étudie l’ajout de nouveaux connecteurs vers Google Pub/Sub et Amazon DynamoDB en sus des optimisations prévues pour ceux dédiés à Kafka et Amazon Kinesis.

Ces promesses d’optimisations sont prises au sérieux : rien qu’en juin 2022, Databricks a observé l’exécution de 4 millions de jobs de streaming depuis son data lake. Il faudra toutefois attendre que ces ajouts prennent corps. Toutes ces propositions ont été publiées il y a moins d’une semaine.