Enefit - Kaggle项目

news/2025/11/25 13:44:23/文章来源:https://www.cnblogs.com/moonlight1209/p/18801789

项目简述

对能源系统中的安装了太阳能的消费者兼生产者（prosumers）消费或生产的电力进行预测以减少电力不平衡带来的损失或者说调节电力不平衡的费用。

问题描述

预测具体任务：实际是属于区域的电力预测，基本单元是county，在此基础上又对product_type，is_bussiness进行了区分，实际应用中应该更加面向电力运营商、或区域性电力交易的需求。

一个独特的segment是[county, product_type, is_bussiness, is_consumption]的组合
时间问题：
预测时间：2023-05-27 11:00:00
预测目标：2023-05-28 00:00:00 - 23:00:00的能源生成or消耗
可用其它数据(avaliable)：

client	滑窗的历史target	historical_weather	forecast_weather(2025-05-27 00:00:00生成后面两天的)	electricity_prices	gas_prices
2023-05-26 client也随着时间改变	为何只用昨天的？	2025-05-26 11:00:00~2025-05-27 10:00:00	2025-05-27 01:00:00~2025-05-29 23:00:00	每天下午两点公布	每天下午两点公布

数据集

💡thinking：机器学习项目中，拿到不熟悉领域的数据集该怎么办呢？ -> 这正是特征工程困难的地方
记录一下各个数据集的字段的含义：

train.csv

county - 县的ID代码。
is_business - 表示能源客户是否是商业客户的布尔值。
product_type - 契约类型的ID代码，包括 {0: "Combined", 1: "Fixed", 2: "General service", 3: "Spot"} 的映射。
target - 相关时段的电力消耗或产生量。时段由 county、is_business 和 product_type 定义。
is_consumption - 表示该行数据的目标是电力消耗还是产生的布尔值。
datetime - 爱沙尼亚时间（EET / EEST）。
data_block_id - 具有相同data_block_id的所有行将在同一时间进行预测。这取决于实际制定预测时可用的信息。❓
row_id - 行的唯一标识符。
prediction_unit_id - county、is_business 和 product_type 组合的唯一标识符。测试集中可能会出现或消失新的预测单位。-> 所以预测的每条数据是按这个类别作为一条的，而非一户一个预测。

gas_prices.csv:

origin_date - 前一天的天然气价格数据的日期。
forecast_date - 价格应该生效的日期。（the date when the prices should be revelant），同理，第二天才知道昨天的价格。
[lowest/highest]_price_per_mwh - 天然气在前一天的日前市场的最低/最高价格，以欧元每兆瓦时计。
data_block_id

client.csv:

product_type - 契约类型。
county - 县的ID代码。
eic_count - 能源消耗点（EICs - European Identifier Code）的汇总数量。❓
installed_capacity - 安装的光伏太阳能电池板容量，以千瓦为单位。
is_business - 表示能源客户是否是商业客户的布尔值。
date
data_block_id

electricity_prices.csv:

origin_date - 电力价格数据的日期。
forecast_date - 价格应该生效的日期。也就是说9月1号才能得到8月31日的价格。
euros_per_mwh - 前一天日前市场上电力的价格，以欧元每兆瓦时计。-> 说明这个项目的预测背景是日前市场
data_block_id

forecast_weather.csv:
每天凌晨两点生成之后一天的天气预报数据：

[latitude/longitude] - 天气预报的坐标。
origin_datetime - 天气预报生成的时间戳。（timestamp of when the forecast is made）
hours_ahead - 天气预报生成时间与预测天气之间的小时数。每个预测涵盖总共48小时。
temperature - 地面上2米高处的空气温度（摄氏度）。
dewpoint - 地面上2米高处的露点温度（摄氏度）。
cloudcover_[low/mid/high/total] - 不同高度区域（0-2公里、2-6公里、6+公里以及总体）的云层覆盖百分比。
10_metre_[u/v]_wind_component - 测量地表上方10米的风速的东向/北向分量，以米每秒计。
data_block_id
forecast_datetime - 预测天气的时间戳，即预测的是哪个时刻的时戳，由origin_datetime和hours_ahead生成。
direct_solar_radiation（DNI） - 每小时沿着与太阳方向垂直的平面上达到地表的直接太阳辐射，以瓦特时每平方米计。
surface_solar_radiation_downwards（GHI） - 达到地球表面的水平面上的太阳辐射，包括直接辐射和散射辐射，以瓦特时每平方米计。
snowfall - 过去一小时内的降雪量，以水当量米计。
total_precipitation - 过去一小时内在地球表面降落的液态降水（包括雨和雪）的累积量，以米为单位。

historical_weather.csv:

datetime - 日期时间。
temperature - 温度。
dewpoint - 露点温度。
rain - 与预测约定不同。前一小时的大尺度天气系统降雨量（毫米）。
snowfall - 与预测约定不同。前一小时的降雪量（厘米）。
surface_pressure - 地表处的大气压力（百帕）。
cloudcover_[low/mid/high/total] - 与预测约定不同。云层覆盖在不同高度区域（0-3公里、3-8公里、8+公里以及总体）的百分比。
windspeed_10m - 与预测约定不同。地面上方10米处的风速（米每秒）。
winddirection_10m - 与预测约定不同。地面上方10米处的风向（度）。
shortwave_radiation - 与预测约定不同。全球水平辐射（瓦特时每平方米）。
direct_solar_radiation - 直接太阳辐射。
diffuse_radiation - 与预测约定不同。漫射太阳辐射（瓦特时每平方米）。
[latitude/longitude] - 天气站的坐标。
data_block_id

weather_station_to_county_mapping.csv
给了对应气象站对应的经纬度和county名称，气象站数量

综上，我获得的数据集包含的信息是，地区性的不同用户类型的小时级的用电/发电信息，天然气价格信息，所有客户的信息，电价信息，网格化的历史和预测的天气信息；
❓ 为何天然气价格和电价没有区域的信息，所以默认全国一致？

竞赛思路1：

作为机器学习项目，主要使用特征工程、xgboost类似的模型来进行预测。
在code中，有选手使用了外部数据集location.csv，可以查找出county对应的经纬度坐标；❓咋找的
❓ 这些数据集如何合并使用的？
代码给出的方式是每个数据集用了不同的merge列名进行合并，最终是一个大的数据集。（所以还是需要理解每个标签的含义）

self.client_join = ['county', 'is_business', 'product_type', 'data_block_id'] # 形成唯一的数据条
self.weather_join = ['datetime', 'county', 'data_block_id'] # 历史天气需要处理时间为偏移；预报的天气不需要（使用forecast_date对齐即可） because? -> 
self.gas_join = ['data_block_id'] # gas就依据block_id对齐，because? -> block_id对应了forecast_date即可用日期，和train.csv是对应的，这里用的特征是前天预测的昨天的价格 ❓不知道预测生成的具体时间
self.electricity_join = ['datetime', 'data_block_id'] # datetime = forecast_datetime + pd.DateOffset(1) ，时间偏移后可以对齐，实际只用block_id貌似也行