Leer de Pub/Sub a Dataflow

En esta página se describen las prácticas recomendadas para leer datos de Pub/Sub en Dataflow.

Apache Beam proporciona una implementación de referencia del conector de entrada/salida de Pub/Sub para que lo usen los ejecutores que no son de Dataflow. Sin embargo, el runner de Dataflow usa su propia implementación personalizada del conector. Esta implementación aprovecha las APIs y los servicios internos de Google Cloud Platform para ofrecer marcas de agua de baja latencia, alta precisión y desduplicación eficiente para el procesamiento de mensajes exactamente una vez. El conector está disponible para Java, Python y Go.

Procesamiento exacto

Pub/Sub desacopla los editores de eventos de los consumidores de eventos. La aplicación publica mensajes en un tema y Pub/Sub entrega los mensajes de forma asíncrona a los suscriptores.

Pub/Sub asigna un ID de mensaje único a cada mensaje que se publica correctamente en un tema. De forma predeterminada, Pub/Sub realiza la entrega de mensajes al menos una vez. Para conseguir una semántica de al menos una vez, si Pub/Sub no recibe la confirmación del suscriptor antes de la fecha límite, vuelve a intentar entregar el mensaje. También se pueden producir reintentos antes de la fecha límite de confirmación o después de que se haya confirmado un mensaje.

Dataflow confirma los mensajes después de que la primera fase combinada los haya procesado correctamente y los efectos secundarios de ese procesamiento se hayan escrito en el almacenamiento persistente. Para reducir el número de mensajes duplicados, Dataflow amplía continuamente el plazo de confirmación mientras se procesa un lote de mensajes en esta fase.

Como Pub/Sub puede volver a enviar un mensaje, es posible que lleguen mensajes duplicados al flujo de procesamiento. Si tu flujo de procesamiento de Dataflow usa el modo de streaming "una sola vez", Dataflow anula los duplicados de estos mensajes para conseguir una semántica de "una sola vez".

Si tu canalización puede tolerar algunos registros duplicados, te recomendamos que uses el modo de streaming al menos una vez. Este modo puede reducir significativamente la latencia y el coste total de tu flujo de trabajo. La contrapartida es que los mensajes duplicados se pueden procesar dos veces. Para obtener más información, consulta Elegir el modo de streaming que se va a usar.

Eliminar duplicados por atributo de mensaje

De forma predeterminada, Dataflow elimina los duplicados en función del ID de mensaje. Sin embargo, una aplicación puede enviar el mismo registro dos veces como dos mensajes de Pub/Sub distintos. Por ejemplo, los datos de origen pueden contener registros duplicados o la aplicación puede publicar incorrectamente el mismo mensaje dos veces. Esto último puede ocurrir debido a reintentos, si se ha descartado la confirmación debido a problemas de red u otras interrupciones. En estas situaciones, los mensajes duplicados tienen IDs de mensaje diferentes.

En función de tu situación, tus datos pueden contener un campo único que se pueda usar para eliminar duplicados. Por ejemplo, los registros pueden contener un ID de transacción único. Puedes configurar el conector de entrada/salida de Pub/Sub para que elimine los mensajes duplicados en función del valor de un atributo de mensaje, en lugar de usar el ID de mensaje de Pub/Sub. Siempre que el editor defina este atributo de forma coherente durante los reintentos, Dataflow podrá detectar los duplicados. Los mensajes deben publicarse en Pub/Sub con una diferencia de 10 minutos como máximo para que se eliminen los duplicados.

Para obtener más información sobre el uso de atributos de ID, consulta los siguientes temas de referencia del SDK:

Suscripciones

Cuando configuras tu canalización, especificas un tema o una suscripción de Pub/Sub desde los que leer. Si especificas una suscripción, no utilices la misma suscripción de Pub/Sub en varias canalizaciones. Si dos flujos de procesamiento leen datos de una sola suscripción, cada uno de ellos recibirá parte de los datos de forma no determinista, lo que puede provocar que se dupliquen los mensajes, que haya un retraso en la marca de agua y que el autoescalado sea ineficiente. En su lugar, crea una suscripción independiente para cada canal.

Si especificas un tema, el conector crea una suscripción temporal. Esta suscripción es única por canal.

Marcas de tiempo y marcas de agua

Todos los mensajes de Pub/Sub tienen una marca de tiempo, que representa el momento en el que Pub/Sub recibe el mensaje. Tus datos también pueden tener una marca de tiempo de evento, que es la hora en la que la fuente generó el registro.

Puede configurar el conector para que lea la marca de tiempo del evento de un atributo del mensaje de Pub/Sub. En ese caso, el conector usa la marca de tiempo del evento para añadir la marca de agua. De lo contrario, se usará de forma predeterminada la marca de tiempo del mensaje de Pub/Sub.

Para obtener más información sobre cómo usar las marcas de tiempo de los eventos, consulta los siguientes temas de referencia del SDK:

El conector de Pub/Sub tiene acceso a la API privada de Pub/Sub, que proporciona la antigüedad del mensaje más antiguo sin confirmar de una suscripción. Esta API proporciona una latencia más baja que la disponible en Cloud Monitoring. Permite que Dataflow avance las marcas de agua de las canalizaciones y emita resultados de computación en ventanas con latencias bajas.

Si configuras el conector para que use marcas de tiempo de eventos, Dataflow creará una segunda suscripción a Pub/Sub, llamada suscripción de seguimiento. Dataflow usa la suscripción de seguimiento para inspeccionar las horas de los eventos de los mensajes que aún están en el registro pendiente. Este enfoque permite que Dataflow estime con precisión el backlog de tiempo de evento. La cuenta de servicio de trabajador debe tener al menos los siguientes permisos en el proyecto que contiene la suscripción de seguimiento:

  • pubsub.subscriptions.create
  • pubsub.subscription.consume
  • pubsub.subscription.delete

Además, necesita el permiso pubsub.topics.attachSubscription en el tema de Pub/Sub. Te recomendamos que crees un rol de gestión de identidades y accesos personalizado que solo contenga estos permisos.

Para obtener más información sobre las marcas de agua, consulta la página de Stack Overflow sobre cómo calcula Dataflow las marcas de agua de Pub/Sub.

Si una canalización tiene varias fuentes de Pub/Sub y una de ellas tiene un volumen muy bajo o está inactiva, se retrasa el avance de toda la marca de agua, lo que aumenta la latencia general de la canalización. Si hay temporizadores o agregaciones de ventanas en la canalización basados en la marca de agua, también se retrasan.

Búsqueda de Pub/Sub

Pub/Sub Seek permite a los usuarios reproducir mensajes confirmados anteriormente. Puedes usar la búsqueda de Pub/Sub con Dataflow para volver a procesar mensajes en una canalización.

Sin embargo, no se recomienda usar la búsqueda de Pub/Sub en una canalización en ejecución. Si se retrocede en una canalización en ejecución, se pueden duplicar o eliminar mensajes. También invalida la lógica de marca de agua de Dataflow y entra en conflicto con el estado de una canalización que incorpora datos procesados.

Para volver a procesar mensajes mediante la búsqueda de Pub/Sub, se recomienda seguir este flujo de trabajo:

  1. Crea una captura de la suscripción.
  2. Crea una suscripción para el tema de Pub/Sub. La nueva suscripción hereda la captura.
  3. Agota o cancela la tarea de Dataflow actual.
  4. Vuelve a enviar la canalización con la nueva suscripción.

Para obtener más información, consulta Reprocesamiento de mensajes con las funciones de captura y búsqueda de Pub/Sub.

Funciones de Pub/Sub no compatibles

Las siguientes funciones de Pub/Sub no se admiten en la implementación del conector de entrada/salida de Pub/Sub del runner de Dataflow.

Tiempo de espera exponencial

Cuando creas una suscripción de Pub/Sub, puedes configurarla para que use una política de reintentos con retroceso exponencial. Sin embargo, el tiempo de espera exponencial no funciona con Dataflow. En su lugar, crea la suscripción con la política de reintentos Reintentar inmediatamente.

El retroceso exponencial se activa cuando se recibe una confirmación negativa o cuando vence el plazo de confirmación. Sin embargo, Dataflow no envía confirmaciones negativas cuando falla el código de la canalización. En su lugar, vuelve a intentar procesar el mensaje indefinidamente, mientras amplía continuamente el plazo de confirmación del mensaje.

Temas de mensajes fallidos

No uses temas de mensajes fallidos de Pub/Sub con Dataflow por los siguientes motivos:

  • Dataflow envía confirmaciones negativas por varios motivos internos (por ejemplo, si un trabajador se está cerrando). Por lo tanto, es posible que los mensajes se envíen al tema de mensajes fallidos aunque no se produzcan errores en el código de la canalización.

  • Dataflow confirma los mensajes después de que la primera fase combinada procese correctamente un paquete de mensajes. Si la canalización tiene varias fases fusionadas y se producen errores en cualquier momento después de la primera fase, los mensajes ya se han confirmado y no se envían al tema de mensajes fallidos.

En su lugar, implementa el patrón de mensajes fallidos de forma explícita en la canalización. Para ello, enruta los mensajes fallidos a un destino para procesarlos más adelante. Algunos receptores de E/S tienen compatibilidad integrada con colas de mensajes fallidos. En los siguientes ejemplos se implementan patrones de mensajes fallidos:

Entrega exacta una sola vez de Pub/Sub

Como Dataflow tiene sus propios mecanismos para el procesamiento de tipo "exactamente una vez", no se recomienda usar la entrega de tipo "exactamente una vez" de Pub/Sub con Dataflow. Si habilitas la entrega de Pub/Sub exactamente una vez, se reduce el rendimiento de la canalización, ya que se limita el número de mensajes que están disponibles para el procesamiento en paralelo.

Orden de los mensajes de Pub/Sub

La ordenación de mensajes es una función de Pub/Sub que permite a un suscriptor recibir mensajes en el orden en el que se publicaron.

No se recomienda usar el orden de los mensajes con Dataflow por los siguientes motivos:

  • Es posible que el conector de E/S de Pub/Sub no conserve el orden de los mensajes.
  • Apache Beam no define directrices estrictas sobre el orden en el que se procesan los elementos. Por lo tanto, es posible que no se conserve el orden en las transformaciones posteriores.
  • Usar el orden de los mensajes de Pub/Sub con Dataflow puede aumentar la latencia y reducir el rendimiento.

Transformaciones de mensajes individuales de Pub/Sub

Las transformaciones de mensajes únicos (SMTs) te permiten manipular, validar y filtrar mensajes en función de sus atributos o datos a medida que se transmiten por el sistema. Las suscripciones que se introducen en Dataflow no deben usar SMTs que filtren mensajes, ya que pueden interferir con el escalado automático. Esto ocurre porque el filtrado de SMT de suscripciones puede hacer que el backlog parezca mayor de lo que se envía a Dataflow hasta que el SMT procesa los mensajes filtrados. Los SMTs de temas que filtran mensajes no causarán problemas con el autoescalado.

Siguientes pasos