Streaming en computación sin servidor

En esta página se describe cómo elegir la configuración adecuada para las cargas de trabajo de streaming sin servidor en Azure Databricks, incluidas canalizaciones continuas, ingesta incremental y conectores administrados. Elegir la configuración adecuada depende de las necesidades de origen, forma y latencia de la secuencia.

Qué se considera una carga de trabajo en streaming

Una carga de trabajo de procesamiento en streaming lee datos no acotados de un origen (como el almacenamiento de objetos en la nube, un bus de mensajes o un canal de cambios) y escribe en un destino de forma incremental. Azure Databricks soporta los siguientes patrones de cargas de trabajo en streaming:

• Continuo: Una pipeline que se ejecuta sin detenerse y procesa nuevos datos a medida que llegan, para cargas de trabajo con requisitos de frescura medidos en segundos o minutos.
• Tiempo real: Una tubería continua que procesa registros con latencia inferior a un segundo para cargas operativas soportadas. El modo en tiempo real está disponible en Lakeflow pipelines y en Structured Streaming.
• Incremental (también denominado desencadenado): una canalización que se ejecuta según una programación o un desencadenador, procesa todos los datos que han llegado desde la última ejecución y se detiene. La latencia se mide en minutos.

Algunas cargas de trabajo parecen ser canalizaciones de streaming, pero técnicamente no son canalizaciones. Algunos ejemplos incluyen un servicio que contiene un websocket abierto para escuchar eventos, una aplicación de chat que mantiene una conexión persistente por usuario o un receptor de webhook que controla las solicitudes HTTP entrantes. Estas son aplicaciones, no canalizaciones de streaming. Para obtener la opción sin servidor adecuada para esas cargas de trabajo, consulte Cargas de trabajo que no son canalizaciones de streaming.

Elección de la configuración de streaming correcta

En esta tabla se asignan casos de uso a las configuraciones sin servidor que mejor se ajusten a ellas. Las secciones siguientes en esta página proporcionan más detalles sobre estas recomendaciones.

Transmisión continua

Para la transmisión continua en proceso sin servidor, utilice las canalizaciones de Lakeflow en modo continuo. La canalización permanece en ejecución, procesa los registros a medida que llegan y se recupera automáticamente de los errores.

Para configurar un flujo continuo:

• Configure la canalización como sin servidor. Consulte Configuración de una canalización sin servidor.
• Establezca el modo de canalización en modo continuo. Consulte Desencadenado frente al modo de canalización continua.
• Use tablas de streaming para resultados que se mantienen de forma incremental.

Los desencadenadores de Structured Streaming basados en tiempo, como Trigger.ProcessingTime(interval) y Trigger.Continuous(interval), no están disponibles en cuadernos o trabajos sin servidor. Utilice las canalizaciones de Lakeflow en modo continuo para el patrón siempre activo. Consulte Limitaciones de streaming. Trigger.Once() está soportado pero está obsoleto. Migrar consultas existentes a Trigger.AvailableNow().

Transmisión en tiempo real

El modo en tiempo real en las canalizaciones Lakeflow soporta cargas de trabajo operativas de latencia inferior a un segundo, como la detección de fraude y la personalización en tiempo real. Está disponible tanto en entornos de proceso clásicos como serverless. Configura un flujo de actualización con un destino compatible y revisa los requisitos de ejecución y del operador. Los flujos de actualización en tiempo real no pueden escribir en tablas Delta Lake.

El modo de pipeline continuo y el modo en tiempo real cumplen diferentes requisitos de latencia. Activar solo el modo continuo no activa el modo en tiempo real.

Transmisión incremental y activada por desencadenadores

Para el streaming incremental, ejecute Structured Streaming con Trigger.AvailableNow() en un trabajo sin servidor. Cada ejecución procesa todos los datos que han llegado desde el último punto de control y, a continuación, sale.

Para configurar un trabajo sin servidor con streaming incremental:

• Programe la tarea con la frecuencia que necesite. Consulte Ejecución de trabajos según una programación.
• Usa Trigger.AvailableNow() en todas las consultas de streaming del trabajo. Consulte Configurar intervalos del desencadenador de Structured Streaming.
• Ajuste el tamaño del lote con maxFilesPerTrigger o maxBytesPerTrigger para mantener un uso de memoria predecible. Consulte Procedimientos recomendados para el proceso sin servidor.

En el ejemplo siguiente se leen los nuevos archivos del almacenamiento en la nube (source_path) con el cargador automático, se procesan todos los datos disponibles en el momento de la ejecución y se escriben en una tabla 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"))

Una tarea programada Trigger.AvailableNow() es el patrón de transmisión más eficiente en costes en la computación sin servidor cuando se acepta una latencia del orden de minutos. La capacidad de cómputo se inicia en cuestión de segundos, ejecuta el proceso por lotes y se apaga.

Ingesta gestionada

Si el origen es una aplicación SaaS o una base de datos operativa, use Lakeflow Connect en lugar de escribir código de Structured Streaming. Lakeflow Connect ejecuta canalizaciones de ingesta sin servidor para conectores como Salesforce, Workday, SQL Server CDC y CDC de PostgreSQL. Consulte los conceptos de conectores Lakeflow Connect.

Esta ruta de acceso es la respuesta correcta cuando:

• Hay un conector para su fuente.
• Quiere una canalización administrada en lugar de código personalizado.
• Necesita la evolución del esquema, el linaje y la supervisión de forma predeterminada.

Procesamiento de datos incrementales administrados por SQL

Para los equipos que priorizan SQL, use tablas de streaming para cargas de trabajo nativas de SQL para streaming. Puede definir tablas de streaming dentro de canalizaciones de Lakeflow o como tablas de streaming independientes.

Para las tablas de streaming independientes creadas mediante la instrucción SQL CREATE OR REFRESH STREAMING TABLE, la actualización inicial de los datos y la población comienzan inmediatamente. El sistema crea y administra automáticamente una canalización sin servidor dedicada para cada tabla de streaming.

Si necesita resultados de consulta semántica por lotes con actualización administrada, use vistas materializadas en su lugar. Consulte Vistas materializadas.

Cargas de trabajo que no son canalizaciones de streaming

Una carga de trabajo que necesita contener una conexión de larga duración, escuchar en un puerto o responder a las solicitudes HTTP entrantes no es una canalización de streaming; es una aplicación. No ejecute estas cargas de trabajo en un trabajo sin servidor. Las opciones correctas de Databricks son:

• Servicios de larga duración que necesitan una conexión persistente o un punto de conexión HTTP: compile el servicio con Databricks Apps. Databricks Apps es la plataforma sin servidor para hospedar aplicaciones personalizadas en Azure Databricks, incluidas las aplicaciones FastAPI, Flask, Streamlit, Dash, Gradio, Node.jsy Shiny. Consulte Aplicaciones de Databricks.
• Webhooks entrantes o detectores de eventos: Exponga un punto de conexión HTTP en Databricks Apps o procese el webhook en un servicio externo y escriba los eventos en el almacenamiento en la nube o en un bus de mensajes; a continuación, recójalos con una canalización de procesamiento en streaming sin servidor.
• Intercambio personalizado de tokens o credenciales: Use entidades de servicio con OAuth, o llame a las API REST de Databricks desde una aplicación. Las canalizaciones de transmisión no mantienen sesiones por usuario ni estado personalizado de los tokens.

Si está evaluando si su carga de trabajo encaja en una canalización de datos en streaming, pregúntese:

• ¿La carga de trabajo lee datos de una fuente de datos no acotada y los escribe en un destino? Si es así, se trata de una canalización de streaming.
• ¿La carga de trabajo necesita contener una conexión abierta a un cliente? Si es así, es una aplicación; usa Databricks Apps.

Limitaciones

Las siguientes restricciones de streaming se aplican a los notebooks y trabajos serverless. Para los requisitos y limitaciones de la canalización, consulte Configurar una canalización serverless y Utilizar el modo en tiempo real en las canalizaciones de Lakeflow.

• Los desencadenadores de Structured Streaming basados en tiempo (Trigger.ProcessingTime(interval) y Trigger.Continuous(interval)) no se admiten en cuadernos o trabajos sin servidor. Utilice las canalizaciones de Lakeflow en modo continuo para flujos siempre activos o Trigger.AvailableNow() para ejecuciones activadas. Consulte Limitaciones de streaming.
• Las consultas de streaming sin un desencadenador explícito producen un error con INFINITE_STREAMING_TRIGGER_NOT_SUPPORTED. Apache Spark tiene como valor predeterminado Trigger.ProcessingTime("0 seconds"), que no se admite en el proceso sin servidor. Configure siempre Trigger.AvailableNow() en cada consulta de streaming, o use canalizaciones de Lakeflow en modo continuo.
• Todas las limitaciones de streaming en modo de acceso estándar también se aplican al proceso sin servidor. Consulte Limitaciones de streaming.

Pasos siguientes

• Configuración de una canalización sin servidor
• Ejecutar Lakeflow Jobs en computación sin servidor
• Explora conceptos de conectores Lakeflow Connect