A museum network's Lakehouse holds a decade of visitor-flow and ticketing history across dozens of branches. Analysts almost always filter their reports to a single month or a single quarter, yet every query currently scans the full ten years of files before applying that filter. Which change to the table's physical layout would most directly reduce the amount of data scanned for these queries?
Select an answer to reveal the explanation.
Short Explanation
Think of the ten years of data like a decade of filing-cabinet drawers labeled by year and month — if you need March's records, you only open March's drawer instead of digging through every drawer ever filled. That's what date partitioning does for a Lakehouse table: it lays files out by time period so a month or quarter filter can skip everything else on disk. The query still asks the same question; it just has far less to read to answer it.
Full Explanation
Partitioning a table by a column analysts consistently filter on — here, date — physically separates the data into folders by that value, so the query engine can perform partition pruning: it identifies which folders match the filter and skips reading every other folder entirely, cutting scan volume from ten years to a handful of months. This works because the analysts' access pattern is described as consistently time-bounded, which is exactly what partition pruning is built to exploit. A computed, rounded price column changes what's stored per row but does nothing to reduce which files get scanned; it's unrelated to the described bottleneck. Dynamic data masking changes what values are displayed to certain users; it's a security control layered on top of a read, not a way to avoid reading unnecessary files in the first place. Moving the table to a different workspace changes organizational placement and access boundaries, not the physical file layout that determines how much data a scan touches. A caveat worth flagging: partitioning by too fine a grain (say, by exact day for a lightly-updated table) can recreate the small-file problem, so the partition key should match real query and write cardinality. A concrete check: review the query plan or execution statistics for a month-filtered query before and after partitioning to confirm the number of files or partitions read has dropped.