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, Python e Go). Essa implementação de origem de E/S é 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.

O executor do Dataflow usa uma implementação particular diferente de PubsubIO (para Java, Python e Go). 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 (e, portanto, integridade dos dados) e eliminação de duplicação eficiente (processamento único de mensagens).

Os conectores de E/S do Apache Beam permitem interagir com o Dataflow usando origens e coletores controlados. A implementação de PubsubIO no executor do Dataflow reconhece automaticamente as mensagens após o processamento delas pelo primeiro estágio combinado e os efeitos colaterais desse processamento são gravados no armazenamento permanente. Consulte a documentação da fusão para mais detalhes. Portanto, as mensagens só serão reconhecidas quando o Dataflow puder garantir que não haja perda de dados se algum componente falhar ou 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. A hora 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 serviço 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, e é possível usar o modelo de programação do Apache Beam para realizar o processamento único de streamings de mensagens do Pub/Sub. 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

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.

Tópicos de mensagens inativas e políticas de novas tentativas de atraso de espera exponencial

Os tópicos de mensagens inativas e as políticas de novas tentativas de atraso de espera exponencial do Pub/Sub não são totalmente suportados pelo 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 inativas e as políticas de novas tentativas de atraso de espera exponencial 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. Porém, o back-end do Dataflow pode enviar mensagens NACK por vários motivos internos. Portante, é 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 as falhas ocorrerem em qualquer ponto após o primeiro estágio, as mensagens já serão confirmadas.

Entrega exatamente uma vez no Pub/Sub

Como o Dataflow tem o próprio processamento único, não é recomendável usar a entrega única do Pub/Sub no Dataflow. Ativar a entrega única do Pub/Sub reduz o desempenho do pipeline porque limita as mensagens disponíveis para processamento paralelo.

Ordem das mensagens do Pub/Sub

Quando a ordenação de mensagens do Pub/Sub está ativada, o Dataflow pode reordenar as mensagens. O pipeline é executado, mas não há garantia de que as mensagens cheguem na ordem em que o Dataflow as recebe. No entanto, ao usar o Pub/Sub com o Dataflow, ativar a ordenação de mensagens pode aumentar a latência e diminuir o desempenho.

A seguir