/%E6%89%B9%E9%87%8F%E5%A4%84%E7%90%86/ Recent content in 批量处理 on 老张开工了 Hugo zh-cn Sat, 11 Apr 2026 00:00:00 +0000 /posts/2026/04/etl-batch-scheduling/ Sat, 11 Apr 2026 00:00:00 +0000 /posts/2026/04/etl-batch-scheduling/ 为什么需要批量处理 ETL 的本质是数据的搬移和转换。当数据量达到一定规模后，逐条处理就不再可行。不管是每天几百万条订单记录，还是每小时数 GB 的日志文件，批量处理都是数据工程的基础操作方式。 批量处理的核心思路很简单：把数据分成一个个批次，每个批次作为一个整体来处理。这样做的好处很明显： 吞吐量高：一次处理一批数据，而不是一条一条来 资源利用好：可以集中分配计算和存储资源 可恢复性强：一个批次失败不会影响其他批次 成本可控：按批处理，容易预估时间和开销 举一个实际的例子。假设你每天凌晨需要把前一天的所有订单从业务数据库同步到数据仓库。如果逐条同步一百万条订单，每条都在 10 毫秒，总耗时超过 2.5 小时；但如果用批量方式，每次插入一万条，网络往返次数从一百万次减少到一百次，整个流程可能十几分钟就完成了。 调度策略的三种模式 调度就是决定"什么时候跑哪个任务"。在 ETL 场景中，调度策略主要分三种。 时间驱动调度 最简单也最常用的方式。规定好时间，到点就执行。常见的形式有： 固定间隔：每 5 分钟跑一次增量抽取 定时执行：每天凌晨 3 点跑全量刷新 日历触发：每月 1 号跑月度汇总 时间驱动的优点是实现简单，依赖少。缺点是不够灵活——你无法感知上游数据是否准备好，如果上游系统故障导致数据延迟到达，定时任务可能跑了个空。 事件驱动调度 不是看时间，而是看条件。当某个事件发生时触发执行。事件可以是： 文件到达：监控某个 FTP 目录，新文件出现就触发处理 消息通知：上游系统发送一条 Kafka 消息，通知数据已就绪 API 回调：第三方系统通过 Webhook 通知数据变更 数据库变更：CDC 工具捕获到变更后触发后续流程 事件驱动的优势是反应迅速，不会浪费计算资源跑空任务。缺点是引入事件中间件会增加系统复杂度，而且事件丢失后需要有补偿机制。 依赖驱动调度 任务之间有关系。B 必须在 A 完成后才能跑，C 必须等 A 和 B 都完成。这种"先做这个，再做那个"的编排方式就是依赖驱动调度。 依赖驱动的典型实现是 DAG（有向无环图）。每个任务是一个节点，任务之间的依赖关系是边。调度引擎按照 DAG 的拓扑顺序执行任务，保证每个任务只在其所有前置依赖完成后才启动。 Cron 表达式与定时任务 Cron 是 Linux 世界最经典的定时任务工具。几乎所有调度框架都兼容 cron 表达式。来看一个基本的 cron 格式：