Each month the city mashes multi-agency open-data dumps for a retrospective equity report. Where should that heavy batch mashup run?
Select an answer to reveal the explanation.
Short Explanation
Month-end mashups are warehouse work, not cashier-window work. A Hadoop batch cluster is built for hauling big historical open-data piles; the live tax OLTP box is not. Keep the mashup off the payment servers.
Full Explanation
Heavy monthly multi-agency open-data mashups for equity retrospectives should run on a Hadoop batch analytics cluster sized for large historical joins—not on systems that serve live citizen transactions during peak hours. Running that mashup on the live property-tax OLTP server during peak payment hours risks clerk and resident outages and payment failures. Limiting the work to a single analyst laptop spreadsheet without a cluster fails scale, repeatability, and auditability for citywide multi-agency dumps. Issuing ad-hoc UPDATEs against the 911 CAD transactional database conflates analytics with emergency transactional integrity. Exam caveat: batch analytics placement must protect OLTP and public-safety systems of record from heavy scans. Operational check: schedule the equity mashup on the analytics cluster after extracts land, measure runtime against the publication calendar, and forbid direct heavy scans on tax or CAD production databases. In municipal platform operations, record the rationale in the architecture decision record so future on-call staff know which pattern was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that monitoring, access paths, and recovery steps still match the documented design for agencies that depend on this platform.