1. 课程导论与背景：为什么需要闲置资源回收？

各位同学好，我是老赵。在数据平台这个领域摸爬滚打了十来年，今天咱们来聊一个「既痛又痒」的话题——闲置资源回收。

你可能会问：资源嘛，多分配一点不是更稳当？万一不够用怎么办？

嗯，这个想法我刚开始做运维时也有。直到有一次，我看着监控大屏上那一片「浅蓝色」的 CPU 利用率曲线，突然意识到一个问题：我们花了几百万买的服务器，大部分时间都在「摸鱼」。

1.1 数据平台资源浪费的现状

先看一组我自己的真实数据。去年我负责的一个中型 Hadoop 集群，总共 120 台节点。我花了一周时间，把过去 3 个月的资源使用情况拉出来做了个分析。

资源类型	总量	平均利用率	峰值利用率	闲置比例
CPU	4800 核	23%	67%	约 35%
内存	38.4 TB	41%	82%	约 25%
HDFS 存储	2.4 PB	52%	58%	约 30%
YARN 容器	2400 个	18%	55%	约 45%

看到这个表，你什么感觉？

CPU 平均利用率只有 23%，YARN 容器更是低到 18%。说白了，我们花大价钱买的硬件，有将近三分之一是「白交电费」的。

为什么会这样？我总结了几点常见原因：

• 「多占少用」的潜规则：业务方申请资源时，习惯性按峰值再乘 1.5 倍。我见过一个离线任务，申请了 64GB 内存，实际只用 8GB。
• 任务「僵尸化」：有些定时任务早就没人维护了，但调度系统还在每天按时启动。跑出来的数据没人看，占着资源不干活。
• 数据「只进不出」：HDFS 上的临时表、中间结果，用完就扔在那里。我清理过一个项目，光 90 天前的临时数据就占了 200TB。
• 集群「过度建设」：为了应对双十一这类大促，集群规模按峰值扩容。但大促一过，资源就空转着。

1.2 成本分析：闲置资源到底烧了多少钱？

咱们来算一笔账。还是拿我那 120 台节点的集群举例。

每台服务器硬件成本（按 3 年折旧）：约 8 万元/台。120 台就是 960 万。每年电费、机柜、网络、空调：约 120 万/年。运维人力成本（3 人）：约 150 万/年。

总成本：960 万（硬件）+ 120 万×3（电费）+ 150 万×3（人力）= 1770 万（3 年）。

按闲置比例 30% 算，3 年白白浪费了 531 万。

你想想看，这 531 万如果省下来，能干多少事？

• 再买 60 台新服务器，支撑新业务
• 升级网络设备，把带宽翻一倍
• 给团队发奖金，招更多牛人

我在项目中遇到过最夸张的一次：一个客户的 Spark 集群，总共 500 台节点。我上去一看，有个用户的流式任务申请了 200 个 executor，每个 executor 8 核 32GB。但实际上，这个任务每秒处理的数据量不到 100 条。我帮他调优后，只用了 20 个 executor，效果完全一样。光这一个任务，每年就省了 80 多万的云资源费用。

1.3 闲置资源的「隐形杀手」效应

除了直接的经济损失，闲置资源还有几个更隐蔽的危害：

1. 拖慢真正重要的任务：资源被僵尸任务占着，核心业务任务反而要排队。我见过一个实时报表任务，因为资源被离线任务抢走，延迟从 5 分钟飙升到 2 小时。
2. 增加运维复杂度：集群里跑着几百个「不知道干嘛用」的任务，出问题时排查链路极其痛苦。我曾经花了两天时间，才找到一个「幽灵任务」的源头——一个离职员工留下的测试脚本。
3. 降低团队信任度：业务方发现「申请资源很容易，但任务跑得越来越慢」，就会对平台失去信心。最后大家都去搞独立集群，资源碎片化更严重。

1.4 本章知识体系总览

下面这张图，是我对整门课程知识体系的一个梳理。你可以把它当作一张「地图」，后面每章都会对应到其中的一个模块。

这张图把整个课程分成了 5 个层级：

• 识别层：怎么找到闲置资源？用什么指标衡量？
• 分类层：计算、存储、任务，各自的特点和回收策略不同。
• 手段层：动态调度、生命周期管理、任务治理、成本计费，四管齐下。
• 运营层：不是一次性的活动，要建立持续运营机制。
• 目标层：最终实现降本增效。

后面的课程，我会带着你一步步深入每个层级。咱们先从最基础的「识别」开始，再到具体的回收手段，最后落地成一套可执行的运营体系。