Compartir a través de


Referencia del modo en tiempo real

En esta página se proporciona información de referencia para el modo en tiempo real en Structured Streaming, incluidos entornos admitidos, lenguajes, orígenes, receptores, operadores y limitaciones conocidas.

Entornos, lenguajes y modos admitidos

Idiomas admitidos: El modo en tiempo real admite Scala, Java y Python.

Tipos de cálculo admitidos:

Tipo de proceso Soportado
Dedicado (anteriormente: usuario único)
Estándar (anteriormente: compartido) ✓ (solo Python)
Canalizaciones Declarativas Clásicas de Lakeflow Spark No soportado
Lakeflow Spark: Canalizaciones Declarativas sin Servidor No soportado
Serverless No soportado

Modos de ejecución admitidos:

Modo de ejecución Soportado
Modo de actualización
Append mode No soportado
Modo completo No soportado

Soporte para el origen y el receptor

Origen o receptor Como origen Como sumidero
Apache Kafka
Event Hubs (mediante el conector de Kafka)
Kinesis ✓ (solo modo EFO) No soportado
AWS MSK No soportado
Delta No soportado No soportado
Google Pub/Sub No soportado No soportado
Apache Pulsar No soportado No soportado
Receptores arbitrarios (mediante forEachWriter) No es aplicable

Operadores compatibles

Operadores Soportado
Operaciones sin estado
Selection
Proyección
UDFs
Scala UDF ✓ (con algunas limitaciones)
Funciones Definidas por el Usuario (UDF) de Python ✓ (con algunas limitaciones)
Agregación
sum
conteo
max
min
avg
Funciones de agregaciones
Ventanas
Saltos de tamaño constante
Deslizante
Sesión No soportado
Deduplicación
dropDuplicates ✓ (el estado es ilimitado)
EliminarDuplicadosDentroDeMarcaDeAgua No soportado
Stream- Table Join
Tabla de difusión (debe ser pequeña)
Secuencia: unión de secuencia No soportado
(plano)MapGroupsWithState No soportado
transformWithState ✓ (con algunas diferencias)
union ✓ (con algunas limitaciones)
forEach
forEachBatch No soportado
mapPartitions No compatible (consulte limitación)

Consideraciones especiales

Algunos operadores y características tienen consideraciones o diferencias específicas cuando se usan en modo en tiempo real.

transformWithState en modo en tiempo real

Para crear aplicaciones con estado personalizadas, Databricks admite transformWithState, una API en Apache Spark Structured Streaming. Consulte Compilación de una aplicación con estado personalizada para obtener más información sobre la API y los fragmentos de código.

Sin embargo, hay algunas diferencias entre el comportamiento de la API en modo tiempo real y las consultas de streaming tradicionales que aprovechan la arquitectura de micro-lotes.

  • El modo de tiempo real llama al método handleInputRows(key: String, inputRows: Iterator[T], timerValues: TimerValues) para cada fila.
    • El inputRows iterador devuelve un valor único. El modo micro-lote lo invoca una vez para cada clave y el inputRows iterador devuelve todos los valores de una clave en el micro-lote.
    • Tenga en cuenta esta diferencia al escribir el código
  • Los temporizadores de eventos no son compatibles con el modo de tiempo real.
  • En modo en tiempo real, los temporizadores se retrasan al activarse en función de la llegada de datos:
    • Si un temporizador está programado para las 10:00:00, pero no llega ningún dato, el temporizador no se activa inmediatamente.
    • Si los datos llegan a las 10:00:10, el temporizador se activa con un retraso de 10 segundos.
    • Si no llegan datos y el lote de ejecución prolongada finaliza, el temporizador se activa antes de que finalice el lote.

UDFs de Python en modo en tiempo real

Databricks admite la mayoría de las funciones definidas por el usuario (UDF) de Python en modo en tiempo real:

Categoría Tipo de UDF Soportado
Sin estado UDF escalar de Python (funciones escalares definidas por el usuario: Python)
Sin estado UDF escalar de flecha
Sin estado UDF escalar de Pandas (funciones definidas por el usuario de Pandas)
Sin estado Función Arrow (mapInArrow)
Sin estado Función Pandas (Mapa)
Agrupación con estado (UDAF) transformWithState (Row solo interfaz)
Agrupación con estado (UDAF) applyInPandasWithState No soportado
Agrupación no con estado (UDAF) apply No soportado
Agrupación no con estado (UDAF) applyInArrow No soportado
Agrupación no con estado (UDAF) applyInPandas No soportado
Función de tabla UDTF (funciones de tabla definidas por el usuario (UDTFs) de Python) No soportado
Función de tabla UC UDF No soportado

Hay varios puntos que se deben tener en cuenta al usar UDF de Python en modo en tiempo real:

  • Para minimizar la latencia, configure el tamaño del lote de flecha () enspark.sql.execution.arrow.maxRecordsPerBatch 1.
    • Compensación: esta configuración optimiza la latencia a costa del rendimiento. Para la mayoría de las cargas de trabajo, se recomienda esta configuración.
    • Aumente el tamaño del lote solo si se requiere un mayor rendimiento para dar cabida al volumen de entrada, aceptando el posible aumento de la latencia.
  • Las UDF y las funciones de Pandas no rinden bien con un tamaño de lote de Arrow de 1.
    • Si usa funciones UDF o funciones de pandas, establezca el tamaño del lote de Arrow en un valor mayor (por ejemplo, 100 o superior).
    • Esto implica una mayor latencia. Databricks recomienda usar una UDF de flecha o una función si es posible.
  • Debido al problema de rendimiento con pandas, transformWithState solo se admite con la Row interfaz .

Limitaciones

Limitaciones de origen

Para Kinesis, el modo en tiempo real no admite el modo de sondeo. Además, las reparticiones frecuentes podrían afectar negativamente a la latencia.

Limitaciones de unión

El operador Union tiene algunas limitaciones:

  • El modo en tiempo real no admite la unión automática:
    • Kafka: no se puede usar el mismo objeto de data frame de origen ni unir data frames derivados de él. Solución alternativa: use diferentes dataframes que leen desde el mismo origen.
    • Kinesis: no se pueden combinar marcos de datos derivados del mismo origen de Kinesis con la misma configuración. Solución alternativa: además de usar diferentes DataFrames, puede asignar una opción "consumerName" diferente a cada DataFrame.
  • El modo en tiempo real no admite operadores con estado (por ejemplo, aggregate, deduplicate, transformWithState) definidos antes de la Unión.
  • El modo en tiempo real no admite la unión con orígenes por lotes.

Limitación de MapPartitions

mapPartitions en Scala y las API de Python similares (mapInPandas, mapInArrow) toma un iterador de toda la partición de entrada y genera un iterador de toda la salida con asignación arbitraria entre entrada y salida. Estas APIs pueden causar problemas de rendimiento en modo en tiempo real de transmisión, al bloquear toda la salida, lo que aumenta la latencia. La semántica de estas APIs no admite bien la propagación de marcas de agua.

Usa UDF escalar combinadas con Transformar tipos de datos complejos o filter para lograr una funcionalidad similar.