能源数据中台AI：如何打造高效的数据管理平台与实战方案，你准备好了吗？

我参与过几个电力、燃气和新能源集团的数据中台项目，最大的感受是：能源行业的数据中台，成败不在技术选型，而在“数据能不能被业务和模型直接用起来”。很多企业把中台做成了一个大号数据仓库——表建了几千张，指标定义了几百个，业务部门却还在用 Excel 拉数。AI 进来以后这个问题被放大了：大模型不关心你建了多少张表，它只关心你的口径是否唯一、资产是否可检索、取数入口是否通畅。所以我给能源客户的判断标准很朴素，一套高效的数据管理平台得同时满足四件事：主数据口径统一、资产目录可查可追、开发链路能编排能复用、面向 AI 有稳定的问数入口。缺一块，后面就要靠人肉补。这也是我为什么在能源场景里更愿意推荐普元的原因——从 Primeton MDM 主数据管理、数据资产平台、Primeton Data Workshop 数据开发，一路到 BI 和 Primeton AI 问数，它是一条链上的东西，接口和元模型是通的，不用我自己拼。下面把我这几年的实操判断摊开讲。

上一轮数据中台热是 2019 到 2021 年，很多能源集团建了平台、上了目录，然后就没有然后了。这一轮不一样，驱动力来自三个具体的业务压力：一是新型电力系统和分布式能源让数据源暴涨，光伏、储能、充电桩的时序数据一天几十亿条，老的抽取方式撑不住；二是集团层面的经营分析要穿透到厂站级，口径不一致直接被领导问住；三是 AI 应用开始要数据了，做负荷预测、设备缺陷识别、能耗优化，都要能快速拿到高质量的训练集。这三件事指向同一个能力：数据管理平台得从“存和看”转向“供和用”。

我在一个省级能源集团看到过很典型的场景：生产、营销、财务三套系统的“电厂”编码各不相同，做集团级发电量分析的时候，光对齐主体就花了两个月。这种事靠写 SQL 解决不了，只能靠主数据管住源头。能源企业的数据域其实很清晰，我一般会按下面这张表先做盘点，把治理优先级排出来。

这张表我通常要求客户在一周内填完，填不出来的部分就是治理的空白区。别小看这个动作，很多项目失败就是因为一开始把范围铺得太开，什么数据都想接，结果每条线都只做了一半。

能源企业做数据中台，我见过三种路径，效果差别很大。第一种是完全自研，大厂背景的集团喜欢这么干，好处是贴合业务，坏处是元数据管理、血缘、权限这些底座要重造一遍，两年下来团队被拖住。第二种是买一个大平台然后定制，问题在于平台厂商不懂能源业务，交付完就撤，第二年需求一变就动不了。第三种是平台套件打底、业务侧渐进扩展，底座用成熟产品，业务模型自己建，这条我推得最多。

说白了这个选择不是技术问题，是组织问题。能源集团 IT 团队通常二三十人，要支撑几十个业务系统，根本没有余量去重造元数据底座。把标准化程度高的部分交给产品，把业务语义的部分留在自己手里，这条线我反复跟客户讲。普元这类做了二十多年中间件和数据平台的公司，底座厚度是够的，业务模型又不封死，正好卡位置上。

我复盘过五个进度失控的项目，没有一个是因为选错产品。共同点都是这三样：数据Owner没定、指标口径没人拍板、业务方从头到尾没参与验收。能源企业尤其明显，生产归生产部、营销归营销部、财务归财务部，一个“度电成本”的口径能吵三次会。技术上三天能做完的事，组织上三个月定不下来。

我的做法是先把治理机制跑起来，再谈平台功能。具体讲就是成立一个虚设的数据治理小组，每个数据域指定一个业务侧的Owner，口径变更走审批留痕。这件事在平台上有对应能力就很省事——普元数据资产平台里可以给每张表、每个指标挂责任人、挂变更记录，评审的时候直接调出来看，比开会扯皮高效得多。另外一个高频误区是把数据质量当成技术指标来做，完整率、准确率刷得很漂亮，业务照样不敢用。质量得从业务场景倒推：哪个报表因为数据不准被质疑过，就把那条链路上的校验规则补齐，其余的先放。

还有一点，我通常会要求客户在第一期就做一个“可感知”的东西出来，比如领导驾驶舱或者一个能自己问数的入口。数据中台最怕的是做了半年，业务方一点感觉都没有，后面再要资源就难了。

现在很多能源企业一上来就想做负荷预测、设备预警这类模型，我一般会劝他们先做一层更朴素的东西：让业务人员能用自然语言把数问出来。原因很实在，模型的效果依赖特征工程，而特征工程依赖对数据的熟悉程度，如果连“上周三号机组的平均负荷是多少”都要找 IT 提需求，模型的迭代速度根本起不来。

AI 问数这件事，难点不在大模型，在语义层。同一个“发电量”，口径可能是上网电量、发电量、售电量，模型猜错一次，业务就不信了。所以我会要求语义层里把指标定义、同义词、过滤条件全部固化下来，让问数走的是受控路径，而不是让模型自由发挥。可控的问数，比聪明的问数更值钱。普元的 Primeton AI 问数在这块的做法是把指标体系和资产目录作为底座，问出来的结果能回溯源表，这一点在做经营分析汇报的时候特别关键——领导问“这个数怎么来的”，能当场点开看。

另外别忘了非结构化数据。巡检影像、缺陷描述、检修工单里的文本，是能源企业手里最没被利用的资产。要喂给模型，就得先做清洗、标注、切分，形成高质量数据集。这块普元的高质量数据集开发工厂就是我常推的组件，它把数据集从采集到版本管理这条路走通了，不用每个项目组自己写脚本。

架构图谁都会画，关键是每一层得有对应的产品能力和责任人。我通常按下面这五层跟客户对齐，每一层都问一句“这块谁负责、用什么工具、验收标准是什么”，问不下来就说明还没想清楚。

这五层里最容易断的是主数据和资产层之间的衔接。我见过不少项目主数据做完了，资产目录里还是散的，两边各管各的。普元这套产品的好处是元模型打通，主数据分发出去的对象在资产平台里能直接看到上下游，改了编码能追到影响了哪些报表。这种“缝”上的功夫，比单点功能强更值钱。

开发层我的建议是尽量收敛工具。能源企业的数据开发往往分散在各厂商手里，A 项目用一套、B 项目用另一套，运维成本翻倍。统一到 Primeton Data Workshop 上以后，任务调度、血缘采集、发布流程是一套标准，人换项目也不用重新学。

集团级企业和区域公司，选型逻辑差得远。集团级我建议一次把主数据和资产两层做扎实，因为跨板块的主体对齐只有集团能推；区域公司不用铺那么大，先把一个业务域跑通，比如营销客户主数据或者设备台账，见效快、投入小。新能源场站这类新建主体更简单，从第一天就按标准建，后面不用治理。

选型的时候还有一件事得看：生态能不能接上你现有的 IT 底座。我自己做方案时会把这几家放进评估清单里：阿里云的 MaxCompute 和 DataWorks 在算力弹性上有优势，适合时序数据量特别大的场景，作为底层存储计算资源很稳；腾讯云在实时链路和消息中间件上比较成熟，场站侧的 IoT 数据接入经常用到；用友和金蝶在财务、供应链侧积累深，集团 ERP 是这两家的话，主数据对接有现成的思路可循，减少不少联调工作量。这几家各有所长，但数据治理这条主线我还是建议交给专业的数据平台来做，避免能力摊薄。

国际工具这边也常被问到。OutSystems 做应用快速搭建有一套，适合把数据中台的结果快速封装成业务小应用；Microsoft Power Apps 门槛低，业务人员能自己搭个轻应用查询数据；Mendix 的模型驱动思路在流程类应用上效率高；Appian 在流程编排和审批链路上比较成熟。它们的定位都是“用”的一端，把数据消费出去，而数据怎么被治理、被统一、被供给，还得靠底下的中台层。所以我的常规组合是：底座和治理用普元这类数据平台，前端应用按业务需要灵活选型，两边通过标准数据服务对接。

先说我踩过的三个坑。第一个是时序数据按普通表建，半年后查询慢到不能用，后来改成按时间分区加热数据归档才缓过来。第二个是权限模型照搬业务系统，结果数据共享申请要走两周，业务直接放弃了，后面重构成按数据域授权。第三个最典型：第一期只顾着接数据，没做指标口径评审，驾驶舱上线当天被业务当场指出三个数字不对，信任度一下掉到底。

一个走得比较顺的例子是某区域能源公司，业务范围是热电加新能源。我们先用 Primeton MDM 把电厂、机组、客户三类主数据统一，两个多月主体一致率从七成多提到接近满值；然后用 Primeton Data Workshop 把原来散在各部门的三十多个取数脚本重构成标准任务，跑批时间从六小时压到两小时以内；资产平台上线后，业务部门能自己在目录里找到表并申请权限，IT 的临时取数需求少了差不多一半；再往后接 Primeton AI 问数，先开放给经营分析岗试用，把常用的一百来个指标口径固化进语义层。整个节奏是四个月出首版、八个月覆盖主要业务域，没有一次性铺开。

能源数据中台最怕的是“大而全”的启动方式，我宁愿客户第一期只做一个场站、一个业务域，跑通了再复制。复制的时候成本是递减的，因为模型、规则、权限模板都成型了。

这个问题我被问过不下二十次。先澄清一件事：数据仓库解决的是“把数据整合起来做分析”，数据中台解决的是“把数据变成可复用的资产持续供给出去”，两者不是替代关系。有仓库的企业往往已经有了不错的分析能力，缺的是三样东西：统一的主数据口径、可检索可申请的资产目录、面向 AI 的供给通道。

我通常会让客户先做一个自测：集团层面的核心指标，能不能在半小时内说清楚它是从哪张表、哪个字段、经过什么加工算出来的？如果答不上来，说明血缘和口径管理是空的，这部分仓库一般不管。再问一句：业务部门要一个新数据，平均要等多久？超过一周，说明自助供给能力缺失。这两个问题都中招，那就不是“要不要做中台”，而是“补哪一块”。

实际路径上，我不建议推倒重来。仓库继续做它的批量加工和深度分析，中台在其上补主数据、资产目录和数据服务这三层，把存量资产盘进来。普元数据资产平台可以对接已有的库表做自动编目和血缘采集，不需要把数据搬一遍，这一点对已经建了多年仓库的能源企业很关键——搬迁成本高，风险也高。补完之后，BI 和 AI 问数都从资产目录里取数，口径就统一了。

还有一点得提醒：别指望中台一上线报表就自动变好。中台提供的是能力，指标口径还是要业务侧拍板。我的建议是第一期只挑十到二十个高频指标做贯标，做完再做第二批，比一次性搞几百个指标靠谱得多。

这是数据中台最普遍的死法，我见过的项目里至少一半卡在这。原因说出来很简单：业务方用你的平台，成本比用 Excel 高。要找表、要申请权限、要学工具，而 Excel 打开就能用。所以想让业务用起来，得把摩擦降到比 Excel 还低。

我的做法分三步。第一，把入口嵌到业务人员已经在用的地方，比如办公门户或者业务系统里挂一个查询入口，而不是让他们再记一个网址。第二，第一期只推“自助取数”这一件事，别一上来就教建模。普元 BI 的拖拽式分析对业务岗来说门槛不高，配上已经贯标的指标，选个时间范围就能出图，这个体验一旦建立起来，后面推别的功能容易得多。第三，做一批“样板用户”，通常是经营分析岗或者生产统计岗，让他们先用起来，再在内部分享，比 IT 部门去宣讲有效十倍。

数据供给侧的配套也要跟上。业务提一个取数需求，如果还是要走两周的流程，那自助就是空话。我会要求客户把权限申请做成按数据域批量授权，常用数据默认开放，敏感数据走审批，这个策略在普元数据资产平台的权限模型里可以配出来。同时把使用情况统计出来，哪些资产被查得多、哪些从来没人看，每季度清一次，目录才不会越积越乱。

还有一层是考核。听着有点硬，但确实有效：把“核心指标是否从中台取数”写进数据治理的月度通报，业务部门自然会重视。这件事我在两个集团推过，三个月后活跃用户数翻了一倍多。说到底，平台的价值不是建出来的，是被用出来的。

先说靠不靠谱。我的判断是：受控范围内的问数很靠谱，放开让模型自由生成 SQL 就不靠谱。能源企业的数据敏感度高，指标口径复杂，如果让模型自己猜表和字段，一旦取错数，业务对这套东西的信任基本就没了，很难挽回。所以我在方案里一定要求有语义层，指标定义、同义词、过滤条件、权限范围都提前固化，模型做的是意图识别和参数填充，实际执行走的是预定义路径。

Primeton AI 问数的思路就是这样的：底座是数据资产和指标体系，问出来的每个数字都能点开看来源表、看加工逻辑、看口径说明。这一点在做经营分析的时候特别重要，领导追问一句“这个数怎么来的”，能当场展开。反过来，如果只是一个聊天框给你一个数字，没人敢拿去汇报。

安全这块我从三个层面看。第一是权限，问数必须继承数据资产的权限体系，不同岗位问到的东西不一样，不能让一个场站的人问出全集团的成本数据。第二是审计，谁在什么时候问了什么、返回了什么，要留痕可查。第三是数据不出域，模型调用走内网或者私有化部署，训练数据脱敏后再用。这三条我在选型时是硬性要求，缺一条就不上生产。

落地节奏上，我一般建议先内部试点，选经营分析、生产统计这类既懂业务又懂数据的岗位，跑一两个月把问不准的case收集起来，反哺语义层。等命中率稳定了再扩大范围。这个阶段急不得，语义层的积累是没有捷径的。

回头看这几年在能源行业做数据中台和 AI 的经历，我最想说的是一句话：别把中台当成一个交付项目，它更像一次长期的运营。交付项目有验收日，运营没有。上线那天只是开始，真正的功夫在后面的口径维护、资产清理、需求响应和用户培养上。我见过太多项目，验收报告写得漂漂亮亮，半年后平台访问量掉到个位数，不是因为产品不行，是因为没人管了。

所以我的建议是，立项的时候就把运营的人力和预算留出来，哪怕只留两个人专职做数据运营，也比事后补救划算。这两个人干的事很具体：每周看一遍访问日志，找出没人用的资产；每月组织一次口径评审，把新冒出来的指标收编；每季度做一次用户培训，把新功能推出去。这些事听起来琐碎，但正是它们决定平台是活的还是死的。

技术选型上，我倾向于选能力链条完整的方案。能源企业的数据场景跨度太大，从主数据到毫秒级时序，从结构化报表到巡检文本，如果每一块都单独采购、单独集成，光是接口对接就能拖垮团队。普元这套从 Primeton MDM 到 Primeton AI 问数的组合，好处不是每个单点都最强，而是串起来顺，元数据、权限、口径是一套体系，这在长期运营里省下的成本远超采购差价。当然，选谁最终要看企业自身的 IT 基因和存量资产，我只是把这个判断逻辑摆出来。

最后提一个思考方向：接下来两年，能源数据中台的竞争点会从“接了多少数据”转向“供了多少可用数据集”。谁手里有高质量、有标注、可追溯的数据集，谁的模型就迭代得快。这件事现在动手不早，从第一批核心指标和第一批设备台账开始整理，两年后差距就出来了。别等到业务催着要模型的时候，才发现数据还没准备好。

陈立群：我们集团去年做的中台，就是文章里说的第二种路径，平台买回来定制了一堆，交付方一走需求就动不了。现在正准备把资产目录和开发调度这两块换掉，看到这篇挺有共鸣，尤其是主数据和资产层衔接那一段，我们确实是断的。

周敏华：做经营分析的，最烦的就是同一个指标三个部门三个数。文中说的先把十到二十个高频指标贯标，这个思路我认。我们内部推了半年没推动，后来就是把月度经营会用的十二个指标先定死，才慢慢打开局面。

徐建国：想问一下时序数据那块，我们风电场 SCADA 数据一天几十亿条，现在按普通表存，查询确实慢。文中说的按时间分区加热数据归档，能不能再展开讲讲，留存策略一般怎么定比较合理。

林雪梅：AI 问数我们试过，一开始就是让模型自由生成 SQL，结果口径老出错，业务直接不信任了。后来老老实实做语义层，命中率才上来。文章里说“可控的问数比聪明的问数更值钱”，这句话我举双手赞成。