简介一份面向充电桩运营数据分析、GIS可视化及接口联调场景的轻量Demo数据集聚焦湖北黄石及周边充电站站点信息适合需要真实充电站数据做解析、展示或测试的初中级开发者与数据分析师。整份压缩包仅31KB共18个文件其中16个JSON按站点逐一存储结构化明细另附1个XLS站点汇总表便于快速浏览整体分布包内还留有作者联系方式文件方便交流。内容覆盖黄石宝马充电站、大冶中心城市综合体、黄石瑞捷充电站等多样站点部分文件还标注了‘道路检修无法使用’等状态能用于练习异常状态数据清洗、字段抽取与批量解析。通过站点列表可快速定位各充电站JSONXLS则提供汇总视角整体目录虽小但结构清晰适合充电桩数据项目的前期原型验证或教学演示。已有1338人学习下载。1. 星星充电数据demo.7z一份充电桩数据样本能验证多少事星星充电数据demo.7z是充电桩运营平台在对外做数据合作或算法竞赛时常发的一类脱敏数据包从真实环境里按比例抽取订单、桩状态和告警记录压成一个 7z 文件分发。它谈不上大却足够让你在不上生产系统的前提下把充电桩数据的字段口径、时间粒度、单位习惯一次摸清用来验证报表逻辑、训练算法模型或者测试数仓流程都够用。适合三类人刚接手充电数据的新手分析师、要评估数据质量的算法工程师、以及给充电平台做数据对接的软件开发。2. 解压 .7z 前的工具选型与最小命令Linux 和 Windows 别装错拿到星星充电数据demo.7z第一件事不是双击也不是直接扔给 pandas 去读而是先确认两件事压缩包是不是完整以及系统里有没有能解开 7z 的工具。7z 压缩率通常比 zip 高 20%~30%代价是工具生态不如 zip 普及——Linux 默认并不带 7z 命令Windows 自带的“压缩文件夹”也解不了 7z。我在帮别人排查这类 demo 数据时见过太多卡在第一步的情况装错工具、漏装组件、把 .001 分卷只下了一半结果解压到一半报 CRC 校验错误。先花两分钟把工具选好后面所有步骤都不会白做。2.1 7z 工具三选一p7zip、7-Zip、py7zr 怎么选常见做法是看你所在的系统和分析链路选不是三个都装。Linux 服务器一般装 p7zip-full。它提供 7z、7za、7zr 三个命令其中完整版 7z 支持的格式和解压选项最全能处理带密码、分卷、解压到指定目录这些操作。Debian/Ubuntu 的软件源里有两个包一个叫 p7zip另一个叫 p7zip-full后者才带 7z 命令本体建议直接装 full。装完执行 7z i 查看版本号如果低于 16.02解压超过 4GB 的大文件时可能报错老工具在碰到新压缩参数时尤其容易翻车。Windows 桌面端用 7-Zip 官方版。除了右键集成它自带一个文件管理器打开压缩包后左侧会显示压缩文件树不用解压就能看到里面有哪些目录、哪些 CSV、每个文件原始大小。这个文件树对判断数据包结构特别有用你能一眼看出订单是按天拆文件还是一个大 CSV再决定解压后怎么读。如果你常在远程 Windows 服务器做分析把 7z.exe 加进 PATH写批处理脚本时能省掉一长串绝对路径。纯 Python 环境里我推荐 py7zr。它是纯 Python 实现的 7z 解压库pip install py7zr 即可不依赖系统命令适合在数据管道里批量解压多个 demo 包。py7zr 的解压速度比原生 7z 慢但稳定性足够而且能直接读出包内文件列表配合 pandas 可以做到“边解压边读”不必把解压文件全部落盘。三者的选择边界可以这样记服务器做数据分析用 p7zip临时看包结构用 7-Zip写自动化代码用 py7zr。工具适用环境安装方式常用命令p7zip-fullLinuxapt install p7zip-full7z x demo.7z7-ZipWindows官网安装包7z.exe x demo.7zpy7zrPython 3.8pip install py7zrPy7zr().extractall(path)2.2 Linux 下解压 7z 文件的最小命令如果压缩包已经落盘我一般会执行一次“安全解压”先查看再解压。查看这一步能帮你确认包内是否有一个统一根目录避免解压后文件散落一地。Ubuntu/Debian 下的最小命令组合是# 安装 p7zip-fullDebian/Ubuntu 通用 sudo apt update sudo apt install -y p7zip-full # 列出压缩包内文件不解压只看清单 7z l 星星充电数据demo.7z # 解压到指定目录-o 与路径之间不能有空格 mkdir -p ~/star_demo 7z x 星星充电数据demo.7z -o~/star_demo -y7z l 输出每一条文件路径、原始大小、压缩大小和 CRC 值。实际解压时-o 指定输出目录7z 不会自动创建目录所以先用 mkdir -p 兜底-y 表示遇到覆盖提示自动确认适合脚本自动化。如果你担心覆盖旧文件可以把 -y 去掉交互确认更安全。如果在 Windows 上做同样的事命令主体不变只是可执行文件名换成 7z.exe7z.exe l 星星充电数据demo.7z 7z.exe x 星星充电数据demo.7z -oD:\workspace\star_demo -y不太想敲命令的话右键压缩包选“7-Zip - 解压到指定文件夹”在弹窗里填目标路径即可。注意解压完成后别急着关窗口第一眼确认解压出的根目录名和文件树再决定后续脚本路径。另一种常见情况是拿到的是分卷文件比如 星星充电数据demo.7z.001、.002 这样一串。分卷必须从 .001 开始解且所有分卷放在同一个目录命令还是 7z x 星星充电数据demo.7z.001工具会自动按序号找后续分卷。如果你发现中间某个分卷缺失解压到一半会报错报错信息里会带缺失分卷的文件名按名去补下即可不用全部重下。2.3 解压后先看文件树顺序错了后面全白做解压完成后的第一件事不是打开 CSV而是用 tree 或 ls 递归看目录结构。充电桩数据 demo 通常按业务域拆目录大致如下tree star_demo # 期望输出: # star_demo/ # ├── station/ # │ └── station_info.csv # ├── order/ # │ ├── order_20240101.csv # │ └── order_20240102.csv # └── device/ # ├── device_static.csv # ├── device_status.csv # └── device_alarm.csv看到这个结构后续分析路线基本就定了station 是站点主数据order 是交易明细device 是设备状态与告警。主数据用于关联维度交易明细用于算量算费设备状态用于可用率分析。三条线对应不同表不要上来就把所有 CSV 读进同一个 DataFrame 硬 join数据量和粒度都不一样join 完你会得到一张巨宽且意义混乱的表。文件/目录内容域典型用途station/station_info.csv站点主数据站点名称、地址、运营商、桩数order/order_YYYYMMDD.csv交易明细订单量、充电量、费用、利用率device/device_status.csv设备状态可用率、在线率、故障统计device/device_alarm.csv告警事件故障定位、告警聚类在这一步顺手确认三件事。第一CSV 文件头有没有 BOM带 BOM 的 UTF-8 在 pandas 里会把第一列列名读成带 \ufeff 前缀的怪名字第二order 目录下按天还是按月切分这直接决定 groupby 的粒度第三包内有没有 schema.json 或 README.txt很多 demo 会把字段字典放在说明文件里先读它比猜字段强得多。工具和入口确认完毕后下一步就是读表和理解字段了。3. 看懂 demo 里的三类表订单、桩状态、站点主数据星星充电这类充电平台的数据 demo字段命名可能每家不同但背后实体基本一致。订单表记录“一次充电业务”的完整链路谁在哪个站哪台桩上从几点充到几点充了多少度电付了多少钱。设备状态表记录桩的高频心跳区分空闲、充电、离线、故障。站点主数据则是静态字典把站点名称、地址、运营商、桩的功率等级固定下来。先分清这三类表后面做关联和分析才不会张冠李戴。3.1 充电订单表时间、电量、费用三个核心字段订单表是 demo 里价值最高的一张表它直接支撑“充电量有多少”“收入有多少”“利用率高不高”这类业务问题。常见的订单字段构成如下字段名类型常见单位字段含义order_idstring-订单唯一编号user_idstring-用户标识已脱敏station_idstring-充电站编码device_idstring-充电桩编码start_timedatetimeyyyy-mm-dd HH:MM:SS充电开始时间end_timedatetimeyyyy-mm-dd HH:MM:SS充电结束时间powerfloatkWh本次充电电量feefloat元用户支付总金额service_feefloat元其中服务费部分duration_minint分钟充电时长这里最核心的三个字段是 start_time、power、fee。时间字段能聚合出日/周/月曲线电量字段是新能源运营的核心指标直接关联碳减排折算和电网负荷预测费用字段关联收入分析。注意power 的行业标准单位是 kWh也就是常说的“度”。很多跨行过来的同事会默认它是 kW那是功率单位差一个时间维度。订单表里如果真出现功率字段一般叫 peak_power、avg_power 之类单位是 kW别跟 power 混。费用字段要特别注意 fee 与 service_fee 的关系。充电计价大体是“总费用 电费 服务费”电费是电网侧成本服务费是运营主要利润来源。demo 数据里费用字段可能被整体加扰但这个比例结构通常保留。所以算收入时别只盯着 fee要把电费和服务费拆开看否则做营收构成分析时口径对不上。时间字段也是最容易被误用的部分。start_time 和 end_time 同时存在意味着你可以自己算充电时长也可以判断订单是否跨尖峰平谷时段。我一般不太相信 duration_min——它可能是系统按整点处理后的近似值自己用 end_time 减 start_time 得到的分钟数更精确。如果两列同时存在且计算值差异超过 5 分钟基本可以断定 duration_min 是另一套统计口径。3.2 设备状态表和告警表粒度决定分析上限设备状态表在最简单的 demo 里只有三列device_id、status_code、heartbeat_time。status_code 各家定义不同常见取值是 0 离线、1 空闲、2 充电中、3 故障。这张表的特点是行数极大每台桩每 30 秒到 1 分钟上报一条一个 50 桩站点一天就能产生几万到十几万行是整个 demo 包里数据量最大的部分。告警表是另一类事件数据记录设备在什么时间报了哪种警。常见字段有 alarm_id、device_id、alarm_type、alarm_level、start_time、end_time。告警表和状态表最大的区别在于写入频率状态表是固定节奏心跳告警表是事件发生时插入一行时间分布天然不均匀。alarm_level 一般分提示、次要、重要、紧急四档但 demo 抽样时往往会过滤掉“提示”档因为提示类告警量太大占空间。这两张表的粒度差异直接决定分析方法。订单表是一事一结一个月几千到几万行状态表是一报一录一个月几百万行告警表是一警一录数量不稳。计算设备可用率时应该以状态表为基础统计每个站点“空闲充电中”的时间占比而不是用订单时长去近似——订单时长只覆盖正在充电的窗口非充电的空闲时间全被丢掉了。做故障定位时则要把告警表和状态表按 device_id 时间窗口关联先定位告警发生时刻再看前后一分钟内桩的状态变化确认到底是瞬时抖动还是持续故障。3.3 一份能直接跑的 CSV 读取脚本看懂结构之后我习惯用一个脚本把订单表读进来并验证 schema下面是可直接复制的版本import pandas as pd # 读取订单 CSV时间列边读边解析 orders pd.read_csv( star_demo/order/order_20240101.csv, parse_dates[start_time, end_time], dtype{ station_id: string, device_id: string, user_id: string, }, encodingutf-8-sig, ) # 看前几行确认字段没读歪 print(orders.head(3)) # 看类型重点确认时间列是不是 datetime64 print(orders.dtypes) # 看数值分布马上能发现单位异常 print(orders[[power, fee]].describe())parse_dates 让 pandas 把时间字符串转成 datetime64dtype 把 ID 类字段强制转成 string。这一步很关键因为 station_id 这类前缀带 0 的编号如果放任 pandas 按 int64 读00123 会变成 123后面和站点表 join 一定匹配不上。encoding 指定 utf-8-sig能同时兼容带 BOM 和不带 BOM 的 UTF-8 文件。读完第一时间做三项核对列名列表、dtypes、每列缺失值数量。如果 start_time 是 object 而不是 datetime64说明 parse_dates 没生效最常见原因是源文件里存的是 Unix 整数而不是时间字符串这个在第 4 章处理。如果 power 有大量空值先别急着 fillna回到原始数据确认是抽样丢了字段还是正常为空——免费充电订单可能没有 service_fee但没有 start_time 的订单没有任何分析价值。如果 demo 里同时给了 JSON 格式的订单数据也可以用 json 库逐行解析import json with open(star_demo/order/order_20240101.json, encodingutf-8) as f: orders_json [json.loads(line) for line in f if line.strip()] orders pd.DataFrame(orders_json)这种逐行 JSON 在导出的数据里很常见每行一个订单对象字段名和 CSV 基本对应。用列表推导式读进来再转 DataFrame和 read_csv 效果一致。4. 把 demo 数据洗成能用时间、单位、空值三关解压和读取只是热身真正让新手翻车最多的是清洗环节。充电桩数据的坑高度集中在三处时间字段要么是 Unix 秒要么是字符串数值字段的单位多半存在混用空值字段的填充方式直接影响统计口径。我一般按“先时间、再单位、最后空值”的顺序处理依次通过后数据基本就可以进入分析或建模了。4.1 时间戳格式化先看位数再动手demo 里的时间字段通常以两种形式出现一种是标准字符串“2024-01-01 08:12:33”一种是 10 位或 13 位的整数 Unix 时间戳。pandas 的 parse_dates 只能解析字符串遇到数字会原样读成 int64所以拿到数据后先看 dtype再决定怎么转。# 情况一标准字符串显式指定格式 orders[start_time] pd.to_datetime( orders[start_time], format%Y-%m-%d %H:%M:%S ) # 情况二10 位 Unix 秒最常见 orders[start_time] pd.to_datetime( orders[start_time], units ) # 情况三13 位 Unix 毫秒少部分平台使用 orders[start_time] pd.to_datetime( orders[start_time], unitms )这里最容易踩的坑是位数的选择。10 位数字是秒13 位数字是毫秒如果用 units 去解析 13 位数字出来的时间会跑到 50000 年之后几乎一眼就能发现异常反过来用 unitms 解析 10 位数字得到的是 1970 年附近的瞬间很容易被误当成“数据全空”而直接丢弃。所以转换前先打印一列前几行数一下位数再决定 unit。如果 demo 数据跨时区还要额外处理时区偏移。国内充电平台一般直接存北京时间CST不带时区后缀如果数据源是 UTC画出来的日曲线整体右偏 8 小时夜间充电高峰会变成凌晨高峰。统一时区的处理方式# 把无时区的时间先标记为 UTC再转上海时区 orders[start_time_cst] ( orders[start_time] .dt.tz_localize(UTC) .dt.tz_convert(Asia/Shanghai) )时区问题比较隐蔽因为单独看时间戳看不出问题只有做跨站点、跨数据源对比时才会暴露。处理原则只有一个所有外部数据在入库前统一转成同一个时区不要留“当地时区”的口子。4.2 单位与精度kW 和 kWh 差一个字母就翻车充电数据里的单位问题是血泪经验高发区。我至少见过三种混用power 字段数值其实是 Wh字段名却没带单位电量存成 mWh 需要除以 1000 或 10000功率字段明明是 kW却被当成 kWh 直接累加。判定单位最可靠的办法是先做分布统计再和充电桩的物理参数对比。一台 120 kW 的直流桩单次订单充电量通常在 10~80 kWh 之间极端的超充场景也不会超过 500 kWh。如果 orders[power].describe() 的均值显示几万或者最大值是 120000那几乎可以断定单位是 Wh。修正方式很简单# 先看描述统计再判断单位 print(orders[power].describe()) # 若确认单位是 Wh统一转成 kWh orders[power_kwh] orders[power] / 1000费用字段也要防“元”和“分”的混用。充电订单金额一般精确到分但 CSV 导出可能保留两位小数元或者不带小数分。一个快速判断技巧看 service_fee 字段如果服务费是 0.38 这样的小数单位是元如果是 38单位是分。统一换算后再参与聚合否则日均收入会放大 100 倍对账必然对不上。还有浮点精度问题。CSV 里的费用可能是 23.459999999这是浮点存储的固有误差不是数据错误。聚合前先 round(2) 再求和能避免最后报表出现 0.01 的尾差orders[fee] orders[fee].astype(float).round(2)4.3 空值与重复值先算缺失率再决定填不填空值处理最怕盲目 fillna。先算缺失率再结合字段业务含义定策略。比如 fee 为空可能是免费充电营销订单可以接受但 start_time 为空绝对不能接受这条订单没法参与任何时间维度分析。# 缺失率一览 missing orders.isna().mean() print(missing[missing 0]) # 按业务主键去重订单表用 order_id orders orders.drop_duplicates(subset[order_id], keepfirst)重复值同样是常见隐患。订单号理论上全局唯一但 demo 抽样时可能把同一订单重复导出设备状态表更是每天都可能有重复上报。处理重复值的标准做法是 subset 指定业务主键订单表用 order_id状态表用 device_id heartbeat_time 的组合。不要对整个 DataFrame 去重否则不同时间的合法记录会被误删。时间字段缺失时如果 end_time 缺失但 duration_min 存在可以用 start_time 加 duration_min 推算反过来则用 end_time 减时长。但这种推算只适合做分布统计不适合做计费——计费偏差一分钟都可能引发客诉。所以推算前一定在订单表里加一列 is_estimated 标记后面算费用时好把它剔除或单独分析。5. 避坑解压和读数阶段最常见的五个坑这一章写给准备动手或者已经翻车正在查原因的人。下面五个问题我几乎每次拿到新的 demo 数据都会遇到至少一个按出现频率排序写在这里。5.1 解压报“无法作为 7z 解压”扩展名和真实格式对不上现象执行 7z x 星星充电数据demo.7z 后终端提示“Unsupported archive format”或“无法作为 7z 压缩文件打开”。原因文件传输过程中被改名或者发布侧用 zip/RAR 压缩后直接把后缀写成 .7z 分发另一种常见情况是网盘下载中断生成了残留文件扩展名是 .7z 但内容不完整。解决先用 file 命令看真实格式再选对应的解压方式。# 查看文件真实类型 file 星星充电数据demo.7z # 如果输出 Zip archive data说明其实是 zip unzip 星星充电数据demo.7z -d star_demo # 如果输出 RAR archive data用 unrar 或 7z 再试 7z t 星星充电数据demo.7z7z t 是完整性校验命令输出里带每个文件的 CRC 校验结果。如果显示某个文件 CRC 失败说明文件在下传时损坏重下对应文件比本地折腾工具更快如果整个包都解不开直接联系发布方重新打包别花时间猜格式。额外提醒一句解压前先确认压缩包来源。7z 和 zip 一样可能携带路径穿越漏洞老版本解压工具在解压恶意构造的包时可能把文件写到目标目录之外。我一般用 7z l 看一下包内路径发现 ../ 或者绝对路径就直接放弃解压不冒这个险。5.2 订单 CSV 打开乱码编码不是 UTF-8 的锅现象用 Excel 双击打开订单 CSV中文全部显示成乱码但在 pandas 里读却正常反过来有些文件 pandas 读乱码Excel 正常。原因文件是 UTF-8 编码Excel 默认按 GBK 解码所以显示乱码如果文件是 GBK 编码pandas 默认按 UTF-8 读同样乱码。解决在 pandas 读取时显式指定编码。# UTF-8 带 BOM 的读法Excel 和 pandas 都正常 orders pd.read_csv(order.csv, encodingutf-8-sig) # 如果确认是 GBK 编码 orders pd.read_csv(order.csv, encodinggbk)不确定编码时可以用文本编辑器如 VS Code打开文件右下角会显示推断的编码。统一把文件转成带 BOM 的 UTF-8 再分发两边都不会乱码这个处理对团队协作特别重要因为 Excel 用户永远是数据链路里不可忽略的一环。5.3 时间字段读出来是 11 位数字忘记转时间类型现象orders[start_time].dtype 显示 int64打印出来是 1704067200groupby 按天聚合时报错或者结果全部落在 1970 年。原因时间列实际存的是 Unix 时间戳。pandas 不会自动把整数识别成时间pd.to_datetime 默认按纳秒解析于是得到 1970 年附近的错误结果。解决按位数选 unit 参数10 位用秒13 位用毫秒。orders[start_time] pd.to_datetime( orders[start_time], units ) # 转换后抽一列日期再做 groupby orders[date] orders[start_time].dt.date daily orders.groupby(date)[power].sum()这个坑几乎每个新手都会踩一次原因是 Excel 里显示的是格式化后的日期但导出成 CSV 时底层存的是时间戳。看到 10~11 位整数第一时间就该想到 Unix 时间而不是问“怎么全是数字”。5.4 电量突然放大 1000 倍单位混用是常态现象一台 120 kW 直流桩某条订单电量显示 120000而同一台桩其他订单普遍在 30~70。原因导出脚本在某一行把 kWh 写成了 Wh导致电量放大 1000 倍更少见的还有把 mWh 当成 kWh放大 10000 倍。这类脏数据在真实平台数据里并不罕见尤其多供应商数据汇接时。解决先用分位数筛查异常值再用业务常识判定。# 看分位数99 分位如果超过 1000基本可判定有单位问题 print(orders[power].quantile([0.5, 0.9, 0.99, 1.0])) # 把超过桩功率上限*充电时长上限的订单标记出来 orders[power_abnormal] orders[power] 500如果确认整个文件都是 Wh直接除以 1000 统一修正如果只是个别行异常则标记后剔除不要整个文件换算否则会把本来就对的 95% 数据改坏。修改前保留一份原始列给自己留条退路这种换算操作没有后悔药。5.5 demo 解压后内存不足改分块读取现象解压出的订单 CSV 有好几个 GBread_csv 读着读着进程被杀或者报 MemoryError。原因7z 压缩包大小和解压后 CSV 的差距常在 5~10 倍pandas 默认一次性读全表哪怕你只需要三列。解决只选需要的列或者分块读取做聚合。# 方法一usecols 只读需要的列内存立刻降一半以上 orders pd.read_csv( orders.csv, usecols[start_time, power, fee, station_id], parse_dates[start_time], ) # 方法二分块读取聚合 daily pd.Series(dtypefloat) for chunk in pd.read_csv( orders.csv, chunksize500000, parse_dates[start_time] ): daily daily.add( chunk.groupby(chunk[start_time].dt.date)[power].sum(), fill_value0, )chunksize500000 表示每 50 万行做一次 groupby再把结果累加到 daily 里峰值内存只跟单块大小有关跟整个文件不再成正比。更彻底的做法是第一次读取时转存成 parquet后续分析全基于 parquet又快又省内存。6. 用 demo 数据画一张日充电量曲线数据可用性的最快验证数据清洗完第一张图我建议画“按天聚合的充电量柱状图”。这张图能一次性暴露三类问题时间解析是否成功、单位是否统一、聚合口径是否有误。如果图上的量级在几十到几千度电、曲线有自然的周末波动说明这份 demo 已经可以进入正式的报表或模型开发。import pandas as pd import matplotlib.pyplot as plt # 读取已清洗的订单数据 orders pd.read_csv( star_demo/order/order_20240101.csv, parse_dates[start_time], encodingutf-8-sig, ) # 按天聚合充电量与订单数 orders[date] orders[start_time].dt.date daily orders.groupby(date).agg( 订单数(order_id, count), 充电量(power, sum), 费用(fee, sum), ) # 柱状图标题写清单位避免看图的人误读 fig, ax plt.subplots(figsize(12, 4)) ax.bar(daily.index, daily[充电量], width0.8, labelkWh) ax.set_title(Daily Charging Volume) ax.legend() plt.tight_layout() plt.savefig(daily_volume.png, dpi150)看图时重点核对三点。第一单日充电量是否在合理范围一个 50 台桩的小型充电站单日能耗通常在 2000~20000 kWh小样本 demo 会低一些但不该是个位数如果落到个位数大概率是单位换算错误或者时间筛选范围有问题。第二日期轴是否连续如果中间跳了好几天说明源数据抽取时加了限定条件比如只保留工作日。第三有没有单日尖峰是邻近日期的十倍以上这种尖峰通常对应单位错误或重复导入需要回头查原始数据而不是直接当真实业务高峰。我个人的习惯是任何 demo 数据在进入模型之前先画这张图并让懂业务的人确认“看上去像不像真的”。数据如果连业务常识都过不了后面再复杂的模型也是在垃圾上盖楼——这不是调参能救回来的问题。做数据对接时我也把这个图作为验收物对方给的数据能画出这张图才算真正跑通从解压到分析的最小闭环。这一步走通了你就已经从“拿到一个压缩包”走到了“拿到一份可用的数据资产”。沿着这条路径再做充电站利用率、分时充电特征、用户充电行为分析边界只在你业务问题问得多细而不是数据能不能用。希望帮到你。本文还有配套的精品资源点击获取