Annonce de la disponibilité générale du mode temps réel pour les pipelines déclaratifs Spark sur Databricks

Nous avons lancé le Real-Time Mode (RTM) l'année dernière pour permettre aux clients de créer des cas d'usage opérationnels à faible latence. Cela a tout changé, car cela permet aux clients de traiter des données de streaming en millisecondes, soit jusqu'à 100 fois plus vite que l'architecture micro-batch traditionnelle. De plus, ils n'ont plus besoin de maintenir des moteurs spécialisés séparés comme Flink en plus d'Apache Spark, ce qui élimine les bases de code en double, les modèles de gouvernance fragmentés et la charge opérationnelle.

Aujourd'hui, nous annonçons que le RTM dans Spark Declarative Pipelines (SDP) est désormais généralement disponible. SDP est devenu la norme pour créer des pipelines de streaming et ETL sur Databricks, en gérant automatiquement la résolution des dépendances, le traitement incrémentiel, l'orchestration, la récupération après panne et le contrôle de la qualité des données. Avec le RTM, les clients peuvent créer des pipelines opérationnels à faible latence tout en conservant tous ces avantages de SDP. Que ce soit pour la notation des fraudes, les alertes en temps réel ou l'envoi de nouvelles features vers des magasins opérationnels, vous pouvez désormais utiliser SDP pour tous ces cas d'usage.

Qu'est-ce que le Real-Time Mode (RTM) ?

Le RTM est une évolution du moteur Apache Spark Structured Streaming qui atteint des latences de bout en bout de l'ordre de la milliseconde. Pour ce faire, il diffuse les données en continu, exécute toutes les étapes de requête simultanément et transmet les données entre les étapes dès qu'elles sont produites. Pour une analyse approfondie de l'architecture, lisez l'article de blog : « Briser la barrière des micro-batchs : l'architecture du Real-Time Mode d'Apache Spark ».

Le RTM peut prendre en charge toute charge de travail qui bénéficie de la transformation de données en décisions en quelques millisecondes. Parmi les exemples de cas d'usage, citons la détection des fraudes, la personnalisation en direct, les systèmes de recommandation en temps réel et le calcul de features en temps réel. Nous avons comparé le RTM à Apache Flink sur des charges de travail clients réelles effectuant des calculs de features, et le RTM est jusqu'à 92 % plus rapide que les moteurs spécialisés comme Flink. Vous trouverez les benchmarks ci-dessous. Pour plus d'informations sur les jeux de données et les requêtes mentionnés, consultez ce répertoire GitHub.

Pourquoi choisir le RTM sur Spark Declarative Pipelines

Les clients privilégient de plus en plus SDP pour leurs charges de travail ETL. Avec le RTM, SDP prend désormais en charge toutes les charges de travail de streaming, y compris le streaming opérationnel à faible latence, permettant aux clients d'utiliser un seul framework pour tous les pipelines. Un seul framework signifie une seule pile d'observabilité, un seul modèle de facturation et aucune fragmentation entre les différentes API.

SDP serverless va encore plus loin. Il n'y a pas de calcul à choisir ni de cluster à dimensionner. Vous obtenez une latence inférieure à la seconde, sans réglage d'infrastructure complexe, tout en payant uniquement pour les cœurs utilisés par votre requête. Les flux RTM bénéficient également des fonctionnalités SDP telles que les mises à niveau sans version et la maintenance avec un minimum d'interruptions, ce qui réduit à la fois le travail opérationnel et les perturbations liées aux mises à niveau.

L'un des cas d'usage où le RTM sur SDP a un impact immédiat est le calcul de features en temps réel. Les modèles de machine learning pour la détection des fraudes ou la personnalisation dépendent de signaux récents, tels que le montant total des transactions d'un utilisateur au cours des 10 dernières minutes, pour faire des prédictions précises. Calculer ces agrégations sur fenêtres glissantes et les stocker dans un magasin en ligne en quelques millisecondes est le domaine où le RTM sur SDP fait toute la différence. Databricks Feature Store utilise exactement cette architecture pour offrir une latence p99 de bout en bout de 200 ms de Kafka au magasin de features en ligne.

Premiers pas avec le RTM sur SDP

Étape 1 : Configurer le pipeline

Le Real-Time Mode nécessite que le mode de pipeline soit défini sur continuous et que spark.databricks.streaming.realTimeMode.enabled soit défini sur true pour prendre le relais.

Étape 2 : Définir un flux de mise à jour en temps réel

Le mode temps réel nécessite un flux de mise à jour. Utilisez dp.create_sink() pour définir la cible de sortie, puis utilisez le décorateur @dp.update_flow avec pipelines.trigger défini sur "RealTime" et target pointant vers le récepteur (sink).

Pour connaître les sources et les récepteurs pris en charge, consultez la documentation.

Écriture de features vers n'importe quel récepteur personnalisé

Des cas d'usage tels que la détection des fraudes ou la personnalisation en temps réel exigent non seulement que les features soient calculées en temps réel, mais aussi qu'elles soient enregistrées dans un magasin interrogeable à faible latence. Un modèle de fraude a besoin de la dernière transaction d'un client avant qu'elle ne soit validée, et un moteur de personnalisation doit lire ce qu'un utilisateur vient de consulter.

Aujourd'hui, vous pouvez écrire vers n'importe quel récepteur personnalisé tel que Lakebase, Redis ou tout autre magasin OLTP à partir de SDP en utilisant un récepteur ForEach. Définissez l'écrivain, enregistrez-le en tant que foreach_sink et connectez-le à un update_flow.

Les features arrivent dans votre magasin opérationnel en quelques millisecondes après leur production, sans synchronisation intermédiaire entre le mode hors ligne et le mode en ligne. Les applications et les modèles peuvent les interroger avec une latence ultra-faible. 
Quelle est la prochaine étape pour le RTM sur serverless ?

• Exécuter des pipelines RTM à moindre coût : Regroupez plusieurs flux RTM dans un seul pipeline au lieu que chaque requête déploie ses propres ressources. Le système ajuste également automatiquement les partitions source et shuffle en fonction de la charge de travail, ce qui évite aux utilisateurs un dimensionnement manuel.
• Support étendu des récepteurs : Récepteur Lakebase natif pour SDP, avec regroupement par lots intégré, nouvelles tentatives automatiques et authentification gérée par Unity Catalog.

Conclusion

Le RTM étend Spark Declarative Pipelines à une nouvelle classe de charges de travail : des applications opérationnelles sensibles à la latence qui exigent une réponse immédiate aux données en streaming. En apportant une latence inférieure à la seconde aux API SDP que votre équipe utilise déjà, il élimine le besoin d'exploiter un framework ou un moteur séparé pour vos pipelines les plus critiques. Que vous construisiez des pipelines de détection des fraudes, des moteurs de personnalisation ou des systèmes de calcul de features pour le machine learning, le Real-Time Mode vous offre la latence exigée par votre application avec la simplicité de SDP.

Le Real-Time Mode sur Spark Declarative Pipelines est désormais généralement disponible.

Ressources techniques

Consultez les ressources suivantes pour bien démarrer avec le RTM sur SDP :

• Documentation : Utiliser le Real-Time Mode sur les pipelines Lakeflow
• Documentation : Se connecter au récepteur de streaming Lakebase
• Documentation : Utiliser un récepteur ForEach pour écrire chaque ligne dans les pipelines
• Exemples de code : Exemples de Real-Time Mode sur SDP

FAQ

Qu'est-ce que le Real-Time Mode (RTM) dans Spark Declarative Pipelines ?

Le Real-Time Mode (RTM) permet à Spark Declarative Pipelines (SDP) de traiter des données en streaming avec une latence de bout en bout de l'ordre de la milliseconde. Il diffuse les données en continu, exécute toutes les étapes de requête en même temps et transmet les données entre les étapes dès qu'elles sont produites. Les pipelines en temps réel bénéficient de l'orchestration et de la récupération automatique après panne de SDP.

Le Real-Time Mode est-il disponible dans Spark Declarative Pipelines ?

Oui. Le mode temps réel sur Spark Declarative Pipelines est maintenant généralement disponible. Il apporte le mode temps réel déjà disponible dans Spark Structured Streaming aux pipelines SDP.

Comment activer le mode temps réel dans un pipeline ?

Configurez le pipeline sur le mode continuous et définissez spark.databricks.streaming.realTimeMode.enabled sur true. Définissez ensuite un flux de mise à jour avec pipelines.trigger réglé sur "RealTime" et une cible qui pointe vers un récepteur.

Un pipeline en temps réel peut-il écrire dans Lakebase ou un autre magasin OLTP ?

Oui. Définissez un récepteur ForEach avec un rédacteur qui implémente open, process et close, puis pointez un flux en temps réel vers celui-ci. Cela fonctionne pour Lakebase, Redis ou tout autre magasin OLTP.

Pour quels cas d'usage le mode temps réel dans Spark Declarative Pipelines est-il conçu ?

Le mode temps réel est conçu pour les charges de travail opérationnelles qui transforment des données en continu en décisions en quelques millisecondes. Les exemples incluent la détection des fraudes, la personnalisation en direct, les recommandations en temps réel et le calcul de caractéristiques en temps réel. Le catalogue de caractéristiques Databricks utilise cette architecture pour atteindre une latence p99 de 200 ms d'Apache Kafka vers le magasin de caractéristiques en ligne.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original