4. 批处理基础

在银行核心系统中，日终EOD（End of Day）并不是一个单一动作，而是一组围绕“账务封账、利息计提、总分核对、报表生成”等目标组织起来的批处理作业集合。理解批处理，是理解整个EOD流程的起点。本节从批处理的定义出发，逐步展开作业调度、依赖关系以及串行与并行两种处理模式，帮助你在实战中判断“哪些作业必须等、哪些可以同时跑”。

一、批处理定义：从“逐笔交互”到“批量成组”

批处理（Batch Processing）是指将一批数据或一组任务集中收集，在无需人工逐笔干预的情况下，由系统按预定规则自动、连续地执行处理。与联机交易（OLTP）强调实时响应不同，批处理强调吞吐量、顺序性和可重跑性。在银行场景中，批处理通常具备以下特征：

• 数据成组：以账户、机构、产品等维度批量读取，而非单笔请求。
• 时间窗口：多安排在营业结束后至次日开门前，对时间窗口敏感。
• 状态可追踪：每个作业有明确的开始、结束、成功、失败状态。
• 可重跑与幂等：失败后能安全重跑，不产生重复记账。

一个典型的批处理作业在日志中会留下清晰的生命周期痕迹，例如：

2024-06-30 23:10:02 [EOD] JOB=INT_ACCRUAL START
2024-06-30 23:10:02 [EOD] PARAM: BIZ_DATE=20240630, BRANCH=ALL
2024-06-30 23:12:45 [EOD] READ=1284300, WRITE=1284300, SKIP=0
2024-06-30 23:12:46 [EOD] JOB=INT_ACCRUAL END STATUS=SUCCESS

从这段日志可以看出，批处理作业不仅有业务参数（BIZ_DATE），还有处理量统计（READ/WRITE/SKIP），这些是后续排障与对账的关键依据。

二、作业调度：谁在什么时间触发什么

作业调度（Job Scheduling）解决的是“何时、以何种顺序、由谁触发”的问题。银行EOD调度通常由调度平台（如Control-M、Autosys或自研调度器）统一管理，核心要素包括：

• 触发方式：定时触发（如23:00）、事件触发（前置作业完成）、手动触发（应急补跑）。
• 调度日历：区分工作日、节假日、月末、季末，不同日历对应不同作业集。
• 优先级与资源池：高优先级作业优先占用计算资源。
• 超时与告警：作业超过预期时长触发告警，避免拖垮整个窗口。

三、依赖关系：批处理作业的“先后秩序”

依赖关系（Dependency）决定了作业之间的执行顺序。常见依赖类型包括：

依赖关系如果设计不当，最容易出现两类问题：一是循环依赖，导致调度器无法确定执行顺序；二是隐式依赖，即代码中实际存在先后要求，但调度配置中未声明，结果在并行时出现数据错乱。

四、串行与并行处理模式：效率与安全的权衡

串行（Serial）与并行（Parallel）是批处理中最基本的两种执行模式。串行指作业按严格顺序一个接一个执行，优点是逻辑简单、资源冲突少、易于对账；缺点是整体耗时长。并行指多个作业或同一作业的多个分片同时执行，优点是缩短窗口时间；缺点是资源竞争、锁冲突和顺序不确定性增加。

在银行EOD中，常见的并行策略是按机构或账户分片并行，例如将全行账户按分行拆成多个分片，每个分片独立计提利息，最后统一汇总。下面是一个简化的分片并行示意：

JOB=INT_ACCRUAL
  SHARD=BR001 -> 处理账户 1~300000
  SHARD=BR002 -> 处理账户 300001~600000
  SHARD=BR003 -> 处理账户 600001~900000
  MERGE -> 汇总分片结果，校验总笔数与总金额

五、案例与复盘：一次“并行导致总分不平”的排障

某银行月末EOD中，利息计提作业被拆成4个分片并行执行，同时总分核对作业被配置为“等待计提作业整体完成”。上线后出现总分不平，差额恰好等于某个分行的计提金额。排查发现：计提作业的4个分片虽然都返回成功，但其中两个分片在写入汇总表时发生了更新覆盖，因为汇总表使用了“先查后改”的非原子操作。调度层面看依赖关系正确，但数据层面存在隐式互斥未声明。

复盘结论有三点：第一，并行分片必须保证写入目标互不重叠，或使用原子累加；第二，依赖关系不仅要看作业级，还要看数据级；第三，EOD作业必须提供分片级对账文件，便于快速定位差异来源。

总结来看，批处理基础并不只是“把作业跑起来”，而是围绕定义、调度、依赖和串并行模式建立一套可控、可查、可重跑的执行体系。只有把作业之间的先后秩序和数据边界讲清楚，EOD才能在有限窗口内既跑得快，又跑得稳。