What's changed: Deepened MLS-C01 Chapter 2 (Pearson/Spearman/VIF/log transform, AWS viz tools/pitfalls/t-SNE, two leakage kinds/preprocessing order/Glue DataBrew/time-series split + tables, scenarios, FAQ, traps; ja figures)
2.3Preprocessing and Data Quality
Prepare for the model—understand imputation, outlier handling, encoding/scaling, class-imbalance handling (SMOTE), and avoiding data leakage.
Resolve issues found in EDA via preprocessing: fix missing values, outliers, scale, and imbalance—while avoiding data leakage—before feeding the model.
2.3.1Preprocessing flow
- Imputation: fill with mean/median/mode, or drop columns with heavy missingness.
- Encoding/scaling: categoricals via one-hot/label, numerics via normalize/standardize; log-transform skew.
- Class imbalance: handle with SMOTE (oversampling)/undersampling/class weights.
- Avoid leakage: fit scalers/encoders on training data only, then apply to validation/test.
Common on MLS-C01: class imbalance = SMOTE/undersampling/class weights, fit scalers on training data only (do not fit on test = avoid leakage), categoricals = one-hot/label encoding, and skewed distributions = log transform. Fitting preprocessing on all data causes leakage and over-optimistic evaluation.
MLS-C01 frequently trips people on the kinds of data leakage and the relationship between preprocessing order and splitting. There are two main leaks: (1) target leakage—the label’s information (or a future value unavailable at inference in production) sneaks into a feature (e.g., putting "cancellation fee incurred after churn" into a churn predictor); and (2) train-test contamination—fitting preprocessing (scaling, imputation, encoding, feature selection, SMOTE) on all data before splitting, leaking test information into training. The correct order is split first → fit on training only → transform validation/test with the same fit, automated by a scikit-learn Pipeline or SageMaker preprocessing steps (Processing Job → Pipelines). Resampling like SMOTE must happen only within the training folds, never on validation/test (which should reflect the production imbalance). Inspect data quality along completeness (missing), uniqueness (duplicates), consistency (types/ranges/contradictions), accuracy, and timeliness; on AWS use Glue DataBrew (no-code cleansing, 250+ transforms, profiling), SageMaker Data Wrangler (quality insights + exportable transforms), and Glue (Spark)/EMR for large distributed processing. For time-series splits, avoid future-to-past leakage by using time-ordered splits (earlier for training, later for validation) rather than random splits. For imputation, choose methods that preserve distribution (group-wise median, KNN imputation) and beware of underestimating variance through imputation.
| Leakage/quality topic | Problem | Fix |
|---|---|---|
| Target leakage | Future/label info in features | Use only inference-time info |
| Train-test contamination | Fit on all data, test leaks | Fit on train after split |
| Misusing SMOTE | Applied to test, optimistic eval | Apply within train folds only |
| Time-series split | Random split leaks future | Time-ordered split |
Scenario: a churn model’s validation accuracy is suspiciously high but it fails completely in production. → Suspect target leakage. Check whether features include information not available at inference time, such as a penalty finalized after cancellation or a status updated after the cancellation date. Also verify you didn’t fit scaling/imputation on all data before the split (train-test contamination).
FAQ: Q. Apply SMOTE to validation too? A. No—only within training folds; validation/test should reflect production imbalance. Q. No-code cleansing? A. Glue DataBrew (profiling + 250+ transforms); use Data Wrangler to wire transforms into the ML pipeline. Q. Random-split a time series? A. No—future leaks into training; split by time order.
Trap: "apply SMOTE to all data then split" is false—synthetic samples leak into test/validation and inflate evaluation. Resample after the split, on training data only. Also "always impute missing values with the mean" is wrong: the mean is sensitive to outliers, so median or group-wise imputation often fits better, and if missingness is informative, keep a missing flag.
2.3.2Section summary
- Preprocess = impute → encode/scale → handle imbalance
- Imbalance = SMOTE etc.; avoid leakage = fit on training data only
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. In classification, target classes are heavily skewed 95:5. Appropriate handling?
Q2. When standardizing (scaling), what is correct to avoid data leakage?
Q3. Make a categorical variable (e.g., color = red/blue/green) usable by an ML model. Common method?