Informations de référence sur le mode temps réel

Cette page fournit des informations de référence pour le mode en temps réel dans Structured Streaming, notamment les environnements pris en charge, les langues, les sources, les récepteurs et les opérateurs. Pour connaître les limitations connues, consultez les limitations du mode temps réel.

Langues prises en charge

Le mode en temps réel prend en charge Scala, Java et Python.

Types de calcul

Le mode en temps réel prend en charge les types de calcul suivants :

Type de capacité de calcul	Soutenu
Dédié (anciennement : utilisateur unique)	✓
Standard (anciennement : partagé)	✓ (uniquement Python)
Pipelines déclaratifs Spark Lakeflow Classic	Non pris en charge
Pipelines déclaratifs Spark Lakeflow sans serveur	Non pris en charge
Sans serveur	Non pris en charge

Modes d'exécution

Le mode en temps réel prend uniquement en charge le mode de mise à jour :

Mode d’exécution	Soutenu
Mode de mise à jour	✓
Mode d’ajout	Non pris en charge
Mode complet	Non pris en charge

Sources et puits

Le mode en temps réel prend en charge les sources et récepteurs suivants :

Source ou récepteur	En tant que source	En tant que récepteur
Apache Kafka	✓	✓
Event Hubs (à l’aide du connecteur Kafka)	✓	✓
Kinesis	✓ (mode EFO uniquement)	Non pris en charge
AWS MSK	✓	Non pris en charge
Delta	Non pris en charge	Non pris en charge
Google Pub/Sub	Non pris en charge	Non pris en charge
Apache Pulsar	Non pris en charge	Non pris en charge
Récepteurs arbitraires (utilisation de forEachWriter)	Sans objet	✓

Opérateurs

Le mode en temps réel prend en charge la plupart des opérateurs de streaming structuré :

Opérations sans état

Opérateur	Soutenu
Sélection	✓
Projection	✓

UDFs

Opérateur	Soutenu
Scala UDF	✓ (avec certaines limitations)
Python UDF	✓ (avec certaines limitations)

Aggregation

Opérateur	Soutenu
sum	✓
count	✓
max	✓
min	✓
avg	✓
Fonctions d’agrégation	✓

Windowing

Opérateur	Soutenu
Tumbling	✓
Sliding	✓
Session	Non pris en charge

Deduplication

Opérateur	Soutenu
dropDuplicates	✓ (l’état n’est pas lié)
dropDuplicatesWithinWatermark	Non pris en charge

Diffuser en continu vers la jointure de table

Opérateur	Soutenu
Jointure de table de diffusion (la table doit être petite)	✓
Diffuser en continu la jointure	Non pris en charge
(plat)MapGroupsWithState	Non pris en charge
transformWithState	✓ (avec certaines différences)
union	✓ (avec certaines limitations)
forEach	✓
forEachBatch	Non pris en charge
mapPartitions	Non pris en charge (voir limitation)

Considérations spéciales

Certains opérateurs et fonctionnalités ont des considérations ou des différences spécifiques lorsqu’ils sont utilisés en mode temps réel.

transformWithState en mode temps réel

Pour la création d’applications personnalisées avec état, Databricks prend en charge transformWithState, une API dans Apache Spark Structured Streaming. Consultez Créer une application avec état personnalisé pour plus d’informations sur l’API et les extraits de code.

Toutefois, il existe des différences entre le comportement de l’API en mode réel et les requêtes de diffusion en continu traditionnelles qui tirent parti de l’architecture de micro-lots.

• Le mode en temps réel appelle la handleInputRows(key: String, inputRows: Iterator[T], timerValues: TimerValues) méthode pour chaque ligne.
  • L’itérateur inputRows retourne une valeur unique. Le mode micro-lot l'appelle une fois pour chaque clé, et l'itérateur inputRows renvoie toutes les valeurs d'une clé dans le micro-lot.
  • Tenir compte de cette différence lors de l’écriture de votre code
• Les temporisateurs d’événements ne sont pas pris en charge en mode temps réel.
• En mode temps réel, les minuteurs sont retardés en fonction de l’arrivée des données :
  • Si un minuteur est planifié pour 10:00:00, mais qu’aucune donnée n’arrive, le minuteur ne se déclenche pas immédiatement.
  • Si les données arrivent à 10:00:10, le minuteur se déclenche avec un délai de 10 secondes.
  • Si aucune donnée n’arrive et que le traitement de longue durée se termine, le minuteur se déclenche avant l’arrêt du traitement.

Python fonctions définies par l’utilisateur en mode temps réel

Databricks prend en charge la majorité des fonctions définies par l’utilisateur (UDF) Python en mode temps réel :

Sans état

Type UDF	Soutenu
Python fonctions scalaires UDF ( Fonctions scalaires définies par l’utilisateur - Python)	✓
Fonctions UDF scalaires de flèche	✓
Fonctions UDF scalaires Pandas (fonctions définies par l’utilisateur pandas)	✓
Fonction fléchée (mapInArrow)	✓
Pandas, fonction (Map)	✓

Regroupement avec état (UDAF)

Type UDF	Soutenu
transformWithState (interface uniquement Row )	✓
applyInPandasWithState	Non pris en charge

Regroupement non avec état (UDAF)

Type UDF	Soutenu
apply	Non pris en charge
applyInArrow	Non pris en charge
applyInPandas	Non pris en charge

Fonctions de table

Type UDF	Soutenu
UDTF (Python fonctions de table définies par l’utilisateur (UDF))	Non pris en charge
UC UDF	Non pris en charge

Il existe plusieurs points à prendre en compte lors de l’utilisation de Python fonctions définies par l’utilisateur en mode temps réel :

• Pour réduire la latence, réglez la taille du lot Arrow (spark.sql.execution.arrow.maxRecordsPerBatch) à 1.
  • Compromis : cette configuration optimise la latence au détriment du débit. Pour la plupart des charges de travail, ce paramètre est recommandé.
  • Augmentez la taille du lot uniquement si un débit plus élevé est nécessaire pour prendre en charge le volume d’entrée, en acceptant l’augmentation potentielle de la latence.
• Les fonctions pandas et UDF ne fonctionnent pas correctement avec une taille de lot Arrow de 1.
  • Si vous utilisez des fonctions UDFs ou pandas, définissez la taille du lot Arrow sur une valeur supérieure (par exemple, 100 ou plus).
  • Cela implique une latence plus élevée. Databricks recommande d’utiliser une fonction ou une fonction UDF de flèche si possible.
• En raison du problème de performances avec pandas, transformWithState est uniquement pris en charge avec l’interface Row .