第二章：创建和管理Snowflake架构

十年前，数据平台架构缺乏可扩展性，无法轻松地让数据驱动的团队同时共享数据，无论团队的规模大小或者他们与数据的接近程度如何。对于可扩展性的需求不断增长，并且对于对数据进行受管控访问以生成可行动洞察的需求也日益增加。为了满足这些需求，对现有数据平台架构进行了修改。然而，鉴于平台的数量和复杂性，以及应用程序对数据的密集需求，这并没有解决问题，直到Snowflake以其独特的架构闪亮登场。

Snowflake是一种创新的现代数据平台，解决了可扩展性问题。与传统的云数据平台架构相比，Snowflake能够实现数据存储和处理的速度更快、更易于使用且更经济实惠。Snowflake的Data Cloud通过将新的SQL查询引擎与创新的架构结合起来，为用户提供了独特的体验，该架构是专门为云环境从零开始设计和构建的。

准备工作

创建一个名为"Chapter2 Creating and Managing Snowflake Architecture"的新工作表。如果需要创建新工作表的帮助，请参考"导航Snowsight工作表"。为了设置工作表上下文，请确保你正在使用SYSADMIN角色和COMPUTE_WH虚拟仓库。

传统数据平台架构

在本节中，我们将简要回顾一些传统的数据平台架构以及它们是如何设计的，以改善可扩展性。可扩展性是系统处理不断增加的工作量的能力。我们还将讨论这些架构的限制，并了解到Snowflake Data Cloud架构的独特之处。之后，我们将详细介绍Snowflake架构的三个不同层级：云服务层、查询处理（虚拟仓库）计算层和集中式（混合列式）数据库存储层。

共享磁盘（可扩展）架构

共享磁盘架构是一种早期的扩展方法，旨在将数据存储在中央存储位置，并从多个数据库集群节点访问（如图2-1所示）。每个集群节点访问的数据是一致可用的，因为所有数据修改都被写入共享磁盘。这种架构是传统的数据库设计，以其数据管理的简洁性而闻名。虽然这种方法在理论上很简单，但需要复杂的磁盘锁定机制来确保数据一致性，这反过来会造成瓶颈。数据并发性，允许多个用户在数据库中影响多个事务，也是一个主要问题，而在共享磁盘架构中添加更多的计算节点只会加剧这个问题。因此，这种架构的真正可扩展性是有限的。

Oracle RAC是共享磁盘架构的一个例子。

共享无关（可扩展）架构

共享无关架构是为了应对共享磁盘架构所造成的瓶颈而设计的，其中存储和计算是一起扩展的（如图2-2所示）。这种架构的演变得以实现，是因为存储成本相对较低。然而，分布式集群节点以及相关的磁盘存储、CPU和内存需要在节点之间进行数据传输，这会增加开销。

数据在节点之间的分布方式将决定额外开销的程度。在存储和计算之间取得合适的平衡尤为困难。即使可以调整集群的大小，也需要时间进行调整。因此，组织往往会过度配置共享无关资源，导致未使用和不必要的资源。共享无关架构的示例包括IBM DB2、Vertica和Pivotal Greenplum。

NoSQL架构

大多数NoSQL解决方案依赖于共享无关架构，因此它们具有许多相同的限制。然而，NoSQL解决方案的好处是可以存储非关系型数据，而无需先对数据进行转换。此外，大多数NoSQL系统不需要模式（schemas）。NoSQL是一个暗示“Not Only SQL”而不是“No to SQL”的术语，适用于存储电子邮件、网页链接、社交媒体帖子和推文、道路地图和空间数据等内容。

有四种类型的NoSQL数据库：文档存储（document stores）、键值（key-value）存储、列族数据存储或宽列数据存储，以及图形数据库。

基于文档的NoSQL数据库，如MongoDB，将数据存储在类似于键值对的JSON对象中，每个文档都具有类似的结构。键值数据库，如DynamoDB，特别适用于捕捉特定会话中的客户行为。Cassandra是一个基于列的数据库的示例，其中大量的动态列被逻辑地组织成列族。基于图形的数据库，如Neo4j和Amazon Neptune，在推荐引擎和社交网络中表现良好，能够帮助找到数据点之间的模式或关系。

NoSQL存储的一个主要限制是在涉及大量记录的计算中（如聚合、窗口函数和任意排序）性能表现较差。因此，当您需要快速在表中创建、读取、更新和删除（CRUD）单个条目时，NoSQL存储可以非常有用，但不建议用于即席分析。此外，NoSQL替代解决方案需要专门的技能集，并且与大多数基于SQL的工具不兼容。

请注意，NoSQL解决方案并不是数据库仓库的替代品。虽然NoSQL替代方案对于数据科学家可能有用，但在分析方面性能表现不佳。

Snowflake架构

即使是改进的传统数据平台，尤其是那些在本地部署的平台，也无法充分解决现代数据问题或解决长期存在的可扩展性问题。Snowflake团队决定采取一种独特的方法。他们不是试图逐步改进或转变现有的软件架构，而是为云环境构建了一个全新的现代数据平台，允许多个用户同时共享实时数据。

独特的Snowflake设计在物理上将存储和计算进行了分离，但在逻辑上进行了整合，并提供了安全性和管理等服务。随着我们在接下来的章节中探索许多独特的Snowflake特性，您将能够亲自看到为什么Snowflake架构是唯一能够实现数据云的架构。

Snowflake混合模型架构由三个层级组成，如图2-3所示：云服务层、计算层和数据存储层。每个层级以及三个Snowflake缓存将在以下章节中详细讨论。

Snowflake的处理引擎是原生的SQL，并且正如我们将在后面的章节中看到的那样，Snowflake还能够处理半结构化和非结构化数据。

云服务层

在Snowflake实例中，所有与数据的交互都始于云服务层，也称为全局服务层（如图2-4所示）。Snowflake云服务层是一组服务，协调诸如身份验证、访问控制和加密等活动。它还包括处理基础设施和元数据的管理功能，以及执行查询解析和优化等功能。云服务层有时被称为Snowflake的"大脑"，因为所有各种服务层组件共同工作，处理从用户请求登录的时候开始的用户请求。

每当用户请求登录时，该请求都会由云服务层处理。当用户提交一个Snowflake查询时，该SQL查询将首先发送到云服务层的优化器，然后再发送到计算层进行处理。云服务层使得可以通过SQL客户端界面执行对数据的数据定义语言（DDL）和数据操作语言（DML）操作。

管理云服务层

云服务层管理数据安全，包括数据共享的安全性。Snowflake云服务层在每个云提供商区域中跨多个可用区运行，并保存结果缓存，即已执行查询结果的缓存副本。查询优化或数据过滤所需的元数据也存储在云服务层中。

云服务层的计费

大多数云服务的使用已经纳入到Snowflake的定价中。然而，当客户偶尔超过每日计算配额使用量的10%时，将会对超出部分进行计费。请注意，每日计算配额使用量是按照UTC时区计算的。

所有查询都使用了少量的云服务资源。DDL操作是元数据操作，因此只使用云服务。在考虑成本较高的云服务情况时，我们应该评估一些情况，确定增加的成本是否值得获得增加的效益。

增加使用云服务层的情况通常发生在使用多个简单查询时，特别是访问会话信息或使用会话变量的查询。使用多个连接的大型复杂查询也会增加使用量。与批量加载相比，逐行插入会导致更高的云服务消耗。最后，如果您在INFORMATION_SCHEMA表上使用命令或使用特定的仅元数据命令，如SHOW命令，那么只会消耗云服务资源。如果您发现云服务的费用高于预期，您可能需要调查这些情况。还要调查任何合作伙伴工具，包括使用JDBC驱动程序的工具，因为这些第三方工具可能会提供改进的机会。

即使特定用例的云服务成本较高，从经济和/或战略上来看，有时承担这些成本也是有意义的。例如，利用查询的结果缓存，特别是对于大型或复杂的查询，将意味着该查询的计算成本为零。对于DDL命令，特别是在克隆等用例中，选择合适的频率和粒度可以更好地平衡云服务消耗成本和虚拟仓库成本，从而实现整体成本的降低。

查询处理（虚拟仓库）计算层

Snowflake的计算集群，通常简称为虚拟仓库，是由CPU、内存和临时存储组成的动态计算资源集群。在Snowflake中创建虚拟仓库时，使用了虚拟机在云中进行后台配置。Snowflake不会公开使用的确切服务器，因为云提供商可能会修改其服务，所以服务器可能会发生变化。Snowflake的计算资源是按需为用户创建和部署的，对用户来说这个过程是透明的。

大多数SQL查询和所有DML操作（包括加载和卸载数据以及更新表中的行）都需要一个正在运行的虚拟仓库。一些SQL查询可以在不需要虚拟仓库的情况下执行，我们将在本章后面讨论查询结果缓存时看到相关示例。

Snowflake的独特架构实现了存储和计算的分离，这意味着任何虚拟仓库都可以访问与其他仓库相同的数据，而不会产生争用或影响其他仓库的性能。这是因为每个Snowflake虚拟仓库都是独立运行的，不与其他虚拟仓库共享计算资源（如图2-5所示）。

一个虚拟仓库在运行时始终会消耗计算资源。然而，Snowflake的虚拟仓库可以随时启动和停止，并且可以在运行时调整大小。Snowflake支持两种不同的仓库扩展方式。通过调整仓库的大小可以将虚拟仓库的规模扩大（scale up），而通过添加集群可以将虚拟仓库的规模扩展（scale out）。可以同时使用这两种扩展方法，也可以只使用其中一种。

虚拟仓库的规模大小

Snowflake的计算集群是通过其规模来定义的，规模对应于虚拟仓库集群中的服务器数量。对于每次增加虚拟仓库的规模，计算资源的容量平均会增加一倍（参见表格2-1）。在4X-Large之后，使用了不同的方法来确定每个集群中的服务器数量。然而，这些极大型的虚拟仓库每小时的计算资源消耗仍会增加两倍的因素。

将虚拟仓库调整为较大的规模，也被称为扩展（scaling up），通常是为了提高查询性能和处理大型工作负载。在接下来的部分中，将对此进行更详细的讨论。

将虚拟仓库的规模扩大以处理大数据量和复杂查询

在一个完美的世界中（即简单的工作负载，每个测试完全相同），使用X-Small虚拟仓库和使用4X-Large虚拟仓库的总费用将相同。唯一的区别将是完成时间的减少。然而，在现实中，情况并不是那么简单。许多因素会影响虚拟仓库的性能。并发查询的数量、正在查询的表的数量以及数据的大小和组成等因素都应在调整Snowflake虚拟仓库大小时加以考虑。

适当调整大小很重要。如果虚拟仓库太小，导致资源不足，可能会导致查询花费太长时间。如果查询过小且虚拟仓库过大，可能会对成本产生负面影响。

调整Snowflake虚拟仓库的大小是一个手动过程，即使在查询运行时也可以进行调整，因为虚拟仓库无需停止或暂停即可调整大小。然而，当调整Snowflake虚拟仓库的大小时，只有后续的查询会使用新的大小。已经在运行的查询将继续运行，而排队的查询将在新大小的虚拟仓库上运行。将虚拟仓库的规模扩大将增加服务器的数量（如图2-6所示），例如从中型扩大到大型。将虚拟仓库的规模缩小将减少服务器的数量。

在Snowflake中，我们可以通过用户界面或使用SQL创建虚拟仓库。稍后我们将使用这两种方法创建一些虚拟仓库。但首先，让我们在进行实际操作之前，回顾一些有关虚拟仓库的内容。

当我们使用Snowsight用户界面创建一个新的虚拟仓库时，如图2-7所示，我们需要知道虚拟仓库的名称和我们希望虚拟仓库的大小。我们还需要决定是否希望虚拟仓库成为多集群虚拟仓库。多集群虚拟仓库允许Snowflake自动进行扩展和缩减。在下一节中，您将了解有关多集群虚拟仓库的更多信息。

一旦我们创建了虚拟仓库，我们就可以随时返回并调整其大小。调整虚拟仓库的大小意味着我们可以将其扩大或缩小。扩大或缩小仓库的操作是通过手动编辑现有的虚拟仓库来完成的。

通过用户界面或在工作表中使用SQL语句，可以实现对虚拟仓库的扩容或缩容。另一个需要注意的是，您可以选择使用一些高级虚拟仓库选项，例如自动暂停和自动恢复（如图2-8所示）。自动暂停和自动恢复默认情况下是启用的。启用自动暂停后，如果虚拟仓库在一段指定的时间内处于非活动状态，Snowflake将自动暂停该虚拟仓库。自动暂停功能确保在没有传入查询时不会让虚拟仓库持续运行。这一点很重要，因为只有在虚拟仓库运行时才会收取费用，所以在不使用虚拟仓库时最好将其暂停。

通过使用多集群虚拟仓库进行横向扩展，以最大化并发性

多集群虚拟仓库的运行方式与单集群虚拟仓库非常相似。其目标是在集群的数量和规模方面优化Snowflake系统的性能。在前面的部分中，我们了解到，当由于SQL查询运行时间过长或要加载或卸载的数据量很大而导致排队问题时，通过扩容可以提高性能，因为查询可以更快地运行。

如果并发性问题是由于用户或连接数过多而导致的，扩容将无法充分解决问题。相反，我们需要通过添加集群来进行横向扩展（如图2-9所示），例如从最小集群数为1扩展到最大集群数为3。多集群虚拟仓库可以设置为在用户数量和/或查询数量波动时自动进行扩缩容。

与单集群虚拟仓库类似，多集群虚拟仓库可以通过Web界面或使用Snowflake实例的SQL进行创建。不同于单集群虚拟仓库需要手动调整大小，多集群虚拟仓库的扩容或缩容是自动进行的。您只需要告诉Snowflake您希望多集群虚拟仓库扩容多少。

例如，您可以编辑Snowflake虚拟仓库，将最小集群数设置为1个小型集群，最大集群数设置为3个小型集群，如图2-10所示。 多集群虚拟仓库可以选择的两种模式是自动扩缩容和最大化。Snowflake的扩缩容策略旨在帮助控制自动扩缩容模式下的使用点数，可设置为标准或经济模式。

当多集群虚拟仓库配置为采用标准扩缩容策略时，第一个虚拟仓库将在查询排队时立即启动，或者当Snowflake系统检测到比当前运行的集群能够执行的查询多一个时启动。每个后续虚拟仓库将在前一个虚拟仓库启动后的20秒启动。 如果多集群虚拟仓库配置为采用经济扩缩容策略，只有当Snowflake系统估计查询负载可以至少使虚拟仓库保持繁忙六分钟时，虚拟仓库才会启动。

经济扩缩容策略的目标是通过保持虚拟仓库的充分负载来节省使用点数。因此，查询可能会进入排队状态，并且可能需要更长的时间才能完成。

建议将最大集群数（Max Clusters）的值设置得尽可能高，同时要注意相关的成本。例如，如果将最大集群数设置为10，要意识到当所有10个集群都在运行时，计算成本可能增加十倍。当最小集群数（Min Clusters）大于1且最小集群数和最大集群数的值相等时，多集群虚拟仓库被称为最大化（Maximized）。我们将在下一节中看到一个例子。

创建和使用虚拟仓库

使用SQL命令在Web界面或工作表中执行虚拟仓库操作。首先，我们将查看如何使用SQL创建和管理虚拟仓库，然后再了解虚拟仓库的Web界面功能。

创建Snowflake虚拟仓库时，可以选择两个选项：自动暂停（Auto Suspend）和自动恢复（Auto Resume）。自动暂停是在虚拟仓库离线之前等待执行查询的秒数。自动恢复会在需要计算资源的操作出现时重新启动虚拟仓库。

以下SQL脚本将创建一个具有四个集群的中型虚拟仓库，并在五分钟后自动暂停。需要注意的是，使用SQL创建虚拟仓库时，暂停时间需要以总秒数表示，而在用户界面中以分钟为单位输入。请导航到您的"Chapter2 Creating and Managing Snowflake Architecture"工作表，并执行以下SQL语句来创建一个新的虚拟仓库：

USE ROLE SYSADMIN;
CREATE WAREHOUSE CH2_WH WITH WAREHOUSE_SIZE = MEDIUM
    AUTO_SUSPEND = 300 AUTO_RESUME = true INITIALLY_SUSPENDED = true;

之前我们讨论了如何通过扩容或缩容来改变虚拟仓库的大小，以及这是一个手动的过程。为了进行扩容或缩容，我们将使用ALTER命令：

USE ROLE SYSADMIN;
ALTER WAREHOUSE CH2_WH
SET WAREHOUSE_SIZE = LARGE;

在创建此虚拟仓库后，在此工作表中执行的任何SQL语句都将在该虚拟仓库上运行。如果您更喜欢使用特定的虚拟仓库来执行脚本，可以在工作表中指定该虚拟仓库：

USE WAREHOUSE CH2_WH;

或者，您可以在Web界面右上方的上下文菜单中更新虚拟仓库（如图2-11所示）。

我们使用SQL命令创建了虚拟仓库，但我们也可以使用Snowsight Web界面来创建和/或编辑Snowflake虚拟仓库。现在让我们导航到那里。点击左上方的首页图标，然后选择Admin → Warehouses。您将看到我们刚刚创建的虚拟仓库（在图2-12中的CH2_WH）。如果您没有看到两个虚拟仓库，请尝试刷新页面。

向右滚动，点击省略号，然后选择编辑选项（如图2-13所示）。请注意，您可以选择通过点击+ Warehouse按钮来创建新的虚拟仓库，而不是选择编辑现有的虚拟仓库。

选择编辑选项后，您现在应该看到编辑虚拟仓库的界面，如图2-14所示。

如果您在Snowflake标准版组织中工作，则不会看到多集群虚拟仓库选项。对于企业版、业务关键版和虚拟私有Snowflake版，多集群虚拟仓库是启用的。即使在选择一个集群时多集群虚拟仓库的选项被切换为开启状态，但无法超出单个集群进行扩容。要进行扩容，集群的数量必须为两个或更多。当您增加集群的数量至两个或更多时，请确保评估模式。您很可能希望将模式从默认的最大化模式更改为自动扩缩容模式。这样，您的多集群虚拟仓库将按需进行扩缩容。

要通过SQL创建Snowflake多集群虚拟仓库，您需要指定扩缩容策略以及最小和最大集群数。正如前面所述，扩缩容策略仅适用于虚拟仓库在自动扩缩容模式下运行时，可以选择经济或标准模式。

工作负载的分离和工作负载管理

在传统数据库系统中，当工作负载达到最大容量时，查询处理往往变慢。相比之下，Snowflake会估算每个查询所需的资源，当工作负载接近100%时，每个新的查询会被暂停在队列中，直到有足够的资源来执行它们。有多种方法可以有效处理不同规模的工作负载。其中一种方法是通过将不同的虚拟仓库分配给不同的用户或用户组来分离工作负载（如图2-15所示）。图2-15中显示的虚拟仓库都是相同大小的，但在实际中，不同工作负载的虚拟仓库很可能是不同大小的。

不同的用户组可以被分配到不同大小的Snowflake虚拟仓库。这样，查询数据的用户将获得一致的平均查询时间。市场营销和销售团队可以创建和评估活动，并捕捉销售活动。会计和财务团队可以访问他们的报告并深入研究底层数据。数据科学家可以在大量数据上运行大规模复杂的查询。ETL流程可以持续加载数据。

在本章的前面部分，我们了解到多集群虚拟仓库可以设置为自动扩缩容，以避免并发问题。对于一个自动扩缩容的多集群虚拟仓库，我们仍然需要定义虚拟仓库的大小以及最小和最大集群的数量。之前我们已经看到了如何通过Snowflake UI创建新的虚拟仓库。现在让我们使用SQL来创建一个用于会计和财务的多集群虚拟仓库，并查看该虚拟仓库的自动扩缩容示例。返回到Chapter2 Creating and Managing Snowflake Architecture工作表：

USE ROLE SYSADMIN;
CREATE OR REPLACE WAREHOUSE ACCOUNTING_WH 
    WITH Warehouse_Size = MEDIUM MIN_CLUSTER_COUNT = 1
    MAX_CLUSTER_COUNT = 6 SCALING_POLICY = 'STANDARD';

一旦配置好多集群虚拟仓库，扩缩容过程将自动进行。图2-16说明了当并发SQL语句的数量增加时，自动扩缩容是如何工作的。

您可以看到，每小时的工作负载在员工的核心工作时间之间更重。我们还可能希望进行调查，以确认消耗型虚拟仓库用于报告的每日工作负载总体上在月初较重，因为会计部门需要准备和审查上个月的会计报表。

虚拟仓库层的计费

Snowflake虚拟仓库的消费费用是根据仓库的大小来计算的，大小由每个集群中的服务器数量、如果是多集群虚拟仓库则还包括集群的数量以及每个集群服务器的运行时间确定。Snowflake采用每秒计费，每次虚拟仓库启动或调整大小时，最低计费时间为60秒。当虚拟仓库扩缩容时，额外配置的资源将按照一分钟的计费单位计费。所有的计费都以小时的分数形式报告，即使计算时以秒为单位。

当使用ACCOUNTADMIN角色时，您可以通过在UI中点击"Account → Usage"来查看您账户的虚拟仓库使用情况。您还可以查询SNOWFLAKE共享数据库中的Account Usage视图以获取相关信息。建议您选择一个X-Small虚拟仓库来进行查询，因为数据集的规模较小且查询简单。

集中化（混合列式）数据库存储层

Snowflake的集中化数据库存储层保存着所有的数据，包括结构化数据和半结构化数据。当数据加载到Snowflake中时，它会被优化地重新组织为压缩的列式格式，并存储在Snowflake数据库中进行维护。每个Snowflake数据库由一个或多个模式（Schema）组成，模式是数据库对象（如表格和视图）的逻辑分组。第三章将介绍如何创建和管理数据库和数据库对象。在第九章中，我们将深入研究微分区，以更好地理解数据聚类和Snowflake的物理数据存储。

Snowflake数据库中存储的数据始终是压缩和加密的。Snowflake负责管理数据存储的各个方面。Snowflake会自动将存储的数据组织成微分区，这是一种优化的、不可变的、压缩的列式格式，并使用AES-256加密进行加密。Snowflake通过优化和压缩数据，使元数据提取和查询处理更加简单高效。正如我们在本章前面学到的那样，当用户提交一个Snowflake查询时，该查询会先经过云服务优化器，然后再发送到计算层进行处理。

Snowflake的数据存储层有时被称为远程磁盘层。底层文件系统是在亚马逊、微软或谷歌云上实现的（如图2-17所示）。数据存储时使用的特定提供商是您创建Snowflake账户时选择的提供商。Snowflake不限制您可以存储的数据量，也不限制您可以创建的数据库或数据库对象的数量。Snowflake表格可以轻松地存储PB级的数据。在Snowflake账户中增加或减少存储时，并不会影响虚拟仓库的大小。两者独立于彼此和云服务层进行扩展。

存储层架构中有两个独特的功能：时间旅行（Time Travel）和零拷贝克隆（zero-copy cloning）。这两个非常强大的Snowflake功能将在本章中介绍，并在以后的章节中详细讨论。为了准备后面的章节，您需要对这两个功能有深入的了解。

零拷贝克隆简介

零拷贝克隆提供给用户一种快照拷贝Snowflake数据库、模式或表以及其相关数据的方式。在进行零拷贝数据克隆时，不会额外收取存储费用，因为它只是一个元数据操作。例如，如果你克隆一个数据库，并在克隆的表中添加新的表或删除某些行，那么此时会开始收取存储费用。零拷贝克隆除了用于创建备份外，还有许多其他用途。最常见的用途是用于支持开发和测试环境。我们将在第8章中看到相关示例。

时间旅行简介

时间旅行(Time Travel)允许您恢复数据库、表或模式的以前版本。这是一个非常有用的功能，使您有机会修复之前错误的编辑或恢复错误删除的项目。通过时间旅行，您还可以通过将时间旅行功能与克隆功能结合使用，从过去的不同时间点备份数据，或者可以查询不再存在的数据库对象。您可以回溯到过去多久取决于几个不同的因素。时间旅行将在第7章中详细讨论。对于本章而言，重要的是要注意，对于已删除但仍可恢复的任何数据，将收取数据存储费用。

存储层的计费

Snowflake的数据存储费用是基于压缩数据的每日平均大小而计算的，而不是未压缩数据的大小。存储费用包括永久表中存储的持久数据的费用，以及用于批量数据加载和卸载的文件的费用。故障安全数据和使用时间旅行进行数据恢复的保留数据也被考虑在数据存储费用的计算中。同样，被删除数据引用的表的克隆也会被考虑在内。

Snowflake缓存

当您提交一个查询时，Snowflake会检查该查询是否之前已经运行过，并且结果是否仍然存在缓存中。如果结果仍然可用，Snowflake将使用缓存的结果集而不是执行您刚刚提交的查询。除了从缓存中检索先前的查询结果外，Snowflake还支持其他缓存技术。Snowflake有三种缓存类型：查询结果缓存、虚拟数据仓库缓存和元数据缓存。

查询结果缓存

从Snowflake中检索数据的最快方式是使用查询结果缓存。Snowflake查询的结果会被缓存或持久化存储，保留时间为24小时，然后被清除。这与虚拟数据仓库缓存和元数据缓存的工作方式不同。这两个缓存不会根据时间表进行清除。尽管查询结果缓存只持续24小时，但每次重新执行查询时，计时器会重新设置，最长可持续31天，从查询首次执行的日期和时间计算。在31天之后，或者在底层数据发生更改时，再次提交查询时会生成和缓存新的结果。

查询结果缓存完全由Snowflake全局云服务(GCS)层管理，如图2-18所示，并且在所有虚拟数据仓库中都可用，因为虚拟数据仓库可以访问所有数据。检索缓存结果的过程由GCS管理。但是，一旦结果的大小超过一定的阈值，结果将存储在云存储中，并从云存储中检索。

查询结果返回给一个用户后，对于任何具有必要访问权限并执行相同查询的用户也是可用的。因此，任何用户可以在没有运行虚拟数据仓库的情况下针对结果缓存运行查询，前提是查询已被缓存且底层数据没有发生更改。

查询结果缓存的另一个独特功能是它是唯一可以通过参数禁用的缓存。导航到Chapter2工作表并执行以下SQL语句：

ALTER SESSION SET USE_CACHED_RESULT=FALSE;

在进行A/B测试之前，禁用结果缓存是必要的，并且在测试完成后启用查询结果缓存非常重要。

元数据缓存

元数据缓存完全由全局服务层管理（如图2-19所示），用户对元数据具有一定的控制权，但对缓存没有控制权。Snowflake收集和管理关于表、微分区甚至聚类的元数据。对于表，Snowflake存储了行计数、表的字节大小、文件引用和表版本。

因此，在运行SELECT COUNT(*)查询时，不需要运行虚拟仓库，因为计数统计信息保存在元数据缓存中。

Snowflake的元数据存储库包括表定义和对该表的微分区文件的引用。从微分区中获取的最小值和最大值范围、NULL计数和不同值的数量都会被捕获并存储在Snowflake中。因此，某些查询不需要运行虚拟仓库即可返回结果。

例如，对于整数数据类型列的邮政编码的最小值，不需要虚拟计算云服务。Snowflake还存储了微分区的总数和重叠微分区的深度，以提供关于聚类的信息。

虚拟仓库本地磁盘缓存

传统的Snowflake数据缓存是针对用于处理查询的虚拟仓库的。运行中的虚拟仓库使用SSD存储来存储从集中数据库存储层中检索的微分区，在执行查询时必须完成所请求的查询。虚拟仓库的SSD缓存大小由虚拟仓库的计算资源大小决定。

每当一个虚拟仓库接收到一个要执行的查询时，它会首先扫描SSD缓存，然后再访问Snowflake远程磁盘存储。从SSD读取数据比从数据库存储层读取数据更快，但仍需要运行中的虚拟仓库来完成操作。

虚拟仓库缓存虽然是在每个独立的虚拟仓库层实现的，但全局服务层通过查询优化器处理整个系统的数据更新。优化器通过检查每个分配给虚拟仓库的数据段的新鲜度，并构建一个查询计划，用来从远程磁盘存储中替换任何数据段来更新数据。

需要注意的是，虚拟仓库缓存有时也被称为原始数据缓存、SSD缓存或数据缓存。该缓存在虚拟仓库被暂停时会被清除，因此您需要权衡保持虚拟仓库运行所消耗的资源与保留以前查询数据的缓存以提高性能之间的关系。默认情况下，Snowflake会在虚拟仓库闲置10分钟后自动暂停，但这可以进行更改。

代码清理

在第2章的工作表中，请确保将缓存结果设置为TRUE：

USE ROLE SYSADMIN;
ALTER SESSION SET USE_CACHED_RESULT=TRUE;

请继续删除虚拟仓库：

USE ROLE SYSADMIN;
DROP WAREHOUSE CH2_WH;
DROP WAREHOUSE ACCOUNTING_WH;