简介本资源为星星充电充电桩数据示例包面向充电桩运营分析、数据可视化及新能源行业研究的学习者可用于站点信息整理、区域分布统计等练习场景。包内共18个文件以16个json数据文件为主涵盖站点列表及黄石多个充电站的独立数据另附1个xls表格用于汇总查看以及1个作者联系方式文件压缩包整体约31KB体积轻便便于快速导入解析。目前已有1336人学习下载具备一定参考热度。通过这批样例数据读者可了解充电站数据的字段结构与组织方式用于练习json解析、表格转换、地图标注或运营指标统计也可作为接口调试与数据清洗的测试素材帮助快速搭建充电桩数据分析原型。1. 拿到「星星充电数据demo.7z」先别急着解压它到底能解决什么问题充电桩运营方、做充电聚合平台的后端、以及给车企做车联网数据中台的团队大概率都遇到过同一个尴尬手上有一堆桩的订单流水但字段命名各说各话时间戳时区混乱枪口状态和订单状态对不上想做个像样的充电行为分析或者计费对账光清洗就要耗掉两周。这时候如果拿到一个叫「星星充电数据demo.7z」的压缩包第一反应往往是「里面是不是有现成的样例数据能直接喂进我的 pipeline」。它本质上是一份围绕充电订单、设备状态、计费明细的脱敏样例数据集价值不在于数据量而在于它把真实运营里那套字段结构、状态机流转和异常分布压缩成了一个小体积样本让你能在本地把「解析—入库—指标计算—可视化」这条链路先跑通再去对接真实生产库。适合谁正在做充电 SaaS、需要快速验证数据模型的后端做 ECharts 数据可视化大屏、缺真实字段的前端以及拿它当课程设计或大数据作业素材的学生。不适合谁指望靠它直接训练模型的人demo 数据的量级撑不起训练它更像一把尺子量的是你的处理流程对不对。2. 拆开压缩包之前充电数据 demo 的字段结构和选型逻辑2.1 一份充电订单数据通常长什么样在动手解压前先把「充电数据」这件事的骨架想清楚否则拿到文件只会看到一堆列名发懵。一个完整的充电订单从业务上至少横跨四张逻辑表订单主表、充电过程采样表、计费明细表、设备状态表。订单主表记录一次充电的生命周期核心字段包括订单号、桩编号、枪口号、用户标识脱敏后通常是哈希串、开始时间、结束时间、起止 SOC、充电电量、订单金额、支付状态。充电过程采样表是按固定间隔常见 30 秒或 1 分钟打的点字段是订单号、采样时间、电压、电流、功率、SOC。计费明细表把一次充电拆成电费和服务费可能还分尖峰平谷时段。设备状态表则是桩维度的在线离线、故障码、枪口占用状态。为什么强调这个结构因为 demo 压缩包里的文件命名和分表方式基本会遵循这套逻辑。你解压后如果看到类似order_*.csv、charge_sample_*.csv、fee_detail_*.csv这样的命名就能对上号。常见做法是每个文件对应一张逻辑表用订单号做外键关联。这里有个容易翻车的点很多 demo 数据为了压缩体积会把采样表做成「一个订单一行、过程数据塞进 JSON 字符串」的形式这时候你就不能直接当宽表读得先解析 JSON 再展开。所以第一步不是写代码是先用文本编辑器或者命令行看一眼文件头。# 先看压缩包里有什么不要直接全解压 7z l 星星充电数据demo.7z # 只看前几行判断分隔符和编码 7z e -so 星星充电数据demo.7z order_202401.csv | head -n 5 # 如果中文乱码多半是 GBK转一下再看 7z e -so 星星充电数据demo.7z order_202401.csv | iconv -f GBK -t UTF-8 | head -n 5上面三条命令的逻辑是7z l只列目录不解压避免污染工作区7z e -so把指定文件输出到标准输出配合head只看头部判断第一行是不是表头、分隔符是逗号还是制表符iconv处理中文编码国内不少运营系统导出的 CSV 默认 GBK直接当 UTF-8 读会得到乱码列名。参数上-so是关键它让 7z 把内容吐到 stdout 而不是落盘适合快速侦察。如果你机器上没装 7z用unzip -l和unzip -p也能达到类似效果只是 7z 对多卷和加密包支持更好。2.2 为什么选 pandas SQLite 而不是直接上大数据栈拿到 demo 数据后一个高频争论是「要不要直接上 Spark 或者 Flink」。我的血泪经验是demo 阶段千万别。demo 数据的量级通常在几万到几十万行用 pandas 单机跑从读到算到出图几分钟内能迭代一轮上 Spark 光是环境、依赖、序列化开销就够你调半天而且你根本用不到分布式。选型逻辑很简单——数据量决定工具不是工具决定架构。SQLite 作为落地存储也够用单文件、零配置、SQL 语法完整做完分析把.db文件一删工作区干干净净。真正需要提前想清楚的是「字段类型映射」。CSV 读进来默认全是 object时间列是字符串金额列可能混着货币符号SOC 可能是85%这种带百分号的字符串。如果你不显式转换后面做时间序列聚合或者金额求和时就会报错或者算出离谱结果。常见做法是在读取阶段就用dtype和parse_dates参数把类型定死读进来就是对的省得后面到处astype。import pandas as pd import sqlite3 # 读取订单主表显式指定类型避免后续反复转换 orders pd.read_csv( order_202401.csv, encodinggbk, # 国内系统导出常见编码 parse_dates[start_time, end_time], # 直接解析为 datetime dtype{ order_id: string, pile_id: string, gun_id: int8, energy_kwh: float32, amount: float32, pay_status: category, # 枚举值用 category 省内存 }, ) # 采样表可能很大分块读只保留需要的列 sample_iter pd.read_csv( charge_sample_202401.csv, encodinggbk, parse_dates[sample_time], usecols[order_id, sample_time, power_kw, soc], chunksize100_000, ) conn sqlite3.connect(charging_demo.db) orders.to_sql(orders, conn, if_existsreplace, indexFalse) for chunk in sample_iter: chunk.to_sql(samples, conn, if_existsappend, indexFalse) conn.close()这段代码的关键点有三个。第一parse_dates让 pandas 在读取时就把时间列转成 datetime比读完再pd.to_datetime快也避免中间态出错。第二dtype里把pay_status设成category因为支付状态就那么几种取值category 类型在内存占用上比 object 小一个数量级几十万行数据下差别很明显。第三采样表用chunksize分块读配合to_sql的append模式逐块入库避免一次性把大文件读进内存导致 OOM。参数上chunksize设 10 万是个经验值太小了 IO 次数多太大了内存压力大具体看你机器内存和单行宽度。if_exists第一张表用replace建表后续用append追加这个顺序不能反否则每次追加都会把前面的数据冲掉。3. 从原始 CSV 到可用指标充电订单清洗与聚合的完整链路3.1 时间戳、时区和跨天订单这三个坑必须先填充电数据里最容易出玄学的地方就是时间。你可能会发现同一笔订单开始时间比结束时间还晚或者电量算出来是负数。先别怀疑数据造假八成是时区或者跨天处理的问题。国内运营系统常见两种时间存储一种是本地时间东八区直接存字符串另一种是 UTC 时间戳。如果 demo 数据里混了这两种聚合时就会错位。判断方法很简单看时间列的数值范围如果小时数集中在 0 到 8 之间很可能是 UTC如果集中在 8 到 22多半是本地时间。跨天订单是另一个坑。一笔从晚上 11 点充到次日凌晨 1 点的订单如果按「日期」分组统计日充电量它会被拆到两天里但业务上这往往算作一笔完整订单。处理方式取决于你的分析目标做日粒度报表就按开始时间归属做时段分析就按采样点实际时间归属。没有绝对对错但必须在代码里显式声明不能含糊。# 统一时区假设原始是 UTC转成东八区 orders[start_time] orders[start_time].dt.tz_localize(UTC).dt.tz_convert(Asia/Shanghai) orders[end_time] orders[end_time].dt.tz_localize(UTC).dt.tz_convert(Asia/Shanghai) # 过滤异常订单结束早于开始、电量为负、时长为零 mask_valid ( (orders[end_time] orders[start_time]) (orders[energy_kwh] 0) ((orders[end_time] - orders[start_time]).dt.total_seconds() 60) ) clean_orders orders[mask_valid].copy() # 计算充电时长分钟和平均功率 clean_orders[duration_min] ( clean_orders[end_time] - clean_orders[start_time] ).dt.total_seconds() / 60 clean_orders[avg_power_kw] clean_orders[energy_kwh] / (clean_orders[duration_min] / 60) print(f原始 {len(orders)} 条清洗后 {len(clean_orders)} 条剔除 {len(orders)-len(clean_orders)} 条)逻辑说明tz_localize是给「无时区信息」的时间打上 UTC 标签tz_convert再转到目标时区这两步顺序不能反反了会报错或者得到错误偏移。过滤条件里时长大于 60 秒是为了排除那些「插枪即拔」的无效订单这类订单在真实数据里占比不低不剔除会拉低平均功率。avg_power_kw用总电量除以小时数注意单位换算duration_min / 60才是小时。参数上60 秒这个阈值可以按业务调整快充场景可以放宽到 30 秒慢充场景可以提到 5 分钟。跑完打印剔除数量是为了让你对数据质量有个量化感知如果剔除比例超过 20%说明原始数据问题严重得回头查采集环节。3.2 用 SQL 做时段聚合和桩利用率排名数据清洗完落到 SQLite 后真正的分析才刚开始。充电运营最关心的两个指标是「分时段充电量」和「桩利用率」。分时段看的是电网负荷和定价策略桩利用率看的是资产回报。这两个指标用 SQL 做比 pandas 更直观也更容易复用到生产环境。-- 分时段充电量按小时聚合看一天里的充电高峰 SELECT strftime(%H, start_time) AS hour_of_day, COUNT(*) AS order_cnt, ROUND(SUM(energy_kwh), 2) AS total_kwh, ROUND(AVG(avg_power_kw), 2) AS avg_power FROM clean_orders GROUP BY hour_of_day ORDER BY hour_of_day; -- 桩利用率排名按桩统计订单数和总电量取前 10 SELECT pile_id, COUNT(*) AS order_cnt, ROUND(SUM(energy_kwh), 2) AS total_kwh, ROUND(SUM(duration_min) / 60.0, 2) AS busy_hours FROM clean_orders GROUP BY pile_id ORDER BY total_kwh DESC LIMIT 10;第一条 SQL 的strftime(%H, start_time)把时间截到小时注意 SQLite 的 strftime 对带时区的字符串处理有限如果前面存进去的是带08:00的 ISO 字符串最好在入库前就转成纯本地时间字符串。第二条 SQL 里busy_hours是累计充电时长用它除以统计周期总小时数就是利用率但 demo 数据往往只覆盖几天所以这里先看绝对值排名。参数上LIMIT 10按需调整做全量排名就去掉。如果你发现某个桩的total_kwh高得离谱先别高兴很可能是这个桩的订单里混了测试数据或者重复记录回头用订单号去重验证一下。提示SQLite 没有原生的时区函数所有时间运算都基于字符串。如果你在 pandas 里已经转成了带时区的 datetimeto_sql存进去会变成带偏移的字符串后续 SQL 聚合前最好先统一转成YYYY-MM-DD HH:MM:SS格式的本地时间字符串。4. 避坑与排查充电 demo 数据处理里最容易翻车的五件事4.1 解压后中文列名乱码读进来全是问号现象用 pandas 读 CSV列名显示为\xe8\xae\xa2\xe5\x8d\x95\xe5\x8f\xb7这种字节串或者直接是乱码方块。原因文件是 GBK 或 GB18030 编码而 pandas 默认按 UTF-8 读。解决读取时显式指定encodinggbk如果还不行就试gb18030它兼容性更广。如果只有个别列乱码可能是导出时混合了编码那就先用iconv整文件转码再读。4.2 订单号和采样表关联不上JOIN 出来是空现象订单主表有 5 万条采样表有 200 万条但按订单号 JOIN 后只剩几千条。原因两边订单号的格式不一致比如一边是纯数字一边带了前缀或者前后有空格。解决JOIN 前先做标准化strip()去空格统一大小写去掉非数字字符。用SELECT DISTINCT对比两边的样本肉眼确认差异模式。4.3 金额字段带货币符号求和直接报错现象amount列里混着¥12.50、12.5元、12.50三种格式SUM出来是 0 或者报类型错误。原因导出时没有做数值格式化。解决用正则提取数字部分再转 floatdf[amount].str.replace(r[^\d.], , regexTrue).astype(float)。注意这个操作会丢掉负号如果有退款订单正则要保留-。4.4 采样表时间间隔不均匀直接算功率偏差大现象按采样点算平均功率和订单主表里的总电量对不上。原因采样间隔不固定有的 30 秒有的 2 分钟简单平均会失真。解决用时间加权先算相邻采样点的时间差作为权重再对功率做加权平均。或者直接用订单总电量除以总时长以主表为准采样表只用来画曲线。4.5 去重去掉了正常数据订单量骤降现象按订单号drop_duplicates后数据量少了一半。原因一笔订单在采样表里本来就有多行你误对采样表去重了或者订单主表里同一订单号确实有多次状态更新记录。解决先确认去重的粒度订单主表按订单号去重采样表按「订单号采样时间」去重。去重前用duplicated()看看重复的是哪些列别一刀切。5. 把 demo 数据变成可复用的验证集三个进阶技巧5.1 用采样数据反推桩的功率曲线验证设备健康度demo 数据里最有价值的其实不是订单汇总而是采样表里的功率序列。一个健康的直流桩功率曲线应该是先爬升到额定功率维持一段平台期然后随 SOC 升高逐渐下降。如果你发现某个桩的功率曲线频繁出现断崖式下跌或者长时间停在低功率那可能是模块故障或者枪口接触不良。做法是把采样表按订单号分组取功率列用滑动窗口算方差方差超过阈值的订单标记为异常。# 按订单分组计算功率序列的波动指标 def power_stability(group): p group[power_kw].values if len(p) 5: return None return { order_id: group.name, max_power: p.max(), std_power: p.std(), drop_count: int((pd.Series(p).diff() -10).sum()), # 功率骤降次数 } stability samples.groupby(order_id).apply(power_stability).dropna() # 骤降超过 3 次的订单大概率设备有问题 suspicious stability[stability[drop_count] 3] print(suspicious.head(10))这段代码的逻辑是对每个订单的功率序列统计最大值、标准差和「单步下降超过 10kW」的次数。diff()算相邻差值小于 -10 说明功率在短时间内掉了 10kW 以上正常充电过程不该频繁出现。参数上10kW 这个阈值适合 60kW 以上的直流桩交流慢充要调小到 1-2kW。len(p) 5是过滤采样点太少的订单样本不足算出来的统计量没意义。跑完看suspicious的数量如果占比超过 5%说明这批 demo 数据里的设备状态分布可能偏真实故障场景正好拿来测试你的告警规则。5.2 构造「脏数据」子集做数据质量回归测试demo 数据的一个隐藏用法是当测试夹具。你把清洗逻辑写好后可以人为往干净数据里注入几类典型脏数据——空值、重复行、时间倒挂、金额异常——然后跑你的清洗 pipeline看能不能全部识别并处理。这比等生产环境出问题再修要主动得多。具体做法是写一个inject_dirty函数按比例随机污染记录污染位置再验证清洗后这些位置是否被正确修复或剔除。脏数据类型注入方式预期处理结果空值随机将 5% 的 energy_kwh 置空被过滤或填充为 0重复行随机复制 3% 的行按订单号去重后消失时间倒挂交换 2% 订单的起止时间被有效性过滤剔除金额异常将 1% 的 amount 乘以 100被 3σ 或 IQR 规则标记这张表可以直接当测试用例清单用。每注入一类跑一次清洗对比输出行数和标记数量就能量化你的清洗逻辑覆盖率。注意注入比例别太高超过 10% 会让数据面目全非失去参考价值。5.3 用 ECharts 把聚合结果快速可视化验证指标合理性数字对不对比看曲线更直观。把前面 SQL 算出的分时段充电量导成 JSON丢给 ECharts 画个柱状图你一眼就能看出高峰时段是否符合常识——比如早高峰和晚高峰两个峰凌晨低谷。如果曲线是平的或者出现多个莫名其妙的尖峰说明聚合逻辑有问题。这一步不需要写前端工程一个 HTML 文件加 CDN 引入 ECharts 就够。// 假设后端返回的数据格式[{hour: 08, kwh: 1234.5}, ...] fetch(/api/hourly_energy) .then((res) res.json()) .then((data) { const chart echarts.init(document.getElementById(chart)); chart.setOption({ xAxis: { type: category, data: data.map((d) d.hour :00) }, yAxis: { type: value, name: 充电量(kWh) }, series: [{ type: bar, data: data.map((d) d.kwh), itemStyle: { color: #3b82f6 }, }], tooltip: { trigger: axis }, }); });这段 JS 的关键是数据映射x 轴用小时字符串y 轴用电量数值tooltip开启轴触发方便悬停看具体值。实际用时把fetch的地址换成你的接口或者直接内联 JSON 数据。颜色和样式按需调重点是先看到形状。我一般会把这个页面留着每次改完清洗逻辑就刷新看一眼曲线形状不对就回去查 SQL比盯着数字快得多。5.4 一个我踩过的坑别把 demo 当生产数据用最后说个教训。有次我拿一份类似的充电 demo 数据调好了整套指标信心满满接生产库结果第一天就翻车——生产数据里订单量是 demo 的几千倍我那个用 pandas 全量加载再 groupby 的脚本直接把内存打爆。后来改成先按时间分区逐天读、逐天算、结果追加写入才稳住。demo 数据能帮你验证逻辑对不对但验证不了性能边界。所以我的习惯是demo 阶段就把「分块处理」和「增量计算」的架子搭好哪怕数据量小到用不上等接生产时改的只是参数不是架构。这个方案值不值得做如果你手头正好有充电数据要处理花半天把 demo 跑通比直接上生产库试错成本低得多。希望帮到你。本文还有配套的精品资源点击获取 星星充电数据demo实战：从CSV解析到充电订单清洗与聚合
简介本资源为星星充电充电桩数据示例包面向充电桩运营分析、数据可视化及新能源行业研究的学习者可用于站点信息整理、区域分布统计等练习场景。包内共18个文件以16个json数据文件为主涵盖站点列表及黄石多个充电站的独立数据另附1个xls表格用于汇总查看以及1个作者联系方式文件压缩包整体约31KB体积轻便便于快速导入解析。目前已有1336人学习下载具备一定参考热度。通过这批样例数据读者可了解充电站数据的字段结构与组织方式用于练习json解析、表格转换、地图标注或运营指标统计也可作为接口调试与数据清洗的测试素材帮助快速搭建充电桩数据分析原型。1. 拿到「星星充电数据demo.7z」先别急着解压它到底能解决什么问题充电桩运营方、做充电聚合平台的后端、以及给车企做车联网数据中台的团队大概率都遇到过同一个尴尬手上有一堆桩的订单流水但字段命名各说各话时间戳时区混乱枪口状态和订单状态对不上想做个像样的充电行为分析或者计费对账光清洗就要耗掉两周。这时候如果拿到一个叫「星星充电数据demo.7z」的压缩包第一反应往往是「里面是不是有现成的样例数据能直接喂进我的 pipeline」。它本质上是一份围绕充电订单、设备状态、计费明细的脱敏样例数据集价值不在于数据量而在于它把真实运营里那套字段结构、状态机流转和异常分布压缩成了一个小体积样本让你能在本地把「解析—入库—指标计算—可视化」这条链路先跑通再去对接真实生产库。适合谁正在做充电 SaaS、需要快速验证数据模型的后端做 ECharts 数据可视化大屏、缺真实字段的前端以及拿它当课程设计或大数据作业素材的学生。不适合谁指望靠它直接训练模型的人demo 数据的量级撑不起训练它更像一把尺子量的是你的处理流程对不对。2. 拆开压缩包之前充电数据 demo 的字段结构和选型逻辑2.1 一份充电订单数据通常长什么样在动手解压前先把「充电数据」这件事的骨架想清楚否则拿到文件只会看到一堆列名发懵。一个完整的充电订单从业务上至少横跨四张逻辑表订单主表、充电过程采样表、计费明细表、设备状态表。订单主表记录一次充电的生命周期核心字段包括订单号、桩编号、枪口号、用户标识脱敏后通常是哈希串、开始时间、结束时间、起止 SOC、充电电量、订单金额、支付状态。充电过程采样表是按固定间隔常见 30 秒或 1 分钟打的点字段是订单号、采样时间、电压、电流、功率、SOC。计费明细表把一次充电拆成电费和服务费可能还分尖峰平谷时段。设备状态表则是桩维度的在线离线、故障码、枪口占用状态。为什么强调这个结构因为 demo 压缩包里的文件命名和分表方式基本会遵循这套逻辑。你解压后如果看到类似order_*.csv、charge_sample_*.csv、fee_detail_*.csv这样的命名就能对上号。常见做法是每个文件对应一张逻辑表用订单号做外键关联。这里有个容易翻车的点很多 demo 数据为了压缩体积会把采样表做成「一个订单一行、过程数据塞进 JSON 字符串」的形式这时候你就不能直接当宽表读得先解析 JSON 再展开。所以第一步不是写代码是先用文本编辑器或者命令行看一眼文件头。# 先看压缩包里有什么不要直接全解压 7z l 星星充电数据demo.7z # 只看前几行判断分隔符和编码 7z e -so 星星充电数据demo.7z order_202401.csv | head -n 5 # 如果中文乱码多半是 GBK转一下再看 7z e -so 星星充电数据demo.7z order_202401.csv | iconv -f GBK -t UTF-8 | head -n 5上面三条命令的逻辑是7z l只列目录不解压避免污染工作区7z e -so把指定文件输出到标准输出配合head只看头部判断第一行是不是表头、分隔符是逗号还是制表符iconv处理中文编码国内不少运营系统导出的 CSV 默认 GBK直接当 UTF-8 读会得到乱码列名。参数上-so是关键它让 7z 把内容吐到 stdout 而不是落盘适合快速侦察。如果你机器上没装 7z用unzip -l和unzip -p也能达到类似效果只是 7z 对多卷和加密包支持更好。2.2 为什么选 pandas SQLite 而不是直接上大数据栈拿到 demo 数据后一个高频争论是「要不要直接上 Spark 或者 Flink」。我的血泪经验是demo 阶段千万别。demo 数据的量级通常在几万到几十万行用 pandas 单机跑从读到算到出图几分钟内能迭代一轮上 Spark 光是环境、依赖、序列化开销就够你调半天而且你根本用不到分布式。选型逻辑很简单——数据量决定工具不是工具决定架构。SQLite 作为落地存储也够用单文件、零配置、SQL 语法完整做完分析把.db文件一删工作区干干净净。真正需要提前想清楚的是「字段类型映射」。CSV 读进来默认全是 object时间列是字符串金额列可能混着货币符号SOC 可能是85%这种带百分号的字符串。如果你不显式转换后面做时间序列聚合或者金额求和时就会报错或者算出离谱结果。常见做法是在读取阶段就用dtype和parse_dates参数把类型定死读进来就是对的省得后面到处astype。import pandas as pd import sqlite3 # 读取订单主表显式指定类型避免后续反复转换 orders pd.read_csv( order_202401.csv, encodinggbk, # 国内系统导出常见编码 parse_dates[start_time, end_time], # 直接解析为 datetime dtype{ order_id: string, pile_id: string, gun_id: int8, energy_kwh: float32, amount: float32, pay_status: category, # 枚举值用 category 省内存 }, ) # 采样表可能很大分块读只保留需要的列 sample_iter pd.read_csv( charge_sample_202401.csv, encodinggbk, parse_dates[sample_time], usecols[order_id, sample_time, power_kw, soc], chunksize100_000, ) conn sqlite3.connect(charging_demo.db) orders.to_sql(orders, conn, if_existsreplace, indexFalse) for chunk in sample_iter: chunk.to_sql(samples, conn, if_existsappend, indexFalse) conn.close()这段代码的关键点有三个。第一parse_dates让 pandas 在读取时就把时间列转成 datetime比读完再pd.to_datetime快也避免中间态出错。第二dtype里把pay_status设成category因为支付状态就那么几种取值category 类型在内存占用上比 object 小一个数量级几十万行数据下差别很明显。第三采样表用chunksize分块读配合to_sql的append模式逐块入库避免一次性把大文件读进内存导致 OOM。参数上chunksize设 10 万是个经验值太小了 IO 次数多太大了内存压力大具体看你机器内存和单行宽度。if_exists第一张表用replace建表后续用append追加这个顺序不能反否则每次追加都会把前面的数据冲掉。3. 从原始 CSV 到可用指标充电订单清洗与聚合的完整链路3.1 时间戳、时区和跨天订单这三个坑必须先填充电数据里最容易出玄学的地方就是时间。你可能会发现同一笔订单开始时间比结束时间还晚或者电量算出来是负数。先别怀疑数据造假八成是时区或者跨天处理的问题。国内运营系统常见两种时间存储一种是本地时间东八区直接存字符串另一种是 UTC 时间戳。如果 demo 数据里混了这两种聚合时就会错位。判断方法很简单看时间列的数值范围如果小时数集中在 0 到 8 之间很可能是 UTC如果集中在 8 到 22多半是本地时间。跨天订单是另一个坑。一笔从晚上 11 点充到次日凌晨 1 点的订单如果按「日期」分组统计日充电量它会被拆到两天里但业务上这往往算作一笔完整订单。处理方式取决于你的分析目标做日粒度报表就按开始时间归属做时段分析就按采样点实际时间归属。没有绝对对错但必须在代码里显式声明不能含糊。# 统一时区假设原始是 UTC转成东八区 orders[start_time] orders[start_time].dt.tz_localize(UTC).dt.tz_convert(Asia/Shanghai) orders[end_time] orders[end_time].dt.tz_localize(UTC).dt.tz_convert(Asia/Shanghai) # 过滤异常订单结束早于开始、电量为负、时长为零 mask_valid ( (orders[end_time] orders[start_time]) (orders[energy_kwh] 0) ((orders[end_time] - orders[start_time]).dt.total_seconds() 60) ) clean_orders orders[mask_valid].copy() # 计算充电时长分钟和平均功率 clean_orders[duration_min] ( clean_orders[end_time] - clean_orders[start_time] ).dt.total_seconds() / 60 clean_orders[avg_power_kw] clean_orders[energy_kwh] / (clean_orders[duration_min] / 60) print(f原始 {len(orders)} 条清洗后 {len(clean_orders)} 条剔除 {len(orders)-len(clean_orders)} 条)逻辑说明tz_localize是给「无时区信息」的时间打上 UTC 标签tz_convert再转到目标时区这两步顺序不能反反了会报错或者得到错误偏移。过滤条件里时长大于 60 秒是为了排除那些「插枪即拔」的无效订单这类订单在真实数据里占比不低不剔除会拉低平均功率。avg_power_kw用总电量除以小时数注意单位换算duration_min / 60才是小时。参数上60 秒这个阈值可以按业务调整快充场景可以放宽到 30 秒慢充场景可以提到 5 分钟。跑完打印剔除数量是为了让你对数据质量有个量化感知如果剔除比例超过 20%说明原始数据问题严重得回头查采集环节。3.2 用 SQL 做时段聚合和桩利用率排名数据清洗完落到 SQLite 后真正的分析才刚开始。充电运营最关心的两个指标是「分时段充电量」和「桩利用率」。分时段看的是电网负荷和定价策略桩利用率看的是资产回报。这两个指标用 SQL 做比 pandas 更直观也更容易复用到生产环境。-- 分时段充电量按小时聚合看一天里的充电高峰 SELECT strftime(%H, start_time) AS hour_of_day, COUNT(*) AS order_cnt, ROUND(SUM(energy_kwh), 2) AS total_kwh, ROUND(AVG(avg_power_kw), 2) AS avg_power FROM clean_orders GROUP BY hour_of_day ORDER BY hour_of_day; -- 桩利用率排名按桩统计订单数和总电量取前 10 SELECT pile_id, COUNT(*) AS order_cnt, ROUND(SUM(energy_kwh), 2) AS total_kwh, ROUND(SUM(duration_min) / 60.0, 2) AS busy_hours FROM clean_orders GROUP BY pile_id ORDER BY total_kwh DESC LIMIT 10;第一条 SQL 的strftime(%H, start_time)把时间截到小时注意 SQLite 的 strftime 对带时区的字符串处理有限如果前面存进去的是带08:00的 ISO 字符串最好在入库前就转成纯本地时间字符串。第二条 SQL 里busy_hours是累计充电时长用它除以统计周期总小时数就是利用率但 demo 数据往往只覆盖几天所以这里先看绝对值排名。参数上LIMIT 10按需调整做全量排名就去掉。如果你发现某个桩的total_kwh高得离谱先别高兴很可能是这个桩的订单里混了测试数据或者重复记录回头用订单号去重验证一下。提示SQLite 没有原生的时区函数所有时间运算都基于字符串。如果你在 pandas 里已经转成了带时区的 datetimeto_sql存进去会变成带偏移的字符串后续 SQL 聚合前最好先统一转成YYYY-MM-DD HH:MM:SS格式的本地时间字符串。4. 避坑与排查充电 demo 数据处理里最容易翻车的五件事4.1 解压后中文列名乱码读进来全是问号现象用 pandas 读 CSV列名显示为\xe8\xae\xa2\xe5\x8d\x95\xe5\x8f\xb7这种字节串或者直接是乱码方块。原因文件是 GBK 或 GB18030 编码而 pandas 默认按 UTF-8 读。解决读取时显式指定encodinggbk如果还不行就试gb18030它兼容性更广。如果只有个别列乱码可能是导出时混合了编码那就先用iconv整文件转码再读。4.2 订单号和采样表关联不上JOIN 出来是空现象订单主表有 5 万条采样表有 200 万条但按订单号 JOIN 后只剩几千条。原因两边订单号的格式不一致比如一边是纯数字一边带了前缀或者前后有空格。解决JOIN 前先做标准化strip()去空格统一大小写去掉非数字字符。用SELECT DISTINCT对比两边的样本肉眼确认差异模式。4.3 金额字段带货币符号求和直接报错现象amount列里混着¥12.50、12.5元、12.50三种格式SUM出来是 0 或者报类型错误。原因导出时没有做数值格式化。解决用正则提取数字部分再转 floatdf[amount].str.replace(r[^\d.], , regexTrue).astype(float)。注意这个操作会丢掉负号如果有退款订单正则要保留-。4.4 采样表时间间隔不均匀直接算功率偏差大现象按采样点算平均功率和订单主表里的总电量对不上。原因采样间隔不固定有的 30 秒有的 2 分钟简单平均会失真。解决用时间加权先算相邻采样点的时间差作为权重再对功率做加权平均。或者直接用订单总电量除以总时长以主表为准采样表只用来画曲线。4.5 去重去掉了正常数据订单量骤降现象按订单号drop_duplicates后数据量少了一半。原因一笔订单在采样表里本来就有多行你误对采样表去重了或者订单主表里同一订单号确实有多次状态更新记录。解决先确认去重的粒度订单主表按订单号去重采样表按「订单号采样时间」去重。去重前用duplicated()看看重复的是哪些列别一刀切。5. 把 demo 数据变成可复用的验证集三个进阶技巧5.1 用采样数据反推桩的功率曲线验证设备健康度demo 数据里最有价值的其实不是订单汇总而是采样表里的功率序列。一个健康的直流桩功率曲线应该是先爬升到额定功率维持一段平台期然后随 SOC 升高逐渐下降。如果你发现某个桩的功率曲线频繁出现断崖式下跌或者长时间停在低功率那可能是模块故障或者枪口接触不良。做法是把采样表按订单号分组取功率列用滑动窗口算方差方差超过阈值的订单标记为异常。# 按订单分组计算功率序列的波动指标 def power_stability(group): p group[power_kw].values if len(p) 5: return None return { order_id: group.name, max_power: p.max(), std_power: p.std(), drop_count: int((pd.Series(p).diff() -10).sum()), # 功率骤降次数 } stability samples.groupby(order_id).apply(power_stability).dropna() # 骤降超过 3 次的订单大概率设备有问题 suspicious stability[stability[drop_count] 3] print(suspicious.head(10))这段代码的逻辑是对每个订单的功率序列统计最大值、标准差和「单步下降超过 10kW」的次数。diff()算相邻差值小于 -10 说明功率在短时间内掉了 10kW 以上正常充电过程不该频繁出现。参数上10kW 这个阈值适合 60kW 以上的直流桩交流慢充要调小到 1-2kW。len(p) 5是过滤采样点太少的订单样本不足算出来的统计量没意义。跑完看suspicious的数量如果占比超过 5%说明这批 demo 数据里的设备状态分布可能偏真实故障场景正好拿来测试你的告警规则。5.2 构造「脏数据」子集做数据质量回归测试demo 数据的一个隐藏用法是当测试夹具。你把清洗逻辑写好后可以人为往干净数据里注入几类典型脏数据——空值、重复行、时间倒挂、金额异常——然后跑你的清洗 pipeline看能不能全部识别并处理。这比等生产环境出问题再修要主动得多。具体做法是写一个inject_dirty函数按比例随机污染记录污染位置再验证清洗后这些位置是否被正确修复或剔除。脏数据类型注入方式预期处理结果空值随机将 5% 的 energy_kwh 置空被过滤或填充为 0重复行随机复制 3% 的行按订单号去重后消失时间倒挂交换 2% 订单的起止时间被有效性过滤剔除金额异常将 1% 的 amount 乘以 100被 3σ 或 IQR 规则标记这张表可以直接当测试用例清单用。每注入一类跑一次清洗对比输出行数和标记数量就能量化你的清洗逻辑覆盖率。注意注入比例别太高超过 10% 会让数据面目全非失去参考价值。5.3 用 ECharts 把聚合结果快速可视化验证指标合理性数字对不对比看曲线更直观。把前面 SQL 算出的分时段充电量导成 JSON丢给 ECharts 画个柱状图你一眼就能看出高峰时段是否符合常识——比如早高峰和晚高峰两个峰凌晨低谷。如果曲线是平的或者出现多个莫名其妙的尖峰说明聚合逻辑有问题。这一步不需要写前端工程一个 HTML 文件加 CDN 引入 ECharts 就够。// 假设后端返回的数据格式[{hour: 08, kwh: 1234.5}, ...] fetch(/api/hourly_energy) .then((res) res.json()) .then((data) { const chart echarts.init(document.getElementById(chart)); chart.setOption({ xAxis: { type: category, data: data.map((d) d.hour :00) }, yAxis: { type: value, name: 充电量(kWh) }, series: [{ type: bar, data: data.map((d) d.kwh), itemStyle: { color: #3b82f6 }, }], tooltip: { trigger: axis }, }); });这段 JS 的关键是数据映射x 轴用小时字符串y 轴用电量数值tooltip开启轴触发方便悬停看具体值。实际用时把fetch的地址换成你的接口或者直接内联 JSON 数据。颜色和样式按需调重点是先看到形状。我一般会把这个页面留着每次改完清洗逻辑就刷新看一眼曲线形状不对就回去查 SQL比盯着数字快得多。5.4 一个我踩过的坑别把 demo 当生产数据用最后说个教训。有次我拿一份类似的充电 demo 数据调好了整套指标信心满满接生产库结果第一天就翻车——生产数据里订单量是 demo 的几千倍我那个用 pandas 全量加载再 groupby 的脚本直接把内存打爆。后来改成先按时间分区逐天读、逐天算、结果追加写入才稳住。demo 数据能帮你验证逻辑对不对但验证不了性能边界。所以我的习惯是demo 阶段就把「分块处理」和「增量计算」的架子搭好哪怕数据量小到用不上等接生产时改的只是参数不是架构。这个方案值不值得做如果你手头正好有充电数据要处理花半天把 demo 跑通比直接上生产库试错成本低得多。希望帮到你。本文还有配套的精品资源点击获取