Planeje o pipeline do Dataflow

Nesta página, explicamos considerações importantes para planejar seu pipeline de dados antes de começar o desenvolvimento de código. Os pipelines de dados movem dados de um sistema para outro e geralmente são componentes essenciais de sistemas de informações comerciais. O desempenho e a confiabilidade do pipeline de dados podem afetar esses sistemas mais amplos e a eficácia com que os requisitos de negócios são atendidos.

Se você planejar seus pipelines de dados antes de desenvolvê-los, é possível melhorar o desempenho e a confiabilidade deles. Neste guia, explicamos várias considerações de planejamento para pipelines do Dataflow, incluindo:

• Expectativas de desempenho para seus pipelines, incluindo padrões de mensurabilidade
• Integração dos pipelines com fontes de dados, coletores e outros sistemas conectados
• Regionalização de pipelines, origens e coletores
• Segurança, como criptografia de dados e rede privada

Definir e medir SLOs

Uma medida importante de desempenho é o nível de desempenho do pipeline com relação aos requisitos do negócio. Os objetivos de nível de serviço (SLOs) fornecem definições tangíveis de desempenho que podem ser comparadas em limites aceitáveis. Por exemplo, você pode definir os seguintes SLOs de exemplo para seu sistema:

• Atualização de dados: gere 90% das recomendações de produtos na atividade do site do usuário que ocorreram nos últimos três minutos atrás.

• Precisão dos dados: em um mês, menos de 0,5% das faturas dos clientes devem conter erros.

• Isolamento de dados/balanceamento de carga: em um dia útil, processe todos os pagamentos de alta prioridade dentro de 10 minutos de hospedagem e conclua os pagamentos de prioridade padrão no próximo dia útil.

É possível usar indicadores de nível de serviço (SLIs) para medir a conformidade com o SLO. SLIs são métricas quantificáveis que indicam como seu sistema está atendendo a um determinado SLO. Por exemplo, é possível medir o SLO de atualização de dados de exemplo usando a data da atividade processada do usuário mais recentemente como um SLI. Se o pipeline gera recomendações de eventos de atividade do usuário e se o SLI informa um atraso de quatro minutos entre o horário do evento e o horário em que o evento é processado, as recomendações não consideram o site do usuário. atividade de 4 minutos. Se um pipeline que processa dados de streaming exceder uma latência de sistema de quatro minutos, você saberá que o SLO não foi atendido.

Como os componentes do sistema além do pipeline afetam seu SLO, é importante capturar uma variedade de SLIs que descrevam o desempenho geral do sistema além do desempenho do próprio pipeline, incluindo métricas que descrevem o integridade completa do sistema. Por exemplo, o pipeline do Dataflow pode calcular resultados com atraso aceitável, mas um problema de desempenho pode ocorrer com um sistema downstream que pode afetar SLOs mais amplos.

Para mais informações sobre SLOs importantes a serem considerados, consulte o livro Engenharia de confiabilidade do site.

Atualização de dados

Atualização de dados refere-se à usabilidade dos dados em relação à data de criação. Os seguintes SLOs de atualização de dados são mencionados no livro de Engenharia de confiabilidade do site, como os formatos de SLO mais comuns de atualização de dados de pipeline:

• X% dos dados processados em Y [segundos, dias, minutos]. Esse SLO se refere à porcentagem de dados processados em um determinado período. Ele geralmente é usado para pipelines em lote que processam fontes de dados limitadas. As métricas desse tipo de SLO são os tamanhos de dados de entrada e saída nas etapas de processamento chaves relativas ao ambiente de execução do pipeline decorrido. Você pode escolher uma etapa que leia um conjunto de dados de entrada e outra etapa que processe cada item da entrada. Um exemplo de SLO é "Para o jogo Shave the Yak, 99% das atividades do usuário que afetam as pontuações dos jogadores são contabilizadas até 30 minutos após a conclusão da partida".

• Os dados mais antigos não têm mais de X [segundos, dias, minutos]. Esse SLO se refere à idade dos dados produzidos pelo pipeline. Geralmente é usado para pipelines de streaming que processam dados de fontes ilimitadas. Para esse tipo de SLO, use métricas que indicam quanto tempo o pipeline leva para processar dados. Duas métricas possíveis são a data do item não processado mais antigo (há quanto tempo um item não processado está na fila) ou a data do item processado mais recentemente. Um exemplo de SLO é "As recomendações de produtos são geradas pela atividade do usuário com no máximo 5 minutos".

• O job do pipeline é concluído em X [segundos, dias, minutos]. Esse SLO define um prazo para a conclusão bem-sucedida e é normalmente usado em pipelines em lote que processam dados de fontes de dados limitados. Esse SLO requer o tempo total decorrido do pipeline e o status de conclusão do job, além de outros sinais que indicam o sucesso do job (por exemplo, a porcentagem de elementos processados que resultam em erros). Um exemplo de SLO é "Os pedidos dos clientes do dia útil atual são processados às 9h do dia seguinte."

Para mais informações sobre como usar o Cloud Monitoring para avaliar a atualização de dados, consulte Métricas do job do Dataflow.

Correção de dados

Correção de dados refere-se a dados sem erros. Você pode determinar a correção dos dados por diferentes meios, incluindo:

• Testes de unidade e testes de integração, que são automatizados com a integração contínua.

• Testes de pipeline completos, que podem ser executados em um ambiente de pré-produção depois que o pipeline for aprovado nos testes de unidade e de integração. É possível automatizar testes de pipelines completos usando a entrega contínua.

• Pipelines em execução na produção, quando você usa o monitoramento para observar métricas relacionadas à correção de dados.

Para executar pipelines, a definição de um destino de correção de dados geralmente envolve a avaliação da correção durante um período. Exemplo:

• Por job, menos de X% dos itens de entrada contêm erros de dados. É possível usar esse SLO para medir a correção de dados para pipelines em lote. Um exemplo de SLO pode ser "Para cada job em lote diário que processa leituras de medidores de eletricidade, menos de 3% das leituras contêm erros de entrada de dados".
• Em uma janela de movimento de X minutos, menos de Y% dos itens de entrada contêm erros de dados. É possível usar esse SLO para medir a correção de dados para pipelines de streaming. Um exemplo de SLO é "menos de 2% das leituras de medidor de eletricidade na última hora contêm valores negativos".

Para medir esses SLOs, use métricas em um período adequado para acumular o número de erros por tipo. Exemplos de tipos de erro: se os dados estiverem incorretos devido a um esquema malformado ou se estiverem fora de um intervalo válido.

Para mais informações sobre como usar o Cloud Monitoring para medir a correção de dados, consulte Métricas do job do Dataflow.

Isolamento de dados e balanceamento de carga

O isolamento de dados envolve a segmentação de dados por atributo, o que pode facilitar o balanceamento de carga. Por exemplo, em uma plataforma de processamento de pagamentos on-line, é possível segmentar os dados para que pagamentos individuais tenham prioridade padrão ou alta. O pipeline pode usar o balanceamento de carga para garantir que os pagamentos de alta prioridade sejam processados antes dos pagamentos de prioridade padrão.

Imagine que você defina estes SLOs para o processamento de pagamentos:

• Os pagamentos de alta prioridade são processados em até 10 minutos.
• Os pagamentos de prioridade padrão são processados até as 9 h do dia seguinte.

Se a plataforma de pagamento estiver em conformidade com esses SLOs, os clientes poderão ver os pagamentos de alta prioridade finais em um painel de relatórios à medida que forem concluídos. Por outro lado, os pagamentos padrão podem não aparecer no painel até o dia seguinte.

Neste cenário de exemplo, você tem as seguintes opções:

• Executar um único pipeline para processar pagamentos de prioridade padrão e de alta prioridade.
• Isolar e balancear a carga dos dados com base nas prioridades de vários pipelines.

As seções a seguir descrevem cada opção em detalhes.

Como usar um único pipeline para entregar SLOs mistos

O diagrama a seguir ilustra um único pipeline usado para processar pagamentos de alta prioridade e de prioridade padrão. O pipeline recebe notificações de novos pagamentos de uma fonte de dados de streaming, por exemplo, um tópico do Pub/Sub ou do Apache Kafka. Em seguida, ele processa imediatamente os pagamentos e grava eventos no BigQuery usando inserções de streaming.

A vantagem de um único pipeline é que ele simplifica os requisitos operacionais, porque é necessário gerenciar apenas uma única fonte de dados e um pipeline. O Dataflow usa recursos de ajuste automático para ajudar a executar seu job o mais rápido e da forma mais eficiente possível.

Uma desvantagem de um único pipeline é que o pipeline compartilhado não pode priorizar pagamentos de alta prioridade sobre os de prioridade padrão, e os recursos do pipeline são compartilhados entre os dois tipos de pagamento. No cenário de negócios descrito anteriormente, o pipeline precisa manter o mais rigoroso dos dois SLOs. Ou seja, o pipeline precisa usar o SLO para pagamentos de alta prioridade, independentemente da prioridade real dos pagamentos processados. Outra desvantagem é que, no caso de um backlog de trabalho, o pipeline de streaming não pode priorizar o processamento de backlog de acordo com a urgência do trabalho.

Como usar vários pipelines adaptados a SLOs específicos

É possível usar dois pipelines para isolar recursos e fornecer contra SLOs específicos. O diagrama a seguir ilustra essa abordagem.

Os pagamentos de alta prioridade são isolados em um pipeline de streaming para processamento priorizado. Os pagamentos de prioridade padrão são processados por um pipeline em lote executado diariamente e que usam jobs de carregamento do BigQuery para gravar resultados processados.

Isolar dados em pipelines diferentes tem vantagens. Para realizar pagamentos de alta prioridade em relação a SLOs mais rigorosos, é possível encurtar os tempos de processamento atribuindo mais recursos ao pipeline dedicado a pagamentos de alta prioridade. As configurações de recursos incluem adicionar workers do Dataflow, usar máquinas maiores e ativar o escalonamento automático. Isolar itens de alta prioridade para uma fila de processamento separada também pode atenuar os atrasos no processamento caso ocorra um fluxo repentino de pagamentos de prioridade padrão.

Quando você usa vários pipelines para isolar e balancear a carga de dados de origens de lote e streaming, o modelo de programação do Apache Beam permite que os pipelines de alta prioridade (streaming) e padrão (lote) compartilhem o mesmo código. A única exceção é a transformação de leitura inicial, que lê de uma origem limitada para o pipeline em lote. Para mais informações, consulte Criar bibliotecas de transformações reutilizáveis.

Plano para fontes de dados e coletores

Para processar dados, um pipeline de dados precisa ser integrado a outros sistemas. Esses sistemas são chamados de fontes e coletores. Os pipelines de dados leem dados de origens e gravam dados em coletores. Além de origens e coletores, os pipelines de dados podem interagir com sistemas externos para o enriquecimento e filtragem de dados ou chamar a lógica externa de negócios em uma etapa de processamento.

Para escalabilidade, o Dataflow executa os estágios do pipeline em paralelo em vários workers. Os fatores que estão fora do código do pipeline e do serviço Dataflow também afetam a escalonabilidade. Esses fatores podem incluir:

• Escalonabilidade de sistemas externos: os sistemas externos com que o pipeline interage pode restringir o desempenho e formar o limite superior de escalonabilidade. Por exemplo, um tópico do Apache Kafka configurado com um número insuficiente de partições para a capacidade de processamento necessária pode afetar o desempenho do pipeline. Para garantir que o pipeline e os componentes dele atendam às metas de desempenho, consulte a documentação de práticas recomendadas para os sistemas externos que você está usando. Você também pode simplificar o planejamento de capacidade da infraestrutura usando os serviços do Google Cloud que oferecem escalonabilidade integrada. Para mais informações, consulte Como usar origens e coletores gerenciados pelo Google Cloud nesta página.

• Escolha de formatos de dados: determinados formatos de dados podem ser lidos mais rapidamente do que outros. Por exemplo, o uso de formatos de dados compatíveis com leituras paralelas, como o Avro, geralmente é mais rápido do que o uso de arquivos CSV com novas linhas incorporadas nos campos, além de ser mais rápido do que o uso de arquivos compactados.

• Localização de dados e topologia de rede: a proximidade geográfica e as características de rede das origens e coletores de dados em relação ao pipeline de dados podem afetar o desempenho. Para mais informações, consulte Considerações regionais nesta página.

Chamadas para serviços externos

Chamar serviços externos do pipeline gera sobrecarga por chamada, o que pode diminuir o desempenho e a eficiência do pipeline. Se o pipeline de dados chamar serviços externos, para reduzir sobrecargas, agrupe vários elementos de dados em solicitações únicas sempre que possível. Muitas transformações nativas de E/S do Apache Beam executam automaticamente essa tarefa, incluindo o BigQueryIO e as operações de adição de streaming. Além dos limites de capacidade, alguns serviços externos também podem impor cotas que limitam o número total de chamadas durante um período (por exemplo, uma cota diária) ou restringir a taxa de chamadas (como o número de solicitações por segundo).

Como o Dataflow carrega o trabalho em paralelo entre vários workers, muito tráfego pode sobrecarregar um serviço externo ou esgotar as cotas disponíveis. Quando o escalonamento automático é usado, o Dataflow pode tentar compensar com a adição de workers para executar uma etapa lenta, como uma chamada externa. A adição de workers pode aumentar a pressão nos sistemas externos. Verifique se os sistemas externos oferecem suporte aos requisitos de carga previstos ou limite o tráfego do pipeline a níveis sustentáveis. Para mais informações, consulte Limitar tamanhos de lote e chamadas simultâneas a serviços externos.

Como usar fontes e coletores gerenciados do Google Cloud

O uso dos serviços gerenciados do Google Cloud com o pipeline do Dataflow elimina a complexidade do gerenciamento de capacidade ao oferecer escalonabilidade integrada, desempenho consistente, cotas e limites que atendem à maioria dos requisitos. Você ainda precisa conhecer diferentes cotas e limites para operações de pipeline. O próprio Dataflow impõe cotas e limites. Para aumentar alguns deles, entre em contato com o suporte do Google Cloud.

O Dataflow usa instâncias de VM do Compute Engine para executar seus jobs. Portanto, você precisa de uma cota do Compute Engine suficiente. A cota insuficiente do Compute Engine também pode impedir o escalonamento automático de pipeline ou impedir que os jobs sejam iniciados.

As partes restantes desta seção exploram como diferentes cotas e limites do Google Cloud podem influenciar o modo como você projeta, desenvolve e monitora o pipeline. O Pub/Sub e o BigQuery são usados como exemplos de origens e coletores de pipelines.

Exemplo 1: Pub/Sub

Quando você usa o Pub/Sub com o Dataflow, o Pub/Sub fornece um serviço de ingestão de eventos escalonável e durável para entregar mensagens dos pipelines de e para os dados de streaming. Você pode usar o console do Google Cloud para visualizar o consumo de cota do Pub/Sub e aumentar os limites de cota. Recomendamos que você solicite um aumento de cota se tiver um pipeline único que exceda as cotas e os limites por projeto.

As cotas e limites do Pub/Sub foram projetadas em torno do uso no nível do projeto. Especificamente, editores e assinantes em projetos diferentes recebem cotas de capacidade de dados independentes. Se vários pipelines publicarem ou se inscreverem em um único tópico, você poderá receber a capacidade máxima permitida nesse tópico implantando cada pipeline em seu próprio projeto. Nessa configuração, cada pipeline usa uma conta de serviço baseada em um projeto diferente para consumir e publicar mensagens.

No diagrama a seguir, o Pipeline 1 e o Pipeline 2 compartilham a mesma cota de assinante e editor disponível para o Projeto A. Por outro lado, o Pipeline 3 pode usar toda a cota de capacidade do assinante e do editor referente ao Projeto B.

Vários pipelines podem ler de um único tópico do Pub/Sub usando assinaturas separadas para o tópico, o que permite que os pipelines do Dataflow extraiam e confirmem mensagens independentemente de outros assinantes (neste caso, outros Pipeline). Isso facilita a clonagem de pipelines criando assinaturas adicionais do Pub/Sub. Criar assinaturas adicionais é útil para criar pipelines de réplica para alta disponibilidade (normalmente para casos de uso de streaming), para executar pipelines de teste adicionais nos mesmos dados e para ativar atualizações de pipeline.

Exemplo 2: BigQuery

A leitura e a gravação de dados do BigQuery são compatíveis com o SDK do Apache Beam para várias linguagens, incluindo Java, Python e Go. Quando você usa Java, a classe BigQueryIO oferece esse recurso. O BigQueryIO aceita dois métodos para ler dados: EXPORT (exportação de tabela) e DIRECT_READ. Os diferentes métodos de leitura consomem diferentes cotas do BigQuery.

A exportação da tabela é o método de leitura padrão. Ela funciona como mostrado no diagrama a seguir:

O diagrama mostra o seguinte fluxo:

1. O BigQueryIO invoca uma solicitação de exportação do BigQuery para exportar dados da tabela. Os dados da tabela exportada são gravados em um local temporário do Cloud Storage.
2. O BigQueryIO lê os dados da tabela do local temporário do Cloud Storage.

As solicitações de exportação do BigQuery são limitadas por cotas de exportação. A solicitação de exportação também precisa ser concluída para que o pipeline possa começar a processar dados, o que aumenta o tempo de execução do job.

Por outro lado, a abordagem de leitura direta usa a API BigQuery Storage para ler dados de tabela diretamente do BigQuery. A API BigQuery Storage fornece desempenho de leitura de alta capacidade para dados da linha da tabela usando gRPC. Usar a API BigQuery Storage torna a etapa de exportação desnecessária, o que evita as restrições de cota de exportação e diminui o tempo de execução do job.

Veja no diagrama a seguir o fluxo, se você usar a API BigQuery Storage. Ao contrário do fluxo que usa uma solicitação de exportação do BigQuery, esse fluxo é mais simples, porque tem apenas uma etapa de leitura direta para transferir os dados da tabela para o pipeline.

Gravar dados em tabelas do BigQuery também tem suas próprias implicações de cota. Por exemplo, os pipelines em lote que usam jobs de carregamento do BigQuery consomem diferentes cotas de jobs de carregamento do BigQuery que se aplicam no nível da tabela e do projeto. Da mesma forma, os pipelines de streaming que usam inserções de streaming do BigQuery consomem cotas de inserção de streaming do BigQuery.

Para determinar os métodos mais apropriados de leitura e gravação de dados, considere seu caso de uso. Por exemplo, evite usar jobs de carregamento do BigQuery para anexar dados milhares de vezes por dia a uma tabela. Usar um pipeline de streaming para gravar dados quase em tempo real no BigQuery. O pipeline de streaming precisa usar inserções por streaming ou a API Storage Write para essa finalidade.

Considerações regionais

O Dataflow é oferecido como um serviço gerenciado em várias regiões do Google Cloud. Ao escolher uma região para executar os jobs, considere os seguintes fatores:

• O local das fontes de dados e dos coletores
• Preferências ou restrições para locais de processamento de dados
• Recursos do Dataflow oferecidos apenas em regiões específicas
• A região usada para gerenciar a execução de um determinado job
• A zona que é usada para os workers do job

Para um determinado job, a configuração da região usada para o job e para os workers pode ser diferente. Para mais informações, como quando especificar regiões e zonas, consulte a documentação de regiões do Dataflow.

Ao especificar regiões para executar os jobs do Dataflow, é possível planejar considerações regionais para alta disponibilidade e para a recuperação de desastres. Para mais informações, consulte Alta disponibilidade e redundância geográfica.

Regiões

As regiões do Dataflow armazenam e processam metadados relacionados ao job, como informações sobre o próprio gráfico do Apache Beam, como nomes de transformação. Eles também controlam os comportamentos dos workers, como o escalonamento automático. A especificação de uma região ajuda você a atender às necessidades de segurança, conformidade, localidade de dados e posicionamento regional de um job. Para evitar o impacto no desempenho das chamadas de rede entre regiões, recomendamos que você use a mesma região para o job e para os workers sempre que possível.

Workers do Dataflow

Os jobs do Dataflow usam instâncias de VM do Compute Engine (chamadas de workers do Dataflow) para executar o pipeline. Os jobs do Dataflow podem usar qualquer zona do Compute Engine para workers, incluindo regiões onde não há locais do Dataflow. Ao especificar uma região de worker para o job, é possível controlar o posicionamento regional dos workers. Para especificar uma região ou zona de worker, faça o seguinte:

• Se você usar a CLI gcloud para criar um job de um modelo do Dataflow, use a sinalização --worker-region para substituir a região do worker ou a --worker-zone para substituir a zona do worker.
• Se você usar o SDK do Apache Beam para Java, crie regiões e zonas para workers usando opções de pipeline. Use workerRegion para modificar a região do worker ou workerZone para modificar a zona do worker.

Para melhorar a latência e a capacidade da rede, recomendamos que você crie workers em uma região geograficamente próxima das suas fontes de dados e coletores. Se você não especificar uma região ou zona para workers ao criar um job, o Dataflow usará automaticamente uma zona que esteja na mesma região do job.

Se você não usar o serviço Dataflow Shuffle ou o Streaming Engine, os dados processados pelo job (ou seja, os dados armazenados em qualquer objeto PCollection) residirão nos workers do job, supondo que nenhum código de usuário transmita dados para fora do workers. Se o serviço Dataflow Shuffle ou o Streaming Engine estiverem ativados, o conjunto de dados distribuídos representados por um objeto PCollection poderá ser transmitido entre os workers e esses serviços.

Considerações sobre criptografia de dados

Como um serviço totalmente gerenciado, o Dataflow criptografa automaticamente os dados que passam pelo pipeline de dados usando chaves de propriedade e gerenciadas pelo Google para dados em trânsito e em repouso. Em vez de usar chaves de propriedade e gerenciadas pelo Google, você pode preferir gerenciar suas próprias chaves de criptografia. Nesse caso, o Dataflow é compatível com chaves de criptografia gerenciadas pelo cliente (CMEK) usando o Cloud Key Management Service (KMS). Outra opção é usar o Cloud HSM, um serviço de módulo de segurança de hardware (HSM) hospedado na nuvem. Com ele, é possível hospedar chaves de criptografia e executar operações de criptografia em um cluster de HSMs Nível 3 de FIPS 140-2 (em inglês) certificados.

Quando você usa a CMEK, o Dataflow usa sua chave do Cloud KMS para criptografar os dados, exceto para operações baseadas em chaves de dados, como gestão de janelas, agrupamento e junção. Se as chaves de dados contiverem dados confidenciais, como informações de identificação pessoal (PII, na sigla em inglês), será preciso gerar um hash ou transformá-las antes que entrem no pipeline do Dataflow.

Considerações sobre rede privada

Os requisitos de rede e segurança podem impor que as cargas de trabalho baseadas em VM, como jobs do Dataflow, usem apenas endereços IP particulares. O Dataflow permite especificar que os workers usem endereços IP particulares em toda a comunicação de rede. Se os IPs públicos estiverem desativados, ative o Acesso privado do Google na sub-rede para que os workers do Dataflow possam acessar as APIs e os serviços do Google.

Recomendamos desativar os IPs públicos para workers do Dataflow, a menos que os jobs do Dataflow exijam IPs públicos para acessar recursos de rede fora do Google Cloud. A desativação de IPs públicos também impede que os workers do Dataflow acessem recursos que estão fora da sub-rede ou acessem redes VPC com peering. Da mesma forma, o acesso da rede a workers de VM de fora da sub-rede ou de redes VPC com peering também será bloqueado.

Para mais informações sobre como usar a opção de pipeline --usePublicIps para especificar se os workers precisam ter apenas IPs privados, consulte Opções de pipeline.

A seguir

• Desenvolva e teste o pipeline.
• Saiba mais sobre como projetar fluxos de trabalho completos do pipeline.
• Leia mais sobre as práticas de engenharia de confiabilidade do site (SRE, na sigla em inglês) para pipelines de processamento de dados.