Materializing dimensions and metrics in semantic views¶
To improve the query performance of a semantic view, you can materialize selected dimensions and metrics in the view, similar to how you materialize data in a materialized view.
When you query the semantic view, Snowflake reads from the materialized dimensions and metrics, rather than scanning the base table and computing the information.
Preparing a semantic view to support materialization¶
Before you can materialize the dimensions and metrics in a semantic view, you must
Setting the maximum staleness of the materialized dimensions and metrics¶
The MAX_STALENESS property determines the maximum amount of time that the materialized dimensions and metrics can be stale (out of date) before they are refreshed. For example, if you don’t want the materialized dimensions and metrics to be out of date by more than 1 hour, set the MAX_STALENESS property to ‘1 hour’.
You can set this property when running the CREATE SEMANTIC VIEW command to create a new semantic view:
You can also set this property on an existing semantic view by running ALTER SEMANTIC VIEW … SET MAX_STALENESS:
Note
The minimum allowed MAX_STALENESS is 120 seconds.
The following example creates a semantic view with a maximum staleness of 1 hour:
The MAX_STALENESS property defines the maximum acceptable staleness for materialized data. The system uses this value to determine how frequently materializations are refreshed. Queries are only rewritten to use a materialization when the materialization is not older than the value of the MAX_STALENESS property.
Granting the privileges to materialize the dimensions and metrics¶
To materialize the dimensions and metrics in a semantic view and manage those materializations, you must use a role that has been granted the following privileges:
the OWNERSHIP privilege on the semantic view
the ADD SEMANTIC VIEW MATERIALIZATION privilege on the schema that contains the semantic view
To grant this privilege to a role, run the GRANT <privileges> … TO ROLE command. For more information about granting privileges, see Access control privileges.
Materializing dimensions and metrics¶
To materialize dimensions and metrics in a semantic view, run ALTER SEMANTIC VIEW … ADD MATERIALIZATION:
where:
name: Specifies the name of the semantic view.materialization_name: Specifies the name of the materialization to add.WAREHOUSE = warehouse_name: Specifies the warehouse to use when materializing the dimensions and metrics.IMMUTABLE WHERE ( condition ): Specifies a condition that must be true for the dimensions and metrics to be materialized.You specify this to improve performance by limiting the scope of the refresh.
Important
Snowflake strongly recommends specifying this clause to reduce the cost and time of materialization refreshes. For more information, see Improving performance by incrementally refreshing materializations.
DIMENSIONS dimension_name [ , ... ]: Specifies the dimensions to materialize.METRICS metric_name [ , ... ]: Specifies the metrics that you want to pre-aggregate.
Note
You cannot use the following metric types in materializations:
For example:
You can add multiple materializations to a semantic view. Each materialization specifies a subset of dimensions and metrics to pre-aggregate.
You can also use this command to update the definition of an existing materialization.
Snowflake automatically refreshes the materialization regularly to fulfill the desired MAX_STALENESS. If the refreshes take
too long and the materializations become more stale than the limit, they are not used for rewrites. In those cases, check the
refresh history and consider increasing the MAX_STALENESS on the semantic view:
Improving performance by incrementally refreshing materializations¶
If the semantic view contains non-additive metrics (for example, COUNT(DISTINCT ... )) or complex queries spanning multiple
entities, Snowflake recomputes all of the data that is materialized. This is referred to as a full refresh.
To improve performance, you can limit the scope of the refresh to only the data that has changed since the last refresh. This is referred to as an incremental refresh.
To limit the scope of the refresh, specify the IMMUTABLE WHERE clause with a condition when you add or modify the materialization. Only the rows that match the condition are recomputed during the next refresh.
For example, the following statement adds a materialization that limits the scope of the refresh to only the data that has changed since January 1, 2020:
Refreshing a materialization manually¶
If you want to refresh the materialization of a set of dimensions and metrics, run ALTER SEMANTIC VIEW … REFRESH MATERIALIZATION:
Note
You must use a role that has been granted the privileges to materialize the dimensions and metrics.
For example, the following statement refreshes the revenue_by_customer materialization for the revenue_analysis semantic view:
When you run this command, the manual refresh uses the current warehouse of the session. Background refreshes occur automatically based on the MAX_STALENESS property using the warehouse specified when the materialization was created.
Removing a materialization¶
To remove a materialization from a semantic view, run ALTER SEMANTIC VIEW … DROP MATERIALIZATION:
Note
You must use a role that has been granted the privileges to materialize the dimensions and metrics.
For example, the following statement removes the revenue_by_customer materialization from the revenue_analysis semantic view:
Listing the materializations for a semantic view¶
To list the materializations for a semantic view, run the SHOW MATERIALIZATIONS command:
Note
You must use a role that has been granted the SELECT privilege on the semantic view.
For example, to list the materializations for the revenue_analysis semantic view:
The command returns tabular output in the following columns:
Column |
Description |
|---|---|
|
Name of the materialization. |
|
State of the materialization. The state can be one of the following:
|
|
Reason why the materialization is suspended. |
|
Time when the materialization will be stale. |
|
Warehouse that is used to materialize the dimensions and metrics. |
|
Dimensions that are materialized. |
|
Metrics that are materialized. |
|
Condition that is used to limit the scope of the refresh. |
Viewing the history of refreshes¶
To view the history of refreshes for a materialization, call the SEMANTIC_VIEW_MATERIALIZATION_REFRESH_HISTORY table function in the INFORMATION_SCHEMA schema:
For example, to view the history of refreshes for the revenue_by_customer materialization:
The function returns tabular output in the following columns:
Column |
Description |
|---|---|
|
Name of the materialization. |
|
Name of the schema that contains the semantic view. |
|
Name of the database that contains the semantic view. |
|
State of the most recent refresh. The state can be one of the following:
|
|
Error message from the most recent refresh. |
|
Time when the most recent refresh started. |
|
Time when the most recent refresh completed. |
|
Warehouse that is used to materialize the dimensions and metrics. |
|
Action that was taken for the most recent refresh. |
How materializations are used when processing a query¶
When you query a semantic view, Snowflake uses the materializations to fulfill the query. The planner selects the lowest-cost materialization that covers the requested dimensions and metrics. The next sections explain how materializations are used when Snowflake processes a query.
Reaggregation of additive metrics¶
When a materialization contains more dimensions than the query requests, Snowflake can reaggregate additive metrics. For
example, a materialization on (customer_name, order_year) with SUM(total_revenue) can serve a query requesting only
customer_name by summing across years.
If the metrics use the following functions, Snowflake can reaggregate the metrics:
Note
Metrics with an expression on top of the aggregation (for example, 2 * SUM(x) + COUNT(y)) are not considered additive.
If metrics use the following functions, Snowflake cannot reaggregate the metrics:
Any
DISTINCTaggregationDerived metrics referencing non-additive metrics
How dimensions in a WHERE clause are handled¶
Dimensions used in a WHERE clause count as covered dimensions. For example, a materialization on
(customer_name, order_year) can be used when the following query is processed:
When materializations are not used¶
Snowflake falls back to scanning the base tables in the following situations:
No materialization covers the requested dimensions or metrics.
The materialization exceeds the value of the MAX_STALENESS property.
A masking policy or row access policy exists on the underlying tables.
Non-additive metrics require reaggregation.