企业官网建设流程全解析

简介：这是一份面向大数据初学者的课程设计项目，以交通拥堵预测为场景，适合用于毕业设计、课程作业或工程实训。项目整体思路清晰：无现成数据时，用Kafka自主模拟生产交通数据，经消费与预处理后存入Redis等非关系型数据库，再从Redis读取数据进行建模，生成的模型保存至HDFS，待预测时加载HDFS上的模型完成结果输出，完整覆盖数据生产、存储、建模与预测全流程。压缩包共31个文件，大小约60KB，主要由Scala源码、XML配置、Properties配置文件以及工程说明文档组成，源码精简无冗余；包内包含tf_producer、tf_consumer、tf_modeling、tf_prediction四个核心模块，分别对应数据模拟、数据消费与存储、模型训练和预测应用。已有177人参与学习，通过该项目可掌握Kafka模拟数据、Redis读写、Spark建模及HDFS模型管理等关键技术，是理解大数据与非关系型数据库结合应用的实用参考。

1. 交通拥堵预测为什么绕不开非关系型数据库

交通拥堵预测这个课程设计，很多人一开始就往深度学习上想，但真正的门槛往往不在模型精度，而在数据进得来、存得下、查得快。一辆网约车每5秒上报一次GPS轨迹，一座城市一天能产生上亿条位置记录，带经纬度、时间戳、速度、方向，天然是半结构化形态。用关系型数据库存，建表难、扩展难、写压一上来就卡；用分布式文件系统裸存，查询又慢得没法做特征提取。非关系型数据库在这条链路上的位置，是用文档模型直接承载轨迹和路况快照，用水平扩展扛住写入，用索引和聚合管道把原始数据快速加工成训练集。这篇文章说清楚选型、建表建索引、特征工程和避坑，最后落到怎么让题目在答辩中真正出彩。适合正在做大数据方向课程设计、实习项目，或者第一次接触非关系型数据库落地场景的同学。

2. 选型定生死：MongoDB、HBase还是Redis

2.1 交通轨迹数据的三个特性决定选型方向

交通拥堵预测的原始数据，核心就是车辆的轨迹点。它在落地时表现出三个很强的特性，直接决定数据库选型方向。

第一，写入频率极高。假设一个城市有1万辆网约车参与数据采集，按5秒上报一次计算，每秒钟就有2000条写入。这个写入压力单独看并不算恐怖，但架不住是持续性的，而且早晚高峰时段会上浮到平时的3倍以上。关系型数据库在这个量级下，磁盘I/O和锁竞争会先成为瓶颈；课程设计里如果用了单机MySQL，插入速度会肉眼可见地变慢，甚至拖垮后续查询。

第二，数据结构高度半标准化。一条轨迹点包含车号、经纬度、速度、方向角、时间戳，不同数据源的字段命名还不一样。有的带海拔，有的不带；有的速度单位是km/h，有的是m/s。这种差异用关系型数据库建模，要么事先定死所有字段再加一大堆空列，要么做成宽表，维护成本极高。非关系型数据库的文档模型，天然允许同集合内不同文档有不同字段结构，这条容错能力对课程设计实在太友好了。

第三，查询模式以时间-空间切片为主。做特征工程时，你经常要回答“某条路最近30分钟的通过速度是多少”“某个区域8点到9点之间平均拥堵指数怎么变”这类问题。这种查询既要按时间范围过滤，又要按空间或路段过滤，是典型的“二维切片”。MongoDB的地理空间索引加上普通复合索引，正好覆盖这类需求。

这三点叠加在一起，实际上已经帮我们排除了大部分选项。Redis虽然快，但它的主要优势是单键读写和简单数据结构，做复杂的聚合统计要拉数据到应用层算，不划算。HBase强在写吞吐，但在查询灵活性上吃亏，后面第2.3小节专门展开说。所以我的结论是：课程设计主存储选MongoDB，这是当前最平衡的方案。

2.2 用Docker把MongoDB单节点环境跑起来

环境搭建最省心的方案是Docker。一个单节点的MongoDB足够跑整个项目，不需要申请云资源，也不用在几台机器之间配网络。我习惯用docker-compose管理，方便换电脑之后一键恢复环境。

# docker-compose.yml version: '3.8' services: mongo: image: mongo:6.0 container_name: traffic-mongo ports: - "27017:27017" restart: always volumes: - ./data/db:/data/db

这段配置有几个关键点。volumes把容器内的数据目录挂载到宿主机，否则容器一删数据就全部消失，属于课程设计里容易翻车的低级错误。image固定成mongo:6.0而不是latest，避免过一段时间后拉到的版本跟你写的代码不兼容。端口默认27017，如果本机已经占用，改成27018，但后面所有连接串要一起改。

启动之后，验证连通性：

docker exec -it traffic-mongo mongosh --eval "db.runCommand({ping:1})"

如果返回{ ok: 1 }，说明实例已经正常监听。这一步跑通之后，再用pymongo连接时就不会出现网络层面的杂音。值得多说一句：课程设计的书写上，用docker-compose能体现“可复现部署”，比直接写“安装MongoDB”显得更专业。

2.3 HBase什么时候才值得换

如果导师指定了HBase，或者你觉得“大数据”课程设计不用HBase体现不出分量，那你要清楚付出什么代价。

HBase的数据访问模式非常依赖RowKey设计。为了支撑“查某条路最近N个时间窗口”这种高频查询，通常会把RowKey设计成“road_id + 时间戳倒序”，让同一路段的记录在物理存储上相邻。这样做能扛住高并发写入和按前缀扫描，但代价是：你想按“区域+时间段”做条件过滤时，会发现RowKey前缀对不上，得再做二级索引或者全表扫描。

MongoDB的灵活性在于查询条件不是绑定存储布局的。你可以在road_id上建普通索引，在timestamp上建普通索引，或者在两者组合上建复合索引，查询时按需组合$match条件。聚合管道还支持分组、排序、拉平嵌套数组，这些能力对特征工程阶段尤为重要。

HBase的优势场景是数据量达到几十亿行，写入速度成为主要矛盾。但课程设计的数据量通常是几十万到几百万条，单节点MongoDB完全扛得住。所以我一般建议别为了技术栈的“高级感”牺牲开发效率。

提示：如果实在想展示HBase，可以把轨迹原始数据转存一份到HBase做冷备，日常特征计算仍然走MongoDB。这样两者都用了，但核心链路不被拖累。

3. 数据模型设计：把车辆轨迹和路段状态装进文档

3.1 三个核心集合的职责划分与文档结构

数据模型设计是MongoDB项目里最值得花时间的一步。设计得好，后面的聚合、索引、模型训练都顺；设计得草率，每写一个查询都在补坑。

我的做法是拆成三个集合，让每一层数据各司其职。第一个是trajectory，存原始轨迹点，是数据接入的入口；第二个是road_state，存按5分钟窗口聚合后的路段快照，是特征工程的结果；第三个是prediction_result，存模型预测输出，供前端展示和事后分析。

// trajectory 集合中的一条文档 { "vehicle_id": "T-1024", "timestamp": "2024-05-12T08:30:15Z", "loc": {"type": "Point", "coordinates": [116.4074, 39.9042]}, "speed": 32.5, "heading": 128, "road_id": "R-2088", "day_type": "workday" }

这里有几个设计细节需要解释。timestamp存成ISO 8601字符串而不是Unix时间戳，原因是MongoDB查询时字符串和日期可以互相转换，而ISO格式在MongoDB Compass里直接可读，调试时不用先算一遍毫秒数。loc用GeoJSON格式而不用两个普通字段lon和lat，因为GeoJSON能直接建立2dsphere索引，后续做空间范围查询时不需要自己写多边形判断。speed统一为km/h，保证后面统计时不用再做单位换算。

再看road_state集合：

{ "road_id": "R-2088", "window_start": "2024-05-12T08:30:00", "window_end": "2024-05-12T08:35:00", "avg_speed": 28.6, "std_speed": 3.2, "sample_count": 215, "congestion_level": 2 }

window_start和window_end是时间窗口的边界，sample_count代表这个5分钟窗口内有多少个轨迹点参与统计。这个字段非常重要，如果采样量太少，比如只有两三个点，算出来的平均速度不具备统计意义，后面做模型时要么剔除要么降权。congestion_level可以按业界常用的速度阈值划分，比如低于15km/h为严重拥堵，15到25为拥堵，25到40为缓行，高于40为畅通，映射成0到4的等级。

3.2 索引设计：复合索引和空间索引怎么选

集合建好了，索引不跟上就是给自己埋雷。MongoDB在没有索引时做查询是COLLSCAN全表扫描，数据量到百万级别，单次聚合可能耗时十秒以上，答辩演示时会非常尴尬。

我常用的索引组合是这样的：

// 轨迹集合：按时间范围过滤 db.trajectory.createIndex({ "timestamp": 1 }) // 轨迹集合：按车辆查一天轨迹 db.trajectory.createIndex({ "vehicle_id": 1, "timestamp": -1 }) // 轨迹集合：空间索引，做经纬度范围查询 db.trajectory.createIndex({ "loc": "2dsphere" }) // 路况快照：按路段和时间窗口查询 db.road_state.createIndex({ "road_id": 1, "window_start": -1 }) // 预测结果：按路段查询预测序列 db.prediction_result.createIndex({ "road_id": 1, "window_start": -1 })

这段脚本要说明三点。

第一，timestamp单字段索引是基础，因为大多数聚合管道的第一个$match都会卡时间范围，没有这个索引，后面的聚合优化做得再好也没用。

第二，vehicle_id + timestamp是复合索引，服务“查某辆车某段时间轨迹”的场景。如果你的数据源没有按车辆查询的需求，这个索引可以不建，避免浪费存储和写入开销。索引不是越多越好，尤其是持续写入场景，每多一个索引，写入时就要多维护一份数据结构。

第三，road_id + window_start是特征工程阶段最核心的索引，它的设计原则是最左前缀匹配。road_id放前面，window_start放后面，这样无论只按道路查，还是按道路加时间范围查，都能命中索引。

索引建完后，一定要验证执行计划。用explain("executionStats")看stage是不是IXSCAN，docsExamined是否远小于集合总文档数。这一步能避免“以为有索引结果没走”的坑。

3.3 数据过期策略：TTL索引的正确用法

课程设计的数据量虽然不会到海量级别，但如果你反复跑实验，trajectory集合会越积越多。原始轨迹点只用于生成特征，一旦特征算完，它就没有保留价值了。MongoDB有个特性叫TTL索引，可以在字段值超过指定秒数后自动删除文档，不需要写定时清理脚本。

// 轨迹数据只保留7天 db.trajectory.createIndex( { "timestamp": 1 }, { expireAfterSeconds: 604800 } )

注意，TTL索引有几个限制。它只能建在单字段上，不能建在复合索引字段上。也就是说，你不能同时用{vehicle_id: 1, timestamp: 1}做查询索引，又指望它带TTL过期能力，这两个需求要拆成两个索引。另外，TTL后台清理线程每60秒运行一次，所以删除并不是实时的，过期文档最多延迟一分钟左右被物理清除。在撰写设计文档时，这个延迟要写清楚，避免答辩时被追问细节。

另一个细节是，expireAfterSeconds是从字段值算起的。如果你把timestamp误存成字符串，TTL不会生效，它必须存成Date类型。ISO字符串虽然可读性好，但也有这一层风险，所以更稳的做法是存成new Date()，或者存字符串的同时再维护一个ts_date字段来支撑TTL和索引。

4. 用MongoDB聚合管道把原始轨迹变成训练集

4.1 清洗和去重：管道第一层的match条件

拿到原始GPS轨迹后，直接做聚合会得到很多脏结论。GPS数据常见的脏点有几类：经纬度漂移到道路范围外、瞬时速度突变到物理不可能的值、车辆在车库或停车场内原地抖动产生的小范围轨迹。清洗的逻辑实现我一般直接放在聚合管道的第一步，而不是写一个独立的清洗程序，这样整个数据处理流程都在MongoDB内部完成，演示起来更直观。

const pipeline = [ { $match: { timestamp: { $gte: startTime, $lt: endTime }, speed: { $gte: 0, $lte: 80 }, "loc.coordinates.0": { $gte: 115.5, $lte: 117.5 }, "loc.coordinates.1": { $gte: 39.0, $lte: 41.0 } } } ]

这个$match做了四件事。时间范围过滤，速度范围过滤，经纬度矩形范围过滤。速度上限80是城市道路的保守阈值，如果数据源包含快速路或高速路段，可以放宽到100甚至120，但课程设计通常以城市路网为主，80更安全。经纬度的矩形范围按你所在城市设定，这里用的示例范围是北京，换城市就改这四个数，逻辑完全一样。注意coordinates.0和coordinates.1分别对应GeoJSON数组里的经度和纬度。

去重方面，主要避免同一辆车同一时刻上报了重复轨迹点。数据结构本身没有唯一键，所以需要先做一层分组去重：

{ $group: { _id: { vehicle_id: "$vehicle_id", timestamp: "$timestamp" }, doc: { $first: "$$ROOT" } } }

用$$ROOT保留原始文档，按“车号+时间戳”去重后取第一条。这样做会把重复点过滤掉，但代价是聚合管道多了一个分组阶段，内存消耗增大。如果确认数据源没有重复，这步可以省掉。如果保留这步，建议把分组结果$replaceRoot还原成原文档结构，方便后续管道继续处理。

4.2 滑动窗口统计：按路段输出5分钟路况快照

清洗之后，核心任务是把轨迹点聚合成路况快照。我使用的窗口是5分钟，按road_id分组，对速度求均值和标准差。

const windowSeconds = 300; const pipeline = [ { $match: { timestamp: { $gte: startTime, $lt: endTime } } }, { $group: { _id: { road_id: "$road_id", window_start: { $trunc: { $divide: [ { $toLong: "$timestamp" }, windowSeconds * 1000 ] } } }, avg_speed: { $avg: "$speed" }, std_speed: { $stdDevPop: "$speed" }, sample_count: { $sum: 1 }, } }, { $project: { _id: 0, road_id: "$_id.road_id", window_start: { $toDate: { $multiply: ["$_id.window_start", windowSeconds * 1000] } }, avg_speed: 1, std_speed: 1, sample_count: 1 } }, { $out: "road_state" } ]

这一段是特征工程的第一个关键步骤。它的逻辑是，把每条轨迹的时间戳转成长整型毫秒，除以300秒的窗口长度后向下取整，再乘回去，就得到这个点所属窗口的起始时间。比如08:30:15会落在08:30:00这个窗口，08:31:50也会落在这个窗口。

第28行的$stdDevPop是总体标准差，它反映窗口内速度的离散程度。如果某条路上同时有飞驰的车和堵死的车，平均速度看起来可能还在缓行区间，但标准差会很大，这个字段可以作为拥堵程度的辅助判断指标。sample_count则是统计可信度的保障。

最后用$out把结果写进road_state集合，这个操作的好处是重跑管道时会自动覆盖目标集合，相当于给数据处理留了后悔药。如果你在开发过程中发现清洗规则要调整，改完管道重跑一遍就行，不用手动清理脏数据。

4.3 滞后窗口和周期特征拼接

聚集出了当前窗口的avg_speed，下一步就要构造模型需要的特征。交通拥堵预测里最有用的特征通常是过去N个窗口的平均速度，即滞后序列。比如要预测未来5分钟某路段的速度，过去15分钟里每5分钟一个窗口，就有3个滞后值。这些滞后特征需要把同一个road_id的多个窗口横向拼起来，我的做法是用$lookup自关联。

const pipeline = [ { $match: { road_id: "R-2088" } }, { $sort: { window_start: 1 } }, { $lookup: { from: "road_state", let: { roadId: "$road_id", t: "$window_start" }, pipeline: [ { $match: { $expr: { $and: [ { $eq: ["$road_id", "$$roadId"] }, { $lt: ["$window_start", "$$t"] }, { $gte: [ "$window_start", { $subtract: ["$$t", 900000] } ] } ] } } }, { $sort: { window_start: -1 } }, { $limit: 3 } ], as: "history_windows" } } ]

这里$subtract: ["$$t", 900000]是拿当前时间减去15分钟的毫秒数，也就是说，我们只取当前窗口之前15分钟内的历史窗口。$limit: 3取最近的3条，正好对应3组滞后特征。这个管道执行完，history_windows字段里会带一个数组，每个元素包含一个历史窗口的avg_speed、sample_count和window_start。

这里我建议不要在MongoDB管道里把数组展开成多列，而是把数组原样导出，在Python里做json_normalize。原因很简单：展开列意味着要在管道里写一堆$arrayElemAt表达式，管道会变得很难读，调试时也难排查。数据导出到Python之后，用pandas处理这类半结构化数组，代码会清晰得多。

4.4 最小预测模型：线性回归做baseline

特征构造完成后，训练一个能跑的baseline模型并不复杂。我通常先用线性回归打底，它能给出一个合理的误差下限，之后再上KNN或者随机森林做对比。线性回归的好处是训练快、解释性强，答辩时能说明哪些特征重要。

import pymongo import pandas as pd from sklearn.linear_model import LinearRegression from sklearn.metrics import mean_absolute_error client = pymongo.MongoClient("mongodb://localhost:27017/") db = client["traffic"] # 读取 road_state 并展开 history_windows 中的滞后特征 df = pd.DataFrame(list( db.road_state.find({"road_id": "R-2088"}).sort("window_start", 1) )) df["window_start"] = pd.to_datetime(df["window_start"]) df["hour"] = df["window_start"].dt.hour df["day_of_week"] = df["window_start"].dt.dayofweek history = df["history_windows"].apply( lambda x: pd.Series({ f"lag_{i+1}": item["avg_speed"] for i, item in enumerate(x) }) if isinstance(x, list) else pd.Series() ) df = pd.concat([df.drop("history_windows", axis=1), history], axis=1) # 特征列：滞后速度 + 周期特征 features = ["lag_1", "lag_2", "lag_3", "hour", "day_of_week"] df = df.dropna(subset=features + ["avg_speed"]) y = df["avg_speed"].shift(-1) # 预测下一个窗口 df = df.iloc[:-1] # 去掉最后一行没有标签的样本 X = df[features].values y = y.iloc[: len(df)].values split_idx = int(len(X) * 0.8) X_train, X_test = X[:split_idx], X[split_idx:] y_train, y_test = y[:split_idx], y[split_idx:] model = LinearRegression() model.fit(X_train, y_train) y_pred = model.predict(X_test) print("MAE:", mean_absolute_error(y_test, y_pred))

代码里有几个细节值得关注。pd.Series({...})把history_windows数组拆成lag_1、lag_2、lag_3三列，是按时间倒序排列的，所以第1项是最近一个历史窗口，第3项是最早的。y = df["avg_speed"].shift(-1)是把当前窗口速度作为标签的下一个窗口值，这是典型的单步预测做法，预测目标是下一个5分钟的avg_speed。dropna(subset=...)这一步很关键，如果某条记录缺少滞后特征（比如窗口数据不足），直接丢弃，否则模型会学到NaN。

跑完这个脚本，记录下MAE。之后不管换什么模型，都要和这个基线比较。如果KNN或随机森林没有显著优于线性回归，说明特征工程还需要加强，而不是模型不够高级。

5. 避坑指南：课程设计里最容易翻车的六件事

5.1 查询慢不是数据库的问题，而是没看执行计划

现象：数据量才几十万条，一个聚合管道跑起来要好几十秒，响应慢得让人想砸电脑。

原因：大部分情况是$match条件没有命中索引，或者聚合管道的第一个阶段就不是$match，导致MongoDB不得不把大量无关文档带进内存做后续处理。也有少部分是$sort没有走索引，在内存里全量排序。

解决：第一，把时间范围过滤放在管道最前面，这是最有效的裁剪手段。第二，给timestamp和road_id建索引，这里直接复用3.2小节的复合索引即可。第三，用explain("executionStats")查看每个阶段的docsExamined，如果接近集合总量，就说明过滤没有提前生效。按这三步排查，查询从几十秒压到几秒以内基本没问题。

5.2 聚合管道内存溢出：100MB上限怎么破

现象：管道跑着跑着就报错，提示Exceeded memory limit，程序直接中断。

原因：MongoDB对$group、$sort等阶段默认分配最多100MB内存。交通数据窗口聚合时，如果$group的键是road_id + window_start组合，分组数量巨大，内存很容易被打爆。

解决：第一个手段是尽早用$match裁剪数据，减少进入$group的文档量。第二个手段是开启allowDiskUse: true，让聚合引擎把中间结果临时写磁盘。这个选项在代码里可以这样加：

list(db.trajectory.aggregate(pipeline, allowDiskUse=True))

注意，allowDiskUse是允许溢出，不是鼓励滥用。如果开启后还慢，就要检查是不是$match放太晚了。另外，在课程设计文档里把“内存和磁盘的权衡”写清楚，是加分项。

5.3 时间窗口没对齐：边界毛刺怎么来的

现象：统计出来的sample_count序列呈现锯齿状，有的窗口数据特别多，有的特别少，看起来毫无规律。

原因：时间戳没有对齐到窗口起始时间。如果直接用原始时间戳做$group的分组键，那么08:30:15和08:34:50虽然都在同一条路上，但会被分到不同窗口，导致相邻窗口的样本数忽高忽低。

解决：统一用$trunc把时间戳按窗口长度对齐。我一般是在聚合管道里把时间戳先转成毫秒数，除以窗口长度后向下取整，再乘回来，保证每个时间点只会落入唯一一个窗口。这个处理看起来很小，但直接影响训练数据的质量，是我在初期踩过最深的坑之一。

5.4 脏数据拉偏平均速度：物理阈值怎么设

现象：某条道路的avg_speed突然跳到120km/h以上，或者连续几个窗口都是0，模型预测跟着一起失常。

原因：原始GPS数据里有瞬时速度尖峰。比如车辆在隧道里GPS信号丢失，重连后位置跳变，速度计算出来就是个异常值。另外，如果车辆停在路边熄火，上报的点位速度会是0，大量0值窗口会把平均速度拉到异常低。

解决：在管道的第一层$match里加物理阈值过滤。速度范围设0到80，超出这个范围的直接丢弃。对于速度为0的样本，要看它是不是真正的静止：如果sample_count很少且avg_speed为0，这个窗口我认为可以标记为不可信，后面模型训练时剔掉。还有一个处理是去除重复值：同一辆车在同一秒上报两次，只保留一次，这个在前面4.1小节已经提过。

5.5 TTL索引不生效，磁盘还是满了

现象：明明建了TTL索引，trajectory集合的文件大小却只增不减，磁盘空间告警。

原因：TTL索引只能建在单字段上。如果你把{vehicle_id: 1, timestamp: 1}建成了复合索引，再想用同样的字段加过期时间，是建不出来的。另外，如果字段存的是字符串而不是Date类型，TTL也不会触发。

解决：单独建一个{timestamp: 1}单字段索引，并设置expireAfterSeconds。字段值建议存new Date()。如果数据源是字符串格式，导入时先转换：

doc["timestamp"] = datetime.fromisoformat(doc["timestamp"].replace("Z", "+00:00"))

同时要记住，TTL清理是后台异步执行的，最长延迟60秒，设计文档里措辞要写为“分钟级延迟的自动清理”，不要写实时。

5.6 训练与推理特征不一致：最隐蔽的翻车点

现象：离线训练时模型表现还行，MAE在5以内；但到了实时预测的演示环节，预测结果明显偏离真实值，看起来像模型失效了。

原因：这是最隐蔽的一个坑。离线训练时，特征是从road_state的历史记录里计算出来的，滞后窗口、周期特征都齐全；但在线推理时，如果直接在轨迹数据进入的那一刻就触发预测，当前窗口还没有闭合，历史滞后特征的构造方式就变了。特征分布一不一致，模型自然翻车。

解决：把特征提取逻辑抽成公共函数，离线训练和在线推理共用一套。比如写一个build_windows(road_id, end_time)函数，按end_time回溯拉取过去3个窗口的window_start，离线时end_time是每个样本的时间窗起点，在线时end_time是当前时刻。保证两边的窗口对齐方式完全一致，这个血泪经验我在多个项目里反复确认有效。

6. 让课程设计出彩：实时预测链路与效果验证

6.1 用Change Streams把特征计算变成实时触发

如果能演示“数据一进来，预测立刻更新”，答辩效果会明显提升。MongoDB提供了Change Streams能力，可以监听集合的插入事件，每次来新的轨迹点就触发一次增量预测。

with db.trajectory.watch([ {"$match": {"operationType": "insert"}} ]) as stream: for change in stream: doc = change["fullDocument"] # 更新该道路的当前窗口统计 # 构造滞后特征并调用模型预测 # 结果写入 prediction_result 集合

需要注意，Change Streams只对副本集生效。启动时需要加--replSet rs0参数，连接MongoDB后执行rs.initiate()完成单节点副本集初始化。这一步容易漏，我第一次跑的时候也在这里卡了半天。

6.2 MAPE和MAE如何配合使用

效果验证方面，我会同时看MAE和MAPE。MAE是绝对误差，单位是km/h，直观但不反映相对偏差；MAPE是百分比误差，能看出预测和真实值之间的相对关系。如果一个路段的真实速度普遍偏低，MAE可能不大，但MAPE会很高，说明相对偏差严重。计算MAPE时要注意剔掉sample_count过少的窗口，因为真实速度为0时MAPE没有意义。答辩时如果能把“哪类时段的误差更高、原因是什么”讲清楚，比单纯报一个数值更能体现你对整个数据链路的理解。

最后一个习惯是，我总是会在演示脚本里预留一段“模拟GPS漂移”的数据注入逻辑。现场演示时塞一段异常点，让观众看到清洗层把它过滤掉、预测值没有跟着异常跳变。这比任何口头说明都有说服力。做这个项目的过程里我踩过的坑不算少，尤其是时间窗口对齐和特征一致性这两处，希望这篇文章能帮你绕开它们。希望你也能把这个题目做成一个数据链路完整、演示效果出色的作品，希望帮到你。

本文还有配套的精品资源，点击获取