Google PDE: Processamento de Streams com Dataflow e Apache Beam — Guia de estudos

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

Faz parte do Google Professional Data Engineer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O processamento de stream no Google Cloud se concentra no modelo de programação unificado do Apache Beam, executado pelo runner do Dataflow. O Beam fornece uma abstração lógica — pipelines de transformações sobre PCollections — que desacopla seu código de detalhes de execução como paralelismo, autoescalonamento e tolerância a falhas. Em streaming, a corretude depende da semântica de tempo (tempo do evento vs. tempo de processamento), janelamento (fixo, deslizante, de sessão, global), marcas d’água (watermarks), gatilhos (triggers) e tratamento de dados tardios. A excelência operacional no Dataflow exige o dimensionamento correto dos workers, política de autoescalonamento, streaming engine, escolhas de shuffle, design de sink idempotente, tratamento de dead-letter e observabilidade robusta.

Modelo Apache Beam e semântica de tempo

• Pipelines, transformações, PCollections, runners:

  • Um pipeline do Beam aplica um grafo acíclico direcionado de PTransforms a PCollections (limitadas ou ilimitadas).
  • Runners (Dataflow, Spark, Flink, Direct) executam o pipeline; o Dataflow oferece autoescalonamento gerenciado, checkpointing e visibilidade operacional.
  • As transformações incluem operações por elemento (ParDo), agrupamento e combinação (GroupByKey, Combine), junções (CoGroupByKey) e I/Os (PubSubIO, BigQueryIO, FileIO).

• Janelas (Windows):

  • Janelas fixas (Fixed windows): fatias de tempo que não se sobrepõem (ex: janelas de 1 minuto) para agregações periódicas.
  • Janelas deslizantes (Sliding windows): janelas que se sobrepõem para métricas contínuas (ex: janelas de 5 minutos deslizando a cada 1 minuto).
  • Janelas de sessão (Session windows): janelas dinâmicas que se fecham após um intervalo de inatividade, ideais para sessões de usuário ou picos de atividade de dispositivos.
  • Janela global (Global window): a visão padrão sem janelas de todo o stream ilimitado; frequentemente usada em conjunto com gatilhos para materialização periódica.

• Tempo do evento vs. tempo de processamento:

  • Tempo do evento (Event time): quando o evento ocorreu na origem; permite agregações logicamente consistentes apesar de latências de transporte variáveis.
  • Tempo de processamento (Processing time): quando o evento é observado pelo pipeline; útil para gatilhos operacionais, mas não para a corretude semântica.

• Marcas d’água (Watermarks):

  • Uma marca d’água estima a completude do tempo do evento (a suposição do runner de que ele já viu todos os eventos até um tempo T).
  • As marcas d’água podem avançar irregularmente ou parar sob backpressure ou atrasos na origem; dados tardios são quaisquer dados que chegam com um timestamp < marca d’água.

• Gatilhos (Triggers) e dados tardios (lateness):

  • Padrão: gatilho AfterWatermark que dispara quando a marca d’água ultrapassa o final da janela; com latência permitida (allowed lateness) = 0, dados tardios são descartados.
  • Disparos antecipados (baseados em tempo de processamento ou contagem) fornecem resultados preliminares de baixa latência.
  • Disparos tardios permitem correções quando dados tardios chegam; o modo de acumulação (accumulation mode) define se os panes acumulam resultados ou descartam saídas anteriores.
  • Escolha a latência permitida com base na tolerância do negócio e nos trade-offs de armazenamento/computação; mais latência aumenta a retenção de estado e o custo.

• Processamento com estado (stateful), timers, sessãonização, deduplicação:

  • DoFns com estado (Stateful DoFns) mantêm um estado por chave (ex: último evento visto, agregações contínuas) e definem timers para emitir ou limpar o estado.
  • A sessãonização é expressa naturalmente através de SessionWindows; para lógica customizada, use estado por chave (keyed state) e timers de tempo de processamento/evento.
  • Deduplicação: use um ID estável por evento e aplique Distinct/Combine por janela, ou use estado por chave (ex: filtro de Bloom ou um conjunto com TTL). Avalie o trade-off entre memória e falsos positivos versus precisão estrita.

Modos de falha e trade-offs:

• Usar janelas de tempo de processamento para métricas de negócio causa desvios (drift) sob picos de carga ou novas tentativas; prefira janelas de tempo do evento.
• Janelas muito pequenas com gatilhos antecipados frequentes causam emissões excessivas de panes e amplificação de escrita no sink.
• Latência permitida ilimitada pode inflar o estado; sempre limite o TTL do estado e configure timers para limpar chaves inativas.

Implantação, templates e estratégias de upgrade

• Flex Templates:

  • Empacote pipelines em templates conteinerizados e parametrizados para implantações reprodutíveis. Os Flex Templates suportam dependências personalizadas, imagens de GPU e isolamento de ambiente.
  • Externalize parâmetros de tempo de execução (ex: assinatura de entrada, tabela de saída, sink de dead-letter, maxWorkers) para permitir implantações específicas de cada ambiente.

• Atualizações e compatibilidade de pipelines:

  • O Dataflow suporta atualização in-place para muitos pipelines de streaming se os nomes das transformações, especificações de estado e tipos de saída permanecerem compatíveis. Use nomes de PTransform estáveis.
  • Para alterações incompatíveis de grafo ou estado, realize uma transição controlada: inicie o novo job, depois drene o job antigo para finalizar o trabalho em andamento e parar de ler novos elementos.

• Drenagem e snapshots:

  • A drenagem (drain) conclui o processamento de forma gradual, escreve a saída restante e termina; coordene com a retenção do Pub/Sub ou snapshots para evitar lacunas.
  • Para garantir a continuidade, você pode criar um snapshot do Pub/Sub, iniciar o novo pipeline buscando a partir do snapshot ou de um timestamp apropriado, verificar a saída e, em seguida, drenar o job antigo.

• Exemplos de configuração:

  • Exemplo de janelamento com gatilhos antecipados/tardios e acumulação:

undefined

• Exemplo de BigQueryIO com a Storage Write API:

undefined

• Armadilhas comuns:
  • Escrever em sinks baseados em arquivo em streaming sem escritas em janela pode paralisar a finalização; habilite escritas em janela e gatilhos.
  • Crescimento Ilimitado: esquecer de limitar o estado ou o atraso permitido pode causar vazamentos de memória e falhas de escalonamento.
  • Timestamps ausentes: não atribuir timestamps de evento faz com que o pipeline use o tempo de processamento como padrão e perca a corretude sob atrasos variáveis.

Cenário de Problema Prático

A NovaTrack Inc. ingere telemetria de IoT global de 50.000 sensores de temperatura e deve fornecer agregados em nível de minuto, persistir dados brutos e alimentar um dashboard em tempo real. Mensagens malformadas ocasionais e entrega fora de ordem são esperadas. A solução deve escalar automaticamente, expor registros inválidos para inspeção e suportar upgrades sem tempo de inatividade.

Abordagem:

1. Ingestão e semântica de tempo

   • Crie um tópico regional do Pub/Sub e publicadores por região com os atributos deviceId e eventTs (RFC3339). Habilite chaves de ordenação por deviceId quando viável.
   • Justificativa: O Pub/Sub fornece uma entrada durável e elástica com entrega pelo menos uma vez (at-least-once). Anexar timestamps de evento na borda preserva o tempo real do evento; a ordenação por dispositivo reduz a reordenação intra-dispositivo sem gargalos centrais.

2. Pipeline de streaming do Dataflow com janelas de tempo de evento

   • Leia de uma assinatura dedicada via PubSubIO, extraindo eventTs como o timestamp do Beam, recorrendo a publishTime se ausente.
   • Aplique FixedWindows de 1 minuto com um gatilho antecipado aos 30 segundos e disparos tardios para cada elemento atrasado; defina o atraso permitido (allowed lateness) para 10 minutos e painéis acumulativos (accumulating panes).
   • Justificativa: Janelas de tempo de evento garantem agregados de minuto precisos; disparos antecipados alimentam o dashboard com dados atualizados em menos de um minuto; disparos tardios corrigem os agregados à medida que dados atrasados chegam. O limite de atraso limita o tamanho do estado e o custo.

3. Validação, enriquecimento e roteamento para dead-letter

   • Implemente um ParDo que analisa JSON, valida esquema e intervalos, e enriquece com pequenos dados de referência estáticos por meio de um side input carregado do BigQuery no início do job.
   • Use TupleTags para emitir registros válidos para a saída principal e falhas para uma PCollection de dead-letter contendo o payload, erro, deviceId e timestamp de análise; escreva a DLQ em uma tabela particionada do BigQuery.
   • Justificativa: Side inputs mantêm os dados de referência em memória para baixa latência. A captura de dead-letter permite a inspeção e o reprocessamento direcionado de linhas inválidas sem bloquear o fluxo principal.

4. Agregação e mitigação de hot-key

   • Agrupe por deviceId e calcule a média/mín/máx por minuto com CombineFns. Para métricas regionais de top-N, fragmente por região#N para evitar hot keys e, em seguida, reagregue.
   • Justificativa: Combiners minimizam o volume e o custo do shuffle; o particionamento de chaves (key sharding) evita gargalos de chave única durante o fan-in regional.

5. Sinks e efeitos exactly-once

   • Escreva eventos brutos validados e agregados de minuto no BigQuery usando BigQueryIO com a Storage Write API. Defina um insert id estável baseado em deviceId + eventTs para idempotência em quaisquer novas tentativas personalizadas.
   • Justificativa: A Storage Write API fornece ingestão de alta taxa de transferência e baixa latência com semântica exactly-once dentro de um stream. IDs estáveis garantem a deduplicação downstream se ocorrerem repetições.

6. Estratégia de consistência do dashboard

   • O dashboard consulta tabelas de agregados particionadas com uma retrospectiva de 2 minutos em relação à marca d’água (watermark) ou um atraso fixo de 2x a latência de disponibilidade observada para dados de streaming.
   • Justificativa: A visibilidade de streaming do BigQuery é eventualmente consistente; adiar ligeiramente as leituras evita a perda de linhas em trânsito, mantendo um comportamento quase em tempo real.

7. Operações: autoescalonamento e streaming engine

   • Habilite o Streaming Engine; defina maxWorkers com base no pico esperado (ex: 3x a média), selecione um tipo de máquina dimensionado para a análise e criptografia que consomem CPU, e aumente o disco de inicialização para acomodar o shuffle transiente.
   • Monitore o atraso da marca d’água (watermark lag), segundos de backlog, CPU e taxa de transferência por etapa; alerte sobre atrasos sustentados e picos na taxa de DLQ.
   • Justificativa: O Streaming Engine externaliza o estado/shuffle para elasticidade e upgrades mais simples; o dimensionamento correto e o monitoramento evitam violações silenciosas de SLO.

8. Implantação e upgrades com Flex Templates

   • Empacote o pipeline como um Flex Template com parâmetros: assinatura de entrada, tabelas de saída, tabela de DLQ, maxWorkers e região. Para uma alteração incompatível, inicie o novo pipeline visando o mesmo tópico com uma nova assinatura, verifique as saídas e, em seguida, drene o job antigo. Opcionalmente, crie um snapshot do Pub/Sub e faça com que a nova assinatura busque a partir do snapshot para garantir que não haja lacunas.
   • Justificativa: Flex Templates permitem implantações repetíveis e parametrizadas. Uma transição blue/green verificada com drenagem alcança perda zero de dados e tempo de inatividade mínimo.

9. Reprocessamento e backfills em lote

   • Armazene arquivos Avro compactados de eventos brutos no Cloud Storage por meio de uma saída secundária (side output); execute um pipeline de Dataflow em lote para fazer backfill ou reprocessar para o BigQuery quando modelos ou esquemas mudarem.
   • Justificativa: Arquivos brutos duráveis suportam a reprodutibilidade e a evolução do esquema sem impactar o caminho principal (hot path).

Este design produz agregados corretos e de baixa latência com custo limitado, isolamento claro de erros, forte observabilidade e caminhos de upgrade seguros, ao mesmo tempo em que lida com dados fora de ordem e atrasados em escala global.

← Analytics com BigQuery e Engenharia de Data Warehouse · Todos os domínios · Mensageria →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Google →