新鲜度监控是什么
新鲜度监控跟踪每张关键表最新分区的业务日期与分区写入时间，回答的是“现在这份数据能不能用”。两类延迟要分开看：业务延迟指最新分区日期与当前日期的差值，说明数据覆盖到哪一天；写入延迟指分区实际写入时间与承诺产出时间的差值，说明今天的任务有没有按时跑完。按链路的承诺时间分级预警（例如承诺 06:00 产出，05:40 开始预警），并把结果聚合成值班首屏。
基本信息
| 监控指标 | 最新分区值、分区写入时间、业务延迟与写入延迟 |
|---|---|
| 采集方式 | 元数据接口（Metastore、数据地图）或直接查询目标表 |
| 分级 | 按承诺产出时间提前 N 分钟预警，超时升级 |
| 看板 | 按链路聚合，先看链路再看单表 |
| 覆盖范围 | 核心链路的关键产出表与对外交付表 |
典型使用场景
- 值班首屏：早上第一时间确认核心表是否都已产出
- 对外交付前确认依赖表的分区是否到位，避免发出半成品报表
- 上游接口延迟时判断是数据没到还是任务没跑
- 补数之后确认业务延迟已归零，而不是只看任务成功状态
- 新增表接入时把它纳入监控清单，避免无人覆盖
新鲜度查询
新鲜度查询
-- 业务延迟：最新分区与当前日期的差值
SELECT MAX(dt) AS latest_dt,
DATEDIFF(CURRENT_DATE, MAX(dt)) AS biz_lag_days
FROM dwd_trade_order_detail_di;
-- 写入延迟：结合元数据取分区写入时间（字段名按平台调整）
SELECT table_name, dt, write_time
FROM table_partition_meta
WHERE table_name IN ('dwd_trade_order_detail_di','dws_trade_user_1d')
ORDER BY write_time DESC;
-- 链路视图：按依赖层级聚合，先看链路再看单表
SELECT chain_name, MAX(biz_lag_days) AS max_biz_lag,
SUM(CASE WHEN write_time > sla_time THEN 1 ELSE 0 END) AS breach_cnt
FROM table_freshness_view WHERE dt = CURRENT_DATE GROUP BY chain_name;两个延迟分别说明什么
| 指标 | 含义 | 正常值 | 异常含义 |
|---|---|---|---|
| 业务延迟 | 最新分区日期与今天相差天数 | T+1 表为 1 | 大于 1 说明历史数据缺口 |
| 写入延迟 | 分区写入时间晚于承诺时间 | 小于 0（按时） | 大于 0 说明当日产出超时 |
| 分区是否存在 | 目标分区有无数据 | 当日分区存在 | 缺失说明任务未产出 |
| 异常分区空跑 | 分区存在但行数为 0 | 行数大于 0 | 空跑会伪装成产出成功 |
新鲜度要按业务日期而不是写入日期判断：补昨天的数据与正常产出今天的数据含义完全不同，只看写入时间会把补数误判为正常。
分区存在不等于数据可用：任务成功但写出空分区的情况必须用行数共同判断，否则会误报正常。
监控表清单要跟着建模流程更新，新表上线时同步注册；清单长期不更新时，新增的关键表会长期处于无监控状态。