大数据指标和 SLA，那些你以为懂了其实没懂的事

——Echo_Wish：咱聊点接地气、能落地的大数据监控经

很多做大数据的同学，经常会被一句话弄得“精神内耗”：“这个指标为什么没达标？SLA 又掉了！”

说实话，刚入行的时候我也懵：指标到底该怎么定义？SLA 应该怎么算？监控到底监啥？怎么监控才算“有脑子”？

今天咱就不装深沉，带你把这些概念从云端拉下来，变成落地、能用、看得懂的东西。

你会看到的内容是：
✔ 大数据系统常见指标到底有哪些？
✔ SLA 到底是什么鬼？怎么量化？
✔ 监控怎么做才算靠谱？
✔ 给你几段代码示例，让你回去就能落地

准备好了吗？咱开聊！

1. 大数据系统的指标，不是越多越好，是越“关键”越好

很多公司一开始做监控喜欢“堆指标”：CPU、内存、磁盘、网络、吞吐、延迟、QPS、TPS、I/O Wait…

监控大屏看起来像开了挂，但出了事谁都不知道到底哪个指标真正代表问题。

做监控的第一原则：指标是为业务服务，而不是为了好看。

在大数据场景里，我们大概可以把指标分 4 类：

① 计算类指标（Spark / Flink / MapReduce）

为什么重要？

因为它们直接关联一个核心问题：我的任务能不能准时跑完？

② 存储类指标（HDFS / Object Storage / 数据仓库）

存储的问题往往比你想象的更致命。
小文件、NN 负载、磁盘打满这些事，“搞不好就是灭顶之灾”。

③ 服务接口类指标（API / Gateway / 离线导出服务）

如果你的大数据平台有“对外服务能力”，这些指标就是命根子。

④ 数据质量类指标（DQ）

别再认为监控只看 CPU 了！现在更重要的是“你数据好不好”。

2. SLA 不是“看心情写的”，它其实很数学

很多业务方对 SLA 的理解是这样的：

“你们计算任务必须每天 6:00 之前跑完，不然 SLA 不达标！”

但 SLA 真不是一句口号，它是一个公式：

✔ SLA 定义：

SLA = 服务可用时间 / 总时间

如果按月统计：

SLA = (总分钟数 - 故障分钟数) / 总分钟数

比如一个月 30 天，总分钟数是 43200 分钟，
如果你这个月发了 2 次事故各挂了 30 分钟——

SLA = (43200 - 60) / 43200 = 99.86%

✔ 在大数据里的特殊 SLA

大数据系统的 SLA 不只是“掉不掉线”，还有两类更特殊的 SLA：

① 离线任务 SLA = 准点率

例如：

“日任务必须 6:00 前完成，准点率需 ≥ 99.5%”

计算方式：

准点率 = 准时完成次数 / 总运行次数

② 实时任务 SLA = 延迟

例如：

“Flink 流任务端到端延迟 ≤ 5 秒，达标率 ≥ 99.9%”

计算方式：

延迟达标率 = (延迟 ≤ 阈值的事件数) / (总事件数)

3. 监控到底怎么落地？别画大饼，越简单越稳定

常见监控体系：

✔ 指标采集（Prometheus / JMX / 业务埋点）
✔ 指标存储（Prometheus TSDB / ClickHouse）
✔ 可视化（Grafana）
✔ 报警系统（Alertmanager / 自研）

很多人只搞一个 Grafana，大屏弄得光鲜亮丽，却没有报警策略。
大屏不报警，就是电子挂件。

4. 给你几段真正能落地的代码示例

（1）示例：Prometheus 监控 Spark 指标（Python pushgateway）

业界常用：Spark 指标 → Prometheus Pushgateway → Grafana 展示

# 推送 Spark Job 指标到 Prometheus Pushgateway
from prometheus_client import CollectorRegistry, Gauge, push_to_gateway
import time

def push_spark_metrics(job_name, duration, status):
    registry = CollectorRegistry()

    g_duration = Gauge('spark_job_duration_seconds',
                       'Spark Job Duration',
                       registry=registry)
    g_status = Gauge('spark_job_status',
                     '0=failed, 1=success',
                     registry=registry)

    g_duration.set(duration)
    g_status.set(1 if status == 'success' else 0)

    push_to_gateway('http://pushgateway:9091',
                    job=job_name,
                    registry=registry)

# 示例：推送一个任务的执行结果
push_spark_metrics("daily_etl_order", duration=523, status="success")

用这个你就能创建自己的 任务 SLA 监控系统。

（2）示例：Flink 计算延迟监控（Java Metrics）

// 注册延迟指标
Gauge<Long> latencyGauge = runtimeContext.getMetricGroup()
    .gauge("event_latency_ms", () -> System.currentTimeMillis() - event.getTimestamp());

这个指标可以直接被 Prometheus 抓取，用于计算延迟 SLA。

（3）示例：数据质量 Freshness SLA 提取（PySpark）

from pyspark.sql import functions as F

df = spark.read.table("dwd_order")

# 计算该表中最新分区的延迟（分钟）
freshness_df = df.agg(
    (F.current_timestamp() - F.max("update_time")).alias("freshness_delay")
)

freshness_df.show()

# 如果延迟超过 30 分钟则报警
delay = freshness_df.collect()[0]["freshness_delay"].seconds / 60
if delay > 30:
    print("ALERT: Data freshness breached!")

这个脚本可以做 数据新鲜度 SLA 的基础监控。

5. 我的一些“老程序员经验之谈”

① 监控系统越复杂，越容易出事

报警狂响的时候，通常原因不是系统出问题，而是监控自己出问题。

Keep it simple.

② SLA 不要乱承诺，否则你会痛不欲生

很多公司技术团队“嘴上很硬”：“这个任务保证 6 点前完成！”
结果集群一抖、任务链路一长，自己天天背锅。

SLA 的制定应该是：

资源 + 架构 + 任务本身 能力的综合产物，而不是拍脑袋。

③ 指标不在多，而在“关键且可行动”

一个指标好不好，有一个简单标准：

指标是否能指导运维或开发去解决问题？

不能行动的指标，就是垃圾指标。

6. 写在最后：大数据不是堆 KPIs，而是保障“业务最后的安心感”

大数据平台本质不是技术堆叠，而是：

✔ 数据要准
✔ 任务要稳
✔ 服务要快
✔ 出问题要能第一时间知道