Realiza transmisiones con Pub/Sub

En esta página, se proporciona un resumen conceptual de la integración entre Dataflow y Pub/Sub. En este resumen, se especifican algunas optimizaciones disponibles en la implementación del ejecutor de Dataflow del conector de E/S de Pub/Sub. Pub/Sub es un sistema de transferencia y entrega de eventos escalable y duradero. Dataflow complementa el modelo de entrega escalable de tipo “al menos una vez” de Pub/Sub con la anulación de mensajes duplicados, el procesamiento “exactamente una vez” y la generación de una marca de agua de los datos a partir de eventos con marcas de tiempo. Para usar Dataflow, escribe la canalización con el SDK de Apache Beam y, luego, ejecuta el código de canalización en el servicio de Dataflow.

Antes de comenzar, obtén más información sobre los conceptos básicos de Apache Beam y las canalizaciones de transmisión. Lee los siguientes recursos para obtener más información:

Compila canalizaciones de transmisión con Pub/Sub

Para obtener los beneficios de la integración de Dataflow con Pub/Sub, puedes compilar tus canalizaciones de transmisión de cualquiera de las siguientes maneras:

Funciones de integración de Pub/Sub y Dataflow

Apache Beam proporciona una implementación de fuente de E/S de referencia (PubsubIO) para Pub/Sub (Java, Python y Go). que utilizan ejecutores que no son de Dataflow, como los ejecutores de Apache Spark y Apache Flink, y el ejecutor directo.

El ejecutor de Dataflow usa una implementación de PubsubIO que es distinta y privada (para Java, Python y Go). Además, aprovecha las API y los servicios internos de Google Cloud para ofrecer tres ventajas principales: marcas de agua de baja latencia, alta precisión de marcas de agua (y, por lo tanto, integridad de datos) y anulación de duplicación eficiente (procesamiento de mensajes “exactamente una vez”).

Los conectores de E/S de Apache Beam te permiten interactuar con Dataflow mediante fuentes y receptores controlados. La implementación de PubsubIO del ejecutor de Dataflow reconoce de forma automática los mensajes después de que la primera etapa fusionada los procesa de forma correcta, y los efectos secundarios de ese procesamiento se escriben en el almacenamiento continuo. Consulta la documentación de Fusion para obtener más detalles. Por lo tanto, se confirma la recepción de los mensajes solo cuando Dataflow puede garantizar que no habrá pérdida de datos si falla algún componente o se pierde una conexión.

Marcas de agua de baja latencia

Dataflow tiene acceso a la API privada de Pub/Sub que proporciona la antigüedad del mensaje no confirmado más antiguo de una suscripción, con una latencia menor que la disponible en Cloud Monitoring. A modo de comparación, las métricas de trabajos pendientes de Pub/Sub que están disponibles en Cloud Monitoring suelen retrasarse entre dos y tres minutos, mientras que, en Dataflow, la demora es de alrededor de diez segundos. Esto permite que Dataflow potencie las marcas de agua de la canalización y emita resultados de procesamiento en ventanas más rápido.

Alta precisión de marcas de agua

Otro problema considerable que se resuelve de manera nativa mediante la integración entre Dataflow y Pub/Sub es la necesidad de una marca de agua sólida para las ventanas que se definen en la hora del evento. La hora del evento es una marca de tiempo que especifica la aplicación del publicador como un atributo de un mensaje de Pub/Sub, en lugar del campo publish_time configurado en un mensaje por el servicio de Pub/Sub. Debido a que Pub/Sub calcula las estadísticas de las tareas pendientes solo con respecto a las marcas de tiempo asignadas por el servicio (o el tiempo de procesamiento), la estimación de la marca de agua de la hora del evento requiere un mecanismo independiente.

Para resolver este problema, si el usuario decide usar marcas de tiempo de eventos personalizados, el servicio de Dataflow crea una segunda suscripción de seguimiento. Esta suscripción de seguimiento se usa para inspeccionar los tiempos de los eventos de los mensajes de la lista de tareas pendientes de la suscripción base y calcular las tareas pendientes de tiempo del evento. Consulta la página de Stack Overflow que trata sobre cómo calcula Dataflow las marcas de agua de Pub/Sub para obtener más información.

Anulación de duplicación eficaz

La anulación de duplicación de mensajes es necesaria para el procesamiento de mensajes del tipo “exactamente una vez” y puedes usar el modelo de programación de Apache Beam a fin de lograr el procesamiento de mensajes del tipo “exactamente una vez” de las transmisiones de mensajes de Pub/Sub. Dataflow anula los mensajes duplicados con respecto al ID de mensaje de Pub/Sub. Como resultado, toda la lógica de procesamiento puede dar por hecho que los mensajes ya son únicos según el ID de mensaje de Pub/Sub. En la API de PubsubIO, se abstrae el mecanismo de agregación incremental y eficiente que permite lograr esta anulación de duplicación.

Si PubsubIO está configurado para usar el atributo de mensaje de Pub/Sub en la anulación de duplicación en lugar del ID del mensaje, Dataflow anulará la duplicación de los mensajes publicados en Pub/Sub en un plazo de 10 minutos entre sí.

Características de Pub/Sub no compatibles

Las siguientes funciones de Pub/Sub no son compatibles con la implementación del ejecutor de Dataflow del conector de E/S de Pub/Sub.

Temas de mensajes no entregados y políticas de reintentos de retirada exponencial

Los temas de mensajes no entregados de Pub/Sub y las políticas de reintento de retraso de retirada exponencial no son totalmente compatibles con Dataflow. En su lugar, implementa estos patrones de forma explícita dentro de la canalización. Se proporcionan dos ejemplos de patrones de mensajes no entregados en la aplicación de venta minorista y la plantilla de Pub/Sub a BigQuery.

Existen dos motivos por los que las políticas de reintentos de retirada exponencial y temas de mensajes no entregados no funcionan con Dataflow.

Primero, Dataflow no envía mensajes NACK (es decir, envía una confirmación negativa) a Pub/Sub cuando falla el código de canalización. En su lugar, Dataflow vuelve a intentar el procesamiento del mensaje de forma indefinida, mientras extiende el plazo de confirmación para el mensaje de forma continua. Sin embargo, el backend de Dataflow puede enviar mensajes NACK por varios motivos internos, por lo que es posible que los mensajes se entreguen al tema de mensajes no entregados, incluso cuando no hay fallas en el código de la canalización.

En segundo lugar, Dataflow puede confirmar mensajes antes de que la canalización procese los datos por completo. En particular, Dataflow reconoce los mensajes después de que se procesaron de forma correcta en la primera etapa fusionada y los efectos secundarios de ese procesamiento se escribieron en el almacenamiento continuo. Si la canalización tiene varias etapas fusionadas y se producen fallas en cualquier momento después de la primera etapa, los mensajes ya se confirmaron.

Entrega de Pub/Sub “exactamente una vez”

Debido a que Dataflow tiene su propio procesamiento “exactamente una vez”, no se recomienda usar la entrega “exactamente una vez” de Pub/Sub con Dataflow. Habilitar la entrega “exactamente una vez” de Pub/Sub reduce el rendimiento de la canalización, ya que limita los mensajes disponibles para el procesamiento paralelo.

Pub/Sub: ordenamiento de mensajes

Cuando el orden de mensajes de Pub/Sub está habilitado, Dataflow puede reordenar los mensajes. La canalización se ejecuta, pero no se garantiza que los mensajes lleguen en el orden en que Dataflow los recibe. Sin embargo, cuando se usa Pub/Sub con Dataflow, habilitar el ordenamiento de los mensajes puede aumentar la latencia y disminuir el rendimiento.

¿Qué sigue?