Snowflake Materialized Views: An Overview
By: Rajiv Gupta
Tags: Performance, Materializedviews, Oracle, Snowflake, Snow

As the name suggest, materialized view are not like view but behave more like a table which gets refreshed in a scheduled manner. In snowflake materialized view are zero maintenance. By term “zero maintenance” means it is automatically maintained by Snowflake, but it has cost attached to it. In view, we have only SQL query stored in database and when someone executes view the underline SQL gets executed, whereas in materialized view if there is any change in underline tables which is part of Materialized view query, data are synced using Snowflake provided compute. Materialized views can speed up expensive aggregation, projection, and selection operations, especially those that run frequently and that run on large data sets. Materialized view are created with the purpose to enhance the performance of complex query which takes lots of time.

Snowflake does not allow standard DML operation (e.g. INSERT, UPDATE, DELETE) on materialized views. Snowflake does not allow users to truncate materialized views.

Materialized View can be of two flavor:

1> Secure Materialized view.

2> Unsecure Materialized view(Default).

When deciding whether to use a secure view, you should consider the purpose of the view and weigh the trade-off between data privacy/security and query performance. Making view secure adds a penalty on performance.

How to find whether the view is secure or not?

The command to find out whether a view is secure.

For non-materialized views, check the IS_SECURE column in the output of the SHOW VIEWS command.

column in the output of the command. For materialized views, check the IS_SECURE column in the output of the SHOW MATERIALIZED VIEWS command.

SHOW MATERIALIZED VIEWS LIKE ‘<MV_NAME>’

When to choose Materialized View?

Materialized view is useful in below scenario:

1> The underline base table of MV is not changed frequently.

2> Query is based on External table which is slow and creating MV can improve performance.

3> Query which require significant processing like aggregation, analyzing semi-structure data which takes lots of time and creating MV to make them fast by pre-calculating things.

4> Query based on very big table, but you frequently query only few rows or columns based on certain logic.

Materialized View Vs Regular View. When to choose what?

Create a materialized view when all the following are true:

The query results from the view don’t change often. This almost always means that the underlying/base table for the view doesn’t often change, or at least that the subset of base table rows used in the materialized view don’t change often.

The results of the view are used often (typically significantly more often than the query results change).

The query consumes a lot of resources. Typically, this means that the query consumes a lot of processing time or credits, but it could also mean that the query consumes a lot of storage space for intermediate results.

Create a regular view when any of the following are true:

The results of the view change often.

The results are not used often (relative to the rate at which the results change).

The query is not resource intensive, so it is not costly to re-run it.

All compute cost are tagged against Snowflake-provided virtual warehouse named MATERIALIZED_VIEW_MAINTENANCE. You can also query snowflake data dictionary to get more details understanding of cost.

MATERIALIZED_VIEW_REFRESH_HISTORY table function (in the Information Schema). Return results only for the ACCOUNTADMIN role or any role that has been explicitly granted the MONITOR USAGE global privilege. The history is displayed in increments of 1 hour.

Select * from table(information_schema.materialized_view_refresh_history());

MATERIALIZED_VIEW_REFRESH_HISTORY View (in Account Usages). Latency for the view may be up to 180 minutes (3 hours).

Select * from SNOWFLAKE.ACCOUNT_USAGE.MATERIALIZED_VIEW_REFRESH_HISTORY

Demo on Materialized View

Although Materialized view seems very promising by its features for all performance requirement but still materialized view has certain limitation which needs to be considered before arriving at any conclusion.

The following limitations apply to creating materialized views:

A materialized view can query only a single table.

Joins, including self-joins, are not supported.

You cannot directly clone a materialized view by using the CREATE VIEW … CLONE… command. However, if you clone a schema or a database that contains a materialized view, the materialized view will be cloned and included in the new schema or database.

Time Travel is not currently supported on materialized views.

Materialized Views are not monitored by Snowflake Resource Monitors.

A materialized view cannot query:

1>A materialized view.

2>A non-materialized view.

3> A UDTF (user-defined table function).

A materialized view cannot include:

1>UDFs (this limitation applies to all types of user-defined functions, including external functions).

2> Window functions.

3> HAVING clauses.

4> ORDER BY clause.

5> LIMIT clause.

6> GROUP BY keys that are not within the SELECT list. All GROUP BY keys in a materialized view must be part of the SELECT list.

7> GROUP BY GROUPING SETS.

8> GROUP BY ROLL UP.

9> GROUP BY CUBE.

10> Nesting of sub-queries within a materialized view.

Maintenance of Materialized View is done by background process handled by Snowflake which is not transparent to any user. It might happen that the base table has changed recently and Materialized View is not synced after that. In such scenario Snowflake will always return you up-to date data by skipping reading those micro-partition which are outdated and read directly from the base table. It may result in slowness, but the result will never be outdated. To see the last time that a materialized view was refreshed, check the REFRESHED_ON and BEHIND_BY columns in the output of the command SHOW MATERIALIZED VIEWS.

The following command and view provide information about materialized views:

The SHOW VIEWS command returns information about both materialized and regular views.

INFORMATION_SCHEMA.TABLES shows materialized views. The TABLE_TYPE column shows “MATERIALIZED VIEW”. The IS_INSERTABLE column is always “NO”, because you cannot insert directly into a materialized view.

Troubleshooting Materialized View

You can look into Snowflake documentation for troubleshooting related details here.

Things to remember:

Materialized views impact your costs for both storage and compute resources. Materialized views uses storage to store your computed results and also uses compute to keep your materialized views up to date.

If you clone a schema or a database and if that contain a materialized view, then the materialized view is cloned.

If you clone the materialized view and the corresponding base table at the same time (as part of the same CREATE SCHEMA … CLONE or CREATE DATABASE … CLONE operation), then the cloned materialized view refers to the cloned base table.

If you clone the materialized view without cloning the base table (e.g. if the table is in Database1. Schema1 and the view is in Database1.Schema2, and you clone only Schema2 rather than all of Database1), then the cloned view will refer to the original base table.

If you cluster both the materialized view(s) and the base table on which the materialized view(s) are defined, you can cluster the materialized view(s) on different columns from the columns used to cluster the base table.

If columns are added to the base table, those new columns are not automatically propagated to the materialized views. This is true even if the materialized view was defined with “Select * ”.

If a base table is altered so that existing columns are changed or dropped, then all materialized views on that base table are suspended; the materialized views cannot be used or maintained(This is true even if the modified or dropped column was not part of the materialized view.).

If a base table is dropped, the materialized view is suspended (but not automatically dropped)

Hope this blog help you to get insight on Overview of Snowflake Materialized View. Feel free to ask a question in the comment section if you have any doubts regarding this. Give a clap if you like the blog. Stay connected to see many more such cool stuff. Thanks for your support.

You Can Find me:

Follow me on Medium: https://rajivgupta780184.medium.com/

Follow me on Twitter: https://twitter.com/RAJIVGUPTA780

Connect with me in LinkedIn: https://www.linkedin.com/in/rajiv-gupta-618b0228/

Subscribe to my YouTube Channel: https://www.youtube.com/channel/UC8Fwkdf2d6-hnNvcrzovktg

#Keep learning #Keep Sharing #Everyday Learning.

References:-