微分区和数据聚类

传统数据仓库依靠对大型表进行静态分区来实现可接受的性能,并实现更好的扩展。在这些系统中,分区 是一个管理单元,使用专门的 DDL 和语法独立操纵。但静态分区有许多公认的局限性,如维护开销和数据扭曲,可能导致分区大小不成比例。

与数据仓库相比,Snowflake 数据平台实现了一种强大而独特的分区形式,称为 微分区,它具备静态分区的所有优点,杜绝了静态分区已知的局限性,还提供了额外的显著优势。

注意

混合表 基于一种架构,这种架构不支持标准 Snowflake 表中可用的某些功能(例如群集密钥)。

什么是微分区?

Snowflake 表中的所有数据都会自动划分到微分区中,微分区是连续的存储单元。每个微分区包含 50 MB 至 500 MB 的未压缩数据(注意,在 Snowflake 中的实际大小要小一些,因为数据在存储时始终经过压缩)。表中的行组映射到单个微分区,并以列式方式组织。这种大小和结构允许对超大型表(可能由数百万乃至数亿个微分区构成)进行高度精细的修剪。

Snowflake 会存储有关微分区中存储的所有行的元数据,包括:

  • 微分区中各列的值范围。

  • 非重复值的数量。

  • 用于优化和高效查询处理的附加属性。

备注

系统会对所有 Snowflake 表自动执行微分区。在插入/加载数据时,将使用数据的排序透明地对表进行分区。

微分区的优势

Snowflake 的表数据分区方法有以下优势:

  • 不同于传统的静态分区,Snowflake 的微分区是自动生成的,无需事先显式定义,也不需要用户进行维护。

  • 顾名思义,微分区是非常小的(在压缩前为 50 到 500 MB),因此能实现极其高效的 DML 和细粒度修剪,从而加快查询速度。

  • 微分区的值范围可以重叠,再加上其大小一贯较小,有助于防止数据扭曲。

  • 列独立存储在微分区内,通常称为 列式存储。这支持有效扫描单个列;只需要扫描查询引用的列。

  • 在微分区内,列也是单独压缩的。Snowflake 会自动为每个微分区中的列确定最有效的压缩算法。

通过为每个表指定一个群集密钥,可以在特定表上启用群集。有关指定群集密钥的信息,请参阅:

有关群集的其他信息,包括选择对哪些表进行群集的策略,请参阅:

微分区的影响

DML

所有 DML 操作(如 DELETE、 UPDATE、 MERGE)都利用了底层的微分区元数据,以方便和简化表元维护。例如,某些操作(如删除表中的所有行)是仅限元数据的操作。

删除表中的一列

删除表中的一列后,执行 drop 语句时不会对包含已删除列数据的微分区进行重写。删除的列中的数据仍在存储中。有关详细信息,请参阅 ALTER TABLE 使用说明

查询修剪

Snowflake 维护的微分区元数据可在查询运行时精确修剪微分区中的列,包括含有半结构化数据的列。换言之,如果某查询指定了针对一个值范围的筛选谓词,以访问该范围内 10% 的值,那么理想情况下,该查询只扫描 10% 的微分区。

例如,假设一个大型表包含一年的历史数据,其中有日期和小时列。假设数据分布均匀,那么理想情况下,针对特定小时的查询应该扫描表中 1/8760 的微分区,然后仅扫描微分区中包含小时列数据的部分;Snowflake 使用分区的列式扫描,因此如果查询仅按一列进行筛选,则不会扫描整个分区。

换言之,扫描的微分区和列式数据的比例越接近于选定实际数据的比例,对表进行修剪的效率就越高。

对于时间序列数据,这种程度的修剪可使查询范围(即“切片”)细化到一小时甚至更短,从而实现亚秒级响应时间。

并非所有谓词表达式都能用于修剪。例如,即便子查询的结果是常量,Snowflake 也不会基于带有子查询的谓词修剪微分区。

什么是数据聚类?

通常情况下,表中存储的数据会按照自然维度(如日期和/或地理区域)进行排序/排列。这种“聚类”是查询的一个关键因素,因为未排序或仅部分排序的表数据可能会影响查询性能,对于超大型表尤其明显。

在 Snowflake 中,当数据插入/加载到表中时,系统会收集并记录在此过程中创建的每个微分区的聚类元数据。Snowflake 随后会利用这些聚类信息,避免在查询过程中对微分区进行不必要的扫描,从而显著加快引用这些列的查询的性能。

下图展示了 Snowflake 表 t1,其中有四列按日期排序:

采用自然排序的逻辑和物理表结构

表由 24 行组成,分别存储在 4 个微分区中,所有行平均分配到各微分区之间。在每个微分区内,数据按列进行排序和存储,这使得 Snowflake 可对表的查询执行以下操作:

  1. 首先,修剪查询不需要的微分区。

  2. 随后在其余微分区内按列进行修剪。

请注意,此图仅用作 Snowflake 在微分区中使用的数据聚类的小比例概念表示。一个典型的 Snowflake 表可能包含数千乃至数百万个微分区。

为微分区维护的聚类信息

Snowflake 维护表中微分区的聚类元数据,其中包括:

  • 构成表的微分区总数。

  • 包含彼此重叠的值(指定的表列子集内)的微分区数量。

  • 重叠的微分区的深度。

聚类深度

填充表的聚类深度用于衡量表中指定列的重叠微分区的平均深度(1 或更大)。平均深度越小,表与指定列相关的聚类就越好。

聚类深度可用于多种用途,包括:

  • 监控大型表的聚类“健康状况”,尤其是在对表执行 DML 的过程中。

  • 确定大型表能否受益于显式定义 群集密钥

没有微分区的表(即未填充的表/空表)的聚类深度为 0

备注

表的聚类深度 并非 表聚类是否良好的绝对或精确衡量标准。归根结底,查询性能才是衡量表聚类程度的最佳指标:

  • 如果对某个表的查询的执行效果符合需要或预期,则该表很可能聚类良好。

  • 如果查询性能随着时间的推移而降低,则表很可能不再聚类良好,并且有可能从聚类中受益。

聚类深度示意图

在下图的概念示例中,表由五个微分区组成,这些微分区的值从 A 到 Z 不等,此示例展示了重叠如何影响聚类深度:

聚类深度示例

如此图所示:

  1. 最初,所有微分区的值范围是重叠的。

  2. 随着重叠微分区数量的减少,重叠深度也随之缩小。

  3. 在没有任何微分区的值范围存在重叠时,微分区被认为处于 *恒定状态*(即无法通过聚类加以改进)。

此图并不代表实际表。在实际表中,数据包含在大量微分区中,不可能为了提高查询性能而使所有微分区达到恒定状态,也不需要这样做。

监控表的聚类信息

为了查看/监控表的聚类元数据,Snowflake 提供了以下系统函数:

有关这些函数如何使用聚类元数据的更多详情,请参阅 聚类深度示意图 (本主题内容)。

语言: 中文