📚 课程目录第3章报表环境概念

3. 报表环境概念：报表系统的组成与审计要求

报表环境是审计回放的基础载体。一个完整的报表系统由四个核心层构成：数据源、ETL、报表引擎和前端展示。审计对报表环境的要求，本质上是确保每一层的数据流转可追溯、可验证、可复现。

3.1 报表系统的四层组成

层级	核心组件	审计关注点
数据源	关系型数据库（MySQL、PostgreSQL）、日志文件、API 接口、消息队列	数据完整性、时间戳精度、源端变更记录
ETL	数据抽取、清洗、转换、加载（如 Go 编写的 ETL 管道）	转换逻辑版本、异常处理记录、增量/全量标识
报表引擎	计算引擎（OLAP、内存聚合）、调度器、缓存层	计算一致性、调度时间戳、缓存失效策略
前端展示	Web 仪表盘、移动端、PDF 导出、邮件推送	渲染时间、用户操作日志、导出文件哈希

  关键理解： 审计回放不是简单重跑 SQL，而是沿着“数据源 → ETL → 引擎 → 展示”这条链路，逐层比对状态快照与操作日志。

3.2 报表系统架构图

下图展示了报表系统的四层架构及数据流向，审计回放需要覆盖每一层的输入、输出与中间状态。

3.3 审计对报表环境的核心要求

审计基线要求报表环境具备以下五个能力，缺一不可：

可追溯性：每一张报表必须能追溯到原始数据行、ETL 任务实例、引擎计算版本和前端渲染快照。
可复现性：给定同一时间窗口的数据源快照和相同配置，必须能复现出完全一致的报表结果。
不可篡改性：数据源、ETL 中间结果、引擎输出和展示内容，均需记录哈希或签名，防止事后修改。
时间一致性：四层之间使用统一的时间源（NTP 同步），确保回放时时间轴对齐。
异常可观测：ETL 失败、引擎超时、缓存穿透等异常事件必须记录结构化日志，供回放时注入故障场景。

实践建议： 在 Go 报表系统中，建议为每个 ETL 任务生成全局唯一 ID（如 ULID），并在引擎层和展示层透传该 ID，形成端到端的审计链路。

3.4 审计要求与报表层级的映射关系

审计要求	数据源	ETL	报表引擎	前端展示
可追溯性	binlog / WAL 日志	任务实例 ID + 输入输出行数	计算计划快照	渲染 DOM 快照
可复现性	数据源快照文件	ETL 脚本版本 + 参数	引擎配置 + 缓存策略	模板版本 + 数据绑定
不可篡改性	源端校验和	中间结果 SHA256	输出结果哈希链	导出文件数字签名
时间一致性	NTP 同步时间戳	任务开始/结束时间	调度触发时间	用户访问时间
异常可观测	连接失败日志	转换异常堆栈	OOM / 超时记录	渲染错误详情

3.5 审计回放的数据流模型

在 Go 报表环境中，审计回放的数据流可以抽象为以下管道模型，每个阶段都保留输入与输出的不可变记录：

// Go 审计回放管道抽象示例
type AuditReplayPipeline struct {
    SourceSnapshot   []byte    // 数据源快照（压缩后）
    ETLScriptHash    string    // ETL 脚本的 SHA256
    EngineConfigHash string    // 引擎配置的 SHA256
    TemplateHash     string    // 前端模板的 SHA256
    ReplayTimestamp  time.Time // 回放基准时间
}

// 每个阶段输出均记录哈希
type StageOutput struct {
    StageName string
    Output    []byte
    Checksum  string // SHA256
    Duration  time.Duration
}

常见误区： 审计回放不等于重新执行一次报表生成。必须使用与原始环境相同版本的数据源快照、ETL 脚本、引擎配置和模板，否则回放结果与原始结果之间的差异无法归因。

3.6 报表环境审计基线的检查清单

✅ 数据源是否开启变更数据捕获（CDC）并保留至少 7 天日志？
✅ ETL 任务是否记录每次执行的输入行数、输出行数、异常行数？
✅ 报表引擎是否支持按时间戳回放指定计算计划？
✅ 前端展示是否保留每次渲染的原始数据绑定 JSON？
✅ 四层之间是否使用统一的 NTP 时间源？
✅ 关键输出是否生成不可变哈希并持久化存储？