Data for AI & ML — PDE Study Guide

Two lanes for ML data, one shared rule

A data engineer gets two ML requests in the same week. The first: forecast churn from the customers table that already sits in BigQuery. The second: build an assistant that answers questions from a folder of PDF contracts in Cloud Storage. Both are 'prepare data for ML', yet they need different services, and the fastest way to pick the right one is to notice they fall into two lanes that share a single rule, do the preparation where the data already lives rather than exporting it to a separate ML stack.

The rule to internalize first: the lane is set by what the model consumes, not by which model you eventually train. Lane one is structured features for predictive models. You take tabular columns, clean and shape them into features (the input signals a model learns from), then either train in place with BigQuery ML^[1] or hand the features to Vertex AI for custom training. Lane two is unstructured data turned into embeddings. You take text, images, or documents, convert each into an embedding (a numeric vector that places semantically similar items close together), and use those vectors for semantic search and retrieval-augmented generation. Retrieval-augmented generation, RAG, means retrieving the most relevant passages for a question and feeding them into a model's prompt so it answers from your data instead of guessing.

This page is one lane per section, then a section on choosing between BigQuery and Vertex AI, and finally how the exam phrases each case. One boundary to hold as you read: this subtopic is the data-engineer-for-ML angle, preparing and serving the data, not training and tuning the model end to end, which the ML Engineer exam owns. And the neighbouring subtopics in this domain are different jobs entirely: shaping data for dashboards is data-visualization, and granting other parties access to datasets is sharing-data. Here the job is getting data into the shape an ML model or an embedding search can consume.

Preparing ML data splits into two lanes that share one rule, work where the data lives: structured features for training, and unstructured data turned into embeddings for RAG.

Lane 1: features for training and serving

Lane one is the predictive-model path, and the headline rule is simple: if the data is already in BigQuery and your team writes SQL, prepare and train it there rather than exporting. BigQuery ML^[1] lets you create and run a model with a CREATE MODEL statement on a table, so neither the features nor the model leave the warehouse. That removes the slowest step in most ML projects, moving large datasets into a separate framework.

Shaping features and training in SQL

A feature is an input signal the model learns from, and feature engineering is shaping raw columns into those signals: bucketizing an age, one-hot encoding a category, joining in an aggregate. In BigQuery you do this with ordinary SQL (or BigQuery's TRANSFORM clause so the same preprocessing is reapplied automatically at prediction time), then train:

CREATE MODEL `mydataset.churn_model`
OPTIONS(model_type = 'LOGISTIC_REG') AS
SELECT tenure_months, plan_tier, monthly_charges, churned AS label
FROM `mydataset.customers`;

BigQuery ML supports a wide range of model types^[1]: linear and logistic regression, k-means clustering, matrix factorization, PCA, boosted trees (XGBoost), deep neural networks, and ARIMA_PLUS time-series models, among others. When you train, BigQuery ML splits the input into a training set and an evaluation set so it can report quality on data the model did not learn from; the data_split_method and data_split_eval_fraction options let you control that split (for example, a random split or a fraction you choose), and the default automatically reserves a portion for evaluation. For frameworks BigQuery ML does not cover, or when you need GPUs and a custom training loop, prepare the features in BigQuery or Dataflow and train on Vertex AI instead.

One feature, both paths: avoiding training-serving skew

The most expensive data bug in this lane is training-serving skew: the code that builds features for training differs from the code that builds them at prediction time, so the model is trained on one distribution and scored on another, and accuracy quietly drops in production. The rule that prevents it: a feature computed once must be reused for both training and serving. Vertex AI Feature Store^[2] is the managed answer, it is a central repository that computes a feature once and serves the same value online at low latency and offline from BigQuery as the feature source, so training and production read identical features. Google's own ML best-practice guidance^[3] reinforces both halves: store training data in BigQuery for structured features and on Cloud Storage for unstructured, and use skew detection in monitoring to catch when production data drifts from what the model trained on. Even without a feature store, the discipline is the same, define each transformation once and run it for both paths.

Vertex AI Feature Store serves one computed feature to both the training and serving paths, so the model sees identical features and training-serving skew disappears.

Lane 2: embeddings, vector search, and RAG

Lane two answers questions over unstructured data: 'what do our contracts say about termination?' across a folder of PDFs, or 'find support tickets like this one'. Keyword matching fails here because the words differ even when the meaning matches. The fix is to search by meaning, and the rule to internalize is the three-step shape: generate embeddings, index them, then search. An embedding is a numeric vector that places semantically similar text near each other in vector space, so 'cancel my plan' and 'how do I end my subscription' land close together even with no shared words.

Generate embeddings in BigQuery

When the text lives in a BigQuery table, you generate embeddings in place. ML.GENERATE_EMBEDDING^[4] (the newer AI.GENERATE_EMBEDDING^[4] is the same job under the AI function family) runs a remote model that references a Vertex AI text-embedding model and returns a vector for each row in a column named ml_generate_embedding_result. You create the remote model once, then call the function over a whole table:

SELECT ml_generate_embedding_result, content
FROM ML.GENERATE_EMBEDDING(
  MODEL `mydataset.embed_model`,
  TABLE `mydataset.docs`);

Long documents are usually chunked into passages before embedding, because a single vector for a whole document blurs its distinct sections; embedding chunks lets retrieval return the precise passage that answers a question.

Index and search the vectors

With vectors stored, VECTOR_SEARCH^[5] finds the nearest neighbours of a query vector. On its own it does a brute-force scan; to make it fast you first build an index with CREATE VECTOR INDEX^[6], which switches the search to approximate nearest neighbour (ANN). A vector index supports two types, IVF^[6] (inverted file, which clusters vectors with k-means) and TreeAH^[6] (built on Google's ScaNN algorithm, optimized for batch queries), and three distance types, EUCLIDEAN (the default), COSINE, and DOT_PRODUCT. One sharp threshold the exam likes: a vector index is not populated on a table smaller than 10 MB^[6], so on a tiny set the search just runs brute force and the index buys nothing. This retrieval step is the engine of RAG: embed the user's question, VECTOR_SEARCH for the closest passages, then pass those passages into a generative model so it answers from your data.

Reaching unstructured files in Cloud Storage

When the source is not text in a table but images or PDFs in a bucket, you bridge to it with an object table^[7], a read-only table over unstructured objects in Cloud Storage that exposes each object as a row with its uri and metadata. Because the data stays in the bucket and the table only indexes it, you can run BigQuery ML inference or generative AI functions over images and documents and join the results to structured tables, all from SQL. Like a BigLake table, an object table uses access delegation, so users query it without direct read access to the bucket.

RAG in BigQuery: embed and index the corpus once (ML.GENERATE_EMBEDDING, CREATE VECTOR INDEX), then embed each question and VECTOR_SEARCH for the passages to feed the model.

BigQuery ML or Vertex AI: choosing per job

Both lanes can be run in BigQuery or on Vertex AI, and the exam routinely tests which to choose. The decision turns on one question per job: is the data already in BigQuery and is SQL enough, or do you need a dedicated ML platform's scale and control?

For training, BigQuery ML wins when the data is in BigQuery and the team is SQL-fluent: CREATE MODEL trains in place and even registers the model to the Vertex AI Model Registry^[8] so it can later be deployed to an endpoint. Vertex AI custom training wins when you need a specific framework (TensorFlow, PyTorch), GPUs or TPUs, hyperparameter tuning, or a custom loop. A useful tell: 'our analysts know SQL, the data is in BigQuery, build a model fast' is BigQuery ML; 'our ML engineers need PyTorch on GPUs' is Vertex AI.

For vector search, BigQuery's VECTOR_SEARCH wins when the vectors live in BigQuery alongside your other data and you want to query them with SQL. Vertex AI Vector Search^[9], the dedicated service built on the same ScaNN algorithm, wins when you need low-latency approximate-nearest-neighbour serving over very large vector sets as a standalone online endpoint, typically the retrieval tier of a production RAG application rather than an analytical query. Both implement ANN; the split is analytical-in-warehouse versus low-latency-serving-at-scale.

The comparison table on this page lays the two lanes side by side; the recurring mistake is choosing the dedicated Vertex AI service when the data already lives in BigQuery and SQL would do the job in place, paying for an export and a second system you did not need.

If the data is in BigQuery and SQL suffices, train with BigQuery ML or retrieve with VECTOR_SEARCH; otherwise reach for Vertex AI custom training or Vertex AI Vector Search.

Reading the stem: which prep, which service

The exam rarely names a service in the question; it describes a data situation and expects you to map it to one. The tells on this subtopic resolve cleanly once you know the two lanes.

'Analysts know SQL, the customer data is already in BigQuery, build a churn or forecast model without a separate ML stack' is BigQuery ML with CREATE MODEL. Swap in 'the team needs PyTorch on GPUs' or 'a custom training loop' and the answer becomes Vertex AI custom training, fed by features you prepared in BigQuery or Dataflow.

'A feature is computed differently in training and in production, and the model underperforms live' is training-serving skew, and the fix is Vertex AI Feature Store serving one feature to both paths. If a stem stresses 'reuse the same features across several models and serve them at low latency', that is also Feature Store.

'Answer questions over a corpus of documents' or 'find semantically similar items' is the embedding lane: ML.GENERATE_EMBEDDING to build vectors, CREATE VECTOR INDEX to speed search, VECTOR_SEARCH to retrieve, the building blocks of RAG. 'Run inference or AI functions over images and PDFs sitting in Cloud Storage' points to an object table as the bridge. And 'serve nearest-neighbour lookups at very large scale with low latency outside the warehouse' is Vertex AI Vector Search, while the same retrieval inside BigQuery is VECTOR_SEARCH.

The single most common distractor across these is reaching for a dedicated Vertex AI service when the data already lives in BigQuery and SQL would finish the job in place. Match the situation to the lane first, then to the in-place option unless the stem demands a framework, GPUs, or standalone low-latency serving.

Where to prepare each kind of ML data on Google Cloud

Job	Structured features (Lane 1)	Embeddings + RAG (Lane 2)
Generate the ML input	Clean/shape columns in BigQuery or Dataflow	ML.GENERATE_EMBEDDING over text in BigQuery
Train or index	CREATE MODEL trains in BigQuery ML	CREATE VECTOR INDEX over the embedding column
Reuse / retrieve	Feature Store serves one feature for train + serve	VECTOR_SEARCH returns nearest passages for RAG
Unstructured source	n/a (tabular)	Object table exposes GCS images/PDFs to SQL
Scale-out engine	Vertex AI custom training	Vertex AI Vector Search for low-latency ANN at scale

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Split ML data prep into two lanes set by what the model consumes

Preparing data for ML on Google Cloud falls into two lanes: structured features for predictive models, and unstructured data turned into embeddings for semantic search and RAG. The lane is set by what the model consumes, not which model you eventually train, and both share one rule, do the preparation where the data already lives rather than exporting it. Naming the lane first makes the service choice fall out: tabular work points at BigQuery ML and Feature Store, embedding work at ML.GENERATE_EMBEDDING and vector search.

Train in BigQuery ML when the data is in BigQuery and the team writes SQL

BigQuery ML creates and trains a model with a CREATE MODEL SQL statement directly on a BigQuery table, so the data never leaves the warehouse and SQL-fluent analysts can build models without a separate ML stack. It removes the slowest step in most ML projects, exporting large datasets into another framework. Reach for Vertex AI custom training instead when you need a specific framework like TensorFlow or PyTorch, GPUs or TPUs, or a custom training loop.

Trap Choosing Vertex AI custom training when the data is already in BigQuery and SQL would train the model in place; you pay for an export and a second system you did not need.

BigQuery ML covers regression, clustering, trees, DNNs, and ARIMA_PLUS

BigQuery ML supports many model types from SQL, including linear and logistic regression, k-means clustering, matrix factorization, PCA, boosted trees (XGBoost), deep neural networks, and ARIMA_PLUS time-series models. That breadth is why 'analysts know SQL, build a forecast or classifier fast' resolves to BigQuery ML rather than a custom Vertex AI job. The model type is chosen in the OPTIONS(model_type=...) clause of CREATE MODEL.

BigQuery ML auto-splits training data and lets you control the split

When you train, BigQuery ML reserves a portion of the input as an evaluation set so it can report quality on data the model did not learn from, instead of you splitting by hand. The data_split_method and data_split_eval_fraction options control how, for example a random split or a fixed evaluation fraction, with a default that automatically holds out part of the data. Evaluating on held-out rows is what catches overfitting before the model ships.

Trap Evaluating the model on the same rows it trained on; quality looks inflated because the model has already seen those examples.

2 questions test this

A feature computed once must feed both training and serving

Training-serving skew is when the pipeline that builds features for training differs from the one that builds them at prediction time, so the model trains on one distribution and scores on another and accuracy drops in production. The discipline that prevents it is computing each feature once and reusing the same value for both training and serving. Even without a feature store, define each transformation once and run it for both paths rather than reimplementing it on the serving side.

Trap Reimplementing the feature logic separately in the serving path; the two implementations drift and reintroduce the skew you were avoiding.

5 questions test this

Vertex AI Feature Store serves one feature online and offline to kill skew

Vertex AI Feature Store is a central repository that computes a feature once and serves the same value online at low latency and offline from BigQuery as the feature source. Because training reads the offline value and production reads the online value of the same feature, training and serving see identical features and training-serving skew is eliminated. It also lets several models reuse the same curated features instead of each team recomputing them.

Trap Treating a raw BigQuery query as an online feature store; an ad-hoc warehouse read is not built for millisecond low-latency serving the way Feature Store online serving is.

1 question tests this

You are designing a Dataflow ML pipeline that enriches streaming transaction data with customer features stored in Vertex AI Feature Store…

Embeddings turn text into vectors that place similar meaning close together

An embedding is a numeric vector that positions semantically similar items near each other in vector space, so 'cancel my plan' and 'end my subscription' land close even with no shared words. That is what lets you search unstructured data by meaning rather than keyword. Embeddings are the input to both semantic search and retrieval-augmented generation, so generating them is the first step of the whole unstructured lane.

Generate embeddings in BigQuery with ML.GENERATE_EMBEDDING over a table

ML.GENERATE_EMBEDDING runs a remote model that references a Vertex AI text-embedding model and returns a vector for each row in a column named ml_generate_embedding_result, called over a whole table from SQL so the text never leaves BigQuery. The newer AI.GENERATE_EMBEDDING is the same job under the AI function family. You create the remote model once with a connection, then call the function across the table to embed every row in one query.

Chunk long documents before embedding so retrieval returns the right passage

A single embedding for a whole document blurs its distinct sections, so long text is split into smaller passages and each chunk is embedded separately. Chunking lets vector search return the precise passage that answers a question rather than a whole document, which sharpens the context fed into a RAG prompt. The chunk is the unit of retrieval, so its size trades recall of detail against how much surrounding context each result carries.

VECTOR_SEARCH finds nearest neighbours; a vector index makes it approximate and fast

VECTOR_SEARCH finds the rows whose embeddings are closest to a query vector, doing a brute-force scan on its own. Building an index with CREATE VECTOR INDEX switches it to approximate nearest neighbour (ANN), trading a little recall for a large speed gain on big vector sets. This retrieval step is the engine of RAG: embed the question, run VECTOR_SEARCH for the closest passages, then feed those passages to a generative model.

Trap Expecting an index to speed up a tiny vector set; below the size threshold BigQuery does not populate the index and the search just runs brute force anyway.

BigQuery vector index offers IVF and TreeAH, with three distance types

A BigQuery vector index supports two types: IVF (inverted file), which clusters vectors with k-means, and TreeAH, built on Google's ScaNN algorithm and optimized for batch queries that process many query vectors. The distance type can be EUCLIDEAN (the default), COSINE, or DOT_PRODUCT, and it must match how the embeddings were intended to be compared. Pick TreeAH when you score many query vectors in a batch and IVF for general single-query lookups.

Trap Leaving the distance type at the EUCLIDEAN default when the embeddings are meant for cosine similarity; the search then ranks by the wrong notion of closeness.

A BigQuery vector index is not populated below a 10 MB table size

If you create a vector index on a table smaller than 10 MB the index is not populated, and VECTOR_SEARCH silently falls back to a brute-force scan. If an indexed table later shrinks below 10 MB through deletions, the index is temporarily disabled. The threshold is on total table size, not row count, so on a trivially small corpus an index buys nothing and is expected to be skipped.

Trap Assuming a vector index always accelerates VECTOR_SEARCH; under 10 MB it is not populated, so the query runs brute force regardless.

RAG retrieves the closest passages and feeds them into the model's prompt

Retrieval-augmented generation grounds a generative model in your own data: embed the user's question, use vector search to retrieve the most relevant passages, then pass those passages into the model's prompt so it answers from retrieved context instead of only its training. The retrieval quality, driven by good chunking and the right distance metric, sets the ceiling on answer quality. In BigQuery the building blocks are ML.GENERATE_EMBEDDING, CREATE VECTOR INDEX, and VECTOR_SEARCH.

Object tables bridge SQL to unstructured images and PDFs in Cloud Storage

An object table is a read-only table over unstructured objects in Cloud Storage that exposes each object as a row carrying its uri and metadata, so you can run BigQuery ML inference or generative AI functions over images and documents and join the results to structured tables, all from SQL. The data stays in the bucket; the table only indexes it. Like a BigLake table, an object table uses access delegation, so users query it without direct read access to the underlying bucket.

Trap Loading the binary files into BigQuery to analyze them; an object table reads them in place in Cloud Storage instead of copying them into the warehouse.

BigQuery ML models register to the Vertex AI Model Registry for deployment

A model trained with BigQuery ML can be registered to the Vertex AI Model Registry, the versioning and governance point between build and serve, so it can later be deployed to an endpoint for online prediction. This bridges the SQL-trained model into the Vertex AI serving stack without rebuilding it. It is the path when analysts train in BigQuery ML but the model must serve real-time predictions through a managed endpoint.

Choose BigQuery vector search in-warehouse, Vertex AI Vector Search for serving at scale

Both BigQuery VECTOR_SEARCH and Vertex AI Vector Search implement approximate nearest neighbour on the same ScaNN-style technology; the split is analytical versus serving. Use VECTOR_SEARCH when the vectors live in BigQuery alongside your other data and you query them with SQL. Use Vertex AI Vector Search when you need low-latency ANN serving over very large vector sets as a standalone online endpoint, typically the retrieval tier of a production RAG application.

Trap Standing up Vertex AI Vector Search when the embeddings already sit in BigQuery and an in-warehouse VECTOR_SEARCH would serve the analytical query without a second system.

Prepare features in BigQuery or Dataflow, then train custom models on Vertex AI

When BigQuery ML does not cover the framework or you need GPUs and a custom loop, the data-engineering job is to shape features upstream and hand them to Vertex AI rather than train in SQL. Use BigQuery for structured feature transforms and Dataflow for large-scale conversion of unstructured data into training formats, then point Vertex AI custom training at the prepared data. This keeps the heavy data prep on the warehouse and the stream engine while the framework training happens on the ML platform.

Put preprocessing in the BigQuery ML TRANSFORM clause so it re-runs automatically at prediction

Preprocessing defined in the CREATE MODEL TRANSFORM clause is stored with the model and reapplied automatically during ML.PREDICT and ML.EVALUATE, which is what prevents training-serving skew. Analytic preprocessing functions used there require an OVER() clause so the statistics learned during training are reused at serving.

Trap Computing features in a separate query before training, leaving prediction to recompute them inconsistently.

7 questions test this

Combine categorical columns with ML.FEATURE_CROSS over a STRUCT

ML.FEATURE_CROSS(STRUCT(col_a, col_b, ...)) creates feature crosses—every combination of the supplied categorical columns—to capture interaction effects one feature alone can't express. Placed in the TRANSFORM clause, the cross is generated automatically during prediction as well as training.

Trap Passing the columns as bare arguments instead of wrapping them in a STRUCT as ML.FEATURE_CROSS requires.

5 questions test this

Bucket a skewed numeric feature by distribution with ML.QUANTILE_BUCKETIZE

ML.QUANTILE_BUCKETIZE splits a continuous column into buckets based on quantiles computed from the training data, so each bucket holds roughly equal counts—well suited to skewed columns with outliers. Used in the TRANSFORM clause with OVER(), the same quantile boundaries are reapplied at prediction.

Trap Reaching for fixed-width bucket boundaries when the distribution is skewed and equal-population quantile buckets are wanted.

3 questions test this

Honor a pre-assigned split column with DATA_SPLIT_METHOD='CUSTOM' and DATA_SPLIT_COL

Setting DATA_SPLIT_METHOD='CUSTOM' with DATA_SPLIT_COL lets BigQuery ML split on a column you already populated. With a BOOL column, TRUE or NULL rows go to evaluation and FALSE rows to training; with hyperparameter tuning a STRING column accepts 'TRAIN', 'EVAL', and 'TEST'. The split column is excluded from the model's features.

Trap Assuming TRUE rows in a custom BOOL split feed training—TRUE (and NULL) actually mark evaluation rows.

5 questions test this

Scale pandas-style preprocessing with the Apache Beam DataFrames API on Dataflow

The Apache Beam DataFrames API offers a pandas-like interface so data scientists keep familiar syntax while Beam distributes the work across workers; running the pipeline on Dataflow provides fully managed, autoscaling infrastructure. This lets logic prototyped on a small pandas DataFrame run over datasets far too large for one machine with minimal code change.

Trap Running plain pandas, which loads the whole dataset into a single machine's memory and won't scale to terabytes.

3 questions test this

Use Beam MLTransform with artifact locations to apply identical transforms in training and serving

MLTransform bundles multiple Apache Beam ML preprocessing operations (ComputeAndApplyVocabulary for categorical-to-index, ScaleToZScore for z-score normalization, TFIDF, etc.) in one class. Writing to write_artifact_location during training saves the learned vocab and normalization stats, and read_artifact_location reapplies the same transforms at inference, eliminating training-serving skew.

Trap Recomputing vocabulary and scaling stats at serving time instead of reading the artifacts saved during training.

5 questions test this

Two lanes for ML data, one shared rule

Lane 1: features for training and serving

Shaping features and training in SQL

One feature, both paths: avoiding training-serving skew

Lane 2: embeddings, vector search, and RAG

Generate embeddings in BigQuery

Index and search the vectors

Reaching unstructured files in Cloud Storage

BigQuery ML or Vertex AI: choosing per job

Reading the stem: which prep, which service

Where to prepare each kind of ML data on Google Cloud

Decision tree

Cheat sheet

References