3. 资源利用率指标：CPU使用率、内存使用率、磁盘IO、网络吞吐量、Executor数量与负载
资源利用率指标是Spark作业运行状态的“体温计”。CPU、内存、磁盘IO、网络吞吐量以及Executor数量与负载，共同决定了作业能否在合理时间内完成。调优告警阈值的第一步，就是理解这些指标的正常基线、异常模式以及它们之间的关联关系。
3.1 核心指标定义与告警意义
下表列出了五个核心资源利用率指标的标准定义、采集方式以及告警触发后的典型排查方向。
| 指标名称 | 定义 | 采集方式 | 告警触发后的排查方向 |
|---|---|---|---|
| CPU使用率 | Executor JVM进程及系统进程占用CPU的百分比 | YARN / Kubernetes Metrics API / top | 数据倾斜、线程阻塞、GC频繁 |
| 内存使用率 | 堆内/堆外内存使用量占分配量的比例 | Spark UI / JVM Heap Dump / Prometheus | OOM风险、缓存溢出、序列化膨胀 |
| 磁盘IO | 磁盘读写吞吐量（MB/s）及IOPS | iostat / Node Exporter / CloudWatch | Shuffle落盘过多、中间结果溢出 |
| 网络吞吐量 | 节点间数据交换的带宽利用率 | iftop / YARN Network Metrics / CNI | Shuffle瓶颈、数据本地性差 |
| Executor数量与负载 | 活跃Executor个数、每个Executor上并发Task数 | Spark UI / ResourceManager API | 资源分配不合理、任务调度延迟 |
实战建议：不要对单一指标设置孤立阈值。例如CPU使用率低但内存使用率高，往往意味着GC瓶颈；磁盘IO高但网络吞吐量低，说明数据本地性较好但Shuffle落盘量过大。多指标联合分析才能准确定位根因。
3.2 指标关联关系与典型异常模式
下图展示了五个指标在Spark作业运行过程中的典型关联关系。箭头方向表示“可能导致”或“伴随出现”的关系。
3.3 阈值调优步骤与基线建立
建立合理的告警阈值需要遵循“采集基线 → 识别波动 → 设定边界 → 动态调整”的闭环流程。以下是标准操作步骤：
- 采集历史基线：收集过去7~30天作业运行时的资源利用率数据，剔除异常作业（如失败、超时）后计算P50/P75/P95分位值。
- 识别波动范围：观察指标在正常作业中的波动幅度。例如CPU使用率在ETL作业中通常稳定在60%~80%，而Ad-Hoc查询可能从10%到90%剧烈波动。
- 设定初始阈值：以P95分位值作为告警阈值下限，以P99或最大值作为严重告警阈值。例如：CPU使用率P95=75%，则告警阈值设为80%，严重告警设为90%。
- 动态调整：每两周复盘告警触发记录，将误报率高于20%的阈值放宽5%~10%，将漏报率高于5%的阈值收紧5%~10%。
基线示例：某实时流处理作业的典型基线为：CPU使用率55%~70%，内存使用率65%~80%，磁盘IO 80~120 MB/s，网络吞吐量 200~350 Mbps，Executor数量固定为32个，每个Executor负载为4~6个并发Task。若某时刻CPU突增到92%且内存使用率同步升至88%，则大概率是数据倾斜或GC压力过大。
3.4 Executor数量与负载的调优策略
Executor数量与负载是资源利用率调优的“总开关”。数量过多会导致调度开销增大，数量过少则无法充分利用集群资源。下表给出了不同场景下的推荐配置与告警阈值。
| 场景 | 推荐Executor数量 | 每个Executor核心数 | 每个Executor内存 | 负载告警阈值 |
|---|---|---|---|---|
| 批处理ETL（大Shuffle） | 集群总核心数 ÷ 4~5 | 4~5 | 8~16 GB | 并发Task数 > 核心数×2 |
| 实时流处理（低延迟） | 集群总核心数 ÷ 2~3 | 2~3 | 4~8 GB | 并发Task数 > 核心数×1.5 |
| Ad-Hoc查询（高并发） | 集群总核心数 ÷ 1~2 | 1~2 | 2~4 GB | 并发Task数 > 核心数×3 |
避坑提醒：不要盲目增加Executor数量。当Executor数量超过集群总核心数时，操作系统调度开销会急剧上升，反而导致CPU使用率虚高但有效计算能力下降。建议通过Spark UI的“Scheduling Delay”指标判断是否存在调度瓶颈。
3.5 磁盘IO与网络吞吐量的联合调优
磁盘IO和网络吞吐量在Shuffle阶段表现最为敏感。下图展示了Shuffle过程中磁盘与网络的交互关系，以及告警阈值设置的关键位置。
在Shuffle阶段，磁盘IO写速率和网络吞吐量通常呈正相关。若磁盘IO写速率超过200 MB/s但网络吞吐量低于集群带宽的30%，说明数据本地性差或网络存在瓶颈；若网络吞吐量高但磁盘IO读速率低，则可能是Reduce端拉取数据后未及时落盘，存在内存压力。
3.6 告警阈值推荐初始值
以下是一组经过多个生产环境验证的初始告警阈值，适用于大多数Spark批处理和流处理作业。请根据实际集群规模和作业类型进行微调。
| 指标 | 警告阈值 | 严重阈值 | 持续时长 | 评估周期 |
|---|---|---|---|---|
| CPU使用率 | > 85% | > 95% | ≥ 5分钟 | 1分钟 |
| 内存使用率 | > 80% | > 90% | ≥ 3分钟 | 30秒 |
| 磁盘IO（写） | > 150 MB/s | > 250 MB/s | ≥ 2分钟 | 30秒 |
| 网络吞吐量 | > 集群带宽的60% | > 集群带宽的85% | ≥ 3分钟 | 1分钟 |
| Executor负载（并发Task数） | > 核心数×2.5 | > 核心数×4 | ≥ 2分钟 | 30秒 |
调优口诀：CPU高看倾斜，内存高看GC，磁盘高看Shuffle，网络高看本地性，Executor多则调度乱，负载高则Task挤。记住这五句话，资源利用率调优不再难。