2. Snowflake可观测性数据源全景

在 Snowflake 上做可观测性，第一件容易踩坑的事不是“指标怎么算”，而是“数据从哪里取”。Snowflake 提供了多套元数据与使用数据视图，它们看起来都在描述“查询、仓库、存储、任务”，但延迟、保留期、权限模型、覆盖范围完全不同。选错数据源，轻则指标口径对不上，重则监控面板在故障发生时看不到任何数据。

可以把这些数据源按两个维度来理解：覆盖范围（单个账户内，还是整个组织跨账户）和数据新鲜度（实时/近实时，还是小时级延迟）。前者决定你能看到谁，后者决定你能多快看到。

账户内数据源：ACCOUNT_USAGE 与 INFORMATION_SCHEMA

ACCOUNT_USAGE 位于 SNOWFLAKE.ACCOUNT_USAGE 模式，是账户级使用数据的“历史仓库”。它的核心特征是保留期长（多数视图保留 365 天）和小时级延迟（通常 45 分钟到 3 小时不等）。这意味着它非常适合做成本趋势、仓库利用率、查询性能的长期分析，但不适合做“刚刚那条查询为什么卡住”的实时排障。

其中最重要的视图是 QUERY_HISTORY，它记录每条查询的 SQL 文本、执行状态、总耗时、编译时间、排队时间、扫描字节数、仓库名、用户与角色。做可观测性时，常用它计算 P95 查询延迟、失败率、按仓库的信用消耗归因。例如下面这段查询，用于找出过去 24 小时内平均耗时最长的前 10 个查询指纹：

SELECT query_hash,
       COUNT(*) AS exec_cnt,
       ROUND(AVG(total_elapsed_time)/1000, 2) AS avg_sec,
       ROUND(MAX(total_elapsed_time)/1000, 2) AS max_sec,
       SUM(bytes_scanned)/1024/1024/1024 AS gb_scanned
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD('hour', -24, CURRENT_TIMESTAMP())
  AND execution_status = 'SUCCESS'
GROUP BY query_hash
ORDER BY avg_sec DESC
LIMIT 10;

INFORMATION_SCHEMA 则位于每个数据库内，提供近实时的元数据与查询历史。它的 QUERY_HISTORY 视图（注意与 ACCOUNT_USAGE 同名但不同位置）延迟通常在秒级到分钟级，保留期只有 7 天到 14 天。因此它适合做实时监控告警：当某条查询失败或排队时间超过阈值时，可以立即从 INFORMATION_SCHEMA 中读到。但它的历史深度不足以做月度成本分析。

组织级数据源：ORGANIZATION_USAGE

当企业有多个 Snowflake 账户（例如按业务线、环境或地区拆分）时，单账户视图无法回答“整个组织这个月花了多少信用额度”。ORGANIZATION_USAGE 位于组织账户中，提供跨账户的用量、存储、信用额度、登录历史等数据。它的延迟同样是小时级，但覆盖范围从单账户扩展到整个组织。

典型场景包括：组织级成本分摊、跨账户的仓库用量对比、统一的安全审计。需要注意的是，访问 ORGANIZATION_USAGE 需要组织管理员权限，且视图结构与传统 ACCOUNT_USAGE 不同，字段命名和粒度都有差异。例如 ORGANIZATION_USAGE.USAGE_IN_CURRENCY_DAILY 按账户、日期、服务类型汇总费用，而 ACCOUNT_USAGE 更偏向资源级明细。

EVENT 表：自定义可观测性埋点

前三类数据源都是 Snowflake 自动采集的“系统元数据”。但很多可观测性需求是业务自定义的：数据管道每一步的耗时、某个任务处理了多少行、外部 API 调用的成功率。这时需要 EVENT 表。

EVENT 表通过 CREATE EVENT TABLE 创建，配合 ALTER SESSION SET EVENT_TABLE = ... 或账户级设置，让 Snowflake 将日志、追踪、指标事件写入表中。它的最大特点是实时写入，且 schema 由用户定义。你可以用 SYSTEM$LOG 函数或 OpenTelemetry 协议写入结构化事件，然后用 SQL 直接查询。

CREATE EVENT TABLE observability.public.app_events;

ALTER SESSION SET EVENT_TABLE = observability.public.app_events;

-- 写入一条自定义追踪事件
SELECT SYSTEM$LOG('INFO',
  OBJECT_CONSTRUCT('pipeline', 'orders_etl',
                   'stage', 'transform',
                   'rows', 152340,
                   'duration_ms', 8420));

写入后即可用标准 SQL 分析：按 pipeline 分组统计各阶段耗时、按小时统计错误率。EVENT 表把“可观测性数据”从系统元数据扩展到了业务语义层，是构建端到端可观测性的关键拼图。

如何选择：一张决策表

实际工程中，这四类数据源往往组合使用：用 EVENT 表采集业务埋点，用 INFORMATION_SCHEMA 做实时告警，用 ACCOUNT_USAGE 做趋势与成本分析，用 ORGANIZATION_USAGE 做跨账户汇总。理解每类数据源的延迟、保留期和覆盖范围，是设计可观测性架构的第一步，也是避免“指标算错、告警漏报”的根本前提。