DAA-C01 Question 201
Single answerSummarize large data sets using Snowsight dashboardsA retail analytics team uses Snowsight dashboards to monitor daily sales across hundreds of millions of transaction rows. Business users complain that a dashboard tile showing sales by region and product category is slow to load and is difficult to interpret because it returns too many detailed rows. The analyst wants to redesign the tile so executives can quickly review trends while minimizing the amount of data processed for the visualization. Which approach should the analyst take?
- A
Create a query for the dashboard tile that aggregates sales with GROUP BY region, product category, and day, returning only summarized measures needed for the chart.
- B
Replace the chart with a table visualization that shows every transaction row so Snowsight can summarize the data interactively in the dashboard.
- C
Use SELECT * in the tile query and rely on Snowsight filters to reduce the data after the full result set is returned.
- D
Export the transaction data to a CSV file, re-import a smaller sample into Snowflake, and build the dashboard from the sample instead.
Show answer and explanation
Correct answer: A
Explanation
When building Snowsight dashboards for large data volumes, analysts should design SQL queries that return summarized, business-ready data instead of raw detail. Aggregating measures with GROUP BY and selecting only the required columns improves query efficiency and creates visualizations that are easier to understand. This is especially important for executive dashboards, where the goal is rapid interpretation of trends rather than row-level exploration. Snowflake and Snowsight best practices favor pushing summarization into SQL so the dashboard tile works with a smaller, more meaningful result set. This reduces unnecessary processing and rendering overhead while preserving accuracy and freshness from the underlying Snowflake data.
- A. Correct.
Correct. For large data sets, the best practice is to summarize data in the SQL query before it reaches the visualization. Using GROUP BY with only the dimensions and measures needed for the dashboard reduces the result set size, improves performance, and makes the chart easier for executives to interpret. This aligns with how Snowsight dashboards are typically built: tiles are backed by SQL queries, and well-designed queries should return aggregated results appropriate for the business question.
- B. Incorrect.
Incorrect. Returning every transaction row increases the amount of data that must be scanned, transferred to the result set, and rendered in the dashboard. A table of raw rows is usually less useful for executive summary reporting and does not address the performance concern. The misconception is assuming the visualization layer should perform the summarization rather than the SQL query.
- C. Incorrect.
Incorrect. SELECT * is a poor choice for dashboard queries against large data sets because it retrieves unnecessary columns and detailed records. Applying filters after returning a large result set does not optimize the initial query appropriately for a summary dashboard. The misunderstanding here is confusing interactive filtering with efficient query design.
- D. Incorrect.
Incorrect. Sampling and rebuilding the dashboard from imported CSV data creates data freshness and governance problems and is not an appropriate solution when Snowflake can query and aggregate the source data directly. Executives typically need accurate, current summaries, not a static sample. This distractor reflects an unnecessary workaround rather than a Snowflake analytics best practice.