Guia

Dados contínuos de alto volume exigem análise em minutos após a chegada.

→Pub/Sub para ingestão -> Dataflow (streaming) para transformação -> BigQuery com inserções de streaming ou Storage Write API para analytics.

Por quê: Este é o padrão canônico de streaming serverless e com autoescalonamento. O processamento em lote (por exemplo, Dataproc) não atenderia aos requisitos de baixa latência.

O pipeline de dados deve lidar com picos de tráfego imprevisíveis (por exemplo, volume sazonal 10x) enquanto mantém baixa latência.

→Use serviços totalmente gerenciados e com autoescalonamento: Pub/Sub para ingestão, Dataflow com autoescalonamento habilitado e BigQuery para armazenamento.

Por quê: Serviços gerenciados escalam automaticamente os recursos para corresponder à carga, evitando custos de provisionamento excessivo e garantindo o desempenho sob tráfego de pico.

Migre um grande data warehouse Hadoop/Hive on-premises para o Google Cloud.

→Migre os dados para o Cloud Storage e, em seguida, carregue-os no BigQuery. Substitua Hive/Spark SQL por BigQuery para análises serverless. Use Dataproc para trabalhos Spark que não são facilmente traduzidos para SQL.

Por quê: BigQuery oferece uma substituição serverless e de alto desempenho para data warehouses Hadoop, reduzindo a sobrecarga operacional.

Um pipeline de streaming requer que as mensagens sejam processadas exatamente uma vez e em ordem para cada entidade (por exemplo, por símbolo de ações).

→Publique mensagens no Pub/Sub com uma chave de ordenação. Processe com um pipeline de streaming do Dataflow, que garante o processamento em ordem para uma determinada chave.

Por quê: As chaves de ordenação do Pub/Sub combinadas com o Dataflow fornecem processamento gerenciado, escalável, ordenado e exactly-once sem gerenciamento manual de estado.

Referência↗

Construa um data lake flexível e escalável para suportar cargas de trabalho em lote e streaming com governança de dados.

→Use o Cloud Storage como camada de armazenamento. Use o Dataflow para processamento em lote e de stream. Use o Dataplex com o Data Catalog para gerenciamento de metadados, descoberta e governança.

Por quê: Esta arquitetura desacopla armazenamento e computação, permitindo o uso de múltiplos motores de processamento (Dataflow, Dataproc) em um armazenamento de dados central com governança unificada.

Um pipeline que processa dados sensíveis (por exemplo, PHI, PII) deve estar em conformidade com regulamentações como HIPAA ou GDPR.

→Ative o Cloud Audit Logs para todo o acesso a dados. Implemente VPC Service Controls para criar um perímetro de segurança que impeça a exfiltração de dados.

Por quê: O registro de auditoria é fundamental para rastrear o acesso a dados para conformidade. O VPC Service Controls oferece uma forte defesa contra a exfiltração de dados, um requisito chave para dados sensíveis.

Uma arquitetura lambda com camadas separadas de lote e velocidade precisa apresentar uma visão unificada dos dados.

→Use o BigQuery para a camada de serviço. Use uma instrução `MERGE` para atualizar/inserir dados processados em lote em uma tabela mestre, sobrescrevendo os dados de streaming para o mesmo período. Exponha uma view que combine dados históricos em lote com dados de streaming em tempo real para o período atual.

Por quê: Este padrão oferece tanto visões em tempo real de baixa latência quanto precisão histórica corrigida por lote, sem exigir lógica de reconciliação no lado do cliente.

Implemente uma arquitetura de malha de dados descentralizada onde os domínios são proprietários de seus produtos de dados.

→Use o Dataplex para governança federada sobre "lakes" e "zones" específicos do domínio. Use datasets do BigQuery por domínio. Use o Analytics Hub para compartilhar produtos de dados entre domínios.

Por quê: O Dataplex fornece o plano de governança central, permitindo a autonomia do domínio, um princípio central da malha de dados.

Combine um data lake e um data warehouse, permitindo trabalhos Spark em dados brutos e SQL rápido em dados curados.

→Armazene dados em formatos abertos (Iceberg, Delta Lake) no Cloud Storage. Use o BigLake para fornecer uma camada unificada de governança e acesso. Consulte dados de Dataproc (Spark) e BigQuery.

Por quê: O BigLake permite consultar dados no local no Cloud Storage com desempenho de BigQuery e segurança granular, unificando o lake e o warehouse.

Projete uma estratégia de recuperação de desastres para um data warehouse BigQuery crítico com um RPO baixo (por exemplo, 1 hora).

→Configure a replicação de dataset entre regiões do BigQuery para datasets críticos. Use Terraform ou Dataform para gerenciar definições de esquema e view. Orquestre o failover com Cloud Functions acionadas por alertas do Cloud Monitoring.

Por quê: A replicação entre regiões fornece uma cópia continuamente atualizada e consultável em uma região de DR, atendendo aos requisitos de baixo RPO/RTO para dados críticos.

Replique continuamente as alterações de um banco de dados OLTP (por exemplo, Oracle, PostgreSQL, MySQL) para o BigQuery com baixa latência.

→Use o Datastream para realizar Change Data Capture (CDC). Configure-o para fazer stream das alterações diretamente para o BigQuery, que as aplica usando sua capacidade MERGE.

Por quê: O Datastream é um serviço CDC gerenciado e serverless que simplifica a replicação de banco de dados em tempo real sem exigir pipelines personalizados ou uma carga significativa no banco de dados de origem.

Referência↗

Um pipeline de streaming do Dataflow deve produzir resultados precisos em janelas de tempo de evento, mesmo que alguns eventos cheguem horas atrasados.

→Configure janelas de tempo de evento com `allowedLateness` definido para acomodar o atraso. Use triggers com disparos antecipados para resultados preliminares e acumulando panes disparados para incluir dados atrasados.

Por quê: O modelo de watermarks, triggers e `allowedLateness` do Dataflow fornece uma estrutura robusta para equilibrar completude e latência ao lidar com dados fora de ordem.

Um pipeline Dataflow que grava no BigQuery experimenta duplicatas após reinícios ou falhas transitórias.

→Use o sink da BigQuery Storage Write API (`STORAGE_WRITE_API`) com o método definido como `at-least-once` (padrão, anteriormente `STREAMING_INSERTS`) ou `exactly-once` (modo `COMMITTED`).

Por quê: A Storage Write API no modo `COMMITTED` fornece semântica `exactly-once` integrada para streaming, eliminando a necessidade de lógica de deduplicação personalizada.

Ingira dados de uma REST API paginada e com limite de taxa usando Dataflow.

→Use um `SplittableDoFn` para processar a fonte paginada em paralelo. Implemente lógica de limitação de taxa (por exemplo, usando um Guava RateLimiter) e exponential backoff para retentativas dentro do DoFn.

Por quê: Um `SplittableDoFn` permite o rebalanceamento dinâmico do trabalho. Combiná-lo com limitação de taxa e lógica de retry cria um padrão resiliente e eficiente para lidar com APIs externas.

Um único stream de dados precisa ser gravado em múltiplos destinos (por exemplo, BigQuery, Bigtable, Cloud Storage).

→Em um único pipeline Dataflow, após o processamento inicial, aplique múltiplos `PTransform` writers à mesma `PCollection` final.

Por quê: O padrão fan-out é altamente eficiente, pois os dados são processados apenas uma vez. Ele evita o custo e a complexidade de executar múltiplos pipelines separados lendo da mesma fonte.

Um stream de alto volume deve ser enriquecido unindo-se a uma tabela de dimensão de mudança lenta (por exemplo, perfis de usuário) que é atualizada periodicamente.

→Use o padrão side input no Dataflow. Carregue a tabela de dimensão como uma `PCollectionView`. Configure um trigger periódico para atualizar o side input em um cronograma, evitando reinícios do pipeline.

Por quê: Side inputs transmitem os dados da dimensão para todos os workers para buscas rápidas em memória, evitando chamadas de API/DB por elemento. A atualização periódica lida com as atualizações de forma eficiente.

As cargas de trabalho do cluster Dataproc variam significativamente, levando a sobre-provisionamento ou subdesempenho.

→Crie um cluster Dataproc com uma política de autoescalonamento. Defina contagens mínimas/máximas de workers primários e secundários. A política escalará o cluster com base nas métricas YARN.

Por quê: O autoescalonamento otimiza os custos ao corresponder os recursos do cluster à demanda do trabalho, escalando para cima em cargas pesadas e para baixo durante períodos de inatividade.

Um pipeline Dataflow requer binários personalizados, bibliotecas proprietárias ou versões específicas não presentes em imagens de worker padrão, e deve ser executado em uma VPC sem internet.

→Crie uma imagem de container personalizada com todas as dependências pré-instaladas. Envie a imagem para o Artifact Registry. Implante o pipeline usando um Flex Template que referencia o container personalizado.

Por quê: Flex Templates com containers personalizados fornecem controle total sobre o ambiente de tempo de execução e as dependências, crucial para ambientes offline ou especializados.

Um trabalho Dataflow ou Spark que realiza um `GroupByKey` é lento porque algumas chaves têm um número desproporcionalmente grande de valores (uma "chave quente").

→Implemente uma agregação de dois estágios (key salting). Primeiro, anexe um sufixo aleatório à chave para dividir a chave quente entre vários workers. Agregue parcialmente. Segundo, remova o sufixo e agregue os resultados parciais.

Por quê: Esta técnica de fanout divide manualmente o trabalho para a chave quente, permitindo que seja processado em paralelo e superando o gargalo.

Um pipeline de streaming não deve falhar devido a registros malformados. Registros inválidos devem ser isolados para análise sem interromper o processamento.

→Em um `DoFn`, use um bloco try-catch para parsing. Use um `DoFn` de múltiplas saídas com `TupleTag` para rotear registros válidos para a saída principal e registros inválidos (com contexto de erro) para uma saída de erro separada. Envie a `PCollection` de erro para um destino de dead-letter como um tópico Pub/Sub ou uma tabela BigQuery.

Por quê: Este padrão oferece resiliência ao isolar dados ruins, prevenindo falhas no pipeline e garantindo que os registros com falha sejam capturados para depuração e reprocessamento.

As consultas do BigQuery são lentas e caras, geralmente filtrando por uma coluna de data/hora e outras colunas de alta cardinalidade (por exemplo, `customer_id`).

→Particione a tabela pela coluna de data/hora (por exemplo, partições diárias). Agrupe a tabela por até quatro colunas frequentemente filtradas (por exemplo, `customer_id`, `product_category`).

Por quê: O particionamento poda os dados escaneados para apenas períodos de tempo relevantes. O agrupamento organiza ainda mais os dados dentro das partições, minimizando os dados escaneados para filtros em colunas agrupadas. Este é o principal padrão de ajuste de desempenho do BQ.

Referência↗

A aplicação requer leituras e gravações de baixa latência (abaixo de 10ms) para datasets massivos (bilhões de linhas), como para personalização em tempo real ou um feature store de IoT.

→Use Bigtable. Projete uma row key que suporte o padrão de acesso primário. Para séries temporais, use `entity_id#reverse_timestamp`.

Por quê: O Bigtable é um armazenamento NoSQL de coluna larga otimizado para cargas de trabalho de alta throughput e baixa latência em escala. O BigQuery é para análises e tem maior latência de pesquisa pontual.

Uma aplicação transacional requer distribuição global, escalabilidade horizontal e forte consistência com uma interface SQL.

→Use o Cloud Spanner com uma configuração multirregional.

Por quê: O Spanner é o único serviço que oferece todas essas capacidades: distribuído globalmente, transações ACID e um esquema relacional. O Cloud SQL é regional; o Bigtable não é relacional e tem consistência eventual entre clusters.

Um data warehouse BigQuery possui grandes quantidades de dados históricos que são consultados com pouca frequência, mas devem ser retidos, resultando em altos custos de armazenamento.

→Nenhuma ação necessária para partições/tabelas não modificadas por 90 dias consecutivos. O BigQuery aplica automaticamente o preço de armazenamento de longo prazo, uma redução de custo de ~50%.

Por quê: Esta é uma otimização automática e integrada. Mover dados manualmente para o GCS (a menos que seja para a camada Archive) é frequentemente desnecessário e adiciona complexidade.

Dados em um bucket do Cloud Storage possuem um padrão de acesso previsível: frequente por 30 dias, ocasional por 90 dias e, em seguida, raro.

→Configure uma política de ciclo de vida do bucket para transicionar objetos: Standard -> Nearline (aos 30 dias) -> Coldline (aos 90 dias).

Por quê: As políticas de ciclo de vida automatizam a otimização de custos, movendo dados para classes de armazenamento mais baratas à medida que são acessados com menos frequência.

Uma tabela BigQuery deve impor uma restrição de chave única.

→Aplique a unicidade no pipeline de carregamento. Use uma instrução `MERGE` com lógica que apenas insere quando a chave ainda não existe. Alternativamente, use um DoFn stateful no Dataflow para deduplicar.

Por quê: O BigQuery não impõe restrições `PRIMARY KEY` ou `UNIQUE`. A unicidade deve ser gerenciada pelo processo de carregamento de dados.

Uma tabela de dimensão no BigQuery precisa manter um histórico completo de alterações para análise pontual (SCD Tipo 2).

→Adicione as colunas de timestamp `valid_from` e `valid_to`. Quando uma alteração ocorre, use uma instrução `MERGE` para atualizar o `valid_to` no registro antigo e inserir um novo registro.

Por quê: Este é o padrão padrão para implementar SCD Tipo 2 em um data warehouse. `MERGE` fornece uma maneira eficiente e atômica de realizar as operações de atualização e inserção necessárias.

Uma aplicação requer um banco de dados gerenciado e escalável para documentos JSON com esquema flexível, suporte transacional e necessidades complexas de consulta.

→Use o Firestore no modo Nativo. Utilize coleções, documentos e subcoleções para modelar os dados. Crie índices compostos para consultas complexas.

Por quê: O Firestore é um banco de dados de documentos NoSQL serverless otimizado para cargas de trabalho transacionais com ricas capacidades de consulta, diferentemente do Bigtable (chave-valor) ou BigQuery (analítico).

Precisa consultar dados no Cloud Storage (Parquet, Avro, etc.) via BigQuery, aplicando segurança granular (por linha/coluna).

→Crie tabelas BigLake sobre os dados do Cloud Storage. Aplique políticas de segurança de linha e coluna do BigQuery às tabelas BigLake.

Por quê: O BigLake estende a governança do BigQuery para dados de formato aberto no Cloud Storage, permitindo uma arquitetura de data lakehouse segura e unificada.

Uma equipe de ciência de dados precisa treinar modelos de ML em grandes datasets do BigQuery sem mover ou exportar dados.

→Use o BigQuery ML. Escreva declarações `CREATE MODEL` em SQL para treinar, avaliar e prever diretamente no BigQuery.

Por quê: O BQML elimina a movimentação de dados, simplifica o fluxo de trabalho de ML e aproveita o poder de processamento do BigQuery, acelerando a iteração.

Referência↗

Modelos de ML exigem features para treinamento em lote e inferência online de baixa latência, com consistência entre eles para evitar skew.

→Use o Vertex AI Feature Store. Ingira features via lote ou streaming. Ele fornece um armazenamento offline (BigQuery) para treinamento e um armazenamento online (Bigtable) para serviço de baixa latência.

Por quê: Este é um serviço gerenciado e desenvolvido especificamente que resolve o problema complexo de consistência de features, correção pontual e requisitos de dual-serving.

Usuários de negócios precisam de BI self-service, mas criam métricas e relatórios inconsistentes ao consultar o data warehouse diretamente.

→Implemente uma camada semântica Looker usando LookML. Defina dimensões, medidas e joins uma vez. Os usuários exploram o modelo governado em vez das tabelas brutas.

Por quê: O LookML oferece uma "fonte única de verdade" para a lógica de negócios, garantindo relatórios consistentes e precisos, ao mesmo tempo em que permite a exploração self-service.

É necessário implementar verificações automatizadas de qualidade de dados (nulos, unicidade, faixas de valor) e monitoramento para dados no BigQuery e Cloud Storage.

→Use o Dataplex Data Quality. Defina regras em YAML ou use regras auto-geradas a partir do perfilamento. Agende varreduras para monitorar a qualidade ao longo do tempo.

Por quê: O Dataplex oferece uma solução de qualidade de dados gerenciada e integrada, mais escalável e manutenível do que verificações SQL personalizadas ou scripts.

Descubra agrupamentos ou segmentos naturais dentro de um dataset de clientes sem rótulos predefinidos.

→Use o BigQuery ML para treinar um modelo de clustering `KMEANS` diretamente nos dados do cliente.

Por quê: K-means é um algoritmo de aprendizado não supervisionado ideal para segmentação. O BQML o torna acessível via SQL sem exportação de dados.

Habilite a busca semântica (baseada em significado, não em palavras-chave) sobre dados de texto armazenados no BigQuery.

→Use a função `ML.GENERATE_EMBEDDING` com um modelo de fundação Vertex AI para criar embeddings vetoriais. Armazene-os e use a função `VECTOR_SEARCH` para busca de similaridade.

Por quê: Este padrão traz poderosas capacidades de busca semântica diretamente para o BigQuery, evitando a necessidade de índices de busca externos como o Elasticsearch.

Integre capacidades de Large Language Model (LLM) como sumarização ou classificação de texto diretamente em um fluxo de trabalho analítico do BigQuery.

→Crie um modelo remoto do BigQuery ML que aponta para um endpoint LLM do Vertex AI. Use a função `ML.GENERATE_TEXT` dentro de uma consulta SQL para processar dados de texto.

Por quê: Isso integra firmemente a IA generativa ao SQL, permitindo que os analistas aproveitem os LLMs em seus dados sem sair do ambiente BigQuery ou escrever código de aplicação complexo.

Um pipeline de dados de várias etapas envolve dependências complexas, retentativas e tarefas em diferentes serviços GCP (por exemplo, Dataflow, BigQuery, Dataproc).

→Use o Cloud Composer (Apache Airflow gerenciado). Defina o fluxo de trabalho como um Directed Acyclic Graph (DAG) usando Python.

Por quê: O Composer é a ferramenta GCP designada para orquestração de fluxo de trabalho complexo, fornecendo gerenciamento robusto de dependências, agendamento, lógica de retentativa e monitoramento que ferramentas mais simples como o Cloud Scheduler não possuem.

Uma tarefa Airflow DAG que chama uma API externa falha frequentemente devido a problemas de rede transitórios.

→Configure retentativas em nível de tarefa no DAG com `retry_exponential_backoff=True`. Isso aumenta o atraso entre as retentativas, dando tempo ao sistema externo para se recuperar.

Por quê: O exponential backoff é uma prática recomendada para retentar falhas transitórias, pois evita sobrecarregar um sistema downstream em dificuldade com solicitações rápidas e repetidas.

Gerencie, versionar, teste e agende um conjunto complexo de transformações SQL interdependentes no BigQuery.

→Use o Dataform. Defina tabelas e dependências em arquivos SQLX, use Git para controle de versão, escreva asserções de qualidade de dados e agende fluxos de trabalho de execução.

Por quê: O Dataform é a solução nativa do Google Cloud para ELT, fornecendo gerenciamento de dependências, testes e controle de versão para transformações do BigQuery, promovendo as melhores práticas de DataOps.

É necessário entender e visualizar como os dados fluem da origem para o relatório final em múltiplos serviços como BigQuery e Dataflow.

→Use o Dataplex, que captura e exibe automaticamente a linhagem de dados de serviços Google Cloud suportados na UI do Data Catalog.

Por quê: O rastreamento automatizado da linhagem é crucial para análise de impacto, depuração e governança. O Dataplex oferece isso pronto para uso para serviços integrados.

Um trabalho de streaming Dataflow em execução precisa ser atualizado com nova lógica sem perder dados ou estado.

→Lance a nova versão do pipeline usando a opção de linha de comando `--update` e especificando o ID do trabalho do pipeline em execução. Use o modo `drain` para permitir que o trabalho antigo finalize o processamento dos dados em trânsito.

Por quê: O mecanismo de atualização in-place do Dataflow oferece uma forma de zero-downtime para implantar alterações em pipelines de streaming, preservando o estado e garantindo o processamento exactly-once.

Para conformidade, todo o acesso de leitura e gravação a dados sensíveis no BigQuery e Cloud Storage deve ser registrado e auditável.

→Ative o Cloud Audit Logs, especificamente os logs de Acesso a Dados, para os serviços relevantes. Crie um sink de log para exportar esses logs para o BigQuery para retenção e análise de longo prazo.

Por quê: O Cloud Audit Logs fornece um registro abrangente e à prova de adulteração do acesso aos dados. Enviar logs para o BigQuery permite auditoria e relatórios poderosos baseados em SQL.

Datasets, tabelas e controles de acesso do BigQuery precisam ser gerenciados como código para repetibilidade e versionamento (Infrastructure as Code).

→Defina todos os recursos do BigQuery (datasets, tabelas, políticas IAM) em arquivos de configuração Terraform (`.tf`). Gerencie as implantações através de um pipeline de CI/CD.

Por quê: O Terraform é o padrão para IaC no GCP, permitindo o gerenciamento auditado, versionado e consistente da infraestrutura de dados, prevenindo o desvio de configuração manual.

Um modelo de ML em produção mostra degradação de desempenho ao longo do tempo.

→Implemente o Vertex AI Model Monitoring. Configure um trabalho de monitoramento para detectar o training-serving skew e a prediction drift comparando o tráfego de produção com uma baseline. Configure alertas para acionar investigação ou retreinamento automatizado.

Por quê: O desempenho do modelo degrada devido ao data drift. O monitoramento proativo é essencial para detectar isso e manter a precisão do modelo, justificando o retreinamento.