监控动态表性能¶

性能监控可帮助您完成以下任务：

识别缓慢或昂贵的动态表刷新。
诊断瓶颈。
衡量优化的影响。

本主题说明在监控动态表性能时的注意事项以及如何诊断问题。有关监控工具的信息，请参阅监控动态表。

小技巧

有关实践示例，请参阅教程：为 SCD Type 1 工作负载优化动态表性能。

关键绩效指标¶

要监控动态表性能，请重点关注本部分中描述的指标。

刷新持续时间¶

刷新持续时间衡量每次刷新完成所需的时间。要发现性能下降情况，请跟踪一段时间内的刷新持续时间。

Warning signs:

持续时间随着时间的推移而增加：数据量增长或数据局部性降级可能会导致刷新时间不断增加。
持续时间接近目标滞后：当刷新时间几乎与目标滞后相同时，您可能无法满足数据新鲜度要求。
持续时间方差高：刷新时间大幅波动可能意味着工作负载激增或资源争用。

要查看刷新持续时间，请参阅监控动态表的刷新状态。

滞后指标¶

滞后指标反映了动态表满足数据新鲜度目标的效果。有关目标滞后工作原理的信息，请参阅了解动态表目标滞后。

Key metrics:

实际滞后：从源数据发生变化到动态表反映这些变化之间的时间间隔。
目标滞后内时间比率：表保持在目标滞后内的时间所占百分比。比率低于 1，表示管道未达到其新鲜度目标。
最大滞后：给定周期内的最长实际滞后。

要查看滞后指标，请参阅监控动态表的刷新状态。

分区统计信息¶

对于增量刷新，扫描的分区数应与更改的数据成正比，而不是与表的总大小成正比。高分区扫描率表明数据局部性较差。

Warning signs:

增量刷新期间扫描总分区的很大比例。
分区扫描率随着时间的推移而增加，而数据却没有相应增长。

要查看分区统计信息，请参阅分析查询配置文件。

有关改进数据局部性的指南，请参阅提高数据局部性。

刷新模式¶

刷新模式直接影响性能。验证动态表是否使用预期模式。

要检查刷新模式，请使用 SHOW DYNAMIC TABLES 并审查 refresh_mode 和 refresh_mode_reason 列。在 Snowsight 中，在对象标头处查看刷新模式。

有关选择正确刷新模式的指南，请参阅选择刷新模式。

诊断刷新缓慢问题¶

当刷新时间超过预期时，请按照以下步骤确定原因：

Check the refresh history for trends in refresh duration, such as gradual increases or sudden spikes (监控动态表的刷新状态).
Review the query profile to identify bottlenecks (分析查询配置文件):
- 高分区扫描率表明数据局部性较差。
- Bytes spilled suggest that the warehouse is too small.
- 特定的运算符花费很长时间，可能表明有机会优化动态表查询。
Check whether lag consistently exceeds your target, which indicates that refreshes might not keep up with your data volume (监控动态表的刷新状态).
Review upstream dependencies to check whether upstream tables cause delays or produce large volumes of changes.

In the Graph view in Snowsight, look for the following conditions:
- 执行刷新的上游表（显示为 executing 状态）。
- 上游表出现故障或暂停。
- 上游表的刷新时间比平时更长。
要访问 Graph 视图，请参阅查看连接到动态表的表图形。
Check the volume of changes that the dynamic table processes, because large volumes of changes from upstream dependencies can slow down refreshes.

使用 DYNAMIC_TABLE_REFRESH_HISTORY 函数来查看最近刷新中有多少行发生了变化：
```
SELECT
  name,
  data_timestamp,
  statistics:numInsertedRows::INT AS rows_inserted,
  statistics:numDeletedRows::INT AS rows_deleted,
  refresh_action
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME => 'my_dynamic_table'
))
ORDER BY data_timestamp DESC
LIMIT 10;
```
Copy
当变更数据量相对于表总规模来说较大（超过表行数的 5%）时，建议改用全量刷新模式。

Common patterns and recommended actions¶

Refresh duration is stable, but lag is high: Your target lag is probably too aggressive for the current warehouse size and data volume. Refreshes finish successfully but can't keep up with incoming changes. Check whether your target lag and warehouse resources match your data volume.
刷新持续时间突然激增，溢出的字节数很高：仓库没有足够的内存来处理刷新，这可能是因为仓库太小，或者是因为其他查询正在同时运行。增加仓库规模或将动态表刷新移动到专用仓库。
分区扫描率会随着时间的推移而增加，但数据量保持不变：数据局部性较差，迫使 Snowflake 扫描不必要的分区。检查群集密钥和数据局部性。还要检查上游变更是否影响许多分散的分区，而不是几个连续的分区。
Each refresh processes a large portion of the table (more than five percent of rows or partitions): Incremental refresh provides little benefit when most of the table changes frequently. Switch to full refresh mode or redesign your pipeline to reduce the amount of data that changes with each refresh.

基于您的发现，根据优化动态表性能进行相应的修复。

备注

Skipped or failed refreshes are typically caused by configuration issues, not performance problems. See 动态表刷新跳过或失败故障排除.

分析查询配置文件¶

查询配置文件显示每次刷新的详细执行统计信息。当刷新缓慢时，查询配置文件可帮助您确定优化机会。

要访问查询配置文件，请执行以下操作：

导航到 Transformation » Dynamic Tables。
选择动态表并转到 Refresh History 选项卡。
选择要分析的刷新旁边的 Show query profile。

首先，从刷新历史记录获取查询 ID：

SELECT
  name,
  refresh_start_time,
  query_id
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME => 'my_dynamic_table'
))
WHERE state = 'SUCCEEDED'
ORDER BY refresh_start_time DESC
LIMIT 5;

Copy

然后，使用 GET_QUERY_OPERATOR_STATS 函数分析查询配置文件：

SELECT *
FROM TABLE(GET_QUERY_OPERATOR_STATS('<query_id>'));

Copy

What to look for¶

扫描的分区与修剪的分区：当分区扫描率相对于分区总数较高时，其原因通常是数据局部性较差或缺乏聚类。
时间分布：检查哪些运算符消耗的时间最多。耗时过长的运算符可能意味着存在查询优化的机会。请参阅优化增量刷新查询以获得特定于运算符的指南。
溢出到本地或远程存储的字节：高字节溢出通常表明仓库规模不足以应对当前刷新工作负载，或同一仓库上运行的其他查询占用了刷新所需的内存资源。考虑增加仓库规模或在专用仓库上运行动态表刷新以减少争用。

有关如何解决查询配置文件中发现的问题的更多指南，请参阅优化动态表性能。

监控仓库使用情况¶

要检查仓库是否可以处理动态表工作负载并找到降低成本的方法，请监控仓库使用情况。

Key metrics to monitor¶

溢出的字节：字节溢出到本地或远程存储意味着仓库规模可能太小。考虑增加仓库规模。有关识别和排查字节溢出问题的详细信息，请参阅寻找溢出到存储的查询。
仓库利用率：检查仓库是否有足够的资源用于刷新工作负载。利用率低意味着您的仓库规模可能过大。排队时间长意味着您的仓库规模过小或并发查询过多。
Query queuing: Queued queries delay refreshes. If refreshes frequently queue, increase warehouse size, use a dedicated warehouse for dynamic table refreshes, or consider a multi-cluster warehouse to handle variable workloads.
credit 使用量：跟踪 credit 以平衡性能与成本。定期监控以发现调整仓库规模或优化刷新调度的机会。

要查看仓库使用情况和排队时间，请参阅减少队列。使用优化动态表性能优化动态表的仓库配置。

监控依赖关系¶

Dependencies between dynamic tables can affect performance. Performance issues in upstream tables cascade to downstream tables because a downstream table must wait for upstream tables to complete their refreshes before it can start its own refresh.

要诊断与上游依赖关系相关的性能问题，请参阅诊断刷新缓慢问题。

要查看依赖关系图，请参阅查看连接到动态表的表图形。

设置性能问题警报¶

您可以设置警报，以便在性能下降时通知您。我们建议为以下条件创建警报：

刷新持续时间超过阈值。
滞后始终未达到目标。

警报使用事件表来跟踪刷新事件。有关设置说明，请参阅动态表的事件表监控和警报。