4. 监管报送平台整体架构
监管报送平台不是“把数据导出来再传上去”的工具，而是一套面向监管口径、具备强审计属性的数据生产系统。它要同时满足三件事：数据算得准、过程可追溯、报送不超时。因此架构设计必须从分层、模块、选型、可用性与扩展性五个维度同时约束，任何一层缺失都会在报送高峰期暴露为生产事故。
一、核心原理：为什么必须分层
监管报送的本质是“把机构内部业务数据，按监管定义的指标口径，转换为可校验、可签章、可回执的报文”。这条链路横跨源系统、数据加工、规则校验、报文生成、通道传输与回执处理，各环节的变更频率完全不同：源系统接口随业务迭代，监管口径随发文更新，传输通道随监管机构要求调整。若不分层，任何一处变更都会引发全链路回归。
分层架构的核心价值在于隔离变更：接入层屏蔽源系统差异，加工层沉淀指标口径，报送层封装报文与通道，管控层统一审计与调度。层与层之间通过标准化的数据契约交互，上层不感知下层实现细节。
二、功能模块划分与职责边界
分层确定后，模块划分要遵循“单一职责 + 可独立部署”原则。以下清单是实战中经过验证的最小模块集：
| 模块 | 核心职责 | 关键输出 | 典型技术 |
|---|---|---|---|
| 数据采集 | 对接源系统，增量/全量抽取 | 贴源数据、采集日志 | DataX、Flink CDC |
| 指标加工 | 口径计算、汇总、衍生指标 | 指标结果表、血缘 | Spark SQL、Doris |
| 规则校验 | 监管校验、勾稽、阈值 | 校验报告、差错清单 | Drools、自研引擎 |
| 报文生成 | 模板渲染、签章、加密 | 报文文件、摘要 | FreeMarker、国密SDK |
| 通道传输 | 报送、重传、回执解析 | 回执、状态流水 | SFTP、MQ、HTTP |
| 调度管控 | 任务编排、依赖、重跑 | 调度实例、告警 | DolphinScheduler |
| 审计留痕 | 操作、数据、报文全留痕 | 审计日志、版本快照 | ELK、对象存储 |
三、技术选型的关键取舍
选型不是选最新，而是选与报送节奏匹配的。监管报送具有明显的周期性峰值：月末、季末、年末集中跑批，平时负载很低。因此计算引擎优先考虑弹性与批处理能力，而非纯流式。
# 典型调度依赖配置（DolphinScheduler 片段）
task:
name: east_report_generate
type: SHELL
depends:
- dws_indicator_calc
- rule_validate_pass
schedule:
cron: "0 30 2 1-10 * ?" # 每月1-10日 02:30 触发
retry:
times: 3
interval: 300
timeout: 7200存储层建议冷热分离：近 3 个月报送数据放高性能库支撑重跑与查询，历史报文与审计日志转对象存储，降低成本。消息队列用于解耦采集与加工，避免源系统抖动传导至报送链路。
四、高可用与扩展性设计
高可用的核心不是“永不停机”，而是失败可恢复、状态可续跑。报送任务必须设计为幂等：同一批次重复执行不产生重复报文。调度层采用主备或集群模式，任务实例状态持久化，节点宕机后由其他节点接管。
- 计算高可用：Spark on YARN/K8s，Executor 失败自动重试，Checkpoint 保存中间状态。
- 传输高可用：通道双活，主通道失败自动切换备用通道，回执超时触发重传。
- 数据高可用：关键指标表多副本，报送前生成快照，支持按版本回溯。
- 扩展性：新增监管报表时，只新增规则配置与报文模板，不改动加工主链路。
五、场景复盘：一次月末报送超时的定位
某机构月末 1104 报送在 03:00 未完成，监控显示加工层卡在指标汇总。排查发现：新增一张报表的规则校验被错误地串行挂在汇总任务之后，导致汇总必须等待校验完成，而校验又依赖汇总结果，形成循环等待。根因是模块边界不清，校验与加工耦合。
修复方案：将校验拆为“加工前预校验”和“加工后终校验”两段，预校验只做格式与空值检查，不依赖汇总结果；终校验独立并行执行。调整后该批次提前 40 分钟完成。这个案例说明：架构分层不只是画图，而是要在调度依赖上真正落地。
综上，监管报送平台的架构设计应围绕“分层隔离变更、模块独立部署、选型匹配峰值、失败可续跑、扩展靠配置”五条原则展开。把这五点写进架构决策记录，后续每次监管发文更新时，团队都能快速判断改动落在哪一层、影响哪些模块，从而把报送风险控制在可预期范围内。