1. 批处理基础概念
什么是批处理
批处理，说白了就是「攒一批，一起干」。
你想想看，如果快递员每收到一个包裹就立刻送一趟，一天得跑几十趟。但要是等包裹攒够一车，再集中送一趟，效率就高多了。批处理就是这个道理——把多个任务攒起来，一次性处理完。
在计算机世界里，批处理是指将一组数据或任务收集起来，在某个时间点统一执行。数据不要求实时到达，处理结果也不要求立刻返回。系统只管埋头干活，把这一批全部搞定。
我刚开始接触批处理时，觉得这玩意儿太简单了。不就是循环遍历嘛。后来在项目中踩过坑才明白，批处理的难点不在于「批」，而在于「怎么批」——批次大小怎么定？失败任务怎么重试？数据倾斜怎么处理？这些才是真正考验人的地方。
- 数据是静态的、有界的——处理前数据已经全部到位
- 延迟较高——从提交到出结果，可能需要几秒、几分钟甚至几小时
- 吞吐量高——批量操作能充分利用系统资源
- 适合离线场景——不要求实时响应
批处理 vs 流处理
很多人搞不清批处理和流处理的区别。我简单画个对比，你就明白了。
我整理了一个表格，把关键差异列出来，方便你对照。
| 对比维度 | 批处理 | 流处理 |
|---|---|---|
| 数据特征 | 有界、静态 | 无界、持续 |
| 处理时机 | 数据到齐后触发 | 数据到达即处理 |
| 延迟 | 高（分钟~小时） | 低（毫秒~秒） |
| 吞吐量 | 高 | 中等 |
| 资源消耗 | 集中爆发 | 持续平稳 |
| 容错方式 | 重跑整个批次 | 状态回溯+重放 |
| 典型场景 | 离线报表、ETL、数据清洗 | 实时监控、风控、推荐 |
批处理的应用场景
批处理不是过时的技术。恰恰相反，在大数据时代，批处理依然是数据工程的核心支柱。我列几个最常见的场景。
1. 离线数据 ETL
这是批处理最经典的应用。每天凌晨，把业务数据库的数据抽取出来，清洗、转换、加载到数据仓库。为什么选在凌晨？因为业务系统负载低，数据也完整了——当天的交易都结束了。
-- 一个典型的批处理 ETL 任务（伪代码）
-- 每天凌晨 2:00 执行
CREATE TABLE dwd_order_daily AS
SELECT
order_id,
user_id,
product_id,
amount,
status,
create_time
FROM ods_order
WHERE dt = '${yesterday}'
AND status IN ('paid', 'completed');2. 大规模数据计算
有些计算量太大，实时搞不定。比如全量用户画像、商品推荐模型的离线训练、历史数据的聚合分析。这些任务跑一次可能要几十分钟甚至几小时，但结果可以复用很久。
我记得有个项目，需要计算过去三年所有用户的购买行为特征。数据量几百 TB，如果用流处理逐条算，光状态维护就能把集群撑爆。最后还是老老实实跑批处理，MapReduce 分而治之，跑了两个多小时，但结果一次到位。
3. 报表与对账
财务系统对数据准确性要求极高。一分钱都不能差。流处理虽然快，但万一丢了一条消息，对账就对不上了。批处理可以保证「要么全做，要么全不做」，出错了整个批次重跑，数据一致性有保障。
4. 数据迁移与备份
把数据从一个存储系统搬到另一个，或者做全量备份。这种场景天然适合批处理——数据是完整的、有界的，不需要实时性。用批处理工具（比如 Sqoop、DataX）一把梭，又快又稳。
5. 定时任务与调度
很多业务逻辑不需要实时触发。比如每天给用户发推送、每周生成运营周报、每月结算佣金。这些任务用批处理调度框架（比如 Azkaban、Airflow）来编排，依赖清晰，重试方便。
批处理的核心流程
不管什么场景，批处理都遵循一个基本流程。我画了张图，帮你建立整体认知。
这个流程看着简单，但每个环节都有坑。数据采集阶段要考虑数据源的稳定性，清洗阶段要处理脏数据，计算阶段要防止数据倾斜，输出阶段要保证幂等性。后面几章我会逐个展开讲。