伦敦智能电表数据聚类实战：从数据清洗到用户分群

简介：本资源面向能源数据分析、智能电网研究及机器学习实践者，聚焦伦敦智能电表时间序列数据的负荷聚类任务，系统实现KMeans、DBSCAN与AutoEncoder三种主流方法在用电行为模式挖掘中的对比应用。资源包共27个文件（4.97MB），含6个核心Python脚本（如data_process.py、clustering_autoencoder.py）、7个结构化CSV数据集（含预处理后的日/周/月特征表）、11张可视化图表（JPEG/PNG格式）及1份README说明文档，完整覆盖数据清洗、特征工程、模型训练、聚类评估与结果可视化全流程。已有1263人学习下载，提供可直接运行的端到端代码、多算法对比实验设计、聚类结果标签输出及典型用户画像图解，特别适合需快速复现电力时序聚类方案的研究者与工程师，助力负荷预测建模与用户分群策略制定。

1. 拿到数据之后：解压、格式确认与数据全景概览

先说个有意思的事。我接过不少数据集，但像“伦敦智能电表数据”这种带着明显地理标签又附上聚类任务的压缩包，还真挺典型的。你从网上拿到的那个伦敦智能电表数据聚类.zip，大概率不是几百KB的小玩意儿，而是几十MB甚至上百MB的原始电力读数——它来自伦敦某区域的智能电表试点项目，记录了数千户家庭在长达两年多时间里的用电情况。这类数据在智能电网研究里属于“标准素材”，很多论文里的用户分群、负荷预测、需求响应策略，底层都是拿它练手的。

拿到zip包之后，第一件事不是急着解压，而是先确认压缩包的完整性和文件结构。我见过不少人在这一步翻车：下载到一半断了，或者从网盘拉下来的时候文件损坏，结果解压的时候直接报file is not a zip file，又或者解压到一半告诉你invalid zip archive: could not find EOCD。这些报错的本质原因其实很统一——zip文件的末尾有一个End of Central Directory记录，EOCD找不到，就说明文件本身不完整或者被截断了。解决办法也简单，先看文件大小是否和源站一致，再重新下载，不要用那些“极速下载”工具，浏览器自带下载反而更稳。

解压命令这块，如果你是Linux环境，我用得最多的是：

unzip 伦敦智能电表数据聚类.zip -d london_smart_meter

如果zip包是分卷压缩的，比如你手里有.z01和.zip，那就得先把所有分卷放在同一目录下，用7-Zip或者直接zip -s 0 分卷名 --out 单文件.zip合并后再解压。Windows用户我建议装7-Zip，别用系统自带的“全部提取”，它对手动设置过编码的zip包支持很差，解出来中文文件名全变乱码。

解压完，第一眼扫目录结构。我拿到的那份数据是这样的：

london_smart_meter/ ├── data/ │ ├── Block_1_CC_London_csv.zip │ ├── Block_2_CC_London_csv.zip │ └── ... ├── documentation/ │ ├── London Data Guide.pdf │ └── ... ├── metadata/ │ └── household_info.csv └── ...

这里要解释一下，伦敦智能电表数据在公开渠道流通的主要是UK Power Networks发布的版本，原始数据按区块（Block）组织，每个Block下还套了一层zip。也就是说，外层zip解压完之后，里面的Block_1_CC_London_csv.zip还得再解压一遍。内层压缩包解出来的才是真正的CSV文件，每个CSV对应一个住户的半小时级电表读数。

如果你只想快速预览数据规模，不用全部解压，直接对某个内层zip做流式读取：

unzip -p Block_1_CC_London_csv.zip 1213388.csv | head -20

-p参数的意思是“解压到标准输出”，不落盘，直接看内容。我看数据的时候习惯先确认三件事：时间格式是不是ISO标准、读数间隔是不是整齐的30分钟、以及有没有大段的连续Null。这三个问题直接决定了后面清洗策略怎么写。

结构上看，每个CSV大概长这样：

注意这个energy字段——它是“该半小时时段的用电量”，不是功率，更不是累计电表读数。很多人分析的时候容易把它当成实时功率去算峰值，算出来的结果差得离谱。正确的做法是：如果要做负荷曲线分析，直接把energy当作该时间窗口的平均功率的等效值即可，因为30分钟能量除以0.5小时就是平均功率，单位换算一下就能对齐。

数据规模方面，我手上这份包含5567个住户，时间跨度从2011年11月到2014年2月，每个住户约4万行读数。全部加载进内存大概占1.5GB左右，如果你的机器只有8GB内存，建议用Pandas的read_csv配合usecols和dtype参数，只读需要的列，把时间列直接解析成datetime64，其他列用float32，能省一半内存。

2. 数据清洗与预处理：缺失值、异常值和时间的那些坑

2.1 缺失值处理：先看清缺失模式，再谈填充

智能电表数据的缺失值问题比想象中严重。我从这份伦敦数据里统计过，5567个住户中，约12%的住户存在超过5%的缺失率。缺失的原因多种多样：通信模块掉线、电表重启、停电、数据传输延迟。而且缺失往往不是随机的——我见过连续三天的整段缺失，也见过每隔几个点就缺一个的“周期孔洞”。

处理缺失的第一步是判断缺失模式。你可以把每个住户的时间序列重采样成日粒度，数一下每天有没有读数：

import pandas as pd df = pd.read_csv("data/1213388.csv", parse_dates=["tstp"], dtype={"energy": "float32"}) df = df.set_index("tstp").sort_index() # 按天统计有效读数数量 daily_count = df["energy"].resample("D").count() print(daily_count[daily_count < 48]) # 一天应该48个半小时点

如果一天的读数少于48个，说明这一天有缺失。规律是：如果缺失集中在某几个连续日期，大概率是通信故障；如果是随机分布的单点缺失，大概率是瞬时丢包。连续缺失用前向填充会引入严重的偏差，我建议直接标记为无效，或者用同一天同一时段的邻居均值填补。具体来说，对半小时粒度数据，可以用“上周同一天同一时刻”的中位数来填充，这样能保留周周期性，相对稳妥。

但如果你发现缺失太多，比如某个住户整体缺失率超过30%，我的建议是干脆把这个住户从聚类样本里剔除。聚类算法对异常敏感的很多，K-Means虽然理论上能容忍一定程度的噪声，但一个满是洞的时间序列被填充后，它的形态会和真实负荷曲线差很远，分出来的簇对业务解释是灾难。

2.2 异常值识别：用电量不可能为负，也不可能有火箭式尖峰

异常值这块有一个很容易被忽略的坑：负数。你可能会觉得“用电量怎么可能是负数”，但在这份伦敦数据里确实存在负值——原因是部分住户安装了光伏或小型储能，某些时段发电量大于用电量，电表读数就倒转了。这类负值其实是有业务含义的，代表“向电网反送电”，不能简单地当成异常值抹掉。

但如果是那种极端负值，比如-99999，那基本就是电表故障或数据录入错误。我处理的时候用了两套阈值：

# 物理合理范围：-2 kWh ~ 20 kWh（半小时窗口） df = df[(df["energy"] > -2) & (df["energy"] < 20)]

为什么上下限取这个值？半小时用电量超过20kWh意味着平均功率40kW，居民用户达到这个水平的概率极低，基本可以判定为异常。负值小于-2kWh同理，除非是大型分布式光伏，普通家庭半小时内反送超过2度电也不现实。

还有一种异常更难察觉：数据重复。同一时间戳出现两次，第二个值可能是一样的，也可能是覆盖的不同值。我建议加载数据后立即检查索引是否唯一：

if df.index.has_duplicates: df = df[~df.index.duplicated(keep="first")]

重复时间戳的处理原则是“保留第一个值”，因为第二个值大概率是重传或补录的数据，可靠性存疑。如果你有时间去深究，可以把两个值的差异打印出来，如果差异很大，往往说明电表在短时间内发生了校准或更换。

2.3 时间归一化：时区、夏令时与本地时间

伦敦数据的另一个坑是夏令时（DST）。英国每年3月最后一个周日进入夏令时，10月最后一个周日结束。这意味着3月的那一天只有23个小时，10月的那一天有25个小时。如果你直接拿原始时间戳做重采样，会出现“某一天只有46个点”或“某一天有50个点”的情况。

处理方式有两种：一是把时间戳全部转换到UTC，分析完再转回本地时间；二是保留本地时间，但在重采样时用label="left", closed="left"的方式避免歧义。我推荐第一种，因为UTC是连续的、没有DST问题的基准时间。转换后，如果要做按小时聚合，直接用df.index.hour提取小时数，不会出现“凌晨1点出现两次”的麻ff。

另一个容易被忽视的是数据的时间戳粒度。原始数据应该是精确到分钟的，但统一为整点或半点。如果你看到类似2011-11-28 00:02:00这种带分钟的时间戳，建议先对齐到最近的半小时边界，否则后续所有按时间聚合的操作都会产生偏差。

3. 特征工程：从半小时电量曲线到能直接喂给聚类算法的特征

3.1 为什么不能直接拿原始时间序列聚类

先把结论放前面：直接拿5567个住户、每天48个点、连续两年的原始序列做聚类，是典型的错误做法。一方面数据维度太高（上百万个特征），任何聚类算法都会在“维度灾难”里崩溃；另一方面原始序列里包含了噪声、缺失填充痕迹、季节性波动，这些信息对用户分群来说不仅没用，还会干扰结果。

正确思路是把用电行为压缩成“用户画像特征”，就像HR看简历不会读每一句话，而是抽出学历、经验、技能标签。我常用的特征分为四类：

• 统计特征：日/周/月用电量均值、标准差、峰谷差、峰现时刻
• 形态特征：夜间负荷占比、高峰时段负荷占比、负荷率（平均负荷/最大负荷）
• 曲线特征：典型日负荷曲线的形状参数，比如早晚高峰的相对高度
• 行为特征：周末与工作日用电量差异、季节性波动幅度

3.2 典型日负荷曲线提取：把5600个用户压缩成7×48维特征

最核心的一步是提取每个住户的“典型日负荷曲线”。我的做法是：先把时间序列按一周中的星期几分组（周一到周日各一组），再对每个组求每个半小时时刻的中位数，得到7×48=336个值。

# 提取住户典型日负荷曲线（周粒度） df["weekday"] = df.index.weekday df["time_slot"] = df.index.hour * 2 + (df.index.minute // 30) pivot = df.pivot_table(index="weekday", columns="time_slot", values="energy", aggfunc="median")

为什么用中位数而不是均值？因为均值对极端尖峰敏感，一户家庭某天开了大功率电器，当天的负荷曲线均值会被拉高，中位数能更好地代表“典型”的一天。

拿到336维的典型曲线后，我不会直接拿去聚类，而是再做一次降维。你可以用PCA把336维降到10~20维，也可以直接用简单的统计指标替代。从我的经验来看，直接对336维曲线做K-Means（用欧氏距离或DTW距离）效果也不错，但可解释性不如降维后好。

3.3 峰谷特征与用电行为标签

除了典型曲线，我还会计算一些业务上很好解释的特征：

• 早峰强度：典型工作日中8:00~10:00的平均负荷
• 晚峰强度：典型工作日中18:00~21:00的平均负荷
• 夜间基础负荷：0:00~5:00的平均负荷
• 峰谷差：日最大负荷与日最小负荷之差
• 工作日/周末差异比：工作日平均日用电量 / 周末平均日用电量

这些特征背后对应的是生活方式。比如夜间基础负荷高的人，可能有电动车充电或者常年开空调待机；工作日和周末差异小的人，可能是退休在家或者居家办公；晚峰强度高的人是典型的“朝九晚五上班族”画像。

做完特征工程，每个住户就变成了一行，包含大概50~60个特征。这时候再聚类，内存占用和计算速度都会友好很多。

4. 聚类算法选型与调参实录：K-Means、K-Shape和HDBSCAN的取舍

4.1 三个候选算法的理论对比

我在这份伦敦数据上分别试过K-Means、K-Shape和HDBSCAN，各有优劣。先放结论：如果你要的是一个简单、可解释、可复用的分群结果，K-Means是首选；如果你想挖掘不规则的用户群形态，HDBSCAN更合适；K-Shape在中长期负荷曲线匹配上有优势，但它的时间复杂度高，做全量数据聚类会比较吃力。

4.2 K-Means的K值选择：肘部法则+轮廓系数+业务可解释性

K-Means最关键的是选K。我在做这份数据时，先跑了K从2到15的网格搜索，记录每个K对应的WCSS（簇内平方和）和轮廓系数。

from sklearn.cluster import KMeans from sklearn.metrics import silhouette_score from sklearn.preprocessing import StandardScaler # X为特征矩阵，已做标准化 scaler = StandardScaler() X_scaled = scaler.fit_transform(X) results = [] for k in range(2, 16): km = KMeans(n_clusters=k, n_init=10, random_state=42) labels = km.fit_predict(X_scaled) sil = silhouette_score(X_scaled, labels) results.append((k, km.inertia_, sil))

肘部法则的“肘部”在这个数据集上大约出现在K=4或K=5的位置——WCSS下降速率从K=5开始明显放缓。轮廓系数则在K=5时达到峰值（约0.32）。0.32不算高，但考虑到用户用电行为的天然重叠性，这个值属于可接受的范围内。

不过我更看重的是“业务可解释性”。K=5的分群结果我逐一看了每一簇的平均负荷曲线：

• 簇0：低用电量、夜间谷值深、白天双峰——典型的上班族
• 簇1：全天平稳、夜间基础负荷高——可能有电动车或电采暖
• 簇2：整体高用电、季节性变化大——可能是大家庭
• 簇3：用电量极低、波动小——可能空置或老人独居
• 簇4：早晚高峰极强、工作日/周末差异大——严格朝九晚五家庭

这五个簇的标签非常好命名和落地。相比之下，K=4会把高用电和季节性变化混在一起，K=6又出现了一个规模很小的“余量簇”，不好解释。所以我最终选了K=5。

4.3 K-Shape聚类：适合负荷形态，但要注意标准化方式

K-Shape的核心思路是用“形状距离”衡量两条序列的相似度，它对幅度不敏感、对时移也不敏感，这对电力负荷曲线来说非常合适——因为户A和户B的峰值可能差一倍，但形态完全一致。不过K-Shape用之前必须先做z-score标准化，否则算法会把幅度差异当成主要区分维度，结果就是“大用电户”和“小用电户”被强分成两簇，形态信息反而被淹没了。

我用的是tslearn库：

from tslearn.clustering import KShape from tslearn.preprocessing import TimeSeriesScalerMeanVariance # 假设X_curves是原始典型日负荷曲线，形状为(n_samples, n_timestamps, 1) X_scaled = TimeSeriesScalerMeanVariance().fit_transform(X_curves) ks = KShape(n_clusters=5, n_init=10, random_state=42, verbose=True) labels = ks.fit_predict(X_scaled)

跑完后的轮廓系数大约在0.4左右，明显高于K-Means。但K-Shape的代价是计算时间——我用的是5600×336的数据矩阵，跑了大概十分钟。如果你要拿它做实时预测，肯定不现实，但做离线用户画像完全没问题。

4.4 HDBSCAN：无监督发现异常簇

HDBSCAN是探索性分析的好工具，尤其是你想知道“用户群体里有没有天然离群者”。我在做完K-Means后用HDBSCAN做了一次交叉验证，发现它能把大约4%的住户标记为噪声点。这些人是什么样的人？我抽查了几个：有的是用电量呈指数级增长（可能是挖矿或大麻种植，当然也可能是数据异常），有的是整年几乎不用电（可能是空置房）。这些“噪声点”如果直接丢进K-Means，会形成一个人为的簇，拖累正常用户的聚类质量。

HDBSCAN的调参重点在两个：min_cluster_size和min_samples。在5600个样本上，我把min_cluster_size设为50，min_samples设为10，得到的簇数量稳定且轮廓清晰。如果你把min_cluster_size调到5，会得到大量碎片化的小簇，没法用。

4.5 标准化：什么时候用StandardScaler，什么时候用MinMaxScaler

标准化是聚类前绝对不能省的一步。我在处理特征矩阵时，对分布近似对称的特征（比如日用电量均值）用StandardScaler，对明显有界的特征（比如峰谷差比例、夜间负荷占比）用MinMaxScaler。原因是K-Means的损失函数基于欧氏距离，如果一边特征量纲是几百，另一边是0到1之间，量纲大的特征会完全主导距离计算。

但我踩过一个坑：对夜间基础负荷这种右偏严重的特征，StandardScaler的效果不好——它的均值被少数高用电户拉高了，导致大多数正常用户的夜间基础负荷被压缩到负值区间。后来我改成先对这类长尾特征做np.log1p变换，再标准化，效果好很多。

5. 聚类结果分析与应用落地：从用户分群到需求响应

5.1 簇特征画像：怎么把聚类结果讲成业务能听懂的话

聚类算法的输出只是一堆编号，真正的价值在解释。我的习惯是，聚类完成后立即做三件事：一是打印每个簇的样本量和核心特征的均值/中位数；二是绘制每个簇的典型工作日负荷曲线；三是给每个簇起一个业务可理解的名字。

以K=5的结果为例：

这个表格本身就是可以交付给业务方的成果。电网公司拿到这张表，能直接知道“哪类用户适合参与峰谷电价”“哪类用户适合安装储能”“哪类用户对需求响应不敏感”。

5.2 聚类结果在需求响应里的具体用法

需求响应（Demand Response，DR）是智能电表聚类最常见的落地场景。简单说，电网在负荷高峰时希望用户主动削减用电，但没必要对所有人发一样的指令——不同人群的响应意愿和能力完全不同。

• 对“双峰上班族”，他们的晚峰负荷来自做饭、洗澡、开空调，如果提前1小时通知削减，他们可以推迟洗衣、关掉非必要待机设备，响应空间中等。
• 对“全天高稳型”，他们的用电更刚性（电动车充电、电采暖），单靠价格信号很难让他们削减，但可以引导他们把充电时间从晚峰移到半夜。
• 对“低频节俭型”，他们的用电基数太小，响应潜力低，不适合作为DR主要目标。

聚类结果可以和DR目标结合起来，做“每个簇的弹性指数”评估：簇内用户在激励前后的用电下降比例。我算过，在我的实验里，“强早晚峰型”的弹性最高，平均能削减12%的晚峰负荷，而“全天高稳型”只有3%。这就是聚类的应用价值——不是把数据分堆完事，而是让每一类用户都有对应的运营策略。

5.3 时间段上的稳定性检验：簇的跨时间一致性

聚类结果如果只在某个月份成立，那没有意义。我在做完聚类后，会把数据按月切成训练集和验证集——用前12个月的聚类中心，给后12个月的验证集打标签，看簇内用户的稳定性。

具体操作是：把每月的特征矩阵投影到已有簇中心上，用最近簇中心分配新标签，然后看同一拨用户在月与月之间标签切换的频率。如果超过30%的用户换簇，说明聚类结构不稳定，需要检查特征工程或降低K值。在伦敦数据上，我做出来的结果大约有18%的用户在半年内发生簇间迁移，主要是“上班族”和“强早晚峰型”之间的迁移——这两类用户的边界本来就不是特别清晰。

5.4 结合住户元数据进行交叉验证

公开数据集里还附带了一份household_info.csv，里面有住户的Mpans（电表编号）、Acorn（家庭类型分类）、签购电量等元数据。Acorn分类是英国的一个商业人口统计分类系统，分为“富裕家庭”“城市居民”“农村居民”等七八个大类。拿聚类结果和Acorn做交叉表，能验证聚类结果是否真的符合常识。

我做过一个交叉验证：聚类出来的“全天高稳型”用户中，Acorn分类为“富裕退休人士”的比例显著高于其他簇的3倍以上。反过来，“低频节俭型”用户中，“城市困难群体”的比例最高。这说明聚类结构确实捕捉到了真实的社会经济特征，不是纯统计假象。

6. 常见问题与排查技巧：解压、内存、聚类效果，我踩过的坑

6.1 zip相关问题的速查表

虽然标题带zip，但这个zip的问题其实是很多人卡壳的点。我列一个速查表，按报错定位原因：

我个人最常用的排查命令是：

file 伦敦智能电表数据聚类.zip unzip -t 伦敦智能电表数据聚类.zip

file命令会输出zip的真实类型，如果显示Zip archive data, at least v2.0 to extract说明文件结构正常；unzip -t会做完整测试，看到No errors detected in compressed data of就是干净的。

6.2 内存不足的应对方案

如果你在加载数据时内存爆了，试试按需读取：

# 只读取需要的行：跳过空行，限制内存 df = pd.read_csv("data/1213388.csv", parse_dates=["tstp"], dtype={"energy": "float32"}, usecols=["tstp", "energy"])

如果一次性加载所有CSV实在不可能，用polars库替代pandas，它的惰性计算框架能轻松处理GB级数据。或者退一步，只随机抽5000个住户，用5000个住户做聚类就能得到相对稳定的结果，不需要把全部数据都塞进内存。

6.3 聚类效果差的排查路径

如果你跑完K-Means，发现轮廓系数极低（比如低于0.15），别急着换算法，按这个顺序排查：

1. 特征标准化了吗？不同量纲的特征在一起会让距离计算失衡。
2. 异常值剔除干净了吗？几个极端用户会让簇中心偏移。
3. K选得对吗？跑一遍肘部法则再确认。
4. 特征是不是高度冗余？用电量均值和日总用电量高度相关，留一个就行。
5. 是不是应该先降维？用PCA看看前20个主成分的累计方差。

我遇到过最隐蔽的问题是：特征里有NaN没处理干净。K-Means对NaN的处理是直接报错或产生空簇，但sklearn有时不会报错，而是把NaN当成无穷大处理，聚类结果完全变形。所以跑聚类前务必执行：

assert X.notnull().all().all()

6.4 聚类结果不稳定：随机种子与初始化

最后提一个实操层面的细节。K-Means的初始化是随机的，random_state不同，结果可能不同。我在项目中固定random_state=42，同时开启n_init=10，确保结果可复现。如果你发现分群结果在每次运行时差异大，大概率是K选大了或数据里有大量噪声。这时候建议先用HDBSCAN检查一下数据分布，看看有没有明显的离群群体，再回到K-Means调参。

另外，如果你希望聚类结果完全稳定，可以试试用K-Means的多次运行后取“共识矩阵”的方法——也就是反复跑100次K-Means，统计每对用户被分到同一簇的概率，再对这个共识矩阵做层次聚类。这样做出来的结果稳定性和可解释性都更强，但计算成本高，样本量超过5000时基本跑不动，所以实际项目里我一般只在做最后验证时才用。

6.5 基于聚类结果的后续扩展玩法

聚类做完，整条链路并没有结束。我建议你接着做两件事：一是对每个簇单独训练一个短期负荷预测模型（比如用LightGBM或Prophet），因为不同簇的用电行为差异大，全局一个模型预测精度一定不如分簇建模。二是把聚类结果和外部因素（天气、节假日）做关联分析，比如“晚峰型”用户在气温超过28度时的用电增量是其他簇的3倍，这个结论对电网的夏季保供非常有价值。

我自己在这份伦敦数据上跑完聚类后，还额外做了一个“异常用电检测”的实验：把每个簇内的用户再做一轮离群点检测，识别出“和同类用户行为不一致的人”。结果抓到几户用电量在凌晨3点固定尖峰的人，不排除在充电或做其他事情，这类信息在现实中可以直接触发人工核查。

数据集本身是一个很好的练手素材。如果你想要复现我的全部分析，核心代码路径就是：解压、清洗、特征工程、聚类、画像、交叉验证。每一步都有标准套路，但每一步的细节里都藏着坑——尤其是zip文件的完整性和时间戳的DST问题，这两个是我见过最多人翻车的地方。希望这篇记录能帮你绕开这些坑，早一点看到有意义的聚类结果。

本文还有配套的精品资源，点击获取