SnowFlake 中的合并语句似乎写入了太多行。有没有办法改善这一点？

Question

在 Snowflake 中，我正在执行基本的合并语句来更新表中的一组行。该表有 1B 行，大小为 160GB。该表使用 TenantId 列作为集群键进行集群。该列有 10k 个不同的值，分布相当均匀。

我要合并的数据只是更新，其中包括针对这些租户 ID 子集（约 500 个）的 100 万条记录。合并根据 TenantId（目标的集群键）和 recordID 将此源连接到目标。

合并的结果正确列出了已更新的行数，但花费的时间比我预期的要长。如果我查看查询执行详细信息，我会发现计划中的合并操作（与表扫描/连接相比几乎占用了所有时间）的“扫描字节数”和“写入字节数”均等于 160GB 大小我的桌子。

写入的字节似乎与此有关。有没有办法让它将写入集中在与所触及的记录相关的微分区上？似乎不需要写表的完整大小。

表的簇深度：1.0208

表的集群信息：{ "cluster_by_keys" : "LINEAR(TENANTID)", "total_partition_count" : 29827, "total_constant_partition_count" : 29646, "average_overlaps" : 0.0323, "average_depth" : 1.0208, "partition_depth_histogram" : { "00000" ：0、“00001”：29643、“00002”：19、“00003”：49、“00004”：55、“00005”：17、“00006”：9、“00007”：25、“00008”：5 ，“00009”：5，“00010”：0，“00011”：0，“00012”：0，“00013”：0，“00014”：0，“00015”：0，“00016”：0 } }

Answer 1

您必须了解底层发生了什么以及微分区如何工作才能了解正在发生的情况。

雪花表看起来是可变的（允许更新），但它的底层是由不可变的文件组成的。当对现有记录执行更新时，表示该记录的文件将作为更新前的先前状态的记录写入时间旅行。并将新记录写入活动的微分区；没错，更新将创建微分区，那些对活动微分区可见的微分区和现有微分区都致力于时间旅行。

这就是为什么仅插入建模和架构范例比允许更新的建模和架构范例要高效得多的原因。即使在传统的 RDBM 中，更新也是昂贵的操作，而在大数据平台中，这几乎是不可能的。

是的，Snowflake 支持更新，但有效使用该平台取决于您，是的，甚至包括您在平台上建模的方式。