Google PDE: Orquestração de Workflows e Automação de Pipelines — 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.

Confiabilidade, Tratamento de Falhas e Idempotência

Retentativas, timeouts e backoff

Use backoff exponencial limitado para falhas transitórias e limite as janelas totais de retentativa ao SLA do job. Por exemplo, um frontend ou uma tarefa que consulta um banco de dados a cada 15 minutos deve tentar novamente com backoff exponencial por até 15 minutos e, em seguida, apresentar uma falha controlada.
Configure o execution_timeout por tarefa e SLAs globais da DAG no Airflow; no Workflows, defina timeouts por etapa e políticas de retentativa com max_doublings e max_retry_duration. Para jobs do Cloud Run, defina a contagem de retentativas e o backoff.

Backfills, catchup e tratamento de falhas

Habilite o catchup para recálculo histórico quando as tarefas forem idempotentes e as fontes forem particionadas por data. Para saídas não determinísticas ou efeitos colaterais externos, considere usar DAGs exclusivas para backfill ou tabelas de auditoria de escrita para rastrear o que foi produzido.
Use tópicos/tabelas de dead-letter para falhas em nível de registro em transformações de streaming/lote (batch). Para o Dataflow em lote, capture linhas inválidas com tags de erro e agregue métricas de erro; para streaming, use DLQs do Pub/Sub.

Design de tarefas idempotentes e reexecuções

BigQuery: prefira MERGE ou INSERT com chaves de desduplicação; use o insertId para desduplicar inserções de streaming. Para processamento em lote (batch), escreva em uma tabela de preparo (staging) e depois execute MERGE na tabela de destino dentro de uma etapa transacionalmente segura para permitir reexecuções completas.
Cloud Storage: use pré-condições de geração e nomes de objetos determinísticos (ex: prefixo/data/hash) para que as reexecuções sobrescrevam com segurança apenas quando esperado.
Pub/Sub e Dataflow: projete para entrega do tipo “pelo menos uma vez” (at-least-once). Inclua identificadores de mensagem (ex: ID do pacote, timestamp lógico do evento) para que os sistemas posteriores (downstream) possam desduplicar e analisar a latência. Se as regras de negócio aceitarem a semântica de “o primeiro evento processado vence”, documente essa troca (trade-off) e monitore a distorção (skew); caso contrário, resolva os vencedores pelo tempo do evento com critérios de desempate.
Recuperação de falha parcial: particione as saídas por run_id ou data, escreva marcadores de conclusão e faça as tarefas posteriores (downstream) dependerem desses marcadores. Reprocesse apenas as partições marcadas como incompletas.

Solução de problemas e escalabilidade

Quando um dashboard de streaming perde eventos, mas o Pub/Sub mostra que eles estão presentes, execute um conjunto de dados fixo e conhecido através do pipeline do Dataflow para isolar defeitos na transformação. Valide o janelamento (windowing), os gatilhos (triggers) e a latência permitida (allowed lateness).
Modo de falha comum: criar um pipeline de streaming sem janelamento (windowing)/gatilhos (triggers) apropriados para fontes ilimitadas (unbounded) ou usar uma janela fragmentada (sharded) incorretamente pode causar falha na criação do pipeline ou explosões de estado (state blowups).
Escale o Dataflow através do número máximo de workers e do algoritmo de autoscaling; para picos (ex: 50.000 instalações), aumente o número máximo de workers para permitir o escalonamento horizontal durante esses picos.

Segurança, Parametrização, Ambientes e CI/CD

Parametrização e gerenciamento de configuração

Externalize a configuração por ambiente. No Composer, use Variables, Connections e variáveis de ambiente; use templates para os parâmetros da DAG por data de execução ou partição. No Workflows, use argumentos de tempo de execução e workflows separados por ambiente ou leia a configuração do Secret Manager.
Use orquestração orientada por metadados lendo uma tabela de controle (ex: um dataset de configuração no BigQuery) que lista clientes, fontes ou partições. Gere tarefas dinamicamente para que as alterações de código sejam desacopladas das alterações orientadas por dados.

Secrets, contas de serviço e privilégio mínimo

Armazene as credenciais no Secret Manager e referencie-as em tempo de execução. Evite embutir secrets no código ou nas Variables do Airflow.
Atribua uma conta de serviço (service account) distinta por pipeline com os papéis (roles) mínimos necessários do IAM. Para acesso regulado ao BigQuery, isole os dados do cliente em datasets separados, conceda papéis específicos do dataset apenas a usuários aprovados e restrinja o acesso à API do BigQuery a principais (principals) aprovados. Para multilocação (multitenancy), crie um dataset por cliente e vincule apenas os papéis apropriados.

CI/CD e infraestrutura como código

Gerencie a infraestrutura (ambientes do Composer, Workflows, jobs do Scheduler, tópicos do Pub/Sub, receptores de log) com o Terraform. Use módulos para padronizar projetos/ambientes, secrets e contas de serviço.
Compile e teste o código do pipeline com o Cloud Build ou GitHub Actions. Automatize testes unitários, linting de SQL, dry-runs do Dataform e a validação de DAGs do Airflow. Promova artefatos via tags; para o Composer, empacote as DAGs como pacotes implantáveis; para o Dataform, use branches de release que são promovidas após a aprovação das asserções (assertions).
Promoção de implantação: dev → test → prod através de projetos separados e configurações parametrizadas. Use entrega contínua com portões de aprovação manual e janelas de mudança para promoções de alto risco.

Observabilidade, Alertas e Runbooks

Telemetria e alertas

Encaminhe todos os logs de orquestração para o Cloud Logging com campos estruturados (pipeline, dag_id, run_id, task_id, partition). Exporte os logs de erro para o Monitoring por meio de métricas baseadas em logs. Crie alertas para:
- Agendamentos perdidos ou violações de SLA
- Falhas consecutivas de tarefas
- Crescimento do backlog (ex: mensagens sem confirmação (unacked) no Pub/Sub, atraso do sistema (system lag) no Dataflow)
- Falhas em asserções de qualidade de dados
Cloud Composer: monitore a duração de DAGs/tarefas, taxa de sucesso, profundidade da fila e a saúde do scheduler. Configure o on_failure_callback para acionamento de plantão (paging) e runbooks de remediação.
Cloud Workflows: inspecione os logs de Execução e as latências das etapas; adicione tentativas explícitas e manipuladores de erro; emita logs personalizados com IDs de correlação.
Notificações de alteração de tabela do BigQuery: crie um coletor (sink) do Logging no nível do projeto com um filtro avançado para jobs de inserção que visam uma tabela específica e exporte para o Pub/Sub; sua ferramenta de monitoramento se inscreve no tópico para receber alertas instantâneos sem o ruído de outras tabelas.

Design de runbooks

Para cada pipeline, documente gatilhos, dependências, SLAs, procedimentos de rollback/repetição e etapas seguras de backfill. Inclua a “reprodução de conjunto de dados fixo” (fixed dataset replay) para o Dataflow, como drenar um job de streaming, como reprocessar partições com falha e como remediar mensagens da DLQ.
Capture assinaturas de falhas comuns (ex: permissão negada, cota excedida, incompatibilidade de esquema) com árvores de decisão e caminhos de escalonamento.

Cenário de Problema Prático

A Acme Retail Analytics precisa ingerir arquivos CSV diários de parceiros que contêm ocasionalmente linhas malformadas, transformar e carregar os dados válidos no BigQuery e expor as linhas inválidas para investigação. Eles também desejam enriquecimento orientado a eventos para atualizações de preços quase em tempo real e promoção segura de dev para prod.

Abordagem:

Armazenamento e gatilhos de eventos
- Crie um bucket dedicado do Cloud Storage com versionamento de objetos e acesso uniforme no nível do bucket. Habilite notificações de finalização de objeto para o Pub/Sub via Eventarc.
- Justificativa: A finalização de objeto é um evento confiável para acionar a ingestão downstream; o versionamento suporta novas execuções e auditorias.
Ingestão em lote com tratamento de dead-letter
- Use o Cloud Composer para agendar um DAG diário do Airflow às 02:00 com catchup habilitado. O DAG inicia um job em lote do Dataflow que analisa os CSVs, valida o esquema e grava os registros válidos no BigQuery usando tabelas de preparo (staging) determinísticas e, em seguida, faz um MERGE nas tabelas de destino particionadas. Encaminhe registros malformados/com falha para uma tabela de dead-letter no BigQuery.
- Justificativa: O Dataflow escala a análise/validação; o MERGE garante a idempotência; a captura em dead-letter permite a inspeção sem bloquear o pipeline, correspondendo ao padrão recomendado para linhas malformadas.
Enriquecimento orientado a eventos
- Implante um job do Cloud Run para realizar enriquecimento leve para atualizações incrementais de preços. Acione-o via Cloud Workflows que escuta mensagens do Pub/Sub vindas do Eventarc quando pequenos arquivos de atualização chegam durante o dia.
- Justificativa: Contêineres serverless com o Workflows fornecem orquestração de baixa latência e baixa sobrecarga operacional para eventos pequenos, mantendo as transformações pesadas em lote.
Controles de confiabilidade
- Configure novas tentativas com backoff exponencial para falhas transitórias nos jobs do Dataflow и Cloud Run, limitando o tempo total de novas tentativas ao SLA do DAG. Defina tempos limite de execução por tarefa e callbacks on_failure no Airflow; no Workflows, defina max_doublings e max_retry_duration.
- Justificativa: O backoff limitado preserva os SLAs e evita novas tentativas descontroladas.
Segurança e privilégio mínimo
- Execute cada componente com uma conta de serviço (service account) dedicada: SA do orquestrador do Composer, SA do worker do Dataflow, SA do job do Cloud Run. Conceda apenas os papéis necessários: leitura do GCS no bucket de ingestão para o Dataflow, dataEditor do BigQuery nos conjuntos de dados de destino e Viewer nos logs. Armazene segredos no Secret Manager e referencie-os em tempo de execução.
- Justificativa: Impõe o princípio do privilégio mínimo e isola o raio de impacto (blast radius).
Orquestração orientada por metadados
- Mantenha uma tabela de controle no BigQuery listando as fontes dos parceiros, padrões de arquivo e conjuntos de dados de destino. Em tempo de execução do DAG, o Airflow consulta essa tabela e usa o mapeamento dinâmico de tarefas para gerar tarefas por parceiro.
- Justificativa: Adicionar um parceiro se torna uma alteração de dados, não uma alteração de código, reduzindo o risco da implantação.
Observabilidade e alertas
- Emita logs estruturados com run_id e partner_id. Crie políticas de alerta para violações de SLA do DAG, atraso do sistema (system lag) do Dataflow e contagens não vazias na tabela de dead-letter. Para inserções do BigQuery na tabela de destino, configure um coletor (sink) do Cloud Logging com um filtro avançado para essa tabela, enviando para um tópico do Pub/Sub consumido pela ferramenta de monitoramento da Acme.
- Justificativa: Alertas detalhados permitem uma triagem rápida e sem ruído.
CI/CD e promoção
- Gerencie a infraestrutura (buckets, Pub/Sub, Eventarc, Composer, Workflows, datasets do BigQuery) no Terraform. Use o Cloud Build para validar a sintaxe do DAG do Airflow, executar testes de unidade e implantar em um ambiente de dev do Composer. Promova para os ambientes de teste e produção com configurações parametrizadas e portões de aprovação manual após a aprovação das asserções do Dataform e dos testes de integração.
- Justificativa: Implantações declarativas e repetíveis e promoção segura entre ambientes.
Runbook e recuperação
- Documente os passos para reprocessar uma data específica: restaurar o CSV a partir do versionamento de objetos, reexecutar o job do Dataflow para aquela partição, fazer o MERGE dos resultados e revisar os registros da DLQ. Inclua um procedimento de “reprodução de conjunto de dados fixo” (fixed dataset replay) para isolar bugs de transformação caso surjam discrepâncias.
- Justificativa: O design idempotente e a recuperação documentada simplificam a remediação de falhas parciais.