A library consortium compares nightly batch SQL reports on catalog tables with a new workload that analyzes clickstreams and sensor feeds together. How do those workloads differ in Big Data terms?
Select an answer to reveal the explanation.
Short Explanation
Picture two kitchens: one cooks from a neat recipe card every night, the other juggles live streams from a dozen messy counters. Catalog SQL is the recipe-card job; clickstreams plus sensors are the multi-source mash-up that stretches ordinary tools. Structured data can still appear in Big Data—it just is not the whole story anymore.
Full Explanation
Nightly batch SQL on structured catalog tables is conventional reporting: a known schema, bounded latency, and tools that already fit. Jointly analyzing high-scale clickstreams and sensor feeds is a multi-source Big Data workload because volume, velocity, and variety together stress conventional single-system reporting. A library consortium comparing those kitchens correctly separates ordinary catalog reports from live, heterogeneous civic usage and facilities data.
Calling both workloads identical because any SQL is already Big Data fails by concept: conventional SQL reporting can remain ordinary when tools still succeed. Claiming clickstreams and sensors are conventional while nightly SQL is Big Data reverses the difficulty signal and fails by concept. Asserting that Big Data forbids structured tables fails by concept: structured data often participates in Big Data mashups; the issue is scale and complexity, not a ban on tables.
Exam caveat: Distinguish conventional workloads that existing tools handle from multi-source, high-scale workloads that push beyond them—without equating "uses SQL" with Big Data or banning structured data.
Operational check: Inventory which library reports still finish reliably on the catalog RDBMS, then separately size ingest, storage, and join costs for clickstream-plus-sensor pilots before labeling them Big Data.