第1章：数据采集技术选型与部署

大家好，我是老张。在风电行业摸爬滚打了十来年，今天咱们聊聊数据采集这块硬骨头。

很多人觉得数据采集就是装几个传感器、拉几根网线的事。嗯，真这么想就太天真了。我见过太多项目，前期采集方案没想清楚，后期运维时数据断流、格式混乱、时间戳对不上……那叫一个头疼。

说白了，数据采集是整个大数据平台的根基。根基不稳，后面所有分析、预测、优化都是空中楼阁。今天我就把SCADA、CMS、气象数据这三类核心数据的采集方案，以及Flume/Kafka的汇聚策略，掰开了揉碎了讲清楚。

1.1 SCADA数据采集：风机的“黑匣子”

SCADA系统，说白了就是风机的运行日志。它记录着每台风机的电压、电流、功率、转速、桨距角、温度……几乎所有能测的电气参数和运行状态。

采集方式

  • OPC UA/DA：这是最主流的协议。风机主控系统一般都支持OPC Server，我们通过OPC Client去拉数据。我个人习惯用OPC UA，安全性更好，跨平台也方便。
  • Modbus TCP/RTU：老一点的风机或者某些特定设备还在用。采集频率不高的话够用，但并发大了容易丢包。
  • 私有协议：有些风机厂商（比如Vestas、Gamesa）有自己的协议。这时候就得用他们提供的SDK或者中间件。我在项目中遇到过，某厂商的私有协议文档写得跟天书一样，最后硬是跟他们的工程师磨了三天才调通。

采集频率

数据类型推荐频率说明
电气参数（功率、电流）1秒用于功率曲线分析、故障诊断
状态量（启停、并网）事件触发变化时才上报，减少数据量
累计量（发电量、运行时间）5分钟用于统计报表，不需要太高频
注意：SCADA数据采集最怕的是“数据风暴”。风机故障时，短时间内会产生大量报警和状态变化，如果采集程序没做好限流和缓冲，很容易把整个系统打崩。我曾经见过一个场站，一台风机报故障，结果采集程序直接OOM，导致全场数据中断了半小时。

1.2 CMS振动数据采集：听风机的“心跳”

CMS（状态监测系统）采集的是振动信号，用来分析齿轮箱、轴承、发电机这些旋转部件的健康状态。这玩意儿跟SCADA不一样，数据量大得多，而且对实时性要求更高。

采集方式

  • 加速度传感器：贴在轴承座、齿轮箱壳体上。采样频率一般在2kHz~20kHz之间。
  • 数据采集卡（DAQ）：把模拟信号转成数字信号。我建议用24位精度的卡，信噪比高，能捕捉到更微弱的故障特征。
  • 边缘计算节点：现在很多CMS厂商都提供边缘计算盒子，直接在风机上做FFT变换、特征提取，只把结果上传到平台。这样能大幅减少网络带宽压力。

数据量估算

举个例子：一台风机装6个振动测点，每个测点采样频率10kHz，24位精度。算下来：

6个测点 × 10,000采样/秒 × 3字节/采样 = 180,000字节/秒 ≈ 1.44Mbps

一个风场50台风机，就是72Mbps。这还只是原始数据。如果做实时分析，带宽和存储压力都不小。

我的建议：CMS数据不要全量上传。在边缘端做特征提取，只上传时域特征（峰值、均方根值）、频域特征（频谱峰值、边频带）和趋势数据。原始波形保留在本地，需要时再远程调取。这样带宽能省80%以上。

1.3 气象数据接入：风从哪里来？

气象数据是风电预测的“粮食”。没有准确的气象数据，功率预测就是瞎猜。

数据来源

  • 测风塔：场站内立的测风塔，数据最准，但维护成本高。我见过测风塔被雷劈坏的，也见过被鸟筑巢堵住风速仪的。
  • 激光雷达（LiDAR）：现在越来越流行。可以测不同高度的风速、风向，精度高，而且不用爬塔维护。
  • 数值天气预报（NWP）：从气象局或商业气象服务商买数据。分辨率一般在3km~10km，需要做降尺度处理才能用到单台风机。
  • SCADA反演：利用风机本身的功率和转速数据，反推轮毂高度的风速。这个方法成本低，但精度有限，只能作为补充。

数据格式

气象数据常见的格式有：

  • CSV：简单，但缺乏元数据描述。
  • NetCDF：气象行业标准格式，自带维度、变量、属性信息。我强烈推荐用这个。
  • GRIB2：NWP数据常用格式，压缩率高，但解析起来稍微麻烦点。
关键点：气象数据接入时，一定要处理好时间对齐。测风塔数据是本地时间，NWP数据可能是UTC时间，SCADA数据又是另一个时间基准。我曾经因为时间戳没对齐，导致功率预测模型训练出来全是错的，排查了整整两天才发现是时区问题。

1.4 使用Flume/Kafka进行数据汇聚

好了，SCADA、CMS、气象数据都采集上来了。但问题是，它们来自不同的系统、不同的协议、不同的频率。怎么把它们统一汇聚到大数据平台？

这里我推荐用Flume + Kafka的组合拳。

整体架构

SCADA数据源 CMS数据源 气象数据源 Flume Agent集群 Source（数据源） Channel（通道） Sink（下沉） Kafka集群 Topic: scada_data Topic: cms_data Topic: weather_data 数据采集、格式化、缓冲 数据持久化、解耦、削峰

Flume配置示例

下面是一个典型的Flume配置，从SCADA的OPC UA接口采集数据，写入Kafka：

# 定义agent名称
agent1.sources = scada_source
agent1.channels = kafka_channel
agent1.sinks = kafka_sink

# 配置source：OPC UA采集
agent1.sources.scada_source.type = org.apache.flume.source.OPCUASource
agent1.sources.scada_source.endpoint = opc.tcp://192.168.1.100:4840
agent1.sources.scada_source.pollInterval = 1
agent1.sources.scada_source.nodeIds = ns=2;i=1001,ns=2;i=1002

# 配置channel：使用内存通道，提高吞吐量
agent1.channels.kafka_channel.type = memory
agent1.channels.kafka_channel.capacity = 10000
agent1.channels.kafka_channel.transactionCapacity = 1000

# 配置sink：写入Kafka
agent1.sinks.kafka_sink.type = org.apache.flume.sink.kafka.KafkaSink
agent1.sinks.kafka_sink.kafka.topic = scada_data
agent1.sinks.kafka_sink.kafka.bootstrap.servers = kafka1:9092,kafka2:9092
agent1.sinks.kafka_sink.serializer.class = kafka.serializer.StringEncoder

# 绑定
agent1.sources.scada_source.channels = kafka_channel
agent1.sinks.kafka_sink.channel = kafka_channel

为什么选Flume + Kafka？

  • 解耦：数据生产者和消费者互不依赖。SCADA系统挂了，不影响CMS数据写入。
  • 削峰填谷：风机故障时数据量暴增，Kafka能缓冲住，下游慢慢消费。
  • 多源汇聚：不同数据源可以写到不同的Kafka Topic，下游再根据需要做流式处理或批量入库。
  • 高可用：Flume和Kafka都支持集群部署，单点故障不影响整体。
避坑指南：我曾经在项目里直接用Logstash替代Flume，结果发现Logstash在处理高频CMS数据时CPU飙到90%以上，而且经常OOM。后来换成Flume，同样的数据量，CPU只用了20%。所以，高频数据场景，Flume比Logstash靠谱得多。

1.5 数据质量与监控

数据采集上来只是第一步，保证数据质量才是关键。我总结了几条经验：

  • 心跳检测：每个数据源每5分钟发一个心跳包。如果连续3个心跳没收到，就触发告警。
  • 数据完整性校验：检查数据是否有缺失、重复、乱序。特别是SCADA数据，时间戳必须严格递增。
  • 值域校验：风速不可能超过50m/s，功率不可能超过额定功率的1.2倍。超出范围的数据直接标记为异常。
  • 延迟监控：记录每条数据从采集到进入Kafka的延迟。如果延迟超过30秒，说明系统有瓶颈。
重要提醒：数据质量监控一定要做自动化。别指望人工盯着看。我见过一个场站，数据断流了整整一周都没人发现，因为运维人员只看SCADA界面，没看数据平台。后来我们加了自动告警，数据断流超过5分钟就发短信给值班人员。

好了，数据采集这块就聊到这儿。记住一句话：采集方案设计得好，后面运维省心一半。下一章咱们聊聊数据存储的选型，看看HBase、InfluxDB、ClickHouse这些家伙到底该怎么选。

专注资料整理
← 上一章 📖 返回目录 下一章 →