Google PDE: Analytics com BigQuery e Engenharia de Data Warehouse — 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 BigQuery é um data warehouse analítico serverless, colunar e MPP (Massively Parallel Processing) que separa o armazenamento da computação, oferecendo escala quase infinita, SQL padrão ANSI e governança integrada. A engenharia de warehouse no BigQuery equilibra o design do schema (particionamento, clustering, desnormalização vs. normalização, registros aninhados), padrões de ingestão (cargas em lote, streaming, Storage Write API) e gerenciamento de cargas de trabalho (edições sob demanda vs. baseadas em capacidade e reservas). Segurança robusta (views autorizadas, políticas de linha/coluna, tags de política) coexiste com controles de custo e ferramentas de performance para minimizar os bytes lidos e reduzir a latência. Esta seção aborda o design principal, as operações e os modos de falha que você deve antecipar em produção.

Armazenamento e Semântica: Datasets, Tabelas, Views e Acesso ao Lake

• Datasets, tabelas, views:

  • Datasets definem o escopo do IAM e da governança. Mantenha datasets por locatário (per-tenant) para isolamento e clareza no faturamento.
  • Tabelas padrão armazenam dados nativamente; partições e clustering governam o layout e o pruning (eliminação de partições).
  • Views encapsulam a lógica SQL sem armazenar dados. Views autorizadas permitem que o proprietário de uma view exponha subconjuntos restritos a outros projetos ou locatários, ocultando as tabelas subjacentes.
  • Views materializadas (MVs) persistem resultados pré-calculados e são atualizadas automaticamente. A reescrita de consultas (query rewrite) usa MVs de forma transparente quando compatível; predicados ou funções incompatíveis as ignoram.
  • Tabelas externas referenciam dados no Cloud Storage, Google Drive ou Google Sheets. Elas evitam a ingestão, mas trocam performance (throughput) e suporte a funções por conveniência. Para análises repetidas, ingira os dados em tabelas nativas.

• Particionamento, clustering e registros aninhados:

  • Particione por tempo de ingestão, DATE/TIMESTAMP/DATETIME ou intervalo de inteiros para fazer o pruning de leituras. Use filtros WHERE na coluna de partição ou decoradores como _PARTITIONDATE para habilitar o pruning.
  • Faça o clustering em colunas de alta cardinalidade, frequentemente filtradas ou usadas em joins (até 8). O BigQuery faz o reclustering automaticamente; DMLs pequenos e repetidos podem degradar temporariamente a qualidade do clustering.
  • Registros aninhados e repetidos (STRUCT, ARRAY) modelam relacionamentos um-para-muitos sem a sobrecarga de joins. Use UNNEST com critério; UNNESTs repetidos em arrays grandes podem causar uma expansão (fan out) dramática.

• Desnormalização vs. normalização:

  • Desnormalize atributos de dimensão em tabelas de fatos para minimizar joins e explorar as leituras colunares; isso é ideal para análises com leitura intensiva (read-heavy).
  • Normalize quando a amplificação de escrita, hotspots de atualização ou self-joins causam contenção ou complexidade (por exemplo, separar tabelas mestre de pacientes e de visitas para evitar explosões de self-join).
  • Considere uma abordagem híbrida: entidades principais normalizadas com fatos largos e desnormalizados ou filhos aninhados.

• Views materializadas: considerações de design

  • Ideal para agregações estáveis e incrementais sobre tabelas base particionadas. A atualização da MV é assíncrona; usuários downstream devem tolerar janelas de dados obsoletos (staleness) ou consultar as tabelas base como alternativa (fallback).
  • Filtre e agrupe pela coluna de partição para atualização incremental. Funções não determinísticas, joins não suportados ou UDFs podem desqualificar as MVs para a reescrita de consulta.

• Consultas federadas, BigLake e pushdown:

  • Consultas federadas leem sistemas externos (por exemplo, Cloud SQL) diretamente com SQL. Elas são convenientes para joins leves ou exploração pontual, mas têm maior latência e cotas mais restritas; extraia os dados para o BigQuery para análises pesadas.
  • Tabelas BigLake unificam a governança do lake e do warehouse com controles em nível de coluna e linha sobre dados no Cloud Storage ou em formatos de tabela abertos (como Parquet). O predicate e projection pushdown reduzem os bytes baixados; leituras grandes ainda favorecem a ingestão em tabelas nativas para performance máxima.

• Tabelas curinga (wildcard) e shards legados:

  • Consultas curinga (wildcard queries) são um padrão legado para tabelas fragmentadas por data (date-sharded). Prefira o particionamento nativo, mas quando necessário: SELECT ... FROM \bigquery-public-data.noaa_gsod.gsod*` WHERE _TABLE_SUFFIX >= ‘2010’`.

Otimização de Consultas e Gerenciamento de Carga de Trabalho

• Poda (pruning) de partição e clustering:

  • Sempre filtre na coluna de partição para evitar a varredura de partições frias. Use BETWEEN com janelas estreitas.
  • Ordene as chaves de clustering por seletividade; as chaves iniciais devem corresponder a filtros e joins frequentes. Evite fazer clustering em colunas com cardinalidade muito baixa.

• Otimização do plano de consulta:

  • Use EXPLAIN e os detalhes de execução para encontrar joins assimétricos (skewed joins), shuffles grandes ou varreduras não podadas (non-pruned scans).
  • Reduza as colunas o mais cedo possível com listas SELECT e subconsultas; o BigQuery é colunar e descarta colunas não utilizadas de forma eficiente.
  • Prefira agregações aproximadas (por exemplo, APPROX_QUANTILES) para equilibrar velocidade e custo em grandes volumes de dados.

  • Aplique a desduplicação com window functions quando as fontes de ingestão puderem repetir eventos:

undefined

• Joins e desnormalização:

  • Colocalize as chaves de join como chaves de cluster para reduzir o shuffle. Filtros Bloom (Bloom filters) ou pré-agregação podem ajudar com assimetria extrema (extreme skew).
  • Desnormalize dimensões pequenas e de alteração lenta (slowly changing dimensions) em tabelas de fatos para evitar joins sobrecarregados (hot joins). Para dimensões muito largas com atualizações frequentes, normalize e confie nas chaves de cluster e em joins materializados.

• Gerenciamento de carga de trabalho, slots, edições e autoscaling:

  • On-demand: o BigQuery escala elasticamente a computação por consulta; você paga por TB verificado. Controle o custo com o máximo de bytes faturados e a poda de partição.
  • Baseado em capacidade com as edições do BigQuery (Standard, Enterprise, Enterprise Plus) usa reservas de slots. Adquira compromissos de base (baseline commitments), crie reservas e atribua projetos ou pastas. O autoscaling pode adicionar slots durante os picos e liberá-los quando a demanda cai; use reservas separadas para ETL vs. BI para evitar interferência.
  • Prioridade de job: interativo (padrão) para baixa latência; em lote (batch) para backfills e consultas agendadas. Jobs em lote ficam na fila até que a capacidade ociosa esteja disponível na reserva ou no serviço, e então são executados com custo normal.

• Simultaneidade e cotas:

  • Use reservas e atribuições (assignments) para isolar cargas de trabalho críticas. Para múltiplos locatários (mixed tenants), coloque-os em reservas ou projetos distintos com limites de simultaneidade personalizados.
  • Rotule os jobs para atribuição; monitore INFORMATION_SCHEMA.JOBS e as métricas do Cloud Monitoring para utilização de slots e atrasos na fila.

• Cache de BI e atualização de dados (freshness):

  • O cache de resultados de consulta melhora a latência/custo para consultas idênticas; desative-o em clientes que precisam de dados atualizados em menos de uma hora. Algumas ferramentas de BI armazenam dados em cache de forma independente — desative o cache de relatórios para exibir os resultados mais recentes.

Ingestão, Federação e Recuperação

• Jobs de carregamento (Load jobs):

  • Cargas em lote (batch loads) a partir do Cloud Storage (preferencialmente Avro/Parquet) são confiáveis e econômicas. Defina o esquema e a codificação (encoding) explicitamente; codificações de CSV incompatíveis são uma causa comum de discrepâncias byte a byte.
  • Use decoradores de partição (partition decorators) ou carregue para tabelas particionadas para evitar merges. Para cargas grandes, paralelize por partição.

• Ingestão por streaming e a Storage Write API:

  • As inserções por streaming legadas são simples, mas têm cotas mais rígidas e podem apresentar consistência eventual por alguns segundos; o time travel em dados muito recentes pode ter atrasos.
  • A Storage Write API é o caminho recomendado para escritas de alta vazão e baixa latência com melhores controles de desduplicação. Use a idempotência (offsets de stream) para evitar duplicatas.
  • O design da aplicação deve tolerar eventos em trânsito (in-flight): atrase as consultas interativas pelo tempo de disponibilidade esperado (por exemplo, 2x a latência observada) ou use marcas d’água (watermarks) em partições de tempo de ingestão.

• Dataflow e design de dead-letter:

  • Para CSVs entregues por parceiros com linhas malformadas, use o Dataflow para analisar e validar, escrever registros válidos no BigQuery através da Storage Write API e rotear os erros para uma tabela de dead-letter para inspeção.
  • Ao ler do BigQuery em grande escala, prefira leituras baseadas em consulta (fromQuery) para selecionar apenas os campos necessários e reduzir o shuffle.

• Consultas agendadas e transformações:

  • Use consultas agendadas para transformações ELT, rollups incrementais e manutenção de tabelas. Prefira escrever em destinos particionados e clusterizados. As consultas agendadas usam prioridade de lote (batch) por padrão e se integram com as reservas.

• Notificações e observabilidade:

  • Exporte os logs de auditoria do BigQuery com um coletor de logs (log sink) para o Pub/Sub para acionar alertas em jobs de inserção de tabelas específicas:
    • Exemplo de filtro: resource.type=“bigquery_resource” AND protoPayload.methodName=“jobservice.jobCompleted” AND jsonPayload.jobChange.job.jobConfiguration.load.destinationTable.tableId=“target_table”
  • Use os logs de auditoria do Cloud Logging e as visualizações do INFORMATION_SCHEMA para descobrir padrões de uso e aplicar a governança.

• Time travel, snapshots e clones:

  • O time travel permite que você consulte uma tabela em um carimbo de data/hora anterior (padrão de 7 dias). Use FOR SYSTEM_TIME AS OF para ler estados passados.
  • Snapshots de tabela capturam uma visão em um ponto no tempo (point-in-time) com copy-on-write; use para backfills consistentes ou recuperação. Clones de tabela fornecem cópias de metadados quase instantâneas para desenvolvimento ou análise de cenários (what-if) com armazenamento mínimo até que haja divergência.
  • Opções de recuperação:
    • Erros pequenos: consulte usando time travel e INSERT...SELECT para restaurar.
    • Restauração grande: crie a partir de um snapshot ou clone e, em seguida, troque (swap).
  • Defina a expiração de tabelas e partições para impor a retenção; verifique se a retenção está alinhada com as necessidades do time travel.

• Fontes federadas:

  • Use a federação do Cloud SQL para joins leves; para análises contínuas ou varreduras grandes, agende a extração e carregamento (extract-load) para tabelas nativas.
  • Tabelas BigLake sobre Parquet/ORC no Cloud Storage podem aplicar tags de política (policy tags) e fazer push down de filtros e projeções de colunas; ainda assim, espere uma latência maior do que o armazenamento nativo.

Segurança, Governança e Controle de Custos

• IAM e menor privilégio:

  • Conceda papéis no nível do dataset minimamente (BigQuery Data Viewer, Data Editor) apenas para usuários aprovados; restrinja o acesso à API a contas de serviço e grupos selecionados.
  • Segregue clientes e ambientes por dataset e projeto para isolamento. Atribua reservas por projeto ou pasta para evitar vizinhos barulhentos.

• Visualizações autorizadas e segurança em nível de linha:

  • Visualizações autorizadas expõem apenas colunas/linhas selecionadas para projetos externos, enquanto o projeto da visualização mantém o acesso à tabela. Mantenha a visualização e a origem no mesmo dataset ou use autorização no nível do dataset para o projeto de destino.
  • A segurança em nível de linha com políticas de acesso a linhas filtra as linhas por usuário ou grupo no momento da consulta; combine com visualizações autorizadas para um controle em camadas.

• Segurança em nível de coluna e tags de política:

  • Use tags de política do Data Catalog para proteger colunas sensíveis e habilitar o mascaramento de dados. Atribua acesso às tags (não às tabelas) para alinhar com a classificação de dados. Para acesso de parceiros, mascare ou negue colunas de PII por meio de tags.

• BigQuery ML e análise no próprio warehouse:

  • Treine e sirva modelos diretamente no BigQuery (por exemplo, regressão linear/logística, XGBoost, K-means, séries temporais) com

undefined

e

undefined

. Armazene features em tabelas particionadas e use retreinamento agendado.

• Modelos remotos permitem que você invoque o Vertex AI ou endpoints externos a partir do SQL para pontuação dentro de uma governança federada. Armazene as saídas em cache em tabelas para amortizar a latência de consultas repetidas.

• Controles de custo e solução de problemas de desempenho:

  • Reduza os bytes lidos:
    • Particione e clusterize; sempre filtre por essas chaves.
    • Use

undefined

apenas para as colunas necessárias; evite

undefined

. - Use visualizações materializadas e cache de resultados quando aplicável. - Defina

undefined

para limitar o custo.

• Solucione problemas de desempenho:
  • Inspecione os detalhes de execução do job em busca de distorção (skew), partições não eliminadas ou hotspots de shuffle. Altere as chaves dos joins ou pré-agregue para reduzir o shuffle.
  • Valide as reescritas de MV; garanta predicados compatíveis e funções determinísticas.
  • Para dashboards sem dados de streaming recentes, considere o atraso de consistência ou desabilite o cache do lado do cliente.
• Visibilidade da governança: audite com o Cloud Logging,

undefined

e rótulos de job detalhados para repassar custos e identificar outliers.

Cenário de Problema Prático

A NovaCare Health opera uma plataforma regional de telemedicina. Um design de tabela única,

undefined

, deu suporte a um piloto, mas com uma escala 100 vezes maior, os relatórios expiram (timeout), duplicatas aparecem de upserts de streaming e os parceiros exigem isolamento de dados rigoroso.

Abordagem:

1. Redesenhar o esquema e o layout
   • Crie tabelas principais normalizadas:

undefined

e

undefined

.

• Transforme

undefined

em uma tabela particionada por

undefined

, clusterizada por

undefined

e

undefined

. Mantenha pequenas dimensões de referência desnormalizadas dentro de

undefined

para acelerar os dashboards.

• Justificativa: A normalização evita self-joins caros e atualizações pesadas de linhas em uma única tabela quente. O particionamento elimina varreduras históricas; a clusterização colocaliza joins e filtros em

undefined

, reduzindo o shuffle.

2. Ingerir com a Storage Write API e garantir a idempotência

   • Use um pipeline do Dataflow para analisar eventos de entrada, validar e gravar em streams nomeados na Storage Write API com offsets idempotentes.
   • Encaminhe eventos malformados para uma tabela de dead-letter do BigQuery para triagem.
   • Justificativa: A Storage Write API oferece maior throughput, menor latência e melhores garantias de desduplicação do que o streaming legado. O uso de dead-lettering preserva a visibilidade sobre problemas de qualidade dos dados dos parceiros.

3. Projetar para atualidade dos dados e desduplicação nas consultas

   • Para análises interativas, adicione um watermark curto (por exemplo, 2x a disponibilidade observada) antes de consultar a partição mais recente; ou filtre por

undefined

onde

undefined

para excluir linhas em trânsito.

• Use

undefined

em visualizações que devem tolerar novas tentativas (retries) do upstream.

• Justificativa: O streaming é eventualmente consistente por um breve intervalo. Watermarking e desduplicação baseada em janela protegem os dashboards de lacunas e duplicatas transitórias.

4. Acelerar agregações comuns com visualizações materializadas
   • Crie MVs alinhadas à partição sobre a tabela

undefined

para KPIs diários agrupados por

undefined

e coortes de pacientes. Garanta que os predicados sejam compatíveis com a reescrita.

• Justificativa: MVs reduzem a latência e os bytes lidos para relatórios recorrentes; o BigQuery reescreve as consultas para usar a MV de forma transparente.

5. Impor isolamento de tenant e segurança detalhada
   • Coloque cada parceiro em um dataset dedicado. Conceda papéis de menor privilégio no nível do dataset aos grupos de parceiros.
   • Publique visualizações autorizadas para benchmarks compartilhados entre parceiros sem revelar as tabelas brutas.
   • Aplique tags de política a colunas de PII e adicione políticas de acesso a linhas na tabela

undefined

para restringir o acesso por

undefined

para análises internas multitenant.

• Justificativa: A segmentação de dataset por tenant, juntamente com visualizações autorizadas e tags de política, impõe o menor privilégio ao mesmo tempo que permite o compartilhamento selecionado.

6. Gerenciar cargas de trabalho com edições, reservas e autoscaling
   • Adquira capacidade nas edições do BigQuery e crie duas reservas:

undefined

(para sinks do Dataflow, transformações agendadas) e

undefined

(para consultas ad hoc/relatórios). Atribua os projetos de acordo e habilite o autoscaling para absorver picos.

• Agende consultas ELT como batch com SLAs claros; defina

undefined

para projetos interativos.

• Justificativa: Reservas separadas evitam que o ETL consuma os recursos do BI. O autoscaling acomoda picos de carga sem superprovisionamento.

7. Governar custos e observar o uso
   • Exija filtros em

undefined

; rejeite

undefined

em visualizações compartilhadas. Use

undefined

para detectar varreduras não eliminadas e joins com distorção.

• Exporte os logs de auditoria do BigQuery para o Pub/Sub com um coletor de logs (log sink) filtrado para jobs de inserção na tabela

undefined

para acionar alertas de monitoramento para picos inesperados.

• Justificativa: A eliminação de bytes (byte-pruning) e a projeção de colunas controlam os custos; os logs de auditoria revelam padrões de acesso e anomalias quase em tempo real.

8. Planejar recuperação e backfills

   • Habilite políticas de expiração de tabela padrão que se alinhem com as necessidades de conformidade e time-travel. Para grandes edições, crie um snapshot, execute as alterações e reverta rapidamente, se necessário. Use clones de tabela para análises de cenário (‘what-if’) em dev/test sem duplicar o armazenamento.
   • Justificativa: Snapshots e clones fornecem redes de segurança rápidas e eficientes em termos de espaço; o time-travel cobre pequenas restaurações corretivas.

9. Integrar ML no próprio warehouse

   • Armazene features de engenharia em tabelas particionadas e treine modelos de classificação do BigQuery ML para risco de readmissão. Para modelos externos hospedados no Vertex AI, crie modelos remotos e armazene as predições em cache em uma tabela clusterizada para joins de baixa latência.
   • Justificativa: Manter o ML próximo aos dados reduz a movimentação e a complexidade da governança; o cache da inferência remota amortiza a latência e o custo.

Com este design, a NovaCare alcança um desempenho previsível sob uma carga 100 vezes maior, forte isolamento de tenant e custos governados, ao mesmo tempo que preserva análises de baixa latência e recuperação reprodutível.

← Armazenamento de Dados · Todos os domínios · Processamento de Streams com Dataflow e Apache Beam →

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

Navegar Google →