数据仓库批处理计算架构选型与落地 - 第1节
一、批处理概述：什么是批处理
批处理这个词，说白了就是「攒一批活儿，一次性干完」。
我刚开始工作时，有个老前辈跟我说过一句话，我一直记着：「能批量做的事，千万别一条一条做」。这句话几乎概括了批处理的核心思想。
从技术角度定义，批处理是一种非实时、周期性、数据驱动的计算模式。它把大量数据收集起来，在预定的时间窗口内，按照固定的流程统一处理。处理过程中通常不需要人工干预，跑完了给个结果就行。
批处理的三个核心特征：
- 非实时性：数据到达后不会立即处理，而是等待触发条件（时间、数据量、事件）
- 高吞吐量：一次处理百万、千万甚至亿级数据，追求的是「单位时间能处理多少」
- 确定性：同样的输入，永远得到同样的输出。这一点在金融、对账场景里极其重要
举个例子。银行每天凌晨跑批处理，把当天所有交易汇总、对账、生成报表。你白天刷卡时，系统只记录流水，不会立刻算你的余额——等凌晨批处理跑完，你的账户才真正更新。这就是典型的批处理。
二、批处理与流处理的区别
很多人搞不清批处理和流处理到底差在哪。我见过不少团队，上来就说「我们要上流处理」，结果业务场景根本不需要实时性，白白增加了系统复杂度。
咱们直接看对比：
| 维度 | 批处理 | 流处理 |
|---|---|---|
| 数据范围 | 有界数据（已知起止时间或数据量） | 无界数据（持续不断流入） |
| 延迟要求 | 分钟级到天级 | 毫秒级到秒级 |
| 处理模式 | 一次性处理全部数据 | 逐条或微批次处理 |
| 典型框架 | MapReduce、Spark Batch、Hive | Flink、Kafka Streams、Storm |
| 容错方式 | 重跑整个批次 | 状态快照 + 精确一次语义 |
| 适用场景 | ETL、报表、数据清洗、离线分析 | 实时监控、风控、推荐、IoT |
这里有个容易踩的坑。我曾经遇到一个项目，业务方说「我们要实时看到昨天的销售报表」。你想想看，昨天已经过去了，哪来的实时？这明显是批处理的活儿。后来我帮他们梳理清楚，每天凌晨跑一次批处理，生成报表后推送到BI系统，成本降了80%。
我的选型建议：
如果业务能接受分钟级以上的延迟，优先考虑批处理。批处理的架构简单、运维成本低、数据一致性容易保证。别为了「听起来高大上」硬上流处理。
三、批处理的应用场景
批处理的应用场景其实比你想的要多。我做了十几年系统，几乎每个公司都离不开批处理。下面说三个最常见的。
3.1 ETL（数据抽取、转换、加载）
ETL 是批处理的「头号玩家」。数据从业务库抽出来，经过清洗、转换，最后加载到数据仓库或数据湖里。
我参与过一个电商项目，每天要处理 2 亿条订单数据。原始数据存在 MySQL 里，但查询太慢。我们的做法是：每天凌晨用 Sqoop 把数据抽到 HDFS，然后用 Spark 做清洗和转换，最后加载到 Hive 表中。整个过程大概跑 40 分钟。
-- 一个典型的 ETL 批处理流程（伪代码）
-- Step 1: 抽取
sqoop import \
--connect jdbc:mysql://host/orders \
--table order_detail \
--target-dir /data/raw/orders/$(date +%Y%m%d)
-- Step 2: 转换（Spark SQL）
INSERT INTO dws.daily_order_summary
SELECT
order_date,
product_id,
SUM(amount) AS total_amount,
COUNT(DISTINCT user_id) AS user_count
FROM ods.order_detail
WHERE dt = '${yesterday}'
GROUP BY order_date, product_id;
-- Step 3: 加载
-- 结果已写入 Hive 表，BI 工具直接查询注意：ETL 过程中最容易出问题的是数据质量。我曾经遇到过源表字段类型变更，导致整个批次跑挂。建议在 ETL 流程中加入数据校验环节，比如记录数校验、金额汇总校验、空值率检查。
3.2 报表生成
报表生成是批处理的「老本行」。日报、周报、月报、季报、年报，几乎都是批处理跑出来的。
我记得有个金融客户，他们的报表系统每天要生成 300 多张报表。如果每张报表都实时查询数据库，数据库根本扛不住。我们的方案是：每天凌晨用批处理预计算所有报表数据，结果存到 Redis 或 MySQL 汇总表中。白天用户查看时，直接读预计算结果，毫秒级响应。
报表批处理的关键点：
- 分层计算：先算原子指标，再算派生指标，最后算复合指标
- 增量更新：大部分报表只需要处理增量数据，不用全量重算
- 结果缓存：预计算结果要设计好存储结构，方便快速查询
3.3 数据清洗
数据清洗听着简单，做起来最头疼。脏数据、重复数据、缺失数据、格式不一致……我见过最夸张的一个项目，原始数据里 30% 的记录都有问题。
批处理在数据清洗上的优势很明显：你可以写一套清洗规则，然后对全量数据统一执行。比如：
-- 数据清洗示例：处理手机号格式
UPDATE user_profile
SET phone = REGEXP_REPLACE(phone, '[^0-9]', '')
WHERE LENGTH(phone) != 11
OR phone NOT REGEXP '^1[3-9]\\d{9}$';我曾经踩过一个坑：清洗规则上线前没做充分测试，结果把一批正常数据也给洗坏了。后来我养成了一个习惯——任何清洗任务，先跑一次「预览模式」，只输出清洗前后的对比结果，确认无误后再执行真正的更新。
数据清洗的黄金法则：
- 保留原始数据副本，永远不要在原表上直接修改
- 清洗规则要可追溯，每条规则都要有版本号和生效时间
- 清洗结果要做抽样验证，不能只看总量
- 异常数据要单独落库，方便后续人工处理
四、批处理的核心知识体系
下面这张图是我自己总结的批处理知识体系，涵盖了架构选型时需要关注的核心维度。你可以把它当作后续学习的路线图。
这张图涵盖了批处理系统的四个核心维度。后续章节我们会逐一深入每个维度，包括具体的框架选型、架构设计、性能调优和落地实践。
嗯，第一章就到这里。批处理的概念、与流处理的区别、以及三个核心应用场景，这些是后续所有内容的基础。你先把这些理解透，后面讲架构选型时才能做出合理的判断。