2.3.2. Data Quality Validation with Glue Data Quality and DataBrew

💡 First Principle: Data quality validation should be automated and run before every training job—not as a one-time manual check. Production data quality degrades over time as upstream sources change, and a model trained on silently corrupted data produces silently wrong predictions. Automated quality gates catch problems before they reach the model.

Think of data quality validation like the quality control department in a factory. Every batch of raw materials gets inspected before entering the production line. If steel has impurities, the cars built from it will fail. Similarly, if training data has null explosions, type mismatches, or distribution shifts from the expected baseline, the model trained on it will underperform.

AWS Glue Data Quality lets you define rules against your data:

• Completeness: "Column X has >95% non-null values"
• Uniqueness: "Column ID has 100% unique values"
• Freshness: "Data was updated within the last 24 hours"
• Custom rules: "Column age has values between 0 and 120"

AWS Glue DataBrew provides visual data profiling that automatically generates statistics: missing value percentages, value distributions, outlier counts, and correlation matrices. This is the discovery phase before you define quality rules.

Data Splitting for ML: Proper splitting (train/validation/test) is a quality gate itself. Key practices:

• Stratified splitting preserves class proportions across splits
• Time-based splitting for time-series (train on past, test on future—never the reverse)
• Shuffling before splitting prevents order-dependent bias
• SageMaker Processing jobs can automate splitting as a pipeline step

Data Augmentation increases dataset size and diversity without collecting new data. For images: rotation, flipping, cropping, color adjustment. For text: synonym replacement, back-translation, random insertion. For tabular: SMOTE (as discussed in 2.3.1). Augmentation also serves as implicit regularization, reducing overfitting by exposing the model to more variations.

⚠️ Exam Trap: Time-series data must never be randomly shuffled before splitting. If you shuffle, future data leaks into the training set, and the model learns patterns it wouldn't know at prediction time. This is called "data leakage" and the exam specifically tests for it. Always use chronological splits for time-series.

Reflection Question: A data quality check reveals that 8% of records in a production dataset have null values in a critical feature. Last month, the null rate was 2%. What does this trend suggest, and what automated action should the pipeline take?