数据仓库与 ETL 测试

• 字段映射清单
• 清洗规则
• 逐项断言

建立映射清单（Mapping Specification）是 ETL 测试的核心。清单包含：源字段→目标字段的映射、转换规则（类型转换、格式统一）、清洗规则（去空、去重、标准化、默认值、异常丢弃）、业务规则（计算公式、口径）。逐项断言：对每个字段或规则，构造对应的源数据作为输入，执行 ETL 后断言目标字段值符合规则。例如：源某字段为空时，断言目标为默认值；源格式非法时，断言按清洗规则处理或丢弃；金额计算时，断言目标等于规则计算值。映射清单应作为规范文档，且每个规则对应测试用例，实现"一规则一断言"，保证 ETL 逻辑与文档一致。

映射清单是 ETL 逻辑的"契约"。把它转化为可执行的断言，能确保每个转换/清洗规则都被测试覆盖，防止逻辑漏测或与文档漂移。逐项断言是 ETL 正确性验证的基石。

• 分层结构
• 行数对账
• 金额与主键唯一性对账

分层对账验证各层数据一致性。行数对账：对比 ODS 与 DWD 之间、DWD 与 DWS 之间的行数，验证经过过滤、去重、join 后的行数符合预期（如 DWD 行数 = ODS 去重后行数）。金额对账：对比各层金额字段的汇总（sum、count、去重后求和），验证金额不因分层转换而丢或增，允许口径内误差。主键唯一性对账：验证各层主键唯一性，DWD/DWS 的核心主键无重复（如订单 ID 唯一），对比主键集合在上下层间一一对应。对账方式：用 SQL 对 count(*)、sum(amount)、count(distinct key) 做跨层比较，或用专门对账工具。对账不通过说明分层逻辑有误（丢数、重复、口径错误）。

分层对账是数仓质量的核心保障。行数/金额/主键唯一性覆盖了数据"是否有、是否全、是否唯一"三个维度，跨层对账能定位分层转换中的丢数、重复与口径问题。金额对账要注意浮点与口径差异。

• 口径字典
• 同名不同义问题
• 口径一致性测试

口径字典是统一指标定义（如"活跃用户"的定义、统计口径、维度、来源）的规范。同名不同义问题指同一指标名在不同表/团队中定义不同（如"GMV"含不含退款、去重规则不同），导致数据不一致。口径一致性测试：对同一指标在不同来源（如不同表、实时与离线）计算，对比结果是否一致；识别口径差异（过滤条件、去重键、时间口径、金额口径）并定位差异来源。做法是建立口径字典，为每个指标定义唯一口径，通过"口径=计算 SQL"的绑定，测试该 SQL 在不同场景下结果一致；对同名不同义指标，通过口径字典标记并测试其差异，避免混淆。口径变更时更新字典并触发下游用例回归。

口径管理是数仓"数据可信"的关键。同名不同义是数据不一致的根源。通过口径字典统一定义 + 一致性测试校验，能识别并治理口径差异，保证指标口径一致、可追溯。

• SCD 类型
• 测试用例设计
• 历史数据验证

SCD 处理维度属性变化。Type 1（覆盖）：直接覆盖旧值，不保留历史，测试验证更新后旧值被替换、历史数据也被更新为最新值。Type 2（新增记录）：保留历史，新增一条记录并标记有效/失效时间，测试验证更新后新增记录、旧记录失效、历史正确分段。Type 3（历史列）：增加字段保存上一次值，测试验证新值与上一次值字段更新。历史数据验证：Type 1 验证无历史保留；Type 2 验证按时间区间的快照正确（查询某时间点返回当时的有效值）；Type 3 验证上一次值字段。用例设计：构造维度更新（改名称、改属性、改唯一键），验证目标表与历史记录符合 SCD 类型语义，并验证跨时间查询的结果。

SCD 决定历史数据如何保留。不同类型对历史处理不同，测试须按类型验证更新行为与历史快照。历史数据验证（时间点查询）是 SCD 正确性的关键，能发现历史被意外覆盖或分段错误。

• 上游质量问题处理策略
• 阻断 vs 放行加标记
• 权衡与决策

上游数据质量有问题时，有两种策略。阻断下游（Fail-fast）：上游质量不达标就阻断下游任务，避免脏数据扩散，但会中断下游可用性、影响 SLA，适合关键、不可逆链路。放行加标记（Pass-through + flag）：上游数据带质量标记放行，下游消费时感知标记（如 quality_flag 字段），可追溯、可修复，但脏数据可能短暂影响下游。决策依据：问题严重度、数据用途（关键交易 vs 分析）、下游是否有纠错能力、SLA 要求。测试需验证两种策略都被正确实现：阻断时下游正确失败/告警；放行带标记时标记字段正确、下游可感知。可设计"质量门禁"配置，按严重度分级（阻断/告警/放行）。

这是数据质量治理的策略取舍。测试要验证策略实现的一致性与可配置性，并确保决策可追溯。放行加标记更灵活，阻断更安全，实际常按严重度分级混合使用。

• SQL 静态检查
• 表/字段/权限/敏感列
• 质量门禁

通过解析 SQL AST 与元数据、权限、敏感列清单比对，实现静态检查。检查项：表名/字段名存在性（与元数据比对）、表分区与字段类型正确性、权限（用户是否有读写权限）、敏感列（查询/写入是否涉及敏感列，是否需脱敏或权限控制）、SQL 规范（如无条件分区会全表扫描、笛卡尔积 join）。将这些检查形成质量门禁（CI 中在提交时自动执行），不合格的 SQL 阻断发布。可配置规则引擎（如 SQLFluff、自定义 parser），输出检查报告，标明违规项与建议。门禁是"发布前的质量防线"，能提前拦截大多数可静态发现的错误。

静态检查把易错点前置到发布前，成本低、覆盖面广。表/字段/权限/敏感列四大类问题可静态识别，形成门禁能防止不合格 SQL 进入生产，减少运行期事故。

• 源到目标映射
• 类型转换与 NULL 处理
• 去重与增量抽取

源到目标映射验证：逐字段断言源字段正确映射到目标字段，变换规则（拼接、截取、计算）结果正确。类型转换验证：覆盖不同数据类型（字符串↔数字、日期格式、精度转换），验证转换正确且不丢精度、不溢出。NULL 处理验证：NULL 输入时目标字段是否按规则处理（默认值、保留 NULL、剔除），验证 NULL 不导致异常。去重验证：按去重键去重后行数正确、无重复主键。增量抽取验证：按时间戳/主键/CDC 增量抽取，验证只抽取新增/变更数据、不重复、边界时间正确。这套用例用"已知输入→期望输出"的黄金断言逐项验证，覆盖 ETL 的每个核心环节。

ETL 的核心就是"映射、转换、清洗、抽取"。逐项验证这些环节能保证数据正确到达目标。类型/NULL/去重/增量是 ETL 最容易出错且影响数据质量的地方，需重点覆盖。

• 分层测试策略
• 各层数据一致性
• 指标口径对齐

分层测试策略：对各层分别测试。ODS 验证与源数据一致（行数、字段、增量完整性）；DWD 验证明细层清洗、去重、标准化正确，主键唯一；DWS 验证汇总层聚合正确（指标口径、聚合粒度）；ADS 验证应用层指标与报表正确。各层一致性：通过跨层对账（行数、金额、主键）验证层间传导正确。指标口径对齐：同一指标在 DWS/ADS 计算口径一致，与口径字典一致，通过"口径=SQL"绑定测试。策略上采用"纵向逐层 + 横向跨层对账"：每层验证本层逻辑，跨层验证传导，保证一致性。层间变更时做联动回归。

分层测试的关键是"每层逻辑正确 + 层间传导一致"。纵向逐层验证本层转换，横向对账验证层间无丢数无重复，口径对齐保证指标跨层一致。分层策略让测试可定位、可追溯。

• 幂等性
• 可重跑
• 部分成功场景

幂等测试验证同一任务重复执行多次，结果一致（行数、内容、无重复数据）。可重跑测试验证失败后重跑能正确恢复，不因已写入的部分数据导致重复或错误。部分成功场景：任务某阶段失败（如写入部分分区成功），验证重跑时能正确处理——覆盖已写入数据（INSERT OVERWRITE 分区）或从失败点继续，不产生脏数据。验证方法：对同一输入执行多次，比对输出；在任务中途注入失败，重跑后比对结果与完整执行一致；验证主键唯一性、分区无重复。幂等的关键在写入策略（overwrite vs append、去重、唯一键），测试应验证这些策略在重跑下正确。

幂等与可重跑是 ETL 可靠性的基础。大数据任务常失败重跑，若不可重跑会产生重复数据。测试验证重复/失败/部分成功场景下结果一致，能防止重跑引入脏数据。

• 异常数据识别
• 异常分支处理
• 断言异常行为

构造异常数据并验证其走异常分支。格式错误：日期非法、数字为字符串、JSON 格式错误，验证 ETL 按规则丢弃、告警或转默认值。字段缺失：关键字段 NULL 或缺失，验证按默认值填充、暂存或丢弃。超范围值：金额负数、数量超大、ID 越界，验证是否被拦截或修正。测试断言：异常数据被正确识别并进入异常分支（丢弃并计数、写入异常表、触发告警、填默认值），同时正常数据不受影响。验证异常分支的"可追溯性"：异常数据被记录（异常表、日志、计数），便于排查。避免异常数据被静默处理或错误地进入正常结果。

脏数据不可避免，异常分支决定其去向。测试验证异常数据被正确识别与处理（丢弃/告警/默认值），保证正常数据干净、异常可追溯。这是 ETL 健壮性的关键。

• 增量抽取方式
• 新增/更新/删除/回补
• 边界时间断言

增量抽取三种方式。时间戳：按 last_modified 抽取，覆盖新增与更新，边界时间需精确断言（边界时间点、时区、跨日、同刻多条），避免漏抽或重复。主键：按主键去重抽取，覆盖新增与更新（覆盖），删除需特殊处理（逻辑删除/标记）。CDC：基于 binlog 捕获变更，覆盖新增/更新/删除，需验证删除事件被正确捕获。历史回补：补抽历史数据（如补数），验证回补不覆盖现有、不重复。边界时间断言：测试增量抽取的游标边界（如 > last_max 是否漏掉边界值、>= 是否重复），验证时间戳精度与毫秒/秒边界。对每类操作（增/改/删/回补）构造数据，断言抽取结果正确。

增量抽取的边界是"漏抽/重复/漏删除"的高发区。覆盖新增/更新/删除/回补并精确断言边界时间，能保证增量数据完整、无重复、删除正确。CDC 与时间戳/主键的差异需分别验证。

• 字符集转换
• 时区换算
• 跨日与日期分区

字符集转换：测试 UTF-8、GBK 等编码的读取与转换，验证中文字符、特殊字符（emoji、多字节）不乱码、不截断。时区换算：测试不同时区（UTC、东八区、夏令时）的时间换算，验证时间戳转换正确、日期计算（如 date_add）不受时区影响。跨日影响：测试跨日事件（23:59:59 与 00:00:00）归属日期分区正确，验证按本地时区划分的日期分区不因跨日错位。金额影响：金额字段在编码/时区转换中不丢失精度、不因四舍五入误差。用例设计：构造跨时区、跨日、含特殊字符的边界数据，断言转换后日期分区、金额、字符正确。用固定时区配置（如 Asia/Shanghai）保证可复现。

编码与时区是 ETL 的隐形陷阱，跨日/跨时区易导致日期分区错位与金额误差。设计针对字符集、时区、跨日的边界用例，能暴露并验证这些转换问题，保证数据准确。

• DataOps 测试分层
• 管道冒烟测试
• 质量规则与 SLA 告警

DataOps 测试分三层。管道冒烟测试：快速验证数据管道能正常启动、执行、产出数据（不验证深度正确性），覆盖管道连通性、依赖关系、基础运行，用于发布后快速检查。数据质量规则：验证业务数据质量规则（完整性、唯一性、及时性等）是否正确执行，覆盖规则逻辑与阈值，是数据质量的持续验证。SLA 告警：验证数据产出时间、延迟、新鲜度的 SLA 监控与告警，覆盖告警触发、通知、升级流程，确保超时/异常能被及时感知。三层从"跑通"到"质量"到"时效"递进，形成完整的 DataOps 质量保障。测试关注各层检测指标与触发条件。

DataOps 分层让测试覆盖"能否跑通、数据是否对、是否及时"三个层次。冒烟保连通、质量规则保正确、SLA 告警保时效与可观测，三者结合形成端到端的数据运维质量保障。

• 调度依赖
• 失败重跑
• 数据就绪检查

调度依赖测试验证 DAG 中任务依赖的正确性。失败重跑：某任务失败后，验证其下游任务被阻塞/失败、依赖链不错误执行；重跑时只重跑失败任务及其下游，不重跑无关任务。数据就绪检查：验证下游任务在上游数据就绪（如上游产出分区、SLA 完成）后才启动，通过资源就绪检查（文件存在、分区存在、质量门禁通过）控制。验证：模拟上游失败/延迟，断言下游不提前启动；上游就绪后下游正确触发；重跑范围正确（部分重跑）。可用测试调度器（如 Airflow 的测试环境、DolphinScheduler）构造依赖图，验证依赖关系与重跑行为、就绪检查逻辑。

调度依赖保证任务按正确顺序与就绪状态执行。失败重跑与数据就绪检查防止"下游用脏数据/提前跑"与"重跑范围错误"。测试验证依赖与重跑语义，是数据管道可靠性的基础。

• ETL 性能
• 执行窗口
• 资源占用

ETL 性能测试验证任务在指定执行窗口（SLA 时间窗，如每日 2 小时内完成）内能完成，且资源占用可控。时间窗口验证：在配置的调度窗口内执行任务，度量整体耗时，断言满足 SLA（如 耗时 < 窗口）；对增长的数据量做基准，验证耗时随数据量增长可控。资源验证：监控任务的内存、CPU、并发、shuffle 数据量，验证资源占用在分配范围内（不 OOM、不超额占用）；对比不同资源配比（并行度、内存）下的耗时与资源，找到最优配置。压测：在最大数据量/峰值瞬时执行，验证不超时、资源不超限。优化定位：用执行计划、stage 耗时、shuffle 定位性能瓶颈。

ETL 性能要兼顾"按时完成"与"资源可控"。验证 SLA 窗口内完成与资源占用不超过分配，能防止任务超时或拖垮集群。压测最大值场景能提前暴露性能风险。

• 自动化框架
• 源目标比对
• 规则断言与调度触发

ETL 自动化框架工具化三部分。源目标比对：自动跑源表与目标表的 SQL 对账（行数、字段、聚合），生成比对结果，支持全量与抽样比对，可配置对账规则。规则断言：把数据质量规则（非空、唯一、范围、格式）配置为可执行断言，自动执行并报告违规。调度触发：与调度系统集成，任务完成后自动触发测试，或在发布/数据就绪时触发；测试结果与 CI、告警联动。落地方案可用框架（如 dbt test、Great Expectations、自研对账引擎）配合 SQL 模板，实现"配置化 + 自动执行 + 报告"。测试框架需支持用例管理、基线管理、结果聚合与告警，让 ETL 测试持续自动运行。

ETL 测试工具化让"对账、断言、触发"自动化，替代人工比对。配置化规则 + 调度触发 + 报告联动，能实现持续、可重复的数据质量验证，是 ETL 质量保障的工程化落地。

• 查询性能测试
• 延迟基线
• 性能回归

建立查询性能基线：选取常用报表与典型即席查询作为基准查询集，在固定数据量与环境下执行，记录各查询的耗时（p50/p95/p99）作为基线。回归：定期或数据模型变更后重跑基准查询集，对比耗时与基线，超过阈值（如 p95 超基线 20%）判定性能回归。要点：固定查询集、数据量与环境（避免不同环境干扰）；用冷热缓存（清缓存测冷查询、命中缓存测热查询）区分；监控执行计划变化（如 join 方式、扫描量）定位性能退化原因。回归触发模型变更（加列、改分区、改索引）、数据量增长、引擎升级等场景。性能基线可纳入 CI，异常时告警。

查询性能基线是数仓性能可观测的手段。通过固定基准查询集 + 阈值对比，能发现数据模型/数据量变化导致的性能退化。区分冷热缓存与监控执行计划，能准确定位性能瓶颈。

• 元数据与口径文档
• 变更触发
• 文档实现漂移

防止文档与实现漂移，需建立"变更即触发"的联动机制。表结构变更：监控元数据（表结构、字段、分区）变更，自动检测受影响的 SQL 与下游用例，触发对应用例更新与回归。口径变更：口径字典变更时，识别依赖该口径的指标、报表与测试用例，提示更新。做法：元数据变更检测基于元数据系统（如 DataHub、Atlas）或 SQL 依赖解析，生成"变更影响清单"；测试用例与表/口径绑定，变更时自动标记受影响用例并触发重跑。同时用"文档即代码"（口径字典、模型定义作为代码入库），通过测试验证文档正确，防止文档与实现漂移。断言：变更后受影响用例被更新、文档与实现一致。

文档与实现漂移是数仓维护的常见问题。通过元数据变更检测 + 用例绑定 + 影响分析，让表结构/口径变更自动触发下游用例更新，保证文档与实现同步、测试不失效。