📚 课程目录第2章核心评估指标

核心评估指标：延迟、吞吐量、数据质量、资源利用率、错误率

评估一个数据管道健不健康，不能光凭感觉。我见过不少团队，上线时跑得挺欢，过两周就开始报警不断。说白了，你得有把“尺子”去量。这把尺子就是五个核心指标：延迟、吞吐量、数据质量、资源利用率、错误率。

这五个维度，缺一不可。你想想看，吞吐量再高，数据全是脏的，有什么用？延迟再低，资源把集群打爆了，也撑不住。下面我一个一个拆开讲，顺便聊聊我在项目中踩过的坑。

  核心观点： 五个指标必须联动看，单看任何一个都是“盲人摸象”。

2.1 延迟（Latency）

延迟，就是数据从产生到可被消费的时间差。我习惯把它分成两种：端到端延迟和单节点延迟。

端到端延迟： 从源头（比如业务数据库、日志采集器）到目标（比如数仓、OLAP引擎）的总耗时。这个指标最直观，业务方最关心。
单节点延迟： 每个处理环节（如Kafka消费、Spark计算、写入HDFS）各自的耗时。用来定位瓶颈。

我曾经遇到一个实时推荐管道，端到端延迟从5分钟飙到了40分钟。业务方天天催。我排查后发现，不是计算慢，而是Kafka的一个分区挂了，导致数据积压。嗯，这里要注意：延迟飙升，很多时候不是计算资源不够，而是上游或中间件出了问题。

监控建议： 用P50、P95、P99三个分位数来监控延迟。P99更能反映长尾问题。我习惯在Grafana上同时展示这三条线，一眼就能看出有没有“慢查询”拖后腿。

2.2 吞吐量（Throughput）

吞吐量，单位时间内管道能处理的数据量。常见单位有：条/秒、MB/s、GB/h。这个指标和延迟是“欢喜冤家”。

你想想看，一味追求低延迟，可能会限制并发，导致吞吐量上不去。反过来，为了高吞吐量，可能会用大批次处理，延迟自然就高了。我个人的经验是：先定延迟SLA，再在这个约束下最大化吞吐量。

场景	优先指标	典型技术选型
实时风控	延迟（毫秒级）	Flink、Kafka Streams
离线ETL	吞吐量（GB级/小时）	Spark、MapReduce
日志采集	吞吐量 + 稳定性	Filebeat + Kafka

避坑指南： 我曾经为了压榨吞吐量，把Spark的batch size调得很大。结果内存溢出，任务频繁失败。吞吐量没上去，错误率倒是先爆了。记住：吞吐量的提升，必须建立在资源充足和稳定性可控的基础上。

2.3 数据质量（Data Quality）

这个指标最容易被忽视，但后果也最严重。数据质量差，下游的分析、报表、模型全是错的。我把它拆成三个维度：

完整性： 有没有丢数据？字段有没有空值？
准确性： 数据值对不对？比如金额字段有没有出现负数？
一致性： 同一份数据在不同系统里是否一致？比如用户ID在MySQL和Hive里格式是否统一？

我建议在管道中埋设“数据质量检查点”。每经过一个关键环节，就做一次校验。比如：

# 伪代码：数据质量检查
def check_data_quality(df):
    # 完整性检查
    assert df.count() > 0, "数据为空！"
    # 准确性检查
    assert df.filter(col("amount") < 0).count() == 0, "存在负金额！"
    # 一致性检查
    assert df.select("user_id").distinct().count() == expected_count, "用户ID不唯一！"
    print("数据质量检查通过")

  个人习惯： 我会把数据质量指标也做成一个监控面板。一旦完整性低于99.9%，或者准确性异常，立刻告警。别等到下游跑完报表才发现数据是脏的，那代价太大了。

2.4 资源利用率（Resource Utilization）

资源利用率，说白了就是你的集群在“摸鱼”还是在“996”。主要看CPU、内存、磁盘IO、网络带宽。

利用率太低，说明你资源买多了，浪费钱。利用率太高（比如持续超过90%），说明集群快扛不住了，随时可能雪崩。我一般把目标定在60%-80%之间，留点余量应对突发流量。

我记得有一次，一个Spark任务把集群的CPU打到了95%。其他任务全在等资源，延迟飙升。后来发现是某个实习生写的代码，没有做数据倾斜处理。嗯，这里要注意：资源利用率高，不一定是好事，可能是代码有bug。

优化思路： 如果CPU利用率低但内存高，可能是数据倾斜；如果磁盘IO高但CPU低，可能是频繁的shuffle或小文件问题。对症下药，别盲目加资源。

2.5 错误率（Error Rate）

错误率，就是失败任务数占总任务数的比例。这个指标最直接，也最让人头疼。

我把它分成两类：

可重试错误： 比如网络抖动、连接超时。这类错误通常自动重试就能解决。
不可重试错误： 比如数据格式错误、权限不足、代码bug。这类错误必须人工介入。

我曾经遇到一个管道，错误率一直在5%左右徘徊。自动重试机制一直在跑，但问题没解决。后来我仔细看日志，发现是某个上游接口改了字段类型，但没通知我们。这就是典型的“不可重试错误”被当成了“可重试错误”处理，白白浪费资源。

避坑指南： 错误率监控一定要区分错误类型。对于不可重试错误，要立刻停止重试，并发出高优先级告警。我曾经因为没区分，导致一个错误数据被重复处理了10次，污染了下游所有表。

2.6 五维指标联动分析

单独看一个指标，意义不大。真正的高手，是看五个指标之间的“化学反应”。

举个例子：

延迟高了 + 吞吐量低了 + 资源利用率高了 = 大概率是资源瓶颈，需要扩容。
延迟高了 + 吞吐量不变 + 错误率高了 = 大概率是数据质量问题或代码bug。
延迟低了 + 吞吐量高了 + 数据质量下降了 = 可能为了性能牺牲了校验，需要权衡。

下面这张图，是我自己总结的评估框架，你可以参考一下：

这五个指标，就像汽车的五个仪表盘。你只看速度（吞吐量），不看水温（资源利用率），迟早要开锅。我建议你从今天开始，就把这五个指标都加到你的监控系统里，缺一个都不行。