大数据指标和 SLA，那些你以为懂了其实没懂的事
——Echo_Wish：咱聊点接地气、能落地的大数据监控经
很多做大数据的同学，经常会被一句话弄得“精神内耗”：“这个指标为什么没达标？SLA 又掉了！”
说实话，刚入行的时候我也懵：指标到底该怎么定义？SLA 应该怎么算？监控到底监啥？怎么监控才算“有脑子”？
今天咱就不装深沉，带你把这些概念从云端拉下来，变成落地、能用、看得懂的东西。
你会看到的内容是：
✔ 大数据系统常见指标到底有哪些？
✔ SLA 到底是什么鬼？怎么量化？
✔ 监控怎么做才算靠谱？
✔ 给你几段代码示例，让你回去就能落地
准备好了吗？咱开聊！
1. 大数据系统的指标，不是越多越好，是越“关键”越好
很多公司一开始做监控喜欢“堆指标”：CPU、内存、磁盘、网络、吞吐、延迟、QPS、TPS、I/O Wait…
监控大屏看起来像开了挂，但出了事谁都不知道到底哪个指标真正代表问题。
做监控的第一原则：指标是为业务服务，而不是为了好看。
在大数据场景里，我们大概可以把指标分 4 类：
① 计算类指标（Spark / Flink / MapReduce）
| 指标 | 解释 |
|---|---|
| Job Duration | 作业总耗时（最常用 SLA 指标） |
| Stage/Task Duration | 可用于定位瓶颈阶段 |
| Data Skew Ratio | 数据倾斜情况 |
| Shuffle Read/Write | Shuffle 压力判断 |
| Backpressure（Flink） | 是否出现反压 |
为什么重要？
因为它们直接关联一个核心问题：我的任务能不能准时跑完？
② 存储类指标（HDFS / Object Storage / 数据仓库）
| 指标 | 解释 |
|---|---|
| HDFS NN Heap Usage | NN 是否将近 OOM |
| I/O Throughput | 访问负载 |
| File Count | 小文件爆炸预警 |
| Table Latency | 数据入仓延迟 |
存储的问题往往比你想象的更致命。
小文件、NN 负载、磁盘打满这些事，“搞不好就是灭顶之灾”。
③ 服务接口类指标（API / Gateway / 离线导出服务）
| 指标 | 解释 |
|---|---|
| QPS | 每秒请求数 |
| P99 Latency | 99% 请求耗时 |
| Error Rate | 错误比例 |
如果你的大数据平台有“对外服务能力”，这些指标就是命根子。
④ 数据质量类指标（DQ）
| 指标 | 解释 |
|---|---|
| Completeness | 数据完整性 |
| Freshness | 新鲜度延迟（必须监控） |
| Accuracy | 准确性 |
| Consistency | 一致性 |
别再认为监控只看 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，而是保障“业务最后的安心感”
大数据平台本质不是技术堆叠，而是：
✔ 数据要准
✔ 任务要稳
✔ 服务要快
✔ 出问题要能第一时间知道
