Google PCA: Armazenamento de Dados, Bancos de Dados e Arquitetura de Analytics — Guia de estudos

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Visão Geral

Projetar armazenamento de dados, bancos de dados e analytics no Google Cloud requer a correspondência de padrões de carga de trabalho com os serviços, ao mesmo tempo em que se planeja para durabilidade, disponibilidade, controle de acesso, custo e resiliência operacional. Esta seção abrange armazenamento de objetos e governança de ciclo de vida; bancos de dados operacionais e caches; armazenamento (warehousing) e processamento para analytics; arquiteturas de ingestão; e práticas de governança, proteção e desempenho. Ela destaca escolhas de design, raciocínio operacional e modos de falha ou trade-offs comuns.

Arquitetura de Armazenamento e Objetos

Design de buckets do Cloud Storage

Localização: escolha uma região para cargas de trabalho de baixa latência e sensíveis a custos; dual-region para continuidade de negócios com failover previsível; multi-region para acesso de leitura global. A dual-region oferece replicação turbo opcional para um RPO baixo e com garantia de SLA; caso contrário, a replicação é assíncrona.
Namespace e separação: use buckets separados para domínios de dados, ambientes e níveis de sensibilidade. Empregue acesso uniforme no nível do bucket e prevenção de acesso público para permissões consistentes.
Classes de armazenamento: Standard para dados de acesso frequente (hot); Nearline para acesso pouco frequente (mensal); Coldline para acesso trimestral; Archive para retenção de longo prazo. O Autoclass pode otimizar a alocação de classes automaticamente com trabalho operacional mínimo.
Políticas de ciclo de vida: automatize a transição e a exclusão por idade, classe de armazenamento ou prefixo de objeto. Exemplo para excluir objetos com mais de 90 dias: { “rule”: [ { “action”: {“type”: “Delete”}, “condition”: {“age”: 90} } ] } Aplique com: gsutil lifecycle set lifecycle.json gs://my-bucket
Retenção e bloqueios legais (legal holds): configure políticas de retenção de bucket e, opcionalmente, bloqueie-as para impedir a redução (conformidade/compliance). Bloqueios baseados em eventos (event-based holds) e o versionamento de objetos permitem a recuperação de exclusões ou substituições acidentais.
Replicação: escolha dual-region para semântica de consistência síncrona na API com replicação em segundo plano entre duas regiões; use a replicação de bucket para bucket (para cópias entre projetos ou localidades) para atender a RPO/RTO especializados ou à separação de funções.

Modos de falha e trade-offs

A incompatibilidade de classes aumenta o custo e a latência. O Autoclass reduz isso, mas adiciona uma sobrecarga de gerenciamento por objeto.
O bloqueio de retenção (retention lock) é irreversível; teste as políticas em ambientes de não produção.
A replicação melhora a durabilidade, mas pode aumentar a latência de escrita e o custo; projete os caminhos de leitura/escrita para as localidades alvo.

Padrões

Data lake: zonas de dados brutos (raw) e curados no Cloud Storage; governança via Dataplex; esquemas externalizados no Data Catalog.
Arquivamento (Archival): classe Archive com bloqueio de retenção para conformidade (compliance), com tabelas externas do BigQuery ou restauração sob demanda para análises raras.
Lakehouse: use o BigLake para unificar o acesso entre o Cloud Storage e o BigQuery com segurança consistente.

Datastores Operacionais e Caching

Cloud SQL

Alta disponibilidade: HA regional com replicação síncrona para uma instância de standby; failover automático geralmente em segundos a alguns minutos. O endpoint da instância permanece o mesmo, minimizando alterações na aplicação.
Réplicas de leitura: dentro da região (within-region) ou entre regiões (cross-region), assíncronas; boas para escalabilidade horizontal de leitura (read scale-out) e DR. Monitore o lag; leituras de dados desatualizados (stale reads) podem afetar a corretude.
Backups e PITR: backups agendados mais recuperação point-in-time (PITR) usando logs de transação (geralmente uma janela de até 7 dias, dependendo do engine). Teste a restauração regularmente.
Conectividade privada: IP privado via VPC peering reduz a exposição e a latência; planeje os intervalos de IP para evitar sobreposição.
Migração: o Database Migration Service suporta migrações com baixo tempo de inatividade (low-downtime) de ambientes on-premise ou de outras nuvens; para links de alto volume, prefira o Dedicated ou Partner Interconnect em vez de VPN para reduzir a perda de pacotes e a latência.

Trade-offs e modos de falha

Failovers de HA reiniciam as conexões; as aplicações devem tentar novamente com backoff. Janelas de manutenção podem degradar brevemente o desempenho.
Transações de longa duração aumentam o lag de replicação e o tempo de recuperação do PITR.
Armazenamento superprovisionado é um seguro barato; IOPS subprovisionado causa falhas latentes durante picos de uso.

Cloud Spanner

Escala global e consistência: leituras/escritas fortemente consistentes entre regiões usando TrueTime e two-phase commit. Escolha regional para a menor latência de escrita; multirregional para maior disponibilidade e leituras globais.
Transações: consistência externa e totalmente ACID entre linhas e tabelas; transações somente de leitura escalam entre as réplicas.
Design de schema: escolha chaves primárias que evitem hotspots; use tabelas intercaladas (interleaved tables) para localidade; considere a amplificação de escrita (write amplification) e o comportamento de backfill dos índices secundários.
Regionalidade: o posicionamento da região líder (leader region) determina a latência de escrita; a configuração multirregional adiciona custos de quórum e latência de commit.

Trade-offs

A latência de escrita aumenta com a dispersão geográfica; evite a configuração multirregional, a menos que a disponibilidade e a distribuição global justifiquem.
O custo base é maior do que o de bancos de dados em VMs de nó único; o planejamento de capacidade deve estar alinhado com os SLOs e o crescimento.

Firestore, Bigtable, Memorystore e seleção

Firestore: banco de dados de documentos para backends mobile/web; consistência forte para documentos únicos; segurança de grão fino; indexação automática. Cuidado com a contenção em documentos atualizados com frequência; use contadores distribuídos e escritas em lote (batched writes).
Bigtable: banco de dados de colunas largas (wide-column), escala de petabytes, latência ultrabaixa para séries temporais e IoT; projete as chaves de linha (row keys) para evitar hotspots (ex: hashing ou salting); escale por nós e clusters; roteamento multicluster para disponibilidade. A replicação é assíncrona; a consistência forte é por cluster.
Memorystore for Redis: cache em memória; o nível Basic é uma instância única (sem HA); o nível Standard fornece réplica e failover automático (desconexões breves são possíveis). Trate como um cache, não como a fonte da verdade; os recursos de persistência reduzem a volatilidade, mas não substituem os backups do banco de dados.

Seleção orientada pela carga de trabalho (workload)

Relacional com joins/ACID e escala moderada: Cloud SQL.
Relacional global com escala horizontal e consistência externa: Cloud Spanner.
Séries temporais/telemetria de alta vazão (throughput) ou chave-valor muito grande: Bigtable.
Modelos de documento centrados na aplicação com consultas hierárquicas: Firestore.
Aceleração efêmera e limitação de taxa (rate limiting): Memorystore.

Analytics, Ingestão e Processamento

BigQuery

Datasets: limites lógicos de segurança e faturamento; adote convenções de nomenclatura por domínio e estágio do ciclo de vida.
Particionamento: por tempo de ingestão ou por coluna para filtragem temporal; também particionamento por intervalo de inteiros. Use particionamento por unidade de tempo em

undefined

para otimizar (prune) as varreduras.

Clusterização: até quatro colunas para colocalizar dados relacionados no armazenamento; melhora o desempenho e o custo de consultas seletivas.
Reservations: gerencie slots dedicados via reservas e atribuições; use flex slots para experimentos com picos de uso (bursty); isole workloads críticos para evitar inanição (starvation).
Controle de acesso: IAM no nível do projeto e do dataset; controle de tabela/coluna com políticas de nível de linha (row-level policies) e policy tags; compartilhe dados selecionados (curated) por meio de visualizações e rotinas autorizadas.

Exemplo útil:

undefined

Trade-offs e modos de falha

Particionamento inadequado leva a varreduras completas da tabela (full-table scans) e custos descontrolados.
A clusterização só ajuda quando filtros ou joins incluem as colunas clusterizadas; reorganizações (reshuffles) frequentes podem reduzir o benefício.
Subprovisionamento de slots enfileira os jobs; superprovisionamento aumenta o custo. Monitore a utilização de slots e o “spilled shuffle”.

Ingestão e processamento de dados

Pub/Sub: entrega global, durável e “at-least-once”; chaves de ordenação (ordering keys) garantem a ordem por chave com trade-offs de throughput. Projete consumidores idempotentes.
Dataflow: processamento unificado em lote (batch) e streaming com autoscaling, processamento stateful “exactly-once”, janelamento (windowing) e gatilhos (triggers); o Streaming Engine descarrega o estado. Use tópicos de dead-letter e fontes que permitam reprocessamento (replayable sources).
Dataproc: Spark/Hadoop gerenciado para código e ecossistemas existentes; clusters efêmeros ou com autoscaling; use para bibliotecas de ML ou quando a portabilidade for custosa.

Trade-offs entre Batch e Streaming

Streaming reduz a latência e suporta tempo real, mas aumenta a complexidade (estado, watermarking, dados atrasados) e os custos contínuos.
Batch simplifica a corretude e o controle de custos; é aceitável quando os SLAs toleram atraso.
Padrões híbridos: armazene eventos brutos no Cloud Storage, envie KPIs agregados por streaming para o BigQuery e execute recomputações noturnas em batch para garantir a precisão.

Padrões de Warehouse

Warehouse: BigQuery como o sistema de análise; views materializadas e consultas agendadas para servir ao BI.
Lakehouse: gerencie dados no Cloud Storage com formatos abertos; exponha através do BigLake para o BigQuery com segurança consistente.

Governança, Proteção e Desempenho

Governança e segurança de dados

Metadados e linhagem: use o Data Catalog para metadados técnicos e de negócios; habilite a captura de linhagem do Dataflow, BigQuery e Dataproc para rastrear dependências.
Qualidade: aplique regras com a qualidade de dados do Dataplex e orquestre verificações no Composer ou Dataform; coloque registros ruins em quarentena.
Limites de acesso: VPC Service Controls em torno do BigQuery e Cloud Storage para reduzir o risco de exfiltração; IAM Conditions para acesso sensível ao contexto; CMEK para controle criptográfico; tags de política (policy tags) para restrições em nível de coluna.
Retenção: alinhe a retenção de buckets do Cloud Storage, o time travel de tabelas do BigQuery (configurável até 7 dias) e a expiração de datasets/tabelas com os requisitos legais.

Backup, PITR e proteção contra exclusão

Validar backups: restaure periodicamente backups do Cloud SQL e Spanner em ambientes isolados e execute checksums e validações em nível de aplicação.
Bigtable: habilite o PITR para recuperar para um timestamp dentro de uma retenção configurada; teste restaurações em nível de tabela ou cluster.
Spanner: use backups para recuperação de desastres (disaster recovery); aproveite leituras desatualizadas (stale reads) dentro da retenção de versão para consultas de auditoria.
Cloud Storage: habilite o versionamento de objetos e o bloqueio de retenção do bucket (bucket retention lock) para proteger contra exclusões acidentais; replique para um projeto separado para isolamento de erros de operador.
BigQuery: use time travel e snapshots de tabela; evite drop em datasets de produção com aprovações necessárias e proteção contra exclusão em nível de dataset.

Desempenho de dados e controle de custos

Evitar chaves quentes (hot keys): distribua as chaves de linha (row keys) do Bigtable (prefixos de hash), escolha chaves primárias do Spanner que randomizam as eleições de liderança (leadership elections), fragmente (shard) contadores do Firestore.
Índices: mantenha os índices SQL e NoSQL necessários; no BigQuery, clusterize por filtros comuns; no Cloud SQL, monitore consultas lentas e execute vacuum/analyze no Postgres regularmente.
Planejamento de capacidade: estabeleça uma linha de base (baseline) com testes de carga; defina SLOs e orçamentos de erro (error budgets); monitore a utilização de slots do BigQuery, latências de CPU/leitura-modificação-escrita do Bigtable, CPU/IOPS do Cloud SQL e o backlog do Pub/Sub.
Controles de custo: use compromissos de slot (slot commitments) do BigQuery para cargas de trabalho estáveis, Autoclass para o Cloud Storage, compacte tabelas do Bigtable e ajuste os filtros de Bloom, expire partições e datasets antigos e implemente orçamentos e alertas por equipe.

Cenário de Problema Prático

O Acme Retail Group precisa de uma plataforma unificada de análise de pedidos e clickstream de baixa latência. Requisitos: KPIs em tempo real em até 10 segundos, análise histórica de cinco anos com SQL, objetivos de recuperação abaixo de uma hora, residência de dados estrita nos EUA e prevenção de perda acidental de dados.

Receber eventos brutos e implementar ingestão durável

Crie buckets do Cloud Storage de região dupla (dual-region) us-central1/us-east1 para zonas de dados brutos (raw) e curados (curated); habilite o Autoclass e o versionamento de objetos na zona de dados brutos.
Justificativa: a região dupla atende aos requisitos de durabilidade e residência; o versionamento protege contra backfills mal-sucedidos; o Autoclass otimiza o custo de armazenamento automaticamente.

Transmitir eventos de forma confiável com Pub/Sub e Dataflow

Publique eventos de clickstream e pedidos em tópicos do Pub/Sub com chaves de ordenação (ordering keys) por user_id; implemente um pipeline de streaming do Dataflow para validar, desduplicar, enriquecer e ramificar a saída para o BigQuery (KPIs quentes) e o Cloud Storage (parquet na zona curada).
Justificativa: o Pub/Sub oferece entrega global, durável e do tipo ‘pelo menos uma vez’ (at-least-once); o Dataflow oferece estado ’exatamente uma vez’ (exactly-once) e autoescalabilidade; a ramificação mantém um padrão de lakehouse para reprocessamento.

Servir features em tempo real com Bigtable e Redis

Escreva um subconjunto de eventos enriquecidos no Bigtable com uma chave de linha (row key) com sal (salted) no formato user_id#timestamp; use o Memorystore for Redis como um cache frontal para as sessões mais recentes.
Justificativa: o Bigtable oferece escritas de baixa latência e alta taxa de transferência (throughput) para séries temporais; o uso de sal (salting) evita hotspots; o Redis reduz a latência de cauda (tail latency) para personalização ao vivo.

Armazenar e otimizar consultas no BigQuery

Crie datasets particionados por event_date e clusterizados por user_id, channel. Use visualizações materializadas (materialized views) para KPIs e compactações agendadas para cargas de arquivos pequenos; adquira uma reserva de slots de linha de base (baseline) com um pequeno buffer de slots flexíveis (flex slots) para picos de uso.
Justificativa: particionamento e clusterização eliminam varreduras (prune scans) e reduzem o custo; visualizações materializadas aceleram dashboards; as reservas limitam o custo e protegem cargas de trabalho críticas de entrarem em fila.

Governar o acesso e prevenir a exfiltração

Aplique IAM em nível de dataset para grupos de analistas; use tags de política (policy tags) para restringir colunas com PII e visualizações autorizadas (authorized views) para acesso de fornecedores. Imponha VPC Service Controls em torno do BigQuery e Cloud Storage; use CMEK para datasets regulamentados.
Justificativa: princípio do menor privilégio (least-privilege) nos níveis de dataset e coluna; o VPC SC reduz o risco de exfiltração de dados; o CMEK satisfaz os requisitos de controle criptográfico.

Implementar backups, PITR e testes de restauração

Habilite o PITR do Bigtable por 7 a 14 dias; crie backups semanais do Spanner ou Cloud SQL para os armazenamentos de pedidos transacionais; crie snapshots diários de tabelas críticas do BigQuery e confie no time travel para erros. Execute simulações de restauração (restore drills) trimestralmente em um projeto isolado.
Justificativa: opções de recuperação em camadas abordam erros lógicos e desastres; simulações regulares validam RPO/RTO e runbooks.

Controlar a retenção e o ciclo de vida dos dados

Aplique uma regra de ciclo de vida (lifecycle rule) para purgar objetos brutos após 30 dias e curados após cinco anos; bloqueie uma política de retenção em nível de bucket que atenda à conformidade. Defina a expiração padrão de datasets/tabelas do BigQuery para datasets transitórios.
Justificativa: a aplicação automática reduz o risco operacional; o bloqueio de retenção (retention lock) impede o enfraquecimento acidental ou não autorizado da política.

Monitorar desempenho e custo, e mitigar hotspots

Acompanhe a utilização de slots do BigQuery, bytes escaneados e a concorrência de consultas de BI; monitore a CPU do Bigtable e a latência de leitura-modificação-escrita; alerte sobre o backlog do Pub/Sub. Se surgirem hotspots de user_id, aumente a largura do sal (salt width) e faça o backfill das chaves via Dataflow.
Justificativa: a telemetria contínua encontra gargalos precocemente; mudanças proativas na estratégia de chaves preservam os SLOs sem uma rearquitetura completa.

Fornecer conectividade privada e isolamento

Para dependências híbridas, use o Partner ou Dedicated Interconnect com o Cloud Router; garanta faixas de IP que não se sobreponham; use o Private Service Connect para endpoints de serviços gerenciados.
Justificativa: caminhos privados reduzem a latência e a perda de pacotes; um planejamento de IP claro e o PSC impõem isolamento e roteamento previsível.

Operacionalizar a confiabilidade

Habilite pipelines canary do Dataflow e visualizações blue/green do BigQuery; imponha a evolução do esquema por meio de aprovações no Data Catalog; integre filas de mensagens mortas (dead-letter queues) com a resposta a incidentes.
Justificativa: implantações controladas (rollouts) limitam o raio de impacto (blast radius); alterações de esquema governadas mantêm a qualidade dos dados; DLQs garantem que nenhum dado seja perdido durante incidentes.

← Computação · Todos os domínios · Redes →

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