Planeie o seu pipeline do Dataflow

Esta página explica considerações importantes para planear o 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 são frequentemente componentes críticos dos sistemas de informações empresariais. O desempenho e a fiabilidade do seu pipeline de dados podem afetar estes sistemas mais amplos e a eficácia com que os requisitos da sua empresa são cumpridos.

Se planear os pipelines de dados antes de os desenvolver, pode melhorar o respetivo desempenho e fiabilidade. Esta página explica várias considerações de planeamento para pipelines do Dataflow, incluindo:

• Expetativas de desempenho para os seus pipelines, incluindo normas de mensurabilidade
• Integração dos seus pipelines com origens de dados, destinos e outros sistemas ligados
• Regionalização de pipelines, origens e destinos
• Segurança, como encriptação de dados e redes privadas

Defina e meça SLOs

Uma medida importante do desempenho é a forma como o seu pipeline cumpre os requisitos da sua empresa. Os objetivos ao nível do serviço (SLOs) oferecem definições tangíveis de desempenho que pode comparar com limites aceitáveis. Por exemplo, pode definir os seguintes SLOs de exemplo para o seu sistema:

• Atualidade dos dados: gere 90% das recomendações de produtos a partir da atividade do utilizador no Website que ocorreu, no máximo, há 3 minutos.

• Correção dos dados: num mês civil, menos de 0,5% das faturas dos clientes contêm erros.

• Isolamento/equilíbrio de carga de dados: no prazo de um dia útil, processar todos os pagamentos de alta prioridade no prazo de 10 minutos após o registo e concluir os pagamentos de prioridade padrão até ao dia útil seguinte.

Pode usar indicadores do nível de serviço (INSs) para medir a conformidade com os SLOs. Os SLIs são métricas quantificáveis que indicam o desempenho do seu sistema em relação a um SLO específico. Por exemplo, pode medir o SLO de atualização de dados de exemplo usando a antiguidade da atividade do utilizador processada mais recentemente como um SLI. Se o seu pipeline gerar recomendações a partir de eventos de atividade do utilizador e o seu SLI comunicar um atraso de 4 minutos entre a hora do evento e a hora em que o evento é processado, as recomendações não consideram a atividade do utilizador no Website de há mais de 4 minutos. Se um pipeline que processa dados de streaming exceder uma latência do sistema de 4 minutos, sabe que o SLO não é cumprido.

Uma vez que os componentes do sistema além da sua conduta afetam o SLO, é importante capturar um intervalo de SLIs que descrevam o desempenho geral do sistema além do desempenho da própria conduta, incluindo métricas que descrevam o estado geral de ponta a ponta do seu sistema. Por exemplo, o pipeline do Dataflow pode calcular resultados com um atraso aceitável, mas pode ocorrer um problema de desempenho com um sistema a jusante que afete os SLOs mais amplos.

Para mais informações sobre os SLOs importantes a ter em conta, consulte o livro Site Reliability Engineering (Engenharia de fiabilidade do site).

Atualidade dos dados

A atualidade dos dados refere-se à usabilidade dos dados em relação à respetiva antiguidade. Os seguintes SLOs de atualidade dos dados são mencionados no livro Site Reliability Engineering como os formatos de SLO de atualidade dos dados de pipeline mais comuns:

• X% dos dados processados em Y [segundos, dias, minutos]. Este SLO refere-se à percentagem de dados processados num determinado período. É usado frequentemente para pipelines em lote que processam origens de dados limitadas. As métricas para este tipo de SLO são os tamanhos dos dados de entrada e saída em passos de processamento importantes em relação ao tempo de execução do pipeline decorrido. Pode escolher um passo que leia um conjunto de dados de entrada e outro passo que processe cada item da entrada. Um exemplo de SLO é "Para o jogo Shave the Yak, 99% das atividades dos utilizadores que afetam as pontuações dos jogadores são contabilizadas no prazo de 30 minutos após a conclusão da partida".

• Os dados mais antigos não têm mais de X [segundos, dias, minutos]. Este SLO refere-se à antiguidade dos dados produzidos pelo pipeline. É comummente usado para pipelines de streaming que processam dados de origens ilimitadas. Para este tipo de SLO, use métricas que indiquem quanto tempo a sua pipeline demora a processar dados. Duas métricas possíveis são a antiguidade do item não processado mais antigo, ou seja, há quanto tempo um item não processado está na fila, ou a antiguidade do item processado mais recentemente. Um exemplo de SLO é: "As recomendações de produtos são geradas a partir da atividade do utilizador que não tem mais de 5 minutos."

• A tarefa do pipeline é concluída com êxito no prazo de X [segundos, dias, minutos]. Este SLO define um prazo para a conclusão bem-sucedida e é usado com frequência para pipelines em lote que processam dados de origens de dados limitadas. Este SLO requer o tempo decorrido total do pipeline e o estado de conclusão da tarefa, além de outros sinais que indicam o sucesso da tarefa, como a percentagem de elementos processados que resultam em erros. Um exemplo de SLO é "As encomendas dos clientes do dia útil atual são processadas até às 9 horas do dia seguinte".

Para obter informações sobre a utilização do Cloud Monitoring para medir a atualidade dos dados, consulte o artigo Métricas de tarefas do Dataflow.

Precisão dos dados

A correção dos dados refere-se à ausência de erros nos dados. Pode determinar a correção dos dados através de diferentes meios, incluindo:

• Testes unitários e testes de integração, que pode automatizar através da integração contínua.

• Testes de pipeline completos, que pode executar num ambiente de pré-produção depois de o pipeline passar com êxito nos testes unitários e de integração. Pode automatizar testes de pipeline ponto a ponto através da entrega contínua.

• Pipelines em execução na produção, quando usa a monitorização para observar as métricas relacionadas com a correção dos dados.

Para executar pipelines, a definição de um objetivo de correção de dados envolve normalmente a medição da correção durante um período. Por exemplo:

• Por trabalho, menos de X% dos itens de entrada contêm erros de dados. Pode usar este SLO para medir a correção dos dados para pipelines em lote. Um exemplo de SLO é "Para cada tarefa de lote diária para processar leituras do contador de eletricidade, menos de 3% das leituras contêm erros de introdução de dados".
• Durante um período de X minutos, menos de Y% dos itens introduzidos contêm erros de dados. Pode usar este SLO para medir a correção dos dados para pipelines de streaming. Um exemplo de SLO é "Menos de 2% das leituras do contador de eletricidade na última hora contêm valores negativos".

Para medir estes SLOs, use métricas durante um período adequado para acumular o número de erros por tipo. Alguns exemplos de tipos de erros são os dados estarem incorretos devido a um esquema mal formatado ou os dados estarem fora de um intervalo válido.

Para informações sobre a utilização do Cloud Monitoring para medir a correção dos dados, consulte o artigo Métricas de tarefas 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 equilíbrio de carga. Por exemplo, numa plataforma de processamento de pagamentos online, pode segmentar os dados para que os pagamentos individuais sejam de prioridade padrão ou de prioridade elevada. Em seguida, o seu pipeline pode usar o equilíbrio de carga para garantir que os pagamentos de alta prioridade são processados antes dos pagamentos de prioridade padrão.

Imagine que define os seguintes SLOs para o processamento de pagamentos:

• Os pagamentos de alta prioridade são processados no prazo de 10 minutos.
• Os pagamentos de prioridade padrão são processados até às 09:00 do dia útil seguinte.

Se a plataforma de pagamentos estiver em conformidade com estes SLOs, os clientes podem ver os pagamentos de alta prioridade finalizados num painel de controlo de relatórios à medida que são concluídos. Por outro lado, os pagamentos padrão podem não aparecer no painel de controlo até ao dia seguinte.

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

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

As secções seguintes descrevem cada opção detalhadamente.

Use um único pipeline para gerar resultados em função de SLOs mistos

O diagrama seguinte ilustra um único pipeline usado para processar pagamentos de alta prioridade e de prioridade padrão. O pipeline recebe uma notificação de novos pagamentos de uma origem de dados de streaming, como um tópico do Pub/Sub ou um tópico do Apache Kafka. Em seguida, processa imediatamente os pagamentos e escreve eventos no BigQuery através de inserções por stream.

A vantagem de um único pipeline é que simplifica os seus requisitos operacionais, porque só precisa de gerir uma única origem de dados e um único pipeline. O Dataflow usa funcionalidades de ajuste automático para ajudar a executar a tarefa o mais rápido e eficientemente possível.

Uma desvantagem de um único pipeline é que o pipeline partilhado não pode priorizar pagamentos de alta prioridade em detrimento de pagamentos de prioridade padrão, e os recursos do pipeline são partilhados entre ambos os tipos de pagamento. No cenário empresarial descrito anteriormente, a sua pipeline tem de manter o SLO mais rigoroso dos dois. Ou seja, o pipeline tem de usar o SLO para pagamentos de alta prioridade, independentemente da prioridade real dos pagamentos processados. Outra desvantagem é que, no caso de um atraso no trabalho, o pipeline de streaming não consegue dar prioridade ao processamento do atraso de acordo com a urgência do trabalho.

Use vários pipelines personalizados para SLOs específicos

Pode usar dois pipelines para isolar recursos e fornecer em função de SLOs específicos. O diagrama seguinte ilustra esta abordagem.

Os pagamentos de alta prioridade são isolados numa pipeline de streaming para processamento prioritário. Os pagamentos de prioridade padrão são processados por um pipeline em lote executado diariamente e que usa tarefas de carregamento do BigQuery para escrever os resultados processados.

Isolar os dados em diferentes pipelines tem vantagens. Para fornecer pagamentos de alta prioridade em função de SLOs mais rigorosos, pode reduzir os tempos de processamento atribuindo mais recursos ao pipeline dedicado a pagamentos de alta prioridade. As configurações de recursos incluem a adição de trabalhadores do Dataflow, a utilização de máquinas maiores e a ativação do dimensionamento automático. Isolar itens de alta prioridade numa fila de processamento separada também pode mitigar os atrasos no processamento se ocorrer um afluxo repentino de pagamentos de prioridade padrão.

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

Planeie origens e destinos de dados

Para processar dados, um pipeline de dados tem de ser integrado com outros sistemas. Esses sistemas são denominados origens e destinos. Os data pipelines leem dados de origens e escrevem dados em destinos. Além das origens e dos destinos, os pipelines de dados podem interagir com sistemas externos para enriquecimento, filtragem ou chamada de lógica empresarial externa num passo de processamento.

Para garantir a escalabilidade, o Dataflow executa as fases do pipeline em paralelo em vários trabalhadores. Os fatores que estão fora do código do pipeline e do serviço Dataflow também afetam a escalabilidade do pipeline. Estes fatores podem incluir o seguinte:

• Escalabilidade de sistemas externos: os sistemas externos com os quais o seu pipeline interage podem restringir o desempenho e podem formar o limite superior da escalabilidade. Por exemplo, um tópico do Apache Kafka configurado com um número insuficiente de partições para a taxa de transferência de leitura de que precisa pode afetar o desempenho do seu pipeline. Para ajudar a garantir que o pipeline e os respetivos componentes cumprem os seus objetivos de desempenho, consulte a documentação de práticas recomendadas para os sistemas externos que está a usar. Também pode simplificar o planeamento da capacidade da infraestrutura usando serviços da Google Cloud Platform que oferecem escalabilidade integrada. Para mais informações, consulte a secção Usar origens e destinos geridos da Google Cloud Platform nesta página.

• Escolha de formatos de dados: determinados formatos de dados podem ser mais rápidos de ler do que outros. Por exemplo, a utilização de formatos de dados que suportam leituras paralelizadas, como o Avro, é normalmente mais rápida do que a utilização de ficheiros CSV que têm novas linhas incorporadas em campos e é mais rápida do que a utilização de ficheiros comprimidos.

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

Chamadas de serviços externos

Chamar serviços externos a partir do seu pipeline incorre em custos gerais por chamada que podem diminuir o desempenho e a eficiência do seu pipeline. Se o seu pipeline de dados chamar serviços externos, para reduzir os custos gerais, agrupe vários elementos de dados em pedidos únicos sempre que possível. Muitas transformações de E/S do Apache Beam nativas realizam automaticamente esta tarefa, incluindo BigQueryIO e operações de inserção de streaming. Além dos limites de capacidade, alguns serviços externos também aplicam quotas que limitam o número total de chamadas durante um período, como uma quota diária, ou restringem a taxa de chamadas, como o número de pedidos por segundo.

Uma vez que o Dataflow paraleliza o trabalho em vários trabalhadores, o tráfego excessivo pode sobrecarregar um serviço externo ou esgotar as quotas disponíveis. Quando a escalabilidade automática é usada, o Dataflow pode tentar compensar adicionando trabalhadores para executar um passo lento, como uma chamada externa. A adição de trabalhadores pode exercer mais pressão sobre os sistemas externos. Certifique-se de que os sistemas externos podem suportar os requisitos de carga previstos ou limite o tráfego do seu pipeline a níveis sustentáveis. Para mais informações, consulte o artigo Limite os tamanhos dos lotes e as chamadas simultâneas para serviços externos.

Use Google Cloud origens e destinos geridos

A utilização de Google Cloud serviços geridos com o pipeline do Dataflow remove a complexidade da gestão da capacidade, oferecendo escalabilidade integrada, um desempenho consistente e quotas e limites que se adequam à maioria dos requisitos. Continua a ter de ter em atenção as diferentes quotas e limites para operações de pipeline. O Dataflow impõe quotas e limites. Pode aumentar alguns destes limites contactando o Google Cloud apoio técnico.

O Dataflow usa instâncias de VM do Compute Engine para executar as suas tarefas, pelo que precisa de uma quota do Compute Engine suficiente. A quota insuficiente do Compute Engine pode dificultar o dimensionamento automático do pipeline ou impedir o início de tarefas.

As restantes partes desta secção exploram como as diferentes Google Cloud quotas e limites podem influenciar a forma como cria, desenvolve e monitoriza o seu pipeline. O Pub/Sub e o BigQuery são usados como exemplos de origens e destinos de pipelines.

Exemplo 1: Pub/Sub

Quando usa o Pub/Sub com o Dataflow, o Pub/Sub fornece um serviço de carregamento de eventos escalável e duradouro para enviar e receber mensagens dos seus pipelines de dados de streaming. Pode usar a Google Cloud consola para ver o consumo da quota do Pub/Sub e aumentar os limites da quota. Recomendamos que peça um aumento da quota se tiver um único pipeline que exceda as quotas e os limites por projeto.

As quotas e os limites do Pub/Sub são concebidos em torno da utilização ao nível do projeto. Especificamente, os publicadores e os subscritores em projetos diferentes recebem quotas de débito de dados independentes. Se vários pipelines publicarem ou subscreverem um único tópico, pode obter o débito máximo permitido nesse tópico implementando cada pipeline no seu próprio projeto. Nesta configuração, cada pipeline usa uma conta de serviço baseada em projetos diferente para consumir e publicar mensagens.

No diagrama seguinte, o Pipeline 1 e o Pipeline 2 partilham a mesma quota de débito de subscritores e publicadores disponível para o Project A. Em contrapartida, o Pipeline 3 pode usar toda a quota de débito de subscritores e publicadores associada ao Projeto B.

Vários pipelines podem ler a partir de um único tópico do Pub/Sub através de subscrições separadas do tópico, o que permite que os pipelines do Dataflow extraiam e confirmem mensagens independentemente de outros subscritores, como outros pipelines. Esta funcionalidade facilita a clonagem de pipelines através da criação de subscrições do Pub/Sub adicionais. A criação de subscrições adicionais é útil para criar pipelines de réplica para alta disponibilidade (normalmente para exemplos de utilização de streaming), para executar pipelines de teste adicionais em relação aos mesmos dados e para ativar atualizações de pipelines.

Exemplo 2: BigQuery

A leitura e a escrita de dados do BigQuery são suportadas pelo SDK do Apache Beam para vários idiomas, incluindo Java, Python e Go. Quando usa Java, a classe BigQueryIO oferece esta funcionalidade. O BigQueryIO suporta dois métodos para ler dados: EXPORT (exportação de tabelas) e DIRECT_READ. Os diferentes métodos de leitura consomem quotas diferentes do BigQuery.

A exportação de tabelas é o método de leitura predefinido. Funciona conforme mostrado no seguinte diagrama:

O diagrama mostra o seguinte fluxo:

1. O BigQueryIO invoca um pedido de exportação do BigQuery para exportar dados de tabelas. Os dados das tabelas exportadas são escritos numa localização temporária do Google Cloud Storage.
2. O BigQueryIO lê os dados da tabela da localização temporária do Cloud Storage.

Os pedidos de exportação do BigQuery estão limitados por quotas de exportação. O pedido de exportação também tem de ser concluído antes de o pipeline poder começar a processar dados, o que adiciona tempo de execução adicional à tarefa.

Por outro lado, a abordagem de leitura direta usa a API BigQuery Storage para ler dados de tabelas diretamente do BigQuery. A API BigQuery Storage oferece um desempenho de leitura de elevado débito para dados de linhas de tabelas através do gRPC. A utilização da API BigQuery Storage torna o passo de exportação desnecessário, o que evita restrições de quota de exportação e diminui potencialmente o tempo de execução da tarefa.

O diagrama seguinte mostra o fluxo se usar a API BigQuery Storage. Ao contrário do fluxo que usa um pedido de exportação do BigQuery, este fluxo é mais simples, porque tem apenas um passo de leitura direta para obter os dados da tabela para o pipeline.

A gravação de dados em tabelas do BigQuery também tem as suas próprias implicações de quota. Os pipelines em lote que usam tarefas de carregamento do BigQuery consomem diferentes quotas de tarefas de carregamento do BigQuery que se aplicam ao nível da tabela e do projeto. Da mesma forma, os pipelines de streaming que usam inserções por streaming do BigQuery consomem quotas de inserção por streaming do BigQuery.

Para determinar os métodos mais adequados para ler e escrever dados, considere o seu exemplo de utilização. Por exemplo, evite usar tarefas de carregamento do BigQuery para acrescentar dados milhares de vezes por dia a uma tabela. Use um pipeline de streaming para escrever dados quase em tempo real no BigQuery. O seu pipeline de streaming deve usar inserções de streaming ou a API Storage Write para este fim.

Considerações regionais

O Dataflow é oferecido como um serviço gerido em várias Google Cloud regiões. Quando escolher uma região para usar na execução dos seus trabalhos, considere os seguintes fatores:

• A localização das origens e dos destinos de dados
• Preferências ou restrições nas localizações de tratamento de dados
• Funcionalidades do fluxo de dados oferecidas apenas em regiões específicas
• A região usada para gerir a execução de uma determinada tarefa
• A zona usada para os trabalhadores da tarefa

Para um determinado trabalho, a definição de região que usa para o trabalho e para os trabalhadores pode ser diferente. Para mais informações, incluindo quando especificar regiões e zonas, consulte a documentação sobre as regiões do Dataflow.

Ao especificar regiões para executar as suas tarefas do Dataflow, pode planear em função de considerações regionais para alta disponibilidade e recuperação de desastres. Para mais informações, consulte o artigo Disponibilidade elevada e redundância geográfica.

Regiões

As regiões do Dataflow armazenam e processam metadados relacionados com a sua tarefa, como informações sobre o próprio gráfico do Apache Beam, como os nomes de transformação. Também controlam os comportamentos dos trabalhadores, como o ajuste de escala automático. A especificação de uma região ajuda a satisfazer as suas necessidades de segurança e conformidade, localidade dos dados e posicionamento regional de um trabalho. Para evitar o impacto no desempenho das chamadas de rede entre regiões, recomendamos que use a mesma região para a tarefa e para os trabalhadores, sempre que possível.

Workers do Dataflow

As tarefas do Dataflow usam instâncias de VM do Compute Engine, denominadas trabalhadores do Dataflow, para executar o seu pipeline. As tarefas do Dataflow podem usar qualquer zona do Compute Engine para trabalhadores, incluindo regiões onde não existem localizações do Dataflow. Ao especificar uma região de trabalhadores para o seu trabalho, pode controlar o posicionamento regional dos seus trabalhadores. Para especificar uma região ou uma zona de trabalhadores, faça o seguinte:

• Se usar a CLI gcloud para criar uma tarefa a partir de um modelo do Dataflow, use a flag --worker-region para substituir a região do trabalhador ou use a flag --worker-zone para substituir a zona do trabalhador.
• Se usar o SDK Java do Apache Beam para criar a sua tarefa, defina regiões e zonas para os trabalhadores através de opções de pipeline. Use workerRegion para substituir a região do trabalhador ou workerZone para substituir a zona do trabalhador.

Para melhorar a latência e o débito da rede, recomendamos que crie trabalhadores numa região geograficamente próxima das suas origens e destinos de dados. Se não especificar uma região ou uma zona para os trabalhadores quando cria uma tarefa, o Dataflow usa por predefinição uma zona que está na mesma região que a tarefa.

Se não usar o serviço Dataflow Shuffle ou o Streaming Engine, os dados processados pela tarefa (ou seja, os dados armazenados em qualquer objeto PCollection) residem nos trabalhadores da tarefa, partindo do princípio de que nenhum código de utilizador transmite dados fora dos trabalhadores. Se o serviço Dataflow Shuffle ou o Streaming Engine estiver ativado, o conjunto de dados distribuído representado por um objeto PCollection pode ser transmitido entre os trabalhadores e estes serviços.

Considerações sobre a encriptação de dados

Como um serviço totalmente gerido, o Dataflow encripta automaticamente os dados que se movem através do seu pipeline de dados usando Google-owned and Google-managed encryption keys para os dados em trânsito e os dados em repouso. Em vez de usar Google-owned and Google-managed encryption keys, pode preferir gerir as suas próprias chaves de encriptação. Nesse caso, o Dataflow suporta chaves de encriptação geridas pelo cliente (CMEK) através do Cloud Key Management Service (KMS). Também pode usar o Cloud HSM, um serviço de módulo de segurança de hardware (HSM) alojado na nuvem que lhe permite alojar chaves de encriptação e realizar operações criptográficas num cluster de HSMs certificados de Nível 3 da FIPS 140-2.

Quando usa CMEK, o Dataflow usa a sua chave do Cloud KMS para encriptar os dados, exceto para operações baseadas em chaves de dados, como janelas, agrupamentos e junções. Se as chaves de dados contiverem dados confidenciais, como informações de identificação pessoal (IIP), tem de aplicar hash ou transformar as chaves antes de entrarem no pipeline do Dataflow.

Considerações sobre redes privadas

Os seus requisitos de rede e segurança podem exigir que as cargas de trabalho baseadas em VMs, como as tarefas do Dataflow, usem apenas endereços IP privados. O Dataflow permite-lhe especificar que os trabalhadores usam endereços IP privados para todas as comunicações de rede. Se os IPs públicos estiverem desativados, tem de ativar o acesso privado à Google na sub-rede para que os trabalhadores do Dataflow possam alcançar as APIs e os serviços Google.

Recomendamos que desative os IPs públicos para os trabalhadores do Dataflow, a menos que as suas tarefas do Dataflow exijam IPs públicos para aceder a recursos de rede fora da Google Cloud Platform. A desativação dos IPs públicos impede que os trabalhadores do Dataflow acedam a recursos que estão fora da sub-rede ou que acedam a redes VPC de pares. Da mesma forma, o acesso à rede dos trabalhadores de VMs a partir de fora da sub-rede ou das redes de VPCs pares é impedido.

Para mais informações sobre a utilização da opção de pipeline --usePublicIps para especificar se os trabalhadores devem ter apenas IPs privados, consulte Opções de pipeline.

O que se segue?

• Desenvolva e teste o seu pipeline.
• Saiba como criar fluxos de trabalho de pipeline completos.
• Leia mais acerca das práticas de engenharia de fiabilidade do site (SRE) da Google para pipelines de tratamento de dados.