电网的日常工作，曾经更像一门手艺活。调度员盯着屏幕，凭经验判断哪条线路可能越限；巡线员走遍每一个站点，用手和眼睛检查设备状态；分析员对着报表和数据，一点点核对、汇总、找规律。电网规模有限、复杂度不高的时候，这套逻辑是成立的——多一个人，就多一双眼睛，多一份安全。

但过去十年，这套逻辑的前提正在松动。新能源装机占比持续攀升，出力波动给调度带来更大不确定性；极端天气事件的发生频率明显上升，给电网带来更多突发扰动；用电负荷峰值也在持续刷新。电网的数据量、波动频率、监测难度，都在快速增长。

而人力的增长，是线性的。人海战术的边际成本，已经到了临界点。

系统建了不少，人却一个没少

事实上，这些年电网企业并非没有投入信息化。恰恰相反——SCADA、关系型历史库、专用分析软件，一套接一套地上。但问题出在这里：系统之间的缝隙，还需要人来填。

SCADA 负责采集，关系库负责存历史，专用软件负责计算——三套系统，三套数据口径

• 关系型数据库撑不住高频测点写入，数据丢了、慢了，靠谁？靠人工核对
• 传统历史库偏存储展示，实时计算能力弱，越限监视靠谁？靠人工盯盘
• 系统间数据不互通，报表怎么出？调度员打开 A 系统导出 Excel，再导入 B 系统跑分析，一遍又一遍

人海战术并没有消失，它只是换了一身“信息化”的外衣。

调度员的工作，从“巡检”变成了“搬运”——在系统之间搬运数据、核对数据、修补数据。他们的精力，消耗在填平系统鸿沟这件事上，而不是用在真正有价值的决策判断上。

这不是技术不够先进，而是架构逻辑出了问题。

不做加法，做减法

那么，真正适合新型电力系统的架构应该是什么样？

不是再加一个系统。再加一个系统，本质上只是多一道缝隙，也多一个需要人来填的地方。

正确的方向是反过来——用一个底座把采集、存储、计算、告警全部兜住。数据进来即存储，存储即计算，计算即告警。没有搬运，没有口径对齐，没有“导出再导入”。

做减法的，才叫底座。做加法的，只是在堆烟囱。

而 DolphinDB 走的就是这条路。

与其烟囱式填缝，不如一套底座打通

DolphinDB 的解法是用一个底座把采集、存储、计算、分析、告警、智能辅助全部收敛到一起。

数据的入口是统一的，计算的逻辑是统一的，告警的标准是统一的——中间没有搬运，没有口径对齐，没有“导出再导入”。一种语言、一套技术栈、一个底座，采、存、算、告警都可以在其中完成。

数据采集：进得来、不丢、不乱

电网的数据不只是量大，还很杂——测点读数之外，振动波形、红外热成像、视频巡检等非结构化数据同样在暴增。传统架构里，结构化数据进关系库、非结构化数据走另一套系统，采集端先天被拆成两条线。工控机资源本就有限，两条线来回切换只会让时延更长，告警滞后甚至漏报——这才是"人海战术"的根源：不是没人做，是系统撑不住。

DolphinDB 把这三件事收进同一套底座：

• 分布式架构接住量级增长。测点从百万涨到千万，加节点即可扩容，不需要推倒重来。
• 高可用机制保证不丢数据。数据入库时通过 redo 日志先记后落盘，节点异常重启后可从日志恢复重放；跨节点则通过元数据 raft 机制和数据多副本机制兜底，单点故障不中断服务。
• 多模态存储引擎接住数据的“杂”。结构化测点数据与波形、图像等非结构化数据统一存放、统一检索，不必为不同数据类型再建一套系统、多一条搬运链路。

进得来、不丢、不乱——这是后面所有实时分析和智能决策成立的前提。

实时计算：不等报表，边流边判

传统模式下，数据先存进历史库，再跑离线分析出报表，调度员从报表里找异常——从异常发生到被人看见，中间可以隔几小时甚至几天。更隐蔽的是单点之外的风险：单一测点看起来正常，只有把它们连起来，问题才会显现。

DolphinDB 用两层能力接住这两类问题。流计算框架让判断和告警在数据流入的同时完成，不是“先存后算”，是“边流边判”，告警不再等报表周期，跟着数据实时触发。而复杂事件处理（CEP）引擎 Octopus 补上单点告警看不到的那层：它能把不同测点的信号分别定义成“事件”，识别这些事件按特定顺序或组合出现时构成的模式——即便每个测点单独看都正常，一旦组合关系匹配上预设模式，就直接触发告警。

此外，在传统架构里，批处理和流处理是两套技术栈，同一条越限规则要在离线系统和实时系统里各写一遍，成本翻倍、口径还容易不一致。DolphinDB 的流批一体架构让同一套业务逻辑同时覆盖历史回溯与实时处理，业务人员无需维护两套代码，既节约了开发成本，还规避了两套体系可能带来的批计算与流计算结果不一致的问题。

高性能计算：库内建模，贴近数据执行

在电力场景里，数据量大、时序长、特征复杂，负荷预测、用户画像、异常用电识别等任务，既要做大规模批计算，也要做持续的模型训练和推理。以用电侧为例，亿级智能电表持续产生高频用电曲线，再叠加气象、节假日、产业活动等外部因素，对计算性能和建模效率的要求都非常高。传统架构下，数据治理靠离线脚本，分析靠跨系统搬运，建模还要把数据导出到 Python 里跑，流程长、效率低。

DolphinDB 把这条链路收进库内：

• 数据治理不必单独导出脚本跑：内置 2000+ 函数，覆盖缺失值识别、重复值去重、异常尖峰检测、平滑处理
• 传统机器学习模型可直接调用内置算法及 XGBoost、SVM 等插件，在库内完成训练与推理，无需反复导入导出数据。
• 深度学习场景下，特征存储由 FeatureDB 负责，模型训练在 Python 环境完成，训练结果通过 LibTorch 插件加载回库内做实时推理。

这意味着，模型不必在系统之间反复迁移，而是可以直接在数据所在处完成处理、训练和推理，最大限度减少链路损耗，释放计算效率。

智能决策：经验不再只留在脑子里

除了人力投入，企业更稀缺的是可复用的决策经验。故障根因判断、处置策略选择、工单分流、风险拦截，这些能力过去高度依赖老师傅的经验和人工判断，难以规模化复制。经验一旦无法沉淀，企业的决策效率和一致性就很难提升。

AI 让这些经验有了新的载体：它们可以被整理成知识库、Skill、Agent，变成系统能够直接调用的决策能力。故障诊断规则、处置流程、历史相似案例，不再只是“参考资料”，而是可以嵌入业务流程、自动参与判断和执行的智能能力。

DolphinX 把这些智能化能力集成到统一平台，同时也提供 API 接入业务系统。安全性上，模型生成的脚本先经过安全检查，工具调用复用数据库原有的权限体系，每一次判断都可留痕审计。这样，经验不只是被沉淀下来，而是能真正进入业务流程，成为可执行、可管控、可追溯的决策能力。

案例实战：以抽水蓄能场景为例

案例详情：https://mp.weixin.qq.com/s/L8HxF304UTEJjCgbHDdI4Q

抽水蓄能被称为电力系统的“超级充电宝”——用电低谷时抽水储能，用电高峰时放水发电。一座抽水蓄能电站，一天就能产生 10 亿条数据，长期累计高达千亿条。到了这个量级，单靠“多安排几个人盯盘、多安排几个人核对”早已不现实，数据规模、实时性和关联复杂度，已经远远超出人力能够跟上的范围。这类场景，最能检验一套数据底座到底能不能真正扛住压力。

传统架构面对这个量级，往往绕不开三个问题，也对应三种典型的“人补位”：存储撑不住，就靠运维反复扩容、手动清理告警；查询等不起，跨日期查询衰减到分钟级，调度员只能一边等一边猜；数据合不拢，时序数据、测点信息、设备档案和业务系统数据各自为战，最后还是要靠人工在多个系统里对数据、拼报表。说到底，系统扛不住的部分，最终都压在了人身上。

DolphinDB 的解法是“一套底座，统一管理多类数据”。通过分区机制，全量数据可以分布式存储；需要扩容时，也能快速新增节点，降低运维压力。内置的点位管理能力支持将不同类型测点的数据存储在同一列中，无需建多张表，也无需强制转换数据类型——即便在万亿级数据规模下，查询测点最新值的时延仍可稳定控制在毫秒级，调度员不必再“等结果”。测点描述、设备档案等非时序结构化数据，也可以从多种数据源导入库内统一管理，不再需要人工跨系统拼数据。与此同时，业务逻辑还能被封装成 Skill，支撑智能问数场景，让业务人员不用写查询语句，直接用自然语言就能拿到答案。

实测效果也很直观：某抽水蓄能电站基于 DolphinDB 存储了超过 1300 亿条数据，全量聚合查询耗时不超过 150 毫秒，查找两个测点的最新温度值并关联标签信息，仅需 10.9 毫秒。

省下来的，不只是机器的处理时间，更是原本要靠人工核对、等待和拼接的那部分工作量。

从搬运工到决策者

从人力堆砌，到系统林立、数据各自为政，再到打通底座、走向智能决策——电力行业的数字化转型，正在经历一次从“人找数据”到“数据找人”的变化。DolphinDB 支撑的，正是这条最关键的路径。

这一步的核心，不是用机器取代人，而是把那些人不该做、也做不好的事——核对数据、搬运报表、盯盘告警、跨系统比对——统统交给技术。让业务人员从数据的“搬运工”，回归到真正的决策者。

人海战术的终点，不是更少的人，而是让人做更有价值的事。