刷新模式如何影响动态表性能¶

了解增量刷新性能¶

在增量刷新中，大部分工作通常用于计算动态表中的更改。这取决于查询，可能相当复杂。一个常见的误解是增量刷新只扫描源表中的更改，而不是源表本身。这可能导致误解为增量刷新只应执行与更改的源数据量成比例的工作，但事实并非如此。实际上，增量刷新通常需要直接扫描源表。

例如，想象一个查询在表 A 和表 B 之间进行内部联接。如果向表 A 插入一行，它必须与表 B 联接，以计算查询中的更改。表 A 中的这一行可以与表 B 中的许多行联接，这可能意味着即使源中只有少量更改，也会有很多工作。

这种额外的工作可能需要利用各种运算符来完成。增量刷新处理新数据，跳过已经完成的工作。决定跳过什么内容可能需要额外的工作，特别是复杂的查询，不同的运算符可能会以不同的方式跳过工作。

通常，变更的大小和局部性会影响可以跳过多少工作。

大小如何影响增量刷新性能¶

影响增量刷新性能的最重要因素是源数据变更的大小。在确定动态表格刷新更改的大小时，请确保将复制的行包含在内。在微分区中更改了一些行的 DML 也会将该微分区中未更改的行复制到一个新的微分区。

要分析基本表中更改的行数，请在最后一次刷新时在基本表上创建 一个流，并使用 SYSTEM$STREAM_BACKLOG。例如：

CREATE STREAM mystream ON TABLE mybasetable BEFORE(STATEMENT => 'last refresh UUID');

SELECT * FROM TABLE(SYSTEM$STREAM_BACKLOG('mystream'))

作为一个极端的例子，考虑从一个源中删除所有数据的影响：完整刷新只看到一个空表，这可以非常快速地处理。与此相比，增量刷新必须处理每一行被删除的记录，这使得它的速度慢得多。

类似的减速也可能发生在不太极端的情况下。良好工作负载的一个良好准则是将源或目标中的变更控制在行数的 5% 以下。

局部性如何影响增量刷新性能¶

影响增量刷新的第二个最重要因素是 局部性，它是指不同维度上数据或操作的相关程度。

例如，如果您有一个包含时间戳列的表，并且始终在该列中插入包含当前时间的行，那么您的工作负载在插入顺序和时间戳列之间具有很强的局部性。

局部性能够以各种形式显示，但少数形式对于增量刷新特别重要。在以下任一领域改进局部性可提升增量刷新的性能，尽管有时不太可能所有三个类别都具有强局部性。

单个运算符增量刷新的性能预期¶

下表显示了单个运算符增量刷新的近似性能预期。性能是相对于完整刷新来衡量的，并且假设只有 5% 的行发生了变更，并且刷新作业至少需要 1 分钟。

对于受局部性影响的运算符，该表显示了具有良好局部性和较差局部性的性能预期。请注意，对于某些运算符来说，较差局部性可能导致比完整刷新更糟糕的性能。

有关更多信息，请参阅 运算符如何增量刷新。

优化复杂动态表的增量刷新模式性能¶

动态表通常包含多个运算符，因此难以预测增量刷新的性能。本部分探讨了如何应对这一挑战，并给出了一些增强复杂动态表性能的技巧。

当涉及多个运算符时，增量刷新通过分别处理每个运算符来计算更改，将其变为查询计划的片段，查询计划可以基于其输入计算更改。对于每个输入，此新片段可以在变更之前、变更之后或仅将变更本身请求输入。通过将此过程应用于原始查询中的每个运算符，您将获得一个新的查询计划，该计划将混合使用变更扫描和完整表扫描计算更改。该计划由 Snowflake 的查询优化器优化，并像任何其他查询一样执行。

当增量刷新性能不佳时，通常是因为变更次数太多或局部性较差导致。复杂查询使得识别这些问题变得更加具有挑战性。增量运算符的性能通常取决于变化的数量和输入的局部性。然而，这些输入是其他运算符的输出，因此数据的数量和局部性会随着运算符之间的移动而发生变化。

因此，理解复杂增量刷新性能需要单独考虑每个运算符的输入。以下是一些常见的场景和解决这些问题的建议：