简介：一套面向气象数据分析预测场景的Java后端工程资源，涵盖数据获取、处理、用户服务与网关服务等核心模块，适合具备一定Java基础、希望了解机器学习与气象业务结合方式的开发者和学习者。资源共97个文件，以77个Java源码文件为主，辅以11个XML配置、4个YAML配置文件，以及少量日志和忽略规则文件，整体仅109KB，结构精简，便于快速阅读和二次开发。包内按Meteo-Obtain-Resource、Meteo-Process-Resource、UserClient-Service、Meteo-GateWay等模块组织，清晰展示了从气象数据采集、清洗加工、模型预测到对外服务与网关路由的完整链路；代码中涉及数据预处理、模型调用、接口封装等实践细节，可作为中小型智能气象预测系统的架构参考。目前已有448人学习下载，适合用于课程设计、毕业设计或个人项目起步。
1. 气象数据分析预测系统的定位与数据流
很多拿到MeteoDataProcessServer-master.zip这类多模块工程的人，第一反应是去找神经网络代码，结果翻遍Meteo-Process-Resource才发现主要精力全在数据清洗与特征工程上。这个仓库其实对应一条标准的“数据获取 → 处理 → 模型推理 → 用户服务”流水线，四个核心模块分别是Meteo-Obtain-Resource、Meteo-Process-Resource、UserClient-Service和Meteo-GateWay。本文以 Java 技术栈为例，拆解一个可用于课程设计、人工智能大作业或小型业务验证的气象数据分析预测系统。你会看到在不依赖 Python 训练服务的情况下，如何用 Java 完成气象数据接入、时间序列清洗、机器学习模型训练，以及通过网关把预测结果安全地暴露给前端。新手可以照着代码走通全流程，熟手则能从这里看到时序特征泄漏、网关限流参数和模型验证窗口的设计边界。
2. 数据获取服务实现:从 HTTP API 到 Java 数据模型
2.1 多源气象数据源的接入方式
Meteo-Obtain-Resource模块是整个系统的最前端，负责把气象站 API、历史 CSV 批处理和卫星栅格数据统一成内部可用的WeatherRecord对象。三种来源的特点差异很大，先看一张对比表：
| 数据源 | 类型 | 接入成本 | 典型坑 |
|---|---|---|---|
| 开放气象 API | JSON | 低 | 字段单位不一致、请求限额 |
| CSV 历史数据 | 表格 | 中 | 时区混乱、缺失值多 |
| 卫星栅格 NetCDF | 多维网格 | 高 | 需要专业解析库，内存占用大 |
课程设计阶段优先选开放 API，因为卫星栅格数据需要额外引入ucar等重库，解析 NetCDF 的时间足够把整个模型训练流程写完。接入层最重要的不是“能拉到数据”，而是把不同源的字段统一成一套内部规范。比如温度有的源返回开尔文，有的返回摄氏度；风速有的用 m/s，有的用 km/h。这类单位差异如果放到处理模块再去改，会让错误很难追踪。
下面是一段从气象 API 拉取数据的 Java 代码：
// Meteo-Obtain-Resource/src/main/java/com/meteo/obtain/client/WeatherClient.java @Component public class WeatherClient { private final RestTemplate restTemplate; public WeatherClient(RestTemplate restTemplate) { this.restTemplate = restTemplate; } public WeatherDto fetchStationData(String stationId, LocalDateTime from, LocalDateTime to) { String url = "https://api.example.org/v1/weather?station={id}&start={start}&end={end}"; Map<String, String> params = Map.of( "id", stationId, "start", from.toString(), "end", to.toString() ); ResponseEntity<String> resp = restTemplate.getForEntity(url, String.class, params); return parseJson(resp.getBody()); } }这段代码把 HTTP 请求收敛在WeatherClient类中，后续如果切换 API 提供商，只需要改这里的 URL 和参数映射。from和to必须格式化成 ISO8601 标准字符串，很多气象 API 不接受带空格的日期串。另外一定要给RestTemplate配置连接超时和读取超时，否则某个气象站响应慢会拖垮整个采集线程。常见做法是使用SimpleClientHttpRequestFactory设置 5 秒连接超时和 15 秒读取超时。
2.2 字段映射与内部模型设计
采集器拿到的 JSON 结构往往嵌套复杂，直接绑定到实体类会让代码脆弱。建议先用 Jackson 的JsonNode做一次性字段映射，再组装成WeatherRecord。这样上游字段一改，只需要改一个方法。
public WeatherRecord mapFromJson(String json) { ObjectMapper mapper = new ObjectMapper(); JsonNode root = mapper.readTree(json); WeatherRecord record = new WeatherRecord(); record.setStationId(root.path("station").asText()); record.setTemperature(root.path("temp_2m").asDouble() - 273.15); // K转C record.setWindSpeedMs(root.path("wind_speed_10m").asDouble() / 3.6); // km/h转m/s record.setObservedAt(LocalDateTime.parse(root.path("time").asText())); return record; }path("temp_2m")比get("temp_2m")更安全，字段缺失时返回MissingNode而不是抛 NPE。温度从开尔文转摄氏度、风速从千米每小时转米每秒，这些转换逻辑放在获取服务里完成，Meteo-Process-Resource只处理干净数据。内部模型WeatherRecord的字段建议统一使用LocalDateTime，不要用Date，否则后续时间窗口切片会很痛苦。
2.3 定时采集与生产消费解耦
实际项目中，气象数据采集通常是定时任务，而不是某个接口被调用时才去拉取。模型训练需要连续时间段的观测数据，散落的实时点没法构造特征。我一般用 Spring 的@Scheduled做固定延迟采集，用BlockingQueue解耦采集和处理速度。
@Component public class WeatherIngestionJob { private final WeatherClient weatherClient; private final BlockingQueue<WeatherRecord> rawQueue = new LinkedBlockingQueue<>(); @Scheduled(fixedDelay = 1800000) public void ingest() { List<String> stations = List.of("WUHAN", "SHANGHAI", "BEIJING"); for (String station : stations) { WeatherDto dto = weatherClient.fetchStationData( station, LocalDateTime.now().minusHours(1), LocalDateTime.now() ); for (JsonNode node : dto.getData()) { WeatherRecord record = mapFromJson(node.toString()); rawQueue.offer(record); } } } }BlockingQueue在这里是经典的生产-消费模型解耦点。采集速度快、处理速度慢时，队列会自然堆积，后续即使把队列替换成 Kafka 或 RabbitMQ，也不会影响采集代码。注意@Scheduled默认是单线程执行，如果站点数量超过 50 个，建议改用ThreadPoolTaskScheduler配置并发采集，否则一个慢接口会阻塞整轮任务。另外队列容量要设置上限，避免采集进程一直运行导致内存溢出。
3. 数据处理服务:清洗、插值、时间窗口与特征工程
3.1 缺失值处理与异常值检测
Meteo-Process-Resource是数据进入模型前的最后一道质检线。气象数据最常见的问题是传感器离线导致整段缺失、瞬时风速超出合理范围，以及换站时产生的重复记录。清洗的第一原则是：只能在单个时间窗口内部做填充，不能使用全样本均值，否则会把未来信息带入训练集，造成数据泄漏。
public List<WeatherRecord> clean(List<WeatherRecord> records) { // 1. 去重：同一站点同一时刻只保留一条 Map<LocalDateTime, WeatherRecord> dedup = new LinkedHashMap<>(); for (WeatherRecord r : records) { dedup.putIfAbsent(r.getObservedAt(), r); } List<WeatherRecord> list = new ArrayList<>(dedup.values()); // 2. 异常值：温度范围 -40~45，风速 0~60 list.removeIf(r -> r.getTemperature() < -40 || r.getTemperature() > 45); list.removeIf(r -> r.getWindSpeedMs() < 0 || r.getWindSpeedMs() > 60); return list; }这里的阈值区间是气象业务里比较保守的常识范围。实际部署时要根据地域动态调整，比如青海湖冬季温度下限低于零下三十度很正常，而广州的冬季下限不可能到零下二十度。removeIf适合直接丢弃异常样本，但如果要保留时间序列完整性，更安全的做法是把超限值标记为缺失，再交给后面的插值逻辑处理。
3.2 时间序列重采样与插值
气象站上报时间间隔往往不均匀，有的站点十分钟一条，有的超过一小时。机器学习模型要求固定步长序列，因此需要把原始数据重采样到统一频率，比如每小时一条。常用插值方法有三种：
| 方法 | 适用场景 | 风险 |
|---|---|---|
| 线性插值 | 短时间缺测 | 遇长缺口会失真 |
| 前向填充 | 缓慢变化的气压 | 滞后性明显 |
| 多项式插值 | 平滑信号 | 容易过拟合噪声 |
我的经验是短于 3 小时的缺口用线性插值最稳，超过 6 小时的缺口直接丢弃该段，不要硬补。下面是重采样与插值的代码：
public TreeMap<LocalDateTime, Double> hourlyResample(List<WeatherRecord> records) { TreeMap<LocalDateTime, Double> hourly = new TreeMap<>(); for (WeatherRecord r : records) { LocalDateTime hour = r.getObservedAt().truncatedTo(ChronoUnit.HOURS); hourly.putIfAbsent(hour, r.getTemperature()); } LocalDateTime start = hourly.firstKey(); LocalDateTime end = hourly.lastKey(); for (LocalDateTime t = start; t.isBefore(end); t = t.plusHours(1)) { if (!hourly.containsKey(t)) { Map.Entry<LocalDateTime, Double> prev = hourly.floorEntry(t); Map.Entry<LocalDateTime, Double> next = hourly.ceilingEntry(t); if (prev != null && next != null && !prev.getKey().equals(next.getKey())) { double ratio = (double) Duration.between(prev.getKey(), t).toMinutes() / Duration.between(prev.getKey(), next.getKey()).toMinutes(); hourly.put(t, prev.getValue() + ratio * (next.getValue() - prev.getValue())); } } } return hourly; }TreeMap的有序性在这里非常关键，floorEntry返回小于等于当前时刻最近的一条，ceilingEntry返回大于等于当前时刻最近的一条。ratio表示当前时刻在前两个观测点之间的位置，本质是两点线性插值。注意前后观测点相同时要跳过，否则分母为零。
3.3 特征切片与标准化
模型不直接吃原始温度，这会导致数据量巨大且过拟合。我习惯用滑窗构造“过去 24 小时特征 + 当前时刻特征”，预测未来 3 小时的目标值。窗口长度太大特征爆炸，太小捕捉不到昼夜周期。标准化选择 Z-score 而不是 Min-Max，是因为气象数据里的突发异常值会被 Min-Max 拉伸到极端区间，干扰模型训练。
public double[][] buildFeatures(TreeMap<LocalDateTime, Double> series) { List<double[]> features = new ArrayList<>(); List<LocalDateTime> times = new ArrayList<>(series.keySet()); for (int i = 24; i < times.size(); i++) { double[] window = new double[3]; window[0] = series.get(times.get(i - 24)); window[1] = series.get(times.get(i - 1)); window[2] = series.get(times.get(i)); features.add(window); } return features.toArray(new double[0][]); } public double[] standardize(double[] feature, double mean, double std) { double[] out = new double[feature.length]; for (int i = 0; i < feature.length; i++) { out[i] = (feature[i] - mean) / std; } return out; }窗口使用滞后特征，这是时序预测最朴素的建模方式。standardize里的mean和std必须只由训练集计算，之后应用到验证集和测试集。很多人在这一步直接对整个数据集算均值，造成信息泄漏，模型评估分数虚高，换到新数据就崩。
特征层面我还会加入滑动平均和温差，它们的意义如下：
| 特征 | 计算方式 | 物理含义 |
|---|---|---|
| 滞后温度 | 过去N小时温度 | 热惯性 |
| 滑动平均 | 过去24h均值 | 平滑短时波动 |
| 温差 | 窗口内max-min | 天气稳定程度 |
4. 机器学习模型训练与验证:线性回归与随机森林对比
4.1 预测任务建模与标签构造
气象预测在这里被建模成回归问题，而不是分类问题。分类只能回答“是否降温”，回归才能给出未来几小时的具体温度数值，农业、交通场景都依赖数值。Java 生态中训练模型可以选 Smile 或 Weka，我更推荐 Smile，因为它的 API 更现代，能直接吃double[][]特征矩阵，不需要生成 ARFF 中间文件。
标签构造必须注意时间对齐：如果用t时刻的样本预测t+3时刻，训练标签必须是t+3的真实观测值。常见错误是把标签错位成当前时刻，导致模型学到“当前温度预测当前温度”的恒等映射，看起来误差极低，实际上一小时后的预测完全失效。
4.2 用 Smile 训练随机森林
Smile 的随机森林实现支持特征重要性输出，这比黑盒神经网络更容易向项目汇报。以下是训练示例：
double[][] trainX = ...; // 特征矩阵，已标准化 double[] trainY = ...; // 未来3小时温度 RandomForest forest = RandomForest.fit(trainX, trainY, RandomForest.TreeOptions.of(100) .withMaxDepth(10) .withMaxNodes(256)); double[] preds = forest.predict(testX);of(100)表示训练 100 棵树，withMaxDepth(10)限制树深，withMaxNodes(256)限制叶子节点数。气象数据带有明显的周期性噪声，树深超过 15 时很容易把单个异常点学进去。训练完成后可以调用forest.importance()查看特征重要性，通常“当前温度”和“24小时前温度”排在最前，这是一个合理的可解释性验证。
4.3 网格搜索与前向链验证
时间序列任务不能直接用KFold交叉验证，随机打乱会把未来样本混进训练集。正确做法是前向链验证：用第 1 天到第 n 天训练，预测第 n+1 天；然后把第 n+1 天加入训练集，继续预测第 n+2 天。这样可以模拟真实线上预测时“只有过去数据”的约束。
for (int i = 2; i < 10; i++) { double[][] trainX = Arrays.copyOfRange(features, 0, i * 24); double[] trainY = Arrays.copyOfRange(labels, 0, i * 24); double[][] testX = Arrays.copyOfRange(features, i * 24, (i + 1) * 24); double[] testY = Arrays.copyOfRange(labels, i * 24, (i + 1) * 24); // 每一轮训练集都在扩大，验证集始终紧跟在训练集之后 }i * 24的24来自每小时一条数据的频率，第 i 天刚好有 24 条样本。网格搜索时，随机森林的参数组合建议控制在 50 组以内，否则单机训练会非常慢。常见参数组合是树数量[50, 100, 200]，最大深度[5, 10, 15]，叶子节点数[64, 128, 256]。
模型选型可以参考这张表：
| 模型 | 解释性 | 训练速度 | 非线性 | 适用场景 |
|---|---|---|---|---|
| 线性回归 | 高 | 快 | 无 | 基准模型、趋势外推 |
| 随机森林 | 中 | 中 | 有 | 中小特征维度 |
| 神经网络 | 低 | 慢 | 强 | 大数据量 |
如果训练集只有几个月的小时级数据，随机森林往往是性价比最高的起点。神经网络需要更多数据，且要调学习率、层数、Dropout 等超参数，课程设计阶段容易陷入调参泥潭。
5. 用户服务与网关服务:Spring Boot 与 Spring Cloud Gateway 落地
5.1 用户服务的预测查询 API
UserClient-Service负责对外暴露查询接口，它的内部实现不关心模型是怎么训练出来的，只负责从缓存或模型中读取预测结果并返回。接口设计上，建议用GET加路径参数和查询参数，语义清晰且便于网关做路由。
@RestController @RequestMapping("/api/v1/forecast") public class ForecastController { private final ForecastService forecastService; @GetMapping("/{stationId}") public ResponseEntity<ForecastDto> getForecast( @PathVariable String stationId, @RequestParam String date) { if (!isValidStation(stationId)) { return ResponseEntity.badRequest().build(); } ForecastDto result = forecastService.predict(stationId, LocalDate.parse(date)); return ResponseEntity.ok(result); } }date参数使用LocalDate.parse可以自动校验格式，避免不同时区造成日期偏移。isValidStation做站点白名单校验，防止用户传入任意字符串去触发底层查询。用户服务本身不做模型训练，预测结果会缓存到 Redis 或本地 Caffeine Cache 中，保证接口响应时间在 50ms 以内。
5.2 网关服务的路由、限流与负载均衡
Meteo-GateWay作为所有请求的入口，把/api/v1/forecast/**路由到用户服务，把/admin/**路由到管理服务。网关的职责不只是转发，还要做限流和超时控制。下面是一段 Spring Cloud Gateway 的配置片段：
spring: cloud: gateway: routes: - id: forecast_route uri: lb://user-client-service predicates: - Path=/api/v1/forecast/** filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 10 redis-rate-limiter.burstCapacity: 20 key-resolver: "#{@userKeyResolver}"lb://user-client-service表示从注册中心按负载均衡算法找到可用实例，如果配合 Nacos 或 Eureka，用户服务扩容时网关会自动感知。replenishRate=10表示每秒补充 10 个令牌，burstCapacity=20允许瞬间突发 20 个请求。这个配置能防止大屏应用高频轮询把后端打挂，也能应对短时流量尖峰。key-resolver用用户 ID 维度分离限流，避免某个用户刷接口影响其他用户。
5.3 安全认证与异常兜底
网关层还需要做统一的 API Key 校验，保证只有合法调用方可以访问预测接口。这里不要在用户服务里重复鉴权，网关通过全局过滤器统一处理即可：
@Bean public GlobalFilter apiKeyFilter() { return (exchange, chain) -> { String apiKey = exchange.getRequest().getHeaders().getFirst("X-Api-Key"); if (!"meteo-fixed-key".equals(apiKey)) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } return chain.filter(exchange); }; }固定 API Key 只适合课程设计和内部联调，生产环境应该替换为 JWT 或 OAuth2。网关校验通过后，可以在请求头注入X-User-Id，下游服务直接信任这个字段，就不用每个服务都对接一次认证中心。网关的异常处理也要到位，下游超时或返回 500 时必须给出统一 JSON 错误体，否则前端会看到一堆堆栈信息。
网关过滤器常用功能可归纳为下表：
| 过滤器 | 作用 | 注意事项 |
|---|---|---|
| RequestRateLimiter | 令牌桶限流 | 需引入 Redis |
| GlobalFilter | 全局鉴权 | 路径放行需要白名单 |
| Retry | 失败重试 | 幂等接口才可开启 |
6. 时序预测验证技巧:避免数据泄漏与误差指标选择
6.1 前向链验证 vs 普通K折
在气象预测这种时间序列任务中，普通 K 折验证会把未来的数据混进训练集，导致模型在不经意间“偷看”答案。比如用第 3 天的数据训练，第 2 天的数据验证，学习到的规律在现实预测中根本不存在。严格的做法是前向链验证：训练集只包含验证集之前的数据，并且验证窗口不能太短。小时级数据建议至少一周的窗口，否则单日大风或寒潮会显著扭曲误差。
实现上可以继续沿用上一章的训练循环，核心是在每一轮训练前只对训练窗口计算标准化参数，验证集使用同一种参数转换，不允许重新计算。
6.2 误差指标 RMSE 与 MAE 的配合
回归任务最常用的是 RMSE 和 MAE。RMSE 由于对误差做了平方，放大了极端预测的惩罚，适合用来发现恶劣天气下的失败样本。MAE 更直观，单位与预测目标一致。如果 RMSE 比 MAE 大出 30% 以上，说明模型对冷锋过境或强对流天气的预测存在几个极端偏差点。
我一般把 Java 服务的预测结果落成 CSV，再用 Python 脚本快速评估，因为数据科学工具链更成熟：
import pandas as pd from sklearn.metrics import mean_squared_error, mean_absolute_error df = pd.read_csv("prediction_result.csv") rmse = mean_squared_error(df["actual"], df["predicted"], squared=False) mae = mean_absolute_error(df["actual"], df["predicted"]) print(f"RMSE={rmse:.2f}, MAE={mae:.2f}")这段脚本不参与线上服务，只用于离线验证和模型更新决策。squared=False在mean_squared_error中表示返回 RMSE 而不是 MSE，这个参数在 scikit-learn 1.4 之后一直被保留，旧版本可能需要手写np.sqrt(...)。
6.3 可视化回测与模型更新频率
把预测值和真实值画在同一张折线图上，比任何指标都直观。如果发现每天凌晨的预测误差显著偏大，说明模型缺少夜间辐射降温特征，应该去检查特征列表里有没有加入地表温度或云量，而不是盲目调深度。模型更新频率也要控制：气象数据存在季节漂移，今年 7 月训练的模型很难预测明年 1 月的温度。常见做法是只保留最近 60 天的训练数据，用滑动窗口重建模型，每次更新耗时短且能跟上季节变化。
本文还有配套的精品资源，点击获取
