A região do Dataflow armazena e processa metadados sobre o job do Dataflow e implanta e controla os workers do Dataflow.
Os nomes das regiões seguem uma convenção padrão com base nos nomes das regiões do Compute Engine.
Por exemplo, o nome da região central dos EUA é us-central1.
Esse recurso está disponível em todas as regiões em que o Dataflow é compatível. Para ver os territórios disponíveis, consulte Locais do Dataflow.
Diretrizes para escolher uma região
Use as diretrizes a seguir para escolher uma região adequada para seu job.
Segurança e compliance
Talvez seja necessário restringir o processamento de jobs do Dataflow a uma região geográfica específica devido às necessidades de segurança e conformidade do seu projeto.
Localidade dos dados
Minimize os custos de latência de rede e de transporte de rede executando um job do Dataflow na mesma região que suas fontes, coletores, locais de arquivos de preparo e de arquivos temporários. Se você usar fontes, coletores, locais de arquivos de preparo ou de arquivos temporários localizados fora da região do job, seus dados poderão ser enviados entre regiões.
Na execução de um pipeline, os dados do usuário são manipulados apenas pelo pool de workers do Dataflow, e a movimentação dos dados é restrita aos caminhos de rede que conectam os workers do Dataflow no pool.
Embora os dados do usuário sejam processados com rigor pelos workers do Dataflow na respectiva região geográfica atribuída, as mensagens de registro do pipeline são armazenadas no Cloud Logging, que tem uma única presença global no Google Cloud.
Se você precisar de mais controle sobre o local das mensagens de registro do pipeline, faça o seguinte:
- Crie um filtro de exclusão
para o coletor do roteador de registros
_Defaultpara impedir que os registros do Dataflow sejam exportados para o bucket de registro_Default. - Crie um bucket de registros na região da sua escolha.
- Configure um novo coletor do roteador de registros que exporte os registros do Dataflow para o novo bucket de registros.
Para saber mais sobre como configurar a geração de registros, consulte Visão geral do roteamento e armazenamento e Visão geral do roteamento de registros.
Observações sobre fontes comuns de jobs no Dataflow:
- Ao usar um bucket do Cloud Storage como origem, recomendamos executar operações de leitura na mesma região do bucket.
- Os tópicos do Pub/Sub, quando publicados no endpoint global do Pub/Sub, são armazenados na região do Google Cloud mais próxima. No entanto, é possível modificar a política de armazenamento de tópicos para uma região específica ou um conjunto de regiões. Da mesma forma, os tópicos do Pub/Sub Lite são compatíveis apenas com armazenamento zonal.
Resiliência e separação geográfica
Isole suas operações normais do Dataflow de interrupções que poderiam ocorrer em outras regiões geográficas ou planeje sites alternativos para a continuidade do negócio em caso de um desastre em escala regional.
Nos seus planos de continuidade de negócios e recuperação de desastres, recomendamos incorporar detalhes das fontes e dos coletores usados com seus jobs do Dataflow. A equipe de vendas do Google Cloud pode ajudar você a atender a esses requisitos.
Posicionamento regional
Por padrão, a região selecionada configura o pool de workers do Dataflow para utilizar todas as zonas disponíveis na região. A seleção de zona é calculada para cada worker no momento da criação, otimizando a aquisição de recursos e a utilização de reservas não usadas.
O posicionamento regional oferece benefícios como:
- Disponibilidade de recursos aprimorada: os jobs do Dataflow são mais resilientes a erros de disponibilidade de recursos zonais, porque os workers podem continuar a ser criados em outras zonas com disponibilidade restante.
- Maior confiabilidade: em caso de falha na zona, os jobs do Dataflow podem continuar em execução, porque os workers são recriados em outras zonas.
Considere as seguintes limitações:
- O posicionamento regional oferece suporte apenas para jobs que usam o Streaming Engine ou o Dataflow Shuffle. Os jobs que desativaram o Streaming Engine ou o Dataflow Shuffle não podem usar o posicionamento regional.
- O posicionamento regional se aplica apenas a VMs, e não aos recursos de back-end.
- As VMs não são replicadas em várias zonas. Se uma VM ficar indisponível, por exemplo, os itens de trabalho dela serão considerados perdidos e serão reprocessados por outra VM.
- Se ocorrer um esgotamento em toda a região, o serviço do Dataflow não poderá criar mais VMs.
Conferir zonas de recursos de jobs
Os jobs do Dataflow dependem de recursos internos. Alguns desses recursos de job de back-end são zonais. Se uma única zona falhar e um recurso zonal necessário para o job do Dataflow estiver nessa zona, o job poderá falhar.
Para entender se um job falhou devido a uma falha zonal, analise as zonas de serviço que os recursos de back-end do job estão usando. Este recurso só está disponível para jobs do Streaming Engine.
Para conferir as zonas de serviço no console do Google Cloud, use o campo Zonas de serviço no painel Informações do job.
Para usar a API e analisar as zonas de serviço, use o campo
ServiceResources.
Os valores nesse campo são atualizados durante a duração do job, porque os recursos usados mudam enquanto ele é executado.
Posicionamento de zona automático
Para jobs não compatíveis com posicionamento regional, a melhor zona na região é selecionada automaticamente, com base na capacidade de zona disponível no momento da solicitação de criação do job. A seleção automática de zonas ajuda a garantir que os workers do job sejam executados na melhor zona para o job.
Como o job está configurado para ser executado em uma única zona, a operação poderá falhar com um erro de disponibilidade de recursos zonais se não houver recursos suficientes do Compute Engine.
Além disso, quando uma zona não está disponível, o back-end de streaming também pode ficar indisponível, o que pode resultar em perda de dados.
Especifique uma Região
Para especificar uma região para o job, defina a opção --region como uma das regiões compatíveis.
A opção --region substitui a região padrão definida no servidor de metadados, no cliente local ou nas variáveis de ambiente.
A interface de linha de comando do Dataflow também é compatível com a opção --region para especificar regiões.
Substituir a região ou a zona do worker
Por padrão, quando você envia um job com a opção --region, os workers são atribuídos automaticamente a zonas na região ou à única melhor zona na região, dependendo do tipo de job.
Nos casos em que você quer garantir que os workers do seu job do Dataflow sejam executados estritamente em uma zona específica, especifique a zona usando a opção de pipeline a seguir. Esse padrão de uso é incomum para jobs do Dataflow.
Essa opção controla apenas a zona usada pelos workers do Dataflow. Ele não se aplica a recursos de back-end. Os recursos de back-end podem ser criados em qualquer zona na região do job.
Java
--workerZone
Python
--worker_zone
Go
--worker_zone
Em todos os outros casos, não recomendamos substituir o local do worker. A tabela de cenários comuns contém recomendações de uso para essas situações.
Como o job está configurado para ser executado em uma única zona, a operação poderá falhar com um erro de disponibilidade de recursos zonais se não houver recursos suficientes do Compute Engine.
Execute o comando gcloud compute regions list para ver uma lista de
regiões e zonas disponíveis para implantação do worker.
Cenários comuns
A tabela a seguir contém recomendações de uso para cenários comuns.
| Cenário | Recomendação |
|---|---|
| Quero usar uma região compatível e não tenho preferência de zona nela. Nesse caso, a melhor zona é selecionada automaticamente com base na capacidade disponível. | Use --region para especificar uma região do job.
Isso garante que o Dataflow gerencie seu job e processe os dados na região especificada. |
| Preciso que o processamento do worker ocorra em uma zona específica de uma região. | Especifique as duas regiões --region e umas destas zonas: --workerZone ou --worker_zone.Use |