Google PDE: Armazenamento de Dados, Data Lakes e Formatos de Arquivo — 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 armazenamento de dados no Google Cloud abrange desde o armazenamento de objetos brutos até data lakes curados e formatos otimizados para análise. A construção de lakes confiáveis, governados e de alto desempenho exige escolhas cuidadosas em classes de armazenamento, configurações de bucket, locais, formatos de arquivo, layout de tabela e ciclo de vida. Esta seção detalha os trade-offs de design, os modos de falha a serem evitados e os padrões que se alinham com o BigQuery, Spark e pipelines de streaming em grande escala.

Fundamentos do Cloud Storage: classes, buckets, consistência e ciclo de vida

O Cloud Storage é a base durável e de alta disponibilidade para arquivos brutos e curados.

• Classes de armazenamento

  • Standard (quente): acesso frequente, menor latência. Sem duração mínima de armazenamento.
  • Nearline (frio): acesso infrequente (~mensal). Mínimo de 30 dias; aplicam-se taxas de recuperação.
  • Coldline (mais frio): acesso infrequente (~trimestral). Mínimo de 90 dias; taxas de recuperação mais altas.
  • Archive (o mais frio): retenção de longo prazo (~anual). Mínimo de 365 dias; taxas de recuperação mais altas.
  • O Autoclass pode fazer a transição automática entre as classes; verifique se as taxas de exclusão antecipada e os padrões de acesso não anularão a economia.

• Locais e replicação de buckets

  • Região: ideal para localidade de dados e conformidade em uma única geografia.
  • Duas regiões: duas regiões emparelhadas com replicação automática; a replicação turbo confirma as réplicas rapidamente com um RPO medido em minutos; ideal para DR de baixo RPO.
  • Várias regiões: geodistribuído em um continente para ampla disponibilidade, distribuição de conteúdo e análises que abrangem uma grande área.
  • Escolha os locais para satisfazer as leis de residência de dados e para minimizar a saída/latência para a computação (Dataproc, Dataflow, tabelas externas do BigQuery).

• Consistência e semântica

  • O Cloud Storage oferece consistência forte global de leitura após gravação, leitura após atualização de metadados e listagem após gravação.
  • As gravações de objetos são atômicas e imutáveis; “renomear” é um padrão de copiar e excluir. Projete para cópias idempotentes e verifique os checksums para evitar migrações parciais.

• Padrões de acesso e desempenho

  • Uploads compostos paralelos e uploads retomáveis melhoram o throughput para arquivos grandes.
  • Leituras de intervalo (range reads) permitem rodapés colunares eficientes e leituras seletivas.
  • Evite muitos arquivos pequenos (<8 MB) que aumentam a sobrecarga de metadados/listagem; agrupe ou compacte em objetos maiores.
  • O GZIP não é divisível (splittable) para leituras distribuídas; prefira Parquet/ORC/Avro+Snappy para processamento escalável.

• Ciclo de vida, retenção e versionamento

  • Políticas de retenção no nível do bucket e bloqueios de objetos (baseados em eventos ou temporários) impõem imutabilidade para conformidade e para reduzir exclusões acidentais.
  • O versionamento de objetos mantém as gerações anteriores; útil para recuperação de sobrescritas/exclusões. Monitore o crescimento do custo de armazenamento.
  • As regras de ciclo de vida automatizam transições e exclusões. Exemplo (JSON) para mover dados mais antigos para classes mais frias e excluir após um ano: { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
  • Modos de falha: cobranças por exclusão antecipada se você fizer a transição de forma muito agressiva; os bloqueios de retenção não podem ser encurtados; o versionamento sem compactação pode aumentar os custos.

• Transferências e migração

  • Use o Storage Transfer Service para movimentações paralelizadas e com checkpoint a partir de ambientes on-prem ou de outras nuvens; use o Transfer Appliance para petabytes offline.
  • Valide a integridade com CRC32C/MD5 e pré-condições de correspondência de geração (generation-match) para evitar condições de corrida (race conditions).
  • Prefira gsutil/gcloud storage com -m (paralelo) e checksums; evite gargalos de SFTP para entrada de alto volume.

Governança unificada de lake com BigLake e Dataplex

O BigLake e o Dataplex padronizam a segurança e a governança em arquivos e tabelas.

• BigLake

  • Expõe dados do Cloud Storage como tabelas gerenciadas pelo BigQuery (externas) com controles de acesso refinados e uniformes, incluindo políticas de acesso em nível de linha e tags de política em nível de coluna.
  • Habilita a eliminação de colunas (column pruning) e o envio de predicados (predicate pushdown) para Parquet/ORC, reduzindo os bytes lidos e a saída para mecanismos como BigQuery, Spark no Dataproc e Dataflow.
  • Centraliza a auditoria via Cloud Logging e a aplicação de políticas centralizadas; um único plano de controle para arquivos do lake e tabelas do warehouse.

• Dataplex

  • Organiza os dados em lakes, zonas (bruta, curada, confiável) e ativos (buckets, datasets); gerencia metadados, linhagem e regras de qualidade de dados.
  • Integra-se com tags de política para colunas sensíveis e suporta o princípio do menor privilégio via IAM nos escopos de lake/zona/ativo.
  • Incentiva a padronização de nomes, particionamento e gerenciamento de esquemas em ambientes com várias equipes para evitar “gavetas de bagunça”.

• Padrões de governança

  • Implemente padrões de dataset por locatário (tenant) e bucket por zona; evite o vazamento de dados entre locatários.
  • Use políticas de acesso em nível de linha e tags de política em nível de coluna para PII. Restrinja o acesso à API a identidades aprovadas.
  • Audite o acesso com o Cloud Logging; roteie logs filtrados para o Pub/Sub para monitoramento em tempo real.

Formatos de arquivo, compressão e comportamento de consulta

A escolha do formato correto tem efeitos diretos no custo e no desempenho.

• Formatos colunares (Parquet, ORC)

  • Pontos fortes: poda de colunas (column pruning), predicate pushdown, codificação e compressão por coluna, estatísticas e arquivos divisíveis (splittable).
  • Compromissos: maior uso de CPU no momento da escrita; a evolução do schema deve ser gerenciada com cuidado (ex: adicionar colunas é seguro; alterações de tipo são arriscadas).
  • Compressão: Snappy para velocidade, ZSTD para melhores taxas de compressão onde for compatível. Evite GZIP para formatos colunares, a menos que restrições de interoperabilidade o exijam.

• Avro, orientado a linhas

  • Pontos fortes: evolução de schema com tipagem forte, compressão em nível de bloco, divisível (splittable); excelente para landing zones de streaming e intercâmbio de dados.
  • Compromissos: menos eficiente para varredura (scan) em analytics do que os formatos colunares; converta para Parquet/ORC em zonas de dados curadas (curated zones).

• CSV e JSON (semiestruturados)

  • CSV: legível por humanos, menor sobrecarga (overhead) quando os valores são simples; não possui schema, tipos e consistência de caracteres de escape; caro para analisar (parse) em grande escala.
  • JSON: autodescritivo e flexível; JSON delimitado por nova linha (newline-delimited) é necessário para leituras distribuídas escaláveis; verboso e com alto consumo de CPU para analisar (parse).
  • Sempre que possível, armazene os dados brutos (raw) em CSV/JSON, depois valide e converta para Avro/Parquet para fins de analytics.

• Tabelas externas do BigQuery e tabelas do BigLake

  • Tabelas externas Parquet/ORC se beneficiam de predicate pushdown e poda de colunas (column pruning); tabelas CSV/JSON geralmente não, o que leva a um maior volume de bytes lidos (scanned bytes).
  • Tabelas externas CSV compactadas com GZIP não podem ser divididas entre os workers; espere leituras mais lentas.
  • Exemplo: criando uma tabela Parquet no BigLake com partições no estilo Hive: CREATE EXTERNAL TABLE lake.sales WITH CONNECTION us.biglake_conn OPTIONS ( format = ‘PARQUET’, hive_partitioning_mode = ‘AUTO’, hive_partitioning_source_uri_prefix = ‘gs://corp-raw/sales/’, uris = [‘gs://corp-raw/sales/date=/region=/part-*.parquet’] );

Layout, particionamento, engenharia de performance, residência e migração

• Layout e particionamento de objetos

  • Adote caminhos no estilo Hive para partições e chaves de clusterização: gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
  • Mantenha os tamanhos de arquivo individuais na faixa de 128–1024 MB para um paralelismo balanceado e sobrecarga de tarefas. Evite milhões de arquivos por partição.
  • Mitigue problemas de arquivos pequenos:
    • Fazendo uploads em lote no lado do cliente.
    • Usando jobs de compactação do Dataflow/Spark para unificar arquivos pequenos fora do horário de pico.
    • Arquivando os arquivos pequenos originais e expondo apenas os dados compactados para análise.

• Particionamento e clusterização no BigQuery

  • Particione pelo horário de ingestão ou por uma coluna de filtro de alta cardinalidade (ex: event_date). Evite o particionamento excessivo (ex: por minuto) que explode os metadados.
  • Clusterize por dimensões comumente filtradas/classificadas (até quatro). A clusterização aumenta a localidade dos dados e reduz os bytes escaneados.
  • Prefira tabelas nativas do BigQuery para análises interativas pesadas; use BigLake/externas para acesso governado ao lake, compartilhamento entre mecanismos e isolamento de custos.

• Implicações no desempenho de consultas

  • Formatos colunares reduzem significativamente os custos de escaneamento externo; tabelas externas CSV/JSON geralmente exigem escaneamentos de arquivos completos.
  • As garantias de consistência eliminam a necessidade de atrasos artificiais nas leituras do Cloud Storage, mas sistemas downstream (ex: inserções por streaming no BigQuery) podem exibir um pequeno atraso na visibilidade dos dados — projete com marcas d’água (watermarks) ou atrasos de leitura quando necessário.

• Residência, durabilidade e recuperação

  • Selecione os locais de bucket/dataset para atender às restrições de residência; colocalize a computação para reduzir a saída de dados (egress) e a latência.
  • Use dual-region com replicação turbo para um RPO baixo; versionamento mais políticas de retenção para recuperabilidade de erros humanos e ransomware.
  • Para DR (Disaster Recovery), replique buckets para um projeto/região separado usando a replicação de bucket e proteja com limites de IAM separados.

• Migração e validação seguras

  • Planeje em múltiplas fases: semeadura (transferência em massa), sincronização incremental (cópia por mtime/janela de tempo), transição (fonte somente leitura) e validação pós-transição.
  • Valide com checksums, contagens, totais de bytes e decodificação de amostras. Para dados tabulares, compare contagens de linhas e agregados de hash:

undefined

• Use pré-condições (ifGenerationMatch) para evitar sobrescritas durante a cópia paralela. Mantenha uma janela de rollback com versionamento ou a fonte retida.
• Após a migração, habilite o ciclo de vida (lifecycle) e o Autoclass de acordo com o novo perfil de acesso; evite habilitar a trava de retenção (retention lock) até que as validações sejam aprovadas.

Cenário de Problema Prático

A Acme Retail recebe entregas diárias de CSVs de um parceiro de logística em um bucket regional do Cloud Storage. Ocasionalmente, os arquivos contêm linhas malformadas. A Acme deve receber, validar, converter para um formato pronto para análise e carregar no BigQuery para dashboards quase em tempo real, enquanto retém as linhas inválidas para inspeção e aplica governança.

Abordagem:

1. Receber e governar dados brutos no Dataplex

   • Crie um lake no Dataplex com um ativo de zona bruta (raw zone) mapeado para gs://acme-raw/logistics/.
   • Justificativa: Governança, metadados e linhagem centralizados. Aplicar IAM no nível da zona e marcar campos sensíveis com tags de política (policy tags) para aplicação downstream.

2. Aplicar ciclo de vida e retenção

   • Aplique uma política de retenção de 30 dias no bucket e habilite o versionamento de objetos em acme-raw.
   • Justificativa: Protege contra sobrescrita/exclusão acidental pelo parceiro; a retenção curta equilibra custo e recuperabilidade. O versionamento facilita o rollback de entregas ruins.

3. Validar e ingerir com um pipeline em lote do Dataflow

   • Acione um job diário do Dataflow com base em notificações de finalização de objeto. Leia o CSV com esquema e validação por registro; grave os registros válidos em uma área de preparação (staging) do BigQuery (particionada por event_date) e roteie os erros de análise/validação para uma tabela de mensagens mortas (dead-letter) do BigQuery.
   • Justificativa: O Dataflow fornece análise paralela escalável e tratamento robusto de mensagens mortas (dead-letter) para que os analistas possam inspecionar as linhas inválidas. Isso espelha a melhor prática para qualidade heterogênea de CSVs.

4. Compactar e converter para Parquet na zona curada

   • O mesmo pipeline grava os dados validados em gs://acme-curated/logistics/date=YYYY-MM-DD/ como arquivos Parquet com tamanho de ~256–512 MB.
   • Justificativa: O Parquet permite a eliminação de colunas (column pruning) e o empurramento de predicados (predicate pushdown) no BigQuery e no Spark, reduzindo os bytes escaneados e melhorando a latência; a compactação mitiga a sobrecarga de arquivos pequenos do padrão de entrega do parceiro.

5. Expor análises governadas via BigLake

   • Crie uma tabela externa do BigLake sobre o caminho do Parquet curado com particionamento automático do Hive; aplique tags de política no nível da coluna e políticas de acesso no nível da linha para filtros específicos do parceiro.
   • Justificativa: Acesso refinado e uniforme no BigQuery e no Spark com auditoria centralizada. A eliminação de partições (partition pruning) reduz os custos de escaneamento em filtros de data.

6. Carregar agregados críticos para o BigQuery nativo

   • Para dashboards de acesso frequente (hot), execute um job agendado do BigQuery que ingere os últimos N dias da tabela externa de Parquet curado para uma tabela nativa particionada e clusterizada.
   • Justificativa: O armazenamento nativo acelera o BI de alta concorrência, enquanto a tabela externa do BigLake permanece como o sistema de registro (system-of-record) governado para um acesso mais amplo.

7. Monitorar e alertar com Cloud Logging e Pub/Sub

   • Crie um coletor de logs (log sink) filtrando os resultados dos jobs de carregamento do Dataflow e do BigQuery para o Pub/Sub; integre com a ferramenta de monitoramento para alertas instantâneos sobre falhas ou taxas elevadas de linhas inválidas.
   • Justificativa: Visibilidade operacional direcionada e específica da tabela sem a necessidade de polling; dá suporte às práticas de SRE.

8. Otimizar classe de armazenamento e residência

   • Mantenha o Parquet curado em Standard por 14 dias, transicione para Coldline após 30 dias via regra de ciclo de vida; armazene os buckets brutos e curados na mesma região que os datasets do BigQuery para evitar saída de dados (egress).
   • Justificativa: Equilibra o desempenho de leitura frequente (hot) com o custo. A colocalização mantém a conformidade e minimiza a latência e as taxas de saída de dados (egress).

9. Validar a qualidade de ponta a ponta

   • Após cada execução, compare contagens e agregados de hash entre as tabelas de preparação (staging), externa curada e nativa do BigQuery; coloque anomalias em quarentena.
   • Justificativa: Detecção precoce de desvio de esquema (schema drift) ou regressões na ingestão; hashes criptográficos ou de impressão digital (fingerprint) fornecem uma garantia leve sem reescaneamentos completos.

Este design fornece uma ingestão resiliente com análise de mensagens mortas (dead-letter), Parquet pronto para análise para consultas eficientes, governança centralizada via Dataplex e BigLake e políticas de ciclo de vida otimizadas para custos, tudo isso aderindo ao acesso de privilégio mínimo e a operações auditáveis.

← Arquitetura e Design de Engenharia de Dados · Todos os domínios · Analytics com BigQuery e Engenharia de Data Warehouse →

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

Navegar Google →