{
"componentChunkName": "component---src-templates-case-study-detail-ts",
"path": "/case-studies/38",
"result": {"pageContext":{"next":{"id":42,"attributes":{"feature":true,"title":"智能电站数据中台建设与应用","content":"## **引言**\n\n \n\n近几年随着计算机技术、通信技术、人工智能技术的发展，电站正逐步向网络化、数字化、智能化迈进。智能电站是以电站生产和管理活动中各种信息的数字化为前提，计算机、网络、通信技术为基础，通过采用数据分析和处理、智能控制、自动决策等技术，使得在各种环境条件下都能够提供经济、环保、安全、稳定的电能并与智能电网高度融合的发电站([1-3])。数据信息资源正逐步成为电站的关键要素资源。由于电站信息系统大多是分阶段、分功能实施的，在电站智能化建设过程中，特别是在数据资源使用过程中暴露出来了许多问题。（1）数据孤岛现象严重。各个业务系统数据各自存储、各自定义，数据无法有效连接，数据分散、指标重复建设、数据实用价值低的现象普遍存在。（2）数据缺乏全生命周期管理。电站设计、基建阶段产生的数据不能传递到生产、运维阶段，影响了后期机组及设备的性能诊断和运行优化分析。（3）数据能力未能积累和沉淀。数据服务化程度低，数据共享和交互上缺乏整体协同性，无法形成有效的电站数据资产框架。\n\n如何唤醒电站沉睡的数据资产、打通数据信息壁垒、消除数据烟囱，把数据融合利用起来，是电站智能化转型过程中的难题。而以构建数据资产体系、释放数据资产价值为核心的数据中台正是这一问题的完美解决方案，对提升电站精益化运行管理水平具有十分重要的意义。\n\n \n\n### **1 数据中台架构设计**\n\n \n\n**1.1 电站数据源**\n\n来自电站不同设备和系统的数据主要是生产数据和管理数据，数据类型包含结构化、半结构化和非结构化3类数据。（1）结构化数据包括时序数据和非时序数据。时序数据一般指控制系统现场传感器数据采集过来的数据，比如火电厂的锅炉设备温度、压力等传感器信号，经过规整后存入工业实时数据库中；非时序数据包括各类关键业务系统数据，如智能检修、智能燃料、智能运行、智能经营等系统数据，这些数据基于关系型数据库存储，表现为二维形式。（2）半结构化数据包括各类系统的配置文件、产生的日志文件等，这类数据一般以XML、JSON或自定义文本文件格式存储。（3）非结构化数据包括电站档案系统、门禁系统、智能摄像头、移动机器人产生的各类技术文档、图像文件、音频文件、视频文件等。电站现有平台的管理数据与生产数据没有有效融合，实时数据库与关系数据库的互联互通也存在一定问题，未能进行数据有效组织管理和数据赋能。\n\n**1.2 数据中台架构**\n\n智能电站数据中台通过构建面向电站应用的数据共享和数据分析智能平台，克服了电站现有系统的技术缺陷。数据中台以数据资产高效管理为基础，沉淀数据通用能力，通过构建规范的、安全的、智能的、全域化的数据处理架构，提供数据采集、数据存储、数据萃取、数据治理、数据服务、数据可视化等全链路一体化的服务([4-9])，其技术架构如图1所示。\n\n \n\n\n\n图1 智能电站数据中台技术架构\n\nFig.1 Technology architecture of intelligent power station data middle platform\n\n数据采集是数据中台接入数据的入口，把各种异构数据源的数据采集到数据中台进行集中存储；数据萃取与分析将低价值的原始业务数据转换为高价值的数据资产，通过数据资产框架进行治理；基于数据服务体系将数据以服务化方式交付给业务系统，通过数据可视化框架进行数据展示，激活整个数据中台。\n\n**1.3 数据中台价值**\n\n数据中台的价值体现在“存、通、用、统、快”，如图2所示。通过构建智能电站数据中台，打通数据隔阂，统一数据标准，实现一切业务数据化、一切数据业务化、快速响应用户需求。（1）一切业务数据化。通过业务信息系统的建设，将系统中沉淀的业务数据汇聚到数据中台进行存储，实现一切业务数据化。（2）一切数据业务化。数据中台基于业务系统产生的数据进行体系化加工，将结果以服务化方式提供给业务使用，进而反哺业务，实现一切数据业务化。 \n\n\n\n图2 数据中台价值\n\nFig.2 Value of data middle platform\n\n \n\n### **2 数据中台关键技术**\n\n \n\n**2.1 全域数据采集**\n\n全域数据采集是智能电站数据中台建设的第一步，也是非常重要的一步，为数据中台全面汇集异构数据。数据采集平台可以针对不同的数据源，建立不同的数据采集任务，具备数据采集、转换、传输、复制、迁移、同步等能力([10-11])。（1）电站每台机组控制系统大约有10万个传感器测点，时间戳精度为秒级。转子设备振动数据时间戳精度可以达到毫秒级。采用自主研发的实时数据采集传输程序，基于例外发送、数据缓存、断点续传和历史回补机制，实现电站实时数据的快速高效传输，目前支持OPC、Modbus、101~104规约、CDT规约、RTU规约及其他私有TCP/UDP通信协议。（2）电站业务关系数据库众多，其采集与同步可使用Sqoop和Kettle开源程序。抽取模式可采用全量抽取和增量抽取模式，增量数据抽取一般基于时间戳、触发器、更新标识等机制。（3）电站日志系统数据采集可采用Flume。（4）针对电站外部互联网数据，使用网页爬虫方式自动抓取目标数据。\n\n**2.2 数据湖底座建设**\n\n数据湖底座是智能电站全域数据的存储中心，针对不同数据源和不同数据应用分析需求提供灵活、可扩展的混合型存储架构，以分布式存储系统为核心，能够实现任意规模结构化、半结构化和非结构化数据存储，以提高生产力、主动维护设备，为电站的数据融合提供支撑，为智能运行、智能检修等生产决策提供依据。（1）电站机组控制系统的传感器测点数据采集频率和时间戳精度均为秒级，考虑到存储性能和后期查询、统计、分析性能，采用自主研发的睿腾（Rython）工业实时数据库进行存储，数据库系统架构如图3所示。睿腾实时数据库基于高并发网络通信技术、IO资源管控技术、多级高速数据缓存算法、无损压缩和有损压缩相结合的机制，实现海量测点数据的高效传输、存储、管理和访问。 \n\n\n\n图3 睿腾实时数据库系统架构\n\nFig.3 System architecture of Rython real-time database\n\n \n\n睿腾实时数据库可管控的测点规模可达千万级别。测点表基于两级索引构建，其索引结构如图4所示。在此索引结构中，如果已知一个测点的记录号RecNo，就可通过以下步骤在测点表文件中进行索引定位并进行相应的操作：①计算RecNo/10240可得到该测点所属的一级索引表单元位置，并从一级索引表中读取到二级索引块的起始文件块号；②计算RecNo % 10240可得到该测点所属的二级索引块的单元位置，并从二级索引块中读取到测点属性的文件块号；③根据索引得到的测点属性文件块号，可对该测点属性进行创建和编辑操作；如果需要删除一个标签，则只需要将该测点的二级索引块单元中的标签属性文件块号的高位（第31Bits）置为1即可，不需要更新测点属性。\n\n \n\n\n\n图4 睿腾实时数据库测点表索引结构\n\nFig.4 Tag’s index structure of Rython real-time database\n\n（2）分布式大数据平台基于自主研发的大数据产品，以分布式文件系统为核心，由管理节点和一定数量的工作节点组成大数据存储集群，支撑大数据分析、萃取、挖掘，保存加工处理后的结构化数据和图片、文档等非结构化数据([12])。（3）电站关键业务数据采用分布式关系数据库进行存储。关系数据库平台基于改进的MySql+MHA的部署方案，提供高可用、高数据吞吐能力、扩展性强的关系型数据库引擎。对于分布式数据访问层，采用开源shardingjdbc技术路线。\n\n**2.3 数据萃取与分析**\n\n基于数据开发和算法开发平台，数据萃取层通过电站业务主题域和数据仓库建设，构建完整的智能电站测点数据体系、指标数据体系、设备数据体系、成本数据体系、人员数据体系和文档数据体系。数据开发是将价值不大的原始数据变成对业务有价值的数据资产。数据开发平台产品提供批量计算、流式计算和查询分析能力([13])。（1）批量计算基于MapReduce、Spark等计算框架进行处理，主要用于人机交互较少的批量数据高延时处理，如离线数据仓库的加工、大规模数据清洗与挖掘等，其数据吞吐量大、延时高。（2）流式计算基于Storm、Spark Streaming等计算框架进行处理，数据源为源源不断的流式数据，适用于对数据的加工处理和应用有较高时效性的场景，如设备异常监控告警。（3）查询分析使用ElasticSearch、Kylin、ClickHouse等技术进行处理，适用于历史数据的在线查询、条件过滤和维度分析。算法开发作为一站式的企业机器学习开发平台，包括数据集管理（如数据接入与标注等）、核心算法组件（如回归、聚类、神经网络等）编写、主流算法框架（如TensorFlow、PyTorch、Mahout等）集成、可视化建模，旨在为企业快速提供核心算法服务([14])。基于自主研发的分布式图形化建模计算平台，通过简单的拖拽操作，就可组态出复杂的算法逻辑，为数据中台提供强大的数据建模和计算能力。图形化建模计算平台主要包含以下功能。（1）模型设计器：提供可视化的机理建模、数学建模工具。（2）工程组态：组态工程的编辑、调试、上线、维护管理。（3）算法因子：提供基础通用算法、热力学专用算法、大数据算法等不同种类算法因子。同时可以自定义算法，具备集成第三方算法的能力。（4）计算引擎：基于时间、条件、公式等基础引擎，采用流式计算、离线计算、内存计算等计算模式，进行分布式在线和离线计算。\n\n**2.4 数据资产治理**\n\n数据治理框架，为智能电站提供统一数据标准制定、主数据管理、元数据管理、数据质量管理等能力，通过数据地图和数据血缘实现电站数据360°全链路追踪。框架提供数据全生命周期的管控机制，当发生数据质量问题时，可通过可视化图形方式追溯指标的血缘及逻辑关系、关联指标的数据和权重，进而定位问题([15])。（1）电站资产模型通过设备树的方式进行组织定义，每个设备都用元素表示，元素的关联数据将作为元素的属性进行存储，元素属性数据包括常量、实时数据库测点值、关系数据库引用值、指标公式计算值、图片、文档等。（2）数据治理计算框架基于分布式消息引擎RocketMQ和分布式缓存Redis集群，采用事件触发和周期触发机制，实现设备树海量元素属性数据的层次计算和分析计算。**2.5 数据服务化交付**智能电站数据中台将数据进行服务化交付，企业内部业务系统和第三方应用不必关心底层数据库结构，就可以获得目标数据。通过这样的架构设计，对下屏蔽了异构数据的差异性，对上提供了统一的数据服务接口和标准化数据。当新的业务需求出现时，可以快速进行开发响应。基于自主研发的数据服务网关，可以为业务应用提供以下3种形式的数据服务。（1）OPC UA数据服务。在应用端对数据访问效率要求极高时，如实时性很强的测点数据，推荐使用OPC UA服务。（2）Restful WebAPI数据服务。基于微服务架构和SpringCloud技术体系，提供基于HTTP/HTTP2的服务接口。（3）文件数据服务。基于FastDFS分布式文件系统，为业务应用提供在线文档服务。\n\n**2.6 数据可视化框架**\n\n数据可视化框架基于Vuejs前端开源javascript库和CSS响应式布局模式构建，框架设计器如图5所示。框架组件设计采用MVVM（model view viewmodel）模式进行定义，框架内部基于HTML5、Canvas和WebGL图形绘制技术，实现了大量的2D、3D、VR等图形组件。框架组件间消息通讯采用Weak Event机制实现，这样不仅降低了组件间的业务耦合度，也消除了内存泄漏的风险。开发人员或业务人员使用数据可视化框架能够快速进行生产运营决策驾驶舱的数据准备、指标集建立、业务模型配置、管理视图及可视化图表构建，实现对电站海量数据的汇总统计、多维分析、报表呈现、图形展示，以交互、生动的形式直观、全面、快速地了解电厂生产经营情况并进行辅助决策，进而提升工作效率。 \n\n\n\n图5 数据可视化框架设计器\n\nFig.5 Designer of data visualization framework\n\n \n\n### **3 数据中台应用**\n\n \n\n建设智能电站数据中台的最终目的是高效组织利用数据资源，提升电站精益化运行管理水平。以智能电站建设过程中的3个典型应用场景为例，阐述企业如何应用数据中台，提高数据治理、分析计算和展示能力。\n\n**3.1 设备运行监视**\n\n电站在运行过程中，需要对锅炉、汽轮机、发电机、磨煤机、引风机等关键主辅机设备进行实时监控。设备数据种类复杂、来源众多，以磨煤机为例，主要监视的信息如下。（1）一次测点数据。这些数据来自现场控制系统传感器，如磨煤机电流、功率、进口风量、出口风粉温度等，采集频率为秒级，为时间序列型数据。（2）指标数据。这些数据由不同业务系统产生，如发电量、利用小时、非计划停运次数等指标来自可靠性系统，而发电量、负荷率、耗煤量等指标来自在线经营系统。指标数据均通过一次测点数据不同的运算逻辑统计计算得到。（3）设备基础信息。这些数据主要来自设备管理系统，主要包括设备名称、编码、设备KKS编码、所属专业、设备分类、型号规格、生产厂家、出厂编号、安装地点、安装现场图片等信息。（4）设备检修和缺陷记录。这些信息主要来自ERP系统（如SAP），包括检修发生时间、故障描述、参与人员、耗费人工、使用物料、消缺状态等。在传统信息系统建设方式下，电站的各种系统大多是独立建设的，存在指标重复计算、统计口径不一致、数据信息无法互联互通等问题，也无法很好地应对快速变化的前端业务。通过建设智能电站数据中台，可以消除数据壁垒、统一数据标准，实现异构数据融合和设备运行监视的数据可视化快速配置展示。\n\n**3.2 脱硫优化系统**\n\n当前环保压力日益增大，在保证烟气二氧化硫排放达标的前提下，实现脱硫系统的安全、经济、优化运行日益重要。脱硫优化系统基于智能电站数据中台，采用数据驱动模式和大据挖掘技术，进行机组工况的规律发现、特征抽取、自动识别和智能寻优，给运行人员提供及时精细的操作指导，实现企业效益的最大化([16-18])。（1）确定优化关联指标。对脱硫系统的历史运行原始数据进行多维相关性分析，确定与寻优目标“浆液量”强相关的指标：机组负荷、入口二氧化硫浓度、入口烟气流量、入口烟气温度、入口烟气湿度、吸收塔浆液pH值和出口二氧化硫浓度。（2）采集机组稳定运行工况。一般机组负荷波动不超过15%、至少持续运行1 h认为是一个稳定工况。基于机组运行的海量数据，在数据中台萃取层配置提取规则，进行脱硫系统优化关联指标数据的采集和统计，存储到中台数据湖底座。（3）工况标签化分类。采用中台提供的聚类算法对不同负荷工况进行分类，并对聚类类心进行合理选择。（4）以聚类获得的类心作为训练样本，采用中台提供的有监督机器学习算法建模，如图6所示，建立脱硫系统优化模型([19-21])。 \n\n\n\n图6 脱硫系统优化机器学习模型\n\nFig.6 Machine learning model of desulfurization system optimization\n\n（5）根据实时采集的机组负荷、入口二氧化硫浓度、入口烟气流量、入口烟气温度、入口烟气湿度、吸收塔浆液pH值和出口二氧化硫浓度数据，与稳定工况进行匹配，获得期望的“浆液量”优化目标值。\n\n**3.3 大屏幕和移动应用发布**\n\n大数据时代，电站业务数据场景分析和终端展示呈多样化发展。企业通过大屏幕发布系统，可以建立良好的形象宣传窗口；通过终端移动应用，可以随时随地查询生产实时数据、浏览生产过程图形、监控主要设备状态，对关键运营指标进行分析、钻取和统计分析。基于中台数据治理和可视化框架，采用海量酷炫图表组件和所见即所得数据源配置，用户可以快速进行大屏幕和移动应用功能设计。图7展示了智能电站“发电量分析”移动应用业务场景。 \n\n\n\n图7 智能电站移动应用\n\nFig.7 Mobile app of intelligent power station\n\n \n\n### **4 结语**\n\n \n\n（1）针对电站现有系统存在的数据孤岛、数据未能有效利用问题，分析了电站发电过程中产生的海量数据的数据源类型，设计了智能电站数据中台架构，消除了数据烟囱，统一了数据标准，实现了多源异构数据融合。（2）以数据资产高效治理为基础，通过全域数据采集、数据湖底座建设、数据萃取与分析、数据服务化交付、数据可视化等关键技术方案设计，构建和实现了智能电站数据中台。（3）介绍了智能电站数据中台的典型应用场景，阐述了如何应用数据中台提高数据治理、分析计算和展示能力，对于发电企业建设和应用数据中台具有一定的借鉴意义。","date":"2022-04-20","author":"王毅, 王智微, 何新","excerpt":"在电站智能化建设过程中，为解决现有系统的数据孤岛、数据利用率低等问题，设计了数据中台产品。基于全域数据采集、数据湖底座建设、数据萃取与分析、数据服务化交付、数据可视化关键技术，建立了智能电站数据中台，实现了多源异构数据融合、共享和服务能力，有效提升电站精益化运行管理水平。最后介绍了智能电站数据中台的典型应用场景，对发电企业建设和应用数据中台具有一定的参考价值。","metaDescription":null,"createdAt":"2023-03-30T06:40:05.006Z","updatedAt":"2023-03-30T06:41:58.790Z","publishedAt":"2023-03-30T06:41:58.787Z","locale":"zh","caseStudiesType":{"data":null},"cover":{"data":null},"metaLogo":{"data":null},"localizations":{"data":[]}}},"prev":{"id":40,"attributes":{"feature":true,"title":"基于Sharding-JDBC的订单分库⽅案","content":"# **前言** \n\n随着业务的发展，数据量迅速增⻓，单实例 Mysql 数据库的磁盘存储容量很快就会达到上限（阿⾥云 RDB 最⼤上限6T）。因此为了解决⽣产环境的存储瓶颈，需要对数据库进⾏分库设计，加⼤存储空间。**本⽅案基于Apache开源项⽬ ShardingSphere 采 Sharding-JDBC 进⾏订单⽔平分库设计（数据分⽚）缓解存储压⼒。**\n\n \n\n# **方案对比**\n\n⽬前主流的分库分表⽅案就是 Sharding-JDBC 和 Mycat，下⾯主要对⽐这两种。\n\n\n\n经上述对⽐，可以发现 Sharding-JDBC 是直连数据库、没有中间层的⽅式，性能上更优，同时由于 Sharding-JDBC 集成在应⽤代码内，并不会增加额外的运维成本，使开发者可以专注于⾃⾝代码逻辑。另外，Sharding-JDBC ⽬前仅⽀持 Java，考虑到⽬前团队技术栈主要以 Java 为主，所以采⽤ Sharding-JDBC 的分库⽅案成为了⼀个不错的选择。 下图反映了 Sharding-JDBC 在应⽤中所处的位置：\n\n\n\n \n\n# **原理**\n\nSharding-JDBC 提供了精确分⽚扩展接⼝ org.apache.shardingsphere.api.sharding.standard.PreciseShardingAlgorithm. PreciseShardingAlgorithm，**只需要实现其doSharding ⽅法，基于分⽚键做⼀定的算法转换，返回指定的数据源，便可以达到分库的效果。** ⽬前我们使⽤的是⼀致性 hash 算法，⽤于定位分⽚键所在数据源，同时引⼊虚拟节点，可以避免数据倾斜问题（即有的数据源数据多，有的数据源数据少，导致数据源设备压⼒不均衡）算法原理如图： \n\n\n\n **然后基于该分库的分⽚键&分⽚算法，我们还需在 application.yml 中增加 sharding 数据源配置；同时需要增加分表相关的配置信息。**最后项⽬启动时，sharding 会⾃动加载这些配置初始化数据源。在请求时从请求参数中提取到分⽚键，应⽤分⽚算法，找到⽬标数据源，操作该数据源。 \n\n# **实战**\n\n在原有订单数据源 datasource_name 的基础上，新加3台订单数据库实例 datasource_name_1&datasource_name_2&datasource_name_3，扩充后共4台订单数据库实例，磁盘存储最⼤可以达到原有容量的4倍。\n\n\n\n**4.1引⼊maven依赖**\n\n```xml\n\n\torg.apache.shardingsphere\n\tsharding-jdbc-spring-boot-starter\n\t4.1.1.001\n\n```\n\n这⾥的4.1.1.001版本是在官⽹ sharding 4.1.1版本上⾃⾏扩充了⼀部分内容：本⾝根据业务分⽚键对业务数据进⾏分⽚后，同⼀类型的数据只会在⼀个数据源中，sharding 只能操作这⼀个数据源的数据，但对于⼀部分分⽚键落⼊新数据源后，意味着数据源发⽣了变动，⽽在旧库数据未迁⼊到新库时，会存在⼀定的兼容时期，此时，改造源码实现了如下双操作（除插⼊外）：a、双查询：查询新旧数据源的数据，然后业务项⽬⾥使⽤切⾯进⾏查询汇总去重，根据 id+updateDatetime 进⾏去重，保留最新数据。b、双更新：更新数据时，会同时更新新旧数据源中满⾜条件的数据。c、双删除：删除数据时，会同时删除新旧数据源中满⾜条件的数据。双删的⽬的是，为了避免只 删除了⼀个库的数据，⽽由于双查导致另⼀个库的数据被查询出来误⽤。d、单插⼊：插⼊数据时，只会插⼊新分⽚算法所落⼊的数据源中。这样做的好处是，在不影响业 务的情况下，也减少了⼀部分数据迁移的⼯作量，即分库上线后新数据直接插⼊新库，不⽤做任何处理。\n\n改造源码如下：\n\n```java\npackage org.apache.shardingsphere.core.rule;\n\n/**\n * Databases and tables sharding rule.\n */\n@Getter\npublic class ShardingRule implements BaseRule {\n\n // 定义：旧的分库分片策略\n private final ShardingStrategy oldDatabaseShardingStrategy;\n \n public ShardingRule(final ShardingRuleConfiguration shardingRuleConfig, final Collection dataSourceNames) {\n Preconditions.checkArgument(null != shardingRuleConfig, \"ShardingRuleConfig cannot be null.\");\n Preconditions.checkArgument(null != dataSourceNames && !dataSourceNames.isEmpty(), \"Data sources cannot be empty.\");\n this.ruleConfiguration = shardingRuleConfig;\n shardingDataSourceNames = new ShardingDataSourceNames(shardingRuleConfig, dataSourceNames);\n tableRules = createTableRules(shardingRuleConfig);\n broadcastTables = shardingRuleConfig.getBroadcastTables();\n bindingTableRules = createBindingTableRules(shardingRuleConfig.getBindingTableGroups());\n // 加载旧的分库分片策略\n ShardingStrategyConfiguration oldDatabaseShardingStrategyConfig = shardingRuleConfig.getOldDatabaseShardingStrategyConfig();\n if (oldDatabaseShardingStrategyConfig != null) {\n oldDatabaseShardingStrategy = createDefaultShardingStrategy(oldDatabaseShardingStrategyConfig);\n } else {\n oldDatabaseShardingStrategy = null;\n }\n defaultDatabaseShardingStrategy = createDefaultShardingStrategy(shardingRuleConfig.getDefaultDatabaseShardingStrategyConfig());\n defaultTableShardingStrategy = createDefaultShardingStrategy(shardingRuleConfig.getDefaultTableShardingStrategyConfig());\n defaultShardingKeyGenerator = createDefaultKeyGenerator(shardingRuleConfig.getDefaultKeyGeneratorConfig());\n masterSlaveRules = createMasterSlaveRules(shardingRuleConfig.getMasterSlaveRuleConfigs());\n encryptRule = createEncryptRule(shardingRuleConfig.getEncryptRuleConfig());\n }\n}\n```\n\n\n\n```java\npackage org.apache.shardingsphere.sharding.route.engine;\n\n/**\n * Sharding route decorator.\n */\npublic final class ShardingRouteDecorator implements RouteDecorator {\n \n @SuppressWarnings(\"unchecked\")\n @Override\n public RouteContext decorate(final RouteContext routeContext, final ShardingSphereMetaData metaData, final ShardingRule shardingRule, final ConfigurationProperties properties) {\n SQLStatementContext sqlStatementContext = routeContext.getSqlStatementContext();\n // SQL参数集合\n List