历史数据清洗（数据治理）

如果有基本了解的可以直接看总结

事务与幂等性

• 使用事务（Transaction）

  • 若数据量大且涉及多表更新，尽量使用 批量提交（如每 1000 条提交一次）来提高效率，避免单条提交影响性能。

  • 避免长事务，防止锁表或数据库性能下降。

• 保证幂等性

  • 处理数据时，避免重复执行导致数据异常，比如 先检查数据是否已被处理 再执行操作。

  • 可使用 唯一标识字段（如 processed_flag）或 日志记录 追踪处理进度。

清洗规则制定

• 脏数据处理（最好查询时就排除大量的脏数据，脏数据太多代码是写不过来的）
• 缺省字段处理（默认值）
• 字段格式规范（日期、金额等）

性能

• 大数据量分批处理

  • 避免一次性加载所有数据，可采用分页查询或分批更新（如 LIMIT 1000 OFFSET 0）。
  • 可采用 多线程并行清洗，但要注意数据一致性和锁冲突。

• 使用索引加速查询

  • 确保 查询条件字段（如 ID、时间）有索引，避免全表扫描导致性能下降。
    避免死锁。
  • 避免多个进程并发更新同一条数据，必要时可加锁或分批处理。

记录数据清洗日志

• 推荐直接记录日志文件，容查找追溯

异常回滚机制

• 记录已处理 ID，只对未处理的数据重试。
• 将错误数据存入 error_log 表，后续手动修复或自动重试。

总结-问题解决方案

1. 数据清洗过程被中断的解决方案
   记录日志，例如记录已处理数据的 ID 或其他可区分的字段。
   在表中增加 标识字段，标记已清洗的数据行，并 按标识字段排序 进行清洗，以便恢复时能准确找到中断点。
   重新执行时，基于中断点设置相应条件，确保数据连续清洗。

2. 如何处理错误数据
   数据本身错误：
   记录日志文件，包括错误原因和 主键 ID，以便后续分析和修正。
   程序执行错误：
   记录日志，包括错误原因和 主键 ID，便于后续重试。
   若涉及 随机数冲突 等问题，可基于错误数据重新执行修复逻辑。

3. 接口需要的条件
   ID 方式：
   例如 “1232,4343,54545”，接口返回异常 ID，修改后可直接重新执行。
   时间方式：
   通过 创建时间 或其他时间字段，在中断时标记断点，后续清洗时从该时间点继续。
   也可使用 ID 方式，但查询时需 确保正确排序，避免数据遗漏或重复。

4. 记录原始ID，清洗完成后可以进行 数据完整性校验，确保数据没有丢失或遗漏。