4. 数据存储技术选型：时序数据库、关系型数据库、数据湖方案对比

做储能数据融合，说白了就是跟数据存储死磕。我这些年踩过的坑，有一半都跟选错存储有关。你想想看，一个储能电站，每天几百万条数据往上怼，电压、电流、SOC、温度、告警……要是存储选不对，后面做分析、做预测，全是扯淡。

今天咱们就聊聊三种主流方案：时序数据库（InfluxDB、TimescaleDB）、关系型数据库（MySQL/PostgreSQL）、数据湖（Hadoop/Delta Lake）。我会结合实战经验，把各自的优缺点、适用场景、以及我踩过的坑，一次性说清楚。

4.1 时序数据库：天生为时间序列而生

储能数据最大的特点是什么？带时间戳。每一秒、每一毫秒的数据，都是按时间顺序排列的。传统关系型数据库处理这种数据，效率低得让人抓狂。

时序数据库就是专门干这个的。它做了大量优化：

• 列式存储：按时间列压缩，存储空间省一半以上
• 自动降采样：老数据自动聚合，查询秒级响应
• 保留策略：自动删除过期数据，不用你操心

4.1.1 InfluxDB：轻量级首选

我个人习惯，小规模项目（单站、几十万测点）首选 InfluxDB。它部署简单，一条命令就能跑起来。而且它的查询语言 InfluxQL 跟 SQL 很像，上手快。

-- 创建保留策略，数据保留30天，自动降采样为1小时粒度
CREATE RETENTION POLICY "rp_30d" ON "energy_db" DURATION 30d REPLICATION 1 DEFAULT;

-- 写入数据示例
INSERT battery_metrics,device_id=BMS_01,cell_id=001 voltage=3.65,temperature=25.2,soc=78.5 1700000000

4.1.2 TimescaleDB：PostgreSQL 的时序扩展

如果你团队里已经有 PostgreSQL 的运维经验，TimescaleDB 是个不错的选择。它本质上还是 PostgreSQL，只是加了一层时序优化。这意味着你可以直接用 SQL 查询，还能用上 PostgreSQL 的生态（比如 PostGIS 做地理分析）。

TimescaleDB 的核心是超表（Hypertable）。它会自动按时间分区，查询时只扫描相关分区，效率很高。

-- 创建超表
CREATE TABLE battery_data (
    time        TIMESTAMPTZ NOT NULL,
    device_id   TEXT NOT NULL,
    voltage     DOUBLE PRECISION,
    current     DOUBLE PRECISION,
    soc         DOUBLE PRECISION
);

-- 转换为超表，按时间分区，每7天一个分区
SELECT create_hypertable('battery_data', 'time', chunk_time_interval => INTERVAL '7 days');

-- 查询最近1小时的平均电压
SELECT time_bucket('5 minutes', time) AS bucket,
       avg(voltage) AS avg_voltage
FROM battery_data
WHERE time > now() - INTERVAL '1 hour'
GROUP BY bucket
ORDER BY bucket;

4.2 关系型数据库：结构化数据的基石

别以为有了时序数据库，关系型数据库就没用了。在储能系统中，关系型数据库依然扮演着重要角色——存储元数据、配置信息、用户权限、告警规则等结构化数据。

我一般用 PostgreSQL 作为关系型数据库。为什么？因为它支持 JSON、数组、地理空间等复杂类型，而且事务处理能力很强。

数据类型	存储内容	推荐方案
设备元数据	设备ID、型号、安装位置、固件版本	PostgreSQL
告警规则	阈值、触发条件、通知方式	PostgreSQL
用户权限	用户信息、角色、权限	PostgreSQL
时序数据	电压、电流、温度、SOC	InfluxDB / TimescaleDB
历史归档	超过30天的原始数据	数据湖

4.3 数据湖：海量数据的终极归宿

储能系统运行时间长了，数据量会非常恐怖。一个 100MW 的储能电站，一年产生的原始数据可能超过 100TB。这时候，时序数据库也扛不住了——存储成本太高，查询效率也下降。

数据湖就是用来解决这个问题的。它把数据以原始格式存储在廉价的对象存储（如 S3、HDFS）上，需要时再用计算引擎（如 Spark、Presto）去分析。

4.3.1 数据湖 vs 时序数据库

说白了，数据湖和时序数据库是互补关系，不是替代关系。我一般这样设计：

• 热数据（最近 7 天）：放在 InfluxDB 或 TimescaleDB，保证实时查询
• 温数据（7 天 ~ 30 天）：降采样后仍放在时序库，或者迁移到数据湖
• 冷数据（超过 30 天）：全部归档到数据湖，按需分析

# 使用 PySpark 将时序数据写入 Delta Lake
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("EnergyDataLake").getOrCreate()

# 读取 InfluxDB 中的热数据（示例）
df = spark.read.format("influxdb").option("url", "http://influxdb:8086").load()

# 写入 Delta Lake，按日期分区
df.write.format("delta") \
    .mode("append") \
    .partitionBy("year", "month", "day") \
    .save("/data/energy_lake/battery_metrics")

4.4 方案对比与选型建议

说了这么多，到底怎么选？我整理了一张对比表，你一看就明白：

维度	InfluxDB	TimescaleDB	PostgreSQL	数据湖（Delta Lake）
写入性能	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
查询性能（实时）	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐
存储成本	中等	中等	较高	低
运维复杂度	低	中	中	高
适用场景	高频时序、实时监控	需要 SQL 的时序场景	元数据、配置、事务	海量历史数据、批量分析

4.5 知识体系总览

下面这张图，是我梳理的储能数据存储选型框架。你可以把它当作一个决策树来用：

嗯，这张图基本概括了我这些年做储能数据存储的经验。核心思路就是：分层存储，各取所长。热数据追求性能，冷数据追求成本，中间层做平衡。

---

公众号:蓝海资料掘金营，微信deep3321