4. 数据存储与处理：时序数据库设计、数据清洗与转换、数据归档策略
各位同行，今天我们来聊聊风电场监控系统的“心脏”——数据存储与处理。说实话，我见过太多项目，硬件选型一流，网络也通畅，最后却因为数据层设计不合理，导致系统卡顿、查询缓慢，甚至丢数据。嗯，这一块要是没做好，前面所有努力都白费了。
4.1 时序数据库设计：别用MySQL存风电数据
风电数据有个特点：海量、高频、带时间戳。一台风机每秒可能产生几十个测点数据，一个风场几十台风机，一天下来就是几亿条记录。你想想看，用传统的关系型数据库去存，查询一条“过去24小时的平均风速”可能要等半天。
我个人习惯，首选时序数据库（TSDB）。比如InfluxDB、TimescaleDB，或者国产的TDengine。它们天生为这种场景优化。
核心设计原则：
- 标签（Tag）与字段（Field）分离：风机ID、测点类型作为Tag，风速、功率等数值作为Field。Tag会被索引，查询极快。
- 时间戳精度：一般用毫秒级就够了。我在项目中遇到过用纳秒级的，结果存储量暴涨3倍，查询也没快多少，后来改回了毫秒。
- 保留策略（Retention Policy）：原始数据存7天，聚合数据存1年，统计摘要存永久。别想着全量永久保存，成本扛不住。
-- 以TDengine为例，创建超级表
CREATE STABLE wind_turbine_data (
ts TIMESTAMP,
wind_speed FLOAT,
power FLOAT,
temperature FLOAT
) TAGS (
turbine_id INT,
point_type VARCHAR(10)
);
-- 插入数据
INSERT INTO t1 USING wind_turbine_data TAGS(101, 'main') VALUES (now, 12.5, 1500.0, 35.2);
我的小技巧： 设计Tag时，把查询频率高的字段放进去。比如“风机编号”和“故障码”就非常适合做Tag。但“风速值”这种连续变化的，千万别当Tag，否则Tag表会爆炸。
4.2 数据清洗与转换：脏数据比没数据更可怕
风场环境恶劣，传感器经常抽风。我见过风速显示-999的，也见过功率突然跳变到满发的。这些脏数据如果不处理，直接入库，后续的分析、报警全是错的。
数据清洗，说白了就是“去伪存真”。我一般分三步走：
- 异常值过滤：设定合理范围。比如风速0~40m/s，功率0~额定功率。超出范围的直接丢弃或标记。
- 死值检测：连续N个点数值完全不变，大概率是传感器卡死了。我曾经遇到一个风场，连续3小时风速都是6.5m/s，一查发现是传感器冻住了。
- 缺失值处理：短时间缺失（<5分钟）用插值填充；长时间缺失直接标记为无效，别硬填。
# Python示例：简单的清洗逻辑
def clean_wind_data(df):
# 1. 范围过滤
df = df[(df['wind_speed'] >= 0) & (df['wind_speed'] <= 40)]
# 2. 死值检测（连续10个点相同则标记）
df['dead_flag'] = df['wind_speed'].diff().abs() < 0.01
# 3. 缺失填充（线性插值）
df['wind_speed'] = df['wind_speed'].interpolate(method='linear')
return df
注意： 清洗规则一定要可配置。不同风机的传感器型号不同，阈值也不同。我曾经把规则写死在代码里，结果换了批传感器，整个清洗逻辑全废了。后来改成从配置文件读取，省心多了。
数据转换这块，主要是单位换算和格式统一。比如有的传感器输出m/s，有的输出km/h，入库前必须统一。还有时间格式，有的用UTC，有的用本地时间，我建议一律转成UTC+8，避免时区混乱。
4.3 数据归档策略：热温冷三层架构
数据是有生命周期的。刚采集的数据最热，查询最频繁；一周前的数据就很少有人看了；一年前的数据基本只用于年报分析。所以，归档策略的核心就是“按热度分层”。
我常用的方案是热-温-冷三层架构：
| 层级 | 存储介质 | 数据范围 | 查询性能 | 压缩比 |
|---|---|---|---|---|
| 热数据 | SSD / 内存 | 最近7天 | 毫秒级 | 无压缩 |
| 温数据 | HDD / 普通磁盘 | 7天~6个月 | 秒级 | 2:1~5:1 |
| 冷数据 | 磁带 / 对象存储 | 6个月以上 | 分钟级 | 10:1以上 |
归档不是简单的“复制粘贴”。我一般会做降采样：原始数据是1秒1条，归档到冷数据时，可以聚合成1分钟1条（取平均值、最大值、最小值）。这样既保留了趋势信息，又大幅减少了存储量。
-- 降采样示例（TDengine）
SELECT AVG(wind_speed), MAX(wind_speed), MIN(wind_speed)
FROM wind_turbine_data
WHERE ts >= '2024-01-01' AND ts < '2024-07-01'
INTERVAL(1m);
避坑指南： 我曾经设计过一个归档策略，每天凌晨2点执行归档任务。结果某天归档任务卡住了，导致热数据区写满，新数据全丢了。后来我加了监控和重试机制，并且把归档时间错开，比如每台风机错峰归档。嗯，分布式系统里，千万别让所有任务同时启动。
知识体系总览
下面这张图，是我自己总结的数据存储与处理的核心逻辑。你看一眼，基本就能把握住全章的脉络。
你看，整个流程其实不复杂。数据从风场来，经过清洗和转换，存入时序数据库，再根据时间自动归档到不同存储层。每一步都有坑，但只要你按照我上面说的原则来设计，基本不会出大问题。
最后总结一下我的经验：
- 时序数据库选型时，先做POC测试，别光看文档。我见过某数据库号称百万写入，实际一跑就崩。
- 清洗规则一定要可配置、可追溯。每次清洗都记录日志，方便排查问题。
- 归档策略要留有余量。磁盘用到80%就要报警，别等到满了才处理。
好了，数据存储与处理这块就聊到这儿。记住，好的数据层设计，能让你的监控系统跑得又快又稳。下次见！