snowflake-cloud-data-platform - SnowFlake 中的合并语句似乎写入了太多行。有没有办法改善这种情况？

Question

在 Snowflake 中，我正在执行一个基本的合并语句来更新表中的一组行。该表有 1B 行，大小为 160GB。该表使用 TenantId 列作为聚类键进行聚类。此列有 10k 个不同的值，分布相当均匀。
我正在合并的数据只是更新，包括 100 万条记录，针对这些租户 ID 的子集(~500)。合并根据 TenantId(目标的集群键)和记录 ID 将此源连接到目标。
合并的结果正确列出了更新的行数，但花费的时间比我预期的要长。如果我查看查询执行详细信息，我会看到计划中的合并操作(与表扫描/连接相比几乎占用所有时间)具有“扫描的字节数”和“写入的字节数”都等于 160GB 大小我的 table 。
写入的字节似乎与那里有关。有没有办法让它将写入集中在与被触摸的记录相关的微分区上？似乎不需要写出表格的完整大小。
表的簇深度:1.0208
表的簇信息:
{
"cluster_by_keys": "LINEAR(TENANTID)",
“total_partition_count”:29827，
“total_constant_partition_count”:29646，
“average_overlaps”:0.0323，
“平均深度”: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 支持更新，但是否有效使用平台取决于您，是的，甚至包括您在平台上建模的方式。