GCP - Boas Práticas

Boas práticas consolidadas para trabalhar com GCP em contextos de engenharia de dados: organização, segurança, controle de custos e operação dos principais serviços.

Organização de projetos

Separar ambientes em projetos distintos: nunca compartilhar projeto entre dev e prod.

graph TD
    O["org/"] --> FD["folder: dev/"]
    O --> FS["folder: staging/"]
    O --> FP["folder: prod/"]
    FD --> PD["project: empresa-dados-dev"]
    FS --> PS["project: empresa-dados-stg"]
    FP --> PP["project: empresa-dados-prd"]

Nomear projetos com convenção clara: {empresa}-{domínio}-{ambiente} evita confusão em billing e IAM.

Usar labels em todos os recursos para rastrear custos por equipe, domínio e ambiente:

labels = {
  team        = "engenharia-dados"
  environment = "prod"
  managed_by  = "terraform"
}

IAM e segurança

Princípio do menor privilégio: nunca conceder roles/owner ou roles/editor a service accounts. Usar roles granulares:

Serviço	Role mínima para leitura	Role mínima para escrita
BigQuery	`roles/bigquery.dataViewer`	`roles/bigquery.dataEditor`
Cloud Storage	`roles/storage.objectViewer`	`roles/storage.objectCreator`
Pub/Sub	`roles/pubsub.subscriber`	`roles/pubsub.publisher`
Dataflow	`roles/dataflow.viewer`	`roles/dataflow.developer`

Uma Service Account por serviço/pipeline: não reutilizar a mesma SA em múltiplos sistemas.

Nunca colocar chaves de SA em código ou variáveis de ambiente em produção: usar Workload Identity (GKE), GOOGLE_APPLICATION_CREDENTIALS no CI/CD ou Secret Manager.

Ativar VPC Service Controls para dados sensíveis: cria um perímetro que impede exfiltração de dados via APIs GCP.

BigQuery

Sempre particionar e clusterizar tabelas grandes antes de qualquer otimização de query:

-- Partição por data + cluster pelas colunas mais filtradas
CREATE TABLE dataset.eventos
PARTITION BY DATE(event_time)
CLUSTER BY user_id, event_type
AS SELECT * FROM staging.eventos;

Usar INFORMATION_SCHEMA.JOBS_BY_PROJECT para monitorar consumo e identificar queries caras antes de virar problema de custo.

Preferir tabelas nativas a externas para dados acessados frequentemente, com melhor performance e custos menores.

Definir maximumBytesBilled em jobs críticos para evitar queries acidentalmente caras:

job_config = bigquery.QueryJobConfig(
    maximum_bytes_billed=10 * 1024**3  # 10 GB máximo
)

Expiração de tabelas: definir table_expiration_days em datasets de staging para limpeza automática.

Cloud Storage

Escolher a classe certa desde o início: mover objetos entre classes gera custo de operação. Usar lifecycle rules para automação:

{
  "rule": [
    {
      "action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
      "condition": {"age": 30, "matchesStorageClass": ["STANDARD"]}
    },
    {
      "action": {"type": "Delete"},
      "condition": {"age": 365}
    }
  ]
}

Ativar versionamento apenas em buckets onde recovery de objetos é necessário, pois versionamento desnecessário aumenta custos de storage.

Organizar por partição no path para aproveitar partition pruning em tabelas externas BigQuery:

gs://bucket/tabela/year=2026/month=05/day=05/data.parquet

Dataflow

Usar Flex Templates em vez de Classic Templates para novos pipelines, pois são mais flexíveis e baseados em Docker.

Dimensionar workers corretamente: começar com --max_num_workers=10 e ajustar via Cloud Monitoring. Workers ociosos custam dinheiro.

Preferir Dataflow Shuffle (serviço gerenciado) ao shuffle local para jobs grandes:

--experiments=shuffle_mode=service

Habilitar Streaming Engine para pipelines streaming, pois reduz uso de memória e custo por worker.

Cloud Composer / Airflow

Usar catchup=False em todos os DAGs a menos que backfill seja explicitamente necessário.

Não fazer requests HTTP dentro de tasks Python diretamente: usar operadores e hooks para que retries e timeouts sejam gerenciados pelo Airflow.

Separar DAGs por domínio e frequência: DAGs de ingestão horária não devem misturar com pipelines diários de transformação.

Monitorar o lag do scheduler: se o scheduler estiver atrasado, as tasks começam tarde. Monitorar via Cloud Monitoring, na seção de métricas do Composer.

Controle de custos

Ativar Budget Alerts no Billing para cada projeto com limites por % do orçamento
Usar Committed Use Discounts (CUD) para workloads previsíveis (Compute Engine, BigQuery slots)
BigQuery on-demand: revisar mensalmente as queries mais caras via INFORMATION_SCHEMA
GCS: auditar buckets com lifecycle rules ausentes, identificando dados em Standard que deveriam estar em Coldline

IaC e reprodutibilidade

Gerenciar toda a infraestrutura GCP via Terraform (hashicorp/google). Ver terraform-cloud-gcp.

Não criar recursos manualmente no console em ambientes de staging e prod, pois dificulta auditoria e reprodutibilidade.

Second Brain

Explorer