资源定义与分类：计算、存储、网络与Yarn队列
做资源回收，第一步不是写脚本，而是搞清楚你到底在回收什么。
我见过不少团队，上来就写个定时任务清空临时目录，结果把HDFS上正在写入的Checkpoint数据给删了。嗯，这种事故其实完全可以避免——只要你先把资源分类搞清楚。
这一章，我们就来拆解数据平台里的四大类资源：计算资源、存储资源、网络资源和Yarn队列资源。每一类我都结合自己的踩坑经历来讲，希望能帮你少走弯路。
核心观点：资源分类不是学术概念，而是回收策略的起点。分不清类型，就定不准回收阈值。
2.1 计算资源：CPU与内存
计算资源是数据平台最贵的资源，没有之一。你想想看，一台物理机几十万，上面跑的Spark、Flink任务，哪个不是在烧钱？
我个人习惯把计算资源分成两类来看：在线计算和离线计算。在线计算对延迟敏感，资源必须预留；离线计算则可以弹性伸缩，也是回收的重点对象。
CPU资源回收要点
- 闲置判定标准：连续15分钟CPU利用率低于5%的任务，基本可以判定为闲置。
- 常见浪费场景：Spark Streaming任务在无数据时段仍然占用vCore，这种我见过太多。
- 回收手段：动态调整executor数量，或者直接停掉空跑任务。
我的经验：曾经有个Flink任务，每天凌晨3点到6点完全没有数据流入，但一直占着20个vCore。后来我加了水位线检测，无数据时自动缩容到2个vCore，一个月省了将近3000元的计算成本。
内存资源回收要点
内存比CPU更难回收。为什么？因为内存是独占的，一旦分配出去，其他任务就拿不到。我遇到过最夸张的情况：一个Spark任务申请了200G内存，实际只用不到30G，剩下的全浪费了。
- 内存利用率监控：重点关注堆内内存和堆外内存的使用比例。
- 回收策略：对长期内存利用率低于40%的任务，强制降低spark.executor.memory配置。
- 避坑：不要一次性回收太多，否则可能导致任务OOM。建议每次减少10%-20%，观察稳定后再继续。
我曾经踩过的坑：有一次我直接把一个任务的executor内存从8G降到2G，结果任务跑了半小时就OOM了。后来学乖了，用spark.dynamicAllocation.enabled=true配合spark.dynamicAllocation.minExecutors来做渐进式回收。
2.2 存储资源：HDFS与对象存储
存储资源是数据平台的“不动产”。一旦数据写进去，很少有人主动去删。我见过一个HDFS目录，里面存了3年前的临时表，占用超过10TB，居然没人敢删——因为没人知道还有没有人在用。
HDFS资源回收
| 资源类型 | 闲置判定标准 | 回收动作 |
|---|---|---|
| 临时表/中间表 | 最后修改时间 > 7天 | 移动到回收站，30天后自动清理 |
| 日志文件 | 最后访问时间 > 30天 | 压缩归档或删除 |
| 快照/备份 | 保留超过90天 | 按策略保留最近3份，其余删除 |
| 测试数据 | 无关联任务超过14天 | 通知owner确认后清理 |
这里有个细节：HDFS上的小文件问题。大量小文件不仅浪费NameNode内存，还会拖慢任务执行。我建议在回收存储时，顺手把小文件合并一下——hadoop archive或者Spark的coalesce都能干这事。
对象存储资源回收
对象存储（比如S3、OSS、COS）的回收逻辑和HDFS不太一样。对象存储没有目录树的概念，所有文件都是扁平化的key-value。这意味着你不能简单地“扫目录”，得用ListObjects接口遍历。
- 生命周期策略：直接配置存储桶的生命周期规则，自动将冷数据转为归档存储或删除。
- 版本管理：开启版本控制后，旧版本文件会持续占用空间。建议设置非当前版本保留天数。
- 碎片文件：MultipartUpload失败产生的碎片，很多人会忽略。我建议每月清理一次。
关键指标：存储资源回收的核心指标是存储利用率和数据生命周期。利用率低于60%的存储集群，说明存在大量冷数据或冗余数据，需要立即启动回收流程。
2.3 网络资源
网络资源往往是被忽视的一类。大家总觉得带宽是“共享的”，不够用就加。但实际上一台物理机的网络带宽是有限的，如果被闲置连接占满，真正需要传输数据的任务反而会卡住。
我遇到过最典型的情况：某个数据同步任务，每天凌晨全量拉取数据，把机架间的带宽全部占满，导致其他实时任务延迟飙升。后来一查，发现这个任务根本不需要全量同步，增量同步就够了。
网络资源回收要点
- 闲置连接：长时间空闲的TCP连接，建议设置keepalive超时时间，超过阈值自动断开。
- 带宽占用：对数据同步、备份等大流量任务，限制其带宽上限，避免影响核心业务。
- 跨机房流量：跨机房数据传输成本极高，建议优先在同机房内完成数据聚合。
我的做法：在Yarn上配置网络带宽的cgroup限制，对非核心任务设置带宽上限。比如把数据备份任务的带宽限制在200Mbps以内，这样既不影响备份进度，也不会挤占实时任务的带宽。
2.4 Yarn队列资源
Yarn队列资源是数据平台资源管理的“最后一公里”。前面说的CPU、内存、存储，最终都会通过Yarn队列来分配和调度。我个人觉得，Yarn队列的闲置资源回收，是性价比最高的优化手段——因为改配置就能见效，不需要动代码。
Yarn队列资源模型
Yarn队列的核心参数就两个：最小资源和最大资源。最小资源是保证的，最大资源是上限。闲置资源回收，主要针对的是“申请了但没用”的部分。
| 参数 | 含义 | 回收策略 |
|---|---|---|
| minimum-capacity | 队列保证的最小资源比例 | 不回收，这是SLA底线 |
| maximum-capacity | 队列能使用的最大资源比例 | 可动态调整，闲置时降低上限 |
| user-limit-factor | 单个用户可占用的最大比例 | 建议设为1.0，防止单个用户占满队列 |
Yarn队列闲置判定
- 队列利用率：连续1小时利用率低于20%，判定为闲置队列。
- 应用等待时间：队列中有大量应用在等待资源，但利用率却很低——说明资源碎片化严重。
- 抢占成功率：如果抢占成功率长期为0，说明队列资源没有被充分利用。
我曾经犯过的错：有一次我直接修改了生产队列的maximum-capacity，从80%降到40%，结果下午业务高峰时，队列资源不够用，大量任务失败。后来我改成用Yarn的yarn.scheduler.capacity.scheduling-mode配合自动伸缩脚本，只在夜间闲置时段降低上限，白天自动恢复。
2.5 资源分类与回收策略对照表
最后，我把这四类资源的回收策略整理成一张对照表。你可以在实际工作中直接参考。
| 资源类型 | 闲置判定指标 | 回收手段 | 风险等级 |
|---|---|---|---|
| CPU | 利用率 < 5% 持续15分钟 | 缩容executor、停任务 | 中 |
| 内存 | 利用率 < 40% 持续30分钟 | 降低executor内存、启用动态分配 | 高 |
| HDFS | 最后修改时间 > 7天 | 归档、删除、合并小文件 | 低 |
| 对象存储 | 最后访问时间 > 30天 | 生命周期策略、碎片清理 | 低 |
| 网络带宽 | 连接空闲 > 10分钟 | 断开连接、限速 | 中 |
| Yarn队列 | 利用率 < 20% 持续1小时 | 动态调整maximum-capacity | 高 |
嗯，这张表我建议你打印出来贴在工位上。每次做资源回收前，先对照一下，别搞混了。