Emergency operations depend on HDFS-backed analytics and serving clusters during disasters. What should architects align when designing resilience?
Select an answer to reveal the explanation.
Short Explanation
If EOCs lean on the analytics stack in a crisis, recovery goals have to match that reality. Pretty dashboards will not restore lost NameNode metadata.
Full Explanation
When emergency operations depend on HDFS-backed analytics and serving clusters during disasters, architects must align recovery objectives for storage and serving with EOC needs—explicit RPO and RTO, NameNode or metadata protection, replica strategy, and serving failover—rather than cosmetic portal themes. Resilience design is a civic duty when dashboards and models inform response under stress. Cosmetic theme colors on the BI portal home page do not restore lost metadata or serving capacity when a site or rack fails. A policy that backups are unnecessary if replication is set to one copy both under-replicates and misunderstands that replication is not a complete backup and restore program. Deferring all resilience planning until after the next hurricane season ends leaves the city exposed during the very events that need the analytics platform most. Exam caveat: replication is not a full backup strategy; disaster design must cover metadata, serving tiers, and recovery drills, not only DataNode block copies. Operational check: write analytics RPO/RTO into the EOC annex, verify NameNode metadata backups and replica factors, rehearse restore to a secondary site, and confirm dashboards recover within the stated objective before storm season.