A mayor's innovation office lists predictive maintenance, citizen sentiment analysis, and dynamic routing as candidate pilots. What Big Data rationale best justifies treating them as application classes?
Select an answer to reveal the explanation.
Short Explanation
Predictive maintenance, sentiment, and routing all chew through messy, multi-source evidence that a lonely weekly PDF cannot. That is why they sit in the Big Data applications family—insight from complex feeds, not "delete history" theater. Keep the relational systems that still fit; add Big Data patterns where the workload outgrows them.
Full Explanation
Typical Big Data application classes—predictive maintenance, sentiment analysis, and dynamic routing—fit because they extract operational insight from large, complex, or multi-source data beyond conventional single-system reporting. A mayor's innovation office should justify pilots by that workload fit: civic assets, citizen voice, and mobility all benefit when multi-source analytics inform operations, not when tools are banned for theater.
Requiring deletion of all historical data before models run fails by concept: history is often essential training and baseline evidence. Mandating abandonment of every relational database fails by concept: RDBMS can coexist; Big Data is not an absolutist tool ban. Equating these classes with printing weekly PDFs from one static table fails by concept: static single-table PDFs are conventional reporting, not those application classes.
Exam caveat: Justify application classes by multi-source complexity and insight needs—not by deleting history, abolishing all RDBMS, or renaming weekly PDFs as Big Data innovation.
Operational check: For each pilot, name the sources, the decision improved, and why conventional single-system reports fail; reject charters that only demand tool bans without civic outcomes.