A dashboard repeatedly runs the same KQL summarize-and-aggregate query against a large, continuously-growing Eventhouse table of vibration-sensor readings to show a rolling hourly average per vault. Each dashboard refresh re-scans and re-aggregates the full underlying table, which is becoming slow as history accumulates. Which Eventhouse feature is designed to precompute and store this kind of recurring aggregation so refreshes don't have to reprocess raw data from scratch each time?
Select an answer to reveal the explanation.
Short Explanation
Recomputing the same hourly average from scratch every time is like re-adding a long column of receipts from the beginning every time someone asks for the running total, instead of just keeping a running total updated as receipts come in. A materialized view is that running total: it keeps the aggregation current as new events arrive, so a dashboard just reads the already-computed answer. The raw table keeps growing, but the query the dashboard actually runs doesn't have to grow with it.
Full Explanation
A materialized view in an Eventhouse maintains the result of a defined aggregation query incrementally as new data lands in the source table, storing a continuously up-to-date summary rather than requiring every query to reprocess raw events from the beginning of the table's history; pointing the dashboard at the materialized view instead of the raw table means each refresh reads a small, precomputed result instead of re-scanning and re-aggregating a growing volume of raw sensor readings. Expanding the caching policy to cover the entire retention period would keep more raw data in fast storage, but the dashboard's query would still have to scan and re-aggregate all of it on every refresh — caching speeds up access to raw data, it doesn't avoid recomputing the aggregation itself. A deployment pipeline manages promoting Fabric items between workspaces for lifecycle purposes; it has no role in how a query's results are computed or cached at runtime. Dynamic data masking changes what values are visible to certain users; it doesn't reduce how much raw data a query has to process. A caveat: materialized views work best for aggregations that can be maintained incrementally and won't perfectly cover queries that need arbitrary, unanticipated slicing of raw events — those still need to go against the raw table. A concrete check: compare the dashboard refresh duration and the volume of data scanned per query before and after pointing it at the materialized view instead of the raw table.