A retail bank must rebuild account features for the full saved history after a definition change. The job can finish overnight and must not sit on the path that scores each new transaction as it arrives. Which processing path fits?
Select an answer to reveal the explanation.
Short Explanation
Rebuilding a long history on the live checkout line is like repaving a highway while the cars are still using it. A batch job scans the saved history off to the side, which is the path you want for this overnight rebuild. The trap is the live event path, which should score each new transaction and stay clear of the full rebuild.
Full Explanation
A large historical rebuild reads stored history once, can finish on a schedule such as overnight, and should stay off the path that scores live transactions. A batch job is that path: it scans the saved account history after the definition change and writes the rebuilt features without sitting in front of each new transaction. The live event path is reserved for scoring arrivals as they happen; placing the full rebuild there would block or delay that scoring. Streaming enrichment on every new transaction repeats work per arrival and contends with the live scorer, which is the wrong shape for a one-time pass over the full history. An analyst's interactive query can explore a sample and does not rebuild the feature history that downstream jobs will read. Exam caveat: batch is the right path for this rebuild, not a claim that every feature in the bank must be batch; a single new transaction can still be scored on the live path with the updated definition. Operational check: confirm the rebuild reads stored history on a schedule, writes a feature table, and is not attached to the transaction-scoring service.