电力现货市场全面进入5分钟出清时代之后储能交易员的日常工作节奏被彻底打乱了。以前15分钟一个点还能用Excel拉完数据慢慢分析现在5分钟一个点一天288个出清时段光盯盘就得盯到眼花。我接手储能电站交易监控这个活儿的时候第一个感受就是靠人盯是盯不住的必须得有一套能扛住5分钟节奏的实时监控大屏。这套大屏上线之后最直观的变化是每天收盘后不再需要花一两个小时手动核对申报结果和出清结果了。系统自动把96点甚至288点的曲线拉出来哪里有偏差、哪笔申报没成交、哪个时段价格异常全部在几秒钟内呈现。这篇文章就围绕这套监控大屏的完整搭建过程展开从需求拆解、架构选型到指标定义、实时计算引擎对比再到部署和踩坑复盘一次性讲清楚。适合正在做储能交易、电力现货交易系统或者对能源行业实时监控平台感兴趣的朋友参考。1. 5分钟出清到底改变了什么监控需求从“分钟级”变成了“秒级”先说一个很多人没意识到的问题5分钟出清不是把15分钟的数据密度简单提高三倍而是从根本上改变了交易员的操作模式。15分钟出清时代一个时段内你有充足的时间去判断、申报、校核监控大屏更多是“事后复盘”工具。但5分钟出清时代288个出清时段意味着系统每5分钟就要产生一轮完整的申报、出清、结算数据循环任何环节的迟滞都会被放大。我最初设计监控大屏时核心需求其实来自三个非常具体的痛点交易员需要实时掌握“当前时段”的现货价格走势包括日前价格、实时价格、出清价格三条曲线的收敛情况。以前15分钟一个点看两条曲线差别还不大现在5分钟一个点价格跳动频率极高靠人工盯盘基本等于赌博。储能电站的充放电策略需要根据实时价格信号快速调整大屏必须把“当前可充可放的剩余容量”“当前出力”“计划出力”“实时电价”四个关键量放在同一视野内。一旦出现偏差要立刻告警否则一个时段没跟上损失的就是真金白银。申报结果的确认和异常识别必须实时化。5分钟一个申报窗口人工复核根本来不及系统需要在出清结果返回后立即比对申报值和成交值任何不一致都要弹窗提示并给出偏差原因分类。这三个痛点对应到监控大屏上就是三块核心能力实时数据接入与展示、储能运行状态与市场的联动分析、异常申报的自动识别与告警。而为了支撑这三块能力底层的数据链路、存储选型和计算引擎都要重新设计原有的15分钟数据仓库思路完全跟不上节奏。我见过不少同行在这个阶段的误区以为只是把刷新频率从“1分钟刷新一次”改成“5秒刷新一次”就够了。实际完全不是这样5秒刷新只是把旧数据拿过来重新画一遍真正的实时监控大屏需要的是5分钟事件驱动的“数据流”架构——每一个出清时段结束一次全链路的计算、比对、告警、归档自动完成整个过程要控制在几秒钟内这样交易员才能在下一次申报前看到上一轮的完整结果回执。2. 数据基座选型为什么我放弃了传统关系型数据库做实时通道这套监控大屏的底层数据最核心的是一条交易数据流从市场出清结果的接入到储能电站运行数据的汇聚再到前端大屏的展示整个链路必须保证低延迟、不丢数、可回溯。我一开始的想法很简单直接用MySQL或PostgreSQL建几张宽表定时拉取数据写到表里前端轮询查表就好。但实测下来288个时段的数据加上高频的储能运行数据传统关系型数据库在写入和查询并发上很快就出现了瓶颈。具体来说5分钟出清产生的大量时序数据有非常明显的特征写入频率高、数据只追加不修改、查询模式固定按时间范围取数、按设备维度聚合。这种特征天然适合时序数据库。我最终的数据基座选型如下数据接入层以MQTT和Kafka双通道接入。市场出清结果通过官方数据接口以消息形式推送用Kafka保证消息不丢失储能电站的本地运行数据通过MQTT网关接入因为现场设备大多支持MQTT协议接入成本最低。数据存储层采用“时序库关系库”双轨制。时序数据库用TDengine国产开源时序数据库部署简单性能足够专门存放所有的出清价格序列、运行功率序列、SOC序列关系数据库存交易申报记录、账户信息、结算结果等结构化数据这部分量不大但需要强一致性。数据计算层采用流式计算引擎处理实时数据我用的是Flink。当时也有人推荐Spark Streaming但我最终选Flink的核心原因是它的事件驱动模型更适合“每一个出清时段触发一次完整计算链”的场景而且支持精确一次Exactly-once语义不会漏算、重算。这套双轨架构落地之后效果非常明显后端写入耗时从原来的秒级降到毫秒级前端大屏拉取5分钟曲线的平均耗时从原来的3到5秒降到800毫秒以内交易员基本感觉不到卡顿。不过这套架构也有一个需要注意的点时序库和关系库之间的数据一致性。在初期我用定时任务把时序库的数据同步到关系库做归档后来发现实时计算和归档任务并行时偶尔会出现数据不齐的情况。最后我调整为“以时序库为实时主库、以关系库为离线归档库”的策略所有实时查询一律直接打时序库关系库只做离线分析和报表导出彻底绕开了双写一致性的坑。3. 大屏核心指标体系不是堆数字而是帮交易员做减法这是整套系统搭完之后我觉得最有复盘价值的一部分。很多人做监控大屏容易犯的毛病是“什么都往上放”一个屏幕恨不得塞满所有能查到的指标好像数字越多就越专业。但储能交易的大屏不一样它的使用者不是基金经理而是需要每5分钟做一次快速决策的交易员。交易员在5分钟出清节奏下真正需要的信息其实非常聚焦我把它归纳为“一个核心、四个辅助、三个告警”。一个核心核心指标是“充放电收益偏离度”。这个指标的计算逻辑是当前时段按照实时价格和当前SOC计算出的理论最优充放电收益与实际执行出力产生的实际收益之间的偏差百分比。偏差越小说明策略执行越到位偏差超过一定阈值比如5%大屏立刻高亮告警。四个辅助指标分别是出清价格三曲线日前、实时、实时预出清当前时段市场供需比储能电站当前充放电状态与可调容量本日累计充放电收益与预测收益对比三个告警是我在踩坑中总结出来的申报未成交告警比对当天申报记录与出清结果只要申报价格在出清边界附近而未被成交立刻提醒交易员关注避免“看得见吃不着”的申报陷阱。充放电反向告警储能处于充电状态但实时价格高于放电阈值或者储能处于放电状态但实时价格低于充电阈值。这种反向工况是储能交易里最常见的亏损来源。数据断流告警如果超过5分钟没有收到新的出清数据或设备运行数据系统自动标记“数据疑似断流”防止大屏显示的是陈旧数据。这套指标体系的背后是我和交易员反复沟通后达成的共识大屏不是用来“看”的而是用来“做决策”的。任何一个数字如果不能让交易员在5分钟内做出一个更好的决策那它就不应该出现在第一屏。多余的指标我全部放进了“下钻详情页”想深入分析的人可以点击进去看但主屏只保留高密度的决策信息。这里也分享一个具体计算实例方便大家理解“充放电收益偏离度”的算法设计。假设一个100MW/200MWh的储能电站当前时段实时电价为0.45元/kWh理论上最优策略是满功率充电2小时100MW x 2h 200MWh成本为200000kWh x 0.45 90000元。但实际因为SOC限制只充了160MWh成本为72000元则当前时段的理论充放电收益为负值因为是充电时段收益体现在后续放电差价实际执行收益相对理论收益的偏差即为“充电不足偏差”。这个偏差如果持续出现说明策略或设备执行有问题需要检查组串故障、功率限制等物理原因。4. 5分钟作业节奏下的技术债我经历的三次架构调整做这套实时监控大屏说实话上一版方案的时候我自己心里也没底。因为5分钟出清带来的高频数据流和过去15分钟出清的低频数据流完全不是一个量级的工程问题。整个开发过程中我经历了三次比较关键的架构调整每次调整都踩了不少坑但也在过程中把系统的性能一步步磨出来了。4.1 第一次调整从轮询变成事件驱动最早版本的架构非常简单后端写一个定时任务每5分钟去拉一次出清结果然后写入数据库前端每5秒轮询一次接口刷新数据。听起来没毛病但实际运行两个小时后我就发现了问题定时任务的时钟和出清时刻并不能精确对齐经常出现“数据还没拉到前端已经在等待”的空窗期而且每次轮询拉取的都是全量数据随着时段数据的累积数据库压力急剧上升。后来我把“定时拉取”改成了“事件驱动”出清数据一进入Kafka后端立刻被唤醒执行入库、计算、推送一整套动作前端也不再轮询而是通过WebSocket接收后端主动推送的最新数据。这个调整上线后数据从出清结果产生到大屏刷新的延迟从原来的“最长5分钟”缩短到了“1到3秒”。4.2 第二次调整从全量计算变成增量计算第一次调整解决了数据新鲜度的问题但很快新的问题暴露了每5分钟触发一次的计算如果每次都把当天所有288个时段的数据重新算一遍随着时段数增多单个事件的处理时间越来越长到下午时段已经达到了10秒以上眼看就跟不上5分钟的节奏了。这次调整的核心是从“全量计算”改为“增量计算”每次只计算当前新增的1个时段的指标同时对“充放电收益偏离度”这类累积指标做增量更新。为了支持增量计算我在时序库里专门建了一张指标中间表每次计算结束后把当前时段的中间结果如时段收益、充电量、放电量、价格加权值写进去下次计算只需要读取上一时段的中间结果和当前时段的新数据就可以快速算出最新值。优化之后单次事件处理时间稳定在2秒以内。4.3 第三次调整实时计算和展示彻底分离第三次调整是我个人觉得最有价值的一次架构演进。前两个版本都存在同一个隐患实时计算逻辑和前端展示逻辑混在一起前端某个图表配置改一下就要重新发布后端服务非常容易出错。我给系统做了一次彻底的前后端功能切割实时计算层独立成一个“计算服务”只负责指标计算、告警判定和数据推送展示层独立成一个“可视化服务”只负责接收数据、渲染图表、响应用户操作。两层之间通过Kafka和Redis解耦计算服务把计算结果写入Redis缓存并发布消息可视化服务订阅消息后从Redis读取数据渲染。这样改完之后前端想调整展示结构完全不碰计算服务后端想改算法指标也不会影响正在展示的页面。这次调整还有一些额外的好处。因为展示层的数据全部来自Redis缓存前端刷新页面、多人同时访问大屏时后端不会重复计算压力非常小。同时因为计算服务和展示服务可以独立发布迭代速度明显加快后续新增指标、调整告警阈值都变成了轻量操作。5. 实时计算引擎的选型对比Flink配置与作业调优实录前面提到我最终选了Flink做实时计算引擎但当时其实也对比了其他方案。这里把对比过程和调优经验详详细细写出来给准备做类似系统的朋友一个参考。5.1 选型对比Flink vs Spark Streaming vs ClickHouse实时物化视图我当时调研了三个方案Flink流式计算框架支持事件驱动、精确一次语义。优点是非常适合“每个出清时段触发一次完整计算链”的场景延迟低、可扩展性强缺点是学习曲线陡峭运维复杂度高。Spark Streaming微批次模型延迟在秒到分钟级在5分钟出清场景下其实也能满足但微批次有一定延迟叠加而且处理精确一次语义不如Flink自然。时序数据库的实时物化视图比如TDengine的连续查询Continuous Query或者ClickHouse的物化视图。优点是可以直接做“每5分钟自动聚合一次”的操作不需要单独维护一套流式计算框架缺点是不够灵活复杂的计算逻辑比如需要查关系库做比对很难在一个纯SQL表达式中完成。最终选Flink核心原因是储能交易监控大屏不只是做简单的聚合它要做“申报值 vs 成交值”比对、“SOC和实时价格联动的策略偏差计算”、以及“告警判定”等多步复杂逻辑这些在Flink中可以用成熟的有状态流处理算子优雅实现而在物化视图里写会非常痛苦。5.2 Flink作业的关键配置我在调优Flink作业时有四个配置参数值得专门说checkpoint间隔我设置了60秒做一次checkpoint。间隔太短频繁做快照磁盘IO压力大间隔太长任务失败恢复时会丢更多状态。60秒是我实测下来的平衡点。状态后端用的是RocksDB因为状态里有每天288个时段的数据和SOC序列量级不小RocksDB的磁盘存储比内存更稳。并行度我根据数据分区数设置了与Kafka分区数一致的并行度。Kafka的topic设了6个分区Flink的source算子并行度就设6保证一个分区对应一个Flink并发实例不会造成分区数据竞争。水印Watermark策略因为出清数据是事件时间驱动的我设置了允许15秒乱序的水位线防止网络抖动导致的数据乱序影响计算结果。5.3 Flink作业的日常运维心得Flink作业上线后最大的感受是“它能跑但你要伺候好它”。我遇到过两个比较典型的坑一个是RocksDB的状态膨胀。有时候上游数据量突增或者某天出清结果有异常重发RocksDB的状态会快速膨胀导致checkpoint持续变慢。我的处理方式是给状态配置TTLTime-to-live把超过一天的历史时段数据在状态里自动清理只保留必要的中间指标有效控制了状态量。另一个是作业重启后的“数据补偿”问题。Flink重启后如果从最近一次checkpoint恢复会丢失checkpoint到重启之间的数据。对监控大屏来说这段时间的数据不能凭空消失。我的做法是在Flink作业的source端增加一个“重放逻辑”启动时先从时序库里查询当前处理到哪个时间点然后把缺失时段的数据重新拉取一遍。虽然代码多写了几十行但保证了异常情况下的数据完整性。6. 大屏可视化设计交易员不是看热闹是看门道数据架构和技术选型说完了最后聊聊大屏前端的可视化设计。这也是很多人容易忽略的地方技术再好前端一塌糊涂价值就减半。储能实时监控大屏的可视化设计和普通的BI报表完全不同。BI报表是给人“慢慢探索”的大屏是给人“一眼抓住重点”的。我设计时的核心原则有三条高信息密度、低认知负担、强告警感知。高信息密度指的是每一个像素都要传递有效信息。我不做大面积的无意义装饰大屏的顶部是滚动的时间轴与当前时段信息中部是三张核心价格曲线日前、实时、实时预出清的叠加走势图左下是储能电站的SOC和充放电功率仪表盘右下是告警事件列表和收益统计卡片。每块区域都有明确的“视觉锚点”交易员扫一眼就能定位到自己关心的数据。低认知负担指的是把数据变成“一眼就能看懂”的视觉元素。价格曲线我用了不同颜色日前用白色、实时用黄色、实时预出清用绿色而且曲线末端会有一个发光的小圆点表示“最新值”这样交易员不需要看坐标轴就能直观感受到三条曲线的价差走势。SOC仪表盘我用了渐变色的弧线图绿色到红色的过渡表示电量高低比单纯显示“85%”要直观得多。强告警感知是我最看重的设计。普通的状态展示型大屏告警可能只是弹一个红色的Toast。但交易监控大屏的告警必须在视觉上“抢注意”。我的做法是告警发生时对应区域会有一个脉冲动画同时整个大屏顶部的告警灯带会亮起告警色如果是严重告警比如充放电反向工况大屏会自动切换到“告警聚焦模式”把最相关的曲线和状态卡片放大显示交易员无需任何点击就能看到问题所在。前端技术方案上我选了Vue3 ECharts WebSocket的组合。ECharts在K线图、折线图、仪表盘等可视化场景非常成熟5分钟刷新一次的数据量对它来说完全没压力WebSocket保证了实时推送的即时性。一开始有人建议我用WebGL做3D大屏说视觉效果更炫酷但被我否了——储能交易大屏最重要的是“精确”和“快速”不是“炫”。3D效果反而会分散交易员对核心数据的注意力。7. 部署与运维中的5个实战细节部署这套系统的时候踩了不少坑我把其中最关键的5个细节单独拎出来每个都是真金白银换来的经验细节一时序数据库的保留策略一定要提前规划。288点一天一天就有288条价格序列再加上储能运行数据一天的数据量比15分钟出清时代涨了3倍。我一开始没有设置保留策略跑了两周发现磁盘告警。后来设置了“原始数据保留90天、聚合数据保留2年”的降采样策略磁盘压力立刻缓解。细节二告警阈值必须做成“可配置”的不能写死在代码里。不同时段的告警阈值其实应该是不同的比如充放电收益偏离度在电价飙升的尖峰时段偏离度很容易超阈值但不一定是真问题而在平时时段微小的偏离度反而更值得警惕。我把告警阈值做成了一张独立的配置表可以随时调整不用发版这个决定在后续几次策略调整中帮了大忙。细节三大屏必须支持“历史回放”模式。交易员盯实时大屏盯久了会疲惫但复盘的时候需要把某一天的曲线完整调出来仔细看。我的做法是给大屏加了一个“时间旅行”开关可以随意切到任意历史日期所有曲线、告警、收益卡片都会同步回放到那个时间点。这个功能上线后使用频率比实时模式还高。细节四接口的容错设计必须到位。市场出清数据偶尔会有推送延迟、重复推送的情况。我在接入层做了“幂等处理”每条数据带一个唯一的业务主键时段数据类型版本号重复推送时直接丢弃防止同一时段的结算数据被计算两次。细节五大屏要有“降级方案”。如果实时计算服务挂了不能整个大屏白屏。我给系统设计了降级逻辑展示层检测到WebSocket数据流中断超过30秒后自动切到“只读模式”直接从时序库查询最近一段时间的数据渲染最近状态同时顶部提示“实时数据流异常当前为降级视图”。这样至少交易员还能看到最近的数据不至于两眼一抹黑。8. 从“有大屏”到“用大屏”上线后的运维法则和收益复盘系统上线一个月后交易团队的氛围发生了微妙的变化。以前每到出清时段交易员都像打仗一样忙手机、电脑、紧急沟通群全部开启生怕错过一个价格信号现在有了实时监控大屏大部分情况下只要盯住大屏上的异常告警就行只有在告警弹出时才会触发人工介入流程。从实际收益看这套系统带来的改善主要有三点申报偏差的及时发现率大幅提升。以前申报未成交的情况有时候要等到收盘后核对结算单才能发现晚几个时段补救成本非常高。现在一旦申报未成交大屏几乎立刻高亮提示交易员可以在下一个时段马上调整策略。充放电方向错误的次数明显减少。储能运行方向与市场价格方向偶尔会背离这是最钱直接的亏损来源。大屏的“充放电反向告警”上线后这类情况都能在发生后的5分钟内被捕捉到而不是等到零点结算复盘时才发现。交易团队的时间和精力被释放出来。以前花大量时间做数据整理和曲线核对现在这些都由系统自动完成交易员可以把更多心思花在策略优化和异常市场场景的分析上。不过我还是要泼一盆冷水监控大屏本质上是一个“感知工具”它不能替代交易策略本身。系统做得再好如果背后的申报策略是错的大屏只是帮你看得更清楚你在亏钱。所以搭完大屏之后更重要的是把精力放在策略模型上用大屏的数据反馈去迭代优化策略参数。我自己在实际运维中的体会是这类系统的价值不是体现在“炫酷的大屏”上而是体现在“交易员可以更安心地下班”这件事上。出清结果一回来系统自动比对、自动归档、自动告警交易员只需要在真有问题时处理问题其余时间精力留给策略研究和复盘。如果你也在做储能交易或者电力现货市场的相关工作这套“数据流实时计算可视化告警”的搭法完全可以复用核心就一句话让每一个5分钟的数据事件都能在几秒钟内变成可决策的信息这就够了。
