Certificação Google Cloud PMLE: dados, features e pipelines

Série PMLE - 2 de 5

Publicado a 17 de Abril de 2026

Muitos modelos falham antes de existir qualquer problema algorítmico. Falham nos dados: esquemas instáveis, features mal definidas, leakage, pipelines frágeis e ausência de controlo sobre o que foi realmente usado para treinar.

Identidade visual da série PMLE - dados, features e pipelines

Neste artigo

Mapear o bloco de dados da PMLE: qualidade, preparação, feature engineering, Feature Store e pipelines de transformação.

Domínios do exame

  • Collaborate within and across teams to manage data and models
  • Automate and orchestrate ML pipelines
  • Monitor AI solutions

Ferramentas-chave

  • BigQuery
  • BigQuery ML
  • Dataflow / Dataproc
  • Feature Store

Neste post

O exame não separa dados de modelação

Na prática, a PMLE trata os dados como parte do próprio sistema de ML. Isso significa que perguntas sobre modelos podem esconder um problema de schema, de agregação temporal, de treino versus serving, ou de atualização de features. Se estudares dados como um bloco “pré-modelo”, vais perder metade da lógica do exame.

O que significa ter bons dados no contexto da PMLE

Bons dados não são apenas dados limpos. São dados acessíveis no momento certo, com definição estável, sem leakage, com splits coerentes e com um processo reproduzível de transformação. Em Google Cloud, isso costuma implicar combinar armazenamento e analytics com mecanismos de preparação e verificação: BigQuery para exploração e modelação low-code, Cloud Storage para datasets e artefactos, Dataflow ou Dataproc quando é preciso processamento mais robusto, e ferramentas de validação e feature engineering ao longo do pipeline.

Disponibilidade

A feature existe antes do momento da previsão e pode ser calculada com latência compatível com o serving?

Estabilidade

O schema, o tipo de dado, os ranges e a semântica da feature são suficientemente estáveis para treino e produção?

Reprodutibilidade

Outra pessoa consegue reconstruir a mesma tabela, o mesmo split e a mesma transformação?

Observabilidade

Há verificações que permitam detetar skew, drift, schema drift ou degradação de qualidade?

Problema Porque aparece no exame Que pergunta tens de saber responder
Leakage Infla métricas e destrói generalização. Esta feature existe realmente no momento da previsão?
Schema drift Quebra pipelines e degrada qualidade silenciosamente. Como detetar que a estrutura dos dados mudou?
Training-serving skew Treino e produção passam a ver versões diferentes da mesma feature. Como garantir que a feature é calculada da mesma forma nos dois lados?
Data drift A distribuição de entrada muda mesmo sem mudar o código. Que sinais justificam reavaliação ou retraining?

Leakage e anti-padrões reais

Leakage é uma palavra simples para um problema que assume formas muito diferentes. O que interessa para exame não é só a definição formal; é conseguir reconhecer as versões mais traiçoeiras em cenários concretos.

Temporal leakage

Estás a prever churn, default ou falha de equipamento e uma feature usa eventos que só existem depois do momento da decisão.

  • Agregações “últimos 30 dias” mal recortadas no tempo.
  • Estados administrativos criados após o evento-alvo.
  • Labels parciais refletidas em features derivadas.

Leakage por agregação

Fazes estatísticas globais antes do split ou incluis amostras futuras na média da entidade que queres prever.

  • Normalização calculada em todo o dataset.
  • Target encoding fora de fold.
  • Feature selection feita antes de separar treino e teste.

Grouping leakage

O mesmo utilizador, paciente ou máquina aparece em treino e validação, inflacionando métricas sem ensinar generalização real.

  • Várias visitas do mesmo paciente em splits diferentes.
  • Logs por sessão sem agrupar por identidade.
  • Recomendações avaliadas com interações do mesmo utilizador espalhadas no tempo.

Leakage por pipeline

O dado está “certo”, mas a transformação do treino usa informação que o serving nunca vai ter.

  • Lookup table diferente entre treino e produção.
  • Feature montada manualmente no notebook e reimplementada de forma divergente no serviço.
  • Join assíncrono com atraso maior do que a janela de serving tolera.

BigQuery e BigQuery ML: rapidez com disciplina

BigQuery ML aparece no currículo porque resolve uma classe importante de problemas sem obrigar a exportar tudo para fora do warehouse. Para a certificação, interessa perceber quando este caminho é adequado: dados já estruturados em BigQuery, problema supervisionado relativamente standard, necessidade de rapidez, integração com SQL e uma equipa que beneficia de reduzir complexidade operacional.

Mas rapidez não elimina disciplina. Mesmo em BigQuery ML, continuas a ter de pensar em leakage, splits temporais, features derivadas e métricas adequadas ao problema. O low-code muda o nível de abstração; não elimina a responsabilidade de engenharia.

Heurística útil: se a principal razão para sair de BigQuery é “porque parece mais avançado”, ainda não tens razão suficiente. Sai quando o problema exigir mais controlo, não por reflexo estético.

Escolher entre BigQuery, Dataflow e Dataproc

Necessidade Serviço que tende a encaixar melhor Sinal de que deves reconsiderar
Transformação analítica e features em SQL perto dos dados BigQuery / BigQuery ML Quando começas a precisar de lógica de streaming, orquestração complexa ou dependências fora do warehouse.
Pipeline de dados escalável, repetível e eventualmente em streaming Dataflow (frequentemente com Pub/Sub como fonte de eventos em streaming) Se o trabalho for sobretudo batch pesado baseado em ecossistema Spark já existente.
Jobs distribuídos com Spark/Hadoop e legado compatível Dataproc Se a equipa só precisa de transformação gerida sem operar clusters ou compatibilidades específicas.

Windowing no Dataflow: quando a janela temporal importa

Em pipelines de streaming, a forma como agrupas eventos no tempo determina a lógica das features que geras. Dataflow (Apache Beam) oferece três tipos de janela que o exame testa regularmente:

Tipo de janela Como funciona Quando usar
Tumbling (fixed) Janelas de tamanho fixo, sem overlap. Ex: a cada 5 minutos. Contagens periódicas, agregações regulares. Ex: “número de cliques nos últimos 5 minutos”.
Sliding Janelas de tamanho fixo com overlap. Ex: janelas de 10 min a cada 5 min. Médias móveis, features que exigem continuidade. Ex: “média móvel de temperatura nos últimos 30 min”.
Session Janelas definidas pela atividade do utilizador, com gap de inatividade configurável. Comportamento de utilizador (duração de sessão, eventos por sessão). O tamanho da janela varia por utilizador.
Para o exame: se o enunciado menciona “média móvel” ou “agregação deslizante”, a resposta é sliding window. Se menciona “sessão de utilizador” ou “atividade com gaps”, a resposta é session window. Trocar tumbling por sliding (ou vice-versa) é uma armadilha frequente.

Feature engineering: a parte menos glamorosa e mais decisiva

Feature engineering continua a ser um dos centros de gravidade do currículo. Não apenas selecionar colunas, mas construir representações úteis, consistentes e reprodutíveis. Isso inclui agregações corretas no tempo, encoding apropriado, tratamento de missing values, normalização calculada no sítio certo e documentação sobre a semântica de cada feature.

O exame tende a premiar respostas que preservam consistência operacional: a mesma lógica de transformação, a mesma definição, a mesma proveniência. É aqui que Feature Store entra como conceito importante. Mais do que uma caixa de features, é um mecanismo para reduzir divergência entre treino e serving, melhorar reutilização e dar mais visibilidade sobre o que está a ser usado.

Outro ponto que aparece no currículo: em cenários supervisionados, labels de qualidade são tão importantes como features de qualidade. Vertex AI Data Labeling permite gerir tarefas de anotação com revisão humana, controlo de qualidade e rastreabilidade. Quando o cenário de exame menciona dados não anotados ou labels inconsistentes, reconhecer este serviço pode ser a diferença entre uma resposta genérica e a resposta certa.

Feature readiness e Feature Store

Uma feature pronta para produção não é só “correlacionada com o target”. Tem de estar disponível, ser calculável com o mesmo método em treino e serving, ter comportamento estatístico observável e possuir um dono operacional. É aqui que muita preparação de exame se torna demasiado abstrata. Convém ter uma checklist mental concreta.

Semântica

A equipa consegue explicar o que a feature mede e porque faz sentido para o problema?

Operação

A feature chega a tempo para serving online ou só existe em batch? Isso está alinhado com o produto?

Observação

Há limiares para nulls, cardinalidade, drift e ranges anómalos?

Vertex AI Feature Store: arquitetura e modos de operação

O Vertex AI Feature Store serve como repositório centralizado de features para treino e serving, com o objetivo explícito de reduzir training-serving skew. A versão atual usa BigQuery como offline store e sincroniza com Cloud Bigtable como online store para serving de baixa latência (<10ms).

Modo Backend Quando usar
Offline serving BigQuery Exportações batch para treino; point-in-time joins para evitar leakage temporal.
Online serving Cloud Bigtable (sincronizado) Latência <10ms para predições em tempo real; features servidas diretamente ao endpoint.
Streaming ingestion Pub/Sub + Dataflow Atualizações em tempo real de features (cliques, transações, eventos).
Conceito crítico: point-in-time correctness significa que, ao construir o dataset de treino, cada exemplo só usa features que existiam antes do momento da label. O Feature Store faz estes joins automaticamente com base nos timestamps, evitando leakage temporal silencioso que invalida métricas.

Como o exame distingue opções plausíveis

Boa parte da dificuldade da PMLE não está em decorar definições. Está em separar duas respostas que parecem sensatas, mas resolvem problemas diferentes. O truque é olhar para o enunciado e perguntar: o que está realmente em causa aqui? Latência, consistência, custo operacional, point-in-time correctness, ou simples conveniência analítica?

Se o enunciado disser... A resposta tende a ser... Porque as alternativas falham
Dados tabulares já vivem em BigQuery e a equipa quer baseline rápida com baixo overhead. BigQuery ML Dataflow e Dataproc resolvem transformação; não são, por si, a opção mais simples para treinar e servir um baseline low-code.
Eventos chegam continuamente, features dependem de janelas temporais e há necessidade de streaming. Dataflow BigQuery cobre análise e batch, mas não substitui um pipeline de streaming com windowing e processamento contínuo.
A equipa já depende fortemente de Spark/Hadoop ou precisa de compatibilidade com jobs distribuídos legados. Dataproc Dataflow reduz operação em muitos casos, mas não é a resposta certa quando o requisito central é compatibilidade com o ecossistema Spark existente.
O problema é garantir que treino e serving usam a mesma feature, com baixa latência online e joins corretos no tempo. Vertex AI Feature Store Tabelas avulsas e notebooks manuais até podem funcionar em protótipo, mas deixam a porta aberta para skew e leakage temporal.
O enunciado fala de anomalias de schema, ranges inválidos, novas categorias ou comparação treino vs serving. TFDV / validação de dados Retraining não corrige dados maus. Primeiro valida-se a entrada e só depois se decide se o problema exige novo treino.
A feature parece excelente offline, mas usa informação que só existe depois do momento da previsão. Eliminar leakage e reconstruir o dataset com point-in-time correctness Trocar de algoritmo, aumentar dados ou subir complexidade de modelação não corrige uma violação temporal no dataset.
Heurística de leitura: quando duas respostas parecem tecnicamente possíveis, escolhe a que resolve o problema com menos complexidade operacional e maior fidelidade ao momento real da previsão. Na PMLE, a opção certa costuma ser a mais disciplinada, não a mais sofisticada.

Skew, drift e os sinais de alerta

Mesmo quando a documentação oficial não enumera todos os detalhes, a direção é clara: precisas de compreender ferramentas e práticas para validar dados e acompanhar desvios. TensorFlow Data Validation, verificações de schema, deteção de anomalias e observação de drift fazem parte do tipo de raciocínio que a PMLE valoriza. O ponto não é decorar nomes; é perceber o ciclo: definir o que é “normal”, detetar desvios, decidir impacto e responder com correção no pipeline ou retraining.

Fenómeno O que mudou Como costuma aparecer
Schema drift Estrutura, tipos ou colunas do input Quebra pipelines, joins, parsing e transformações.
Training-serving skew Lógica ou disponibilidade das features entre treino e produção Modelo “bom” offline e incoerente em produção.
Data drift Distribuição dos inputs Mudança gradual no comportamento dos utilizadores, mercado ou sensores.
Degradação do modelo Capacidade preditiva face ao objetivo Métricas de negócio ou métricas supervisionadas descem mesmo sem falha técnica óbvia.
Armadilha recorrente: confundir data drift com degradation do modelo. O primeiro fala da distribuição de entrada; o segundo fala do comportamento do sistema face ao objetivo. Muitas vezes andam juntos, mas não são a mesma coisa.

Taxonomia completa de drift

O exame distingue quatro formas de drift. Confundi-las numa resposta é uma perda de pontos evitável:

Tipo O que muda Exemplo
Data drift / covariate shift Distribuição dos inputs P(X) Rendimentos médios dos candidatos a crédito sobem 5%, mas as regras de concessão não mudam.
Concept drift Relação entre inputs e target P(Y|X) Crise económica muda o que significa “bom pagador” para o mesmo nível de rendimento.
Prediction drift Distribuição das previsões P(Ŷ|X) O produto é lançado numa região mais rica e o modelo começa a aprovar mais crédito.
Label drift Distribuição do próprio target P(Y) A proporção de fraudes vs não-fraudes muda ao longo do tempo.

O concept drift pode ainda assumir formas diferentes que influenciam a estratégia de retraining:

Sudden

Mudança brusca. Ex: nova legislação que altera regras de um domínio.

Gradual

Novo padrão substitui o antigo ao longo de semanas/meses.

Incremental

O conceito muda lentamente, passo a passo, difícil de detetar sem janelas longas.

Recurring

Padrão antigo regressa. Ex: sazonalidade em retail ou turismo.

Pipelines de preparação: o dado também tem de ser reprodutível

Quando a Google fala de automação e orquestração de pipelines, não está a falar apenas do pipeline de treino. A preparação dos dados também tem de ser repetível, observável e passível de auditoria. É aqui que Dataflow, Dataproc e pipelines orquestrados entram na equação. O formato exato depende do problema, mas o princípio é constante: a transformação que produziu as features não pode viver apenas num notebook que ninguém mais consegue reproduzir.

Em estudo, vale a pena pensar em três perguntas para qualquer pipeline:

  • De onde vêm os dados e quem controla o acesso?
  • Como são produzidas as features e como garanto consistência entre treino e serving?
  • Que sinais me mostram que o pipeline começou a produzir entradas problemáticas?

TFDV: pipeline de validação de dados

O TensorFlow Data Validation (TFDV) é uma biblioteca do ecossistema TFX que automatiza a análise, validação e monitorização de dados de ML. Para o exame, interessa perceber os três componentes e o que cada um faz:

Componente Função Que problemas deteta
StatisticsGen Gera estatísticas descritivas (média, min, max, distribuição, missing values) para cada feature. Gaps nos dados, desbalanceamento de classes, distribuições inesperadas.
SchemaGen Infere um schema automático a partir das estatísticas: tipo, domínio, presença obrigatória, ranges válidos. Tipos errados, categorias inválidas, features em falta.
ExampleValidator Compara novas estatísticas com o schema definido e deteta anomalias. Valores fora de range, novas categorias, distribuições que divergem do baseline.
Para o exame: TFDV não só valida dados de treino. Também compara distribuições de treino vs serving para detetar distribution skew — causado por transformações distintas, amostragem enviesada ou janelas temporais diferentes nos dois ambientes.

O que precisas de saber para o exame

  • Quando usar BigQuery ML como solução low-code e quando sair para um pipeline mais customizado.
  • Como evitar leakage em agregações, encoding, imputação e feature selection.
  • Como escolher entre BigQuery, Dataflow e Dataproc com base no tipo de pipeline e no custo operacional.
  • Distinguir tumbling, sliding e session windows no Dataflow e saber quando usar cada uma.
  • O papel de Feature Store na consistência entre treino e serving; online vs offline store; point-in-time correctness.
  • Distinguir data drift, concept drift, prediction drift e label drift com exemplos.
  • Reconhecer formas de concept drift: sudden, gradual, incremental, recurring.
  • Os três componentes TFDV (StatisticsGen, SchemaGen, ExampleValidator) e como detetam anomalias.
  • Que condições fazem de uma feature uma feature pronta para produção.
  • Porque é que a preparação de dados também precisa de automação, rastreabilidade e observabilidade.

Praticar na documentação e nos labs oficiais

A seguir passamos ao momento em que muita gente pensa que “começa” o machine learning: notebooks, treino, avaliação, experimentação e a transição do protótipo para um modelo operacional.

Parte anterior Mapa do exame e da stack de ML Parte 2 Dados, features e pipelines Parte seguinte Treino, avaliação e operacionalização