Open-Meteo 本地部署：3 步快速自建免费气象数据 API-平芜编程栈

Open-Meteo 本地部署：3 步快速自建免费气象数据 API

【免费下载链接】open-meteoFree Weather Forecast API for non-commercial use项目地址: https://gitcode.com/GitHub_Trending/op/open-meteo

Open-Meteo 是一个开源的气象数据平台，把 NOAA GFS、DWD ICON、ECMWF IFS 等气象机构发布的公开预报，统一成一套无需 API key 的 REST 接口。跑在自己的服务器上，就等于自建气象服务：数据落在自己机器，接口随业务改，不用向第三方按量付费。

先跑起来：3 条命令完成 Open-Meteo 本地部署

🚀 结论先说：不用写代码，也不用 clone 源码编译——官方镜像可以直接从公开数据库取数，第一次请求就能出结果。

先看硬件底线：x86-64 或 Arm 服务器、至少 8GB 内存（推荐 16GB）、100GB 以上磁盘，NVMe SSD 更好（存储同时兼任缓存）。详见启动文档。

创建数据卷，存放气象数据和缓存：

docker volume create --name open-meteo-data

启动 API 容器，REMOTE_DATA_DIRECTORY指定公开数据库来源，端口默认只绑定本机：

docker run -d --rm --name open-meteo \ -v open-meteo-data:/app/data \ -e REMOTE_DATA_DIRECTORY=https://openmeteo.s3.amazonaws.com/data/ \ -e CACHE_SIZE=8GB \ -p 127.0.0.1:8080:8080 \ ghcr.io/open-meteo/open-meteo

发一条查询，第一次会慢几秒（要取数并写缓存），之后就近坐标会明显变快：

curl "http://127.0.0.1:8080/v1/forecast?latitude=47.1&longitude=8.4&models=ecmwf_ifs025&hourly=temperature_2m"

如何确认跑成功：响应是一段 JSON，里面temperature_2m字段有完整的小时时间序列（time 和 values），说明本地气象服务已经可用。

一句实话：自托管实例是"按需从公开数据库取数 + 本地缓存"的模式，响应通常比官方公网 API 慢，适合有稳定、重复查询量的场景，不适合只查一次。

它是怎么工作的：数据从哪来、怎么存、怎么查

🧊 打个比方：各国气象机构是出厂的原料商，Open-Meteo 是超市，你的查询是直接从货架上拿一袋已经分装好的商品。

数据从哪来：各国气象机构公开发布的数值预报（NOAA GFS、DWD ICON、ECMWF IFS、MeteoFrance 等）免费可下载，但原始格式是二进制 GRIB 文件，直接用的话要懂网格、投影、二进制定制格式这些专业内容——这正是 Open-Meteo 替你做的事。
怎么存：下载后统一转换成它自研、开源的压缩二进制格式（OM 文件），存在./data目录。这个格式专为"查某个地点一段时间序列"优化，比如"取柏林未来 7 天的温度"只需读很少的数据块。API 大约每 2 分钟检查一次公开数据库的预报更新并预加载，本地数据则保留在CACHE_SIZE控制的 LRU 缓存里。
对外怎么查：标准的/v1/forecast这类 REST 接口，参数就是经纬度、模型、变量，返回 JSON。整个链路源码都在仓库里，比如预报 API 路由、数据读取层，想改什么都能翻到出处。

长期用得稳：按需同步、控制存储、管住访问

📌 跑起来之后，真正花心思的是这三件事。

1. 按需同步，而不是全量下载

默认配置下 API 已经会按需从公开数据库取数并缓存，什么也不用做。
想让数据完全落盘在自己机器上，就另起一个容器跑sync命令，只拉"模型 + 变量"组合（源码见 SyncCommand.swift）：

docker run -d --name open-meteo-sync \ -v open-meteo-data:/app/data \ ghcr.io/open-meteo/open-meteo \ sync dwd_icon temperature_2m --repeat-interval 5

它每 5 分钟对账一次，只下载缺失或新增的文件。

官方 cronjob 示例列了直连各气象机构的全量时间表，但官方明确提醒：全量下载每天产生 4~8TB 流量，务必只选业务需要的变量。

2. 用定时任务压住存储占用

存储占用 ≈ 变量数 × 时间深度，历史数据只增不减，必须定期清理。
官方给出的做法是find按文件年龄分层删除，例如删掉 30 天前的预报数据（sync 文档里的例子用的是 Ubuntu 包路径，Docker 部署对应到数据卷里的/app/data）：

find /app/data -type f -name "chunk_*" -mtime +30 -delete

机器多时不必每台都下载：指定一台机器跑下载，其余 API 节点按多节点同步方案拉取现成数据库。

3. 管住访问，盯住指标

默认端口只绑 127.0.0.1，不要直接暴露公网；对外开放就前置 nginx 反向代理，顺带解决 TLS。
多人共用可以启用内置的 API key 机制：把 key 和限额写进文件、设置API_APIKEYS_PATH，每个 key 有独立调用配额，内置限流。
/metrics接口输出 Prometheus 格式（仅本机可访问），请求数、错误数、缓存占用都有现成指标，可直接接进已有监控（实现在 MetricsController.swift）。

两个真实使用场景

🌾场景一：给 App 加天气功能，不想被第三方免费 API 卡脖子

问题：调用第三方免费 API 有每日请求量上限，网络延迟也取决于别人的服务。
做法：在用户所在区域部署一个 Open-Meteo 本地部署节点，App 后端改为调用本地 API，热查坐标自动进缓存。
效果：接口与公网版完全一致，业务代码不用改；天气请求走内网，配额和数据都归自己。

🚚场景二：内部系统批量查天气（农业、物流、户外排班）

问题：系统每小时要对几百个坐标取天气，反复走公网 API 费带宽、也费配额。
做法：自建节点，用sync只拉业务用到的变量（温度、降水、风速），保留天数按业务设定。
效果：盘里只存真正要用的数据，系统从此有了"自己的气象服务"，数据还能离线分析和回测。

怎么选：Open-Meteo 自建 vs 其他方案

对比项	Open-Meteo 自建	商业气象 API	公网免费 Open-Meteo API
费用	免费，只承担服务器成本	按调用量或档位收费	非商业用途免费
数据掌控	数据存本机，完全自主	数据在第三方	不可控
定制能力	开源（AGPL-3.0），源码可改	有限	不可修改
部署复杂度	中等，容器一键启动	低	无
性能	取决于自有机器和缓存	依赖服务商	公网延迟，通常很快
商用	允许商用自托管（数据为 CC-BY-4.0，需署名）	可商用	商用需另行联系