Google PDE: Arquitetura e Design de Engenharia de Dados — 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

A arquitetura e o design de engenharia de dados no Google Cloud equilibram limites de domínio, padrões de processamento e capacidades de serviço para entregar plataformas de dados confiáveis, escaláveis e com custo-benefício. Designs eficazes tornam o armazenamento, a computação, a orquestração e a disponibilização escaláveis de forma independente; codificam contratos para que os domínios interoperem; e validam riscos antecipadamente com objetivos de nível de serviço (SLOs) mensuráveis. Esta seção resume estilos arquitetônicos canônicos (data mesh, lake, warehouse, lakehouse, armazenamentos operacionais), modos de processamento (lote, microlote, streaming, orientado a eventos, lambda) e os trade-offs entre escalabilidade, latência, disponibilidade, consistência e custo. Também aborda o posicionamento regional e multicloud, a evolução de esquema, o ciclo de vida dos dados de ponta a ponta, a seleção de serviços baseada na carga de trabalho e práticas de validação orientadas a riscos, adaptadas ao Google Cloud.

Paradigmas Arquitetônicos e Padrões de Processamento

• Data mesh, domínios e produtos de dados:
  • Capacite as equipes de domínio a publicar “produtos de dados” com propriedade clara, SLOs, políticas de acesso e documentação. Use o Dataplex para definir domínios, governar metadados e aplicar políticas consistentes no BigQuery e no Cloud Storage. Os produtos podem expor datasets do BigQuery, tópicos do Pub/Sub ou caminhos do Cloud Storage com contratos impostos por meio de esquemas do Pub/Sub e esquemas de tabela do BigQuery.
• Data lake:
  • Armazenamento bruto em formato aberto (Parquet/Avro) no Cloud Storage com ciclo de vida e versionamento. Adequado para cargas de trabalho heterogêneas (Spark no Dataproc, Dataflow, Presto/Trino) e portabilidade multicloud. Trade-off: semântica de consistência eventual em object stores; projete para idempotência e desduplicação orientada por metadados.
• Data warehouse:
  • Analytics curado e governado no BigQuery. Otimizado para ANSI SQL, separação de armazenamento/computação e segurança de granularidade fina. Trade-offs: inserções por streaming apresentam um breve período de dados obsoletos no momento da consulta; prefira cargas em lote ou inserções com consultas em buffer para SLAs de atualização rigorosos.
• Lakehouse:
  • Combina o armazenamento de data lake aberto com as capacidades de um warehouse. No Google Cloud, armazene Parquet/Avro no Cloud Storage; use tabelas externas do BigQuery para economia e tabelas gerenciadas do BigQuery para desempenho e governança. O Dataflow ou o Dataproc mantém semânticas de mesclagem semelhantes a ACID com estratégias de particionamento/clusterização.
• Arquitetura de armazenamento operacional:
  • Armazenamentos transacionais ou de chave-valor de baixa latência que dão suporte a aplicações. Escolha o Cloud SQL para OLTP tradicional, o Cloud Spanner para SQL globalmente consistente com escalabilidade horizontal e o Bigtable para padrões de acesso de altíssima taxa de transferência e colunas largas. Separe os armazenamentos operacionais dos de analytics; use CDC (Datastream) para capturar alterações no Pub/Sub, Cloud Storage ou BigQuery.

Padrões de processamento e quando usá-los:

• Lote (Batch): Transformações periódicas em grande escala (ex: geração noturna de features). Ferramentas: Dataflow em lote, Dataproc. Modos de falha: timeouts de jobs de longa duração, desbalanceamento (skew); mitigue com autoescalonamento e reparticionamento.
• Microlote (Micro-batch): Lotes pequenos e frequentes (ex: a cada minuto) para equilibrar a atualização dos dados com estabilidade e custo. No BigQuery, use consultas agendadas ou o Dataflow com janelas fixas.
• Streaming: Latência de milissegundos a segundos em dados ilimitados. Use Pub/Sub + Dataflow. Lide com eventos atrasados ou fora de ordem com janelas de tempo de evento e marcas d’água (watermarks); garanta a idempotência para evitar duplicatas.
• Orientado a eventos (Event-driven): Acionado por alterações (finalização no GCS, mensagens do Pub/Sub). Use o Cloud Functions ou o Cloud Run para reações sem estado (stateless) e o Dataflow para processamento com estado (stateful). Trade-off: custos por evento vs. taxa de transferência (throughput).
• Padrão Lambda: Mantenha caminhos de streaming e de lote para precisão e reprocessamento. A complexidade dobra; considere uma simplificação do tipo Kappa, onde tudo é reproduzível a partir de um log imutável (arquivamento do Pub/Sub para o Cloud Storage).

Exemplo curto de configuração de streaming do Dataflow para dados atrasados:

events
  .apply(Window.into(FixedWindows.of(Duration.standardMinutes(5)))
    .withAllowedLateness(Duration.standardMinutes(10))
    .accumulatingFiredPanes());

Propriedade de Domínio, Produtos de Dados e Contratos

• Propriedade e SLOs:
  • Cada equipe de domínio define e opera seus produtos de dados com SLOs de disponibilidade, latência e qualidade dos dados. Publique os SLOs por meio dos catálogos do Dataplex e monitore com SLIs do Cloud Monitoring (ex: completude da partição no prazo).
• Contratos e interoperabilidade:
  • Imponha esquemas com o Pub/Sub Schema Registry (Avro/Proto) e esquemas de tabela do BigQuery. Para ingestão de CSV, valide no Dataflow e encaminhe linhas malformadas para uma tabela de “dead-letter” para triagem. Interopere com formatos abertos no Cloud Storage e tabelas externas do BigQuery quando múltiplos mecanismos precisam ler os mesmos dados.
• Evolução de esquema:
  • Prefira alterações retrocompatíveis: adicione colunas que aceitam nulos (nullable), adicione campos opcionais em Avro/Proto, evite renomear/remover sem janelas de descontinuação (deprecation). Comunique as alterações por meio de contratos versionados e cronogramas de descontinuação.
  • Exemplo do BigQuery (adição de coluna retrocompatível):

ALTER TABLE sales.orders
ADD COLUMN coupon_code STRING;

• Impacto no consumidor:
  • Mantenha o versionamento semântico dos esquemas; publique v1 e v2 durante a migração. Para streaming, encaminhe para tópicos versionados ou inclua um campo de versão do esquema. Forneça visualizações autorizadas (authorized views) no BigQuery para isolar os consumidores de alterações físicas.
• Governança e linhagem (lineage):
  • Use o Dataplex e o Data Catalog para metadados, tags (ex: PII) e linhagem. Aplique segurança em nível de linha e de coluna no BigQuery. Para prevenção contra perda de dados, integre o Cloud DLP na ingestão (ex: transformações no Cloud Run ou Dataflow) para tokenizar ou mascarar campos sensíveis antes do armazenamento.

Trade-offs Não Funcionais e Topologia de Implantação

• Escalabilidade:
  • O BigQuery escala elasticamente para analytics; o Bigtable escala linearmente com o número de nós, mas exige um design cuidadoso da chave de linha (row-key) (por exemplo, prefixos com hash ou rotacionados) para evitar hotspotting. O autoscaling do Dataflow responde a backlogs; projete para backpressure aproveitando o controle de fluxo do Pub/Sub.
• Latência:
  • O streaming para o BigQuery oferece inserções de baixa latência, mas as consultas podem apresentar um pequeno atraso (lag); projete consultas com um buffer de atualização (freshness buffer) ou janelas baseadas em marcas d’água (watermarks). Para leituras abaixo de 100 ms em escala, pré-calcule e sirva os dados a partir do Bigtable ou do Memorystore.
• Disponibilidade e consistência:
  • O Cloud Spanner oferece SQL fortemente consistente e distribuído globalmente. O Bigtable oferece alta disponibilidade com consistência eventual entre clusters. A disponibilidade do BigQuery é regional ou multirregional; materialize datasets críticos em uma multirregião para resiliência.
• Custo:
  • Otimize o BigQuery com particionamento e clustering para reduzir os bytes lidos (scanned bytes). Para arquivos pequenos em links de rede limitados, agrupe em lote (batch) ou pacote (bundle) para reduzir o overhead de RPC. Use o BigQuery BI Engine para dashboards interativos e em cache, quando apropriado.
• Regional, multirregional, híbrido e multinuvem:
  • O design regional reduz a latência e o custo; o armazenamento multirregional (por exemplo, BigQuery multirregião US/EU, Cloud Storage dual-region/multi-region) aumenta a durabilidade e as opções de localidade. Para DR (Disaster Recovery), defina o RPO/RTO e replique datasets críticos. Em cenários híbridos, use o Datastream para CDC e os Transfer Appliances ou o Storage Transfer Service para migração em massa (bulk). Para multinuvem, padronize em formatos abertos no Cloud Storage e use computação portátil (Apache Beam/Dataflow, Spark no Dataproc), reconhecendo o overhead operacional e de egresso (egress).

Camadas, Ciclo de Vida e Seleção de Serviços

• Separação de camadas:
  • Armazenamento: Cloud Storage para dados brutos/bronze e arquivamento; BigQuery para análises curadas/de serviço; Bigtable para acesso por chave de baixa latência; Spanner/Cloud SQL para OLTP.
  • Computação: Dataflow para streaming/lote serverless; Dataproc para ecossistemas Spark/Hadoop; BigQuery para ELT dentro do warehouse; Cloud Run/Functions para microsserviços de eventos.
  • Orquestração: Cloud Composer (Airflow) ou Workflows para DAGs e coreografia de APIs; Scheduler para gatilhos do tipo cron.
  • Servir (Serving): Bigtable ou Spanner para leituras online; BigQuery para BI; Looker/BI Engine para dashboards; Memorystore para caching.
• Ciclo de vida dos dados:
  • Ingestão (Ingest): Pub/Sub para streams; Storage Transfer ou gsutil para arquivos; Data Transfer Service para SaaS. Valide, deduplique e armazene dados brutos imutáveis no Cloud Storage com versionamento de objetos.
  • Processamento (Process): Use o Dataflow ou o BigQuery para transformar dados brutos em silver (limpos, conformados) e, em seguida, em gold (marts prontos para o negócio).
  • Servir (Serve): Publique views/tabelas do BigQuery para análises; pré-calcule features ou predições para o Bigtable para APIs.
  • Retenção e arquivamento: Aplique regras de ciclo de vida do Cloud Storage para fazer a transição para as camadas Coldline/Archive; use particionamento por tempo do BigQuery com expiração de partição para retenção. Habilite CMEK onde necessário e VPC Service Controls para proteção contra exfiltração de dados.
• Seleção de serviços com base nas características da carga de trabalho:
  • Séries temporais de alta vazão com linhas largas e baixa latência: Bigtable.
  • OLTP global fortemente consistente com ANSI SQL: Cloud Spanner.
  • Transações relacionais tradicionais com escala modesta: Cloud SQL.
  • Análises em escala de petabytes com ANSI SQL e separação de armazenamento/computação: BigQuery.
  • Ingestão e processamento em tempo real: Pub/Sub + Dataflow.
  • Lotes Spark/Hadoop ou ferramentas específicas de bibliotecas: Dataproc.

Exemplo curto de particionamento no BigQuery:

CREATE TABLE ops.events
PARTITION BY DATE(event_ts)
CLUSTER BY device_id AS
SELECT * FROM staging.events_clean;

Cenário de Problema Prático

A Contoso Mobility opera uma frota global de patinetes elétricos e precisa de ingestão, processamento, armazenamento e análise em tempo real para telemetria de corridas e faturamento. Eles devem suportar milhões de eventos por minuto, regras de fraude abaixo de um segundo, dashboards atualizados, controles de privacidade e operações multirregionais resilientes.

Abordagem:

1. Estabelecer a ingestão de eventos com o Cloud Pub/Sub.

• Justificativa: O Pub/Sub fornece um endpoint global único, buffering durável e escala horizontal para tráfego de dispositivos em rajadas (bursty). Use chaves ordenadas por patinete para preservar a ordem dentro do dispositivo para janelas de 1 hora.

2. Implementar o processamento de streaming com o Cloud Dataflow (Apache Beam).

• Justificativa: O autoescalonamento do Dataflow lida com picos e oferece sinks exactly-once quando combinado com chaves idempotentes. Use janelas de tempo de evento e watermarks para lidar com telemetria atrasada/fora de ordem. Emita uma saída principal para streams curados e uma saída secundária (side output) para registros dead-letter.
• Configuração:

.withAllowedLateness(Duration.standardMinutes(15))
.discardingFiredPanes();

3. Persistir dados brutos e curados no Cloud Storage e no BigQuery, respectivamente.

• Justificativa: Armazene arquivos Avro brutos (bronze) em um bucket dual-region do Cloud Storage para replay e auditoria. Escreva streams curados (silver) em tabelas particionadas do BigQuery para análises, com clustering em scooter_id para buscas pontuais (point lookups) eficientes. Aplique um pequeno buffer de atualização (freshness buffer) nas consultas do dashboard para evitar dados obsoletos transitórios do streaming (transient streaming staleness).

4. Servir consultas operacionais e verificações de fraude a partir do Cloud Bigtable.

• Justificativa: A avaliação de regras abaixo de 100 ms precisa de acesso aleatório de baixa latência. Pré-calcule agregados (ex: corridas por dispositivo por janela de 5 minutos) no Dataflow e escreva no Bigtable usando uma chave de linha com prefixo hasheado (ex: h(prefixo)+device_id+inicio_janela) para evitar hotspotting e paralelizar leituras entre os tablets.

5. Gerenciar o faturamento transacional no Cloud Spanner.

• Justificativa: O faturamento requer SQL globalmente consistente, consistência forte e alta disponibilidade. Use um líder na geografia principal com réplicas somente leitura em regiões secundárias para reduzir as latências de leitura para os portais do cliente.

6. Aplicar governança com Dataplex, Data Catalog e Cloud DLP.

• Justificativa: Classifique campos PII, etiquete datasets e aplique segurança em nível de coluna no BigQuery. Integre o Cloud DLP no pipeline do Dataflow para tokenizar atributos sensíveis antes do armazenamento. Os domínios do Dataplex refletem a propriedade organizacional; cada domínio publica produtos de dados documentados com SLOs.

7. Orquestrar e operar com Cloud Composer e Cloud Monitoring.

• Justificativa: O Composer coordena backfills em lote, compactações e materialização de features de ML. O Monitoring observa SLIs de ponta a ponta: backlog do Pub/Sub, latência do watermark do Dataflow, completude da partição do BigQuery e latências de cauda (tail latencies) do Bigtable. Alerte sobre violações de SLO; autoescale o Dataflow com base no crescimento do backlog.

8. Otimizar custos e ciclo de vida com particionamento e tiering.

• Justificativa: As tabelas do BigQuery são particionadas por event_ts com retenção de 90 dias e clusterizadas por scooter_id. O Cloud Storage usa regras de ciclo de vida para fazer a transição de dados brutos para Coldline após 30 dias e para Archive após 180 dias. Jobs agendados do BigQuery compactam pequenos arquivos de micro-lotes em objetos parquet maiores para reduzir a sobrecarga de contagem de arquivos para jobs Spark posteriores.

9. Validar riscos e resiliência.

• Justificativa: Realize testes de carga com 2x o pico esperado para validar as cotas do Pub/Sub e o autoescalonamento do Dataflow. Execute um exercício de failover regional: datasets multirregionais do BigQuery e buckets dual-region mantêm a disponibilidade; a instância multirregional do Spanner sustenta RPO=0 e o RTO configurado por meio de failover automático. Use Infraestrutura como Código (Terraform) com validação de políticas para impor o uso de CMEK e VPC Service Controls.

Essa arquitetura separa claramente as responsabilidades: o Pub/Sub faz o buffer da ingestão, o Dataflow computa, o Cloud Storage e o BigQuery armazenam e servem análises, o Bigtable acelera as leituras operacionais e o Spanner garante transações consistentes. Ela equilibra escalabilidade e latência enquanto controla custos por meio de particionamento, clustering, políticas de ciclo de vida e autoescalonamento, e incorpora governança e confiabilidade por meio de produtos de dados documentados, contratos e validação contínua.

Todos os domínios · Armazenamento de Dados →

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

Navegar Google →