一、背景:被测试数据孤岛坑惨的良率工程师我做YE时,一次客户投诉某批次可靠性异常,要拉这个lot从CP到FT的全链路测试数据做分析。结果CP数据在测试机本地Excel、FT数据在另一套数据库、WIP在MES,三个来源格式还不一样。我对了整整一天才拼出一张表,客户都等急了,电话打了三个过来催。更常见的是:每周良率复盘,要手动从5台测试机各导一份Excel,合并、清洗、画趋势图,2小时没了。有次漏导了一台机的数据,良率算高了自己高兴,实际那台机的不良被掩盖,周后发现虚惊一场,但会上已经报了假的好数据,信誉受损。核心痛点是数据孤岛无统一元数据。每台机、每个系统对wafer/lot/程序版本/测试项的命名都不一致,人对不齐、机读不了。2023年我决定自己搭个轻量TDMS(Test Data Management System),不追求大平台,先把找得到、对得齐、查得快解决。说实话,搭之前我也犹豫:是不是该申请采购现成系统?但一问报价和周期(半年起步),我就放弃了。一个周末自己撸一个,先把痛点解了,万一不好用再考虑别的。结果这一撸就用到现在。二、技术原理:轻量TDMS长什么样重型TDMS(如Camstar、自主开发的Web系统)功能全但重,部署周期长、需要专职运维,小团队玩不起。我的思路是够用就好:用SQLite做统一元数据库,测试原始数据按lot存文件,库里只存索引和关键结果,检索快、存储省、单机可跑。核心是统一的元数据模型:每条测试记录必须有 wafer_id、lot_id、device、test_program(版本)、equipment、test_type(CP/FT)、test_time、关键参数结果。不同来源进来先映射到这个模型,命名就一致了,后续分析不用再为每个来源写适配。为什么用SQLite而不是MySQL?因为单机、零部署、文件即数据库,复制带走就能用,换新电脑拷文件就行。数据量上亿行时SQLite会变慢,但中小FAB的测试数据(千万级)完全够。真不够再迁PostgreSQL,模型不变,迁移成本低。检索用SQL:查某lot全链路、查某device近30天良率趋势、查某测试项超spec的分布,一条SELECT搞定,秒级返回。比翻Excel快100倍,且不会漏。对比重型方案,轻量TDMS牺牲了并发和权限细粒度,但换来了一个周末能搭起来、零成本、自己完全掌控。对小团队,这是最优解--先解决80%的痛点,剩下20%等规模上来再说。一个设计取舍:元数据存库、原始数据存文件。有人会问为什么不直接全存库?因为原始测试数据动辄几GB,全进SQLite会拖慢查询。拆开后,库轻、检索秒级,原始文件按需读取,各取所长。关于统一的度:元数据模型不要追求一步到位覆盖所有字段,先覆盖检索和分析必须的5个,其余按需补。过度设计会让导入器复杂到没人愿意维护。三、实战:一个周末搭起来的系统落地分四步,全是Python,边写边测:第一步,写导入器 importer.py。针对每台测试机的不同格式(CSV/Excel/设备专有格式),写适配器把数据映射成统一模型,写进SQLite。新增设备就加一个适配器,不影响其他。适配器模式让系统可扩展。第二步,建库 schema。建tests表(元数据关键结果)、wafers表、lots表,建索引加速检索。原始大数据存parquet文件,库里只留路径和摘要,库轻、检索快。第三步,写查询接口 query.py。封装常用查询:by_lot、by_device_trend、by_test_item。分析师不用写SQL,调函数就行,降低使用门槛,组内其他人也能用。第四步,可视化。query结果直接喂matplotlib画良率趋势、参数分布、wafer map。一次分析从对一天变成跑一条命令5分钟出图,效率提升量级明显。上线后第一次客户投诉,我5分钟拉出全链路数据,客户当场认可响应速度。每周复盘也从2小时变20分钟,且再没漏过数据--导入时强制校验元数据,不齐就不收。四、为什么要这样写代码这段代码是统一导入的核心。用INSERT OR REPLACE保证重复导入不报错(测试数据常因重测而重传),ON CONFLICT按lot_idtest_type判重,避免主键冲突打断整批导入。适配器模式(不同设备不同parse函数)让系统可扩展:新设备只需加一个parse_xxx函数并注册,主流程不动。这是开闭原则的实战应用,也是TDMS能从一个周末的小工具长成日常系统的原因。元数据与原始数据分离存储,库轻、检索快;原始数据留文件可追溯。权衡了查询便利和存储成本,也是SQLite能扛住的关键。五、效果对比:从对一天到5分钟搭TDMS前后,单次全链路分析从1天→5分钟,周度良率复盘从2小时→20分钟,且数据完整性从可能漏变成必全(导入时强制校验元数据,漏导直接告警)。隐性收益是分析深度:以前来不及做,现在5分钟出图,我开始做以前想做没做的跨设备参数相关性分析,还真挖出过一个测试程序版本导致的隐性良率损失(某版本CP程序漏测了一项,导致不良流到FT才暴露)。这种发现,靠手工对数据是永远做不到的。ROI角度:这个系统一个周末搭成,零软件成本,省下的是YE每周2小时乘常年。按工程师时薪折算,一年隐性收益就有大几万,更别说几次客户投诉的快速响应带来的口碑。六、实施建议:先定标准再写代码1. 先定元数据标准:wafer/lot/device/程序版本/测试类型这五个字段必须先统一,这是TDMS的地基,不定后面全乱。我花了一天和测试组对齐这五个字段的定义。2. 导入即校验:数据进库前强制校验元数据完整性,缺字段就拒收并告警,别等查询时才发现对不齐。宁可少收,不能收错。3. 原始数据留底:统一模型只存摘要,原始文件必须留(parquet/原文件),出问题可回查,也满足客户审计要求。4. 从一个测试类型起步:先接CP或FT一种,跑顺再扩,别一上来想接全厂所有机台,容易卡在适配器细节里。5. 备份库文件:SQLite是单文件,定时拷到网络盘,丢了就一无所有。我设了每天凌晨自动备份到NAS。6. 封装查询函数:别让同事写SQL,封装成by_lot/by_device这种函数,降低使用门槛,系统才用得起来。推广时降低门槛:写好README和示例,让测试组的人也能自助查,系统才活起来。只你自己会用的工具,迟早随你忙而荒废。七、进阶方向:从孤岛到闭环轻量TDMS下一步是接自动流转:测试机做完自动推数据到系统,不用人工导。这需要测试机开放接口或加一个监听程序,技术上不难,难在和测试组协调流程。再进一步,TDMS和YMS(良率管理系统)、FDC打通,测试异常自动触发FDC分析、良率自动归集,形成闭环。那是大厂玩法,小团队可以分步靠近--先把TDMS这环做实。数据量上亿时,把SQLite迁到PostgreSQLDuckDB做分析,模型不变,平滑升级,前期投资不浪费。数据多了之后,可以加一层自动洞察:比如某device良率连续3天下滑自动标红并推送给YE,不用人每天盯着趋势图。这是TDMS从仓库变哨兵的关键一步。再远一点,TDMS沉淀的数据是训练良率模型的金矿。我们后来直接用TDMS里的标准化数据训了良率预测模型,数据清洗时间从两周降到两天,TDMS的价值从这开始滚雪球。效果对比方案部署成本检索速度扩展性适合规模Excel手工0极慢(翻找)无个人轻量TDMS(SQLite)低秒级中(适配器)中小FAB重型TDMS高快强大厂完整代码import sqlite3, pandas as pdcon sqlite3.connect(tdms.db)con.execute(CREATE TABLE IF NOT EXISTS tests(lot_id TEXT, wafer_id TEXT, device TEXT, test_type TEXT,program_ver TEXT, equipment TEXT, test_time TEXT,yield REAL, raw_path TEXT,PRIMARY KEY(lot_id, test_type, program_ver)))con.commit()def import_test(df, raw_path):df[raw_path] raw_pathdf.to_sql(tests, con, if_existsappend, indexFalse, methodmulti)print(f导入 {len(df)} 行 - {raw_path})trend pd.read_sql(SELECT test_time, AVG(yield) FROM testsWHERE deviceABC123 AND test_typeCPGROUP BY test_time ORDER BY test_time, con)print(trend.head())━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 发布后复制到评论区:你在FAB里遇到过模型上线后悄悄变差的情况吗?或者有哪些数据质量的坑?欢迎在评论区聊聊你的真实经历,我会一一回复。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 本文配套VIP资源:相关工具已打包上传CSDN资源区(关注后可直接下载)。更多半导体AI实战工具,关注我持续更新。 关注我,持续分享半导体智能制造一线实战。