监控动态表性能¶

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

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

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

小技巧

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

关键绩效指标¶

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

刷新持续时间¶

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

警告标志：

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

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

滞后指标¶

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

关键指标：

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

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

分区统计信息¶

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

警告标志：

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

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

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

刷新模式¶

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

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

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

诊断刷新缓慢问题¶

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

检查刷新历史记录以了解趋势。 刷新持续时间是否会随着时间的推移而增加，或者是否突然出现峰值？有关步骤，请参阅监控动态表的刷新状态。
审查查询配置文件以确定瓶颈：
- 高分区扫描率表明数据局部性较差。
- 溢出的字节数表明仓库太小。
- 特定的运算符花费很长时间，可能表明有机会优化动态表查询。
有关说明，请参阅分析查询配置文件。
检查滞后指标。 如果滞后持续超过您的目标，刷新可能跟不上您的数据量。有关说明，请参阅监控动态表的刷新状态。
查看上游依赖项。 检查上游表是否会导致延迟或生成大量更改。

在 Snowsight 中使用 Graph 视图查找以下内容：
- 执行刷新的上游表（显示为 executing 状态）。
- 上游表出现故障或暂停。
- 上游表的刷新时间比平时更长。
要访问 Graph 视图，请参阅查看连接到动态表的表图形。

检查动态表处理的变更量。 来自上游依赖项的大量变更可能会减慢刷新速度。

使用 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%）时，建议改用全量刷新模式。

常见模式和建议操作：

刷新持续时间稳定，但滞后时间较长：对于当前仓库规模和数据量，您的目标滞后可能过于激进。刷新成功完成，但无法跟上传入的变更。检查您的目标滞后和仓库资源是否匹配您的数据量。
刷新持续时间突然激增，溢出的字节数很高：仓库没有足够的内存来处理刷新，这可能是因为仓库太小，或者是因为其他查询正在同时运行。增加仓库规模或将动态表刷新移动到专用仓库。
分区扫描率会随着时间的推移而增加，但数据量保持不变：数据局部性较差，迫使 Snowflake 扫描不必要的分区。检查群集密钥和数据局部性。还要检查上游变更是否影响许多分散的分区，而不是几个连续的分区。
每次刷新都需处理表中大部分数据（超过 5% 的行或分区）：当表中多数数据频繁变更时，增量刷新的优势甚微。切换到全量刷新模式或者重新设计管道，以减少每次刷新时更改的数据量。

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

备注

跳过的或失败的刷新 通常由配置问题引起，而不是由性能问题引起。请参阅 Troubleshooting skipped or failed dynamic table refreshes。

分析查询配置文件¶

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

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

导航到 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

要寻找的内容：

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

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

监控仓库使用情况¶

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

要监控的关键指标：

溢出的字节：字节溢出到本地或远程存储意味着仓库规模可能太小。考虑增加仓库规模。有关识别和排查字节溢出问题的详细信息，请参阅寻找溢出到存储的查询。
仓库利用率：检查仓库是否有足够的资源用于刷新工作负载。利用率低意味着您的仓库规模可能过大。排队时间长意味着您的仓库规模过小或并发查询过多。
查询排队：排队的查询会延迟刷新的执行。如果刷新任务频繁排队，则增加仓库规模、为动态表刷新启用专属仓库，或考虑采用多集群仓库以应对工作负载波动。
credit 使用量：跟踪 credit 以平衡性能与成本。定期监控以发现调整仓库规模或优化刷新调度的机会。

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

监控依赖关系¶

动态表之间的依赖关系可能会影响性能。上游表中的性能问题会级联到下游表，因为下游表必须等待上游表完成刷新，然后才能开始自己的刷新。

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

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

设置性能问题警报¶

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

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

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