简介新能源充电站负荷预测数据集面向电力系统、智能交通与机器学习领域的研究者与开发者整合时间序列用电记录、充电行为特征与外部环境参数可支撑充电负荷预测建模、站点效能评估及电网协同优化研究。整套资源共32个文件压缩包大小约1.97MB内含17个Python脚本、5个CSV站点负荷数据以及说明文档、可视化图片、许可证文件等。Python脚本覆盖数据加载、时间特征提取、掩码处理、评价指标与模型构建环节CSV文件提供Perth、PALO、Boulder、EVnetNL等多地充电站的实际负荷序列便于开展多站点对比与泛化性验证。目前已有82人学习该数据集可帮助快速完成负荷预测任务的基线复现结合温度、降水、假期等外部因素分析负荷波动驱动要素。资源按data、utils、exp、models等模块组织目录结构清晰适合课程设计、论文实验或工程预研。1. 新能源充电站负荷预测数据集三个维度怎么合并成一个可训练的时序问题做充电站负荷预测的人多半都卡在同一个地方公开数据集要么只有充电功率曲线要么只有天气记录缺了能把充电行为和外部环境串起来的那根线。这个标题之所以值得细看因为它把时间序列、充电行为、环境因素拆成了三个明确的数据维度目标是构造成一个能直接喂给模型训练的综合数据集。对做运营调度、容量规划、有序充电策略的工程师来说这套数据决定了你是只能做“昨天什么样今天大概也这样”的基线预测还是能真正捕捉雨天、通勤日、商场打折日带来的负荷跳变。这篇笔记围绕数据集怎么建、特征怎么对齐、预测怎么做、坑在哪来展开适合手里有充电桩运营数据但不知道怎么组织成训练集的从业者。2. 原始数据从哪来三个数据源的对齐是数据集的第一道门槛2.1 数据源与字段结构先定三张表别急着合并构造充电站负荷预测数据集第一步不是写爬虫而是先把三个数据源的边界划清楚。常见做法是分成三张原始表充电记录表、站点信息表、环境气象表。充电记录表来自充电桩运营平台或国网桩联网系统核心字段包括充电开始时间、结束时间、充电电量kWh、最大功率kW、桩编号、用户类型公交/网约车/私家车。站点信息表描述物理实体包括经纬度、所在区域类型居民区/商业区/高速服务区、桩数量、额定功率、是否配备储能。环境气象表从气象站接口或第三方天气服务获取逐小时或逐15分钟一条包含温度、湿度、风速、降雨量、辐照度部分场景还要加入空气质量指数因为雾霾天会改变人们出行意愿。这三张表不要一开始就做join先保持独立存储用站点ID和时间戳做关联键。原因很实际充电记录是稀疏事件一个桩一天可能有几十条记录气象数据是稠密时间序列每15分钟就有一条站点数据是静态属性一天不变。三者粒度不同强行合并成一张宽表会导致大量空填充后面做滞后特征时还会引入未来数据泄漏。我一般会用三张Parquet文件分别存原始层字段名统一用小写下划线时间字段统一存储为UTC时间戳时区信息单独用一列记录避免不同站点跨时区时排序错乱。2.2 时间对齐策略15分钟粒度背后的取舍逻辑数据对齐的粒度选择会直接决定模型上限。15分钟粒度是这个领域最常用的折中方案充电行为的最短有效充电片段通常在20分钟以上15分钟聚合不会丢失太多事件细节同时一天有96个点一周有672个点这个规模对LSTM或Transformer来说输入序列长度适中不需要做过于激进的下采样。如果用电高峰在分钟级波动比如某物流站同时涌进20辆电动货车可以单独对这个站做5分钟粒度但全量数据集统一用15分钟。对齐方法上先按桩维度聚合对每条充电记录把开始时间和结束时间按15分钟bucket切分电量按时间占比分摊到每个bucket里。举个例子一条10:07开始、10:32结束的记录跨越10:00-10:15、10:15-10:30、10:30-10:45三个bucket总电量3.6kWh分摊比例约为8分钟、15分钟、2分钟。分摊后再按站点分组求和得到站点级15分钟负荷序列。天气数据如果只有小时级用前向填充把整点值广播到该小时内的4个15分钟bucket不要用插值。充电行为集中在前半夜、早上通勤和午休时段差几分钟对负荷总量影响不大但插值会平滑掉突变反而破坏模型对真实波动的拟合能力。import pandas as pd def align_charge_to_15min(df_charge, bucket_min15): df_charge 字段: site_id, start_ts, end_ts, energy_kwh, max_power_kw 返回站点级15分钟聚合序列 rows [] for _, r in df_charge.iterrows(): # 将充电区间切分为15分钟bucket bucket_start r[start_ts].floor(f{bucket_min}min) current bucket_start while current r[end_ts]: seg_start max(current, r[start_ts]) seg_end min(current pd.Timedelta(minutesbucket_min), r[end_ts]) seg_minutes (seg_end - seg_start).total_seconds() / 60 seg_energy r[energy_kwh] * seg_minutes / (r[end_ts] - r[start_ts]).total_seconds() * 60 rows.append({ site_id: r[site_id], ts: current, energy_kwh: seg_energy, max_power_kw: r[max_power_kw] }) current pd.Timedelta(minutesbucket_min) df_bucket pd.DataFrame(rows) df_site df_bucket.groupby([site_id, ts]).agg( energy_kwh(energy_kwh, sum), peak_power_kw(max_power_kw, max) ).reset_index() return df_site这段代码里seg_minutes和seg_energy的计算是核心按实际占用的分钟数把电量分摊到对应的bucket里避免把一次充电的完整电量全部算进结束时刻的那个bucket否则会出现负荷“堆积”在某一个点上的假峰值。floor(15min)是pandas内置的时间向下取整比手动算秒数可靠得多。字段energy_kwh是后续聚合的基础peak_power_kw保留最大值而不是平均值是为了反映充电桩是否出现过载风险。2.3 环境因素的时空匹配站点气象不能用一个城市的值代替很多人在环境因素处理上犯的第一个错误就是拉一个城市级天气数据给全部站点用。城市气象站的数据是“面”上的但充电站负荷对微气候相当敏感高速服务区站的雨量和其他区域差异不大但遮挡情况、是否室内停车场会影响温度对充电功率的影响——高温时车载BMS会限流低温时电池活性下降导致充电慢这两个效应如果只用一个城市温度值模型学不到站间差异。正确的做法是优先为每个站点匹配最近的自动气象站数据用经纬度做距离计算取半径30公里内最近的站点如果没有再退回到城市级数据并把这个站标记为“低置信度气象匹配”。环境特征不只是温度本身还要构造“体感”相关变量。气温对负荷的影响不是线性的——零下5度和零上5度充电时长变化远比零上15度和零上20度明显。我一般会额外构造加热度日HDD和降温需求CDD两个累计特征HDDmax(18-温度, 0)CDDmax(温度-24, 0)用阈值截断把非线性关系变成两个线性分段。降雨量和风速这类离散事件变量则编码成一档/二档/三档的有序分类而不是直接用毫米数因为气象站测的毫米数和充电站局部实际感受差异太大模型直接拟合反而容易过拟合。3. 特征工程与相关性验证把行为和环境织进时间序列3.1 时序基础特征滞后项、滚动窗口和周期编码的搭配原则有了原始负荷序列和天气数据后下一步是构造模型真正消费的特征。滞后项是最直接也最容易被滥用的特征lag_1、lag_2、lag_96对应前一天同一时刻、lag_672前一周同一时刻是三个必加的项因为它们分别编码短期惯性、日周期性和周周期性。滞后项不是越多越好超过7个滞后项后特征间共线性会急剧上升LightGBM这类树模型还能扛但LSTM等神经网络会明显受影响。滚动窗口特征用来捕捉趋势而非瞬时值。我常用的组合是过去1小时的均值4个点、过去6小时的均值24个点、过去24小时的均值96个点再加一个过去24小时的标准差衡量波动。标准差这个特征往往被忽略但它对充电站负荷波动极有区分度——居民区的标准差大高速服务区工作日白天标准差小这两个站点的行为模式差异首先体现在方差上而不是均值上。周期编码用正弦余弦把一天中的时刻0-95映射成两个连续值让模型感知到“每15分钟相对一天的相位”这个操作对LSTM尤其重要因为循环神经网络不容易自己学会周期位置。def build_temporal_features(df, site_id_colsite_id, ts_colts, value_colenergy_kwh): df df.sort_values([site_id_col, ts_col]).reset_index(dropTrue) grp df.groupby(site_id_col)[value_col] # 滞后特征 df[lag_1] grp.shift(1) df[lag_2] grp.shift(2) df[lag_96] grp.shift(96) # 前一日同时刻 df[lag_672] grp.shift(672) # 前一周同时刻 # 滚动窗口 df[roll_mean_1h] grp.transform(lambda x: x.rolling(4, min_periods1).mean()) df[roll_mean_6h] grp.transform(lambda x: x.rolling(24, min_periods1).mean()) df[roll_std_24h] grp.transform(lambda x: x.rolling(96, min_periods1).std()) # 周期编码 minute_of_day df[ts_col].dt.hour * 60 df[ts_col].dt.minute df[sin_time] np.sin(2 * np.pi * minute_of_day / (24 * 60)) df[cos_time] np.cos(2 * np.pi * minute_of_day / (24 * 60)) return df这段代码的关键点在groupby配合shift和transform的用法grp.shift(1)会按站点ID分组后在各组内部做滞后不会跨站点串数据。如果用全局shift上一个站点的最后一条记录会变成当前站点第一条记录的滞后值这个泄漏会让验证集指标虚高。min_periods1是两个滚动窗口的兜底参数数据量小于窗口长度时仍能算出部分均值避免前96个点全部变成空值导致训练样本白白丢掉。3.2 环境因素的特征化从天气原始值到行为调节因子环境特征不能和时序特征简单拼接需要做一定的“业务翻译”。比如降雨量对负荷的影响有延迟——下暴雨时正在路上的车不会立刻消失但30到60分钟后到达充电站的车会减少而暴雨结束后积压的充电需求会集中释放。所以环境特征要做滞后对齐降雨量lag_0当前时刻、lag_41小时前、lag_82小时前三档让模型自己学延迟响应权重。温度特征同理但方向相反——低温对充电功率的影响是直接的物理效应不需要延迟而高温对快充功率的限制则在热失控保护触发时瞬时生效。我通常会把温度拆成三个特征当前温度、过去6小时平均温度累计冷热积累效应、温度突变幅度当前值减3小时前的值用绝对差。温度突变这个特征在换季期特别重要春秋两季昼夜温差超过10度时负荷曲线会出现规律性错位不加这个特征模型会误判为随机波动。环境的“行为调节因子”还有节假日和工作日标签。节假日对充电站负荷的影响分为两类高速公路服务区站在节假日第一天和最后一天负荷暴增2到3倍居民区站则相反会下降。直接用0/1节假日标签不够建议构造“距最近法定节假日的天数”和“当日是否在长假窗口内假期前1天、假期中、假期后1天”两个衍生特征。周几这个特征不能直接用整数编码周一1周日7会让模型误以为周日和周一是连续数值应该用one-hot或embedding。3.3 相关性分析不是图好看特征筛选的实用判据很多人做相关性分析是画一张热力图截图放论文里就完了但对数据集构建来说相关性分析的真正用途是筛掉冗余特征降低过拟合风险。我的做法分三步先计算所有特征和目标的Pearson相关系数筛掉绝对值小于0.05的特征再对保留的特征算两两相关性如果两组特征相关系数超过0.9保留和target相关性更高或业务含义更明确的那一组最后用LightGBM跑一次带特征重要性排序的快速训练看特征重要性和相关性排序是否一致——如果不一致说明有混淆效应。需要强调的是充电站负荷预测里有一个相关性陷阱滞后特征和目标的相关系数天然极高lag_1常常超过0.85但不代表模型只需要滞后项就够了。lag_1高相关性里面有大量“当前负荷上时刻负荷噪声”的自我强化模型只学这个会退化成naive预测遇到环境突变场景突然降温、附近修路封路就完全失效。所以特征筛选的底线是模型中必须保留至少三个非滞后特征温度相关、时间周期、站点静态属性即使它们单变量相关性不高。模型预测能力不等于相关性环境特征是“下游放大器”没有它时滞后项在正常日够用但极端天气一到就原形毕露。4. 负荷预测建模从LightGBM基线到LSTM时间序列模型的可跑路径4.1 预测目标构造单步和多步两种模式的区别数据集建成后预测目标的构造决定了模型输出结构。单步预测是最简单的用过去N个时刻的特征预测未来15分钟的负荷值模型输出一个标量。多步预测则要预测未来1小时甚至4小时每个step单独建模或者用序列生成方式。做充电站负荷预测多步是逃不掉的——充电调度策略至少要提前1小时知道负荷趋势否则没法决策是让部分车辆延迟充电还是启动储能放电。多步预测有几种常见构造方式。第一种是直接多输出输出维度设为96一天损失函数计算所有预测点的加权误差。第二种是递归多步模型预测t1然后把t1的预测值当作特征去预测t2。递归法简单但误差会逐点累积预测到第8步以后基本不可用。第三种是teacher forcing训练配合free running推理训练时用真实值做下一步输入推理时用上一步预测值适合LSTM但工程实现复杂度高。我建议第一次做的时候用直接多输出配合截断范围为未来4小时16个点的预测既保证调度有反应时间又避免了误差累积。预测范围再长时误差增速很快不如改成滚动重预测——每15分钟重新推理一次。4.2 LightGBM基线模型特征表训练与关键参数设定先用LightGBM打基线不是为了追求最好精度而是快速验证数据集的信息量是否充足。当特征工程做完后把所有特征展平成一张表每一行对应某站点某时刻标签是未来第1个15分钟的负荷值。这里注意训练集和验证集要按时间顺序切分不能用随机切分——充电站负荷有强自相关随机切分会让模型“见过”未来数据验证结果虚高到不可思议。import lightgbm as lgb from sklearn.model_selection import TimeSeriesSplit # 按时间切分不shuffle tscv TimeSeriesSplit(n_splits5) # 特征列排除标签和时间戳 feature_cols [c for c in df.columns if c not in [ts, site_id, label]] X df[feature_cols] y df[label] params { objective: regression, metric: rmse, learning_rate: 0.05, num_leaves: 63, max_depth: 7, min_child_samples: 20, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 1, verbose: -1, seed: 42 } for train_idx, val_idx in tscv.split(X): train_data lgb.Dataset(X.iloc[train_idx], y.iloc[train_idx]) val_data lgb.Dataset(X.iloc[val_idx], y.iloc[val_idx]) model lgb.train(params, train_data, num_boost_round500, valid_sets[val_data]) break # 先跑一次切分看指标参数里最有讲究的是num_leaves和min_child_samples。num_leaves63对应深度约6到7层充电站负荷数据量通常几万到几十万行这个复杂度足够拟合周期性模式又不会过度记忆噪声。min_child_samples20防止叶子节点样本太少导致预测值大起大落。feature_fraction0.8和bagging_fraction0.8是树模型的双重随机化对时序数据尤其重要——它强制每棵树只看特征和样本的一部分削弱个别极端滞后值对预测的影响。4.3 LSTM时序模型窗口化数据构造与PyTorch最小实现LightGBM验证特征有效后再上LSTM是合理的顺序。LSTM吃的是三维输入(batch_size, seq_len, feature_dim)。seq_len的选择和滞后特征的选择逻辑一致——覆盖一天周期最稳妥即96个历史点。但输入96个点意味着模型必须从头“看”一整天的完整曲线才能预测下一个点训练成本和推理延迟都高。折中方案是seq_len设48半天把一天分成上午和下午两个窗口特征里保留lag_96和lag_672来补充周期性信息。import torch import torch.nn as nn class ChargingLSTM(nn.Module): def __init__(self, feature_dim, hidden_dim64, num_layers2, output_len4): super().__init__() self.lstm nn.LSTM(feature_dim, hidden_dim, num_layers, batch_firstTrue) self.fc nn.Linear(hidden_dim, output_len) def forward(self, x): # x: (batch, seq_len, feature_dim) out, (hn, cn) self.lstm(x) last_hidden hn[-1] # 取最后一层LSTM的隐藏状态 return self.fc(last_hidden)这个网络结构做的是直接多步预测输入48个历史时间点的多维特征一次输出未来4个点的负荷值未来1小时。hn[-1]取最后一层最后时刻的隐藏状态作为整段序列的语义摘要nn.Linear再把它映射到4维输出。输出维度从1维扩到4维相当于模型同时学4个回归任务它们共享同一个上下文向量参数效率比4个独立模型高得多。训练时需要注意的是LSTM对数据尺度极度敏感。负荷值范围从0到几百千瓦如果不做标准化LSTM的梯度会被大数值特征主导训练几个epoch后loss直接nan。用sklearn.preprocessing.RobustScaler或StandardScaler按站点分别标准化——不要用全局scaler因为不同站点额定功率差异太大全局标准化会把小站点的波动压成几乎不可见的噪声。4.4 评估指标MAE、RMSE与PINC各管什么评估指标的选择必须与业务诉求绑定。MAE是绝对误差均值它的特性是“所有误差一视同仁”适合衡量整体预测精度RMSE是先平方再开方对大的预测误差惩罚更重——如果你的目标是调度储能避免电网冲击大误差意味着冲击风险RMSE比MAE更有业务意义。我一般两个都看差值趋势比单独看一个更有诊断价值RMSE/MAE比值接近1说明误差分布均匀没有太多极端误差点比值超过2说明存在少量巨大的预测偏差模型可能需要针对峰值区间做专门处理。PINCPrediction Interval Coverage Probability是区间预测指标指的是真实值落在预测区间内的比例。别只盯点预测精度——调度中心给决策层汇报时更关心“明天下午3点负荷有70%概率在400到550千瓦之间”这种区间判断单一个“预测值470千瓦”没法支撑风险评估。构建区间预测的常用方法是分位数损失模型输出三个值P10、P50、P90分别用0.1/0.5/0.9的分位数损失训练。PINC计算预测区间覆盖真实值的比例目标一般设90%——如果只有70%的覆盖率说明模型对波动估计偏乐观需要调宽区间或加入更多环境特征。5. 避坑排查数据集构建与预测落地的6个高频问题5.1 充电桩离线被当成真实低负荷现象某站点某天负荷曲线突然从150kW掉到接近零模型预测第二天同一时段时也给出极低预测值但实际上第二天负荷恢复正常预测错误率超高。原因充电桩运营平台的数据链路断连或桩离线检修导致数据缺失但接口返回的不是空值而是0聚合逻辑把0当作真实的“无车辆充电”记录参与计算。解决在聚合前先检查桩状态位。充电记录表里一般有status字段充电中/空闲/离线/故障只统计状态为“充电中”的计入负荷聚合。对历史数据中连续6个点以上全为0且当日无任何充电记录的站点标记为“数据缺失日”不参与训练或在特征中显式加一个“当日是否有数据缺失”的布尔列。5.2 气象数据粒度太粗导致预测“飘”现象用城市小时级温度预测站点负荷模型在气温骤变日精度大幅下降但用站点周围30公里内气象站数据后精度恢复。原因城市气象站位于郊区或公园与市区充电站的实际温度有时差和幅差特别是在城市热岛效应明显的夏季差值可达5度以上。模型学习到的温度-负荷映射关系在城市站温度读数上不适用。解决构建站点到最近气象站的距离矩阵按距离加权插值同时保留城市级数据作为第二个特征维度让模型自己决定信任哪个数据源。更简单的方案是给每个站点单独训练一个温度偏置校正量用历史同期对比算出。5.3 节假日模型整体翻车现象平时验证集RMSE 12kW一到国庆假期预测误差飙到50kW以上。原因节假日改变了充电行为的“相位”——同样工作日早上8点出现高峰假期早上9点才开始高速服务区站从规律性中等负荷变成全天的脉冲式高负荷。模型学到的日周期编码和滞后特征在节假日完全不适用。解决不止加节假日0/1标签要加上“距假期天数”特征比如10月1日当天特征是“假期第1天”9月30日是“假期前1天”10月7日是“假期后1天”。更极端的做法是节假日单独训练一个小模型或给样本加权牺牲假期前几天的训练数据量换取假期预测稳定性。5.4 多步预测误差随时间步长指数放大现象直接多输出模型预测未来15分钟误差10kW未来1小时误差25kW未来4小时误差直接飙到60kW。原因时间步长越远输入信息和预测目标之间的相关性越弱。表面上是模型能力不够实质是训练损失函数对所有预测步长一视同仁导致模型花大量参数去拟合步长1的细节忽略了步长16的大尺度趋势。解决损失函数改为步长加权近处步长权重大远处步长权重小但不要让权重下降太快否则远处步长完全不被学习。另一种实用策略是“分段预测”预测1小时时直接输出4个点预测4小时时先跑一次1小时模型得到中间结果再以中间结果为特征预测下一个1小时分4次滚动完成。5.5 时间序列数据切分泄漏现象模型在验证集上表现极好RMSE接近5kW上线后真实场景误差变成20kW。原因训练集和验证集存在时间重叠。做特征工程时滞后特征和滚动窗口特征是通过shift在完整数据集上计算的如果先计算特征再切分数据集验证集前面若干行的滚动统计量实际包含了训练集末尾的数据。解决先按时间切分再对训练集单独计算特征。具体做法是为训练集和验证集各留出max_lag比如672个点的“预热区”切分边界往前推672个点让验证集真正从无特征的状态开始计算滞后值。代码上确保shift操作发生在切分片段内而不是全量数据上。5.6 新站冷启动没有历史数据现象新建充电站需要预测负荷来配置变压器容量但没有历史运行数据。原因时间序列数据集高度依赖滞后特征和站点历史曲线新站这两样都没有。解决用相似站点迁移。按站点静态特征选相似站——区域类型、桩数、周围3公里内人口密度和商业设施数——计算特征相似度后加权复用相似站点的负荷曲线形状再用新站的额定功率做缩放。这个方法是近似估计但比直接按变压器容量瞎猜靠谱一个数量级。6. 验证与进阶滚动回测框架和数据版本管理是后悔药6.1 滚动回测让每一次预测都模拟真实的“当时只知当时事”固定时间切分做一次验证远远不够。充电站负荷预测部署后是持续运行的——每周五要对下周做预测模型每周在更新。我习惯搭一个滚动回测框架固定训练窗口长度比如最近12周每次往前滚1周做一次预测得到52周内的52组误差然后看误差的分布而不是只看平均值。滚动回测能告诉你模型在季节交替时是否会系统性恶化——比如4月转5月温度快速回升时模型是不是连续3周误差偏高。如果发现这个趋势说明温度特征交互项不足需要加站点与温度的cross特征。6.2 数据版本管理一份特征表对应一个版本号数据集不是一次建完就固定了。追加新的充电记录、修正气象数据源、改特征计算公式都会改变模型表现。做数据版本管理的核心是特征表存一份带版本号的快照代码和特征计算脚本也打上对应的commit标记。这样当新模型效果不如旧模型时能直接回退到旧数据集复现结果。实践上我每个版本只保存特征表和数据字典原始三张表可以重新拉取生成但如果特征表被覆盖且代码有bug你没法重建实验结果。数据字典写明每个字段的来源、单位、缺失率这个文件比模型代码重要——一年后你自己回看项目时第一个要找的是字段说明不是训练脚本。6.3 上线前最后一道检查预测曲线可视化抽查指标数字再漂亮也要做曲线可视化抽查。我会随机抽6个站点、每个站点抽2周把预测值和真实值曲线画在一张图上肉眼检查三点峰谷相位对不对预测高峰是不是比实际滞后了半小时、工作日和周末形态有没有区分、极端天气日有没有明显跳变。这一步是对模型行为做“体检”的最后一道防线。有一次我遇到过模型RMSE全达标但预测峰值被系统性削平的情况——后来发现是训练数据里峰值样本占比太少模型自动学会了“求稳”。这种事只有看曲线才能发现指标面板永远察觉不到。做这个方向做久了最大的教训是数据结构设计永远是第一位。特征工程、模型调参、指标优化都是构建在数据正确性之上的数据有洞模型再精也是白搭。从建的第一个数据集起就管好对齐、布好状态位、留好版本记录后面能省掉至少一半的返工时间。希望帮到你。本文还有配套的精品资源点击获取