先聊聊为什么突然想写这个
上个月在苏州一个汽车零部件厂调产线，对方花费几百万上了套所谓“工业大脑”，结果连最基本的产量统计都经常对不上。查来查去，问题不是算法不行，是底层数据存得乱七八糟——PLC里的时间戳和MES里的时间戳差了8个小时，采集过来的数据居然还有重复的。说实话，当时我真想把那个项目经理拎过来骂一顿。
产线数据存储这事，看着是个IT问题，但根子上是机械工程师的活。为什么？因为产线数据从哪来？传感器、PLC、CNC、机器人控制器……这些玩意的数据格式、通讯协议、时钟同步，哪个不是设备层面的事？不懂机械和工艺，光靠IT小哥在那调数据库，纯粹是耍流氓。
存储架构的三种酸爽姿势
第一重：直接塞关系型数据库
国内不少老产线改造，喜欢用SQL Server或者MySQL存所有数据。比如一个焊接工位，每焊一个点就有电流、电压、焊接时间等十几个字段。一天产5000件，每件20个焊点，算一下那就是100万条记录
开始测试数据量小于100万时还行，但真跑到一个月以后，查询报表能卡死你。尤其是当你非得用SQL做实时统计，比如算节拍、算OEE，那滋味堪比用自行车拉火车。我曾经见过某厂为了查一条历史报警记录，等了6分钟，气得操作工差点把显示器砸了。
所以，如果你产线数据量就那样（一天几万条），那关系型库勉强能用。但记住一个建议：所有数据表按日期分区，索引别乱加，写个定时任务把超半年的归档到冷库。
第二重：Kafka + 时序数据库组合拳
真正上了规模的产线（比如3C、电池、整车主线），数据量是每秒几万点级别的。这时候再拿关系型库硬扛，那就是脑子进水了。推荐套朴素的架构：设备数据 → 网关采集（支持Modbus TCP, OPC UA, Profinet都行） → Kafka削峰 → 写入时序数据库（比如InfluxDB, TDengine，或者工业场景常用Pi system） → 上层Hmi和MES读时序库。
说几个坑。第一，网关采集程序必须做断点续传。PLC一重启，采集中断，如果你没存本地缓冲，丢的数据就再也找不回来。我们曾经有个线体，OPC UA服务器偶发重启，结果没做续传，导致夜班3小时的能耗数据全部丢失，第二天白班查了半天气得跳脚。第二，时序数据库的写入压力测试一定要做。别信什么“单机百万写入”的吹嘘，实际现场电磁干扰、网络抖动、多站并发，性能直接减半都是好的。我用过TDengine，单节点撑过每秒25万点没什么问题，但你要是拿InfluxDB开默认配置，过不了几天就“engine maximum series limit exceeded”
顺带提一句，Kafka的分区数别设置太多。很多工程师觉得分区越多吞吐越大，其实分区太多导致文件句柄爆炸，而且全挂了。一般一个设备主题设置8~16个分区足够。
第三重：边缘网关本地缓存 + 云端长期存档
现在很多人喜欢把数据一股脑往云上搬。可产线现场网络不稳定、机房到车间距离几百米，光纤被叉车压断这种事我见过不止一次。所以强烈建议在每个机台或者工位装一个边缘网关（比如研华、西门子或者自己用树莓派攒一个都行），本地用SQLite或者林奇嵌入式数据库先存一份，每秒采集一次，本地至少保留7天。然后网关定期把压缩后的数据块推送到中心服务器或者云存储。
这个架构有个好处：就算中心侧全挂了，产线照跑不误。历史数据丢了也能在本地追回来。我们在做一条柔性装配线的时候，就这么干的。有一次企业交换机烧了，中心数据库宕机4小时，产线上每个工位的边缘网关稳稳妥妥攒了几万条记录，事后补传，无缝衔接。
数据格式与语义，比存储介质更头疼
你以为存下来就完了？最恶心的是不同设备的数据语义完全不一样。比如同行名“温度”，A设备的单位是摄氏度，B设备是华氏度，C设备干脆给你个0~65535的裸数，得乘个系数再加偏移。你要是没做统一的数据字典，后面做分析时数据就是垃圾。
所以上线前必须定义一套信息模型。比如参考OPC UA的配套规范，或者自己建个资产树：产线→工位→设备→部件→参数。每个参数的ID、单位、数据类型、采集周期、可信度范围，全都要有定义。这里推荐用诸如AutomationML或者统一架构建模工具先建好模型，再生成代码。我们吃过亏：曾经建了三个格式的配置文件，不同工艺段各读各的，最后数据汇总的时候光是做单位换算就花了两个月。
另外，时间同步千万要重视。产线上所有设备最好都用NTP同步到同一时钟源。别小看这几十毫秒的偏差。两条半自动线做数据关联分析时，如果时间戳偏差超过100ms，很多开始/结束事件就匹配不上。我见过某项目因为PLC系统时间慢了5分钟，导致产量和废品率对不上，老板差点以为操作工偷懒。
压缩、丢点与存储周期——那些没人教的常识
有些数据需要用原始值存储，比如气囊焊点的电流曲线，做质量追溯必须完整保存。但有些数据，比如连续的温度巡检，就是一个稳定波动，完全可以用死区压缩。方法很简单：只在值变化超过0.5%时记录。拿这个办法，把一条注塑线的模温数据从一天2.5GB压到了300MB，效果明显。
还有数据丢点问题。现场总线经常会有瞬时干扰导致某几个采样点丢失。你是直接留个空洞还是用插值补？我的建议是原始数据必须保留空标志，分析平台可以自己决定要不要补。千万别在存储层面就给它塞个假数。搞过质量分析的人都知道，一个假点的危害胜过十个空洞。
关于存储周期，别一刀切。老规矩：实时数据存3个月，分钟聚合存5年，小时聚合永久保留。聚合任务不要用数据库脚本，用流处理引擎（比如Flink）在写入时候顺带做掉，不然高峰时段拖垮源库。
一个真实的选型对比
最后分享个惨痛教训。今年给一条电池模组线做数据方案，因为工期紧，听信了某厂商“全兼容”的鬼话，选了所谓OPC UA套件直接连所有设备。结果有个焊接控制器的协议是私有扩展的不支持，只好又花了两周写驱动。后来我们用了一款工业网关（支持自定义脚本），花了三天才搞定。所以，选型时一定先做设备协议摸底清单，至少列出来每台设备的通讯手册版本、寄存器表、命名空间，然后再决定用标准化方案还是定制化。
如果你要自己搭存储，软件方面推荐这么配：边缘侧用Eclipse Mosquitto + SQLite，中心侧用Kafka + TDengine + Grafana。这套全是开源，技术栈轻，成本可以压得比较低。唯一注意点是TDengine的集群版常需要授权？其实社区版也够用了，单机+主子表就能扛住大部分工厂的规模。
说说心里的真实感受
说实话，写了这么多，我并不是劝你非得用多炫的技术。产线数据存储的核心就是抓住几个字：稳、准、快、省。稳是数据不能丢；准是时序和语义可靠；快是查询访问不拖沓；省是用合理的成本干完活。
很多厂搞数据中台，最后建成了数据坟场——存了一大堆，没人看也没法用。倒不如先把基础打好，哪怕先用简单架构跑起来，等到数据量真起来了，再平滑扩展不迟。别一开始就上微服务、数据湖、星型模型，那对机加工车间来说纯粹是杀鸡用牛刀，还搞得运维头大。
最后提醒一下：数据安全权限控制，别忽略。有些国产系统默认账户密码全厂通用，出了安全事故可没人帮你背锅。我的习惯是产线终端只给读权限，写操作必须走带审计的接口。
该收尾了（这句不是“总而言之”）
干设备多年，现在发现懂机械的工程师往往低估数据，懂IT的又往往忽略设备本性。产线数据存储这道题，其实是个跨界融合的题。想要不踩坑，就得把设备当人看：你的数据就是它的记忆，存储方案就是它的脑神经系统。别让你的产线得老年痴呆。
以上都是亲身经历，有点啰嗦，但每一条都是拿加班和掉头发换来的。下次谁再跟你吹“一键式工业数据平台”，你先问问他：支持断点续传吗？时间同步机制是什么？存储压缩比多少？大概率能噎住他，哈哈哈。
