Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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
inputRowsiterador devuelve un valor único. El modo micro-lote lo invoca una vez para cada clave y elinputRowsiterador devuelve todos los valores de una clave en el micro-lote. - Tenga en cuenta esta diferencia al escribir el código
- El
- 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 () en
spark.sql.execution.arrow.maxRecordsPerBatch1.- 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
Rowinterfaz .
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.