第26章 ETL测试与调试

第26章：ETL测试与调试

说实话，很多刚入行的朋友觉得ETL开发就是写写SQL、配配调度。但真正干过几年的人都知道——测试和调试才是真正考验功力的地方。我见过太多项目，开发只用了30%的时间，剩下70%全在修bug。

这一章，我就把压箱底的测试调试经验掏出来。咱们从单元测试讲起，一路聊到集成测试、回归测试，最后说说那些让人头疼的调试技巧。

单元测试：你的第一道防线

单元测试，说白了就是测试最小的代码单元。在ETL里，通常就是一条SQL、一个存储过程、或者一个Python函数。

为什么要做单元测试？ 我遇到过最惨的一次——上线前才发现一个字段映射错了，结果全量数据重跑花了整整两天。从那以后，我每条SQL写完都先跑单元测试。

单元测试的核心要点

测试数据要小：几行到几十行就够了，别上来就搞几百万条
覆盖边界值：NULL值、空字符串、最大值、最小值
验证输出结构：字段数量、数据类型、字段顺序对不对
检查数据质量：去重、聚合、关联逻辑是否正确

我个人的习惯是：每个ETL任务都配一个单元测试脚本。开发时跑一遍，改代码时再跑一遍。虽然前期多花点时间，但后期省下的时间绝对值得。

一个简单的单元测试示例

-- 测试：用户订单汇总逻辑
-- 输入：3条订单记录
INSERT INTO test_orders VALUES 
(1, '2024-01-01', 100.00),
(1, '2024-01-02', 200.00),
(2, '2024-01-01', 150.00);

-- 执行目标SQL
INSERT INTO user_order_summary
SELECT user_id, COUNT(*) as order_cnt, SUM(amount) as total_amount
FROM test_orders
GROUP BY user_id;

-- 验证结果
-- 期望：用户1有2笔订单，总额300；用户2有1笔订单，总额150
SELECT * FROM user_order_summary;
-- 手动检查或写断言脚本

小技巧：可以用临时表或事务来隔离测试数据，跑完就回滚，不影响真实环境。

集成测试：看看大家配合得怎么样

单元测试过了，不代表整个流程没问题。集成测试就是检查各个组件之间能不能正常协作。

集成测试关注什么？

数据流转：从源系统到目标系统，中间经过了多少层？每层的数据对不对？
接口对接：API调用、文件传输、数据库连接是否正常？
依赖关系：任务A跑完了，任务B能不能正确读取它的输出？
异常处理：某个环节挂了，下游能不能感知到？会不会产生脏数据？

我记得有一次做集成测试，发现源系统的日期格式是YYYY-MM-DD，但目标系统要求YYYYMMDD。单元测试时各自都正常，一集成就出问题。这就是集成测试的价值——发现那些"各自为政"时看不出来的问题。

回归测试：改代码的"后悔药"

你想想看，一个ETL系统跑了大半年，突然要加一个新字段。你敢直接改吗？

反正我不敢。每次改代码之前，我都会先跑一遍回归测试。

回归测试的核心思想：改完代码后，用同样的输入数据跑一遍，看看输出和之前是不是一样。

回归测试怎么做？

准备基线数据：记录当前版本的输出结果
修改代码：加字段、改逻辑、优化性能
重新运行：用同样的输入数据跑一遍
对比差异：新输出和基线数据逐字段对比

我曾经踩过的坑：有一次改了一个日期处理函数，自认为没问题。结果回归测试发现，有个边缘case的日期差了一天。幸亏跑了回归测试，不然上线后数据对不上，那可就麻烦了。

测试数据生成：巧妇难为无米之炊

做测试，最头疼的就是没有合适的测试数据。真实数据有隐私问题，造数据又怕造得不够全面。

我常用的几种方法：

方法	适用场景	优点	缺点
真实数据脱敏	需要模拟真实分布	数据真实	脱敏过程复杂
随机生成	测试边界值、异常值	覆盖全面	可能不符合业务逻辑
生产数据采样	性能测试	数据量大、真实	需要脱敏
手工构造	特定场景测试	精准控制	工作量大

说白了，没有一种方法能解决所有问题。我一般会组合使用——用真实数据脱敏做基础，再手工构造一些边界case。

调试技巧：那些年我追过的bug

调试，是ETL工程师的日常。我总结了几个实用技巧，希望能帮你少走弯路。

1. 日志要打到位

很多新手舍不得打日志，觉得影响性能。但你想啊，一个任务跑几个小时，中间出错了，没有日志你怎么知道哪里挂了？

-- 好的日志习惯
-- 每个关键步骤都记录：开始时间、处理行数、结束时间
-- 异常时记录：错误信息、上下文数据、堆栈信息

2. 分段排查法

数据量大的时候，别想着一次定位问题。把流程切成几段，一段一段验证。

先看源数据对不对
再看中间转换结果
最后看目标数据

我遇到过一个问题，数据在源端是对的，到目标端就少了。分段排查后发现，是中间有个去重逻辑写错了。

3. 善用临时表

调试复杂SQL时，别直接改生产代码。把逻辑拆开，每一步的结果存到临时表里，慢慢看。

-- 调试示例：分步查看中间结果
-- 第一步：查看过滤后的数据
CREATE TEMP TABLE step1 AS
SELECT * FROM source_table WHERE status = 'ACTIVE';

-- 第二步：查看聚合结果
CREATE TEMP TABLE step2 AS
SELECT user_id, COUNT(*) as cnt
FROM step1
GROUP BY user_id;

-- 第三步：对比最终结果
SELECT * FROM step2 WHERE cnt > 100;

4. 数据对比工具

手动对比数据太累了。我推荐用一些对比工具，比如diff命令、或者写个Python脚本自动对比。

我的调试三板斧：先看日志、再看中间数据、最后看代码逻辑。80%的问题都能用这个方法定位。

知识体系总览

下面这张图，是我对ETL测试与调试的整体理解。你可以把它当作一个检查清单，做项目时对照着来。

嗯，ETL测试和调试这块，说到底就是细心加耐心。没有捷径，但有了这些方法和技巧，至少能让你少踩一些坑。

记住一句话：测试不是为了证明代码没问题，而是为了发现代码有问题。心态摆正了，做起测试来就不会觉得是在浪费时间了。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录