⚙️ ETL测试方法论

05-06ETLELT测试方法论dbt

📌 ETL 与 ELT 的测试差异

ETL（Extract-Transform-Load）与 ELT（Extract-Load-Transform）在数据处理顺序上的差异，直接影响了测试策略的侧重点。ETL 强调在加载前完成转换与清洗，适合合规要求严格的场景；ELT 则利用目标系统（如 Snowflake/BigQuery）的计算能力在加载后转换，灵活性更高。

维度	ETL 测试重点	ELT 测试重点
转换时机	ETL 中间层转换逻辑验证	目标端 SQL/dbt 模型验证
数据质量	在管道入口处拦截脏数据	加载后再清洗，需测试清洗覆盖度
错误处理	转换失败隔离 + 重试机制	原始数据保留，可随时重跑
性能	ETL 服务器资源优化	数仓计算资源 + 查询优化
回滚	需完整的回滚方案	原始数据不变，重跑转换即可

💡 分阶段测试策略

1️⃣ 提取阶段（Extract）

连接器测试：验证数据库/SaaS API/文件系统的连接稳定性与权限
增量提取：基于时间戳/Change Data Capture（CDC）的增量拉取准确性
数据类型映射：源端与ETL工具间的类型转换是否无损（如 Oracle NUMBER→BigQuery NUMERIC）
断点续传：网络中断恢复后，数据不重不漏

2️⃣ 转换阶段（Transform）

字段映射：源字段→目标字段的映射完整性（包括默认值、NULL处理）
业务规则：JOIN、聚合、CASE WHEN 等逻辑的正确性——用源数据手动计算后对比
数据清洗：去重、格式标准化、异常值过滤是否符合预期
缓慢变化维度（SCD）：Type 1/2/3 处理逻辑是否正确生成代理键和生效时间

3️⃣ 加载阶段（Load）

全量 vs 增量：首日全量加载的正确性 + 次日增量 MERGE/UPSERT 的正确性
幂等性：同一批数据重复加载不应产生重复行
加载顺序：事实表必须在维度表加载完成后写入（外键约束）
截断保护：防止误操作 TRUNCATE 生产表

🔍 数据校验方法

校验类型	方法	示例
行数校验	源端 COUNT() vs 目标端 COUNT()	源表 100w 行 → 目标表 100w 行
汇总校验	SUM/AVG/MIN/MAX 聚合值对比	源 SUM(amount) = 目标 SUM(amount)
抽样比对	随机抽取 N 条逐字段比对	抽取 1000 行，80 列逐列校验
哈希校验	按分区计算 MD5/SHA256 后对比	每日分区 hash 一致 = 数据一致
业务规则	断言数据满足业务约束	order_date ≤ ship_date
空值检查	NOT NULL 字段空值率	customer_id NULL 率 = 0%

⚠️ 常见陷阱

时区陷阱：源端 UTC、目标端本地时区，TIMESTAMP 字段偏移 8 小时
编码问题：UTF-8→GBK 乱码，尤其是中文姓名/地址字段
精度丢失：DECIMAL(38,18) → FLOAT 导致金额精度丢失
NULL 语义：Oracle '' = NULL，但 PostgreSQL '' ≠ NULL，导致过滤逻辑差异
隐式排序：某些 ETL 工具默认排序，依赖排序的逻辑在分布式环境下可能失效

📖 dbt 测试实践

dbt（data build tool）内置了强大的测试能力，推荐在 ELT 场景中采用：

Generic Tests：unique、not_null、accepted_values、relationships（外键检查）
Singular Tests：编写自定义 SQL 断言，如 SELECT * FROM orders WHERE amount < 0
dbt-expectations：类似 Great Expectations 的声明式测试插件
单元测试（dbt v1.8+）：Mock 输入数据，验证模型转换逻辑
CI/CD 集成：PR 提交时自动运行 dbt build，测试失败阻止合并

← 数据湖测试策略实时数据管道测试 →