Snowflake性能调优的五项优秀实践-性能调优的五步法

【51CTO.com快译】设想一下：在没有任何索引的情况下，以及数据库本身并无调整选项的情况下，您会如何优化Snowflake数据仓库呢?众所周知，Snowflake的设计非常简单，几乎没有提供有关性能调整的选项。本文为您总结了提高查询性能的五项优秀实践。

单独地查询工作负载?

最大化吞吐量、以及最小化Snowflake延迟的首选方法莫过于：对于工作负载的查询进行分离。下图说明了一种常见的Snowflake部署设计模式--分离工作负载(separation of workloads，请参见https://www.analytics.today/blog/what-is-the-ideal-cloud-datawarehouse-platform)。

与其他数据库系统不同，Snowflake是针对云端构建的。它能够有效地支持无限量的虚拟仓库，即一些独立大小的计算群集。它们可以对于公共数据的存储进行共享式访问。这种EPP(Elastic Parallel Processing，弹性并行处理，请参见https://www.analytics.today/blog/four-stages-that-revolutionised-database-architecture)的架构，可以运行复杂的数据科学类操作。在针对相同数据进行ELT加载、以及商业智能查询时，该架构不会去争用任何的资源。

在一般情况下，我们往往需要按照部门或团队，来分离不同的工作负载。例如：通过为每个团队提供属于其自己的虚拟仓库，来协助跟踪团队的使用情况。而实际上，最合适的做法应该是：按工作负载的类型，而不是用户组来分离工作负载。这就意味着：在一个仓库中，营销用户在进行商业智能类查询的同时，我们可以运行另一个单独的虚拟仓库，以支持超快的财务仪表板式查询。

曾经在一个案子中，我们有位客户计划运行十五个超小型的仓库，以为每个团队提供各自专用的计算资源。然而，在分析了使用状况之后，我们将其改成了四个更大的虚拟仓库。此法不但可以让运行的成本更低，而且能够在大幅提高性能的前提下，改善用户的体验。

最大化Snowflake缓存的使用

下图展示了Snowflake是如何自动地将数据缓存到虚拟仓库(本地的磁盘缓存)和结果缓存(Result Cache)中的。

虽然上述是一种自动化行为，但您完全可以通过如下的两种优秀实践，来最大限度地提高缓存的使用率，并加快查询的性能。

首先，在分割查询工作的负载时，您应该能够让用户在同一个虚拟仓库中查询到相同的数据。如此，那些由某个用户检索到缓存里的数据，也将极有可能被其他人所使用到。

此外，您还应该避免在不使用虚拟仓库时，草草地暂停虚拟仓库。默认情况下，任何仓库将在10分钟后自动被挂起，并在有SQL语句需要被执行时才自动恢复。当然，您虽然可以将自动挂起设置为几秒钟，以节省资源。但是应该注意的是：在恢复之后，虚拟仓库的缓存可能会被清空，这就意味着您将失去原先的缓存性能优势。

最后，请注意：由于结果缓存是完全独立于虚拟仓库的，因此，任何用户用其帐号执行的任何查询，都将会从结果缓存中产生完全相同的SQL文本。

纵向扩展(Scale Up)，以适应大型工作负载

虽然这并非严格意义上的数据库调优，但是利用Snowflake的虚拟仓库功能，来扩展大型工作负载是非常重要的。

上述的SQL代码片段说明了如何调整仓库的大小。本例是一个能够处理巨大工作负载的32个节点集群。在测试中，由于Snowflake维护着一个可用的资源池，因此，它需要花费几毫秒的时间来实现部署，而在特别繁忙的时段，则可能需要几分钟的时间。

在处理完成之后，我们可以简单地让群集在300秒(即，五分钟)之后自动挂起，或者直接在完成任务后立即暂停群集。如果需要，它可以在另一个查询需要被执行时，自动恢复。可见，整个过程对于最终用户的应用程序来说都是透明的。

下面的截图显示的是仓库容量不佳时的指标，它包括了溢出到本地存储(虚拟仓库SSD)和远程存储的数据量。

在虚拟仓库中，由于本地存储始终采用的是快速SSD，因此任何无法在内存中完成的大型排序操作，都将不可避免地溢出到本地存储之中。那么，如果您看到有大量的数据溢出到了外部存储之中，则表明SSD存储已经被用完，而且那些数据正在被写入慢得多的S3或Blob存储之中。可见，根据这两个指标，我们应该考虑调整到一个更大的、拥有更多内存和本地SSD存储的虚拟仓库之中。

横向扩展(Scale Out)并发

与上述纵向扩展不同，横向扩展技术被用于部署一些相同大小节点的集群，以达到目标并发量，即：增加用户的数量，而不是任务的大小或复杂性。

上面的SQL片段显示了在部署针对多个集群的横向扩展体系结构时，所需要的语句。此法并非部署某个大型的主机群集，而是让Snowflake按需添加其他相同大小的群集，直至达到既定的上限。

我们在下图中所展示的是：将商业智能虚拟仓库配置成在其他用户执行查询的时候，能够自动将群集添加到现有的配置环境之中。

显然，这与ELT的仓库有着明显的差异，后者被定义为一个更大的单一化集群，用来处理复杂任务中的各种海量数据。

这种调整方法在英国食品配送服务商Deliveroo那里得到成功应用。2017年，根据最终用户需要在近20TB的数据中，每小时开展7,000多次查询的需求，他们使用到了Snowflake的自动化横向扩展资源的方式。

由于并发用户的数量在一天中的不同时段持续发生变化，因此该群集会自动暂停，以实现Deliveroo只为实际使用到的计算资源付费。下图展示了其他群集会根据用户的使用量，被自动添加进来，以及在不需要的时侯，自动暂停的情况。

使用数据聚合来调整Snowflake

由于使用聚合密钥(cluster key)可以最大限度地消除分区，进而提高查询的性能，因此对于某些大型数据表(通常超过1 TB)而言，设计人员应考虑通过定义聚合密钥，来最大化查询的性能。

为了说明使用聚合调整给Snowflake带来的性能优势，我们针对TPC(Transaction Processing Council)表的STORE_SALES设置了一项基准测试，该表容量有1.3Tb，其中保存了近300亿行销售数据。接着，我们针对该表的聚合版本和非聚合版本，运行了相同的查询，下图是两项结果的对比。