企业官网建设流程全解析

开篇先交代一个背景：每到毕业季，我都能在技术社区看到大量关于“基于XX的大数据分析系统”的提问，而气候数据分析这个方向尤其受欢迎。原因不难理解——气候数据是公开的、量级足够大、时间序列特征明显，天然适合拿来展示Spark的分布式处理能力和LSTM的时序预测能力，再加上Flask做后端服务，整套系统既有技术深度，又有可视化效果，答辩时讲起来也很有底气。我去年辅导过几个做同类项目的学生，自己也完整跑通过一个“Flask-基于Spark的气候数据分析系统”，今天就把从选题、架构到编码、调优、答辩准备的完整过程拆开来讲。

这篇文章不是给你贴一段云里雾里的源码就完事，而是把每一步“为什么这么做”“踩了什么坑”“怎么改才能过”都写清楚。适合正在做毕业设计的计算机专业学生，也适合想快速上手Spark+LSTM技术栈、又需要落地一个完整项目的开发者。理解完这套组合，你不仅能答辩过关，还能真正理解大数据系统里数据层、计算层、模型层、应用层各自该干什么。

1. 选题思路与整体架构拆解

1.1 为什么选气候数据分析：题目如何兼顾难度与可行性

气候数据分析作为毕设题目，它的好处在于“数据源稳定、问题域清晰、技术栈有层次”。所谓数据源稳定，是指无论是国家气象信息中心、NOAA公开数据集，还是国内一些高校开放的天气历史数据库，都能拿到多年份、多站点的气温、降水、湿度、风速等结构化数据。这一点很重要，很多学生选题目时张嘴就是“社交网络用户画像”“电商行为分析”，真到实现阶段才发现数据根本拿不到，只能临时用模拟数据糊弄，答辩时一问就露馅。

从问题域看，气候数据天然是时间序列，预测明天或未来一周的温度、降水概率，用LSTM来做非常顺理成章。这比硬把LSTM套在商品推荐或其他非时序数据上要自然得多。同时，数据量一旦覆盖多个城市、几十年时段，单机Pandas处理起来就会吃力，Spark就有了用武之地。一个题目的数据层能用到Spark、模型层能用到LSTM、展示层又能用到Flask+可视化，这就是评委想看到的“工作量和完整度”。

1.2 技术栈选型的取舍：Flask + Spark + LSTM 各司其职

我见过不少选题类似但技术栈混乱的项目，比如有人用Django替换Flask说“更重”，也有人试图用Spark自带的MLlib里的算法替代LSTM。这里必须先说清楚每个组件的定位。

• Spark负责数据预处理和特征工程。它跑在分布式环境下，可以对千万级别的气象记录做清洗、聚合、滑动窗口计算。你在答辩时可以说“海量历史气候数据的清洗与特征提取由Spark完成”，这句话本身就构成一个加分点。
• LSTM负责时间序列预测。从趋势上看，LSTM在温度、湿度这类中短期气候预测上的表现是可解释的、有依据的，而且PyTorch或TensorFlow实现起来都不复杂，模型代码量不大，容易讲清楚。
• Flask负责把模型封装成Web服务。Flask本身轻量，核心就几个路由，可以做API返回预测结果，也可以直接渲染前端页面。相对Django来说，Flask更容易在一周内搞定，代码也更简洁，适合毕设的时间节奏。

这套组合还有一个隐藏的好处：Spark做离线数据处理，LSTM做模型训练与预测，Flask做在线服务，三者之间边界清晰，画架构图时层次分明，导师和评委一眼就能看懂你的系统是“怎么转起来的”。

1.3 系统分层：从数据接入到前端展示的完整链路

一个完整的气候数据分析系统，我建议按四层来设计：数据采集与存储层、数据处理与特征工程层、模型训练与预测层、Web应用与可视化层。

数据采集层解决“数据从哪来、放哪去”的问题。最稳妥的做法是下载公开CSV/JSON格式的气候数据，用脚本把数据导入MySQL或直接存成Parquet文件交给Spark处理。存储上我推荐默认Parquet，因为它列式存储、压缩比高，Spark读起来比CSV快得多。数据处理层就是Spark的主场，完成缺失值填补、异常值剔除、归一化、时间序列窗口切分，最后把处理好的数据输出成训练集和测试集。模型层在PyTorch里训练LSTM，保存成模型文件，Flask启动时加载这个文件来做实时预测。应用层则负责接收前端请求、调用模型、返回结果，同时展示历史数据曲线和预测结果。

这里有一个重要经验：不要试图把所有逻辑全塞进Spark或全塞进Flask。比如有人在Flask里直接做Pandas预处理，数据量一大接口就卡死；也有人试图让Spark在每次请求时重新跑一遍全量统计，完全是自找麻烦。正确的做法是Spark只做离线计算，算完的结果落到数据库或文件里，Flask只读结果，最多在请求时按参数做一次轻量过滤。

2. 核心细节解析与实操要点

2.1 Spark环境搭建：本地运行还是搭建集群是个关键抉择

很多学生在Spark环境上栽跟头，根源是他们一上来就想搭一个三节点的集群，又是配虚拟机又是折腾网络，结果花了两三周，代码一行没写。实话说，毕设项目并不需要真的集群——你需要的是在答辩时说清楚“系统具备分布式扩展能力”。

我推荐的方案有两种。如果电脑内存在16G以上，优先用Spark local模式，把spark.executor.memory设到4G到8G，数据量在几百万到几千万条级别时，local模式完全跑得动。如果想显得更“正规”一点，可以用Docker在单机上起一个Spark Standalone集群，一个master一个worker，然后用spark://master:7077提交任务。这套方案的好处是你在答辩时能理直气壮地说“系统基于Spark Standalone集群运行”，而且Docker配置到能提交任务只需要小半天。

需要特别注意Windows下Spark的hadoop环境变量问题。Spark依赖Hadoop的WinUtils，在Windows上如果不配置HADOOP_HOME并提供winutils.exe和hadoop.dll，一启动就会报“Could not locate executable null\bin\winutils.exe”的错。这个问题卡了我当时整整一个晚上，后来直接在GitHub上找到对应版本下载并配置好环境变量才算通过。如果你是Mac或Linux，就不需要考虑这个。

2.2 气候数据预处理：脏数据与缺失值的处理思路

气候数据看起来规整，实际脏得很。常见的问题包括：时间戳格式不统一（有的站点用2024-01-01，有的用20240101）、温度字段出现999这种默认缺测值、同一站点同一天有多条重复记录、相对湿度超过100的明显异常值，等等。

处理逻辑上，我建议在Spark阶段按顺序做四件事。第一步是全量探查，打印出每个字段的计数、均值、最大最小值，先用肉眼判断哪些字段不可信；第二步是格式归一，把时间戳统一转成yyyy-MM-dd，并提取年、月、日、季节等衍生特征；第三步是清理异常值，对温度、湿度、气压这类字段设定合理区间，超出区间直接剔除或用插值填充；第四步是缺失值处理，如果某天的记录整体缺失，按前后两天均值做线性插值，如果连续缺失超过7天，干脆把这一段从训练集里剔掉，避免LSTM学到伪规律。

这里有个细节值得讲：归一化必须放在切分训练集和测试集之后分别进行，或者用训练集的极值统一归一化。很多学生先对全量数据做MinMaxScaler，再切分，这在时间序列预测里属于信息泄漏，会让测试集的评估结果虚高。正确流程是先用训练集拟合scaler，然后同样用这个scaler去转换测试集。

2.3 LSTM模型设计：序列长度与特征工程的配合

气候数据做LSTM预测，本质上是一个多变量时间序列预测问题。输入是过去N天的温度、湿度、气压、降水量等多个特征，输出是未来M天的温度或降水概率。这里面最关键的参数就是时间窗口长度N——到底用过去多少天来预测未来。

我测试下来，用过去30天预测未来7天是一个比较稳妥的默认配置。窗口太长（比如90天）会导致训练数据量骤减，窗口太短（比如7天）又不足以让模型捕捉到气候变化的周期。你可以把窗口长度做成一个配置参数，在答辩时展示不同窗口长度对预测精度的影响对比实验——这种对比是加分项，说明你理解模型调优而不只是跑通代码。

特征工程上，除了原始的数值字段，建议额外增加两类特征。一类是时间类特征：一年中的第几天、是否是夏季、是否是雨季，这些都是周期性特征，能帮LSTM理解气候的季节节律；另一类是滞后特征：前一天的温度变化量、近七天平均温度等。滞后特征在时间序列预测里效果非常明显，哪怕不加任何复杂算法，只看前一天的温差变化也能预测大趋势。

LSTM的网络结构不要复杂。我当时用的是两层LSTM，隐藏维度64，接一个全连接层输出未来7天的预测值。训练时用MSELoss，Adam优化器，初始学习率0.001，训练50个epoch，加上早停机制——验证集损失连续5个epoch不降就停止。这个配置训练时间短、不容易过拟合，而且指标上已经能达到不错的RMSE。

2.4 Flask接口设计：如何让模型与前后台顺畅对话

Flask在系统里的角色是Web服务层。套壳最容易犯的错误是把PyTorch模型加载、数据预处理、后处理全部写在一个路由函数里，这样每次请求都会重新加载模型或者反复初始化变量，性能差且容易出错。

推荐的做法是把模型加载放到模块导入阶段，在全局创建一个model对象和一个scaler对象，Flask进程启动时加载一次，之后所有请求复用。预测路由/api/predict只需要接收前端的参数（比如城市、预测天数），在函数内部构造输入序列、调用模型、返回预测结果。整个过程应该控制在几百毫秒以内。

接口设计上，至少包含三组路由：/api/history?city=xxx返回某城市的历史气温数据，用于前端画折线图；/api/predict?city=xxx&days=7返回未来N天的预测结果；/api/summary返回全量数据的统计分析摘要，比如多年平均温度、最高温度、降水总量等。每组的返回格式统一为JSON，键名一致，这样前端做起数据解析来会很顺手。

还有跨域问题，如果你的前端是独立Vue或纯HTML页面，需要安装flask-cors，在初始化时CORS(app)，否则浏览器会拦截接口请求。这个坑我见得太多了，后端接口明明数据没错，前端就是拿不到。

3. 实操过程与核心环节实现

3.1 数据接入层：用PySpark完成数据清洗与特征提取

我用的是近10年国内某城市逐日气象数据，CSV格式，大概30多万行。这个数据量其实不需要分布式，但用Spark处理它能充分展示技术点，而且代码框架可以直接切换到大集群。

数据清洗的PySpark核心逻辑是这样组织的：

from pyspark.sql import SparkSession from pyspark.sql.functions import col, when, to_date, year, month, dayofmonth, avg spark = SparkSession.builder \ .appName("ClimateDataProcess") \ .config("spark.executor.memory", "4g") \ .getOrCreate() df = spark.read.option("header", True).csv("hdfs:///data/climate/*.csv") # 格式转换与异常过滤 df = df.withColumn("date", to_date(col("date"), "yyyy-MM-dd")) \ .withColumn("temp", col("temp").cast("double")) \ .withColumn("humidity", col("humidity").cast("double")) \ .filter(col("temp").between(-30, 50)) \ .filter(col("humidity").between(5, 100)) # 剔除同一日期的重复记录（保留第一条） df = df.dropDuplicates(["city", "date"]) # 缺失值用前后两天平均温度插值（先按城市分区排序） from pyspark.sql.window import Window w = Window.partitionBy("city").orderBy("date") df = df.withColumn("temp_prev", avg(col("temp")).over(w.rowsBetween(-2, -1))) \ .withColumn("temp_next", avg(col("temp")).over(w.rowsBetween(1, 2))) df = df.withColumn("temp", when(col("temp").isNull(), (col("temp_prev") + col("temp_next")) / 2) .otherwise(col("temp"))) # 时间特征 df = df.withColumn("year", year(col("date"))) \ .withColumn("month", month(col("date"))) \ .withColumn("day", dayofmonth(col("date"))) \ .withColumn("day_of_year", dayofyear(col("date"))) df.write.mode("overwrite").parquet("hdfs:///data/climate_clean")

这段代码你要在答辩时能逐行解释。比如为什么要用窗口计算前后两天的均值来插值，因为气候数据的局部相关性很强，前后的值比全局均值更有参考意义；为什么要把温度限定在[-30, 50]区间，因为正常的逐日平均气温不会超出这个范围，超出基本就是传感器异常。

3.2 模型训练：LSTM的完整实现与参数调整

数据处理完成后，把Parquet里的数据导出成Pandas DataFrame，按城市分组、按日期排序，然后做窗口切分。这里有一个容易搞错的地方：不能把所有城市混在一起随机切分，应该每个城市都保留时间顺序，按前后时间划分训练集和验证集。

我写过一份比较清爽的LSTM训练脚本，核心结构如下：

import torch import torch.nn as nn from sklearn.preprocessing import MinMaxScaler from sklearn.model_selection import train_test_split import numpy as np class ClimateLSTM(nn.Module): def __init__(self, input_size, hidden_size, num_layers, output_size): super().__init__() self.lstm = nn.LSTM(input_size, hidden_size, num_layers, batch_first=True) self.fc = nn.Linear(hidden_size, output_size) def forward(self, x): out, _ = self.lstm(x) out = out[:, -1, :] # 取最后一个时间步的输出 return self.fc(out) # 构造时间序列样本 def create_sequences(data, seq_len=30, pred_len=7): X, y = [], [] for i in range(len(data) - seq_len - pred_len + 1): X.append(data[i:i+seq_len, :]) y.append(data[i+seq_len:i+seq_len+pred_len, 0]) # 预测温度 return np.array(X), np.array(y) # 特征：温度、湿度、气压、风速、日序 feature_cols = ['temp', 'humidity', 'pressure', 'wind_speed', 'day_of_year'] data = df[feature_cols].values scaler = MinMaxScaler() data_scaled = scaler.fit_transform(data) X, y = create_sequences(data_scaled, seq_len=30, pred_len=7) X_train, X_val, y_train, y_val = train_test_split(X, y, test_size=0.2, shuffle=False) # 转成PyTorch张量 X_train = torch.tensor(X_train, dtype=torch.float32) y_train = torch.tensor(y_train, dtype=torch.float32) model = ClimateLSTM(input_size=5, hidden_size=64, num_layers=2, output_size=7) criterion = nn.MSELoss() optimizer = torch.optim.Adam(model.parameters(), lr=0.001) for epoch in range(50): model.train() optimizer.zero_grad() output = model(X_train) loss = criterion(output, y_train) loss.backward() optimizer.step() if (epoch+1) % 10 == 0: print(f"Epoch {epoch+1}, Loss: {loss.item():.6f}")

说几个实操中的调整细节。第一，train_test_split必须设置shuffle=False，时间序列数据一旦打乱顺序，模型就学到不时间依赖关系了，这是初学者最容易犯的错。第二，num_layers=2不是固定的，数据量小的话一层就够，两层反而容易过拟合；如果你发现验证集损失远高于训练集损失，优先尝试减小层数而不是加Dropout。第三，output_size=7表示一次输出未来7天的温度预测，相当于把多步预测一次性输出，比逐日递归预测稳定得多。

训练完成后保存模型和scaler：

torch.save(model.state_dict(), "climate_lstm.pth") # 同时保存scaler的参数，Flask端要拿它做数据转换 import json with open("scaler_params.json", "w") as f: json.dump({"scale": scaler.scale_.tolist(), "min": scaler.min_.tolist()}, f)

3.3 服务层：Flask路由与异步调度设计

Flask服务的结构我建议拆成三个文件：app.py负责路由与请求处理，model_service.py负责模型加载和预测逻辑，data_service.py负责从数据库或Parquet结果文件读取历史统计数据。这样拆分的好处是答辩时你能说“系统采用模块化设计”，而且实际调试维护也方便。

model_service.py里最关键的是模型加载和预测函数：

import torch import numpy as np from model import ClimateLSTM class ModelService: def __init__(self, model_path, scaler_path): self.model = ClimateLSTM(input_size=5, hidden_size=64, num_layers=2, output_size=7) self.model.load_state_dict(torch.load(model_path, map_location="cpu")) self.model.eval() # 加载scaler参数并重建 ... def predict(self, recent_data): # recent_data: 最近30天的特征序列 input_seq = torch.tensor(recent_data, dtype=torch.float32).unsqueeze(0) with torch.no_grad(): pred = self.model(input_seq).numpy()[0] # 反归一化还原温度值 pred_temp = pred * self.scale[0] + self.min[0] return pred_temp.tolist()

很多人会忽略model.eval()这一步。训练模式下模型会计算梯度、启用Dropout，预测时如果不切换到eval模式，结果会有随机性，而且速度慢。一句话，eval()是预测的基本素养。

Flask主路由Demo如下：

from flask import Flask, request, jsonify from flask_cors import CORS from model_service import ModelService app = Flask(__name__) CORS(app) service = ModelService("climate_lstm.pth", "scaler_params.json") @app.route("/api/predict", methods=["GET"]) def predict(): city = request.args.get("city", "北京") days = int(request.args.get("days", 7)) recent = load_recent_data(city, 30) # 从数据库/Parquet取最近30天数据 if recent is None: return jsonify({"code": 404, "msg": "城市数据不存在"}), 404 result = service.predict(recent) return jsonify({"code": 200, "city": city, "predictions": result}) @app.route("/api/history", methods=["GET"]) def history(): city = request.args.get("city", "北京") df = load_history_data(city) return jsonify({"code": 200, "data": df.to_dict(orient="records")}) if __name__ == "__main__": app.run(host="0.0.0.0", port=5000, debug=False)

注意生产运行不要开debug，调试时开着方便看异常栈，但要提交演示或部署时务必关掉，否则Web服务会暴露交互式调试器，而且性能很差。

3.4 可视化展示：用ECharts把数据和预测结果讲清楚

前端展示是这个项目的“面子”。评委看你的系统，第一印象就是页面效果。我建议做一个简单的数据大屏，不要求复杂炫酷，但要把三个核心信息展示出来：历史气候趋势、未来天气预测、整体统计摘要。

历史趋势用折线图，横轴是日期，纵轴是温度，可以叠加多年数据看年度周期性变化。预测结果同样用折线图，但颜色区分开，历史数据用浅色、预测数据用亮色，并在图上标注一个竖线分界点，告诉评委“竖线左边是真实数据，右边是LSTM预测的未来温度”。这个对比展示是答辩时最有说服力的画面。

统计摘要可以放三到四个数字卡片：平均气温、最高气温、年降水量、极端天气天数等，数据在Spark阶段算好，存入MySQL，Flask接口返回给前端。另外也可以加一个简单的城市切换下拉框，实时刷新不同城市的数据和预测结果。

前端代码不需要框架，一个HTML页面加原生JavaScript和ECharts CDN就够了。核心逻辑是页面加载时用fetch("/api/history?city=北京")拿历史数据，用fetch("/api/predict?city=北京&days=7")拿预测数据，然后塞给ECharts的setOption。如果答辩时间紧张，这个方案能在两天内搞定前端。

4. 常见问题与排查技巧实录

4.1 Spark任务OOM：光加内存是不够的

Spark跑气候数据时最典型的问题是OOM。我见过两种场景：一种是读取多个城市多年份数据，默认分区数太少导致单分区数据量过大；另一种是collect()把所有数据拉回Driver，内存瞬间爆掉。

解法分两步。首先，读取大文件后可以显式增加分区：

df = df.repartition(100) # 或 spark.sql("SET spark.sql.shuffle.partitions=100")

repartition会做一次全量shuffle，如果只是想在读取阶段分散压力，用coalesce更合适——它是窄依赖，不触发全量重分区，性能好得多。其次，不要动不动就collect()，能用df.select(...).write.parquet(...)输出结果的，就不要把数据全部拉回本地。如果确实要看样例，用df.limit(20).toPandas()，至少不会把几亿条数据一次性吞到内存。

Spark executor内存参数上，本地模式建议spark.executor.memory=6g、spark.driver.memory=4g。如果还是OOM，优先检查是不是代码里的groupBy或join产生了数据倾斜——比如某个城市的数据量特别大，reduce阶段就卡死。给个简单的缓解办法：对倾斜的key加随机前缀打散。

4.2 LSTM预测结果偏差大：先检查数据而不是疯狂调模型

我见过太多学生一看到预测不准就加网络层数、调学习率、换优化器，但其实问题往往不在模型。预测偏差的常见根源有三类。

第一类是数据泄漏，训练集和测试集混用了归一化参数，导致测试集看起来精度很高，实际上没有任何参考价值。第二类是窗口长度不匹配，训练时序列长度是30天，预测时却只给最近7天数据，模型输入维度对不上，输出的结果自然离谱。第三类是天气数据的剧烈波动，某些城市的温度日较差很大，模型预测的是均值趋势，天然会“钝化”——它很难预报极端天气，这是LSTM的特性，不是bug。

实际操作时，先画一张模型在验证集上的预测值和真实值对比曲线。如果曲线整体拟合不错，只是峰值处对不上，说明模型泛化能力正常，答辩时如实说明即可；如果整条曲线滞后一天——预测值相对真实值“平移”了一个时间步，那基本上属于特征不够，把滞后特征（前一天温度变化量）加进去就能缓解。

4.3 Flask加载模型报错：路径、版本、线程安全一个都别漏

Flask端最闹心的坑是模型加载问题。第一个高频问题是相对路径失效。因为app.py可能从不同目录启动，torch.load("climate_lstm.pth")会找不到文件。建议用os.path.join(os.path.dirname(__file__), "models/climate_lstm.pth")来定位，确保无论从哪里启动都能加载到。

第二个高频问题是PyTorch版本不一致，训练时用GPU版的PyTorch 2.0，到Flask服务器上装了CPU版的1.8，load_state_dict之后模型结构对不上直接报错。解决方案是加载时指定map_location="cpu"，部署环境统一用pip freeze锁定版本。

第三个问题是多线程预测的稳定性。默认Flask开发服务器是多线程的，多个请求同时进来时，如果模型不是线程安全的，预测结果会偶发异常。解决方法是给预测逻辑加一个线程锁：

import threading infer_lock = threading.Lock() def predict_safe(data): with infer_lock: return service.predict(data)

要注意的是加锁会略微降低并发性能，但毕设场景下完全够用，而且能避免很多难以排查的随机错误。面试答辩时被问到“系统并发性能如何”，你也可以解释锁的取舍逻辑，反而显得考虑周全。

4.4 答辩高频问题与应对思路整理

做技术项目最怕答辩时被问到没准备过的问题。我结合评审老师一贯的关注点，整理了几个必问方向。

数据来源与真实性是最常问的。你要能说出数据集的确切来源、时间跨度、字段含义、数据量级别，以及你做了哪些清洗处理。自己手工造的假数据也能跑通系统，但根基不稳，一问就穿帮。

架构设计上，评委常问“为什么前后端不分离”“为什么用Spark而不是只用Pandas”“为什么用LSTM而不是ARIMA”。前一个问题答“项目规模适中，Flask直接渲染前端满足需求，减少了开发复杂度”；中间一个答“系统设计面向海量数据场景，Spark具备分布式扩展能力，Pandas处理亿级数据时内存受限”；后一个答“LSTM能捕捉长期依赖，气候数据有明显的季节性和周期性，LSTM的自动特征提取能力优于传统统计方法”。这三个答案是整套系统的技术合理性支撑，要背到张口就来。

模型评估上，一定要有自己的评估结果。提前算好RMSE、MAE、R²，并准备一个真实案例：某城市未来7天温度预测的RMSE是2.3度，在气候预测中处于什么水平。能主动聊模型局限性的学生，往往比只会说“效果很好”的学生得分更高。

我的建议是，答辩前把系统从数据到展示完整跑一遍演示，确认每个接口有返回值，每个图表有数据，再准备一张架构图、一张时序图、三张以上效果截图。演示出bug是最伤分的，宁可视频录好再放，也不要在现场翻车。

5. 一些额外的经验：项目做完了，还能怎么扩展加分

这个项目做到这里已经是一个完整可演示的毕设了。如果你还有精力，我建议做两个扩展，成本低、效果好。

第一个扩展是把离线预测改成定时更新。用APScheduler在Flask里定时跑一个任务，每天凌晨把最新的气象数据拉取进来，重新调用Spark批处理、重新训练LSTM，然后刷新数据库里的预测结果。加上这个功能后，你的系统就变成了“准实时更新”，这在答辩里是一个很好的亮点。

第二个扩展是做模型对比实验。同样一份数据，分别用ARIMA、线性回归、LSTM做预测，把三个模型的RMSE画在一张表里。不用写太多代码，sklearn和statsmodels几行就能跑出结果。答辩时摆出这张对比表和一句话“LSTM在短期气温预测上的RMSE比ARIMA低约30%，说明其更适合处理非线性时序特征”，这个分量比任何客套话都重。

根据我的经验，做完这些扩展，你的毕设已经从“能过”变成了“优秀”的区间。这个项目也不仅仅是一个毕设，它本质上是一个完整的数据分析系统——数据采集、分布式计算、深度学习、API服务、可视化一应俱全，这些能力在之后写简历、面试、做更复杂系统的时候，都会反复用到。遇到问题就去查日志，不要怀疑是环境问题而反复重装；大多数坑都出在数据格式、路径、版本、指标这些细节上。祝你顺利完成。