Configurer les intervalles de déclenchement pour Structured Streaming

Cet article explique comment configurer des intervalles de déclencheur pour Structured Streaming sur Azure Databricks.

Apache Spark Structured Streaming traite les données de manière incrémentielle. Les intervalles de déclenchement contrôlent la fréquence à laquelle Structured Streaming vérifie les nouvelles données. Vous pouvez configurer des intervalles de déclenchement pour le traitement quasi-en temps réel, pour les actualisations planifiées de la base de données ou le traitement par lots de toutes les nouvelles données pendant un jour ou une semaine.

Étant donné qu’est-ce que le chargeur automatique ? utilise Structured Streaming pour charger des données, comprendre le fonctionnement des déclencheurs vous offre la plus grande flexibilité pour contrôler les coûts lors de l’ingestion de données avec la fréquence souhaitée.

Vue d’ensemble des modes de déclencheur

Le tableau suivant récapitule les modes de déclencheur disponibles dans Structured Streaming :

Mode déclencheur	Exemple de syntaxe (Python)	Idéal pour
Non spécifié (valeur par défaut)	N/A	Diffusion en continu à usage général avec une latence de 3 à 5 secondes. Équivalent au déclencheur processingTime avec des intervalles de 0 ms. Le traitement de flux s’exécute en continu tant que de nouvelles données arrivent.
Temps de traitement	.trigger(processingTime='10 seconds')	Équilibrage des coûts et des performances. Réduit la surcharge en empêchant le système de vérifier les données trop fréquemment.
Disponible maintenant	.trigger(availableNow=True)	Traitement par lots incrémentiel planifié. Traite autant de données que possible au moment où la tâche de streaming est déclenchée.
Mode en temps réel	.trigger(realTime='5 minutes')	Charges de travail opérationnelles à latence ultra faible nécessitant un traitement en sous-seconde, comme la détection de fraude ou la personnalisation en temps réel. Aperçu public. « 5 minutes » indique la longueur d’un micro-lot. Utilisez 5 minutes pour réduire la surcharge par lot, comme la compilation des requêtes.
Continu	.trigger(continuous='1 second')	Non pris en charge. Il s’agit d’une fonctionnalité expérimentale incluse dans Spark OSS. Utilisez plutôt le mode en temps réel.

processingTime : intervalles de déclencheurs basés sur le temps

Structured Streaming fait référence aux intervalles de déclencheurs basés sur le temps en tant que « micro-lots à intervalle fixe ». À l’aide du mot clé processingTime, spécifiez une durée en tant que chaîne, telle que .trigger(processingTime='10 seconds').

La configuration de cet intervalle détermine la fréquence à laquelle le système effectue des vérifications pour voir si de nouvelles données sont arrivées. Configurez votre temps de traitement pour équilibrer les exigences de latence et le taux d’arrivée des données dans la source.

AvailableNow: traitement par lots incrémentiel

Important

Dans Databricks Runtime 11.3 LTS et versions ultérieures, Trigger.Once est déconseillé. Utiliser Trigger.AvailableNow pour toutes les charges de travail de traitement par lots incrémentielles.

L’option AvailableNow de déclencheur consomme tous les enregistrements disponibles en tant que lot incrémentiel avec la possibilité de configurer la taille du lot avec des options telles que maxBytesPerTrigger. Les options de dimensionnement varient selon la source de données.

Sources de données prises en charge

Azure Databricks prend en charge l’utilisation Trigger.AvailableNow pour le traitement par lots incrémentiel à partir de nombreuses sources Structured Streaming. Le tableau suivant inclut la version minimale prise en charge de Databricks Runtime requise pour chaque source de données :

Origine	Version minimale de Databricks Runtime
Sources de fichiers (JSON, Parquet, etc.)	9.1 LTS
Delta Lake	10.4 LTS
Chargeur automatique	10.4 LTS
Apache Kafka	10.4 LTS
Cinèse	13.1

realTime : charges de travail opérationnelles à ultra-faible latence

Important

Cette fonctionnalité est disponible en préversion publique.

Le mode en temps réel pour Structured Streaming atteint une latence de bout en bout inférieure à 1 seconde dans le pire des cas, et environ 300 ms dans les cas courants. Pour plus d’informations sur la façon de configurer et d’utiliser efficacement le mode en temps réel, consultez le mode temps réel dans Structured Streaming.

Apache Spark a un intervalle de déclencheur supplémentaire appelé traitement continu. Ce mode a été classé comme expérimental depuis Spark 2.3. Azure Databricks ne prend pas en charge ni ne recommande ce mode. Utilisez plutôt le mode en temps réel pour les cas d’utilisation à faible latence.

Remarque

Le mode de traitement continu de cette page n’est pas lié au traitement continu dans les pipelines déclaratifs Spark Lakeflow.

Modifier les intervalles de déclencheur entre les exécutions

Vous pouvez modifier l’intervalle de déclenchement entre les exécutions lors de l’utilisation du même point de contrôle.

Comportement lors de la modification des intervalles

Si un travail Structured Streaming s’arrête pendant qu’un micro-lot est en cours de traitement, ce micro-lot doit être terminé avant que le nouvel intervalle de déclenchement s’applique. Par conséquent, vous pouvez observer un traitement par micro-lots avec les paramètres précédemment spécifiés après avoir modifié l’intervalle de déclencheur. Les éléments suivants décrivent le comportement attendu lors de la transition :

• Transition de l’intervalle de temps à AvailableNow: un micro-lot pourrait être traité avant que tous les enregistrements disponibles ne soient traités sous forme de lot incrémentiel.

• Transition d'un intervalle AvailableNow vers un intervalle basé sur le temps : le traitement peut continuer pour tous les enregistrements disponibles lors du déclenchement de la dernière AvailableNow tâche. Ce comportement est normal.

Récupération après échecs de requête

Remarque

Si vous essayez de corriger un échec de requête associé à un lot incrémentiel, modifier l'intervalle de déclenchement ne résout pas ce problème, car le lot doit, de toute façon, être terminé. Augmentez la capacité de calcul utilisée pour traiter le lot pour essayer de résoudre le problème. Dans de rares cas, vous devrez peut-être redémarrer le flux avec un nouveau point de contrôle.