一、调度系统概述：实时调度与离线调度的定义、区别与联系

各位同学好，我是老赵。今天咱们正式开讲《实时与离线调度任务混合编排实战》的第一章。

调度系统，说白了就是「谁在什么时候干什么活」的一套机制。你想想看，一个稍微复杂点的业务系统，背后少说几十个任务在跑。有的任务必须秒级响应，有的任务拖到半夜跑完就行。这两种任务放在一起，怎么管？这就是咱们这门课要解决的核心问题。

我个人习惯先把概念掰扯清楚，再动手。所以这一章，咱们先把实时调度和离线调度的定义、区别、联系，以及混合编排的应用场景，一个一个说透。

1.1 什么是实时调度？

实时调度，指的是任务必须在严格的时间约束内完成。超时了，就算失败。

举个例子：你在电商平台下单，系统需要立刻扣减库存、生成订单、推送消息给仓库。这个流程如果超过 3 秒，用户可能就关页面了。更极端的场景——股票交易系统，订单撮合延迟超过 10 毫秒，可能就亏钱了。

我在项目中遇到过最典型的实时调度场景，是物联网设备的告警处理。设备上报温度异常，系统必须在 500 毫秒内触发告警并通知运维人员。晚一秒，设备可能就烧了。

1.2 什么是离线调度？

离线调度，任务没有严格的实时性要求。你只要在某个时间窗口内跑完就行，早一点晚一点问题不大。

最常见的例子就是大数据平台的 ETL 任务。每天凌晨 2 点，把昨天的业务数据从 MySQL 同步到 Hive，然后跑一堆清洗、聚合、统计的脚本。早上 8 点前出报表就行。跑得快，3 点完事；跑得慢，6 点完事，都行。

我记得刚入行那会儿，公司有个离线调度系统，每天夜里跑几百个数据同步任务。有一次某个任务卡住了，导致后续任务全部排队。结果第二天早上报表没出来，业务部门追着问。后来我加了个「任务依赖超时告警」，才算消停。

1.3 实时调度 vs 离线调度：一张表说清楚

很多同学容易把这两个概念搞混。我直接列个对比表，你一看就明白。

你看，这两者从触发方式到失败处理，完全是两套逻辑。但现实系统中，它们往往共存。

1.4 实时与离线的联系：不是非此即彼

有人觉得实时和离线是水火不容的。其实不是。它们之间有很多联系。

第一，数据流是连续的。 实时任务处理的是「当前时刻」的数据，离线任务处理的是「历史时段」的数据。但数据本身是同一个来源。比如用户点击行为，实时任务用来做推荐，离线任务用来做用户画像分析。

第二，离线任务依赖实时任务的产出。 我做过一个项目，实时任务把清洗后的数据写入 Kafka，离线任务每天凌晨从 Kafka 拉取数据做批量聚合。没有实时任务的预处理，离线任务根本跑不起来。

第三，实时任务需要离线任务的模型支撑。 比如实时风控系统，它用的规则模型是离线任务每天凌晨训练好、推送到线上的。没有离线训练的模型，实时判断就是瞎猜。

1.5 混合编排的应用场景

讲完了概念，咱们聊聊实际场景。混合编排，就是把实时任务和离线任务放在同一个调度系统里统一管理。为什么要这么做？

场景一：实时数据入湖 + 离线批量分析

实时任务把业务数据流式写入数据湖（比如 Delta Lake、Iceberg），离线任务每天凌晨对湖里的数据做全量校验、分区合并、历史回溯。两个任务共享同一个数据源和调度平台，避免数据口径不一致。

场景二：在线推理 + 离线模型训练

实时任务负责在线推理（比如推荐、风控），离线任务负责模型训练和评估。训练完成后，离线任务自动触发模型上线，实时任务热加载新模型。整个流程在一个调度系统里编排，省去人工干预。

场景三：实时告警 + 离线根因分析

实时任务监控系统指标，触发告警后，自动拉起一个离线分析任务，去查历史日志、做根因定位。告警和分析是联动的，但一个是实时响应，一个是离线计算。混合编排让这个联动变得自然。

场景四：实时流处理 + 离线回溯修正

实时流处理难免有数据延迟或乱序。离线任务可以在第二天对前一天的数据做回溯修正，把修正结果写回在线存储。实时任务读取修正后的数据，保证最终一致性。

1.6 本章知识体系总览

说了这么多，咱们用一张图把本章的知识结构串起来。这张图是我自己画的，你一看就能理解实时调度、离线调度和混合编排的关系。

这张图把咱们这一章的核心内容都串起来了。从上往下看：实时调度和离线调度各有各的特征，中间通过数据流、依赖关系、模型支撑等衔接点联系起来，最终汇聚到混合编排这个统一调度平台上，支撑四大典型应用场景。