Streaming com o Pub/Sub

Nesta página, apresentamos uma visão geral conceitual da integração do Dataflow com o Pub/Sub. A visão geral descreve algumas otimizações que estão disponíveis na implementação do executor do Dataflow do conector de E/S do Pub/Sub. O Pub/Sub é um sistema de processamento e entrega de eventos durável e escalonável. O Dataflow complementa o modelo escalonável pelo menos uma vez de entrega do Pub/Sub com eliminação de duplicação de mensagens, processamento exatamente uma vez e geração de uma marca-d'água de dados em eventos com carimbo de data/hora. Para usar o Dataflow, grave seu pipeline usando o SDK do Apache Beam e execute o código do pipeline no serviço Dataflow.

Antes de começar, conheça os conceitos básicos do Apache Beam e dos pipelines de streaming. Leia os seguintes recursos para mais informações:

Como criar pipelines de streaming com o Pub/Sub

Para aproveitar os benefícios da integração do Dataflow com o Pub/Sub, você pode criar seus pipelines de streaming de uma das seguintes maneiras:

Recursos de integração do Pub/Sub com o Dataflow

O Apache Beam fornece uma implementação de origem de E/S de referência (PubsubIO) para o Pub/Sub (Java e Python), que é usada por executores que não são do Dataflow, como o executor do Apache Spark, o executor do Apache Flink e o executor direto.

No entanto, o executor do Dataflow usa uma implementação diferente e particular de PubsubIO. Essa implementação aproveita as APIs e os serviços internos do Google Cloud para oferecer três vantagens principais: marcas d'água de baixa latência, alta precisão de marca d'água, que favorece a integridade de dados, e eliminação de duplicação eficiente.

A implementação de PubsubIO do executor do Dataflow confirma automaticamente as mensagens depois que elas tiverem sido processadas com sucesso pelo primeiro estágio de fusão (e os efeitos colaterais desse processamento tiverem sido gravados no armazenamento permanente). Consulte a documentação da fusão para mais detalhes. Portanto, as mensagens só são confirmadas quando o Dataflow pode garantir que não haja perda de dados se algum componente falhar ou se uma conexão for perdida.

Marcas d'água de baixa latência

O Dataflow tem acesso à API privada do Pub/Sub que fornece o tempo da mensagem não confirmada mais antiga em uma assinatura, com uma latência menor do que a disponível no Cloud Monitoring. Para fins de comparação, as métricas de backlog do Pub/Sub que estão disponíveis no Cloud Monitoring geralmente têm um atraso de dois a três minutos, mas as métricas têm um atraso de cerca de dez segundos apenas para o Dataflow. Isso permite que o Dataflow avance as marcas d'água do pipeline e emita os resultados da computação em janela em menos tempo.

Alta precisão da marca d'água

Outro problema importante resolvido nativamente pela integração do Dataflow com o Pub/Sub é a necessidade de uma marca d'água robusta para as janelas definidas na hora do evento. O horário do evento é um carimbo de data/hora especificado pelo aplicativo do editor como um atributo de uma mensagem do Pub/Sub, em vez do campo publish_time definido em uma mensagem pelo próprio serviço do Pub/Sub. Como o Pub/Sub calcula as estatísticas do backlog somente em relação aos carimbos de data/hora atribuídos pelo serviço (ou tempo de processamento), a estimativa da marca d'água de hora do evento requer um mecanismo separado.

Para resolver esse problema, se o usuário optar por usar os carimbos de data/hora do evento personalizados, o serviço Dataflow criará uma segunda assinatura de rastreamento. Essa assinatura de rastreamento é usada para inspecionar as horas do evento das mensagens no backlog da assinatura de base e fazer uma estimativa do backlog da hora anterior. Consulte a página do StackOverflow que explica como o Dataflow calcula marcas d'água do Pub/Sub para mais informações.

Eliminação de duplicação eficiente

A eliminação de duplicação de mensagens é necessária para o processamento único de mensagens. O Dataflow elimina a duplicação de mensagens em relação ao identificador da mensagem do Pub/Sub. Portanto, toda lógica de processamento pode presumir que as mensagens já são exclusivas em relação ao identificador da mensagem do Pub/Sub. O mecanismo de agregação incremental e eficiente para conseguir isso é abstraído na API PubsubIO.

Se PubsubIO estiver configurado para usar o atributo de mensagem do Pub/Sub para eliminação de duplicação em vez do ID da mensagem, o Dataflow eliminará a duplicação de mensagens publicadas no Pub/Sub com intervalos de até dez minutos.

Recursos sem suporte do Pub/Sub

Tópicos de mensagens mortas e políticas de repetição

Os tópicos de mensagens mortas e as novas tentativas do Pub/Sub não são totalmente compatíveis com o Dataflow. Em vez disso, implemente esses padrões explicitamente no pipeline. Dois exemplos de padrões de mensagens inativas são fornecidos no aplicativo de varejo e no modelo do Pub/Sub para o BigQuery.

Há dois motivos para os tópicos de mensagens mortas e políticas de repetição não funcionarem com o Dataflow.

Primeiro, o Dataflow não envia mensagens NACK (ou seja, envia uma confirmação negativa) para o Pub/Sub quando o código do pipeline falha. Em vez disso, o Dataflow repete o processamento da mensagem indefinidamente, estendendo continuamente o prazo de confirmação da mensagem. No entanto, o back-end do Dataflow pode reconhecer mensagens por vários motivos internos, portanto, é possível que as mensagens sejam entregues ao tópico de mensagens inativas mesmo quando não houver falhas no código do pipeline.

Segundo, 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 houver falhas a qualquer momento após o primeiro estágio, as mensagens já foram confirmadas.