📚 课程目录第2章核心指标定义

2、核心指标定义：延迟、时效性、完整性、准确性

聊数据新鲜度监控，绕不开四个核心指标。我见过不少团队一上来就搞监控平台，结果指标定义都没对齐，最后监控成了摆设。说白了，你得先搞清楚：你到底在监控什么？

我个人习惯把这四个指标分成两组来看。延迟和时效性，是时间维度的；完整性和准确性，是质量维度的。咱们一个一个拆开讲。

2.1 延迟（Latency）

延迟，就是数据从产生到进入系统的时间差。举个例子：用户下单时间是 10:00:00，数据到达数仓是 10:05:30，那延迟就是 5 分 30 秒。

这个指标最直观，也最容易踩坑。我遇到过一个问题：某团队把延迟定义为「数据到达时间减去业务时间」，但业务时间用的是数据库的 created_at，而数据库服务器时间比应用服务器慢了 3 分钟。结果延迟经常出现负数，排查了半天才发现是时钟不同步。

注意：延迟计算必须保证时间源一致。建议统一使用 NTP 同步后的服务器时间，或者直接取消息队列的入队时间戳。

延迟的监控粒度也很重要。我一般这样划分：

延迟级别	典型场景	监控频率
秒级延迟	实时风控、在线推荐	每分钟
分钟级延迟	实时报表、监控告警	每 5 分钟
小时级延迟	离线数仓、批量同步	每小时
天级延迟	T+1 报表、财务对账	每天

你想想看，如果做实时风控却只按天监控延迟，那出了事黄花菜都凉了。所以延迟的监控频率，一定要跟业务场景匹配。

2.2 时效性（Timeliness）

时效性跟延迟容易搞混。我简单解释一下：延迟是「实际花了多久」，时效性是「有没有在规定时间内到达」。

举个例子。某报表要求每天 08:00 前产出，数据在 07:55 到了。延迟可能是 23 小时 55 分钟（从昨天 08:00 算起），但时效性是达标的。反过来，如果数据 08:05 才到，延迟只多了 5 分钟，但时效性就不达标了。

时效性指标通常用 SLA 来定义。我习惯这样写：

# 时效性 SLA 示例
sla_config = {
    "实时风控": {"deadline": "5s", "sla": 99.9},
    "实时大屏": {"deadline": "30s", "sla": 99.5},
    "离线报表": {"deadline": "08:00", "sla": 99.0},
    "数据同步": {"deadline": "10min", "sla": 99.9}
}

这里有个坑。我曾经遇到一个项目，SLA 定义的是「99% 的数据在 5 秒内到达」。结果监控发现，确实 99% 达标了，但剩下那 1% 的数据延迟了 30 分钟。这 1% 恰好是核心交易数据，直接导致当天的风控漏报。

经验之谈：时效性监控不能只看平均达标率。我建议同时监控 P99、P999 延迟，甚至直接监控最大延迟。宁可误报，不能漏报。

2.3 完整性（Completeness）

完整性，就是数据有没有丢。这个指标看起来简单，实际做起来最头疼。

我把它分成三个层面：

记录完整性：该有的行数有没有少。比如上游表有 100 万条，下游只收到 99 万条。
字段完整性：每条记录的字段有没有缺失。比如用户手机号字段全是 NULL。
时间完整性：时间窗口内的数据有没有覆盖全。比如某小时的数据完全没过来。

完整性监控最常用的手段是计数对比。我一般这样写：

# 完整性校验示例
def check_completeness(source_count, target_count, threshold=0.99):
    ratio = target_count / source_count
    if ratio < threshold:
        alert(f"数据丢失！源表 {source_count} 条，目标表 {target_count} 条，完整率 {ratio:.2%}")
    return ratio

但光计数不够。我记得有一次，源表和目标表行数完全一致，但数据内容全乱了——因为上游做了全量重刷，把旧数据覆盖了。所以完整性一定要结合其他指标一起看。

  核心原则：完整性监控要「计数 + 抽样 + 校验和」三管齐下。计数看数量，抽样看内容，校验和看数据是否被篡改。

2.4 准确性（Accuracy）

准确性，是数据新鲜度监控里最难定义的指标。为什么？因为「准确」本身就是一个相对概念。

我一般从两个维度来理解准确性：

业务准确性：数据是否符合业务逻辑。比如订单金额不能为负数，用户年龄不能超过 150 岁。
一致性准确性：同一份数据在不同系统间是否一致。比如数仓里的订单金额跟业务库里的对不上。

业务准确性通常靠规则引擎来校验。我举个例子：

# 准确性校验规则示例
accuracy_rules = [
    {"field": "order_amount", "rule": "value > 0", "severity": "critical"},
    {"field": "user_age", "rule": "0 < value < 120", "severity": "warning"},
    {"field": "order_status", "rule": "value in ('paid','shipped','completed')", "severity": "critical"},
]

一致性准确性就麻烦多了。我遇到过最头疼的情况：业务库和数仓的订单金额差了 0.01 元，排查了三天，发现是浮点数精度问题。从那以后，我所有金额字段都强制用 Decimal 类型。

避坑指南：我曾经因为没做准确性校验，导致一份错误的报表直接发给 CEO。从那以后，我定了个规矩：所有核心指标在产出前，必须经过至少两层准确性校验——规则校验 + 交叉比对。

2.5 四个指标的关系

这四个指标不是孤立的。我画了张图，帮你理清它们之间的关系：

从图上你能看出来，延迟是基础。没有延迟数据，时效性就无从谈起。完整性和准确性则是质量保障，缺了它们，数据再快也没用。

我个人建议的落地顺序是这样的：

先搞定延迟监控——这是最容易上手的，也是其他指标的基础。
再补充完整性校验——确保数据没丢，这是数据可用的前提。
然后定义时效性 SLA——把延迟数据转化成业务可理解的达标率。
最后做准确性校验——这是最难的一步，需要业务规则和数据交叉比对。

我的建议：不要试图一步到位。我见过太多团队一开始就想把四个指标全做完美，结果两个月过去了，一个都没跑通。先跑通一个，再迭代下一个，这才是务实的态度。

嗯，四个核心指标的定义就讲到这里。记住一句话：延迟看快慢，时效性看达标，完整性看有无，准确性看对错。把这四个维度抓好了，数据新鲜度监控的骨架就搭起来了。