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 admite dos patrones de cargas de trabajo de streaming:

  • Continuo: una canalización que se ejecuta sin detenerse y procesa nuevos datos a medida que llegan. La latencia se mide en segundos.
  • 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.

Caso de uso Configuración recomendada Por qué
ETL o transformaciones continuas de streaming de baja latencia Lakeflow Spark Declarative Pipelines en modo continuo El modo continuo está diseñado para transmisiones siempre activas. La canalización de flujos ejecuta microlotes de forma simultánea, lo que mejora el rendimiento y reduce la latencia. El estado administrado mantiene la recuperación automática.
Ingesta incremental desde el almacenamiento en la nube Use Auto Loader dentro de las canalizaciones declarativas de Spark de Lakeflow (para una latencia baja) o en un trabajo sin servidor con Trigger.AvailableNow() (si es aceptable una latencia menor). Auto Loader realiza un seguimiento eficaz de los nuevos archivos. Trigger.AvailableNow() procesa la cola pendiente y, a continuación, finaliza, lo que encaja con una cadencia programada o bajo demanda.
Ingestión gestionada de orígenes de SaaS o CDC de bases de datos Conectores estándar en Lakeflow Connect Conectores totalmente administrados con canalizaciones de ingesta sin servidor. No se requiere código para las fuentes compatibles.
Streaming de SQL a través de tablas delta Tablas de streaming Procesamiento incremental nativo de SQL para orígenes orientados a anexos, con canalizaciones administradas y actualización.
Procesamiento periódico por lotes en un cuaderno o trabajo Trabajo sin servidor con Trigger.AvailableNow() Eficiente en costes cuando basta con una actualización al minuto. La computación sin servidor se inicia rápidamente y finaliza cuando termina el lote.

Transmisión continua

Para la transmisión continua en cómputo sin servidor, utilice Lakeflow Spark Declarative Pipelines 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:

Tip

La canalización de flujos está habilitada de forma predeterminada en canalizaciones declarativas de Spark de Lakeflow sin servidor. Los microbatches se ejecutan simultáneamente en lugar de secuencialmente, lo que mejora el rendimiento de las secuencias pesadas de ingesta.

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 declarativas de Spark de Lakeflow en el modo continuo para el patrón siempre activo. Consulte Limitaciones de streaming. Trigger.Once() se admite pero está en desuso: migre las consultas existentes a Trigger.AvailableNow().

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:

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 Conectores administrados en 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 las canalizaciones declarativas de Spark 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

La computación sin servidor impone las siguientes restricciones para el streaming. Ninguna de ellas impide que las cargas de trabajo anteriores se emparejan con el producto correcto.

  • Los desencadenadores de Structured Streaming basados en tiempo (Trigger.ProcessingTime(interval) y Trigger.Continuous(interval)) no se admiten en cuadernos o trabajos sin servidor. Use canalizaciones declarativas de Spark de Lakeflow en modo continuo para secuencias always-on o Trigger.AvailableNow() para ejecuciones desencadenadas. 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. Establezca siempre Trigger.AvailableNow() en cada consulta de streaming, o use canalizaciones declarativas de Spark 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

  • Last updated on