光伏 IV/EL 机台数据采集：一道工序，十种文件格式
前阵子整理这些年各个基地的机台采集配置，几十份 .conf 一份份看下来，印象最深的是：同样是光伏组件的电性能测试，不同设备厂商吐出来的数据，格式差得离谱。
我这边对接过的，IV 测试仪有 4 家品牌，EL 检测有 6 套软件。字段名、分隔符、编码、时间格式，每家都不一样。还没得挑，设备买回来是什么样，你就得接什么样。
下面这些，都是这些年跟机台数据格式死磕出来的。
采集其实有两条链路
一开始我以为采集就是读文件、解析、入库。后来才发现，实际情况分成两条完全不同的路。
走得最多的是文件采集。设备软件把测试结果落盘成 TXT 或 CSV，端侧 Logstash 用 file input 实时 tail，解析完写进 Elasticsearch。绝大多数站点都是这条。
另一条走得少，只用在几台进口 IV 测试仪上。这些设备不落 CSV，而是把结果写进本地的 Access 库（.mdb）。这时候得靠一个同步程序，按字段映射把数据搬进 MySQL，再借 binlog 往下游投递。
两条链路对应两套排查思路。文件采集出问题，看 Logstash 日志和文件本身；数据库采集出问题，得从 Access 库一路查到 binlog 有没有正常产生。不少人一开始以为只有一条路，结果第二类设备的数据死活进不来，查了半天才发现方向从一开始就错了。
六种格式，各有各的脾气
见过的格式归归类，大概是这么六大类。
A 类：空格分隔的逐片日志（某 EL 检测软件）
一行一条结果，字段用空格隔开：
2023-10-22 00:00:00:351: EL:ID 0003158590 OK Bin 1 HalmBin 8 PredictTime 365 HDZ 140.56
看着简单，坑不少。表头那行是注释，得跳过；时间戳的毫秒用的是冒号不是点，00:00:00:351，第一次解析时就在这上面栽了。还有结果字段，这里的 OK 到我们系统里得写成 OK2，因为另一个软件也用 OK，含义却不一样。
B 类：TAB 分隔的固定列（某在线检测软件）
时间\tv1\tv2\tv3\tv4\tv5\t结果\tv7\t...
最坑的是时间格式：2021-8-10-0:17:20。月份、日期、小时都不补零，拿 yyyy-MM-dd HH:mm:ss 去解析直接失败，得换成 yyyy-M-d H:m:s。不同基地对「结果」的判断也不统一，有的写 "OK" in 字段，有的写 字段 == "OK"。
C 类：中文日志行（某一体机）
Debug: 2023-12-14 08:00:00.002 TCPServer: xxx;CellSN:0001,ELBin:8,...
文件是 GB2312 编码，不是 UTF-8。这个坑我踩过，用编辑器改配置时不小心存成了 UTF-8，跑起来中文全乱码。更麻烦的是，这类日志的测试结果不在行里，藏在存图路径的目录名里：
.../SaveImages/.../夜班/8/OK_A/OK/BIN082_0000645431_300_OK_142_...bmp
得从 OK_A/OK 这样的目录层级反推结果和等级。不同基地的目录规则还不一样，切几段都得单独适配。
D 类：CSV 宽表（IV 测试仪）
列最多的有 66 列，还有 60 列、25 列两种列序的。CSV 表结构比日志清楚，但列名经常是占位符，a, b, c 一路排到 bg，真正含义全靠配置里按位置硬对应。
时间字段也不统一，有的是 yyyy-MM-dd HH:mm:ss，有的是 yyyy/MM/dd。还有个细节，CSV 的表头行不能当数据，得靠首行的关键字（StartTime、UniqueID 之类）判断并丢掉。
E 类：组件段专用 CSV
到了组件段又是另一套。图像检测、正检 AOI、正膜背膜，表头各不相同。有一家的 AOI 表头干脆是中文的（图片名、存图路径、降级原因……）。中文表头解析起来特别容易出问题，编码一对不上就直接歇。
F 类：组件 EL 的 InfoLog
2023/05/23 00:04:37,762┃Debug ┃00:04:37:733收到ASideEL拍照允许
这种日志里九成以上是噪音，只有带特定关键字的那几行才有用。解析思路是先按关键字过滤，再处理剩下的行。
所有配置里，藏着几个共同的坑
看了几十份配置，发现不管哪个品牌，有几类坑是共通的。
编码。EL 类机台大多是 GB2312，IV/CSV 类多是 UTF-8，配置里必须显式指定。而且改配置时不能用会改编码的编辑器，你以为只改了两个字，实际把整个文件的编码换了。
时间。几乎所有配置都要把时间统一到一个字段。海外基地这里有个坑：设备记的是当地时间，要换成北京时间。一开始有人图省事，直接在处理逻辑里硬编码减 1 小时。当时能用，等哪天时区规则变了就没法维护。正确做法是用时区参数，不是手算。
结果口径。这个最头疼。同样是合格，不同机台会写成 OK、OK2、True、正常、ok 五种。做良率统计的第一步永远是先对齐这个字段，不然算出来的数字全是错的。
路径大小写。Windows 路径本来不区分大小写，但配置里要是把路径的大小写写错（比如 Topstek 和 TopStek），文件就是读不到。这个坑最难查，日志里看不出任何问题，只会发现没数据进来。
一个人扛下来，代价是什么
几十个基地、十几个品牌的采集配置，一个人是能维护下来，代价是所有细节都装在你脑子里。一旦要交接，或者要把配置复用到新基地，问题就来了。
整理配置的时候，我发现了好几处「复制粘贴忘了改」：索引名还是上一个基地的、主机地址指向了别的厂、路径也是老的。这些错误不报错，只会静默地采不到数据，或者采到错的数据。等发现的时候，可能已经错了好几个月。
所以这套东西迟早要从一堆配置文件，收敛成一套标准加几个模板。
先定一份采集契约
要收敛成标准，核心不是统一技术栈，而是先定一份采集契约，约定每条数据到了下游必须带上哪几个字段：
- 统一的时间字段，标准格式，带时区
- 统一的产线标识
- 数值化的分档字段
- 二值的结果字段（OK / NG）
- 缺陷码字段
各品牌的差异字段（各种 range、intensityStep 之类）全部丢进 ext. 前缀的扩展区，不污染核心字段。
这样无论上游是 4 家 IV 还是 6 家 EL，下游做统计、看板、良率分析时，只认这一份契约。上游格式改不了，但数据进到下游之前长什么样，采集端可以自己定。
这是「光伏机台数据采集」系列的第一篇，后面继续拆具体的格式坑、结果反推，以及 Logstash 的解析选型。如果你也在做类似采集的话，欢迎评论区聊聊。
