简介：这是一份由欧盟委员会联合研究中心（JRC）发布、面向电力系统建模与能源系统分析人员的欧洲水力发电厂数据库，基于公开资源整理而成，为水电并网仿真、调度优化及多能源互补研究提供统一可追溯的基础数据支撑。压缩包约702KB，共5个文件，其中CSV文件保存电厂明细，JSON描述数据包结构和字段，MD提供读前指引，PNG展示电厂空间分布，LICENSE明确许可规则。数据字段覆盖电厂ID、名称、装机容量（含抽水能力）、国家、坐标、类型（径流式/水库式/抽水蓄能）、名义水头、可用库容、最大存储容量及年平均发电量，并预留与GEO、PyPSA-EUR、WRI全球电厂数据库的关联键，便于直接嵌入已有分析流程；存储容量仅在可公开获取时给出，避免估算引入的不确定性。已有388人学习/下载，适合正在搭建欧洲区域电力模型或需要统一水电数据口径的研究者，可直接将其中的CSV数据导入数据分析环境做后续计算与可视化。 做能源基础设施盘点，最烦的就是数据东拼西凑。前阵子在GitHub上翻到一个开源数据集，hydro-power-database，全称是JRC水力发电厂数据库。它把全球已知的水力发电设施，包括径流式、蓄水式、抽水蓄能，统一整理成结构化数据文件，附了坐标、装机容量、水库信息、投运年份、年发电量这些关键字段。对做能源规划、水电资源评估、气候变化影响建模，或者单纯想在GIS里画一张全球水电分布图的人来说，这个库能省掉大量从各国报告和论文里手动扒数的时间。
这篇博文可以看作一份实际使用记录：这个数据库是什么、字段里有哪些坑、怎么把它落到自己的数据库里做查询和统计，以及应用时常见的坑。下面进入正题。
1. 数据来源与整体设计思路
1.1 JRC这个库是怎么来的
JRC是欧盟联合研究中心（Joint Research Centre），长期做能源、环境、可持续相关的数据整合和空间分析。hydro-power-database是它维护的一个开源项目，托管在GitHub上，持续迭代。它的原始数据来源很杂：各国能源部门公开统计、水电工程文献、卫星遥感反演的水库信息、国际组织的数据集等。JRC做的事就是把散落在各个来源里的水电设施信息归拢，做统一编码、字段标准化，再以开放数据的形式发布。
换句话说，它最大的价值不是“独家数据”，而是“整合和清洗”。如果你自己去翻，一个国家的水电装机表可能来自政府白皮书，另一个国家的来自行业论文，单位还不一致，甚至电站坐标都可能差出几十公里。JRC把它变成了一张可以直接用的表，省事程度天差地别。
1.2 它和GRanD、WRI那些数据集有什么不一样
做水电研究的人可能听过GRanD全球大坝数据库、WRI全球水电站数据库。JRC这个库和它们的区别，我实际对比下来有三点。
第一，覆盖面更偏“电厂”而不是“大坝”。GRanD重点关注坝体本身，很多小水电没有明显大坝，GRanD收录就不全。JRC这个库以电厂为实体单位，对径流式电站、坝后式电站都做了收录。
第二，字段设计贴近能源分析需求。它不只是给个地理位置和坝高，还提供装机容量、年发电量、水库面积、投运年份这些直接可用于能源统计和碳排放分析的属性，而你不需要再去关联十几个别的表。
第三，上游会记录数据来源标识。很多字段不是单一置信度，你能看出这条记录是官方公布还是模型估算，这在做严肃研究时特别重要。GRanD在水利工程细节上更细，但论“拿来就能做电力分析”，JRC这个库的整合度更高。
2. 核心字段与数据质量细节
2.1 字段逐个拆开看
这个库常见的字段包括电厂名称、国家、所在河流、经纬度坐标、装机容量（MW）、年发电量（GWh）、水库面积（km²）、坝高（m）、投运年份，还有若干用于追溯来源的字段。下面列几个重点说明一下。
| 字段 | 常见单位 | 使用说明 |
|---|---|---|
| plant_name | 文本 | 电厂名称，注意不同国家可能同名，不能单独当主键 |
| country | ISO国家码或文本 | 做跨国统计时要统一为国别代码 |
| capacity_mw | MW | 装机容量，这是最常用的统计口径 |
| annual_generation_gwh | GWh/年 | 可能是实测值，也可能是模型估算值，务必看来源 |
| reservoir_area_km2 | km² | 水库面积，遥感反演居多，精度有限 |
| commissioning_year | 年 | 投运年份，部分老电站缺失，需要结合其他数据源补 |
| geometry / lat, lon | WGS84经纬度 | 空间分析的关键字段 |
实际用的时候，我习惯先把装机容量为0或NULL的记录单独拎出来看看。这类记录往往是小水电或被拆除电站，直接忽略会导致装机总量偏低；不区分就统计，又会让你误以为数据有缺漏。先做一次基础统计，心里有数再往下走。
2.2 坐标和单位这两个雷区
坐标系统是空间数据最常见的问题。这个库基本使用WGS84经纬度，也就是EPSG:4326，大部分时候直接用没问题。但我在实际项目里遇到过一次，某次下载的数据子集坐标整体偏移了约300米，原因是一条老数据的坐标是局部投影坐标，没有转成经纬度。所以不管库本身怎么说，拿到数据第一件事就是用GIS软件加载，跟底图对一下，看电站点位是否落在河流附近。
单位问题更隐蔽。容量字段虽然设计为MW，但部分来源是kW，个别老记录甚至可能是MVA（视在功率），入库时如果不做校验，汇总数字会差出几个量级。还有面积字段，不同来源可能混用km²和公顷。建议写一个简单的数值分布检查，比如容量列的最大值如果超过2万，基本可以判定有单位污染记录。
2.3 版本更新与引用注意事项
这种开源数据库通常不会只发一版，GitHub仓库里按年份或版本号更新。你会看到类似v1.0、v2.0，或者按数据年份划分的文件目录。我的建议是：在项目文档里明确记录你用的是哪个版本、下载日期、文件哈希。因为水电数据会随着新电站投产、老电站退役和源数据修订而变，不锁版本，半年后你的分析可能无法复现。
另外，JRC这个库属于开放科学数据的范畴，引用时最好附上原始仓库和DOI。很多学术期刊要求数据引用规范，提前把这个写进README或论文材料里，能省很多后期麻烦。
3. 实操过程：下载、入库与基础统计
3.1 落库方案怎么选
拿到数据以后，第一个问题是往哪存。我按场景给几个选择，你可以直接对照。
如果只是做一次性探索，或者本地简单统计，SQLite是首选。它单文件、零配置、Python内置支持，一个.db文件就能带着走。做教学演示也方便，学生不用装服务端。
如果要做多用户并发查询，或者后续要叠加行政边界、人口密度栅格、气候区划这些空间数据，PostgreSQL配合PostGIS扩展是最稳的组合。空间索引、空间函数一应俱全，是行业内做空间数据生产的标配。
MySQL和Oracle也能存，但如果你是做空间分析，PostGIS有压倒性优势。国内项目如果牵涉国产化选型，达梦、人大金仓这类数据库语法上兼容Oracle或PostgreSQL，也能落表，但空间分析扩展支持不如PostGIS成熟，评估时要多留个心眼。
3.2 用Python完成入库与基础统计
下面是我常用的一套流程，直接用pandas读CSV，再写入SQLite，然后跑一个按国家汇总装机的统计。
import pandas as pd import sqlite3 df = pd.read_csv("hydro-power-database.csv", encoding="utf-8") conn = sqlite3.connect("hydro.db") df.to_sql("plants", conn, if_exists="replace", index=False) cur = conn.cursor() cur.execute(""" SELECT country, COUNT(*) AS cnt, SUM(capacity_mw) AS total_mw FROM plants GROUP BY country ORDER BY total_mw DESC LIMIT 10 """) for row in cur.fetchall(): print(row) conn.close()这段代码的重点是to_sql会把pandas的字段类型自动映射到SQLite，但如果你后面要写复杂SQL，最好先查看一下建表语句，确认capacity_mw确实是数字类型而不是文本。很多坑都出在pandas读CSV时把某个字段推断成object，导致SQL里SUM得出来是字符串拼接。
如果数据量大，建议直接用DuckDB跑分析，它读CSV比pandas快得多。虽然DuckDB定位是OLAP，但做这种单机统计绰绰有余，写起来也简单：
SELECT country, COUNT(*), SUM(capacity_mw) FROM 'hydro-power-database.csv' GROUP BY country ORDER BY 3 DESC LIMIT 10;对，DuckDB可以直接把CSV当表查，连导入都省了。不过它不算常规意义上的数据库软件，更多是分析利器，适合快速出结果。
3.3 结合PostGIS做空间分析
再进一步，如果要做空间关系查询，比如“哪些水电站在洪水高风险区范围内”，就需要进入PostGIS的领域。先建表并转换成Geometry类型：
CREATE TABLE plants_geo AS SELECT id, plant_name, capacity_mw, ST_SetSRID(ST_MakePoint(lon, lat), 4326) AS geom FROM plants;然后创建空间索引：
CREATE INDEX idx_plants_geo ON plants_geo USING GIST(geom);有了这个索引，后续的缓冲区查询、叠加分析效率会好很多。比如找每个电站周边10公里有哪些已建电站，就能用ST_DWithin做空间连接，这在评估流域水电开发密度时很有用。
3.4 一个补充：数据库增删改查在这个场景怎么体现
你如果拿这个库做数据库课程设计，这就是现成的实验数据。比如建表之后练习INSERT、UPDATE、DELETE，可以用“新增一座2025年投产的电站”“把某电站装机容量从1200更新为1350”“删除标注为已退役的记录”这种业务操作。它比传统的“学生表”“商品表”有意思，因为字段类型丰富，适合练习多条件查询和聚合统计。
我自己带新人时也常拿它练手，因为数据真实，学生查出来的结果跟实际电力分布对得上，会更有成就感。
4. 常见问题与排查技巧实录
4.1 数据缺失与异常值处理
这个库最常见的坑是缺失值。投运年份、坝高、年发电量都可能为空。我的处理原则是：如果是描述性统计，明确标注缺失量；如果是回归建模，看缺失率决定是否插补。
还有一种异常是坐标漂移。部分电站的经纬度是自动化编码的结果，可能落在偏离实际位置几十公里的地方。排查时可以把电站点和全球河流矢量数据做一次空间关联，如果点离河流超过一个阈值，就打标记复核。虽然不能保证100%准确，但能快速暴露明显错误。
4.2 字段类型、编码和重复记录问题
用utf-8编码读取CSV是最基本的，但某些老版本文件可能混入BOM头，导致第一列字段名带着不可见字符。这种情况在导入数据库后字段名会变得很奇怪，查SQL时总报语法错误。解决办法是用Notepad++、VSCode或命令行iconv统一转码，再入库。
重复记录问题更隐蔽。同一个电站因为分机组记录，可能被拆成多条，容量只占一部分。判断重复不能只看名字，还要结合河流、国家、装机容量、投运年份综合判断。我给过一个简单逻辑：如果plant_name、country、capacity_mw三个字段完全一致，就认为是重复，保留一条，删除其余。
4.3 关于数据库连接和并发的一些提醒
如果你只是单机分析，不太会遇到连接数问题。但如果你把这个库做成在线查询服务，就要考虑连接池配置。连接池太小，并发上来会排队；连接池太大，数据库内存吃紧。常见场景是短时间内大量并发查询，MySQL或PostgreSQL默认配置很可能把连接数打满，表现就是客户端一直报“无法连接数据库”。
还有死锁问题，多见于多事务同时更新同一批记录。只读查询场景不太可能死锁，但如果你做了数据预处理任务，多个任务同时写入同一条电站记录，就有一定概率碰到。我的习惯是写入任务遵循相同顺序操作记录，比如都按主键排序后批量更新，死锁概率会大幅下降。
4.4 常见问题速查表
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 坐标点在海洋或明显偏离河道 | CRS不一致或源数据坐标偏移 | 重新检查坐标系，与河流矢量叠加复核 |
| 装机总量偏大/偏小 | 单位混用（kW vs MW） | 检查数值分布，统一单位 |
| 同一电站出现多行 | 分机组记录或重复收录 | 按名称、国别、容量去重 |
| 字段名乱码 | CSV编码不一致或BOM头 | 统一转UTF-8，去掉BOM |
| 导入后数值字段变成文本 | pandas类型推断错误 | 建表时显式声明schema |
| 并发查询时数据库无响应 | 连接池满 | 调整max_connections或连接池参数 |
| 多事务写入出现死锁 | 并发冲突 | 统一事务操作顺序，按主键排序更新 |
5. 应用场景与后续扩展思路
5.1 能源规划与水电潜力评估
装机容量和年发电量组合起来，可以直接做区域水电开发现状评估。比如按流域汇总装机总量，再和理论水电潜力对比，算出开发率。很多地区开发率数据都来自这类数据库的加总，而不是逐国翻报告。如果你做海外项目前期调研，这个库是很好的起点。
但要注意，这个库给出的是“现状装机”，不是“可开发潜力”。做潜力评估时，需要叠加地形、流量、自然保护区边界等数据，筛选出适合新建水电的流域，再估算理论装机上限，这是完全不同的分析链条。
5.2 气候变化影响与风险暴露分析
水电对气候变化非常敏感，径流式电站尤其。你可以把电站地理坐标与气候模型的径流预测格点数据做空间连接，评估未来径流变化对发电量的影响。也可以结合洪水淹没模型，分析水库大坝在下游极端洪水情景下的暴露度。这种分析在学术论文里很常见，关键就在于有一个全球尺度的电站点位数据作为底表。
5.3 教学与课程设计场景
如果你的专业方向是数据库、GIS或能源系统工程，这个库是很好的课程设计素材。学生可以从建表、数据清洗、增删改查、聚合统计，一路做到空间分析，完整走一遍数据全生命周期。相比传统的“商品订单”案例，它更能激发兴趣，因为最后画出来的全球水电分布图是真的能看出能源格局的。
比如一个典型的课程设计要求：统计各大洲水电装机占比、找出装机量前十的流域、计算全球水电平均单站装机容量。这三问覆盖了多表关联、子查询、聚合函数，难度梯度也合适，作为期中项目很划算。
5.4 往后可以往哪些方向扩展
我现在自己做的方向是把JRC这个库和碳排放因子结合起来，估算全球水电替代火电的减排贡献。思路很简单：装机容量乘以容量系数，得到实际发电量，再乘以区域电网的平均碳排放因子。只要再叠加一个容量系数数据集就能完成。这个库的字段结构做得足够规范，扩展起来几乎不用改表。
如果你有精力，还可以尝试更新自己的流域编码，把电站关联到HydroSHEDS或HydroATLAS的流域ID，这样就能做流域层面的横向比较。跨出这一步，水电数据就能和土壤侵蚀、水文模型、生态保护数据打通，应用空间会大很多。
我个人在实际操作中的体会是，这种公开数据库拿到手，最重要的不是马上跑模型，而是先花时间把字段和数据来源摸透。数据文件只有几十兆，但它背后整合的功夫值回票价。你先做一遍清洗、入库、空间叠加，后面所有分析都会顺很多。以后再拿到类似的开源地理数据集，处理流程基本可以复用，一次积累，长期受益。
本文还有配套的精品资源，点击获取
