Data Engineering and Feature Pipelines
Domain 2 tests whether you can build repeatable, leak-free data and feature pipelines: ingestion, validation, versioning, transformation, feature stores, and train-serving parity.
Contracts and lineage
- Every source needs a schema contract, freshness SLA, owner, and quality checks for nulls, ranges, duplicates, and referential integrity.
- Version raw data, transformation code, and feature definitions together; a model is only reproducible if its input snapshot and logic are reproducible.
- Prefer immutable, append-only event data and idempotent batch jobs so reruns do not duplicate records.
Feature-store correctness
Offline and online stores must use the same aggregation definition. Point-in-time joins prevent leakage: for a label at time T, use only feature values known before T. Time windows must use event time, not ingestion time, and late-arriving data needs a documented backfill policy.
Worked example
A fraud feature is “average transaction amount in the last 30 days.” A naive offline query computes the average over the full history, including transactions after the label. That inflates offline AUC and fails online. Correct design: for each labeled transaction at event time T, join features from [T-30d, T), then materialize the same logic to the online store with a TTL of 30 days. Reasoning: the online model sees only past events, so offline training must match that information set.
Traps
- Random splits on temporal data, which leak future information.
- Different SQL for offline training and online serving.
- Backfills that change historical feature values without versioning.
- No monitoring for schema drift or late data.