A housing open-data team wants ad-hoc, SQL-like queries over tables stored on HDFS without hand-writing low-level MapReduce Java for every ask. Which layer best matches that need?
Select an answer to reveal the explanation.
Short Explanation
Analysts asking "how many permits by ZIP?" want SQL, not a weekend of Java MapReduce. Hive puts a SQL-like face on HDFS tables. Kafka meters, cart locks, and CAP slides don't answer that ad-hoc ask.
Full Explanation
A housing open-data team that wants ad-hoc, SQL-like queries over tables stored on HDFS without hand-writing low-level MapReduce Java for every ask should use Hive as a SQL-like query layer over Hadoop-resident data. A single Kafka consumer group dedicated to parking meter heartbeats is an ingest/streaming construct, not a SQL query layer over HDFS tables. An OLTP checkout database tuned only for shopping-cart locks is the wrong latency and workload model for analytical open-data summaries. A CAP-theorem whiteboard with no executable query engine does not answer ad-hoc SQL needs. Exam caveat: Hive sits above Hadoop storage to provide SQL-like access without raw MapReduce coding for every question. Operational check: catalog housing tables in Hive, grant analysts SELECT on approved schemas, and confirm a sample group-by runs without custom MapReduce Java. 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.