DAA-C01 Question 202
Single answerSummarize large data sets using Snowsight dashboardsA retail analytics team uses Snowsight dashboards to monitor daily sales across several billion rows in a FACT_SALES table. Business users want an executive dashboard that opens quickly and shows high-level KPIs by day, region, and product category, with the ability to filter interactively in Snowsight. The current dashboard is built directly on detailed transaction-level queries and is too slow during peak usage. Which approach would BEST improve dashboard performance while still meeting the requirement to summarize large data sets for interactive analysis?
- A
Create a pre-aggregated summary table or dynamic table at the day, region, and product-category level, and build the Snowsight dashboard from that summarized dataset.
- B
Keep the dashboard on the detailed FACT_SALES table, but increase the warehouse size for all dashboard users so every filter interaction scans the full transaction history faster.
- C
Export the daily results to an external BI tool because Snowsight dashboards are intended only for small sample datasets rather than large summarized datasets.
- D
Replace the dashboard with a worksheet that queries the raw FACT_SALES table so users can manually run SQL each time they need updated KPIs.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to build the dashboard on a summarized dataset at the grain actually needed for the business questions. In Snowsight, dashboards are created from queries and visualizations, so dashboard performance depends heavily on the efficiency of those underlying queries. When the source is a very large fact table, querying raw transactional data for high-level KPI dashboards is usually unnecessary and expensive. Pre-aggregating data into a summary table or using a dynamic table can significantly reduce the amount of data scanned and improve user experience for interactive filters.
This aligns with Snowflake analytic design best practices: model data according to the access pattern, avoid repeatedly scanning detailed history for summary reporting, and use appropriately curated datasets for dashboards. Warehouse scaling can help with compute-intensive queries, but it should not be the primary fix for a dashboard whose logic can be materially simplified through aggregation. Snowsight dashboards are suitable for enterprise reporting scenarios when built on efficient queries and summarized datasets.
- A. Correct.
Correct. For dashboards that summarize very large datasets, the most effective pattern is to reduce the volume of data queried at runtime by pre-aggregating to the grain required for the dashboard. In this scenario, users only need KPIs by day, region, and product category with interactive filtering. A summary table or dynamic table at that grain allows Snowsight visualizations and dashboard tiles to query far fewer rows, improving responsiveness while still supporting the required filters. This matches common Snowflake performance best practices: transform and aggregate data to fit the analytic use case instead of repeatedly scanning transaction-level detail for executive reporting.
- B. Incorrect.
Incorrect. Increasing warehouse size can reduce query runtime, but it does not address the fundamental inefficiency of repeatedly scanning billions of detailed rows for a dashboard that only needs summarized metrics. This is a common misconception: more compute can help, but it is often a costly workaround rather than the best design. For dashboard workloads, especially with repeated interactive filtering, pre-aggregation is typically more efficient and scalable than relying solely on larger virtual warehouses.
- C. Incorrect.
Incorrect. Snowsight dashboards can be used with large enterprise datasets as long as the underlying queries and models are designed appropriately. The limitation here is not that Snowsight cannot handle large summarized datasets; the problem is that the dashboard is querying transaction-level detail unnecessarily. Moving to an external BI tool does not inherently solve poor data modeling or query design.
- D. Incorrect.
Incorrect. Replacing the dashboard with a worksheet removes the self-service dashboard experience and does not solve the performance issue. Worksheets are useful for ad hoc analysis, but executives needing fast KPI monitoring and interactive filtering are better served by a dashboard backed by a dataset modeled for summary analysis. Querying the raw FACT_SALES table manually would likely be slower and less usable.