← All Google Cloud AI guidesFundamentals · 2.1, 3.1
ML fundamentals 1: data, feature engineering and class imbalance
The data half of ML fundamentals: framing a problem, splitting data without leaking the answer, every common feature-engineering technique and when to use it, missing values, feature selection, and a deep treatment of class imbalance (weights, resampling, SMOTE, thresholds, probability correction). Maps each technique to BigQuery ML, TensorFlow Transform and Dataflow.
1. Framing the problem before touching data
Many exam questions are lost before any modelling: the problem was framed wrongly. Before choosing a model, answer these:
| Question | Why it matters |
|---|---|
| Is ML needed at all? | If a rule or a SQL query solves it reliably, that's cheaper and explainable. ML is for patterns too complex to write by hand. |
| What exactly is predicted, and when? | "Will this customer cancel in the next 30 days, predicted on the 1st of each month" defines the label, the prediction time and which data is allowed. |
| What kind of problem is it? | Binary or multi-class classification, multi-label, regression, forecasting, ranking/recommendation, clustering, anomaly detection, generation. |
| What's the baseline? | A majority-class guess, last value, a simple rule, or a linear model. Every model must beat it to be worth shipping. |
| What's the business metric, and what does each error cost? | Decides the evaluation metric and the threshold (see Fundamentals 2). |
| Do labels exist, and how quickly do they arrive? | No labels: unsupervised, weak supervision, or a labelling project. Late labels: retraining and monitoring must account for the delay. |
Write the prediction as a sentence with a time: "At time t, using only data available before t, predict y over window w." Most leakage bugs are violations of that sentence.
2. Data quality and exploration
Exploratory data analysis (EDA) finds problems that would otherwise surface as a mysteriously bad or suspiciously good model.
| Check | What to look for | On Google Cloud |
|---|---|---|
| Schema and types | Numbers stored as strings, mixed date formats, IDs read as numbers | BigQuery schema, INFORMATION_SCHEMA, TensorFlow Data Validation (TFDV) schema |
| Missing values | Rates per column, and whether missingness is itself informative | COUNTIF(col IS NULL), data profile scans (Dataplex) |
| Distributions and outliers | Heavy tails, impossible values (negative ages), sentinel values like -999 | APPROX_QUANTILES, TFDV statistics, notebook histograms |
| Label quality and balance | Class ratios, noisy or inconsistent labels, label definition drift over time | GROUP BY label, label audits |
| Duplicates | Exact or near duplicates across train and test inflate scores | Hash rows; dedupe before splitting |
| Correlations | Features nearly identical to the label (leakage suspects), or to each other (redundancy) | CORR(), feature importance |
| Time coverage | Gaps, seasonality, sudden changes in how data was recorded | Counts per day; plot over time |
3. Splitting data correctly
| Split type | When | Why |
|---|---|---|
| Random train / validation / test (for example 80/10/10) | Independent rows, no time dependence | Simple and unbiased when rows really are independent |
| Stratified | Classification, especially imbalanced | Keeps the class ratio equal in every split, so the rare class appears in validation and test |
| Time-based (train on the past, test on the future) | Forecasting, or any data where the world changes over time (fraud, churn, prices) | A random split lets the model learn from the future it's tested on |
| Group-based | Several rows per user, patient, device or session | All rows of one group stay in one split, or the model memorizes the entity instead of learning the pattern |
- Validation is for choosing models, features, hyperparameters and thresholds. Test is touched once, at the end. Tuning on test makes its score optimistic.
- Fit preprocessing (means, vocabularies, scalers) on training data only, then apply it to validation and test.
- BigQuery ML:
data_split_method=AUTO_SPLIT,RANDOM,CUSTOM(your boolean column),SEQ(by an ordering column, for time) orNO_SPLIT. - Reproducible splits in SQL:
MOD(ABS(FARM_FINGERPRINT(CAST(user_id AS STRING))), 10) < 8puts each user consistently in the training set (a group-based, repeatable split).
4. Data leakage
Leakage means the model sees information during training that it won't have at prediction time. It produces excellent offline metrics and poor production results, and it's one of the most tested fundamentals.
| Type | Example | Prevent it |
|---|---|---|
| Target leakage | Predicting churn with "cancellation_reason" or "refund_issued", recorded only after the customer leaves | For each feature, ask "is this known at prediction time?"; build features as of the prediction timestamp |
| Temporal leakage | Random split of time-series data; a 30-day rolling average that includes future days | Time-based splits; windows that end before the prediction time; point-in-time feature lookups |
| Train-test contamination | Scaling or imputing with statistics computed on all data; duplicates in both splits | Fit transforms on training data only; deduplicate before splitting |
| Group leakage | The same patient's scans in training and test | Group-based splits |
| Target encoding leakage | Replacing a category with the average label computed including the row itself | Out-of-fold target encoding with smoothing |
| Proxy leakage | An "account_closed_date" column that's null for active customers | Inspect features with suspiciously high importance |
A sudden jump to near-perfect validation scores after adding one feature almost always means leakage, not a breakthrough. Check feature attributions: a single dominant feature is the usual tell.
On Google Cloud, point-in-time lookups in the Feature Store (and ML.FEATURES_AT_TIME / ML.ENTITY_FEATURES_AT_TIME in BigQuery) return each feature's value as it was at the label's timestamp, which prevents temporal leakage when building training sets.
5. Feature engineering: numeric features
| Technique | What it does | Use when | BigQuery ML |
|---|---|---|---|
| Standardization (z-score) | (x − mean) / std | Linear models, neural networks, k-means, anything with gradients or distances | ML.STANDARD_SCALER |
| Min-max scaling | Rescale to [0, 1] | Bounded inputs, neural networks; sensitive to outliers | ML.MIN_MAX_SCALER |
| Robust scaling | Uses median and interquartile range | Outliers present | ML.ROBUST_SCALER |
| Log transform | log(x + 1) | Heavy right tails (income, counts, prices) | LOG(x + 1) in TRANSFORM |
| Bucketizing (binning) | Turns a number into ranges | Non-linear effects in linear models (age bands); quantile buckets give equal-sized bins | ML.BUCKETIZE, ML.QUANTILE_BUCKETIZE |
| Clipping | Caps values at percentiles | Extreme outliers that would dominate training | LEAST/GREATEST |
| Polynomial features | x², x·y | Curved relationships in linear models | ML.POLYNOMIAL_EXPAND |
| Ratios and differences | spend per visit, days since last order | Domain knowledge; often the strongest features | SQL expressions |
Tree-based models (boosted trees, random forests) don't need scaling or log transforms: they split on thresholds. Linear models, neural networks and distance-based methods do.
6. Feature engineering: categorical features
| Technique | How | Use when | Watch out |
|---|---|---|---|
| One-hot encoding | One binary column per value | Few distinct values (tens) | Explodes with high cardinality; unseen values at serving need a default |
| Label / ordinal encoding | Integer per value | Truly ordered values (small < medium < large), or tree models | Implies an order linear models will misuse |
| Feature hashing (hash buckets) | hash(value) mod N | Very high or unbounded cardinality (URLs, IDs); new values appear constantly | Collisions merge unrelated values; pick N to keep them rare |
| Embeddings | Learned dense vectors per value | High cardinality in neural networks (user IDs, products, words) | Need enough data per value; cold start for new values |
| Target (mean) encoding | Replace a value with the mean label for it | High-cardinality features in tree models | Leakage unless out-of-fold and smoothed |
| Frequency encoding | Replace with how often the value occurs | Popularity matters | Different values can share a frequency |
| Grouping rare values | Map values below a count to "OTHER" | Long tails; keeps vocabularies stable | Choose the threshold on training data |
- Feature crosses combine features (country × device) so linear models can learn interactions:
ML.FEATURE_CROSS(STRUCT(country, device)). Neural networks and trees learn interactions themselves. - Vocabulary: built from training data; out-of-vocabulary (OOV) values at serving must map to a reserved bucket.
"Few: one-hot. Many: hash or embed. Ordered: ordinal. Interacting: cross."
7. Text, image, time and geospatial features
| Data | Classic features | Modern features |
|---|---|---|
| Text | Bag of words, n-grams, TF-IDF (term frequency–inverse document frequency); ML.NGRAMS, ML.TF_IDF in BigQuery ML | Embeddings from a pretrained model (Gemini embeddings via ML.GENERATE_EMBEDDING), or fine-tuning a transformer |
| Images | Resizing, normalization, colour histograms | Transfer learning from a pretrained CNN or vision transformer; augmentation (flip, crop, rotate) to add variety |
| Time / dates | Hour, day of week, month, holiday flag; cyclical encoding with sine and cosine so 23:00 is close to 00:00 | Lags (value 1, 7, 28 days ago), rolling means and counts over windows that end before the prediction time |
| Geospatial | Latitude and longitude buckets, crosses of lat × long, distance to points of interest | Geohash or S2 cells, BigQuery GIS functions (ST_DISTANCE) |
| Sequences / events | Counts per window, time since last event | Sequence models, session embeddings |
Rolling and lag features must be computed with windows that end before each prediction time. A window centred on the event, or computed over the full table, leaks the future.
8. Missing values
| Approach | When |
|---|---|
| Drop rows | Few rows affected, missing at random, plenty of data |
| Drop the column | Mostly missing and not informative |
| Impute mean or median (numeric), most frequent (categorical) | Simple baseline; median for skewed data. ML.IMPUTER in BigQuery ML |
| Add a "was missing" indicator | Missingness carries signal (no phone number on file) |
| Model-based imputation | Strong relationships between features; more effort |
| Let the model handle it | Gradient-boosted trees (XGBoost, BigQuery ML boosted trees) learn a default direction for missing values |
Whatever you choose, apply the same imputation values at serving, computed from training data. BigQuery ML's
TRANSFORM, TensorFlow Transform and in-model preprocessing layers do this automatically.9. Feature selection
| Family | Examples | Trade-off |
|---|---|---|
| Filter methods | Correlation with the label, mutual information, chi-squared, variance threshold | Fast, model-independent; miss interactions |
| Wrapper methods | Forward selection, backward elimination, recursive feature elimination | Model-aware; expensive |
| Embedded methods | L1 (lasso) regularization drives useless weights to zero; tree feature importance | Selection happens during training |
| Attribution-based | Shapley values, permutation importance, ML.FEATURE_IMPORTANCE, ML.GLOBAL_EXPLAIN | Explains a trained model; good for pruning |
| Dimensionality reduction | PCA (model_type='PCA'), autoencoders | Compresses correlated features; components lose direct meaning |
Fewer, better features mean faster training and serving, less overfitting, simpler monitoring and fewer things that can drift or break.
10. Class imbalance in depth
Imbalance means one class is much rarer than the other (fraud at 0.1%, defects at 0.5%). It causes three problems: misleading metrics (accuracy looks great), a model that ignores the rare class (the loss is dominated by the majority), and too few positive examples to learn from.
1. Measure correctly first
- Never judge on accuracy. Use precision, recall, F1, PR AUC, and recall at a fixed precision (or the reverse). See ROC vs PR.
- Use stratified splits so the rare class appears in every split; keep validation and test at the true class ratio.
2. Change how the model learns
| Technique | How | Pros | Cons |
|---|---|---|---|
| Class weights | Multiply the loss of rare-class errors (for example weight = N / (2 × Nclass)) | No data thrown away; one parameter. auto_class_weights=TRUE in BigQuery ML, class_weight in Keras, scale_pos_weight in XGBoost | Probabilities become miscalibrated (too high for the rare class) |
| Downsampling the majority (undersampling) | Keep a fraction of majority rows | Faster training; often fine with huge data | Discards information; probabilities need correction |
| Downsample + upweight | Downsample the majority by factor k, then weight those rows by k | Google's recommended pattern: fast training with calibrated probabilities | One more parameter |
| Oversampling the minority | Duplicate rare rows | Simple | Overfits the duplicated rows; oversample after splitting, never before |
| SMOTE (synthetic minority oversampling) | Creates synthetic rare examples between neighbours | More variety than duplication | Can create unrealistic points; tabular numeric data only; apply only to training |
| Focal loss | Down-weights easy, well-classified examples | Strong for dense detection and extreme imbalance in deep learning | Extra hyperparameter |
| Anomaly-detection framing | Model "normal" and flag deviations (autoencoder, k-means distance, isolation forest) | When positives are extremely rare or unlabelled | Harder to target a specific kind of positive |
| Collect or label more positives | Active learning, labelling campaigns, data from related sources | Often the biggest gain | Time and cost |
3. Choose the operating point
- Move the threshold instead of (or as well as) resampling: lower it to catch more positives, raise it for fewer false alarms. Pick it on validation data from the cost of each error type.
- If you resampled or weighted, recalibrate probabilities before using them as probabilities (for example in expected-cost decisions), or use the downsample-and-upweight pattern.
Resample only the training set, after splitting. Oversampling before the split copies the same rare rows into test, and evaluating on a rebalanced test set reports precision you'll never see in production.
11. Class imbalance calculator
Enter your class counts and a downsampling plan. The calculator gives balanced class weights, the training ratio after downsampling, the weight that restores calibration, and how to convert a probability from the downsampled model back to the real-world probability.
12. Doing feature engineering on Google Cloud
| Tool | Feature engineering role |
|---|---|
BigQuery ML TRANSFORM | Scalers, bucketizers, imputers, crosses, n-grams stored with the model and applied at prediction automatically |
| TensorFlow Transform (on Dataflow) | Full-pass statistics (vocabularies, means) computed at scale and exported into the serving graph |
Keras preprocessing layers, scikit-learn Pipeline / ColumnTransformer | Preprocessing saved inside the model artifact |
| Dataflow / Spark | Large-scale joins, windows and streaming features |
| Feature Store on Agent Platform | Shared, versioned features with point-in-time training data and online serving |
| Data preparation in BigQuery, Gemini in BigQuery | Low-code cleaning suggestions |
The exam's theme: one implementation of preprocessing, used for training and serving. Different code paths are the main cause of training-serving skew.
13. "Which technique?" chooser
Pick an item to see what it means, why, and the tempting wrong choice.
Pick one above.
14. Scenarios
Exam-style situations: how to diagnose each one, the likely cause and the fix.
15. Searchable reference
| Item | Meaning |
|---|
16. Flashcards (click to flip)
17. Common gotchas in one list
- Ask of every feature: is it known at prediction time? If not, it leaks.
- Random splits leak the future for time-dependent data; split by time.
- Keep each user, patient or device in one split.
- Fit preprocessing on training data only and reuse the same statistics at serving.
- Resample only the training set; validate and test at the real class ratio.
- Accuracy hides imbalance; use precision, recall, PR AUC.
- Class weights and resampling distort probabilities: recalibrate, or downsample and upweight.
- Trees don't need scaling; linear models, neural networks and k-means do.
- One-hot for few values; hashing or embeddings for many; plan for unseen values.
- Linear models need feature crosses for interactions.
- Target encoding must be out-of-fold, or it leaks the label.
- A sudden near-perfect score means leakage until proven otherwise.
- Windows must end before the prediction time for lag and rolling features.
- Often the best imbalance fix is more positive examples.
18. Practice quiz (22 questions)
Score: 0 / 0