Klarf 文件、Defect Map、缺陷分析系统，这三个词放在一起，基本就是半导体 Fab 里做缺陷工程和良率分析的日常。多数工程师默认的做法是打开商业软件，导入 KLARF，拖几个控件，看散点图，再截个图贴进报告。问题在于，商业工具许可贵、API 封闭、字段解释固定，一旦遇到新的检测机台、异常坐标或者需要跟内部良率系统联动，整个流程就开始别扭。我当年在产线上也是被这种别扭反复折腾，最后决定自研一套从 Klarf 解析到 Defect Map 可视化的内部缺陷分析系统。这篇文章把我从文件解析、坐标转换、Web 可视化到缓存加速的完整思路，以及踩过的坑，原原本本写出来，给同样被商业软件限制住的团队做个参考。
这套系统不是要把商业软件所有功能重写一遍，而是聚焦最核心的链路：解析 KLARF 文件、还原缺陷坐标、渲染 Defect Map、叠加 Bin 图与聚合统计。技术栈选型是 Python + FastAPI + Redis + 前端 Canvas 渲染，没有引入太多炫技的组件，目的只有一个，让工程师打开网页就能快速分析一片晶圆或者一个 Lot 的缺陷分布。如果你是 Fab 里的工艺工程师、设备工程师，或者是刚转行做半导体数据分析的研发，这篇文章应该能帮你少走不少弯路。
1. 商业工具用着难受，才决定自己动手做替代方案
1.1 Fab 里每天都在跟什么样的缺陷数据打交道
在晶圆制造产线上，缺陷检测机台（暗场、亮场、电子束复查等）每天会扫出大量缺陷。一片晶圆上少则几百个缺陷，多则几十万个，机台把检测结果导成一个文本或二进制文件，最常见的就是 KLARF 文件。这个文件里记录着每个缺陷的坐标、尺寸、面积、灰度、分类代码，同时还带着晶圆尺寸、Die 尺寸、原点位置、检测配方等上下文信息。
工程师拿到 KLARF 之后，第一件事通常是在商业缺陷分析软件里打开 Defect Map，看缺陷有没有集中分布，比如边缘刮伤、中心密集、同心圆环、划痕跨 Die 等。第二件事是把缺陷跟 Bin 图叠加，看不良 Die 和缺陷位置是否相关。第三件事是把缺陷坐标导出来做 Pareto、晶圆批间对比或者跟 SEM/CD 数据做关联。
但商业工具在这个流程里暴露的问题越来越多。首先是许可成本，真正能装到多人电脑上的并发许可很贵，很多工厂只能共享两三套，工程师排队等分析，效率极低。其次是格式兼容，检测机台厂商经常升级文件格式，增加新字段或者调整块结构，商业软件更新往往滞后，碰上新的缺陷分类字段可能直接显示不了。最麻烦的是数据联动，商业工具的数据通常是封闭在项目文件里的，想把它跟数据库里的良率数据、批次加工参数、设备状态数据做关联分析，基本得靠手工导出 CSV 再二次开发，链路一长就容易出错。
1.2 替代方案的范围不能无限铺开，先圈定核心功能
自研之前，我也做过功能裁剪，明确哪些做、哪些坚决不做。商业软件里一些包装得很漂亮的功能，比如设备监控、配方管理、RMS 联动，其实和缺陷分析并没有强绑定，塞进第一版会让系统变成大杂烩，开发周期拉长，使用体验反而下降。
最终圈定的核心链路包含六块：
- KLARF 解析器：兼容 ASCII 和二进制变体，抗脏数据，输出统一的 DataFrame 结构。
- 坐标转换层：把 KLARF 里的相对坐标还原成晶圆物理坐标、Die 坐标、Map 渲染坐标。
- Defect Map 渲染：散点图、热力图、Bin 图叠加、缺陷聚类轮廓。
- 数据筛选与分组：按 Lot、Wafer、缺陷尺寸、缺陷等级、Bin 号筛选。
- 缓存与加速：用 Redis 缓存解析结果和预聚合数据，减少重复解析。
- 可视化大屏：面向产线实时监控的汇总看板。
技术栈上没有用特别冷门的东西，后端 Python 3.11 + FastAPI，数据缓冲层用 Redis 7，前端用 Vue 3 + Canvas 自绘晶圆图，图表辅助部分用了 ECharts。有人可能会问，为什么不用 Go 或者 Rust 重写核心解析器？我的回答是没必要，Python 足够快，解析单个 KLARF 文件的耗时一般在几十毫秒到几百毫秒，性能瓶颈根本不在解析上，而在渲染和坐标换算。等系统真正跑起来，如果单文件缺陷量超过百万点，再把解析核心抽成 C 扩展也不晚，接口层保持不变就行。
2. Klarf 解析：先弄清文件里究竟写了什么
2.1 ASCII 版本与字段结构
Klarf 文件的完整规范很冗长，但实际解析时只需要抓住几个核心块。第一个是文件头块（FileHeader），包含 FileType、FileVersion、DataType、DeviceID、LotID、SampleID 之类的基本信息。第二个是晶圆映射块（WaferMap），包含 SampleSizeX/Y、SampleCenterX/Y、DiePitchX/Y、DieOriginX/Y、WaferDiameter 等坐标上下文。第三个是缺陷记录块（DefectRecords），每个缺陷有 XREL、YREL、XSize、YSize、DefectID、ClusterID、Classification 等字段。第四个是 Bin 映射块，描述 Die 的良率分类。
一个典型的 ASCII KLARF 片段长这样：
FileType KLARF FileVersion 1.3 DataType ASCII DeviceID CHIP-X LotID LOT-240101-01 SampleID W01 SampleSizeX 100000 SampleSizeY 100000 SampleCenterX 0 SampleCenterY 0 DiePitchX 1200 DiePitchY 1200 DieOriginX -600 DieOriginY -600 WaferDiameter 200 DefectRecord XREL 123.45 YREL -67.89 XSize 2.3 YSize 1.8 DefectID 1 ClusterID 0 Classification 0 EndDefectRecord注意很多字段的单位是微米，坐标可能是相对晶圆中心的，也可能是相对扫描起点的，这个在解析时不能只按字段名猜，要看设备型号和文件头里的单位标记。我在一开始就吃了这个亏，后面第 5 章会详细说。
2.2 防御性解析器的关键设计
写解析器之前，我以为只要按字段名逐行读就行，实际跑了一批产线文件才发现，各家机台导出的格式并不完全一致。有的字段名全是小写，有的是大写，有的是大小写混着；有的在 DefectRecord 块中间插入额外的空行；有的坐标只有 3 位小数；有的缺少 XSize 或 YSize 字段；还有的记录块结束没有 EndDefectRecord 标记，直接出现下一个 XREL 字段就算新缺陷。
所以解析器第一版就做成了防御式设计，核心原则是：逐行扫描，不依赖行号；字段匹配不区分大小写；遇到未知字段先存到 raw 字段里，不要直接报错退出；保留原始行文本，方便排查坐标异常时对照。
我习惯先把每条缺陷记录解析成一行中间数据，包含原始行号、原始行文本、解析后的结构化字段三部分。过程大概是这样：
def parse_defects(path): defects = [] current = {} with open(path, "r", encoding="ascii", errors="replace") as fp: for lineno, raw_line in enumerate(fp, 1): line = raw_line.strip() if not line: continue upper = line.upper() if upper.startswith("XREL"): if current: defects.append(current) current = { "source_line_no": lineno, "source_text": raw_line.strip(), "x_rel": float(line.split()[1]), } elif upper.startswith("YREL"): current["y_rel"] = float(line.split()[1]) elif upper.startswith("XSIZE"): current["x_size"] = float(line.split()[1]) elif upper.startswith("YSIZE"): current["y_size"] = float(line.split()[1]) elif upper.startswith("DEFECTID"): current["defect_id"] = int(line.split()[1]) elif upper.startswith("CLASSIFICATION"): current["classification"] = int(line.split()[1]) if current: defects.append(current) return defects这个写法看起来很简单，但它保证了最基本的容错：只要某个缺陷缺失 YREL，当前记录在下一个 XREL 到来时依然会被追加进去，只是 y_rel 字段为空，不会导致整个文件解析崩掉。后面做数据筛选和可视化时，凡是缺坐标的记录直接打上 invalid 标记，在图上用灰色半透明点表示，既有信息量又不影响主视图。
2.3 二进制 Klarff 格式的兼容处理
ASCII 格式好解决，麻烦的是有些机台默认输出二进制 KLARF。二进制变体和 ASCII 的字段含义基本一致，但文件头里多了记录长度、字节序标记，数据块里用定长结构体存数值。如果拿 ASCII 解析器直接去读二进制，出来的内容就是一堆乱码和错位数字。
二进制解析的关键是三步：
- 解析文件头，读取字节序标记（LE 或 BE）和总记录长度。
- 根据记录长度把文件切成块，每块对应一条缺陷记录。
- 在每条记录内，按预定义的字段偏移量读取整数或浮点数组。
不同机台的二进制块结构可能不一样，最稳妥的做法是做一个 schema 注册表，每个设备型号对应一个字段偏移模板。在解析时先判断文件头里的 DeviceID 或 Version 字段，然后加载对应模板，模板缺失时抛出明确错误，而不是硬猜偏移量。我见过有人为了兼容二进制格式，用模糊匹配去逐字节找浮点数模式，结果在坐标偏移和字段错位的问题上浪费了大把时间，最后还得靠设备厂商的文档把偏移量定死。
3. Defect Map 可视化：坐标转换和密度呈现才是重头戏
3.1 晶圆物理坐标、Die 坐标和渲染坐标的换算链
Defect Map 看起来只是把一个个点画在圆里，但实际上从 KLARF 里的坐标到屏幕上像素坐标，至少要经过两层换算。
第一层是把 XREL/YREL 从文件坐标系换算到晶圆物理坐标。多数 KLARF 文件里的 XREL/YREL 是相对晶圆中心的偏移量，单位微米，所以物理坐标可以近似为：
- x_physical_mm = sample_center_x + x_rel / 1000
- y_physical_mm = sample_center_y + y_rel / 1000
但有些文件里的坐标是相对扫描台原点的，不是相对晶圆中心，这时如果你强行把 sample_center_x 加上去，整张图的缺陷位置就会全部偏移到晶圆外。这个问题的排查过程，我在第 5 章会完整复盘。
第二层是把物理坐标换算到 Die 坐标和渲染坐标。Die 坐标用于判断缺陷落在哪个 Die 上，公式是：
- die_col = floor((x_physical_mm - die_origin_x) / die_pitch_x)
- die_row = floor((y_physical_mm - die_origin_y) / die_pitch_y)
渲染坐标则要考虑晶圆半径和画布半径：
- pixel_x = canvas_center_x + (x_physical_mm - wafer_center_x) / wafer_radius * canvas_radius
- pixel_y = canvas_center_y - (y_physical_mm - wafer_center_y) / wafer_radius * canvas_radius
注意 y 轴方向，文件坐标系和屏幕坐标系经常是反的。很多初版可视化系统画出来整张图上下颠倒，就是因为漏了 y 轴取反。这个细节我放到后面讲，因为它属于典型的“看起来是小问题，实际影响很大”的坑。
3.2 十万缺陷点不能画散点图，要用网格热力图
缺陷点数量少的时候，散点图很直观。但缺陷量一旦超过几万，散点图就是一片深色色块，完全看不出空间分布特征。我之前看到一个批次的晶圆表面缺陷有 8 万多个点，直接画散点图，浏览器卡了半天，投影出来就是一团黑，工艺工程师根本没法判断是边缘刮伤还是中心团簇。
替代方案是网格密度热力图。把晶圆区域划分成 256x256 或者 512x512 的网格，统计每个格子里的缺陷数量，然后用色带映射到像素。这样既压缩了渲染数据量，又能直观暴露缺陷聚集区域。实际实现中，我用 numpy 的二维直方图统计缺陷数量：
import numpy as np grid_size = 512 x_bins = np.linspace(-wafer_radius, wafer_radius, grid_size + 1) y_bins = np.linspace(-wafer_radius, wafer_radius, grid_size + 1) heatmap, _, _ = np.histogram2d( x_physical, y_physical, bins=[x_bins, y_bins] )拿到热力图之后，渲染时再用 Canvas 的 putImageData 直接画像素，速度非常快，对于 8 万点甚至 50 万点的数据，也只需要一次 histogram 计算，完全不会卡。热力图的色带我用的是类红外色带，从深蓝到亮黄，缺陷密度高的区域一眼就能看出来，比默认彩虹色带更符合缺陷热力图的可读性。
3.3 Map 上要叠加哪些信息才有分析价值
单画一张缺陷热力图，信息量还是不够。真正的缺陷分析需要把几个图层叠在一起：
第一层是晶圆轮廓和缺口（Notch/Flat），定义整个可视域的边界。第二层是 Die 格线，方便工程师判断缺陷落在哪个 Die 上。第三层是 Bin 图，把每个 Die 的良率分类用颜色标出来，通常是绿色代表好 Die，红色或黑色代表坏 Die，这样缺陷和坏 Die 的空间相关性一眼可见。第四层才是缺陷热力图或散点图。
我在前端实现时采用了 Canvas 分层绘制：底层画晶圆轮廓和 Die 格线，中层画 Bin 图，顶层画缺陷。每一层都允许开关，工程师可以根据需要切换。交互上支持鼠标悬停读取缺陷 ID 和坐标，点击某个区域后可以框选放大，放大后自动切换到散点模式，让工程师能看清单个缺陷之间的间距和排列。这套交互逻辑不一定最炫，但确实是最贴合产线实际排查需求的。
4. 性能瓶颈、Redis 缓存与可视化大屏的工程化
4.1 数据放大系数到底有多大
先算一笔账。一片晶圆缺陷量按 2 万计算，一个 Lot 通常有 25 片晶圆，就是 50 万条缺陷记录。如果一个工程师一天分析 5 个批次，后端要处理的缺陷记录就是 250 万条。这个量级在数据库层面不难，但如果每次打开网页都重新解析 KLARF 文件、重新计算 Die 坐标、重新聚合成热力图，后端会反复做无用功，响应时间从几百毫秒膨胀到 5 秒以上，完全不可用。
所以在系统设计里，我把“解析”和“可视化”分成两层，解析结果缓存起来，只有文件没变时才复用。这样首访慢，后续访问快，也是整个系统能支撑产线多人同时使用的关键。
4.2 用 Redis 缓存解析结果和预聚合数据
缓存层我选了 Redis，主要原因是它足够轻，既可以做 K/V 缓存，也可以存预聚合数据，还能方便多个后端节点共享。早期我试过用内存缓存，但前端是多人同时访问，缓存状态散落在每个 Python 进程里，一旦进程重启缓存就全没了，还容易出现缓存不一致。
Redis 的 key 设计是后面踩坑的重灾区，所以我单独强调一下。我的 key 结构是：
fab:defect:parsed:{file_md5}:{wafer_id} fab:defect:heatmap:{file_md5}:{wafer_id}:{grid_size} fab:defect:wafer:summary:{lot_id}:{wafer_id}value 不是直接存 JSON 字符串，因为几万条缺陷的 JSON 序列化以后动不动几十 MB，Redis 对这种大 value 的处理并不理想。我实际做的是把缺陷记录的关键字段（x_rel、y_rel、x_size、y_size、defect_id、classification）抽出来，按列压缩成 numpy 数组的二进制内容，塞进 Redis string。读取时一次性取出再反序列化，耗时可以控制在 10 毫秒以内。
小细节：如果缓存数据超过 Redis 单个 value 的安全上限，比如缺陷超过 30 万个点，可以分片存储，按 5 万点一组拆成多个 key。工程上不要等到出问题再拆，设计阶段就把 chunk 的概念加进去，后面扩展会舒服很多。
4.3 可视化大屏不是把图表堆上去就完事
“可视化大屏”这个词现在确实被用滥了，很多系统就是把几十个图表堆在一个页面上，什么都展示，什么都看不清楚。我在做缺陷分析的大屏时，只保留了四个核心区域：
- 当前批次整体缺陷趋势折线图。
- 当前晶圆 Defect Map 热力图。
- 缺陷分类占比柱状图。
- 最近 12 个批次的缺陷密度对比表。
大屏的核心目标是让产线工程师一抬头就知道目前的缺陷分布是不是异常，不需要看到每个缺陷的坐标细节。所以大屏的数据接口也跟分析页面不同，用的是轻量级预聚合接口，定时每 30 秒从 Redis 读一次缓存，前端再用简单的长轮询刷新，避免每次刷新都触发重计算。
后端接口我直接用 FastAPI 暴露，核心分析接口长这样：
@app.get("/api/wafer/defect-map") def get_wafer_defect_map(lot_id: str, wafer_id: str): cache_key = f"fab:defect:heatmap:{lot_id}:{wafer_id}:512" cached = redis_client.get(cache_key) if cached: return deserialize_heatmap(cached) # 没有缓存时解析文件并计算热力图 df = load_defects(lot_id, wafer_id) heatmap = compute_heatmap(df, grid_size=512) redis_client.set(cache_key, serialize_heatmap(heatmap), ex=3600) return heatmap这套设计跑起来之后，后端 CPU 占用率低了很多，正常情况下单台机器就能扛住产线十多个工程师同时刷页面，几乎听不到有人抱怨“系统卡死”。真正的性能问题反而出现在缓存穿透和缓存失效上，这个在后面踩坑部分会细讲。
5. 自研上线后踩过的真实坑：坐标偏移、镜像、多源兼容
5.1 所有点整体偏移到晶圆外：根因排查链路
系统第一个版本上线后的第三天，工艺工程师反馈说某台设备导出的 KLARF 文件，画出来的 Defect Map 上所有点都集中在右上角，甚至有一大半点落在晶圆轮廓外。这个现象很典型，我当时排查链路是这样的：
第一步，先看原始文件，确认 XREL/YREL 的范围。
结果显示 XREL 范围在 0 到 100000，YREL 也在 0 到 100000 附近，而 SampleCenterX/Y 是 0，WaferDiameter 是 200 毫米，换算下来半径只有 100000 微米。但问题恰恰在于，这台设备导出的坐标根本不是相对晶圆中心的，而是相对扫描台原点的，范围是整个晶圆的长宽，不是半径偏移量。如果强行把文件坐标当成相对坐标，所有点只会在第一象限，看起来就像整体跑偏。
第二步，对照设备厂商的 KLARF 导出选项。
这台设备的文件在导出时有一个坐标参考系选项，默认是“Stage Absolute”，需要手动改成“Wafer Center Relative”才会输出相对晶圆中心的偏移量。之前机台配方里的导出参数没改，导致所有坐标都是绝对坐标。这个问题不是解析器能完全兜住的，必须在解析之前判断坐标参考系。
第三步，在解析器里加一个“坐标参考系探测”逻辑。
如果检测到 XREL/YREL 的分布范围超过晶圆半径的两倍以上，且大多落在正象限，就自动认为这是绝对坐标，需要通过 SampleCenterX/Y 和 Wafer 原点偏移量转换。这个启发式判定不完美，但可以作为第一道防线。最靠谱的还是在解析器里同时支持“坐标参考系”配置，每个机台型号默认用哪套，由数据接入时显式指定，不要依赖自动猜测。
5.2 镜像和旋转：图纸明明是反的，坐标却没错
坐标范围正常，但 Defect Map 还是不对劲，一般情况下就是镜像或旋转问题。我第一次遇到时，始终想不通坐标值都对，为什么 Defect Map 和机台屏幕截图左右相反。后来翻设备手册才发现，这台暗场机台导出的 Y 轴方向跟传统晶圆坐标系是反的，也就是相当于做了水平镜像。
这个坑很容易被忽略，因为单个缺陷的坐标看起来都是合理的，Die 格线也对得上，只有叠加 Bin 图之后才会发现缺陷位置跟坏 Die 区域对不上。解决办法是在解析层增加镜像标志，如果缺陷和 Bin 图错位，允许前端和后端都配置一次水平翻转或者 90 度旋转。不要把这个逻辑写死在解析器里，因为不同机台不一样，有的需要翻转，有的不需要。
我现在在数据库里给每个设备型号存了一个坐标变换配置字段，比如：
{ "mirror_x": true, "mirror_y": false, "rotation_angle": 0 }解析完成后统一应用变换，再存到缓存里。这样前端完全不感知坐标变换，只需要按照统一坐标系渲染，避免出现“一台设备一套代码”的维护噩梦。
5.3 Redis 缓存命中的却是旧数据：缓存 key 设计反思
踩过一个很尴尬的坑：某批次的 KLARF 文件重新检测后更新了，系统页面显示的却还是旧缺陷图。排查到最后，原因是我当时缓存 key 只用了 lot_id 和 wafer_id，没有包含文件的修改时间或内容哈希。文件更新后，解析结果缓存还在，Redis 直接命中旧数据，前端就一直显示老图。
从那以后，我在缓存 key 里强制加入文件内容的快速哈希，用的是 mmh3 的 64 位哈希，速度很快，计算代价可以忽略。文件上传或更新时，后端重新计算哈希，生成的缓存 key 也随之变化，旧缓存自然失效，不会再出现数据更新不成功的情况。
顺便说一句，缓存穿透也是需要处理的。如果某个 lot_id 在缓存里不存在，而 Redis 和数据库里都没有对应数据，每个请求都会打到文件解析层，非常容易把后端拖垮。我用的是 singlefly 单飞策略，同一个缓存 key 的并发请求只放行一个，其余请求等待第一个请求的结果返回。这样即使某天有人手动提交了一个不存在的 lot_id，系统也不会因为缓存穿透而整体卡顿。
5.4 多设备厂商文件的“方言”兼容问题
半导体 Fab 里的检测设备通常不是一家的，不同厂商对 KLARF 的字段顺序和可选字段处理都有自己的“方言”。这个问题的恶心之处在于，你没法用一个统一模板适配所有文件，必须做设备型号级别的配置管理。
我处理的方式是把解析器拆成两部分：核心解析引擎负责把文件按块切分、把字段值转成基本类型；设备型号配置则是一个映射表，记录每种设备导出的字段顺序、是否有额外前缀、结束标记是什么、坐标单位是什么。新接入一台设备时，先让它导出一份 KLARF 样例，对照配置表修改设备型号配置，而不是改核心解析器代码。
如果某个字段在配置里缺失，比如没有 YSize，那就不填，可视化时对缺陷尺寸的椭圆绘制自动退化为圆形。因为有了这一步，后续新增设备接入的时间从原来的两三天缩短到半天以内，工程团队的工作量少了很多。
6. 系统落地后的实际效果与后续还能怎么扩展
6.1 上线后省下的时间是真金白银
这套系统在内部跑满一个月之后，我统计过一个粗略的数据：工程师从拿到 KLARF 到生成一张可分析的 Defect Map，原来用商业软件大概需要 1 到 3 分钟，碰到大文件或者文件版本不兼容还会更久；现在打开网页丢文件进去，基本 10 秒内出图，差异非常明显。更关键的是，原来需要排队等商业软件许可，现在团队内部所有人都能同时访问，分析拥堵问题彻底消失。
这里有一个小技巧，我强烈建议做：解析后的结果一定保留一份“数据血缘”字段，至少包括来源文件名、文件哈希、解析器版本、设备型号配置版本。这样以后任何数据异常，都能回溯到具体是哪个环节引入的问题，而不是对着最终 Defect Map 猜来猜去。这个字段看着不起眼，但在排查问题的时候能省掉大量扯皮。
6.2 后续演进方向：从可视化走向自动分析
当前系统的定位还是“辅助工程师看图”，下一步我计划往自动分析方向走。第一个方向是把缺陷聚类结果自动分类，比如根据聚类的空间形态判断是边缘刮伤、中心团簇还是随机散布。第二个方向是训练一个简单的缺陷类型分类器，结合 KLARF 里的 XSize/YSize、灰度、聚类形态等特征做初级筛选，减少工程师逐张看图的时间。
第三个方向是把 Defect Map 和良率 Bin 图做相关性分析，自动计算缺陷密度和 Bin 良率之间的相关性。传统做法是工程师肉眼对比，速度慢，而且容易漏掉弱相关。如果系统能每天自动计算每个 Lot 的缺陷空间分布和 Bin 失效率的相关指标，一旦出现相关性突增就自动告警，产线异常响应速度还能再上一个台阶。整体路线图不算激进，但每一步都是围绕“减少重复人工看图”这个目标展开的，这也是自研系统最大的优势——你可以按自己的节奏定义功能优先级，而不是等商业软件厂商发布新版。
最后再分享一个经验：自研替代方案不要追求第一版就做到界面精致、功能全面，先保证核心链路跑得通，数据准确，再逐步叠加高级分析。只要解析层、缓存层和可视化层分层清楚，后续无论是接入新设备还是增加新分析算法，都会比在商业软件外围打补丁要顺畅得多。
