第1章：平台总体架构设计
大家好，我是老张。在风电行业摸爬滚打了十来年，今天咱们聊聊大数据平台的骨架——总体架构设计。
很多人一上来就堆技术栈，结果项目做到一半发现跑不动。我见过太多这样的案例了。其实，架构设计就像盖房子，地基没打好，后面全是坑。
1.1 分层架构设计
风电大数据平台，说白了就是一套从风机上取数据、存数据、算数据、用数据的流水线。我习惯把它切成四层：
核心四层架构：数据采集层 → 存储层 → 计算层 → 应用层
数据采集层
这是最接地气的一层。风机上的传感器每秒都在产生数据——振动、温度、转速、功率、风速、桨距角……
我早期做过一个项目，现场用的是Modbus TCP协议，采集频率是1秒一次。一台风机一天就能产生86万条记录。一个风场50台风机，你算算多少？
采集层要解决三个问题：
- 协议适配：Modbus、OPC UA、IEC 61850，都得支持
- 断点续传：网络不稳定时不能丢数据
- 数据缓冲：用Kafka做消息队列，扛住突发流量
我的经验：采集层千万别用单点。我曾经有个项目，采集服务器挂了，整整丢了3小时的数据。后来我强制要求所有采集节点必须做双机热备。
存储层
数据进来了，往哪放？这是个大学问。
风电数据有鲜明的时序特征——每条数据都带时间戳。用传统的关系型数据库？嗯，不是不行，但查询性能会让你哭。
我推荐的分层存储方案：
| 数据类型 | 存储方案 | 保留周期 |
|---|---|---|
| 原始时序数据 | InfluxDB / TimescaleDB | 30天 |
| 聚合统计数据 | ClickHouse | 1年 |
| 历史归档数据 | HDFS / MinIO | 永久 |
| 元数据 | MySQL / PostgreSQL | 永久 |
注意：千万别把所有数据都往一个库里塞。我见过有人把原始数据和聚合数据都放InfluxDB，结果查询聚合报表时，数据库直接卡死。
计算层
数据存好了，得算啊。风电场景的计算分两种：
- 实时计算：比如风机超速告警、振动异常检测。用Flink或Spark Streaming，延迟控制在秒级。
- 离线计算：比如月度发电量统计、功率曲线分析。用Spark或Hive，每天凌晨跑一次。
我个人习惯把实时和离线分开部署。为什么？因为实时任务对资源敏感，离线任务跑起来容易把CPU吃满。混在一起，实时任务就遭殃了。
应用层
这一层是给业务人员看的。包括：
- 风机运行监控大屏
- 故障告警与工单管理
- 发电量统计分析
- 运维报表自动生成
应用层我建议用前后端分离架构。前端用Vue或React，后端用Spring Boot或Go。这样扩展起来方便。
1.2 技术选型原则
技术选型这事儿，我踩过的坑比走过的路还多。总结下来就两条原则：
原则一：开源优先 —— 别动不动就上商业版，社区版够用就别花钱。
原则二：生态兼容 —— 选的技术要能互相配合，别搞成技术孤岛。
举个例子，Kafka + Flink + ClickHouse 这个组合，在风电行业非常成熟。Kafka负责缓冲，Flink负责计算，ClickHouse负责存储和查询。三者都是Apache生态的，集成起来很顺畅。
你想想看，如果选了某个小众的消息队列，Flink不支持，还得自己写连接器，那不是给自己找麻烦吗？
我推荐的技术栈：
| 层级 | 推荐技术 | 选型理由 |
|---|---|---|
| 采集层 | Kafka + Flume | 高吞吐、生态好 |
| 存储层 | InfluxDB + ClickHouse + HDFS | 时序优化、列式存储、低成本 |
| 计算层 | Flink + Spark | 实时离线双引擎 |
| 应用层 | Vue + Spring Boot | 前后端分离、社区活跃 |
避坑指南：我曾经选过一个叫"XXDB"的时序数据库，号称性能无敌。结果社区版限制节点数，生产环境一扩容就要买授权。后来全量迁移到InfluxDB，折腾了整整两周。所以，选型时一定要看社区版的License。
1.3 高可用与灾备设计
风电大数据平台，7×24小时不能停。风机在转，数据就在产生。平台挂了，告警发不出去，后果很严重。
高可用设计，我习惯从三个维度考虑：
1. 计算节点高可用
Flink和Spark都支持集群模式。我一般部署3个节点起步，配置Active-Standby模式。主节点挂了，备用节点秒级接管。
# Flink高可用配置示例
high-availability: zookeeper
high-availability.storageDir: hdfs:///flink/ha
high-availability.zookeeper.quorum: zk1:2181,zk2:2181,zk3:21812. 存储层高可用
InfluxDB用副本集，ClickHouse用分布式表，HDFS用3副本。数据不会丢，服务不会断。
我记得有一次，一台存储服务器的磁盘坏了。因为做了3副本，数据自动从另外两台节点恢复，业务完全无感知。
3. 灾备设计
灾备分两种：同城灾备和异地灾备。
- 同城灾备：两个机房，距离10公里以内，光纤互联。数据实时同步。
- 异地灾备：跨省部署，数据异步同步。用于应对区域性灾难。
重要提醒：灾备方案一定要定期演练。我见过太多公司，灾备方案写得漂漂亮亮，结果真出事了才发现数据同步没配好，备份根本不能用。建议每季度做一次灾备切换演练。
嗯，架构设计这块，今天就聊这么多。记住一句话：架构不是一次定死的，它要随着业务发展不断演进。别追求完美，先跑起来再说。
公众号:蓝海资料掘金营，微信deep3321