For task, data loading, and ETL/ELT warehouses, set the timeout for suspension immediately upon completion.Run the following to identify all the virtual warehouses that will not auto-resume when they are queried: Best Practice #3: Set Timeouts Appropriately for WorkloadsĪll virtual warehouses should have an appropriate timeout for their particular workload: If you are going to implement auto-suspend and set appropriate timeout limits, enabling auto-resume is a must otherwise, users will not be able to query the system. Make sure all virtual warehouses are set to auto-resume. Run the following query to identify all the virtual warehouses that do not have auto-suspend enabled: Best Practice #2: Enable Auto-Resume This way, when they are done processing queries, auto-suspend will turn off your virtual warehouses when they are done processing queries, and thus stop credit consumption. Make sure all virtual warehouses are set to auto-suspend. Given all this, here are 10 best practices Snowflake account administrators should be doing. The following figure shows the status and basic configuration of virtual warehouses in an account: Users, databases, tables, queries, and workloads can be monitored through the ACCOUNT_USAGE schema shared with all Snowflake accounts. For example, they can proactively control compute at the individual virtual warehouse level, at the user level, or at the account and organization level through resource monitors. Snowflake is virtually unlimited by default, and account administrators can put in place minor account-level and resource-level restrictions to defend against rogue users or suboptimal use of resources and credits. Because compute and storage are separated and they are elastic, these resources should be monitored for consumption, surprise growth, and resource efficiency. There are a few optimizations every Snowflake account administrator should make and some more-advanced methods they should consider as their Snowflake compute footprint grows. Storage will grow and shrink over time for databases, tables, and meta-data. This means instead of paying for a fixed, limited amount of storage and compute, the amount of storage and compute grows and shrinks as your needs change over time.īy taking advantage of a core tenet of the cloud, elasticity and compute can be dynamically scaled to workloads throughout the day as concurrency needs or raw compute power fluctuate to meet demand. As a cloud data platform, Snowflake can near instantly scale to meet planned, ad hoc, or surprise growth. The need to do advanced resource planning, agonize over workload schedules, and prevent new workloads on the system due to the fear of disk and CPU limitations just go away with Snowflake. Snowflake has completely separate compute and storage, and both tiers of the platform are near instantly elastic. As we covered in part 1 of this blog series, Snowflake’s platform is architecturally different from almost every traditional database system and cloud data warehouse.
0 kommentar(er)
