Google PDE: Ingestão, Integração e Migração 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 ingestão, integração e migração de dados no Google Cloud abrangem padrões repetíveis, serviços gerenciados e controles operacionais que transformam diversos sistemas de origem em conjuntos de dados confiáveis e consultáveis. Designs eficazes separam o transporte da transformação, desacoplam produtores e consumidores, e favorecem pipelines idempotentes e com checkpoints, com linhagem e verificação claras. Esta seção aborda padrões de ingestão, serviços do Google Cloud para movimentação e CDC, controles de esquema e qualidade de dados, conectividade e integração híbrida, e estratégias de cutover, com trade-offs de design e modos de falha destacados ao longo do texto.

Padrões e Cargas de Trabalho de Ingestão

• Ingestão em lote (batch): Extrações periódicas (pulls) ou depósitos de arquivos (file drops) em intervalos definidos. Bom para custos previsíveis e preenchimentos retroativos (backfills). Modo de falha: lotes grandes e infrequentes causam picos de recursos, longas janelas de recuperação e perda de SLAs. Mitigação: dimensione corretamente as janelas de lote, fragmente (shard) por tempo ou chave e use paralelismo.
• Carga em massa (bulk): Cargas únicas ou em grande escala (por exemplo, preenchimento histórico inicial). Prefira formatos colunares ou autodescritivos (Parquet, Avro) e carregue diretamente no armazenamento analítico (BigQuery) ou em um staging no Cloud Storage. Trade-off: consultar tabelas externas evita etapas de carga, mas transfere o custo para a varredura (scan) em tempo de consulta.
• Carga incremental: Cargas delta periódicas via timestamps ou marcas d’água (high-water marks). Requer desduplicação robusta e upserts idempotentes. Modo de falha: assimetria de relógio (clock skew) ou registros que chegam com atraso. Use timestamps de commit do lado do servidor e watermarking.
• Change Data Capture (CDC): Replicação contínua de inserções, atualizações e exclusões de bancos de dados operacionais. Ideal para análises quase em tempo real e migrações com baixo tempo de inatividade. Trade-offs:
  • Ordenação: A maioria das ferramentas de CDC preserva a ordem dentro das transações e normalmente dentro de um shard, mas não garante a ordem global entre shards. Use timestamps de commit da transação e chaves primárias para reconstruir a sequência.
  • Semântica de entrega: “Pelo menos uma vez” (at-least-once) é o padrão; construa consumidores (sinks) idempotentes ou desduplique usando IDs de alteração únicos.
  • Snapshot + CDC: Comece com um snapshot consistente e, em seguida, aplique as alterações de uma sequência de log precisa para atingir a paridade sem tempo de inatividade.

Fontes relacionais, SaaS, on-premises e de arquivos:

• Fontes relacionais: Use CDC nativo ou colunas de timestamp. Para cargas em massa, exporte para Avro/Parquet e armazene em staging no Cloud Storage.
• Fontes SaaS: Prefira APIs do fornecedor com tokens incrementais; integre através de conectores gerenciados (por exemplo, no Data Fusion). Controle o fluxo (throttle) para respeitar os limites de taxa (rate limits) e lide com a deriva de esquema (schema drift).
• Fontes on-premises: Escolha entre transferência baseada em agente, VPN/Interconnect + Private Google Access ou semeadura (seeding) offline com o Transfer Appliance.
• Ingestão de arquivos: Para muitos arquivos pequenos, agrupe-os (por exemplo, com tar) para reduzir a sobrecarga de RPC. Use

undefined

ou clientes paralelizados; componha ou transforme em arquivos colunares maiores para análise.

Serviços do Google Cloud para Ingestão, Integração e Migração

• Datastream (CDC serverless): Captura alterações do MySQL, PostgreSQL e Oracle para o Cloud Storage, BigQuery (via templates) ou Pub/Sub. Ele preserva os limites da transação e os metadados de commit; a ordenação global não é garantida. Aplique a ordenação downstream por chave e timestamp de commit. Espere uma entrega “pelo menos uma vez” (at-least-once); projete consumidores idempotentes (por exemplo,

undefined

do BigQuery com IDs de alteração).

• Database Migration Service (DMS): Para migrações de banco de dados com tempo de inatividade mínimo usando replicação nativa. O DMS cria um snapshot consistente e, em seguida, replica continuamente as alterações usando GTID/LSN/SCN. Ele é projetado especificamente para lift-and-shift, não para transformações arbitrárias. Para análises, complemente o DMS com o Dataflow ou o Data Fusion, se necessário.
• Cloud Data Fusion: Um serviço de integração gerenciado com conectores para sistemas relacionais, SaaS, de arquivos e de mensagens. Construa pipelines com estágios de transformação (joins, agregações, conversões de formato, receitas personalizadas do Wrangler) e capture a linhagem entre fontes e campos. Operacionalmente, ele agenda, tenta novamente e emite métricas. Use o Data Fusion para ELT/ETL no-code/low-code e para centralizar o gerenciamento de conectores.
• Storage Transfer Service (STS): Transferências gerenciadas e agendadas do AWS S3, Azure Blob, on-prem (usando agentes), SFTP e listas de URL para o Cloud Storage. Suporta manifestos, sincronização incremental, controle de largura de banda e integridade com checksum. Os modos de falha incluem ineficiência com arquivos pequenos e throttling de API; mitigue com agrupamento (batching) e concorrência ajustável.
• Transfer Appliance: Appliance offline e criptografado para semeadura (seeding) inicial em escala de multi-terabytes a petabytes, quando a largura de banda da rede é limitada ou os dados são muito sensíveis para trânsito prolongado. A cadeia de custódia e a criptografia são integradas. Após a semeadura, continue com o STS ou CDC para os deltas.
• Cloud Pub/Sub + Dataflow: O Pub/Sub desacopla produtores e consumidores para padrões de streaming ou micro-lotes. O Dataflow oferece processamento de stream/lote com autoescalabilidade e estado (stateful), com checkpointing e watermarking. Use a BigQuery Storage Write API para streaming de baixa latência com garantias “exatamente uma vez” (exactly-once) por stream padrão; caso contrário, confie na semântica de desduplicação do

undefined

.

Para migrações de Hadoop para Dataproc, minimize o uso de Persistent Disk armazenando os dados no Cloud Storage com o conector GCS e use clusters efêmeros ou com autoescalabilidade. Isso evita grandes custos de armazenamento em bloco, preservando a semântica compatível com HDFS para o processamento.

Esquema, Validação e Qualidade de Dados na Fronteira

• Mapeamento de esquema e conversão de tipos: Padronize para esquemas fortemente tipados o mais cedo possível. Avro ou Parquet preservam o esquema e evoluem de forma limpa. No BigQuery, prefira tabelas particionadas e clusterizadas para reduzir o custo de varredura. Exemplo: criar uma tabela particionada para análise diária CREATE TABLE dataset.tracking_table ( event_ts TIMESTAMP, device_id STRING, payload STRING ) PARTITION BY DATE(event_ts) CLUSTER BY device_id;
• Tratamento de registros malformados: Roteie as rejeições para uma fila de mensagens mortas (dead-letter queue) (Pub/Sub) ou um bucket de quarentena no Cloud Storage. Use saídas laterais (side outputs) no Dataflow ou coletores de erro no Data Fusion. Registre os erros de parsing com amostras de payloads e versões de esquema para triagem.
• Validação: Realize verificações de fronteira antes da persistência:
  • Estrutural: conformidade com o esquema, campos obrigatórios, tipos de dados, domínios de enumeração.
  • Referencial: existência de chave estrangeira por meio de buscas em dimensões cacheadas.
  • Razoabilidade: intervalos para timestamps, cercas geográficas (geofences), valores não negativos.
  • Unicidade: colisões de chave primária ou composta.
• Carregamento idempotente: Use chaves determinísticas e operações de upsert. No BigQuery, implemente MERGE com uma chave de alteração natural ou substituta (surrogate). Exemplo: MERGE dataset.orders T USING dataset.orders_stage S ON T.order_id = S.order_id WHEN MATCHED THEN UPDATE SET amount = S.amount, status = S.status WHEN NOT MATCHED THEN INSERT (order_id, amount, status) VALUES (S.order_id, S.amount, S.status);
• Watermarking e dados tardios: Em pipelines de streaming, configure watermarks de tempo de evento e o atraso permitido (allowed lateness) para equilibrar completude e latência. Dados tardios são roteados para caminhos corretivos ou acionam backfills.
• Reconciliação: Monitore contagens de linhas e checksums por partição/janela da origem ao destino (sink). Capture as posições de log do CDC (LSN/SCN) e os timestamps de commit; armazene em uma tabela de controle para provar a continuidade e identificar lacunas.

Conectividade, Confiabilidade e Operações

• Conectividade de rede e acesso privado:

  • Híbrido: Use o Cloud VPN ou o Dedicated/Partner Interconnect para conectividade privada. Habilite o Private Google Access ou o Private Service Connect para acesso privado a APIs do Google, como o Cloud Storage.
  • Segurança: Use contas de serviço para identidade da carga de trabalho (workload identity), IAM de privilégio mínimo, VPC Service Controls para prevenção de exfiltração de dados e CMEK onde for necessário.
  • Taxa de transferência (Throughput): Escale o paralelismo no cliente, mas, em última análise, a largura de banda governa a taxa de transferência. Para transferências massivas, prefira o Transfer Appliance para a carga inicial em massa e, em seguida, o STS ou CDC para atualizações incrementais.

• Checkpoints e contrapressão (backpressure): O Dataflow gerencia checkpoints e autoscaling; projete destinos (sinks) que possam absorver picos de dados (fazer buffer para o Cloud Storage, escritas em lote para o BigQuery). Para o Pub/Sub, ajuste o controle de fluxo e os prazos de confirmação (ack deadlines) para evitar tempestades de reentrega de mensagens.

• Ordenação e consistência com CDC:

  • O Datastream preserva a ordem intra-transação e emite metadados de commit; os consumidores reconstroem a ordem por chave usando os timestamps de commit. Espere entrega do tipo “pelo menos uma vez” (at-least-once); construa a idempotência.
  • O DMS garante a consistência do banco de dados durante a transição (cutover) do snapshot para a replicação usando logs nativos. Use réplicas de leitura ou estratégias de escrita dupla (dual-write) para uma transição em fases.

• Estratégia de arquivos para analytics: Para acesso por múltiplos motores (engines) a grandes volumes de dados, armazene os dados canônicos no Cloud Storage e, onde for custo-efetivo, exponha tabelas externas permanentes para consultas ad hoc. Para analytics de produção, carregue os dados em tabelas particionadas do BigQuery para minimizar o custo de varredura por consulta.

• Otimização de arquivos pequenos: Agrupe arquivos pequenos (ex: ~1.000 por arquivo .tar) antes da transferência e, em seguida, expanda-os na nuvem. Use o gsutil em paralelo e regras de ciclo de vida para migrar para outras camadas de armazenamento (tier) e expirar artefatos de preparação (staging).

• Armadilhas operacionais e mitigações:

  • Desvio de esquema (schema drift) de SaaS: habilite a evolução de esquema no Data Fusion e imponha a compatibilidade. Alerte sobre alterações que quebram a compatibilidade (breaking changes).
  • Fuso horário e codificação: normalize para UTC e UTF-8 na entrada (ingress).
  • Lacunas no CDC: monitore a retenção de logs da origem; alerte quando o atraso da réplica (replica lag) se aproximar dos limites de retenção.
  • Cotas: inserção por streaming no BigQuery, limites de taxa de API; processe em lote ao se aproximar dos limites.

Cutover, Backfill e Verificação

• Planejamento do cutover (virada):
  • Big bang: congelamento curto, uma única virada. Menor complexidade operacional; maior risco se um rollback for necessário.
  • Em fases ou blue/green: execução dupla com escritas espelhadas, desvio progressivo de tráfego e leituras sombra (shadow reads). Custo mais alto; rollback mais seguro.
• Backfill:
  • Realize uma carga inicial em massa (Transfer Appliance ou STS) usando Avro/Parquet para preservar o schema. Particione e clusterize durante a carga para evitar retrabalho.
  • Inicie o CDC em uma posição de log conhecida simultaneamente com o snapshot para capturar os deltas durante a transferência em massa. Reconcilie em um watermark comum antes de abrir para produção.
• Rollback:
  • Mantenha o sistema legado como somente leitura durante a verificação. Para cenários de escrita dupla, controle as escritas por trás de uma feature flag para reverter rapidamente. Mantenha um checkpoint consistente para reproduzir ou desfazer as alterações do CDC, se necessário.
• Verificação da migração:
  • Estrutural: contagens de linhas e checksums por partição correspondem; schema e constraints equivalentes.
  • Temporal: sem lacunas desde o limite do snapshot até o cutover; posições do CDC contínuas.
  • Paridade de negócio: compare agregados e KPIs em janelas de tempo; execute consultas de aceitação.
  • Desempenho: valide a taxa de transferência (throughput) de ingestão, a latência das consultas e o custo em relação aos orçamentos.

Cenário de Problema Prático

A Northstar Retail precisa consolidar uma mistura global de sistemas transacionais on-premise Oracle e MySQL, eventos de CRM SaaS e entregas diárias de arquivos CSV no Google Cloud para potencializar análises e machine learning em near-real-time. Eles também precisam migrar um cluster Hadoop legado sem incorrer em altos custos de armazenamento em bloco e alcançar um cutover com tempo de inatividade zero ou baixo (zero-to-low downtime).

1. Estabelecer conectividade híbrida segura

• Use o Partner Interconnect para a banda principal e o Cloud VPN como fallback. Habilite o Private Google Access para que as cargas de trabalho on-premise possam acessar o Cloud Storage e o Pub/Sub de forma privada. Justificativa: Caminhos privados minimizam a exposição de tráfego de saída (egress) e a latência, e o Private Google Access evita a necessidade de IPs públicos, ao mesmo tempo que atende à política de segurança.

2. Carregar dados históricos de forma eficiente

• Para 800 TB de dados históricos do HDFS, copie para o Cloud Storage usando o Transfer Appliance (carga inicial em massa). Após a carga inicial, execute o Storage Transfer Service diariamente a partir da exportação NFS on-premise para capturar as alterações até o cutover. Justificativa: O Transfer Appliance evita a saturação prolongada da rede; o STS fornece sincronização incremental agendada e com checksum. Armazenar no Cloud Storage com o conector do GCS permite o processamento com o Dataproc sem a necessidade de 50 TB de Persistent Disk por nó.

3. Migrar bancos de dados operacionais com CDC

• Use o DMS para migrar o MySQL e o PostgreSQL com tempo de inatividade mínimo. Para o CDC de Oracle para analytics, use o Datastream para uma área de landing no Cloud Storage e, em seguida, um template do Dataflow fornecido pelo Google para carregar no BigQuery. Justificativa: O DMS utiliza a replicação nativa para um snapshot confiável + sincronização contínua; o Datastream fornece CDC serverless com metadados de commit, enquanto o template do Dataflow garante escritas ordenadas e idempotentes no BigQuery.

4. Ingerir feeds de SaaS e baseados em arquivos

• Crie pipelines no Cloud Data Fusion usando conectores SaaS para eventos de CRM com tokens incrementais, e um pipeline de arquivos para ingerir CSVs diários de um SFTP de fornecedor via STS. Normalize para o formato Avro em um bucket curado no Cloud Storage e, em seguida, carregue em tabelas particionadas do BigQuery. Justificativa: O Cloud Data Fusion centraliza conectores, transformação e linhagem (lineage). A padronização em Avro preserva o schema e facilita a evolução; tabelas particionadas no BigQuery reduzem o custo das consultas.

5. Fazer o stream de eventos em tempo real

• Publique eventos da web e de lojas no Pub/Sub. Processe com o Dataflow para parsing, validação, enriquecimento e watermarking; escreva no BigQuery através da Storage Write API e arquive o Avro bruto no Cloud Storage. Justificativa: O Pub/Sub desacopla produtores e consumidores; o Dataflow oferece autoescalonamento, processamento com estado (stateful), checkpoints e tratamento de dados atrasados; a escrita dupla garante tanto análises de baixa latência quanto a retenção durável dos dados brutos.

6. Aplicar controles de qualidade de dados e de schema na borda

• Implemente registro e validação de schema no Dataflow/Data Fusion. Direcione registros malformados para um bucket de quarentena no GCS e para um tópico de dead-letter no Pub/Sub. Aplique verificações de domínio (ex: códigos de moeda, timestamps UTC) e desduplique usando chaves compostas. Justificativa: A rejeição e a quarentena precoces impedem que dados ruins se propaguem; a idempotência e a desduplicação protegem contra a entrega do tipo “pelo menos uma vez” (at-least-once) de fontes de CDC e streaming.

7. Otimizar o armazenamento e o acesso para analytics

• Carregue conjuntos de dados curados em tabelas particionadas e clusterizadas do BigQuery. Exponha os arquivos brutos como tabelas externas permanentes para exploração de baixa frequência. Para cargas de trabalho OLTP que permanecem transacionais, mantenha o Cloud SQL com réplicas de leitura. Justificativa: O particionamento e a clusterização minimizam o custo de varredura (scan); tabelas externas evitam cargas desnecessárias para acesso ocasional; o Cloud SQL preserva a semântica ACID para aplicações transacionais.

8. Planejar o cutover, o backfill e o rollback

• Execute snapshot + CDC para cada RDBMS; alcance um ponto de reconciliação onde as contagens de linhas e os checksums correspondam. Execute em modo blue/green com escritas duplas por 48 horas, desviando as leituras para o BigQuery gradualmente. Mantenha uma feature flag para reverter as escritas caso discrepâncias sejam detectadas. Justificativa: O modo blue/green reduz o risco; a verificação em um watermark conhecido garante a completude; as flags permitem um rollback rápido.

9. Verificação e observabilidade

• Crie tabelas de controle que capturem o LSN/SCN de origem, timestamps de commit, contagens de linhas e checksums por partição. Monitore o lag do Datastream, o estado da replicação do DMS, os watermarks do Dataflow, o backlog do Pub/Sub, o status dos jobs do STS e as métricas de inserção por streaming do BigQuery. Justificativa: A linhagem de ponta a ponta e os controles quantitativos fornecem uma prova auditável de correção e alertas em tempo hábil sobre lacunas ou lag.

Ao separar as camadas de landing, curadoria e serviço (serving); usar o Cloud Storage como staging e arquivamento duráveis e de baixo custo; alavancar o DMS/Datastream para CDC com consumidores idempotentes; e aplicar controles de schema e qualidade na entrada (ingress), a Northstar Retail alcança uma ingestão segura e escalável e uma migração de baixo risco, verificável e com custo previsível.

← Spark · Todos os domínios · Orquestração de Workflows e Automação de Pipelines →

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

Navegar Google →