Ler do Pub/Sub para o Dataflow

Nesta página, descrevemos as práticas recomendadas para leitura do Pub/Sub no Dataflow.

O Apache Beam fornece uma implementação de referência do conector de E/S do Pub/Sub para uso por executores que não são do Dataflow. No entanto, o executor do Dataflow usa a própria implementação personalizada do conector. Essa implementação aproveita as APIs e os serviços internos do Google Cloud para oferecer marcas d'água de baixa latência, alta precisão de marca d'água e eliminação de duplicação eficiente para o processamento de mensagens exatamente uma vez. Ele está disponível para Java, Python e Go.

Processamento único

O Pub/Sub separa os editores de eventos dos consumidores de eventos. O aplicativo publica mensagens em um tópico, e o Pub/Sub entrega as mensagens de maneira assíncrona aos assinantes.

O Pub/Sub atribui um ID de mensagem exclusivo a cada mensagem publicada em um tópico. Por padrão, o Pub/Sub executa a entrega de mensagens pelo menos uma vez. Para alcançar a semântica do tipo "pelo menos uma vez", o Pub/Sub tenta a entrega novamente caso não receba confirmação do assinante dentro do prazo de confirmação. As novas tentativas podem resultar na entrega de uma mensagem mais de uma vez. Por exemplo, a reentrega pode ocorrer se o assinante confirmar após o prazo ou se a confirmação for perdida devido a problemas temporários de rede.

Se você executar o pipeline do Dataflow usando o modo de streaming exatamente uma vez, o Dataflow elimina a duplicação de mensagens para alcançar semântica exatamente uma vez. Se o pipeline puder tolerar alguns registros duplicados, use o modo de streaming pelo menos uma vez. Esse modo pode reduzir significativamente a latência e o custo total do pipeline. A desvantagem é que algumas mensagens podem ser processadas duas vezes. Para mais informações, consulte Escolher qual modo de streaming usar.

Eliminar duplicação por atributo de mensagem

Por padrão, o Dataflow elimina a duplicação com base no ID da mensagem. No entanto, um aplicativo pode enviar o mesmo registro duas vezes que duas mensagens diferentes do Pub/Sub. Por exemplo, os dados originais podem conter registros duplicados ou o aplicativo pode publicar incorretamente a mesma mensagem duas vezes. O último problema pode acontecer devido a novas tentativas, se a confirmação tiver sido descartada devido a problemas de rede ou outras interrupções. Nessas situações, as mensagens duplicadas têm IDs de mensagem diferentes.

Dependendo do cenário, os dados podem conter um campo exclusivo que pode ser usado para eliminar duplicações. Por exemplo, os registros podem conter um ID da transação exclusivo. É possível configurar o conector de E/S do Pub/Sub para eliminar a duplicação de mensagens com base no valor de um atributo de mensagem, em vez de usar o ID de mensagem do Pub/Sub. Contanto que o publisher defina esse atributo de maneira consistente durante novas tentativas, o Dataflow poderá detectar as duplicatas. As mensagens precisam ser publicadas no Pub/Sub com até 10 minutos umas das outras para eliminar a duplicação.

Para mais informações sobre o uso de atributos de ID, consulte os seguintes tópicos de referência do SDK:

Assinaturas

Ao configurar o pipeline, você especifica um tópico do Pub/Sub ou uma assinatura do Pub/Sub para ler. Se você especificar uma assinatura, não use a mesma assinatura do Pub/Sub para vários pipelines. Se dois pipelines forem lidos de uma única assinatura, cada um deles vai receber parte dos dados de maneira não determinista, o que pode causar mensagens duplicadas, atraso de marca d'água e escalonamento automático ineficiente. Em vez disso, crie uma assinatura separada para cada pipeline.

Se você especificar um tópico, o conector criará uma nova assinatura temporária. Essa assinatura é exclusiva por pipeline.

Marcações de tempo e marcas d'água

Todas as mensagens do Pub/Sub têm um carimbo de data/hora, que representa o momento em que o Pub/Sub recebe a mensagem. Os dados também podem ter um carimbo de data/hora do evento, que é a hora em que o registro foi gerado pela origem.

É possível configurar o conector para ler o carimbo de data/hora do evento de um atributo na mensagem do Pub/Sub. Nesse caso, o conector usa o carimbo de data/hora do evento para a marca d'água. Caso contrário, por padrão, ele usará o carimbo de data/hora da mensagem do Pub/Sub.

Para mais informações sobre como usar carimbos de data/hora de eventos, consulte os seguintes tópicos de referência do SDK:

O conector do Pub/Sub tem acesso à API particular do Pub/Sub que fornece a idade da mensagem não confirmada mais antiga em uma assinatura. Essa API oferece menor latência do que a disponível no Cloud Monitoring. Ele permite que o Dataflow avance as marcas-d'água do pipeline e emita resultados de computação em janela com baixas latências.

Se você configurar o conector para usar carimbos de data/hora de eventos, o Dataflow criará uma segunda assinatura do Pub/Sub. Ela é usada para inspecionar os horários de eventos das mensagens que ainda estão no backlog. Essa abordagem permite que o Dataflow estime o backlog do tempo do evento com precisão. Para mais informações, consulte a página do StackOverflow que aborda como o Dataflow calcula marcas d'água do Pub/Sub.

Busca do Pub/Sub

A busca do Pub/Sub permite que os usuários repitam as mensagens confirmadas anteriormente. É possível usar a busca do Pub/Sub com o Dataflow para reprocessar mensagens em um pipeline.

No entanto, não é recomendado usar a busca do Pub/Sub em um pipeline em execução. Buscar para trás em um pipeline em execução pode levar ao descarte de mensagens duplicadas. Ele também invalida a lógica da marca-d'água do Dataflow e entra em conflito com o estado de um pipeline que incorpora dados processados.

Para reprocessar mensagens usando a busca do Pub/Sub, o seguinte fluxo de trabalho é recomendado:

  1. Crie um snapshot da assinatura:
  2. Criar uma nova assinatura para o tópico do Pub/Sub A nova assinatura herda o snapshot.
  3. Drene ou cancele o job atual do Dataflow.
  4. Envie o pipeline novamente usando a nova assinatura.

Para mais informações, consulte Reprocessamento de mensagens com snapshot e busca do Pub/Sub.

Recursos sem suporte do Pub/Sub

Os seguintes recursos do Pub/Sub não são compatíveis com a implementação do executor do Dataflow do conector de E/S do Pub/Sub.

Espera exponencial

Ao criar uma assinatura do Pub/Sub, é possível configurá-la para usar uma política de nova tentativa com espera exponencial. No entanto, a espera exponencial não funciona com o Dataflow. Em vez disso, crie a assinatura com a política de Tentar de novo imediatamente.

A espera exponencial é acionada por uma confirmação negativa ou quando o prazo de confirmação expira. No entanto, o Dataflow não envia confirmações negativas quando o código do pipeline falha. Em vez disso, ele repete o processamento da mensagem indefinidamente, estendendo continuamente o prazo de confirmação da mensagem.

Tópicos com mensagens inativas

Não use tópicos de mensagens inativas do Pub/Sub com o Dataflow pelos seguintes motivos:

  • O Dataflow envia confirmações negativas por vários motivos internos (por exemplo, se um worker está sendo encerrado). Como resultado, as mensagens podem ser entregues ao tópico de mensagens inativas mesmo quando nenhuma falha ocorrer no código do pipeline.

  • O Dataflow pode confirmar mensagens antes que o pipeline processe totalmente os dados. Especificamente, o Dataflow confirma as mensagens depois que elas são processadas com sucesso pela primeira fase combinada e os efeitos colaterais desse processamento são gravados no armazenamento permanente. Se o pipeline tiver vários estágios combinados e ocorrerem a qualquer momento após o primeiro estágio, as mensagens já serão confirmadas e não vão para o tópico de mensagens inativas.

Em vez disso, implemente o padrão de mensagens inativas explicitamente no pipeline. Alguns coletores de E/S têm suporte integrado para filas de mensagens inativas. Os exemplos a seguir implementam padrões de mensagens inativas.

Entrega exatamente uma vez no Pub/Sub

Como o Dataflow tem os próprios mecanismos para processamento único, não é recomendado usar a entrega única do Pub/Sub com o Dataflow. Ativar a entrega única do Pub/Sub reduz o desempenho do pipeline, porque limita o número de mensagens disponíveis para processamento paralelo.

Ordem das mensagens do Pub/Sub

A ordenação de mensagens é um recurso do Pub/Sub que permite que um assinante receba mensagens na ordem em que foram publicadas.

Não é recomendável usar a ordenação de mensagens com o Dataflow pelos seguintes motivos:

  • O conector de E/S do Pub/Sub pode não preservar a ordem das mensagens.
  • O Apache Beam não define diretrizes rígidas com relação à ordem em que os elementos são processados. Portanto, a ordem pode não ser preservada em transformações downstream.
  • O uso da ordenação de mensagens do Pub/Sub com o Dataflow pode aumentar a latência e diminuir o desempenho.

A seguir