“艾非”这两个字第一次出现在我的便签上时后面跟的不是什么需求文档而是一句很难听的吐槽——同一份数据我一周之内手工合并了四遍每遍都在同样的几个地方翻车。那会儿它还不叫项目,就是一个躺在桌面、文件名带着三个版本号后缀的脚本。半年之后这个代号变成了我每天真正在用的东西定时取数、清洗、校验、产出格式稳定的文件出问题了它自己发消息告诉我。这篇就把“艾非”这套东西从临时脚本长成小系统的完整过程摊开讲一遍包括骨架怎么搭、规则怎么写、失败怎么兜、以及那几个让我返工好几次的坑。适合手上有重复性数据处理工作、又不想一上来就上重框架的人看代码基础薄弱一点也能跟下来。1. 一个只有代号的项目通常从“忍无可忍”开始1.1 重复劳动才是真正的技术债很多人一说技术债就想到代码写得烂、架构不合理但在我看来真正吃掉时间的债是重复劳动。我做过统计那段时间我每周花在手动合并数据上的时间是六到八小时其中至少一半耗在“上一次是怎么做的”这种回忆上。手工操作最大的问题不是慢是不一致今天记得去掉空行明天忘了这次用左连接下次手滑用了内连接结果少了一批记录还浑然不觉。“艾非”最初的目标非常朴素——把这套流程固化下来让机器按同一个标准重复执行。注意这里的关键词是“同一个标准”不是“更快”。速度是副产品一致性才是刚需。我当时给自己定了一条判断标准同一份输入无论跑多少次、隔多久跑产出必须完全一样。这条标准后来救了我很多次因为它直接排除了大量“看起来方便、实际上不可复现”的做法比如手工在表格里改两行、比如依赖某个临时文件的当前状态。起代号这件事本身也有讲究。我不建议用“数据同步脚本v2”这类描述性名字原因很实际描述性名字会随着功能变化而变得名不副实进而没人愿意改它。而一个无意义的代号是“空”的它可以承载任何功能演进也不会因为名字和实现对不上而误导后来的人。当然代号要短、要好念、要能在命令行里快速敲出来这三点比含义重要得多。1.2 先画数据流再选工具动手写第一行代码之前我做了一件现在看非常值的事拿一张纸把数据从哪来、经过哪几步、到哪去画成一条线。画完之后我发现整个流程其实是四个彼此独立的环节取数从导出文件、接口返回、日志目录三个地方拿数据清洗统一字段名、统一格式、处理缺失和异常校验检查条数、关键字段是否为空、数值是否在合理区间产出写成固定格式的文件放到约定位置这条线一画出来工具选型就变得简单了。取数和产出是 IO用什么库差别不大清洗和校验是纯逻辑应该写成不依赖外部状态的纯函数这样才好测。真正需要谨慎的是调度——什么时候跑、跑失败了怎么办这部分最容易出问题也最容易被忽略。提示如果你现在手上的脚本超过两百行、并且开始出现“这一段不能乱动”的注释基本可以判断它需要按数据流拆成几个环节了。拆的粒度不用很细四到六个环节足够再多就是给自己找麻烦。2. 骨架先行把“艾非”拆成四个可独立验证的环节2.1 输入层先统一“形状”再谈业务输入层最容易犯的错是拿到数据就直接开始写业务逻辑。我第一版就是这么干的结果每接一个新数据源就要在业务代码里加一堆 if 判断“这个源的时间字段叫 date 还是 time”。改到第三个源的时候我受不了了加了一个归一化层所有输入进来之后第一件事是转成统一的内部结构字段名、类型、顺序全部对齐业务逻辑只认这一种结构。具体做法很土但很有效——给每个数据源写一个小的适配函数只负责一件事把原始数据映射成标准字段。标准字段我先定了七八个够用就行后来陆续加过两个。适配函数长这样def adapt_export_file(path): raw read_table(path) return { id: str(raw[编号]).strip(), occurred_at: parse_time(raw[日期], fmt%Y/%m/%d), amount: to_decimal(raw[金额]), channel: normalize_channel(raw[渠道]), source: export, }这个函数没有任何业务判断只做形状转换。好处是它可以单独测——给一份样本断言输出字段齐全、类型正确几行代码就能覆盖。等三个源的适配函数都写完并且都通过测试之后我才开始碰清洗逻辑这时候业务代码里已经看不到“这个源叫什么字段”这类分支了。这里有个细节值得说归一化层要把“源”也作为一个字段保留下来。我一开始觉得没必要反正合并之后都一样。后来排查问题才发现没有来源标记出问题的时候根本不知道该去看哪个源的原始数据只能三个源挨个翻。2.2 处理层用纯函数换取可测试性清洗逻辑我坚持写成纯函数也就是输入进来、输出出去中间不读文件、不写数据库、不看系统时间。这条约束听起来麻烦但收益非常直接任何一个清洗规则都可以用几行数据当场验证不需要准备环境、不需要造文件。举个例子金额字段的清洗规则是“去掉千分位逗号、去掉货币符号、转成定点小数、负数保留”。写成纯函数之后测试是这样的def test_amount(): assert clean_amount(1,234.50) Decimal(1234.50) assert clean_amount(88) Decimal(88) assert clean_amount(-3.10) Decimal(-3.10) assert clean_amount() is None这四个断言覆盖了我在真实数据里遇到过的全部形态包括那个让我栽过跟头的空字符串。写测试的时候不觉得有什么等数据源换了、规则要改的时候跑一遍测试就知道有没有改坏这个安心感是花钱买不到的。纯函数还有一个隐性好处它逼你把“规则”和“执行”分开。规则是clean_amount里那几行判断执行是“读文件、逐行调用、写文件”。后者几乎不用改前者可以单独演进。我后来加“科学计数法转普通小数”这条规则只动了纯函数外层一行没改。2.3 输出层格式稳定比功能丰富更重要输出层我踩过一个典型的坑一开始我追求“输出好看”加了很多格式化、分组、小计行。结果下游读的时候各种出错因为它们依赖列的位置而我某次调整顺序就把它们全搞崩了。后来我把输出层的原则改成了三条一直没再变过原则具体做法原因列顺序固定按常量列表输出不随数据变化下游按位置读的很多类型固定金额一律定点小数、时间一律统一格式字符串避免下游再做类型判断空值显式缺失写明确规定过的占位符不留空空单元格在不同工具里含义不同第三条尤其重要。空单元格在有的工具里是空字符串在有的工具里是 null在有的工具里直接被当成 0同一份文件在不同下游手里能读出三种结果。所以空值必须显式写成一个约定过的标记并且这个约定要写进文档、写进代码注释、写进产出文件的头部说明三处都写。还有一点输出文件我坚持“整份重写”不做增量追加。增量追加看起来省时间但一旦某次跑到一半失败文件就处于半新半旧的状态非常难查。整份重写配合“先写临时文件、校验通过再原子替换”的做法虽然慢一点点但永远不会留下坏文件。2.4 调度层把定时任务当成有状态的服务调度是整个“艾非”里最不性感但最要命的部分。我见过太多脚本逻辑写得漂漂亮亮结果因为“跑了两遍”或者“上一遍还没跑完又起了新的一遍”而数据错乱。我的做法是给调度层加三样东西锁、水位、日志。锁保证同一时刻只有一个实例在跑水位记录“上次成功处理到哪”下次从这里继续日志记录每次运行的开始结束时间、处理条数、耗时。三样加起来不到五十行代码但把 90% 的“玄学问题”挡在了门外。注意锁一定要有超时和强制释放机制。我遇到过进程被系统杀掉、锁没释放、后面几天全都不跑的情况排查了半天才发现是锁的问题。锁文件里写进程号和获取时间超过阈值就允许抢占这个兜底必须有。3. 清洗规则里藏着最多的隐性坑3.1 时间字段时区、格式与缺失值的三重陷阱时间字段是我踩坑最多的地方没有之一。第一个坑是格式不统一同一个源里既有2024/01/05也有2024-1-5还有20240105。用带严格格式的解析会直接抛异常用宽松解析又可能把01052024这种歧义格式解错。我的最终方案是先按格式白名单逐个试全部失败就记成异常行并带上原始值绝不猜测。猜错的时间比缺失的时间危害大得多因为它会静默地流到下游。第二个坑是时区。不同来源的时间有的带时区偏移有的不带有的干脆是“本地时间”但没说哪个本地。这个必须和数据的提供方确认清楚不能靠猜。确认之后统一转成一个基准时区存储展示的时候再转回来。我吃过一次亏某源的时间实际是另一个时区我按本地时间处理结果所有记录整体偏了几个小时影响了按小时聚合的统计查了两天才定位到。第三个坑是缺失值。时间缺失和“当天零点”在存储上很容易混淆尤其当你把时间转成时间戳的时候缺失常常变成 0 或者 1970 年。我的处理是时间字段缺失一律记为None并且在校验环节把“关键时间字段缺失率”作为一个指标盯着一旦超过阈值就告警。3.2 数值字段精度、单位与不可见字符数值的坑比时间隐蔽。精度问题最典型用浮点数存金额两笔一加就出来0.30000000000000004下游再一比对就判不等。我全部换成定点小数类型从解析到计算到输出全程不碰浮点这个问题彻底消失。单位问题更隐蔽。同一个字段有的源单位是“元”有的是“分”有的甚至是“万元”。这个不能靠数值大小去猜必须在适配函数里显式乘除并且在标准字段名里带上单位比如amount_yuan而不是amount。名字带单位之后任何人看一眼就知道要不要转换减少了很多沟通成本。不可见字符是个容易被忽略的细节。从表格复制出来的数字后面经常带着不换行空格或者零宽字符肉眼完全看不出来int()直接抛异常。我的做法是在归一化层统一做一遍清洗去掉首尾空白、去掉所有不可见字符、把全角数字转半角。这一步加上去之后那类“明明看着是数字却转不了”的报错基本绝迹了。3.3 文本字段编码与空值语义文本字段的问题集中在两处编码和空值语义。编码方面导出的文件有的带 BOM、有的不带有的干脆是别的编码读进来第一行字段名前面多个不可见字符你怎么都对不上。我的处理是读取时先探测、失败再指定、并且无条件去掉 BOM。空值语义是更麻烦的事。文本字段里的空可能表示“没有值”也可能表示“有值但是空字符串”还可能表示“不适用”。这三个含义在下游处理完全不同。我的做法是在适配层就把它们区分开没有值的记None明确空字符串的记不适用的记一个约定的特殊标记。区分之后统计“有多少条缺失”才有意义。还有一类同一个值有多种写法。比如渠道字段有“线上”“线上渠道”“Online”三种写法其实是一个东西。这个必须建一张映射表在归一化层统一映射表之外的取值一律进异常队列等人处理不能自动归到“其他”里——归到“其他”就等于把这个新情况藏起来了等到统计报表对不上才发现就晚了。3.4 用规则表代替散落各处的 if写到第四个清洗规则的时候我意识到代码里全是 if而且规则和规则之间开始互相影响。于是我把清洗规则抽成了一张规则表每条规则有名字、作用字段、判断条件、处理动作、优先级。执行引擎按优先级逐条应用每条规则的命中情况都记日志。这么做的好处有三个。一是规则可读一张表看下来就知道数据经历了什么处理。二是可开关某条规则出问题可以单独关掉验证。三是可统计哪条规则命中最多、哪条几乎没命中过一目了然后者往往意味着规则写错了或者场景已经变了。规则表的形式不必很复杂一个列表套字典就够RULES [ {name: trim_all, field: *, action: strip}, {name: amount_sign, field: amount_yuan, action: decimal}, {name: channel_map, field: channel, action: lookup, table: CHANNEL_MAP}, {name: drop_dup_id, field: id, action: dedup, keep: last}, ]提示去重规则的“保留第一条还是最后一条”必须明确写出来并且写进文档。我一开始默认保留第一条后来发现业务上应该以最新的为准改过来的时候历史数据已经产出了只能重跑。4. 失败处理重试不是万能药4.1 区分可重试与不可重试失败处理最常见的错误做法是“失败就重试三次”。这个做法之所以危险是因为它把两类完全不同的失败混为一谈暂时性失败网络抖动、目标文件被占用重试有用确定性失败数据格式错误、字段缺失、映射表里没有这个值重试一万次结果都一样只会浪费时间、放大日志、掩盖问题。我的分类标准很简单异常信息里能明确指向“数据内容有问题”的一律不重试直接进失败队列异常指向“外部资源暂时不可用”的才重试。重试还要带指数退避间隔逐次拉长并且设一个总时长上限超过就放弃并告警。失败类型典型表现处理方式暂时性目标文件被占用、读取超时指数退避重试最多三次确定性字段缺失、类型转换失败、映射不存在不重试进失败队列系统性磁盘满、权限不足、配置错误立即停止并告警人工介入这个表贴在代码注释里每次加新的异常处理都对照一下能避免很多“重试把问题掩盖了”的情况。4.2 幂等键怎么设计“跑两遍会不会出问题”这个问题本质上取决于幂等键设计得好不好。我的做法是给每条记录算一个稳定键由业务主键加关键字段组合而成同一份数据无论跑多少次键都一样。有了稳定键重复处理就是“覆盖”而不是“追加”天然幂等。稳定键的设计有两个原则。一是只包含不会变的字段比如创建时间不该算进去因为不同源给的时间精度可能不同。二是拼接前统一做归一化否则A1和a1会被当成两条。我一开始就漏了大小写统一导致重复数据多了一批。4.3 失败队列与人工介入失败队列是我认为“艾非”里最有价值的设计之一。任何一条处理不了的记录都不会被静默丢弃而是连同原始内容、失败原因、失败时间一起进队。队列每天汇总一次有人看一眼就知道今天有多少条需要处理、都是什么原因。队列还有一个隐性作用它是数据质量的温度计。队列长度突然变长通常意味着上游数据源结构变了。我遇到过上游悄悄改了一个字段名适配层没匹配上当天失败队列从几条涨到几百条一眼就看出来了。如果当初设计成“匹配不上就跳过”这个问题可能要等到报表对不上才被发现。5. 校验与告警让系统自己喊疼5.1 数据质量校验的四个层次校验不能只做“有没有报错”这一层。我把校验分成四层每层关注的东西不一样结构层字段是否齐全、类型是否正确、行数是否在合理范围内容层关键字段的空值率、数值的分布是否异常、枚举值是否都在白名单里一致性层同一份数据内部是否自洽比如明细汇总是否等于总计时效层数据是否是最新的、延迟是否在容忍范围内四层里最容易忽略的是一致性层。我加了一个很简单的检查明细条数乘平均单价应该约等于总金额。这个检查抓到过一次上游只传了部分明细、但汇总字段没变的问题如果没有这个检查错误数据会直接流到下游。内容层的空值率检查也有讲究不能设成一个固定值要按字段分别设。id 字段空值率应该是 0备注字段空 80% 都正常。用同一个阈值卡所有字段要么误报太多要么该报的没报。5.2 告警的噪音控制告警做不好会走向反面天天响响到没人看。我踩过这个坑第一版“艾非”每天发十几条消息一周之后我自己都不看了。后来做了三件事把噪音降下来第一分级。只有“数据完全没产出”和“关键校验失败”才发即时消息其余的都进日报。第二合并。同一个原因导致的失败合并成一条带上影响条数而不是每条记录发一次。第三抑制。同一个告警在冷却期内不重复发避免连续失败时被刷屏。改造之后消息量从每天十几条降到每周两三条但每一条都是真的需要人看的。这个比例我自己比较满意。6. 踩坑实录三个真实场景的排查链路6.1 每天少几条记录现象很怪产出文件里的记录数总是比输入少几条而且少的条数每天不一样。第一反应是去重规则误杀了检查了一遍稳定键的拼接逻辑没发现问题。第二步是加日志把每条被丢弃的记录和丢弃原因打出来发现被丢的大多是金额为空的行。继续往下查发现空金额的行在清洗环节被转成了None然后在“剔除无效行”那一步被当成无效数据删了。但这个判断本身是错的——金额为空不代表这条记录无效可能只是还没结算。根因找到了清洗规则把“缺失”和“无效”混为一谈了。修复方案是把“剔除无效行”的规则改窄只剔除稳定键为空的行其余缺失一律保留并在校验层统计。同时把这次的经验写进了规则表任何“删除”动作都必须能说清楚删掉的是什么语义不能只写“剔除异常”。6.2 内存逐步上涨跑得越久内存占用越高跑到第三天直接把机器拖垮。这类问题的排查顺序应该是先确认是数据处理本身的量涨了还是资源没释放。我看了一下输入数据量几天基本持平那就排除第一种。第二步是看处理逻辑里有没有累积结构。翻代码发现有一处把“已处理的 id”放在一个集合里本意是做去重但每处理一条就往里加一条而且从来不清。数据量大的时候这个集合能吃掉好几个 G。改成只保留最近一个窗口内的 id并且定期清理内存就平了。这个坑的教训是任何随处理量线性增长的结构都要警惕尤其是“用来去重”“用来缓存”的那种写的时候觉得无所谓跑久了才知道疼。6.3 输出文件被下游反复读取有个下游反馈说同一批数据被处理了两次。查下来不是“艾非”跑了两次而是下游在我们还没写完的时候就来读了读到了半个文件。原因是我们的写入方式是先删旧文件再写新文件中间有个空窗期。改成“写临时文件 → 校验通过 → 原子替换”之后就再没出现过。这个方案的代价是临时文件会占一点额外空间但换来的确定性非常值。顺带说一句原子替换这个动作在不同的文件系统上行为不完全一样跨盘替换要特别注意最好保证临时文件和目标文件在同一个目录下。7. 演进从脚本到小系统的分界线“艾非”从脚本变成现在这个样子中间有过几次明显的分界。第一次是加归一化层之前每接一个源都要改业务代码之后只需要写一个适配函数。第二次是加规则表之前规则散在各处、改一处影响一片之后规则可以独立开关和统计。第三次是加失败队列之前错误是“抛出来就完事”之后错误变成了“可追踪、可复盘”的东西。这三次分界有一个共同的判断标准当某类改动开始频繁发生、并且每次都要动很多地方的时候就该抽象了。我不是一开始就设计好这些的都是被逼出来的。所以如果你现在手上有一个能跑但很乱的脚本我的建议不是推倒重写而是盯着“改起来最烦的那一处”把它单独抽出来。抽一次痛感降一档抽两三次之后你会发现它自己就长成了一个还算能看的小系统。我个人在实际操作中的体会是这类工具最怕的不是功能少而是行为不可预测。宁可少做几件事也要保证每一件事的结果是确定的、可复现的、出问题能查到的。我后来又给“艾非”加过一个功能每次运行结束除了一份产出文件还会生成一份简短的运行报告记录本次处理了多少条、丢弃了多少条、校验通过率是多少。这份报告我几乎每天都会扫一眼它比任何复杂的监控都更早地告诉我“今天的数据是不是有点不对劲”。
“艾非”这两个字第一次出现在我的便签上时后面跟的不是什么需求文档而是一句很难听的吐槽——同一份数据我一周之内手工合并了四遍每遍都在同样的几个地方翻车。那会儿它还不叫项目,就是一个躺在桌面、文件名带着三个版本号后缀的脚本。半年之后这个代号变成了我每天真正在用的东西定时取数、清洗、校验、产出格式稳定的文件出问题了它自己发消息告诉我。这篇就把“艾非”这套东西从临时脚本长成小系统的完整过程摊开讲一遍包括骨架怎么搭、规则怎么写、失败怎么兜、以及那几个让我返工好几次的坑。适合手上有重复性数据处理工作、又不想一上来就上重框架的人看代码基础薄弱一点也能跟下来。1. 一个只有代号的项目通常从“忍无可忍”开始1.1 重复劳动才是真正的技术债很多人一说技术债就想到代码写得烂、架构不合理但在我看来真正吃掉时间的债是重复劳动。我做过统计那段时间我每周花在手动合并数据上的时间是六到八小时其中至少一半耗在“上一次是怎么做的”这种回忆上。手工操作最大的问题不是慢是不一致今天记得去掉空行明天忘了这次用左连接下次手滑用了内连接结果少了一批记录还浑然不觉。“艾非”最初的目标非常朴素——把这套流程固化下来让机器按同一个标准重复执行。注意这里的关键词是“同一个标准”不是“更快”。速度是副产品一致性才是刚需。我当时给自己定了一条判断标准同一份输入无论跑多少次、隔多久跑产出必须完全一样。这条标准后来救了我很多次因为它直接排除了大量“看起来方便、实际上不可复现”的做法比如手工在表格里改两行、比如依赖某个临时文件的当前状态。起代号这件事本身也有讲究。我不建议用“数据同步脚本v2”这类描述性名字原因很实际描述性名字会随着功能变化而变得名不副实进而没人愿意改它。而一个无意义的代号是“空”的它可以承载任何功能演进也不会因为名字和实现对不上而误导后来的人。当然代号要短、要好念、要能在命令行里快速敲出来这三点比含义重要得多。1.2 先画数据流再选工具动手写第一行代码之前我做了一件现在看非常值的事拿一张纸把数据从哪来、经过哪几步、到哪去画成一条线。画完之后我发现整个流程其实是四个彼此独立的环节取数从导出文件、接口返回、日志目录三个地方拿数据清洗统一字段名、统一格式、处理缺失和异常校验检查条数、关键字段是否为空、数值是否在合理区间产出写成固定格式的文件放到约定位置这条线一画出来工具选型就变得简单了。取数和产出是 IO用什么库差别不大清洗和校验是纯逻辑应该写成不依赖外部状态的纯函数这样才好测。真正需要谨慎的是调度——什么时候跑、跑失败了怎么办这部分最容易出问题也最容易被忽略。提示如果你现在手上的脚本超过两百行、并且开始出现“这一段不能乱动”的注释基本可以判断它需要按数据流拆成几个环节了。拆的粒度不用很细四到六个环节足够再多就是给自己找麻烦。2. 骨架先行把“艾非”拆成四个可独立验证的环节2.1 输入层先统一“形状”再谈业务输入层最容易犯的错是拿到数据就直接开始写业务逻辑。我第一版就是这么干的结果每接一个新数据源就要在业务代码里加一堆 if 判断“这个源的时间字段叫 date 还是 time”。改到第三个源的时候我受不了了加了一个归一化层所有输入进来之后第一件事是转成统一的内部结构字段名、类型、顺序全部对齐业务逻辑只认这一种结构。具体做法很土但很有效——给每个数据源写一个小的适配函数只负责一件事把原始数据映射成标准字段。标准字段我先定了七八个够用就行后来陆续加过两个。适配函数长这样def adapt_export_file(path): raw read_table(path) return { id: str(raw[编号]).strip(), occurred_at: parse_time(raw[日期], fmt%Y/%m/%d), amount: to_decimal(raw[金额]), channel: normalize_channel(raw[渠道]), source: export, }这个函数没有任何业务判断只做形状转换。好处是它可以单独测——给一份样本断言输出字段齐全、类型正确几行代码就能覆盖。等三个源的适配函数都写完并且都通过测试之后我才开始碰清洗逻辑这时候业务代码里已经看不到“这个源叫什么字段”这类分支了。这里有个细节值得说归一化层要把“源”也作为一个字段保留下来。我一开始觉得没必要反正合并之后都一样。后来排查问题才发现没有来源标记出问题的时候根本不知道该去看哪个源的原始数据只能三个源挨个翻。2.2 处理层用纯函数换取可测试性清洗逻辑我坚持写成纯函数也就是输入进来、输出出去中间不读文件、不写数据库、不看系统时间。这条约束听起来麻烦但收益非常直接任何一个清洗规则都可以用几行数据当场验证不需要准备环境、不需要造文件。举个例子金额字段的清洗规则是“去掉千分位逗号、去掉货币符号、转成定点小数、负数保留”。写成纯函数之后测试是这样的def test_amount(): assert clean_amount(1,234.50) Decimal(1234.50) assert clean_amount(88) Decimal(88) assert clean_amount(-3.10) Decimal(-3.10) assert clean_amount() is None这四个断言覆盖了我在真实数据里遇到过的全部形态包括那个让我栽过跟头的空字符串。写测试的时候不觉得有什么等数据源换了、规则要改的时候跑一遍测试就知道有没有改坏这个安心感是花钱买不到的。纯函数还有一个隐性好处它逼你把“规则”和“执行”分开。规则是clean_amount里那几行判断执行是“读文件、逐行调用、写文件”。后者几乎不用改前者可以单独演进。我后来加“科学计数法转普通小数”这条规则只动了纯函数外层一行没改。2.3 输出层格式稳定比功能丰富更重要输出层我踩过一个典型的坑一开始我追求“输出好看”加了很多格式化、分组、小计行。结果下游读的时候各种出错因为它们依赖列的位置而我某次调整顺序就把它们全搞崩了。后来我把输出层的原则改成了三条一直没再变过原则具体做法原因列顺序固定按常量列表输出不随数据变化下游按位置读的很多类型固定金额一律定点小数、时间一律统一格式字符串避免下游再做类型判断空值显式缺失写明确规定过的占位符不留空空单元格在不同工具里含义不同第三条尤其重要。空单元格在有的工具里是空字符串在有的工具里是 null在有的工具里直接被当成 0同一份文件在不同下游手里能读出三种结果。所以空值必须显式写成一个约定过的标记并且这个约定要写进文档、写进代码注释、写进产出文件的头部说明三处都写。还有一点输出文件我坚持“整份重写”不做增量追加。增量追加看起来省时间但一旦某次跑到一半失败文件就处于半新半旧的状态非常难查。整份重写配合“先写临时文件、校验通过再原子替换”的做法虽然慢一点点但永远不会留下坏文件。2.4 调度层把定时任务当成有状态的服务调度是整个“艾非”里最不性感但最要命的部分。我见过太多脚本逻辑写得漂漂亮亮结果因为“跑了两遍”或者“上一遍还没跑完又起了新的一遍”而数据错乱。我的做法是给调度层加三样东西锁、水位、日志。锁保证同一时刻只有一个实例在跑水位记录“上次成功处理到哪”下次从这里继续日志记录每次运行的开始结束时间、处理条数、耗时。三样加起来不到五十行代码但把 90% 的“玄学问题”挡在了门外。注意锁一定要有超时和强制释放机制。我遇到过进程被系统杀掉、锁没释放、后面几天全都不跑的情况排查了半天才发现是锁的问题。锁文件里写进程号和获取时间超过阈值就允许抢占这个兜底必须有。3. 清洗规则里藏着最多的隐性坑3.1 时间字段时区、格式与缺失值的三重陷阱时间字段是我踩坑最多的地方没有之一。第一个坑是格式不统一同一个源里既有2024/01/05也有2024-1-5还有20240105。用带严格格式的解析会直接抛异常用宽松解析又可能把01052024这种歧义格式解错。我的最终方案是先按格式白名单逐个试全部失败就记成异常行并带上原始值绝不猜测。猜错的时间比缺失的时间危害大得多因为它会静默地流到下游。第二个坑是时区。不同来源的时间有的带时区偏移有的不带有的干脆是“本地时间”但没说哪个本地。这个必须和数据的提供方确认清楚不能靠猜。确认之后统一转成一个基准时区存储展示的时候再转回来。我吃过一次亏某源的时间实际是另一个时区我按本地时间处理结果所有记录整体偏了几个小时影响了按小时聚合的统计查了两天才定位到。第三个坑是缺失值。时间缺失和“当天零点”在存储上很容易混淆尤其当你把时间转成时间戳的时候缺失常常变成 0 或者 1970 年。我的处理是时间字段缺失一律记为None并且在校验环节把“关键时间字段缺失率”作为一个指标盯着一旦超过阈值就告警。3.2 数值字段精度、单位与不可见字符数值的坑比时间隐蔽。精度问题最典型用浮点数存金额两笔一加就出来0.30000000000000004下游再一比对就判不等。我全部换成定点小数类型从解析到计算到输出全程不碰浮点这个问题彻底消失。单位问题更隐蔽。同一个字段有的源单位是“元”有的是“分”有的甚至是“万元”。这个不能靠数值大小去猜必须在适配函数里显式乘除并且在标准字段名里带上单位比如amount_yuan而不是amount。名字带单位之后任何人看一眼就知道要不要转换减少了很多沟通成本。不可见字符是个容易被忽略的细节。从表格复制出来的数字后面经常带着不换行空格或者零宽字符肉眼完全看不出来int()直接抛异常。我的做法是在归一化层统一做一遍清洗去掉首尾空白、去掉所有不可见字符、把全角数字转半角。这一步加上去之后那类“明明看着是数字却转不了”的报错基本绝迹了。3.3 文本字段编码与空值语义文本字段的问题集中在两处编码和空值语义。编码方面导出的文件有的带 BOM、有的不带有的干脆是别的编码读进来第一行字段名前面多个不可见字符你怎么都对不上。我的处理是读取时先探测、失败再指定、并且无条件去掉 BOM。空值语义是更麻烦的事。文本字段里的空可能表示“没有值”也可能表示“有值但是空字符串”还可能表示“不适用”。这三个含义在下游处理完全不同。我的做法是在适配层就把它们区分开没有值的记None明确空字符串的记不适用的记一个约定的特殊标记。区分之后统计“有多少条缺失”才有意义。还有一类同一个值有多种写法。比如渠道字段有“线上”“线上渠道”“Online”三种写法其实是一个东西。这个必须建一张映射表在归一化层统一映射表之外的取值一律进异常队列等人处理不能自动归到“其他”里——归到“其他”就等于把这个新情况藏起来了等到统计报表对不上才发现就晚了。3.4 用规则表代替散落各处的 if写到第四个清洗规则的时候我意识到代码里全是 if而且规则和规则之间开始互相影响。于是我把清洗规则抽成了一张规则表每条规则有名字、作用字段、判断条件、处理动作、优先级。执行引擎按优先级逐条应用每条规则的命中情况都记日志。这么做的好处有三个。一是规则可读一张表看下来就知道数据经历了什么处理。二是可开关某条规则出问题可以单独关掉验证。三是可统计哪条规则命中最多、哪条几乎没命中过一目了然后者往往意味着规则写错了或者场景已经变了。规则表的形式不必很复杂一个列表套字典就够RULES [ {name: trim_all, field: *, action: strip}, {name: amount_sign, field: amount_yuan, action: decimal}, {name: channel_map, field: channel, action: lookup, table: CHANNEL_MAP}, {name: drop_dup_id, field: id, action: dedup, keep: last}, ]提示去重规则的“保留第一条还是最后一条”必须明确写出来并且写进文档。我一开始默认保留第一条后来发现业务上应该以最新的为准改过来的时候历史数据已经产出了只能重跑。4. 失败处理重试不是万能药4.1 区分可重试与不可重试失败处理最常见的错误做法是“失败就重试三次”。这个做法之所以危险是因为它把两类完全不同的失败混为一谈暂时性失败网络抖动、目标文件被占用重试有用确定性失败数据格式错误、字段缺失、映射表里没有这个值重试一万次结果都一样只会浪费时间、放大日志、掩盖问题。我的分类标准很简单异常信息里能明确指向“数据内容有问题”的一律不重试直接进失败队列异常指向“外部资源暂时不可用”的才重试。重试还要带指数退避间隔逐次拉长并且设一个总时长上限超过就放弃并告警。失败类型典型表现处理方式暂时性目标文件被占用、读取超时指数退避重试最多三次确定性字段缺失、类型转换失败、映射不存在不重试进失败队列系统性磁盘满、权限不足、配置错误立即停止并告警人工介入这个表贴在代码注释里每次加新的异常处理都对照一下能避免很多“重试把问题掩盖了”的情况。4.2 幂等键怎么设计“跑两遍会不会出问题”这个问题本质上取决于幂等键设计得好不好。我的做法是给每条记录算一个稳定键由业务主键加关键字段组合而成同一份数据无论跑多少次键都一样。有了稳定键重复处理就是“覆盖”而不是“追加”天然幂等。稳定键的设计有两个原则。一是只包含不会变的字段比如创建时间不该算进去因为不同源给的时间精度可能不同。二是拼接前统一做归一化否则A1和a1会被当成两条。我一开始就漏了大小写统一导致重复数据多了一批。4.3 失败队列与人工介入失败队列是我认为“艾非”里最有价值的设计之一。任何一条处理不了的记录都不会被静默丢弃而是连同原始内容、失败原因、失败时间一起进队。队列每天汇总一次有人看一眼就知道今天有多少条需要处理、都是什么原因。队列还有一个隐性作用它是数据质量的温度计。队列长度突然变长通常意味着上游数据源结构变了。我遇到过上游悄悄改了一个字段名适配层没匹配上当天失败队列从几条涨到几百条一眼就看出来了。如果当初设计成“匹配不上就跳过”这个问题可能要等到报表对不上才被发现。5. 校验与告警让系统自己喊疼5.1 数据质量校验的四个层次校验不能只做“有没有报错”这一层。我把校验分成四层每层关注的东西不一样结构层字段是否齐全、类型是否正确、行数是否在合理范围内容层关键字段的空值率、数值的分布是否异常、枚举值是否都在白名单里一致性层同一份数据内部是否自洽比如明细汇总是否等于总计时效层数据是否是最新的、延迟是否在容忍范围内四层里最容易忽略的是一致性层。我加了一个很简单的检查明细条数乘平均单价应该约等于总金额。这个检查抓到过一次上游只传了部分明细、但汇总字段没变的问题如果没有这个检查错误数据会直接流到下游。内容层的空值率检查也有讲究不能设成一个固定值要按字段分别设。id 字段空值率应该是 0备注字段空 80% 都正常。用同一个阈值卡所有字段要么误报太多要么该报的没报。5.2 告警的噪音控制告警做不好会走向反面天天响响到没人看。我踩过这个坑第一版“艾非”每天发十几条消息一周之后我自己都不看了。后来做了三件事把噪音降下来第一分级。只有“数据完全没产出”和“关键校验失败”才发即时消息其余的都进日报。第二合并。同一个原因导致的失败合并成一条带上影响条数而不是每条记录发一次。第三抑制。同一个告警在冷却期内不重复发避免连续失败时被刷屏。改造之后消息量从每天十几条降到每周两三条但每一条都是真的需要人看的。这个比例我自己比较满意。6. 踩坑实录三个真实场景的排查链路6.1 每天少几条记录现象很怪产出文件里的记录数总是比输入少几条而且少的条数每天不一样。第一反应是去重规则误杀了检查了一遍稳定键的拼接逻辑没发现问题。第二步是加日志把每条被丢弃的记录和丢弃原因打出来发现被丢的大多是金额为空的行。继续往下查发现空金额的行在清洗环节被转成了None然后在“剔除无效行”那一步被当成无效数据删了。但这个判断本身是错的——金额为空不代表这条记录无效可能只是还没结算。根因找到了清洗规则把“缺失”和“无效”混为一谈了。修复方案是把“剔除无效行”的规则改窄只剔除稳定键为空的行其余缺失一律保留并在校验层统计。同时把这次的经验写进了规则表任何“删除”动作都必须能说清楚删掉的是什么语义不能只写“剔除异常”。6.2 内存逐步上涨跑得越久内存占用越高跑到第三天直接把机器拖垮。这类问题的排查顺序应该是先确认是数据处理本身的量涨了还是资源没释放。我看了一下输入数据量几天基本持平那就排除第一种。第二步是看处理逻辑里有没有累积结构。翻代码发现有一处把“已处理的 id”放在一个集合里本意是做去重但每处理一条就往里加一条而且从来不清。数据量大的时候这个集合能吃掉好几个 G。改成只保留最近一个窗口内的 id并且定期清理内存就平了。这个坑的教训是任何随处理量线性增长的结构都要警惕尤其是“用来去重”“用来缓存”的那种写的时候觉得无所谓跑久了才知道疼。6.3 输出文件被下游反复读取有个下游反馈说同一批数据被处理了两次。查下来不是“艾非”跑了两次而是下游在我们还没写完的时候就来读了读到了半个文件。原因是我们的写入方式是先删旧文件再写新文件中间有个空窗期。改成“写临时文件 → 校验通过 → 原子替换”之后就再没出现过。这个方案的代价是临时文件会占一点额外空间但换来的确定性非常值。顺带说一句原子替换这个动作在不同的文件系统上行为不完全一样跨盘替换要特别注意最好保证临时文件和目标文件在同一个目录下。7. 演进从脚本到小系统的分界线“艾非”从脚本变成现在这个样子中间有过几次明显的分界。第一次是加归一化层之前每接一个源都要改业务代码之后只需要写一个适配函数。第二次是加规则表之前规则散在各处、改一处影响一片之后规则可以独立开关和统计。第三次是加失败队列之前错误是“抛出来就完事”之后错误变成了“可追踪、可复盘”的东西。这三次分界有一个共同的判断标准当某类改动开始频繁发生、并且每次都要动很多地方的时候就该抽象了。我不是一开始就设计好这些的都是被逼出来的。所以如果你现在手上有一个能跑但很乱的脚本我的建议不是推倒重写而是盯着“改起来最烦的那一处”把它单独抽出来。抽一次痛感降一档抽两三次之后你会发现它自己就长成了一个还算能看的小系统。我个人在实际操作中的体会是这类工具最怕的不是功能少而是行为不可预测。宁可少做几件事也要保证每一件事的结果是确定的、可复现的、出问题能查到的。我后来又给“艾非”加过一个功能每次运行结束除了一份产出文件还会生成一份简短的运行报告记录本次处理了多少条、丢弃了多少条、校验通过率是多少。这份报告我几乎每天都会扫一眼它比任何复杂的监控都更早地告诉我“今天的数据是不是有点不对劲”。
