Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame ADP avalia. Leia de cima a baixo ou pule para uma seção.
Carregar arquivos em lote grandes (CSV, Parquet, Avro) do Cloud Storage para o BigQuery.
Use um trabalho de carregamento do BigQuery. Especifique um URI curinga (por exemplo, `gs://bucket/path/*`) para carregar vários arquivos em um único trabalho.
Por quê: Este é o método mais rápido e econômico para ingestão em lote. Os trabalhos de carregamento são gratuitos. Evita custos por linha de streaming.
Ingerir dados de alto volume e em tempo real (IoT, clickstream) com potencial para transformação.
Pub/Sub -> Dataflow -> BigQuery.
Por quê: Padrão canônico de streaming escalável. O Pub/Sub fornece um buffer durável e escalável. O Dataflow permite transformações complexas, janelamento e processamento exactly-once.
Replicar um banco de dados operacional (MySQL, PostgreSQL, Oracle) para o BigQuery com baixa latência, capturando todas as alterações (inserções, atualizações, exclusões).
Use o Datastream para Change Data Capture (CDC).
Por quê: Desenvolvido especificamente para CDC de baixo impacto e em tempo real. Ele lida com o backfill inicial e transmite alterações contínuas diretamente para o BigQuery.
Realizar validação, enriquecimento ou transformação de dados complexos (por exemplo, nivelamento de JSON/XML aninhado) antes de carregar no BigQuery.
Use um pipeline do Dataflow com transformações customizadas do Apache Beam (por exemplo, ParDo).
Por quê: O Dataflow oferece máxima flexibilidade para código customizado (Python/Java), lógica complexa e roteamento de registros inválidos para uma fila de mensagens mortas.
Transferir terabytes ou petabytes de dados de outra nuvem (por exemplo, S3) ou de um data center on-premises para o Cloud Storage.
Para cloud-to-cloud, use o Storage Transfer Service. Para on-prem com largura de banda de rede limitada, use o Transfer Appliance.
Por quê: O STS é um serviço gerenciado de alta performance para transferências online. O Transfer Appliance é para transferências offline (envio físico) quando a rede é o gargalo.
Consultar dados residentes no Cloud Storage ou Amazon S3 diretamente do BigQuery sem carregá-los.
Crie uma Tabela Externa do BigQuery. Para governança unificada com Spark, use uma Tabela BigLake.
Por quê: Evita a duplicação de dados e custos de armazenamento no BigQuery. O BigLake adiciona segurança granular (nível de linha/coluna) e governança sobre dados de armazenamento de objetos.
Um pipeline de ingestão deve se adaptar automaticamente quando novas colunas são adicionadas aos arquivos de origem (JSON, Avro).
Configure o trabalho de carregamento do BigQuery com `schemaUpdateOptions` definido como `ALLOW_FIELD_ADDITION`.
Por quê: Automatiza a evolução do esquema. O BigQuery adiciona as novas colunas ao esquema da tabela sem falhar o trabalho de carregamento.
Transmitir dados de alto volume para o BigQuery com semântica exactly-once a um custo menor do que a API de streaming legada.
Use a API BigQuery Storage Write.
Por quê: Oferece maior throughput e custos mais baixos do que a API `insertAll` mais antiga, com fortes garantias como entrega exactly-once dentro de um fluxo.
Orquestrar um fluxo de trabalho complexo com múltiplas tarefas dependentes (por exemplo, Dataflow, BigQuery, Cloud Functions) em um agendamento.
Use o Cloud Composer (Apache Airflow gerenciado).
Por quê: O padrão para orquestração de fluxo de trabalho complexo. Fornece DAGs para definir dependências, agendamento, novas tentativas, alertas e um rico ecossistema de operadores.
Um DAG do Cloud Composer precisa pausar e esperar que um arquivo específico apareça em um bucket do Cloud Storage antes de prosseguir.
Use o `GCSObjectExistenceSensor` no DAG do Airflow.
Por quê: Este é o padrão "sensor" idiomático do Airflow para esperar por condições externas. É mais eficiente do que um loop de polling customizado em um PythonOperator.
Um pipeline de streaming do Dataflow precisa agregar eventos corretamente por carimbo de data/hora, mesmo que os eventos cheguem fora de ordem ou atrasados.
Use o janelamento por tempo de evento com watermarks e configure `allowedLateness`.
Por quê: Este recurso principal do Dataflow/Beam agrupa os dados corretamente com base em quando o evento ocorreu, não em quando foi processado. `allowedLateness` evita que dados atrasados sejam descartados.
Executar trabalhos Apache Spark em larga escala e não interativos para processamento em lote ou ML.
Use um cluster Dataproc. Para máxima economia de custos, use um cluster efêmero com Spot VMs (anteriormente VMs preemptivas).
Por quê: O Dataproc é o serviço gerenciado de Spark/Hadoop. Clusters efêmeros existem apenas pela duração do trabalho, e as Spot VMs oferecem grandes descontos para cargas de trabalho tolerantes a falhas.
Criar um pipeline Dataflow padronizado que pode ser executado por diferentes equipes com parâmetros variados (por exemplo, caminhos de entrada/saída).
Empacote o pipeline como um Dataflow Flex Template.
Por quê: Os Flex Templates são o padrão moderno para trabalhos Dataflow reutilizáveis. Eles são baseados em contêineres, suportam dependências personalizadas e aceitam parâmetros de tempo de execução.
Uma tarefa em um DAG do Cloud Composer falha intermitentemente devido a problemas externos temporários (por exemplo, limitação de taxa de API, contenção de recursos).
Configure `retries` e `retry_delay` com `retry_exponential_backoff=True` para a tarefa.
Por quê: Isso torna o pipeline resiliente ao tentar automaticamente novamente as tarefas falhas com atrasos crescentes, frequentemente resolvendo problemas transitórios sem intervenção manual.
Um pipeline de streaming do Dataflow está atrasado, exibindo alta latência do sistema ou frescor dos dados.
Investigue as métricas de monitoramento do Dataflow. Verifique se o autoescalonamento está atingindo o limite de `maxNumWorkers`. Aumente `maxNumWorkers` ou mude para um tipo de máquina maior.
Por quê: Alta latência do sistema é um indicador primário de capacidade de processamento insuficiente. O pipeline precisa de mais ou maiores workers para acompanhar o influxo de dados.
Otimizar uma tabela grande do BigQuery para custo e desempenho de consulta.
Particione a tabela por uma coluna de unidade de tempo frequentemente filtrada (por exemplo, data da transação). Agrupe a tabela por outras colunas de alta cardinalidade e frequentemente filtradas (por exemplo, `customer_id`).
Por quê: O particionamento é a forma mais eficaz de reduzir custo e latência, podando a quantidade de dados escaneados. O agrupamento melhora ainda mais o desempenho, ordenando os dados dentro das partições.
Impedir que dados de um conjunto de dados sensível do BigQuery sejam copiados para um destino não autorizado (por exemplo, um bucket GCS público), mesmo por um usuário com credenciais válidas.
Use os Controles de Serviço VPC para criar um perímetro de serviço em torno do projeto que contém o conjunto de dados do BigQuery.
Por quê: Os Controles de Serviço VPC atuam como um "firewall virtual" para os serviços GCP, impedindo que os dados saiam do perímetro. Este é um controle crítico de defesa em profundidade contra a exfiltração de dados.
Restringir o acesso a colunas sensíveis (por exemplo, PII) em uma tabela do BigQuery a grupos autorizados, permitindo que outros consultem as colunas restantes.
Use o Data Catalog para criar uma taxonomia e tags de política. Aplique tags de política a colunas sensíveis e conceda a função "Fine-Grained Reader" a grupos autorizados.
Por quê: Este é o método nativo e escalável para segurança em nível de coluna no BigQuery. Ele fornece governança centralizada sem a necessidade de criar e gerenciar visualizações separadas.
Filtrar uma tabela para que os usuários vejam apenas as linhas que lhes pertencem (por exemplo, gerentes de vendas veem apenas os dados de sua própria região).
Crie uma Política de Segurança em Nível de Linha na tabela que filtra as linhas com base em `SESSION_USER()`.
Por quê: Fornece filtragem dinâmica baseada em predicados no momento da consulta. Isso é mais seguro e gerenciável do que criar uma visualização autorizada para cada usuário ou função.
Excluir automaticamente dados de uma tabela do BigQuery após um período de retenção especificado para cumprir regulamentações (por exemplo, excluir dados com mais de 7 anos).
Para dados de séries temporais, defina uma expiração de partição na tabela particionada por tempo. Para outras tabelas, defina a expiração padrão da tabela.
Por quê: Este é um recurso integrado e "configure e esqueça" que garante a conformidade sem scripts de limpeza manuais ou orquestração externa.
Uma tabela do BigQuery foi acidentalmente modificada ou excluída.
Use o BigQuery Time Travel para consultar a tabela como ela existia em um ponto no tempo antes do incidente, usando `FOR SYSTEM_TIME AS OF`.
Por quê: O BigQuery mantém automaticamente um histórico de 7 dias dos dados da tabela. Isso permite a recuperação instantânea dentro da janela de tempo de viagem sem a necessidade de restaurar de backups.
Descobrir, gerenciar, proteger e monitorar ativos de dados (BigQuery, GCS) em toda uma organização.
Use o Dataplex.
Por quê: O Dataplex atua como um data fabric inteligente, fornecendo um painel unificado para governança de dados, qualidade, linhagem, descoberta e gerenciamento do ciclo de vida em silos de dados díspares.
Compreender e visualizar como os dados fluem dos sistemas de origem, através dos trabalhos de transformação, para as tabelas de relatório finais.
Use o Dataplex Data Lineage.
Por quê: Captura automaticamente informações de linhagem de BigQuery, Data Fusion e logs do Composer para fornecer uma visualização interativa baseada em grafo das dependências de dados para análise de impacto e auditoria.
Garantir desempenho e custo de consulta previsíveis para cargas de trabalho críticas, evitando "contenção de slots" de outros usuários.
Adquira as Edições do BigQuery (preços baseados em capacidade). Crie reservas para dedicar um pool de slots a projetos ou pastas específicas.
Por quê: Muda de um pool compartilhado sob demanda para uma capacidade de computação dedicada, garantindo recursos para trabalhos críticos e fornecendo faturamento previsível.
Digitalizar todos os ativos de dados no BigQuery e Cloud Storage para identificar e classificar automaticamente PII e outros dados sensíveis.
Configure um trabalho de varredura de descoberta do Cloud Data Loss Prevention (DLP).
Por quê: O Cloud DLP usa centenas de detectores predefinidos para encontrar dados sensíveis em escala. Ele pode se integrar ao Data Catalog para aplicar automaticamente tags de política para governança.
Um aplicativo conteinerizado (em GKE ou Cloud Run) precisa se autenticar de forma segura no BigQuery sem gerenciar chaves de conta de serviço.
Use o Workload Identity.
Por quê: A melhor prática recomendada para autenticação serviço-a-serviço. Ele mapeia uma conta de serviço Kubernetes para uma conta de serviço IAM do GCP, usando tokens de curta duração e rotacionados automaticamente.
Para conformidade, gere um relatório de todos os usuários que consultaram uma tabela sensível do BigQuery nos últimos 90 dias.
Habilite e consulte os logs de auditoria de acesso a dados do BigQuery, que podem ser roteados para um conjunto de dados do BigQuery para análise.
Por quê: Os logs de acesso a dados fornecem um registro imutável de quem acessou quais dados e quando. Eles são essenciais para auditorias de segurança e conformidade, mas devem ser explicitamente habilitados.
Identificar quais usuários ou consultas são responsáveis pelos altos custos do BigQuery.
Consulte a view `INFORMATION_SCHEMA.JOBS`.
Por quê: Esta view de metadados contém informações detalhadas para cada consulta executada, incluindo o usuário, bytes faturados e slots consumidos, permitindo atribuição e análise precisas de custos.
Realizar cálculos analíticos complexos, como totais acumulados, classificação dentro de grupos (por exemplo, top N por categoria) ou comparação de uma linha com uma linha anterior.
Use funções de janela SQL do BigQuery (`SUM() OVER (...)`, `RANK() OVER (...)`, `LAG() OVER (...)`).
Por quê: O método SQL padrão e mais eficiente para realizar cálculos em um conjunto de linhas de tabela que estão de alguma forma relacionadas à linha atual.
Criar e compartilhar painéis interativos e com atualização automática sobre dados do BigQuery para usuários de negócios que não escrevem SQL.
Use o Looker Studio.
Por quê: A ferramenta de visualização nativa e gratuita do GCP. Ela se conecta diretamente ao BigQuery e permite o compartilhamento via um link simples, gerenciando as credenciais da fonte de dados separadamente do acesso do usuário.
Permitir que analistas de negócios usem ferramentas de planilha familiares (tabelas dinâmicas, gráficos, fórmulas) para analisar terabytes de dados no BigQuery.
Use o Connected Sheets.
Por quê: Fornece uma conexão ao vivo do Google Sheets para o BigQuery. Todo o processamento e computação ocorrem no BigQuery, ignorando os limites de tamanho e desempenho de uma planilha tradicional.
Um painel do Looker Studio que consulta agregações grandes e complexas é lento e custoso.
Crie uma Visualização Materializada do BigQuery para pré-computar as agregações. Aponte a fonte de dados do Looker Studio para a visualização materializada.
Por quê: As visualizações materializadas pré-calculam e armazenam em cache resultados de consultas caras. Isso melhora drasticamente o desempenho do painel e reduz os custos de consulta para cargas de trabalho repetitivas.
Construir, treinar e servir um modelo de machine learning (por exemplo, para classificação, regressão ou previsão) usando dados que residem no BigQuery.
Use o BigQuery ML (BQML).
Por quê: Democratiza o ML, permitindo que os usuários treinem modelos com a sintaxe SQL padrão `CREATE MODEL`. O modelo vive e executa dentro do BigQuery, simplificando a implantação e a previsão.
Prever métricas de negócios futuras (por exemplo, vendas, demanda) com base em dados históricos de séries temporais.
Use o BigQuery ML com o tipo de modelo `ARIMA_PLUS`.
Por quê: `ARIMA_PLUS` é um modelo BQML construído especificamente para previsão de séries temporais que lida automaticamente com tendências, sazonalidade, feriados e detecção de anomalias.
Uma consulta do BigQuery que une uma tabela de fatos muito grande (TBs) com uma tabela de dimensão pequena (<100MB) é lenta.
Garanta que o BigQuery esteja usando um broadcast join. Embora frequentemente automático, você pode verificar o plano de consulta ou usar uma dica `JOIN` se necessário.
Por quê: Um broadcast join envia a tabela pequena inteira para cada slot de processamento, evitando uma custosa e lenta reordenação de dados da tabela grande pela rede.
Um modelo BigQuery ML precisa ser retreinado regularmente (por exemplo, semanalmente) em novos dados para prevenir o desvio do modelo.
Use uma Consulta Programada do BigQuery para executar uma declaração `CREATE OR REPLACE MODEL`.
Por quê: Esta é a maneira mais simples e integrada de automatizar o retreinamento do BQML. Não requer serviços externos como Composer ou Cloud Functions.
Construir um sistema de recomendação de filtragem colaborativa (por exemplo, "usuários que compraram X também compraram Y").
Use o BigQuery ML com o tipo de modelo `MATRIX_FACTORIZATION`.
Por quê: Este modelo é projetado especificamente para tarefas de recomendação com base em dados de interação usuário-item.