3、数据采集软件架构：数据采集系统分层设计、实时数据库与历史数据库、边缘计算与云端协同
大家好，我是老张。在储能行业摸爬滚打了十几年，今天咱们聊聊数据采集的软件架构。
说实话，很多刚入行的朋友容易把数据采集想简单了——不就是把电压、电流、温度读上来存起来吗？其实不然。一个储能电站动辄几百个电池簇，几千个电芯，数据量是海量的。怎么采、怎么存、怎么用，这里面的门道可不少。
3.1 数据采集系统的分层设计
我个人习惯把数据采集系统分成三层：感知层、传输层、应用层。你想想看，这就像人体的神经系统——感知层是末梢神经，传输层是脊髓，应用层就是大脑。
核心分层逻辑：
- 感知层：负责原始数据采集，包括传感器、电表、BMS从控等设备。这一层只做一件事——把物理量变成数字信号。
- 传输层：负责数据汇聚和转发，包括网关、交换机、通信协议转换。说白了就是当个"二传手"。
- 应用层：负责数据存储、计算、展示。这是真正出价值的地方。
我在项目中遇到过一个问题：某储能站感知层设备用了Modbus RTU，传输层却强行上MQTT，结果网关频繁掉线。后来我建议统一用Modbus TCP到网关，再转MQTT上云，问题就解决了。嗯，这里要注意——分层不是割裂，层与层之间的接口协议一定要匹配。
3.2 实时数据库与历史数据库
很多新手会问：为什么不能用一个数据库搞定所有事？
我打个比方你就明白了。实时数据库就像你的短期记忆——记得快、忘得也快。历史数据库就像你的日记本——记得慢，但能存一辈子。
| 特性 | 实时数据库 | 历史数据库 |
|---|---|---|
| 典型产品 | Redis、InfluxDB、eXtremeDB | MySQL、PostgreSQL、ClickHouse |
| 写入速度 | 百万级点/秒 | 万级点/秒 |
| 存储周期 | 秒级到分钟级 | 天级到年级 |
| 典型用途 | 实时告警、控制指令、画面刷新 | 数据分析、报表、AI训练 |
我的实战经验：
实时数据库我一般用环形缓冲区设计。比如只保留最近1小时的数据，超过的就自动覆盖。这样内存占用可控，查询也快。历史数据库则用时序压缩，比如死区压缩——电压变化小于0.1V就不记录，能省下80%的存储空间。
我曾经踩过一个坑：某项目把实时数据和历史数据全塞进同一个MySQL库，结果写入一快，查询就卡死。后来拆成Redis+ClickHouse双库，问题迎刃而解。说白了，没有万能的数据库，只有合适的架构。
3.3 边缘计算与云端协同
边缘计算这几年特别火。但我要说一句：边缘不是万能的，云也不是万能的。关键是怎么协同。
我习惯把任务分成三类：
- 必须边缘做的：毫秒级保护、本地闭环控制。比如电池过压保护，延迟超过10ms就可能出事故。
- 必须云端做的：跨站点的全局优化、AI模型训练、长期趋势分析。这些需要海量数据和算力。
- 边缘和云都能做的：比如数据清洗、异常检测。我建议边缘做初步过滤，云端做深度分析。
注意：
边缘计算不是把云端的代码直接搬到边缘设备上跑。边缘设备的CPU、内存、存储都有限。我曾经见过有人把TensorFlow模型直接部署到ARM网关，结果推理一次要3秒——黄花菜都凉了。正确的做法是模型量化+剪枝，或者干脆用规则引擎代替AI。
这里我画了一张架构图，帮你理清思路：
你看这张图，数据从感知层上来，经过传输层的边缘网关做初步处理，再上到云端做深度分析。反过来，云端的控制指令也可以下达到边缘，形成闭环。
关于协同，我总结了三句话：
- 边缘做"快"的事：毫秒级响应、本地保护、数据清洗
- 云端做"大"的事：海量存储、全局优化、模型训练
- 两者做"通"的事：数据同步、指令下发、状态监控
最后说一个我踩过的坑。某项目为了"先进"，把所有数据都先上云再处理。结果网络一抖，本地保护就失效了。后来我强制要求：所有保护逻辑必须在边缘完成，云端只做辅助决策。从此再没出过类似问题。
好了，这一节就聊到这儿。记住一句话：架构设计没有银弹，适合你的场景才是最好的。
公众号:蓝海资料掘金营，微信deep3321