1. 离线实时资源统一管控概述

做资源管控这些年，我见过太多团队在离线资源和实时资源上各自为战。说白了，就是两套班子、两套工具、两套运维流程，最后出了问题互相甩锅。今天咱们就把这事掰扯清楚。

什么是离线资源

离线资源，指的是那些非实时、批量处理的计算和存储资源。我习惯把它理解成「晚上跑批的那堆东西」。

• 典型场景：T+1 报表、历史数据清洗、模型训练、日志归档
• 资源特征：任务有明确的开始和结束时间，对延迟不敏感，但吞吐量要求高
• 常见组件：Hadoop/Spark 集群、Hive 表、离线数仓、批量调度引擎

举个例子。我在上一家公司做数据平台时，每天凌晨 2 点有 3000 多个离线任务同时启动。那时候集群 CPU 直接飙到 95%，但没人管——反正白天没人用。这就是离线资源的典型用法：跑完就释放，不抢实时业务的道。

什么是实时资源

实时资源，就是那些秒级甚至毫秒级响应的计算和存储资源。说白了，用户在前端点一下，后台得立刻给结果。

• 典型场景：实时风控、在线推荐、监控告警、实时大屏
• 资源特征：7×24 小时持续运行，对延迟极其敏感，资源占用相对稳定
• 常见组件：Flink 流处理集群、Kafka 消息队列、Redis 缓存、实时数仓

我记得有一次，实时风控集群因为离线任务抢走了 CPU，导致单条交易审核延迟从 50ms 涨到了 2 秒。业务方直接炸了——每多等一秒，就可能放走一笔欺诈交易。嗯，这就是实时资源的底线：谁也别碰我的延迟。

维度	离线资源	实时资源
响应要求	分钟~小时级	毫秒~秒级
运行模式	批处理，有起止	流处理，持续运行
资源波动	波峰波谷明显	相对平稳
故障影响	次日数据延迟	线上业务受损
典型组件	Hadoop/Spark/Hive	Flink/Kafka/Redis

为什么需要统一管控

你想想看，如果离线资源和实时资源各管各的，会出现什么问题？

问题一：资源争抢

离线任务白天跑，实时任务也白天跑。集群就那么点资源，谁抢到算谁的。我在项目中遇到过，离线 Spark 任务直接把实时 Flink 任务的 slot 全占了，结果实时数据延迟报警响了一整夜。

问题二：利用率低下

离线集群晚上忙死，白天闲死。实时集群正好反过来。但两套集群物理隔离，资源没法互相借调。说白了，就是一边饿死，一边撑死。

问题三：运维成本翻倍

两套监控、两套告警、两套扩缩容策略。运维团队得同时维护两套技能栈。我见过一个团队，离线用 YARN，实时用 Kubernetes，出了问题得两个方向的工程师一起排查——效率极低。

问题四：数据一致性难保证

离线算一套结果，实时算一套结果，两边对不上。业务方问「到底信谁的？」——这个问题我至少被问过 20 次。

核心挑战

统一管控说起来简单，做起来全是坑。我列几个最头疼的：

1. 资源隔离怎么做？——既要保证实时任务的延迟不受干扰，又不能把离线任务饿死。硬隔离浪费资源，软隔离又怕被突破。
2. 调度策略怎么定？——离线任务可以排队，实时任务不能等。优先级怎么动态调整？抢占式调度会不会导致离线任务频繁失败？
3. 弹性扩缩容怎么实现？——离线任务高峰期需要临时借调资源，用完还得还回去。这个过程要自动化，不能靠人工半夜起来加节点。
4. 监控和告警怎么统一？——两套指标口径不同，怎么合并到一个视图里？告警阈值怎么设？实时任务的延迟告警和离线任务的失败告警哪个优先级更高？
5. 成本怎么分摊？——统一管控之后，资源是共享的。离线部门和实时部门怎么算账？按使用量？按优先级？还是按时间段？

核心目标

统一管控不是要把两套东西硬捏在一起，而是要实现以下几个目标：

• 资源利用率最大化——让空闲的资源能被另一方借调，减少物理集群的浪费
• 服务质量保障——实时任务的延迟 SLO 必须守住，离线任务的完成时间也要可预期
• 运维复杂度降低——一套管控平台、一套监控体系、一套扩缩容策略
• 成本透明可追溯——每个部门用了多少资源，花多少钱，一目了然
• 数据一致性——离线和实时计算的结果能对上，不再出现「两套数」的尴尬

说白了，统一管控的终极目标就一句话：让离线和实时在同一个资源池里和谐共处，各取所需，互不干扰。

知识体系总览

下面这张图，是我梳理的离线实时资源统一管控的整体框架。你可以把它当成这门课的地图。

这张图把整个知识体系分成了四层。顶层是目标，第二层是三大支柱，第三层是关键能力，底层是技术组件。后面的课程，我们会一层一层往下拆解。

嗯，第一章就到这里。记住一句话：统一管控不是技术问题，是架构思维问题。想清楚了再动手，比上来就写代码重要得多。