Agile Cost Management in Snowflake – Part 2, Storage

In Agile Cost Management in Snowflake – Part 1, Compute, we discussed managing compute costs. Managing storage costs is much simpler, but it is still very important, as poorly managed storage will result in unexpected expenses.

As with Compute, Snowflake’s revolutionary architecture requires a different approach and mindset to managing storage. In legacy DW RDBMS, storage is a limited resource. The need to accurately estimate current and future requirements is a key driver in determining cost. Adding storage is expensive and often requires downtime. Reducing physical storage is unheard of. Instead, DBAs typically focus on reclaiming and reusing storage as data becomes obsolete. This often involves complex and burdensome Information Life Cycle processes. Finally, managing and ensuring the reliability of backups, restores and recovery is a major headache.

Snowflake brings unlimited storage to the cloud, enabling an Agile “lean and fit” storage management style, effectively eliminating the DBA burdens discussed above. Instead, the focus is on appropriate, simple settings to control storage costs.

Pricing

Storage charges in Snowflake are simply “pass through” of the cloud vendor’s pricing.

Snowflake charges monthly for data in databases and data in Snowflake file “stages”. Charges are based on the average storage used per day, computed on a daily basis.

Managing Cost in Stages

Cost management in stages is pretty simple: remove files from stages after successful load into the target databases, unless there is a compelling reason to keep them. This can be performed as part of the COPY INTO command or via the REMOVE command after loading.

Time Travel

As we’ll see, appropriate use of Snowflake’s data retention capability, Time Travel, is the key to controlling storage costs. Time Travel features enable:

  • Restoring accidentally or deliberately dropped databases, schemas and tables with simple SQL
  • Cloning tables, schemas and databases from key historical points with simple SQL
  • Backing up data for historical and archiving purposes via cloning from key points in the past with simple SQL
  • Querying data as it existed at previous points in time with simple SQL

Snowflake’s Database Storage

To manage database storage costs, it’s important to first understand the relevant parts of the storage architecture.

Snowflake uses unlimited “blob” storage for database and file stage storage, which cloud vendors tout as having “eleven nines”  (99.999999999) of durability. All storage is stored redundantly in multiple availability zones (AZ).

Snowflake’s “secret sauce” is the use of “micro-partitions”. A micro-partition is a file object in blob storage.

A micro-partition has the following characteristics:

  • Micro-partitions are immutable. Once written, their data is never modified.
  • Micro-partitions are always compressed and encrypted. The maximum (and common) size is 16MB, typically representing 100-150MB of uncompressed data.
  • In addition to statistics on the data, a micro-partition may have a “date modified” timestamp.
  • “Active” micro-partitions have not been modified, i.e. no “date modified” timestamp.
  • “Historical” micro-partitions have been modified, i.e. a “data modified” timestamp is present
  • UPDATE, DELETE, and a MERGE that performs an UPDATE, result in the date modified timestamp being set and a new micro-partition being written. INSERT (and COPY) always create new micro-partitions.
  • Truncating a table effectively sets the data modified timestamp to the time of the operation for all of the micro-partitions in the table.
  • Dropping a table sets the date modified timestamp to the time of the operation and makes the table definition unavailable.

When a date modified timestamp is present, the data retention setting determines how long the data is available.

Data Retention Period

When a date modified timestamp is present, the data retention setting determines the length of time the historical data will remain available. This in turn determines the charge for the data.

Data retention may be set at the account, database, schema or table level via DATA_RETENTION_TIME_IN_DAYS parameter. A value at a higher level, e.g. database, may be overridden by setting the value for an object at a lower level. Time Travel may only be set for permanent tables and Transient tables.  The default is always 1 day. Transient tables may only be set to 1 or 0 days.

These features enable Snowflake’s “Time Travel” capabilities. In addition, there is a “Fail Safe” backup of 7 days, available in all editions. Recovering data from Fail Safe requires Snowflake support intervention. Time Travel and Fail Safe are collectively referred to as Continuous Data Protection (CDP).

Historical micro-partitions are moved into Fail Safe when their data retention setting is exceeded.

“Standard Time Travel” is only available for 1 day. This applies to both Standard and Premier Editions.

“Extended Time Travel” may range from 1 to 90 days retention for the Enterprise, Business Critical and Virtual Private Snowflake editions.  Managing Extended Time Travel is the key to managing storage costs.

Note that Time Travel can be disabled by setting the retention period to 0. This is generally a bad idea.

Time Travel Cost Example

This is an extreme example to demonstrate Time Travel’s effect on storage costs and why data retention management is critical.

  1. Create a permanent (not TRANSIENT or TEMPORARY) table with 90 day data retention
  2. Populate on Day 1 with 10GB
  3. Drop table on Day 1.
  4. Total cost = (90+7) * 10GB * price/GB/day

This will enable you to UNDROP the table for 97 days from the time of dropping it. However, you will be charged for 97 days of storage, even though you might never UNDROP and/or use it!  (We’ll show you how to fix this later.)

Similarly, historical micro-partitions modified due to UPDATE, DELETE and MERGE are moved into Fail Safe when their data retention setting is exceeded.

Changing Data Retention Period

The data retention period may be changed for an object via the SQL command:
 ALTER <object> DATA_RETENTION_TIME_IN_DAYS=

If the retention period is increased, all data that has not been moved into Fail Safe will be affected by the new value. E.g., if the value is increased from 10 days to 20 days, historical data that would have been moved to Fail Safe after 10 days lives for an additional 10 days.

If the retention period is decreased, data that has exceeded the original retention period will be moved to Fail Safe. E.g., decreasing the value from 10 to 1 will result in 9 days of historical data will be moved into Fail Safe.

Fixing the 90 day “Mistake”

Let’s assume that this table and its population was a mistake. Fortunately, we can reduce the cost to a minimum of Fail Safe’s 7 days, depending on when the mistake is discovered.

  1. UNDROP the table
  2. Modify the data retention period to 0 days
  3. Drop the table

The data was previously moved into Fail Safe, so you are still subject to a minimum charge of 7 days plus any time the mistake went undiscovered.

Managing Cost and Time Travel

The key decision to be made is “how long do you need data retention”? Key factors are:

  1. Is point in time query required for modified historical data? Remember, 90 days is the maximum age for historical data (for Enterprise Edition and above).
  2. Is point in time query required for overall data consistency, e.g. multiple ETL/ELT processes must be completed before querying a set of tables?
  3. How far back might you need to go for fast restore of dropped objects? Remember, data is redundantly stored in 3 availability zones with eleven 9s of durability, so backup for media failures is not needed.
  4. How volatile is your data, how frequently are UPDATEs, DELETEs and MERGEs that modify data performed?
  5. Is there a need to create historical clones, for testing, debugging, etc.? Note that micro-partitions referenced by clone(s) live until all retention time in referencing clone(s) is exceeded. See Cloning Tables, Schemas, and Databases.

Higher volatility = increased storage usage by creating new micro-partitions. Carefully consider the tradeoffs; does high volatility mean increased need for point in time queries and possibly recovery from mistakes? Or the opposite?

Staging tables should have minimal data retention. They should be either TEMPORARY or TRANSIENT tables. Temporary tables only exist during a session. Transient tables may have data retention of 1 or 0. Data is never moved into Fail Safe for either type of table.

Cluster Keys

Be careful when using Cluster Keys, as this may result in frequent aging of micro-partitions and unexpected storage costs. Consider a fairly low data retention setting when using cluster key.

Point in Time Cloning

Databases, schemas and tables may be cloned as of a point in time using the AT clause. This is particularly useful for regression testing, debugging and other development and QA.

Table Storage Metrics View

You will find all of the storage metrics for a table in the TABLE_STORAGE_METRICS view in the Snowflake database INFORMATION Schema. In particular:

  • ACTIVE_BYTES –number of bytes in active micro-partitions
  • TIME_TRAVEL_BYLES – number of bytes in historical micro-partitions
  • FAILSAFE_BYTES – number of bytes in Fail Safe
  • RETAINED_FOR_CLONE_BYTES – number of bytes in micro-partitions referenced by clones
  • TABLE_DROPPED – date and time if table was dropped
  • TABLE_ENTERED_FAILSAFE – date and time the table entered Fail Safe. Requires Snowflake support to restore

The retention period in days for a table is found is found in the RETENTION_TIME column in the TABLES view. Note that the BYTEs column in this view does not reflect true storage cost; it represents uncompressed byte count for a scan of active micro-partitions.

Summary

Snowflake provides unparalleled capabilities to control your cloud data warehouse spend in an agile manner. It further provides unrivalled Continuous Data Protection against failures of all types. Investing in a new approach to storage management offers an opportunity to significantly improve your ROI on Snowflake.

Thanks to Amy Kaulius for her technical review, and LBJ,my editor/wife.

Copyright © 2019, Jeffrey M. Jacobs, permission to redistribute with copyright notice

Agile Cost Management in Snowflake – Part 1, Compute

Snowflake’s revolutionary architecture brings new opportunities and approaches to managing the cost of running its cloud data warehouse. To paraphrase Voltaire and Peter Parker’s uncle Ben Parker, “with great innovation comes great power; with great power comes new responsibilities”. The overall workload architecture is key to managing spend, which in turn requires new modes of thinking and new administration responsibilities.

Historically, workload management was focused on improving performance and throughput; it was seldom directly involved in cost control.

In “legacy” RDBMS, both in cloud and on-premise, workload management is focused on allocating scarce resources among users running different types of queries. Workload management may take different forms. Users may be limited in the amount of CPU and I/O they can use and/or receive priorities on queues and other resources. Elasticity and expansion options are typically limited, and in many cases require downtime. Shared nothing architectures are particularly difficult to upsize and downsize.

With legacy RDMBS, throughput and performance are the main drivers, not cost management. This leads to “bigger is always better” thinking. Elasticity on these platforms is tactical, not strategic, often involving delays or downtime. Over provisioning for anticipated peak load is all too common.

Snowflake provides unlimited compute and storage resources; money is the scarce resource on which to focus workload management.

Managing Snowflake Spend

There are two aspects to managing your Snowflake spend; compute and storage. This article concentrates on the compute aspects, which are both more variable and tunable. We’ll address storage in Part 2.

Minimizing spend is a matter of proactive management and continual improvement, i.e. “refactoring” the workload distribution. Snowflake provides unique capabilities for refactoring the workload distribution.

Let’s take a brief look at what constitutes workload management (and keep it fairly simple).

“Performance” is defined as how long it takes for a query to execute, i.e. when does the user receive results.

“Throughput” is defined as how many queries can be run in X amount of time. This is determines how many concurrent users the system supports.

The fundamental architectures for database engines are Massively Parallel Processor (MPP) and Symmetric Multi-Processor (SMP).  For our purposes and to keep things simple, we’ll consider an MPP processor as a compute engine, either physical server(s) or virtual machine(s), with local storage used during query execution. In a shared nothing architecture, the persisted database storage (PDS) is also typically distributed across the processors (e.g., Redshift and Teradata).

In MPP, the processing of each query is distributed among all of the processors. This provides the necessary power for processing large amounts of data quickly. More processors = better performance = higher throughput. However, the law of diminishing returns also comes into play. Why use, and pay for, 128 processors when a much smaller number will meet the desired service levels?

Snowflake’s unique architecture provides complete and total separation of the processor and PDS.

Snowflake’s primary billing format is “pay for what you use”, not pay for what you provision. Usage is measured in “credits”. The dollar amount for a credit varies depending on which cloud service is used. For compute:  

credits_used/cluster=  t-shirt_size_of_cluster * running_seconds. (See below for more on t-shirt sizing).

Compute is performed by a “warehouse”, a somewhat confusing terminology choice by Snowflake. The traditional use of the term “(data) warehouse” refers to both the database storage as well as the compute server.

 We will use the term “Virtual Warehouse” (VW), as compute and database storage are completely independent. A VW can potentially use data from any and/or multiple databases.

Managing VWs

All of the settings for a VW in this section may either be:

  • Set at VW creation
  • Changed via the SQL Alter Warehouse statement
  • Set or changed in the Snowflake Web UI

Charges for a VW apply only when it is running, not when it is suspended (not running). VW options include:

  • Auto-resume – a suspended VW is resumed when a query is submitted.  The minimum charge for resuming a suspended VW is 60 seconds.  The alternative is explicitly resuming the VW via the SQL Alter Warehouse statement.
  • Auto-suspend – a VW may be suspended when no queries are run for the specified time. The alternative is explicitly suspending the VW via the SQL Alter Warehouse statement.

A VW consists of between 1 and 10 “clusters”. VWs with > 1 cluster are referred to as “multi-cluster VWs”. More on this later. Each cluster consists of 1 or more “servers”.  A server is a virtual machine with multiple vCPUs and local storage for processing and caching, e.g. an EC2 instance in Amazon. Snowflake engineering is continually evaluating the cloud vendors’ offerings for the best performance and to maintain performance parity across cloud services.

A query runs in only 1 cluster. Multiple clusters provide greater throughput, i.e. load balancing.

Servers come in “t-shirt” sizes

  • Extra Small – 1 server
  • Small – 2 servers
  • Medium – 4 servers
  • Large – 8 servers
  • Extra Large – 16 servers
  • 2X Large – 32 servers
  • 3X Large – 64 servers
  • 4x Large – 128 servers

Multi-cluster VWs come in 2 flavors, auto-scale and maximized.

Auto-scale balances the number of running clusters based on query load, i.e. the number of queries that need to be run simultaneously.  As the load demand increases, additional clusters are started. As the load decreases, clusters are suspended. The 60 second minimum charge applies only to VW startup, not cluster startup. Auto-scale has two additional settings, economy and standard, controlling the aggressiveness of resuming and suspending clusters.

Maximized mode starts with and runs with the number of clusters specified.  Remember the 60 second minimum; in this mode, on resume of the multi-cluster VW , you are charged a minimum of 60 seconds for all clusters!!!

The size of clusters in VWs can be resized up or down on the fly, which does not affect running queries! Only newly submitted queries use the reconfigured size. But there’s one more feature to manage cost; the complete separation of VW and physical database storage allows multiple VW to run against the same data without incurring additional storage costs.

Let’s Get Agile

Where does “agile” come in? As an adjective, it’s defined as “able to move quickly and easily”. All of the options and configurations we’ve discussed are very simple to manage. A key feature of agile development is refactoring, which is the approach to be used for managing our WA and spend. Refactoring may involve either changing the settings for an existing VW, creating new VWs to replace and/or offload work from an existing VW.

Understanding Workload

Snowflake’s Information Schema provides easy to use “table functions” for understanding workload and account usage.  Since we’ve already shown how to Reduce Your DBAs’ Burden with Snowflake, we’ll assign the primary responsibility for workload management to the DBAs.

 The following  are key to understanding workloads:

Typically you would create views or package queries to use these functions as discussed in the documentation.  Note that there are a number of prepackaged dashboards and visualizations available, e.g. from Tableau, Looker and Power BI.

WAREHOUSE_METERING_HISTORY provides a good starting place for identifying VWs to be refactored. In addition, Resource Monitors can be useful for proactively monitoring and controlling credit usage.

QUERY_HISTORY, QUERY_HISTORY_BY_* provides the ability to analyze and identify different workload patterns. Ideally, we want to create one or more history tables covering periods longer than 7 days.

For the purpose of this article, we’ll assume that we are managing workloads for each database separately, as these each address separate business functions.

Which columns identify VW characteristics to be refactored?

  • WAREHOUSE NAME
  • WAREHOUSE SIZE
  • WAREHOUSE TYPE

How do we determine when a VW should be running/resumed/suspended based on date and time?

  • START TIME
  • END TIME

How do we determine sizing?

  • TOTAL ELAPSED TIME
  • TOTAL BYTES SCANNED
  • TOTAL ROWS PRODUCED
  • EXECUTION TIME

With all of this information, we can now clear identify workload patterns such as:

  • What types of queries run during business hours, but almost never on weekend or between 8PM and 7AM?
  • What are the appropriate VW settings for a workload?
  • Are there concurrency spikes in the workload?
  • What is the range of query types? Is the size of the queries consistent or widely ranging?
  • Are there peak loads on certain days of the month, quarter, and year?
  • How often and how complex are ad hoc queries?
  • Which user(s) perform which categories of queries?
  • Estimating credit usage and setting up Resource Monitors?

A Few Guidelines and Tips

  • Workloads will change over time. Not only will existing usage patterns change, new usage patterns will emerge for both existing data and new data.
  • VWs for loading should be separate from VWs used for queries. Be aware of the guidelines for loading data effectively. Larger VWs will not improve performance for loading large files.
  • Understand the cost difference in t-shirt sizes. Adjust auto-resume and auto-suspend appropriately.
  • Set auto-scaling for workloads with varying loads.
  • Consider setting STATEMENT_TIMEOUT_IN_SECONDS, particularly for very large VWs used for ad hoc queries. This will cancel queries that run longer than the time specified.
  • Evaluate the execution plan of queries with long running times, heavy byte scanning, etc. to determine if they should be running in larger VWs. In particular, disk spilling is a key indicator of needing larger t-shirt sizing.

Note on Cluster Keys

Although not strictly part of workload management, the use of cluster keys affects both compute and storage costs as part of its background processing. It should be used with care; see the documentation for discussion on credit usage.

Summary

Snowflake provides unparalleled agile capabilities to control your cloud data warehouse spend. Investing in a new approach to workload management offers an opportunity to significantly manage your ROI on Snowflake.

Copyright ©, 2019, Jeffrey M Jacobs