Projetar fluxos de trabalho de pipelines do Dataflow

A criação de pipelines envolve diferentes etapas e tarefas, como desenvolvimento, teste e entrega de código na produção. Veja o que explicamos neste documento:

• Considerações para integração contínua e entrega contínua (CI/CD) para permitir a criação automatizada, o teste e a implantação de pipelines em diferentes ambientes.
• Recursos do Dataflow para otimizar o desempenho e a utilização de recursos na produção
• Abordagens e pontos de controle para atualizar pipelines de streaming em produção
• Práticas recomendadas para melhorar a confiabilidade do pipeline na produção

Integração contínua

A integração contínua (CI) exige que os desenvolvedores mesclem o código em um repositório compartilhado com frequência, o que é útil para aplicativos que mudam muito, como sites atualizados com frequência. Os pipelines de dados geralmente não mudam tanto quanto outros tipos de aplicativos, mas as práticas de CI oferecem muitos benefícios para o desenvolvimento do pipeline. Por exemplo, a automação de teste fornece feedback rápido quando são encontrados defeitos e reduz a probabilidade de regressões inserirem a base do código.

A automação de teste é uma parte importante da CI. Quando combinada com a cobertura de teste adequada, a automação de teste executa seu conjunto de testes em cada confirmação de código. O servidor de CI pode trabalhar em conjunto com uma ferramenta de automação de versão, como o Maven, para executar o conjunto de testes como uma ou mais etapas do pipeline de CI. É possível empacotar códigos que transmitem testes de unidade e de integração em artefatos de implantação de onde os pipelines são iniciados. Esse build é conhecido como build de aprovação.

O número e os tipos de artefatos de implantação criados de um build de aprovação variam dependendo de como os pipelines são iniciados. Com o SDK do Apache Beam para Java, é possível empacotar o código do pipeline em um arquivo JAR de execução automática (em inglês). Em seguida, armazene o arquivo JAR em um bucket hospedado no projeto para um ambiente de implantação, como o projeto de pré-produção ou de produção do Google Cloud. Se você usar modelos clássicos (um tipo de execução com modelo ), os artefatos de implantação incluem um Arquivo de modelo JSON, o arquivo JAR do pipeline e um modelo de metadados opcional. Em seguida, implante os artefatos em diferentes ambientes de implantação usando a entrega contínua, conforme explicado na seção a seguir.

Entrega e integração contínuas

A entrega contínua (CD) copia os artefatos de implantação para um ou mais ambientes de implantação prontos para serem iniciados manualmente. Normalmente, os artefatos criados pelo servidor de CI são implantados em um ou mais ambientes de pré-produção para executar testes de ponta a ponta. O ambiente de produção será atualizado se todos os testes de ponta a ponta forem aprovados.

Para pipelines em lote, a implantação contínua pode iniciar o pipeline diretamente como um novo job do Dataflow. Como alternativa, outros sistemas podem usar os artefatos para iniciar jobs em lote quando necessário. Por exemplo, é possível usar o Cloud Composer para executar jobs em lote dentro de um fluxo de trabalho ou o Cloud Scheduler para programar jobs em lote.

Pode ser mais complexo implantar pipelines de streaming do que pipelines em lote e, portanto, pode ser mais difícil automatizá-los usando a implantação contínua. Por exemplo, talvez seja necessário determinar como substituir ou atualizar um pipeline de streaming atual. Se não for possível atualizar um pipeline ou optar por não atualizá-lo, use outros métodos, como coordenar vários jobs do Dataflow para minimizar ou evitar interrupções nos negócios.

Identidades e papéis necessários para CI/CD

O pipeline de CI/CD interage com diferentes sistemas para criar, testar e implantar pipelines. Por exemplo, o pipeline precisa acessar seu repositório de código-fonte. Para ativar essas interações, verifique se o pipeline tem as identidades e papéis adequados. As atividades de pipeline a seguir também podem exigir que o pipeline tenha identidades e papéis específicos.

Teste de integração com serviços externos, incluindo o Google Cloud

Quando você usa o Direct Runner para executar testes ad hoc ou de integração do sistema, o pipeline usa as credenciais da Google Cloud CLI para consumir fontes de dados e coletores do Google Cloud ou usa as credenciais fornecidas pela variável de ambiente GOOGLE_APPLICATION_CREDENTIALS. Verifique se a conta de serviço usada para receber as credenciais dos recursos do Google Cloud acessados pelo pipeline tem papéis e permissões suficientes.

Implantar artefatos em diferentes ambientes de implantação

Sempre que possível, use credenciais exclusivas para cada ambiente (efetivamente para cada projeto) e limite o acesso aos recursos conforme necessário.

Use contas de serviço exclusivas para cada projeto a ler e gravar artefatos de implantação em buckets de armazenamento. Dependendo de o pipeline usar um modelo, o processo de implantação pode precisar organizar vários artefatos. Por exemplo, criar e organizar um modelo do Dataflow requer permissões para gravar artefatos de implantação necessários para iniciar seu pipeline, como o arquivo de modelo, um bucket do Cloud Storage.

Implantar pipelines em diferentes ambientes de implantação

Sempre que possível, use contas de serviço exclusivas para cada projeto para acessar e gerenciar recursos do Google Cloud no projeto, incluindo o acesso ao Dataflow.

A conta de serviço usada para criar e gerenciar jobs do Dataflow precisa ter permissões do IAM suficientes para o gerenciamento de jobs. Para mais detalhes, consulte a seção Conta de serviço do Dataflow na página de segurança e permissões do Dataflow.

A conta de serviço do worker usada para executar jobs do Dataflow precisa de permissão para gerenciar recursos do Compute Engine enquanto o job é executado e gerenciar a interação entre o pipeline do Apache Beam e o serviço do Dataflow. Para mais detalhes, consulte a seção Conta de serviço do worker na página de segurança e permissões do Dataflow.

Para especificar uma conta de serviço de worker gerenciada pelo usuário para um job, use a opção de pipeline --serviceAccount. Se você não especificar uma conta de serviço do worker ao criar um job, o Dataflow tentará usar a conta de serviço padrão do Compute Engine. É recomendável especificar uma conta de serviço do worker gerenciada pelo usuário para ambientes de produção, porque a conta de serviço padrão do Compute Engine geralmente tem um conjunto mais amplo de permissões do que as permissões necessárias para os jobs do Dataflow.

Em cenários de produção, recomendamos que você use contas de serviço separadas para o gerenciamento de jobs do Dataflow e para a conta de serviço do worker, o que oferece segurança aprimorada em comparação com o uso de uma única conta de serviço. Por exemplo, a conta de serviço usada para criar jobs do Dataflow pode não precisar acessar fontes e coletores de dados ou usar outros recursos usados pelo pipeline. Nesse cenário, a conta de serviço do worker usada para executar jobs do Dataflow recebe permissões para usar recursos de pipeline. Uma conta de serviço diferente para a criação de jobs recebe permissões para gerenciar (incluindo criar) jobs do Dataflow.

Exemplo de pipeline de CI/CD

O diagrama a seguir é uma visão geral do CI/CD para pipelines de dados, independente da ferramenta. Além disso, o diagrama mostra a relação entre as tarefas de desenvolvimento, os ambientes de implantação e os executores de pipeline.

O diagrama mostra os seguintes estágios:

• Desenvolvimento de código: durante o desenvolvimento do código, um desenvolvedor executa o código do pipeline localmente usando o Direct Runner. Além disso, os desenvolvedores usam um ambiente de sandbox para a execução de pipeline ad-hoc usando o Dataflow Runner.

  Em pipelines típicos de CI/CD, o processo de integração contínua é acionado quando um desenvolvedor faz uma alteração no sistema de controle de origem, como o envio de um novo código para um repositório.

• Criar e testar: o processo de integração contínua compila o código de pipeline e, em seguida, executa testes de unidade e transforma testes de integração usando o Direct Runner. Também é possível executar testes de integração do sistema, que incluem testes com fontes externas e coletores usando conjuntos de dados pequenos.

  Se os testes forem bem-sucedidos, o processo de CI armazenará os artefatos de implantação, que podem incluir arquivos JAR, imagens do Docker e metadados de modelo, necessários para iniciar o pipeline em locais acessíveis ao processo de entrega contínua. Dependendo dos tipos de artefatos de implantação gerados, você pode usar o Cloud Storage e o Artifact Registry para armazenar os diferentes tipos de artefatos.

• Entregar e implantar: o processo de entrega contínua copia os artefatos de implantação em um ambiente de pré-produção ou os disponibiliza para uso nesse ambiente. Os desenvolvedores podem executar manualmente testes completos usando o Dataflow Runner ou a implantação contínua para iniciar o teste automaticamente. Normalmente, uma abordagem de implantação contínua é mais fácil de ativar para pipelines em lote do que para pipelines de streaming. Como os pipelines em lote não são executados continuamente, é mais fácil substituí-los por uma nova versão.

  O processo de atualização de pipelines de streaming pode ser simples ou complexo, e você precisa testar as atualizações no ambiente de pré-produção. Os procedimentos de atualização nem sempre são consistentes entre as versões. Por exemplo, um pipeline pode mudar de tal maneira que torna as atualizações no local impossíveis. Por esse motivo, às vezes é difícil automatizar as atualizações do pipeline usando a implantação contínua.

Se todos os testes de ponta a ponta forem aprovados, será possível copiar os artefatos de implantação ou disponibilizá-los para o ambiente de produção como parte do processo de entrega contínua. Se o novo pipeline atualizar ou substituir um pipeline de streaming atual, use os procedimentos testados no ambiente de pré-produção para implantar o novo pipeline.

Execução de jobs sem modelo e com modelo

É possível criar um job do Dataflow usando o SDK do Apache Beam diretamente de um ambiente de desenvolvimento. Esse tipo de job é chamado de job não modelado. Embora essa abordagem seja conveniente para os desenvolvedores, talvez você prefira separar as tarefas de desenvolvimento e execução de pipelines. Para fazer essa separação, é possível usar modelos do Dataflow, que permitem testar e executar os pipelines como tarefas independentes. Depois que um modelo é testado, outros usuários, incluindo aqueles que não são desenvolvedores, podem executar os jobs no modelo usando a Google Cloud CLI, o console do Google Cloud ou a API REST do Dataflow.

O Dataflow oferece os seguintes tipos de modelos de job:

• Modelos clássicos: os desenvolvedores usam o SDK do Apache Beam para executar o código do pipeline e salvar o gráfico de execução serializado do JSON como o modelo. O SDK do Apache Beam organiza o arquivo de modelo em um local do Cloud Storage com todas as dependências exigidas pelo código do pipeline.
• Modelos Flex: os desenvolvedores usam a Google Cloud CLI para empacotar o pipeline como uma imagem do Docker, que é armazenada no Artifact Registry. Um arquivo de especificação de modelo Flex também é gerado e armazenado automaticamente em um local do Cloud Storage especificado pelo usuário. O arquivo de especificação do modelo flexível contém metadados que descrevem como executar o modelo, como parâmetros de pipeline.

Além dos recursos do modelo Flex explicados na documentação vinculada, os modelos Flex oferecem vantagens em relação aos modelos clássicos para gerenciar modelos.

• Com os modelos clássicos, vários artefatos, como arquivos JAR, podem ser armazenados em um local de teste do Cloud Storage, mas sem recursos para gerenciar esses vários artefatos. Em comparação, um modelo flexível é encapsulado em uma imagem do Docker. A imagem empacota todas as dependências, além da especificação do modelo Flex, que são necessárias para o pipeline em um artefato de implantação gerenciado pelo Artifact Registry.
• Use os recursos de gerenciamento de imagens do Docker para seus modelos flexíveis. Por exemplo, é possível compartilhar com segurança modelos Flex concedendo permissões de pull (e, opcionalmente, push) ao Artifact Registry e usar tags de imagem do Docker para versões diferentes dos seus modelos Flex.

Os desenvolvedores podem usar os modelos clássicos e Flex para iniciar jobs em um projeto diferente do projeto proprietário do registro e do bucket de armazenamento que hospeda os recursos do modelo ou apenas do bucket de armazenamento, se você usar Modelos clássicos. Esse recurso é útil para isolar o processamento de dados de vários clientes em diferentes projetos e jobs do pipeline. Usando modelos Flex, é possível especificar ainda mais diferentes versões de uma imagem do Docker a ser usada quando você inicia um pipeline. Esse recurso simplifica a substituição em fases dos pipelines em lote ou de streaming em vários projetos quando você atualiza os modelos posteriormente.

Recursos do Dataflow para otimizar o uso de recursos

O Dataflow fornece os seguintes recursos específicos do executor para otimizar o uso de recursos, o que pode melhorar o desempenho e reduzir os custos:

• Streaming Engine: o Streaming Engine muda a execução de pipelines de streaming dos workers de VM para um serviço dedicado. Os benefícios incluem melhoria na capacidade de escalonamento automático, reduções nos recursos de VM de worker consumidos e atualizações automáticas de serviço sem reimplantação. Em alguns casos, você também pode reduzir o uso de recursos com um processamento pelo menos uma vez para casos de uso que podem tolerar cópias. É recomendável ativar o Streaming Engine para pipelines de streaming. O recurso é ativado por padrão quando você usa as versões mais recentes do SDK do Apache Beam Java ou do SDK do Python.
• Dataflow Shuffle: o Dataflow Shuffle muda as operações embaralhadas de pipelines em lote dos workers de VM para um serviço dedicado. Os benefícios incluem execução mais rápida para a maioria dos pipelines em lote, redução do consumo de recursos por VMs de worker, melhoria da capacidade de resposta do escalonamento automático e melhor tolerância a falhas. É recomendável ativar o Dataflow Shuffle para pipelines em lote. O recurso é ativado por padrão usando o SDK do Apache Beam Java e o SDK do Python mais recente.
• Programação flexível de recursos (FlexRS): reduz os custos de processamento em lote usando técnicas de programação avançadas, o serviço Dataflow Shuffle e uma combinação de instâncias de VM preemptivas e VMs comuns.

Atualizar pipelines de streaming em produção

Consulte Fazer upgrade de um pipeline de streaming.

Vida útil de um job do Dataflow

Um job do Dataflow passa por um ciclo de vida representado por vários estados de job. Para executar um job do Dataflow, envie-o para uma região. O job é roteado para um back-end disponível do Dataflow em uma das zonas dentro da região. Antes de atribuir um back-end, o Dataflow verifica se você tem cota e permissões suficientes para executar o job. Quando essas verificações de simulação são concluídas e um back-end é atribuído, o job passa para o estado JOB_STATE_PENDING. Para jobs FlexRS, a atribuição de back-end pode ser atrasada em um horário futuro e esses jobs entram em estado JOB_STATE_QUEUED.

O back-end atribuído escolhe o job a ser executado e tenta iniciar os workers do Dataflow no projeto do Google Cloud. A zona escolhida para as VMs de worker depende de vários fatores. Para jobs em lote que usam o Dataflow Shuffle, o serviço também tenta garantir que as VMs de back-end e de worker do Dataflow estejam localizadas na mesma zona, para evitar o tráfego entre zonas.

Depois que os workers do Dataflow são iniciados, eles solicitam trabalho do back-end do Dataflow. O back-end é responsável por dividir o trabalho em blocos paralelos, chamados de pacotes, que são distribuídos entre os workers. Se os workers não conseguirem lidar com o trabalho atual e se o escalonamento automático estiver ativado, o back-end acionará mais workers para processar o trabalho. Da mesma forma, se mais workers são iniciados do que o necessário, alguns deles são encerrados.

Após o início dos workers do Dataflow, o back-end do Dataflow atua como o plano de controle para orquestrar a execução do job. Durante o processamento, o plano de dados do job executa operações de embaralhamento, como GroupByKey, CoGroupByKey e Combine. Os jobs usam uma das seguintes implementações de plano de dados para operações de embaralhamento:

• O plano de dados é executado nos workers do Dataflow, e os dados de embaralhamento são armazenados em discos permanentes.
• O plano de dados é executado como um serviço, externo às VMs de worker. Essa implementação tem duas variantes que você especifica ao criar o job: Dataflow Shuffle para pipelines em lote e Streaming Engine para pipelines de streaming. A reprodução baseada em serviço melhora significativamente o desempenho e a escalonabilidade das operações de reprodução aleatória de dados em comparação com a reprodução baseada em worker.

Jobs de streaming que entram em um estado JOB_STATE_RUNNING continuam em execução indefinidamente até serem cancelados ou drenados, a menos que ocorra uma falha no job. Os jobs em lote são interrompidos automaticamente quando todo o processamento é concluído ou quando ocorre um erro irrecuperável. Dependendo de como o job é interrompido, o Dataflow definirá o status do job como um dos vários estados de terminal, como JOB_STATE_CANCELLED, JOB_STATE_DRAINED ou JOB_STATE_DONE.

Práticas recomendadas de confiabilidade do pipeline

Nesta seção, discutiremos as falhas que podem ocorrer quando você trabalha com o Dataflow e as práticas recomendadas para jobs do Dataflow.

Seguir princípios de isolamento

Uma recomendação para melhorar a confiabilidade geral do pipeline é seguir os princípios de isolamento das regiões e zonas. Certifique-se de que os pipelines não tenham dependências críticas entre regiões. Se você tiver um pipeline com dependência crítica em serviços de várias regiões, uma falha em qualquer uma dessas regiões poderá impactar seu pipeline. Para ajudar a evitar esse problema, implante em várias regiões para redundância e backup.

Criar snapshots do Dataflow

O Dataflow oferece um recurso de snapshot que disponibiliza um backup do estado de um pipeline. É possível restaurar o snapshot do pipeline em um novo pipeline de streaming do Dataflow em outra zona ou região. Inicie o reprocessamento de mensagens nos tópicos do Pub/Sub ou do Kafka começando no carimbo de data/hora do snapshot. Se você configurar snapshots regulares dos pipelines, será possível minimizar o tempo do objetivo de tempo de recuperação (RTO)

Para mais informações sobre snapshots do Dataflow, consulte Usar snapshots do Dataflow.

Solucionar falhas no envio de jobs

Você envia jobs do Dataflow que não são de modelo usando o SDK do Apache Beam. Para enviar o job, execute o pipeline usando o Dataflow Runner, que é especificado como parte das opções do pipeline. O SDK do Apache Beam organiza arquivos no Cloud Storage, cria um arquivo de solicitação de job e o envia para o Dataflow.

Como alternativa, os jobs criados a partir de modelos do Dataflow usam métodos de envio diferentes, que geralmente dependem da API de modelos.

Você pode ver erros diferentes retornados pelo Dataflow que indicam falha no job para jobs de modelo ou sem modelo. Nesta seção, discutimos diferentes tipos de falhas de envio de jobs e práticas recomendadas para resolvê-las ou reduzi-las.

Repetir envios de jobs após falhas temporárias

Se um job não for iniciado devido a um problema de serviço do Dataflow, tente novamente algumas vezes. Tentar novamente reduz os problemas de serviço temporários.

Diminuir as falhas de zona especificando uma região de worker

O Dataflow fornece disponibilidade regional e está disponível em várias regiões. Quando um usuário envia um job para uma região sem especificar explicitamente uma zona, o Dataflow encaminha o job para uma zona na região especificada com base na disponibilidade de recursos.

A opção recomendada para o posicionamento de jobs é especificar uma região de worker usando a flag --region no lugar da flag --zone sempre que possível. Essa etapa permite que o Dataflow forneça um nível extra de tolerância a falhas para os pipelines. Isso é feito escolhendo automaticamente a melhor zona possível para o job. Os jobs que especificam uma zona explícita não têm esse benefício e falham se ocorrerem problemas na zona. Se um envio de job falhar devido a um problema de zona, o problema poderá ser resolvido repetindo o job sem especificar explicitamente uma zona.

Diminuir as falhas regionais armazenando dados em várias regiões

Se uma região inteira não estiver disponível, tente o job em uma região diferente. É importante pensar na disponibilidade dos dados quando os jobs falham em várias regiões. Para se proteger contra falhas de região única sem copiar dados manualmente para várias regiões, use os recursos do Google Cloud que armazenam dados automaticamente em várias regiões. Por exemplo, use locais multirregionais do BigQuery para conjuntos de dados ou buckets birregionais e multirregionais do Cloud Storage. Se uma região ficar indisponível, será possível executar o pipeline novamente em outra região em que os dados estejam disponíveis.

Para um exemplo de uso de serviços multirregionais com o Dataflow, consulte Alta disponibilidade e redundância geográfica.

Solucionar falhas na execução de pipelines

Depois que um job é enviado e aceito, as únicas operações válidas para ele são:

• cancelar jobs em lote;
• atualizar, drenar ou cancelar jobs de streaming.

Não é possível alterar o local dos jobs em execução depois de enviá-los. Se você não estiver usando o FlexRS, os jobs geralmente começarão a processar dados alguns minutos após o envio. Os jobs do FlexRS podem levar até seis horas para iniciar o processamento de dados.

Esta seção discute falhas para executar jobs e práticas recomendadas para processá-los.

Monitorar jobs para identificar e resolver problemas causados por erros temporários

Para jobs em lote, os pacotes que incluem um item com falha são repetidos quatro vezes. O Dataflow encerra o job quando um único pacote tiver falhado quatro vezes. Esse processo resolve muitos problemas temporários. No entanto, se ocorrer uma falha prolongada, o limite máximo de novas tentativas será atingido logo, o que permite que o job falhe rapidamente.

Para monitoramento e gerenciamento de incidentes, configure regras de alerta para detectar jobs com falha. Se um job falhar, inspecione os registros do job para identificar falhas causadas por itens de trabalho com falha que excederam o limite de repetição.

Para jobs de streaming, o Dataflow repete os itens de trabalho com falha indefinidamente. O job não será encerrado. No entanto, o job pode parar até que o problema seja resolvido. Crie políticas de monitoramento para detectar sinais de um pipeline parado, como um aumento na latência do sistema e uma diminuição na atualização de dados. Implemente a geração de registros de erros no código do pipeline para ajudar a identificar as interrupções do pipeline causadas por itens de trabalho que falham repetidamente.

Reiniciar jobs em uma zona diferente caso haja uma interrupção de zona

Depois que um job é iniciado, os workers do Dataflow que executam o código do usuário são restritos a uma única zona. Se houver uma falha temporária zonal, os jobs do Dataflow geralmente serão afetados, dependendo da extensão da falha.

Para falhas que afetam apenas back-ends do Dataflow, os back-ends são migrados automaticamente para uma zona diferente pelo serviço gerenciado para que possam continuar o job. Se o job usar o Dataflow Shuffle, o back-end não poderá ser movido entre zonas. Se ocorrer uma migração de back-end do Dataflow, os jobs poderão ser temporariamente interrompidos.

Se ocorrer uma falha temporária na zona, os jobs em execução provavelmente vão falhar ou parar até que a disponibilidade da zona seja restaurada. Se uma zona ficar indisponível por um longo período, interrompa os jobs (cancelar para jobs em lote e drenar para jobs de streaming) e, em seguida, reinicie-os para permitir que o Dataflow escolha uma nova zona íntegra.

Reiniciar jobs em lote em uma região diferente caso haja uma interrupção regional

Se ocorrer uma falha temporária regional em uma região em que os jobs do Dataflow estão em execução, eles poderão falhar ou parar. Para jobs em lote, reinicie-o em uma região diferente, se possível. É importante garantir que seus dados estejam disponíveis em diferentes regiões.

Diminuir falhas temporárias regionais usando alta disponibilidade ou failover

Para jobs de streaming, dependendo da tolerância a falhas e do orçamento do aplicativo, há opções diferentes para atenuar falhas. Para uma interrupção regional, a opção mais simples e econômica é aguardar até que a interrupção termine. No entanto, se o aplicativo for sensível à latência ou se o processamento de dados não puder ser interrompido ou precisar ser retomado com o mínimo de atraso, as seções a seguir discutirão opções.

Alta disponibilidade: sensível à latência sem perda de dados

Se o aplicativo não puder tolerar a perda de dados, execute pipelines duplicados em paralelo em duas regiões diferentes e faça com que os pipelines consumam os mesmos dados. As mesmas fontes de dados precisam estar disponíveis nas duas regiões. Os aplicativos downstream que dependem da saída desses pipelines precisam ser capazes de alternar entre a saída dessas duas regiões. Devido à duplicação de recursos, essa opção envolve o custo mais alto em comparação com outras opções. Para um exemplo de implantação, consulte a seção, Alta disponibilidade e redundância geográfica.

Failover: sensível à latência com uma possível perda de dados

Se o aplicativo puder tolerar uma possível perda de dados, disponibilize a fonte de dados de streaming em várias regiões. Por exemplo, com o Pub/Sub, mantenha duas assinaturas independentes para o mesmo tópico, uma para cada região. Se houver uma falha temporária regional, inicie um pipeline de substituição em outra região e faça com que o pipeline consuma dados da assinatura de backup.

Reproduzir novamente a assinatura de backup em um momento adequado para manter a perda de dados no mínimo sem prejudicar a latência. Os aplicativos de downstream precisam saber como mudar para a saída do pipeline em execução, semelhante à opção de alta disponibilidade. Essa opção usa menos recursos do que a execução de pipelines duplicados porque apenas os dados são duplicados.

Alta disponibilidade e redundância geográfica

É possível executar vários pipelines de streaming em paralelo para processamento de dados de alta disponibilidade. Por exemplo, é possível executar dois jobs de streaming paralelos em diferentes regiões, o que fornece redundância geográfica e tolerância a falhas para o processamento de dados.

Ao considerar a disponibilidade geográfica de fontes de dados e coletores, é possível operar pipelines completos em uma configuração multirregional altamente disponível. O diagrama a seguir mostra um exemplo de implantação.

O diagrama mostra o seguinte fluxo:

1. O Pub/Sub é executado na maioria das regiões do mundo, o que permite que o serviço ofereça acesso rápido e global a dados e que você tenha controle sobre onde as mensagens são armazenadas. O Pub/Sub pode armazenar automaticamente mensagens publicadas na região do Google Cloud mais próxima dos assinantes, ou pode ser configurado para usar uma região específica ou um conjunto de regiões usando políticas de armazenamento de mensagens.

   O Pub/Sub entrega as mensagens aos inscritos em todo o mundo, independentemente de onde as mensagens são armazenadas. Os clientes do Pub/Sub não precisam estar cientes dos locais de servidores aos quais eles estão se conectando, porque mecanismos de balanceamento de carga globais direcionam o tráfego para o data center do Google Cloud mais próximo em que as mensagens são armazenadas.

2. O Dataflow é executado em regiões específicas do Google Cloud. Ao executar pipelines paralelos em regiões separadas do Google Cloud, é possível isolar os jobs de falhas que afetam uma única região. O diagrama mostra duas instâncias do mesmo pipeline, cada uma em execução em uma região separada do Google Cloud.

3. O BigQuery fornece locais de conjuntos de dados regionais e multirregionais. Quando você escolhe um local multirregional, seu conjunto de dados fica em pelo menos duas regiões geográficas. O diagrama descreve dois pipelines separados, cada um gravando um conjunto de dados multirregional separado.