数据采集与存储：储能系统的“神经系统”

做储能系统这么多年，我越来越觉得，数据采集与存储就像是整个系统的神经系统。数据采得准不准、存得好不好，直接决定了后续所有分析工作的成败。今天咱们就来聊聊这块硬骨头怎么啃。

一、数据采集架构：边缘计算与云端的“分工协作”

说实话，早期做储能项目时，我见过不少“一股脑全上云”的方案。结果呢？网络一抖，数据全丢。后来我学乖了——边缘计算和云端必须分工明确。

1.1 边缘计算：第一道防线

边缘计算的核心价值就四个字：就地处理。在储能系统中，BMS（电池管理系统）和PCS（储能变流器）每秒都在产生海量数据。如果全部上传云端，网络带宽和存储成本都扛不住。

我个人习惯在边缘侧做三件事：

• 数据清洗：剔除明显异常值，比如电压突然跳变到1000V（这明显是传感器故障）
• 特征提取：只上传关键指标，比如SOC、SOH、温度极值，而不是原始采样点
• 本地缓存：网络中断时，数据先存本地，恢复后自动补传

1.2 云端：大脑中枢

云端负责的是全局分析和长期存储。我建议采用分层数据流架构：

边缘设备 → 消息队列（Kafka） → 流处理（Flink） → 时序数据库 → 数据湖

为什么要加消息队列？你想想看，如果几千个储能柜同时上报数据，数据库直接写入肯定扛不住。Kafka就像个缓冲池，让数据平滑流入。

二、时序数据库选型：InfluxDB vs TimescaleDB

储能数据99%都是时序数据——每个时间点对应一组电压、电流、温度值。选对数据库，查询效率能差10倍以上。

特性	InfluxDB	TimescaleDB
存储引擎	自研TSM引擎	基于PostgreSQL
写入性能	极高（百万点/秒）	高（十万点/秒）
查询语法	类SQL（Flux/InfluxQL）	标准SQL
压缩率	约10:1	约5:1
适用场景	高频采集、实时监控	复杂分析、关联查询

我的经验是：监控告警用InfluxDB，深度分析用TimescaleDB。记得有个项目，我们需要对1000个电池模组做一致性分析，InfluxDB的JOIN操作太弱了，最后用TimescaleDB的窗口函数才搞定。

三、数据压缩与存储策略

储能系统的数据量有多大？一个100MW/200MWh的储能站，每天产生约50GB的原始数据。不压缩的话，一年就是18TB——存储成本够买一辆车了。

3.1 压缩策略

我常用的三板斧：

1. 有损压缩：对电压、温度等缓慢变化量，采用旋转门算法（Swinging Door），误差控制在0.5%以内
2. 无损压缩：对SOC、状态码等离散量，用差值编码+Snappy压缩
3. 降采样：历史数据按1分钟、1小时、1天粒度聚合，原始数据保留30天后自动清理

-- 示例：TimescaleDB的连续聚合
CREATE MATERIALIZED VIEW battery_hourly
WITH (timescaledb.continuous) AS
SELECT 
  time_bucket('1 hour', ts) AS hour,
  battery_id,
  AVG(voltage) AS avg_voltage,
  MAX(temperature) AS max_temp
FROM battery_raw
GROUP BY hour, battery_id;

3.2 存储分层

我建议采用热-温-冷三层架构：

• 热数据（最近7天）：SSD存储，响应时间<10ms
• 温数据（7天-6个月）：HDD存储，响应时间<100ms
• 冷数据（6个月以上）：对象存储（如MinIO），压缩后归档

四、数据备份与容灾

说到备份，我想起一个惨痛教训。有次机房空调故障，温度飙到50度，一台存储服务器直接宕机。幸好我们有异地备份，否则两年的实验数据全没了。

4.1 备份策略

我现在的标准配置是：

• 全量备份：每周一次，放在本地NAS
• 增量备份：每天一次，上传到云端对象存储
• WAL日志：实时同步到备用节点

# 使用pg_dump进行TimescaleDB备份
pg_dump -h primary_host -U admin -F c -b -v -f backup.dump储能_db

# 恢复命令
pg_restore -h standby_host -U admin -d储能_db -v backup.dump

4.2 容灾架构

对于关键系统，我推荐主-从-仲裁三节点架构：

• 主节点：负责读写，部署在A机房
• 从节点：异步复制，部署在B机房（距离>10km）
• 仲裁节点：监控心跳，自动触发切换

知识体系总览

下面这张图是我梳理的数据采集与存储核心逻辑，你可以对照着理解：

这张图把整个数据链路串起来了。从边缘采集到最终容灾，每个环节都有坑，但也都有成熟的解法。做储能数据工程，说白了就是把这些环节一个个夯实，别让数据在任何一个节点“掉链子”。