A wireless carrier's churn model rebuilds the same expensive call-detail aggregates at the start of every training run, even though those aggregates rarely change. The next runs should read the finished values. Which practice fits?
Select an answer to reveal the explanation.
Short Explanation
Rebuilding the same aggregates every run is like remaking lunch from scratch when yesterday's lunch is still in the fridge. Persisting the features lets the next training run reuse the stored values, which is the saving you want. The trap is recomputing from raw detail every time, the habit this pipeline is trying to break.
Full Explanation
Persisted features are computed once and stored so later training runs read the finished values instead of repeating the same expensive work. The churn aggregates rarely change, so writing them to a feature table and reusing them is the practice that matches the carrier's goal. Dropping the aggregates and training only on raw call events changes the inputs the model sees; it does not save the finished features. Recomputing every aggregate from raw detail at each run is the current waste, not the remedy, because the pipeline still pays the full cost whenever training starts. Archiving the raw detail and deleting the feature tables keeps a cold copy of the source and removes the very table the next run was supposed to read. The stored table becomes an input the next run can read directly, so its definition and row grain have to match what the training job expects. Exam caveat: a persisted feature must be rebuilt when its definition or the underlying calls change, or later runs will quietly reuse a stale column. Operational check: time a second training run and confirm it reads the stored aggregate table rather than scanning raw call detail again.