第3章数据监控核心

3. 数据监控核心：实时数据展示、趋势曲线、历史数据查询、报表生成

做风电SCADA这么多年，我最大的感触就是——数据监控这块，看着简单，做起来全是坑。你想想看，一个风场少说几十台风机，每台风机上百个测点，数据每秒都在刷新。怎么把这些数据变成运维人员看得懂、用得上的东西？这就是本章要聊的核心。

本章核心脉络：实时数据展示让你「看到现在」，趋势曲线让你「看懂变化」，历史数据查询让你「回溯过去」，报表生成让你「总结规律」。四者缺一不可。

3.1 实时数据展示——让数据「活」起来

实时数据展示，说白了就是让运维人员一眼看清风机当前的状态。我见过太多项目，数据展示做得花里胡哨，结果现场人员根本找不到关键信息。嗯，这里要注意——实时展示的核心不是「炫」，而是「准」和「快」。

我个人习惯把实时数据分成三个层级：

概览层：风场总览图，显示每台风机的运行状态（运行、停机、故障、维护）。用颜色区分，绿色正常、红色故障、黄色告警、灰色停机。
机组层：点击某台风机，进入单机详情。显示关键参数：有功功率、风速、转速、桨距角、发电机温度等。
测点层：最底层，展示某个具体传感器的实时数值和变化趋势。

我的经验：实时数据刷新频率不要一刀切。关键保护信号（如超速、振动）用100ms刷新，普通运行参数用1秒，统计类数据（如发电量）用5秒就够了。刷新太快，服务器扛不住；太慢，又怕漏掉异常。

举个例子，我们看一段前端实时数据展示的伪代码逻辑：

// 实时数据订阅（WebSocket方式）
const ws = new WebSocket('ws://scada-server:8080/realtime');

ws.onmessage = function(event) {
    const data = JSON.parse(event.data);
    
    // 只更新变化的测点，避免全量刷新
    if (data.changedPoints.length > 0) {
        data.changedPoints.forEach(point => {
            updateDisplay(point.id, point.value, point.timestamp);
            checkAlarm(point);  // 顺便做报警判断
        });
    }
};

function updateDisplay(id, value, timestamp) {
    // 数值变化超过阈值才更新UI，避免闪烁
    const element = document.getElementById(id);
    if (Math.abs(value - element.dataset.lastValue) > 0.01) {
        element.textContent = value.toFixed(2);
        element.dataset.lastValue = value;
    }
}

这段代码里有个细节——Math.abs(value - element.dataset.lastValue) > 0.01。为什么要加这个判断？我在项目中遇到过，有些传感器信号有微小抖动，比如风速在5.01和5.02之间来回跳，如果不做滤波，界面会一直闪烁，运维人员看着眼晕。

3.2 趋势曲线——看见数据的「脾气」

实时数据只能告诉你「现在怎么样」，趋势曲线才能告诉你「接下来会怎么样」。我个人觉得，趋势曲线是SCADA系统里最有价值的功能之一。

趋势曲线分两种：

实时趋势：展示最近几分钟到几小时的数据变化，用于监控当前运行状态。
历史趋势：展示过去几天、几个月甚至几年的数据，用于分析长期变化规律。

画趋势曲线时，有几个坑一定要避开：

时间轴对齐：不同测点的采样频率可能不同，画在同一张图上时，时间轴必须对齐。我曾经遇到一个项目，功率数据是1秒一个点，风速数据是10秒一个点，直接画在一起，曲线完全错位。
数据压缩：展示一个月的数据，如果每秒一个点，那就是260万个点。浏览器根本扛不住。需要用旋转门算法或死区压缩算法做降采样。
多轴显示：功率和风速量级不同，功率是MW级，风速是m/s级。画在一起必须用双Y轴，否则风速曲线会变成一条直线。

注意：趋势曲线的数据源一定要打时间戳。不要依赖数据库的插入时间，因为网络延迟可能导致数据乱序。我见过一个风场，因为数据采集服务器时间没同步，趋势曲线上的数据点前后颠倒，运维人员差点误判了故障原因。

下面是一个趋势曲线数据查询的SQL示例：

-- 查询某台风机过去24小时的功率和风速数据
-- 使用时间分区表，提高查询效率
SELECT 
    time_stamp,
    active_power,
    wind_speed
FROM 
    wind_turbine_data_202401  -- 按月分表
WHERE 
    turbine_id = 'WTG-012'
    AND time_stamp >= NOW() - INTERVAL '24 hours'
    AND time_stamp <= NOW()
ORDER BY 
    time_stamp ASC
LIMIT 10000;  -- 防止一次返回太多数据

3.3 历史数据查询——翻旧账的艺术

历史数据查询，说白了就是「翻旧账」。风机出了故障，你得查故障发生前后的数据；要做性能分析，你得查过去几个月的运行数据。怎么查得快、查得准，这里头有门道。

我建议历史数据查询功能要支持以下几种方式：

查询方式	适用场景	注意事项
按时间范围查询	故障分析、日常巡检	时间跨度不宜过大，建议单次查询不超过1个月
按事件触发查询	故障前后数据追溯	自动提取故障前5分钟到后10分钟的数据
按统计周期查询	月度/年度数据分析	支持平均值、最大值、最小值、累计值
自定义条件查询	高级分析、科研用途	支持多条件组合，如风速>12m/s且功率<500kW

历史数据存储是个大问题。一个中型风场（50台风机），每台风机200个测点，每秒存一次，一天就是86.4亿条记录。怎么存？

时序数据库：我推荐用InfluxDB或TimescaleDB。传统关系型数据库扛不住这个量级。
数据降采样：原始数据保留7天，之后自动聚合为分钟级数据，再之后聚合为小时级数据。这叫「数据金字塔」策略。
分区存储：按时间分区，查询时只扫描相关分区，速度能快几十倍。

避坑指南：我曾经遇到一个项目，历史数据查询特别慢，查一个月的数据要等两分钟。后来发现是索引没建好。记住，时间戳字段一定要建索引，而且要用复合索引（时间戳+风机ID）。

3.4 报表生成——把数据变成决策依据

报表这东西，做得好是运维人员的得力助手，做得不好就是没人看的废纸。我见过太多SCADA系统，报表功能做得极其复杂，结果现场人员根本不用，还是自己拿Excel手工统计。

报表的核心原则：自动化、标准化、可定制。

常见的风场报表类型：

日报：昨日发电量、可利用率、故障次数、平均风速。每天早上8点自动生成，推送到相关人员邮箱。
月报：月度发电量统计、故障分布分析、性能指标对比（与设计值对比、与同期对比）。
年报：年度综合评估、设备健康度分析、运维成本统计。
故障报表：每次故障的详细记录，包括故障代码、发生时间、恢复时间、处理措施。

报表生成的技术实现，我一般这样设计：

-- 日报生成SQL示例
-- 统计昨日每台风机的关键指标
SELECT 
    turbine_id,
    COUNT(*) AS fault_count,
    SUM(active_power * 0.001) AS energy_mwh,  -- 功率对时间积分得电量
    AVG(wind_speed) AS avg_wind_speed,
    (SUM(run_time) / 86400.0) * 100 AS availability_pct
FROM 
    turbine_daily_stats
WHERE 
    date = CURRENT_DATE - 1
GROUP BY 
    turbine_id
ORDER BY 
    turbine_id;

关键点：报表数据不要实时从原始数据表里查。应该提前做好预计算，把日报、月报的数据存到统计表中。用户查看报表时，直接从统计表里取数据，秒级响应。

报表的展示格式，我个人习惯支持三种：

网页在线查看：直接在SCADA界面里展示，支持交互式筛选和排序。
PDF导出：用于存档和邮件发送。注意PDF的排版要固定，不能因为浏览器不同而变形。
Excel导出：给喜欢自己分析的人用。Excel模板要预置好公式和图表，用户打开就能用。

嗯，说到Excel导出，我踩过一个坑。有一次导出的Excel文件，用户打开后说数字格式不对，小数点变成了逗号。后来发现是服务器区域设置的问题。所以导出时一定要显式指定数据格式，不要依赖系统默认设置。

最后说一句，数据监控这块，技术实现只是基础，真正难的是理解业务需求。你做的再好，如果现场运维人员觉得不好用，那就是白搭。多去现场听听他们的反馈，比看十本技术书都有用。

📚 课程目录

3. 数据监控核心：实时数据展示、趋势曲线、历史数据查询、报表生成

3.1 实时数据展示——让数据「活」起来

3.2 趋势曲线——看见数据的「脾气」

3.3 历史数据查询——翻旧账的艺术

3.4 报表生成——把数据变成决策依据