项目类型: 技术深度类 | 展示 SQL 专家能力与业务理解 所属公司: 河南九州通医药有限公司 项目时间: 2022 年 6 月 - 2022 年 12 月（7 个月） 项目角色: 应用侧核心执行者（负责数据清洗与业务逻辑验证）
一句话项目概述
在 ERP 系统架构从 v2 升级到 v3 的关键窗口期，作为应用侧核心技术成员，通过编写复杂 SQL 脚本完成千万级历史数据的逻辑清洗，确保新旧版本数据一致性 100%，支撑平滑上线零事故。
项目背景 (Situation)
业务背景
河南九州通（年营收 150 亿 + 的医药流通企业）推行 ERP 核心架构升级，从 v2 版本升级到 v3 版本。新版本引入多业务实体 (OU) 与库存组织 (IO) 的强财务隔离架构，底层数据结构发生质变。
技术挑战
- 数据结构重构: 原 v2 版本的平铺式数据结构，在 v3 中变为多层级架构，数据迁移复杂度极高
- 历史数据脏数据: 多年积累的 ERP 数据中存在大量逻辑错误（无主库存、未核销负数、借贷不平凭证等）
- 合规高压: 若带着脏数据迁移，将导致新系统 ” 财务账实不符 “，构成严重的财务合规风险
核心痛点
- 预检测评发现500+ 条深层逻辑错误数据
- 数据量千万级，人工修正不现实
- 升级窗口期固定，不能影响日常业务
项目目标 (Task)
核心 KPI
- 数据质量: 清洗所有逻辑错误数据，新旧版本财务/库存数据一致性100%
- 平滑切换: 升级切换期间零重大业务事故（P0 级）
- 知识沉淀: 输出可复用的数据校验脚本和问题处理文档
个人职责边界
- 负责应用层数据一致性校验与清洗
- 负责业务逻辑验证与穿测
- 协助制定切换方案与应急预案
关键行动 (Action)
阶段一：数据清洗工程（核心技术工作）
1. 脏数据诊断与分类
- 编写诊断 SQL 脚本，扫描千万级历史数据，定位逻辑错误类型
- 将脏数据分类为：无成本库存、孤立单据、借贷不平凭证、重复数据等 6 大类
2. 清洗脚本开发
-- 示例：清洗无主库存数据
-- 通过多表关联查询，找出库存记录中无对应入库单的异常数据
SELECT
inv.item_id,
inv.quantity,
inv.warehouse_id,
inv.cost_amount
FROM inventory inv
LEFT JOIN receipt_transactions rt
ON inv.transaction_id = rt.transaction_id
WHERE rt.transaction_id IS NULL
AND inv.quantity <> 0
AND inv.created_date < TO_DATE('2022-01-01','YYYY-MM-DD');
-- 根据业务规则，将这些数据与历史单据进行逻辑匹配修复
-- 或标记为待处理，由业务部门确认后处理3. 批量修复执行
- 编写修复 PL/SQL 存储过程，自动化修正 100000+ 条脏数据
- 对于无法自动修复的数据，生成《待人工确认清单》提交业务部门
- 修复后再次执行诊断脚本，确保清洗完整性
关键技术点：
- 复杂 SQL：多表关联查询、子查询、分析函数（ROW_NUMBER, LAG/LEAD）
- 事务控制：COMMIT/ROLLBACK 确保数据一致性
- 性能优化：通过索引优化、分批处理避免长事务锁表
阶段二：业务逻辑验证（全链路穿测）
1. 测试环境搭建
- 在沙箱环境中，使用清洗后的数据构建 v3 测试环境
- 协助 DBA 团队完成数据迁移和配置同步
2. 核心业务流程穿测 组织业务骨干进行P2P（采购到付款） 和O2C（订单到收款） 全流程测试：
- 采购订单→入库→应付核销→付款
- 销售订单→出库→应收核销→收款
3. 差异化问题处理
- 重点验证新架构下的权限隔离（OU 级别权限）
- 重点验证自动记账逻辑（成本计算规则变化）
- 输出《v3 版本操作差异手册》，降低一线人员操作风险
阶段三：上线保障（分级响应）
1. 切换方案制定
- 参与制定《升级切换方案》与《应急回退预案》
- 明确切换时间窗口、数据备份策略、回退触发条件
2. 现场值守
- 升级上线当周实施7×24 小时现场值守
- 设计 ” 分级响应通道 “：P0 级（业务中断）→15 分钟响应；P1 级（功能异常）→30 分钟响应
3. 快速问题修复
- 准备常见问题的 SQL 快速修复脚本
- 对接基础设施团队，确保底层数据库/网络稳定
量化成果 (Result)
核心成果
-
数据质量达标:
- 精准定位并修正500+ 条深层脏数据
- 新旧版本数据一致性校验100% 通过
- 彻底消除迁移 ” 地雷 “，避免财务合规风险
-
平滑上线:
- ERP v3按期上线，升级窗口期无 P0 级重大业务事故
- 日常业务流程正常流转，未出现大规模操作阻塞
-
资产沉淀:
- 编写的数据校验脚本库（包含诊断/修复/验证脚本）
- 输出的《常见报错速查表》与《v3 差异操作手册》
- 被集团 IT 部门推广至其他省公司，作为 ERP 升级标准工具
个人价值体现
- SQL 技术专家: 展示了复杂数据清洗、性能优化、事务控制的深厚功底
- 业务理解深度: 能够将财务/库存业务规则转化为 SQL 逻辑
- 风险控制意识: 提前发现并消除数据质量风险，保障财务合规
技术栈清单
| 类别 | 具体技术 |
|---|---|
| 数据库 | Oracle Database 11g, PL/SQL |
| 核心技能 | 复杂 SQL 查询（多表关联、子查询、分析函数）, 存储过程, 事务控制, 性能优化 |
| ERP 系统 | Oracle ERP（P2P/O2C 模块业务逻辑） |
| 工具 | PL/SQL Developer, Toad for Oracle, Excel（数据分析） |
面试准备：常见问题与应对
Q1: 你在这个项目中具体做了什么？
回答要点：
” 我作为应用侧核心执行者，主要负责三块工作：第一，数据清洗，通过编写复杂 SQL 脚本，扫描千万级数据，定位并修复 500 多条逻辑错误；第二，业务验证，组织业务人员进行采购到付款、订单到收款的全流程穿测；第三，上线保障，制定应急预案并现场值守。最终确保了升级零事故。“
Q2: 数据清洗遇到最大的技术难点是什么？
回答要点：
” 最大难点是无主库存数据的追溯匹配。这些库存记录因为历史原因丢失了入库单关联，但又有实际库存和成本。我通过编写复杂的 SQL，基于商品批次、时间戳、仓库等维度，与历史采购订单进行模糊匹配，成功修复了大部分数据。对于无法自动匹配的，我生成清单交给业务确认后手动修正。“
Q3: 如何保证 SQL 脚本的准确性和安全性？
回答要点：
” 我采用了三步法：第一，先在测试环境反复验证，确保逻辑正确；第二，在生产环境执行前，先用 SELECT 查询预览影响范围，让业务确认；第三，使用事务控制，先执行修改但不 COMMIT，人工检查结果无误后再提交。同时做好数据备份，确保可以回滚。“
Q4: 这个项目对你后续工作有什么帮助？
回答要点：
” 这个项目让我深刻理解了 ERP 系统中业务流和数据流的关系，培养了数据驱动的思维方式。后来转岗做基础设施时，我依然沿用这种 ’ 用数据说话 ’ 的方法进行容量规划、性能分析。而且这段经历让我明白，技术人员不能只懂技术，必须深入理解业务，才能真正解决问题。“
可能的追问点与应对策略
追问 1: “500 条脏数据是怎么统计出来的？”
准备答案：
- 通过诊断 SQL 脚本扫描全量数据
- 按错误类型分类统计（无主库存、借贷不平、孤立单据等）
- 生成《脏数据明细清单》提交给业务确认
追问 2: ” 如果上线后还是出现数据问题怎么办？”
准备答案：
- 我们制定了分级应急预案
- P0 级（业务中断）：立即回滚
- P1 级（数据错误）：快速修复脚本处理
- 准备了常见问题的 SQL 修复脚本库
追问 3: ” 你们的测试覆盖率如何保证？”
准备答案：
- 核心业务流程 100% 穿测（P2P/O2C）
- 高频操作场景重点验证（如月结、盘点）
- 新旧版本对比测试，确保结果一致
追问 4: ” 你觉得这个项目最大的收获是什么？”
准备答案：
- 技术上：SQL 能力提升，能够处理复杂的数据清洗场景
- 业务上：深入理解了医药行业的财务/库存管理规则
- 工作方法上：学会了在高压环境下，如何做好风险控制和应急准备
项目亮点提炼（电梯演讲版 -30 秒）
” 在 ERP 系统从 v2 升级到 v3 的关键项目中，我负责应用层的数据清洗和业务验证。面对千万级历史数据中的 500 多条逻辑错误，我通过编写复杂的 SQL 脚本实现了自动化清洗，确保了新旧系统数据一致性 100%。最终项目按期上线，升级窗口期零重大事故。这段经历让我深刻理解了数据治理的重要性，也培养了数据驱动的工作方式。“
适用场景
推荐在以下情况使用此项目：
- ✅ 应聘需要SQL 能力的岗位（数据分析、数据工程、运维开发）
- ✅ 面试官关注业务理解能力（不只是纯技术）
- ✅ 公司有ERP/SAP 等企业级系统（容易产生共鸣）
- ✅ 岗位 JD 提到数据治理、数据质量等关键词
不推荐在以下情况使用：
- ❌ 纯互联网/云原生公司（可能觉得 ERP 太传统）
- ❌ 强调 DevOps/SRE 自动化的岗位（此项目偏手工）
- ❌ 面试时间紧张，想快速展示技术广度（此项目讲述需 5-10 分钟）