DAA-C01 Question 224
Single answerDomain 4.0: Data Presentation and Data Visualization (28%)A retail analytics team uses Snowsight dashboards to present weekly sales performance to regional managers. The dashboard includes a chart built from a worksheet query that joins a large FACT_SALES table to several dimensions. Managers complain that the dashboard takes too long to load, especially when they change the date range filter. The data engineering team has already optimized the underlying warehouse size and clustering, and the business only needs aggregated daily sales by region and product category for visualization. Which approach should the data analyst take to improve dashboard responsiveness while keeping the dashboard easy to maintain?
- A
Create a view that keeps the full join logic and point the chart to the view instead of the worksheet query.
- B
Create a dynamic table or materialized pre-aggregated table at the daily region/category level and build the Snowsight visualization from that object.
- C
Duplicate the dashboard into separate dashboards by region so that each dashboard has fewer rows to render.
- D
Export the result set to a CSV file and ask managers to use spreadsheet charts instead of Snowsight.
Show answer and explanation
Correct answer: B
Explanation
For dashboarding and presentation workloads, a common best practice is to model data at the grain required by the visualization instead of querying large detailed fact tables directly for every interaction. In this scenario, the visualization only needs daily aggregated sales by region and product category, so a pre-aggregated structure is the most appropriate design. In Snowflake, this can be implemented with a dynamic table or another maintained summary table, allowing Snowsight charts and dashboards to query a smaller, simpler dataset. A standard view improves logical abstraction but does not persist precomputed results, so it usually does not provide the same runtime performance benefit for interactive dashboards. This aligns with Snowflake guidance to optimize analytical presentation layers by reducing query complexity and shaping data for consumption in dashboards and BI tools.
- A. Incorrect.
This is less effective for the stated problem. A standard view does not store results; it simply encapsulates the query logic. Each dashboard refresh or filter change still requires Snowflake to execute the underlying joins and aggregations at runtime. While a view may improve maintainability and reuse, it does not materially improve responsiveness when the expensive computation still happens on demand.
- B. Correct.
This is the best answer. Since the business only needs aggregated daily sales by region and product category, pre-aggregating the data into a dynamic table or another maintained summary table reduces the volume and complexity of work required at dashboard runtime. Snowsight visualizations generally perform better when based on simpler, pre-shaped datasets aligned to the dashboard's grain. This approach improves query performance and keeps maintenance manageable because the transformation logic is centralized in Snowflake rather than embedded in many workbook queries.
- C. Incorrect.
This is a plausible but incorrect workaround. Splitting dashboards by region may reduce the amount of data rendered in each view, but it does not address the root cause: repeated execution of an expensive join-and-aggregate query when filters change. It also creates additional maintenance overhead because the analyst must manage multiple dashboards with similar logic.
- D. Incorrect.
This is incorrect because it abandons the Snowflake-native visualization requirement rather than solving the performance issue. CSV exports are static, require manual handling, and remove interactivity, governance, and centralized access control that Snowsight dashboards provide. This is not a best-practice solution for an operational analytics dashboard.