[公开] 半导体数据湖落地：把电性数据、设备日志与缺陷图片装进同一套体系

【摘要】失效分析要同时看WAT电性、CP测试、设备日志、AOI缺陷图和FA报告，但这些数据分散在五套系统里，格式从数值表到图片到PDF都有。本文讲清数据湖与数仓的边界、开放表格式如何解决schema演进与ACID、非结构化数据用指针加特征的注册表模式怎么设计，并给出小文件治理、时间对齐、权限分层的完整落地方案与一个八英寸厂的改造数据。

分类：数据工具 | 发布：2026-08-17 | 首发：半导体智能制造博客

一、背景故事：一次真实的产线事件

去年秋天我们接了一个失效分析任务，客户端返回了三十片有异常的晶圆，要求四周内给出根因。任务本身不复杂，难的是取数。要看的东西包括：WAT电性参数，在测试数据库里；CP测试的die级Bin数据，在另一套测试系统；这三十片的加工履历，在MES；关键工序的设备日志，在各自的设备服务器上，有的只保留三十天；AOI的缺陷图片，在一台文件服务器的共享目录里，按日期建文件夹；过去半年类似问题的FA报告，是一堆PDF，散在几个人的个人网盘里。

实际执行下来，光是把这些数据凑到一起就用了三周。最耗时的不是查询，是对齐。MES里的批次号带前缀，测试系统里不带；AOI图片的文件名是设备自己生成的时间戳序列，要靠时间窗口去猜对应哪一片；设备日志的时间戳是机台本地时间，而机台时钟半年没校准，和MES差了四十七秒。最后一周才真正开始分析，结论虽然找到了，但过程完全谈不上体面。

会后复盘，大家的第一反应是买个平台。我当时提了一个不同的看法：这件事的本质不是缺工具，而是我们从来没有为"跨源分析"这个场景设计过数据的组织方式。现有的每套系统都是为自己的业务闭环设计的，MES管流程、测试系统管测试、AOI管检测，它们各自都做得不错，但没有任何一层负责让它们能被一起查询。买平台如果不解决主键、时间和元数据这三件事，只会得到一个更贵的文件服务器。

后来我们用了大约五个月做了一套数据湖，把结构化的电性与测试数据、半结构化的设备日志、非结构化的缺陷图片与报告文档统一到同一套访问体系下。这篇文章写的是这套东西的设计思路和落地细节，包括为什么选开放表格式、非结构化数据到底怎么进湖、小文件问题怎么治，以及权限和出口管控要注意什么。

二、技术原理：把机制讲清楚

先厘清三个容易混淆的概念。数据仓库要求写入时就确定schema，数据必须先清洗成规范结构才能入库，优点是查询快、口径统一，缺点是新类型数据进不来，尤其是图片和文档这类非结构化数据根本无处安放。数据湖走的是另一条路，原始数据先按原样落到对象存储，读取时再解释结构，好处是什么都能进，坏处是很容易退化成一个没人敢用的数据沼泽。湖仓一体是这几年的收敛方向，核心做法是在对象存储之上加一层开放表格式，让湖里的数据也具备表的语义。

开放表格式解决的是三个具体问题。第一是事务一致性，没有它的时候，一个写入作业跑到一半失败，读的人会看到半截数据；有了表格式，写入通过快照原子切换，读者要么看到旧快照要么看到新快照，不会看到中间态。第二是schema演进，半导体产线的设备升级、配方增项是常态，今天这台机台的日志多了三个字段，表格式支持在不重写历史数据的前提下加列，老数据读出来对应位置是空值。第三是分区裁剪与时间旅行，按产品和日期分区后查询只扫描相关文件，而快照历史让"三个月前那份数据长什么样"这种审计问题变得可回答。

非结构化数据进湖的关键，是不要试图把图片和PDF本身塞进表里。正确的模式是指针加特征：文件本体存在对象存储的原始区，表里存的是一条注册记录，包含对象URI、内容哈希、文件类型、大小、来源系统、采集时间，以及最重要的一组关联主键。在这条记录之上再挂两类派生信息：一类是提取出的结构化特征，比如AOI缺陷图的缺陷坐标、面积、类别、置信度，FA报告里抽取的失效模式与结论；另一类是向量表示，用于相似图片检索或语义搜索。这样一来，非结构化数据就获得了和结构化数据同等的可查询性，而不需要改变它本身的存储形式。

统一主键的设计是整套体系能不能用起来的分水岭。半导体数据的自然层级是产品、批次、晶圆、芯片位置，加上时间和设备两个正交维度。我们定义了一套规范化主键：产品族加工艺版本、标准化批次号、晶圆序号、die坐标，四层可以逐级下钻。所有入湖数据必须在接入层完成主键规范化，包括去掉各系统自带的前后缀、统一大小写、修正历史遗留的编号规则变更。这项工作枯燥但不可省略，它决定了后面所有join能不能做。

时间对齐是第二个隐形基础设施。机台本地时钟漂移、不同系统时区配置不一致、日志采集延迟，这三者叠加会让时间序列分析完全失真。我们的做法是建一张设备时钟校正表，定期用NTP参考时间与机台上报时间做差值记录，入湖时对所有设备时间戳做校正并同时保留原始值，再统一转成带时区的UTC时间存储。校正量本身也是一个有用的监控指标，某台机台的漂移速率突然变大，往往意味着主板电池或时钟模块该换了。

三、现状分析：多数工厂现在是怎么做的

第一档是文件服务器加Excel。测试数据导成CSV放共享盘，图片按日期建文件夹，报告存在个人目录。这套体系的优点是零门槛，缺点在数据量上来之后全面暴露：找一份两年前的数据要靠回忆当时的文件夹命名习惯，同一份数据存在五个版本谁都不知道哪个是准的，人员离职后他那部分数据基本等于消失。我见过一家厂的共享盘里有十一个名字里带final的文件夹。

第二档是传统数据仓库。通常是随MES或YMS一起建的，收结构化数据，做得好的还有星型模型和一致性维度，报表体系相当成熟。瓶颈在于它天然容纳不了非结构化数据，AOI图片、SEM照片、FA报告只能留在外面，于是形成了一个割裂：数值分析在数仓里做，图像和文档分析在数仓外做，两边无法关联。另一个瓶颈是schema变更成本，加一个字段要走变更流程，设备侧的字段更新频率远高于这个流程的响应速度。

第三档是采购商用数据平台。功能完整、有厂商支持，对没有数据团队的工厂是合理选择。需要提前想清楚的是三件事：一是数据格式是否开放，如果落地格式是私有的，未来迁移成本极高；二是半导体特有的数据模型能否表达，通用平台对die级数据和wafer map的支持往往需要定制；三是数据出口管控，半导体的工艺数据敏感度高，平台的权限模型能否满足内外部审计要求，这一项建议在选型阶段就让合规部门参与评估。

我们最后选的是自建，但用的全是开源组件，理由有三个：数据格式必须开放可迁移；需要深度定制die级数据模型；以及最现实的一条，数据不能出厂内网络，很多云端方案直接被排除。自建的代价是需要一个懂数据工程的人长期维护，如果厂里凑不出这样一个人，我的建议是不要自建，选一个格式开放的商用产品会更稳妥。

四、瓶颈问题：卡在哪里

第一个卡点是小文件风暴。设备日志按秒级采集，如果直接按到达顺序写文件，一天能产生两百多万个小文件。对象存储的元数据服务会被拖垮，查询引擎光是列举文件清单就要几十秒，实际读数据的时间反而是次要的。我们上线第一个月就撞上了这个坑，一个简单的按时间范围过滤查询跑了四十七秒，profile一看，四十一秒花在文件列举上。

第二个卡点是schema演进的连锁反应。某次设备厂商升级软件，日志里新增了七个字段并且改了两个字段的单位，下游有三个报表和两个模型直接失效。问题不在于变更本身，而在于没有任何机制在变更发生时通知下游。数据湖如果只有存储没有元数据治理，schema演进的自由度就会变成下游的风险源。

第三个卡点是非结构化数据的可发现性。图片进了对象存储，但如果只有一个URI，它和结构化数据之间就没有桥。我们早期的版本只做了文件登记，没有做特征提取和主键关联，结果是"找出这批晶圆边缘缺陷的所有AOI图"这种最基本的需求都满足不了，还是要靠人按时间去翻。非结构化数据入湖不等于可用，中间差的就是特征提取这一层。

第四个卡点是查询性能与成本的平衡。全量扫描代价高，但过度分区又会重新制造小文件。我们试过按小时分区，结果是低产量产品的分区里只有几十行数据，分区元数据的开销反而超过了数据本身。分区策略必须结合实际数据分布来定，不能照搬通用最佳实践。

第五个卡点是权限与出口管控。半导体工艺数据的敏感度分级很细，配方参数、良率明细、客户产品信息各有不同的可见范围。数据湖把数据集中之后，如果权限模型跟不上，等于把风险也集中了。我们在评审时被合规部门问住过一个问题：如果某人有整张表的读权限，他能否导出全部数据带走？当时答不上来，后来补了行级权限、列级脱敏和导出审计三层控制才通过。

五、解决方案：可落地的完整做法

存储分层用了四层。Raw层是原始落地区，保持数据源的原始格式与内容，只做压缩和分区，任何情况下不做修改，这一层的作用是可回溯，当下游发现口径问题时可以重新加工。Cleansed层做格式统一、主键规范化、时间校正、基础质量校验，输出为开放表格式的表。Curated层按分析主题建模，比如wafer级综合视图把电性、测试、履历、缺陷计数关联到一行。Serving层是面向具体应用的物化结果，包括看板用的聚合表和模型用的特征表。分层的价值不在于层数，而在于每一层的职责边界清晰，出问题时知道去哪一层查。

表格式选了Iceberg，主要看中三点：隐藏分区让查询者不需要知道分区字段就能享受分区裁剪，这对不熟悉数据工程的工艺工程师很友好；schema演进支持按字段ID而不是位置匹配，改名和加列都不会破坏历史数据；快照与时间旅行让审计和回溯变得简单。小文件治理的做法是双管齐下：写入侧做微批，把秒级数据攒到五分钟或者一百二十八兆再落盘；同时配一个每日的compaction作业，把小文件合并成目标大小的文件并清理过期快照。这两项做完，单日文件数从两百四十万降到八千左右。

非结构化数据用统一注册表模式。注册表是一张Iceberg表，字段包括对象URI、内容SHA256哈希、MIME类型、字节数、来源系统、采集时间、规范化的四层主键、业务时间、以及一个JSON列存放提取出的特征。哈希的作用是去重，我们实测AOI图片的重复率接近百分之十二，去重后存储成本立刻下来一截。特征提取按类型分流：AOI图走图像处理管线提取缺陷坐标、面积、类别；SEM图存尺寸测量结果；PDF报告走文本抽取加结构化解析，提取失效模式、涉及工序、结论与纠正措施。

元数据与血缘用一套目录服务统一管理。每张表登记owner、更新频率、字段字典、敏感级别；每个加工作业登记输入表与输出表，自动生成血缘图。schema变更走一个轻量流程：变更提交后系统自动查血缘找出所有下游消费者并发通知，非破坏性变更如加列可直接生效，破坏性变更如改类型必须下游确认后才允许。这套机制上线后，因schema变更导致的下游故障从一个季度五次降到零次。

权限做了三层。第一层是表级与列级权限，敏感列如配方参数对普通角色直接不可见；第二层是行级过滤，按产品线与客户归属自动限制可见范围，规则挂在用户组上而不是写在查询里；第三层是导出审计，任何超过阈值行数的结果集导出都会记录操作人、时间、查询语句和行数，并按周生成审计报表送合规。另外所有原始文件的下载都走带签名的临时URL，有效期十五分钟，避免链接被转发。

六、实战案例：一个完整的改造过程

落地对象是一家八英寸厂，产品以电源管理和模拟器件为主，月产能约三万五千片。数据源包括WAT电性、CP测试die级数据、十七类设备的日志、AOI缺陷图、SEM照片、以及历史FA报告PDF。项目总周期五个月，人力是一名数据工程师全职、一名IT运维半职、加上各领域工程师按需投入。硬件上没有新采购，用了两台退役下来的服务器搭对象存储，容量四十八TB。

第一个月做主键与时间的规范化，这是最不起眼但最关键的一个月。批次号规则梳理出十一种历史变体，包括两次编号规则调整和三个系统各自加的前缀，写成一张映射表加一段规范化函数。设备时钟校正发现一件事：十七类设备里有五类从投产起就没校过时，最严重的一台漂了三分十二秒。校正表建立后，跨系统事件的时间对齐误差从分钟级压到两秒以内。

第二到第三个月做接入与分层。结构化数据走批量抽取，日志走微批流式，非结构化文件通过一个扫描服务发现并登记。这里踩了一个坑：文件服务器上的AOI图片目录有大量断链和乱码文件名，扫描服务第一次跑直接卡死。后来改成分批扫描加错误隔离，把有问题的文件单独记录到一张异常表而不是中断整个作业，这才跑通。compaction作业也是在这个阶段上线的，效果立竿见影。

第四个月做特征提取与检索能力。AOI图的缺陷特征提取复用了产线原有的算法，只是把输出从设备本地文件改成写入注册表；FA报告的解析用了模板加规则的方式，因为报告格式历史上有四个版本，纯规则覆盖不了，最后是规则处理格式规整的部分，剩下约百分之十八的老报告靠人工补录关键字段。图片相似检索做了一个轻量版本，用缺陷区域的特征向量做近邻搜索，效果上能满足"找出历史上类似缺陷形态的案例"这个高频需求。

第五个月做权限、审计与推广。权限模型按前面说的三层实现，行级规则覆盖了产品线与客户两个维度。推广的策略是先选三个高频场景做成开箱即用的查询模板：批次全景查询、缺陷关联查询、设备日志时间窗查询，工程师填几个参数就能出结果，不需要写SQL。这一步很重要，如果上来就让工艺工程师学SQL，采用率一定上不去。三个月后统计，模板查询占了总查询量的百分之七十一。

七、实施效果：数据说话

最直接的效果在查询性能上。改造前跨系统取数基本靠人工搬运，无法用统一口径衡量；改造后以标准分析查询集做基准测试，P95响应时长从初期未治理状态的四十七秒降到三点一秒，其中小文件合并贡献最大，约占改善量的六成，分区策略优化和列裁剪贡献其余部分。需要说明的是这个数字是在同样硬件上取得的，没有增加任何计算资源，纯粹靠数据组织方式的优化。

业务侧的效果更有说服力。同类失效分析的平均定位周期从三周降到四天，其中取数环节从三周压缩到半天以内，剩下的时间真正花在分析上。全年来看，FA团队处理的案件量在人数不变的情况下增加了约百分之六十。另一个没有预期到的收益是历史案例的复用率，图片相似检索上线后，约有百分之二十三的新案件能在历史库里找到形态相近的先例，直接缩短了假设生成的时间。

存储与运维侧同样有改善。内容哈希去重清理了约百分之十二的重复图片，压缩与格式优化后总存储占用比原来分散存储时减少了三成。单日文件数从两百四十万降到约八千，对象存储的元数据服务压力大幅下降，之前每周都要重启一次的问题彻底消失。运维工时方面，因为schema变更导致的下游故障降到零，这一项过去平均每季度要消耗约四十个工时的救火时间。

最后说两点没做好的地方，供参考。第一是老FA报告的结构化，我们最终只完成了约百分之八十二，剩下的老格式报告投入产出比太低就放弃了，如果重来一次，我会在项目立项时就明确一个截止时间点，早于该时间的历史文档只做全文检索不做结构化解析，避免中途反复讨论。第二是工程师的数据素养建设启动太晚，查询模板虽然降低了门槛，但真正要发挥数据湖价值还是需要一部分人能自己写查询，这部分培训应该和平台建设并行，而不是等平台建好再开始。

八、常见问题答疑

Q：小厂数据量不大，有必要上数据湖吗，直接用一个数据库不行吗？

A：数据量不是判断依据，数据类型的异构程度才是。如果你的分析场景只涉及结构化的测试与电性数据，一个关系数据库加上规范的建模完全够用，而且运维成本低得多。真正需要数据湖的信号是：分析时必须同时用到图片、文档或半结构化日志；数据源的schema变更频繁；需要保留原始数据以便重新加工。这三条中如果命中两条以上，再考虑数据湖，否则容易杀鸡用牛刀。

Q：已经有MES和YMS了，数据湖会不会和它们功能重复？

A：定位不同，不构成替代关系。MES管的是流程执行与实时管控，YMS管的是良率分析的标准流程，两者都是面向确定业务闭环的系统，强调的是事务一致性和响应速度。数据湖面向的是探索性分析和跨源关联，强调的是数据的完整保留与灵活组合。合理的架构是MES与YMS继续承担各自的业务职能，同时把数据同步进湖，湖负责那些它们各自都覆盖不到的跨域分析场景。

Q：设备日志量特别大，全部入湖成本吃不消，该怎么取舍？

A：按价值密度分层保留是可行的做法。我们的策略是：告警与状态变更事件全量长期保留，因为条数少价值高；连续过程变量按原始频率保留三个月，三个月后降采样为一分钟粒度的统计量长期保留，包括均值、标准差、极值与超限计数；纯调试类日志只保留三十天。这套策略把日志存储占用压到全量保留的约百分之十八，而实际分析中需要用到三个月以外原始频率数据的场景不到百分之三。

Q：非结构化文件已经堆了很多年，历史数据要不要全部补进来？

A：建议按时间和价值双维度取舍，不要追求全量。做法是设一个时间线，比如近两年的文件全部登记并做特征提取；两到五年的只做登记与全文检索，不做深度解析；五年以上的仅在有明确需求时按需处理。同时优先补那些被高频引用的类别，比如FA报告和SEM照片通常比日常AOI图更有长期价值。我们的经验是，历史数据补录的边际收益下降得很快，把精力放在保证增量数据的质量上回报更高。

十、配图：数据可视化

图1：数据湖分层与上下游系统对接架构

图2：结构化与非结构化数据的统一接入流程

十一、数据湖分层设计与存储格式选型对照表

十二、结构化与非结构化数据接入规范与治理指标对照表

十三、配套资料与实战工具

本文配套完整实战工具包，包含文中涉及的测算模板、参数配置表、排查清单与Python脚本，可直接用于工厂落地实施。

点击上方「VIP资源」下载区，免费获取以下五项配套资料（持续更新中）：

刻蚀PM后首件恢复SOP与Qual Wafer管理模板（含腔体seasoning收敛判据与首件放行Gate对照表）

半导体数据湖分层设计说明书（含Iceberg表结构、元数据字典、小文件合并与分区调优脚本）

FAB工时台账与排班合规自查工具包（含加班统计模板、异常升级流程与沟通话术卡片）

大模型FMEA自动补全工具包（含Prompt模板库、RPN测算表与人工复核Checklist）

Python实战脚本合集（设备恢复数据比对、Parquet分区调优、FMEA向量检索与批量导出）

────────────────────────────────────────

本文首发于博客：半导体智能制造 | MES工程师实战笔记

你遇到过类似的问题吗？是怎么解决的？欢迎在评论区分享你的实战经验，一起交流进步。

标签：数据工具 | 数据湖 | Iceberg | 非结构化数据 | 元数据治理 | 失效分析 | 半导体