Diffusion en continu sur une informatique sans serveur

Cette page explique comment choisir la configuration appropriée pour les charges de travail de diffusion en continu serverless sur Azure Databricks, notamment les pipelines continus, l’ingestion incrémentielle et les connecteurs managés. Le choix de la configuration appropriée dépend des besoins en matière de source, de forme et de latence du flux.

Ce qui compte en tant que charge de travail de diffusion en continu

Une charge de travail de streaming lit des données non bornées à partir d’une source (comme le stockage d’objets dans le cloud, un bus de messages ou un flux de modifications) et les écrit progressivement dans une destination. Azure Databricks prend en charge deux modèles de charges de travail de streaming :

  • Continu : Un pipeline qui s’exécute sans interruption et traite les nouvelles données à mesure qu’elles arrivent. La latence est mesurée en secondes.
  • Incrémentiel (également appelé déclenché) : pipeline qui s’exécute de façon planifiée ou sur déclenchement, traite toutes les données arrivées depuis la dernière exécution et s’arrête. La latence est mesurée en minutes.

Certaines charges de travail semblent être des pipelines de diffusion en continu, mais ne sont pas techniquement des pipelines. Par exemple, un service qui contient un websocket ouvert pour écouter des événements, une application de conversation qui gère une connexion persistante par utilisateur ou un récepteur webhook qui gère les requêtes HTTP entrantes. Il s’agit d’applications, et non de pipelines de diffusion en continu. Pour obtenir l’option serverless appropriée pour ces charges de travail, consultez Charges de travail qui ne sont pas des pipelines de diffusion en continu.

Choisir la configuration de diffusion en continu appropriée

Ce tableau met en correspondance les cas d’usage avec les configurations serverless qui leur conviennent le mieux. Les sections qui suivent sur cette page fournissent plus de détails sur ces recommandations.

Cas d’utilisation Configuration recommandée Pourquoi
ETL ou transformations en streaming continu à faible latence Lakeflow Spark Declarative Pipelines en mode continu Le mode continu est conçu pour les flux actifs en permanence. Le pipeline de flux exécute des microbatches simultanément, ce qui améliore le débit et la latence. L’état managé conserve la récupération automatique.
Ingestion incrémentielle depuis le stockage cloud Utilisez Auto Loader dans les pipelines déclaratifs Lakeflow Spark (pour une faible latence) ou dans un job serverless avec Trigger.AvailableNow() (si une latence plus élevée est acceptable). Le chargeur automatique effectue le suivi efficace des nouveaux fichiers. Trigger.AvailableNow() traite le backlog, puis quitte, ce qui correspond à une cadence planifiée ou à la demande.
Ingestion gérée depuis des sources SaaS ou la CDC de bases de données Connecteurs standard dans Lakeflow Connect Connecteurs entièrement gérés avec des pipelines d’ingestion sans serveur. Aucun code n’est requis pour les sources prises en charge.
Diffusion en continu de SQL sur des tables Delta Tables de streaming Traitement incrémentiel natif SQL pour les sources de type append, avec des pipelines gérés et actualisation.
Traitement par micro-lots périodique dans un bloc-notes ou un travail Tâche serverless avec Trigger.AvailableNow() Rentable lorsqu’une actualisation à la minute suffit. Le calcul sans serveur démarre rapidement et s’arrête lorsque le traitement par lots est terminé.

Diffusion en continu

Pour le streaming continu avec le calcul serverless, utilisez Lakeflow Spark Declarative Pipelines en mode continu. Le pipeline reste actif, traite les enregistrements à mesure qu’ils arrivent et se rétablit automatiquement après des défaillances.

Pour configurer un flux continu :

Tip

Le traitement en pipeline des flux est activé par défaut dans Lakeflow Declarative Pipelines sans serveur pour Spark. Les microbatches s’exécutent simultanément plutôt que séquentiellement, ce qui améliore le débit pour les flux lourds d’ingestion.

Les déclencheurs Structured Streaming basés sur le temps, tels que Trigger.ProcessingTime(interval) et Trigger.Continuous(interval), ne sont pas disponibles dans les notebooks ou travaux serverless. Utilisez les pipelines déclaratifs Lakeflow Spark en mode continu pour le modèle toujours actif. Consultez les limitations de streaming. Trigger.Once() est pris en charge mais déconseillé : migrez les requêtes existantes vers Trigger.AvailableNow().

Streaming incrémentiel et sur déclenchement

Pour le streaming incrémentiel, exécutez Structured Streaming avec Trigger.AvailableNow() dans un job serverless. Chaque exécution traite toutes les données arrivées depuis le dernier point de contrôle, puis se termine.

Pour configurer une tâche serverless avec un streaming incrémentiel :

L’exemple suivant lit de nouveaux fichiers à partir du stockage cloud (source_path) avec le chargeur automatique, traite toutes les données disponibles au moment de l’exécution et écrit dans une table Delta :

(spark.readStream
   .format("cloudFiles")
   .option("cloudFiles.format", "json")
   .option("cloudFiles.maxFilesPerTrigger", 1000)
   .load(source_path)
   .writeStream
   .trigger(availableNow=True)
   .option("checkpointLocation", checkpoint_path)
   .toTable("catalog.schema.target_table"))

Une tâche Trigger.AvailableNow() planifiée est le schéma de streaming le plus rentable sur une infrastructure serverless lorsqu’une latence de l’ordre de la minute est acceptable. La capacité de calcul démarre en quelques secondes, exécute le traitement par lots, puis s’arrête.

Ingestion managée

Si la source est une application SaaS ou une base de données opérationnelle, utilisez Lakeflow Connect au lieu d’écrire du code Structured Streaming. Lakeflow Connect exécute des pipelines d’ingestion serverless pour les connecteurs tels que Salesforce, Workday, SQL Server CDC et PostgreSQL CDC. Consultez Connecteurs gérés dans Lakeflow Connect.

Ce chemin d’accès est la bonne réponse quand :

  • Un connecteur existe pour votre source.
  • Vous souhaitez un pipeline managé plutôt que du code personnalisé.
  • Vous avez besoin de l’évolution du schéma, de la traçabilité et de la surveillance hors de la boîte de dialogue.

Traitement incrémentiel managé par SQL

Pour les équipes axées sur SQL, utilisez des tables de streaming pour les charges de travail de streaming natives en SQL. Vous pouvez définir des tables de streaming dans Lakeflow Spark Declarative Pipelines ou en tant que tables de streaming autonomes.

Pour les tables de diffusion en continu autonomes créées avec l’instruction CREATE OR REFRESH STREAMING TABLE SQL, l’actualisation initiale des données et la population commencent immédiatement. Un pipeline serverless dédié est créé et géré automatiquement par le système pour chaque table de streaming.

Si vous avez besoin de résultats de requête sémantique par lots avec actualisation managée, utilisez plutôt des vues matérialisées. Consultez Vues matérialisées.

Charges de travail autres que les pipelines de streaming

Une charge de travail qui doit maintenir une connexion persistante, écouter sur un port ou répondre à des requêtes HTTP entrantes n’est pas un pipeline de traitement en continu ; c’est une application. N’exécutez pas ces charges de travail sur un job serverless. Les options Databricks appropriées sont les suivantes :

  • Services de longue durée nécessitant une connexion persistante ou un point de terminaison HTTP : créez le service avec Databricks Apps. Databricks Apps est la plateforme serverless permettant d’héberger des applications personnalisées sur Azure Databricks, notamment FastAPI, Flask, Streamlit, Dash, Gradio, Node.jset les applications Shiny. Consultez Databricks Apps.
  • Webhooks entrants ou écouteurs d’événements : exposez un point de terminaison HTTP dans Databricks Apps, ou faites aboutir le webhook à un service externe et écrivez les événements dans un stockage cloud ou un bus de messages, puis récupérez ensuite ces événements avec un pipeline de streaming sans serveur.
  • Jeton personnalisé ou échange d’informations d’identification : utilisez des principaux de service avec OAuth ou appelez les API REST Databricks à partir d’une application. Les pipelines de streaming ne contiennent pas de sessions par utilisateur ou d’état de jeton personnalisé.

Si vous évaluez si votre charge de travail correspond à un pipeline de diffusion en continu, demandez :

  • La charge de travail lit-elle à partir d’une source de données non entrante et écrit-elle dans un récepteur ? Si oui, il s’agit d’un pipeline de diffusion en continu.
  • La charge de travail doit-elle contenir une connexion ouverte à un client ? Si oui, il s’agit d’une application ; utilisez Databricks Apps.

Limitations

Le calcul serverless impose les contraintes de streaming suivantes. Aucune d’entre elles n’empêche les charges de travail ci-dessus lorsqu’elles sont associées au produit approprié.

  • Les déclencheurs temporels de Structured Streaming (Trigger.ProcessingTime(interval) et Trigger.Continuous(interval)) ne sont pas pris en charge dans les notebooks ou tâches serverless. Utilisez les pipelines déclaratifs Spark Lakeflow en mode continu pour les flux toujours actifs, ou Trigger.AvailableNow() pour les exécutions déclenchées. Consultez les limitations de streaming.
  • Les requêtes de streaming sans déclencheur explicite échouent avec INFINITE_STREAMING_TRIGGER_NOT_SUPPORTED. Par défaut, Apache Spark utilise Trigger.ProcessingTime("0 seconds"), qui n’est pas pris en charge en calcul serverless. Définissez toujours Trigger.AvailableNow() pour chaque requête de streaming, ou utilisez Lakeflow Spark Declarative Pipelines en mode continu.
  • Toutes les limitations du streaming en mode d’accès standard s’appliquent également au calcul serverless. Consultez les limitations de streaming.

Étapes suivantes

  • Last updated on