Skip to content

MLA-C01 Study Notes

Task 1.2: Transform Data and Perform Feature Engineering

Exam weight focus: Domain 1 (Data Preparation for Machine Learning) – this task is heavily tested via scenario questions on encoding choices, missing-value strategy, scaling/normalization decisions, and which AWS tool to reach for (DataBrew vs Data Wrangler vs Glue vs Feature Store vs Ground Truth).

1. Task Overview & Why It Matters

Before any model training you must turn raw, dirty, heterogeneous data into clean numeric (or properly tokenized) tensors/features that algorithms can consume. The exam expects you to know both the statistical techniques and the managed AWS services that implement them at scale, plus when to choose one service over another.

Knowledge You Must Own

  • Data cleaning / transformation: outlier detection & treatment, missing-value imputation, deduplication, joins/combining datasets.
  • Feature engineering: scaling & standardization, normalization, log/power transforms, binning/discretization, feature splitting, polynomial/interaction features, dimensionality reduction (PCA).
  • Encoding: one-hot, label/ordinal, binary, target/mean encoding, tokenization (NLP).
  • Tools: SageMaker Data Wrangler, AWS Glue DataBrew, AWS Glue (Spark ETL), Spark on EMR (rare on exam for this task), SageMaker Feature Store, SageMaker Canvas (no-code path).
  • Streaming transforms: Lambda, Spark Structured Streaming, Kinesis Data Analytics.
  • Labeling: SageMaker Ground Truth, Amazon Mechanical Turk, private workforces.

Skills You Must Demonstrate

  • Build DataBrew recipes or Data Wrangler flows that clean + encode + scale.
  • Materialize features into SageMaker Feature Store (online + offline).
  • Launch (or design) Ground Truth labeling jobs that produce high-quality labels.
  • Choose the correct imputation / encoding / scaling method for a given algorithm and data type.

2. Core Concepts – Quick Reference (Exam High-Yield)

Concept When to use Classic exam trap
One-hot encoding Nominal categorical → numeric for linear models, trees, NNs Choosing target encoding or tokenization instead
Label / ordinal encoding Ordered categories (low/med/high) Using one-hot and exploding dimensionality
Normalization (min-max) Distance-based algos (KNN, K-means, neural nets with sigmoid) Forgetting it when features have vastly different ranges
Standardization (z-score) PCA, linear/logistic regression, SVM, when outliers are already handled Confusing with normalization
Log transform Right-skewed continuous targets/features Applying to already-normal or negative data
Imputation (mean/median/MICE/supervised) Missing < ~20-25 %; never drop if feature is predictive “Just drop the column/row” when % is moderate
PCA / feature selection Multicollinearity or pure dimensionality reduction before linear models Using PCA before tree-based models (usually unnecessary)
Binning Turn continuous into categorical or reduce noise Over-binning and losing signal

Transcript gold: • “You need to transform categorical features into numeric values → one-hot encoding with DataBrew recipe actions.” • “KNN + features on different scales → normalization.” • “15 % missing → supervised imputation or MICE preferred over drop or simple mean.”

⚠️ Frequent traps * Target encoding when the question asks for binary values → one-hot (or binary encoding) is correct. * Tokenization when the column is a simple categorical string, not free text. * Dropping columns that contain only 10-15 % missing values (you may discard signal). * Using Amazon Forecast filling methods on non-time-series tabular data. * Leaving SageMaker Studio / Data Wrangler apps running (cost + exam red-herring about “always-on” tools).

3. Hands-On Exercises (Cost-Minimized)

💡 Cost-control rules used in every exercise * Work with < 5–10 MB sample CSVs only. * Prefer serverless (DataBrew, Glue Python shell / small Spark, Lambda). * SageMaker Studio: use ml.t3.medium (or the cheapest available), create the flow, export, then immediately shut down the Kernel Gateway app and Studio application. Delete the domain if you created it solely for this lab. * Feature Store: create offline-only feature groups (S3) whenever possible; delete feature groups after the exercise. * Ground Truth: use a private workforce (your own IAM users) and ≤ 20 data objects so you incur almost zero labeling spend. * Delete every S3 object, Glue database/table, DataBrew project, and CloudWatch log group when finished. Set a 1-day S3 lifecycle rule on the bucket. * Never leave EMR clusters or large Processing jobs running.

Estimated total cost for all four exercises if cleaned up promptly: < $2–4.

Exercise 1 – AWS Glue DataBrew: Cleaning, Imputation, One-Hot Encoding, Scaling (Serverless, Lowest Cost)

Goal: Reproduce the exact scenario that appears in the exam sample questions (categorical → numeric, missing values, scaling).

  1. Prepare tiny dataset (local machine):
id,age,income,city,education,target
1,34,52000,Seattle,Bachelor,1
2,,48000,Portland,Master,0
3,41,72000,Seattle,,1
4,29,39000,Portland,Bachelor,0
5,37,,Austin,PhD,1
… (add ~50–100 rows total, introduce ~15 % nulls and a couple of duplicate rows)

Save as raw_customers.csv (keep < 50 KB).

  1. Create an S3 bucket mla-c01-feature-lab-YOURNAME (region us-east-1). Upload the CSV to s3://…/raw/. Apply a lifecycle rule: expire after 1 day.
  2. Console → AWS Glue DataBrew → Datasets → Connect new dataset → S3 → select the CSV → name it raw-customers.
  3. Create project → “Project from dataset” → new recipe customer-feature-recipe. DataBrew opens the interactive grid.
  4. Apply recipe steps (exactly the transforms the exam loves):
  5. Deduplicate rows (whole-row match).
  6. Handle missing: age → impute median; income → impute mean; education → impute mode (or “Unknown”).
  7. Outliers: flag or cap income with IQR method (optional but good to see).
  8. One-hot encode city and education (DataBrew recipe action “One-hot encode column”).
  9. Normalize (min-max) the numeric columns age and income into new columns age_norm, income_norm.
  10. Optional: bin age into 3 equal-width bins.

  11. Delete original city/education columns if desired.

  12. Run the recipe job → output to s3://…/curated/ (choose “Replace” or “Create new” table). Use 2 max capacity units and on-demand; job finishes in < 2 min.

  13. Profile the output dataset (DataBrew data profile) – verify null counts = 0, new one-hot columns exist, values of normalized columns sit in [0,1].

Expected result: A clean Parquet/CSV in S3 with numeric-only features, no nulls, one-hot columns, and scaled values. The DataBrew job run history shows the recipe steps you can screenshot for notes.

Maps directly to exam items: * “Transform categorical features into numeric → one-hot with DataBrew.” * Missing-value handling without dropping columns. * Normalization before distance-based models.

Exercise 2 – SageMaker Data Wrangler + Quick Feature Store Ingestion (No-Code + Light Code)

Goal: Experience the Canvas/Data Wrangler path mentioned in the official video and push features into Feature Store.

  1. Create a SageMaker Studio domain (Quick setup, IAM role with S3 + Feature Store full access). Choose the smallest instance.
  2. Open Studio → Data Wrangler → Import from S3 the curated file from Exercise 1 (or the raw file if you want to repeat transforms).
  3. Add transform steps (visual):
  4. Encode categorical (one-hot or ordinal).
  5. Scale features (Standardize or Min-Max).
  6. Custom formula or log transform on a skewed column.
  7. Join (if you upload a second tiny lookup file).

  8. Analysis: feature correlation matrix, target leakage check, histogram.

  9. Export → “Save to SageMaker Feature Store”.

  10. Create a new feature group customer-features-offline.
  11. Select offline store only (S3 location under your bucket). Uncheck online store to save money.

  12. Ingest the data; wait for the processing job (uses a small ml.m5.xlarge by default – stop it the moment it succeeds).

  13. In a Studio notebook (Python 3, Data Science image) run a quick query:

from sagemaker.feature_store.feature_group import FeatureGroup
fg = FeatureGroup(name="customer-features-offline", sagemaker_session=sess)
fg.athena_query().run(...)  # or use the built-in Data Wrangler query

Confirm rows appear.

  1. Immediate cleanup: In Studio, stop all Kernel Gateway and Data Wrangler apps → delete the feature group → empty the S3 prefix → delete Studio domain if no longer needed.

Expected result: Feature group visible in Feature Store console, Athena table queryable, Data Wrangler flow exportable as a Python script or Pipeline step. You have practiced the exact integration path the transcript describes (Data Wrangler → Processing / Pipelines / Feature Store).

Exam link: “After defining a data workflow you can integrate it with SageMaker Processing, Pipelines and Feature Store.” Also tests that you know Data Wrangler can emit a pure Python script for later automation.

Exercise 3 – Missing-Value Strategies & Simple Supervised Imputation (Glue + Tiny Spark or Pandas in DataBrew / Studio)

Goal: Internalize why “drop column” or “fill zero” is usually wrong and why MICE / model-based imputation is preferred.

  1. Use the same raw CSV that contains deliberate 15 % nulls.
  2. In DataBrew (or a free-tier-ish local Pandas + upload, or a 1-minute Glue Python shell job) create three versions:
  3. A = drop any row with null.
  4. B = fill numeric with 0 / mean, categorical with mode.

  5. C = simple supervised: train a tiny RandomForest on the complete rows to predict the missing age/income, then fill. (You can do C in a Studio notebook with scikit-learn in < 20 lines; shut the notebook kernel down immediately.)

  6. Compute basic stats (mean, std, correlation with target) on A/B/C and observe how much the distribution shifts.

Expected result: Version C preserves far more rows and keeps feature-target correlation closer to the complete-case distribution. This matches the transcript recommendation: “supervised learning methods to estimate the missing values … better than mean or drop.”

⚠️ Trap reminder: Exam may offer “drop the 15 % column” as a tempting answer – it is almost always incorrect if the feature has predictive power.

Exercise 4 – Data Labeling with SageMaker Ground Truth (Private Workforce, Tiny Job)

Goal: Touch the labeling service that produces the high-quality labeled datasets mentioned in the task statement.

  1. Upload 10–20 small images (or text snippets) to S3. Create a manifest file.
  2. Ground Truth → Labeling jobs → Create.
  3. Task type: Image classification (or Text classification).
  4. Workforce: Private → create a private team and add your own IAM user / email.
  5. Labeling UI: use the built-in template.

  6. Output path under your lab bucket.

  7. Start the job; label the 10–20 items yourself in the worker portal (takes 5 minutes).

  8. When complete, examine the output augmented manifest (now contains human labels). Optionally chain it into a Data Wrangler flow or Feature Store.
  9. Delete the labeling job, private team, and S3 objects.

Expected result: An augmented manifest ready for supervised training. You understand the Ground Truth → labeled dataset path and the cost model (you paid almost nothing because you were the only worker).

💡 Mechanical Turk public workforce is deliberately avoided – it can incur unpredictable spend and is unnecessary for learning the concept.

Bonus Micro-Exercise (Streaming Transform – Lambda)

Create a 3-line Lambda (Python) that receives a JSON payload, performs a simple log transform + one-hot style mapping, and writes to S3. Trigger it from the console test event. Delete the function afterwards. Demonstrates “services that transform streaming data (Lambda)” at near-zero cost.

4. Exam Tips & Traps Mapped to the Exercises

Exam Scenario Correct Approach (you practiced) Common Wrong Answer
Categorical → numeric for better accuracy DataBrew / Data Wrangler one-hot (Ex 1 & 2) Target encoding, tokenization, date formatting
Convert column to binary values One-hot (or binary encoding) Target encoding, tokenization
~15 % missing values, reduce bias Supervised / MICE imputation (Ex 3) Drop column, fill 0, mean without care
KNN / distance algo + wildly different scales Normalization (min-max) (Ex 1) PCA only, label encoding
Need reusable, shareable features SageMaker Feature Store offline/online (Ex 2) Leave CSVs in S3 forever
Human labeling for ground-truth dataset Ground Truth private workforce (Ex 4) Manual Excel, or public MTurk without budget control
No-code / low-code prep that later becomes a pipeline Data Wrangler flow → export script / Processing / Pipelines (Ex 2) Only raw Glue code from day one

Remember the “why”: Feature engineering and cleaning exist to increase signal-to-noise, remove bias, satisfy algorithm assumptions (Gaussian, distance, numeric input), and improve final model metrics. The services (DataBrew, Data Wrangler, Feature Store, Ground Truth) simply make those techniques scalable and repeatable.

5. Minimal Cleanup Checklist (Do This Every Time)

  • [ ] Empty and delete lab S3 bucket (or let 1-day lifecycle finish).
  • [ ] Delete DataBrew projects, recipes, datasets, jobs.
  • [ ] Delete Glue catalog databases/tables if created.
  • [ ] Delete Feature groups.
  • [ ] Stop & delete all Studio apps → delete domain (if temporary).
  • [ ] Delete Ground Truth labeling jobs & private teams.
  • [ ] Delete Lambda functions & any IAM roles created solely for the lab.
  • [ ] Check Cost Explorer next day for any residual charges.

6. Additional Quick-Reference Resources (Official)

  • Glue DataBrew built-in recipe steps (one-hot, impute, scale, outlier)
  • SageMaker Data Wrangler transform list + Feature Store integration docs
  • SageMaker Feature Store Developer Guide (offline vs online)
  • Ground Truth “Create a private workforce” + augmented manifest format
  • Scikit-learn / Spark MLlib equivalent of each transform (useful when the exam asks “which algorithm under the hood”)

End of Task 1.2 study notes. Master the four exercises, keep the cost checklist sacred, and the encoding / imputation / scaling questions on the real MLA-C01 will feel familiar.