企业官网建设流程全解析

如果你也在准备大数据方向的毕业设计，看到“物流预测系统”这类题目，第一反应多半是：把 PyFlink、PySpark、Hadoop、Hive 全塞进去，再挂上一个机器学习模型，看起来就很“全栈”。但真正动手之后会发现，这套东西的难点不在于单个框架怎么用，而在于六七个大数据组件怎么串成一条能自圆其说的数据链路。我把我做这套物流数据分析可视化与预测系统的过程完整拆开讲一遍，从 Hadoop 伪分布式搭建、Hive 数仓分层，到爬虫采集、PyFlink 实时统计、PySpark 离线分析与 LSTM/XGBoost 预测，再到可视化大屏和答辩准备，每一步的选型理由、踩坑记录和能直接复用的代码逻辑都写清楚。这篇内容适合两类人：一是选了这个题目的毕业生，想找一份能落地的“参考答案”；二是已经学过 Hadoop 基础、想看看真实项目怎么把这些组件串起来的人。你不需要是天才，只要愿意把每一步跑通，这系统就成立。

1. 先看清全局：这套物流预测系统到底在做什么

很多同学拿到的题目是“物流预测系统”，但不同学校的侧重点差别很大。有的重点是数据可视化，有的重点是机器学习算法，有的重点是实时计算。我建议你动工之前，先把系统的“能力边界”定下来：这个系统必须能回答三个问题——历史物流数据怎么分析、实时状态怎么监控、未来货量或时效怎么预测。这三个问题对应三个核心模块：数据仓库与分析、实时计算链路、预测模型。三个模块共用一个数据底座，就是 Hadoop + Hive。

1.1 系统的三个核心模块

第一个模块是数据采集与数仓。物流数据不能靠手造，必须有一个稳定来源。我用爬虫采集快递物流公开信息（运单轨迹、时效、城市路由等），加上自己构造的模拟订单数据，统一落到 HDFS，再用 Hive 分成 ODS、DWD、DWS 三层管理。为什么不用 MySQL 直接存？因为爬虫数据量大、字段乱、重复多，MySQL 存这些脏数据会让后续查询越来越慢，而 Hive 的 Schema-On-Read 特性允许先把文件扔进去，查询时再解析结构，非常适合这种“先有数据、后有结构”的场景。

第二个模块是双引擎计算。PyFlink 负责实时统计，读取 Kafka 中的物流轨迹流，实时计算在途包裹数、各城市发货量、平均中转耗时；PySpark 负责离线批量任务，对 Hive 里的历史数据做深度清洗、特征聚合，产出日/周维度的统计报表。一句话总结：PyFlink 管“现在”，PySpark 管“过去”。两者写起来都是 Python，这也是 PyFlink 和 PySpark 比 Java/Scala 版本更合适做毕设的原因——你不需要在 Python 和 Java 之间来回切换，一个语言把实时和离线全搞定。

第三个模块是机器学习预测。我做了两个预测任务：一是基于历史订单量预测未来 7 天的物流需求；二是预测单条配送线路的时效。选模型时对比了 XGBoost、随机森林和 LSTM，最终方案是树模型做基线、LSTM 做时间序列增强。预测结果写回 MySQL，可视化大屏从 MySQL 读。

1.2 既然要拿来做毕业设计，每层技术选型为什么必须是它们

有个很容易被答辩老师问住的问题：“为什么用这套组合？换成别的行不行？” 你得有能站住脚的解释。

• Hadoop：提供 HDFS 分布式存储和 YARN 资源调度。虽然伪分布式只有一个节点，但 HDFS 的容错机制、块存储原理和 YARN 的调度逻辑都是完整的，这是大数据系统的地基。
• Hive：把 HDFS 上的数据文件映射成表，用 SQL 做数据清洗和统计。对比直接用 MapReduce，Hive 的开发效率高一个数量级。对比 Spark SQL，Hive 更适合做“数仓分层管理”，因为它的元数据服务（Metastore）和分区管理更成熟。
• PySpark：离线分析的主力。虽然 Hive SQL 能做大部分统计，但复杂的特征工程（比如时间窗口滑窗、多表关联后的聚合）用 Spark DataFrame API 写起来更灵活。
• PyFlink：实时流处理的最终选择。对比 Spark Streaming，Flink 的实时性更好、状态管理更强；对比 Kafka Streams，Flink 能和 PySpark 共用 Python 技术栈。Kafka 在系统里承担的是“消息中转站”，PyFlink 作为消费方实时处理。
• Kafka：用来解耦爬虫和实时计算。爬虫采集到的轨迹数据先进 Kafka，PyFlink 再消费，这样即使爬虫端抖动，也不会把下游计算直接打崩。

这套组合的本质是：一个数据底座（Hadoop+Hive）+ 两条计算链路（Flink+Spark）+ 一个预测模块（ML/DL）+ 一个展示出口（可视化）。逻辑上是完备的，技术上每一环都有明确的不可替代性，这就够答辩用了。

2. 从零搭起：Hadoop 伪分布式搭建与 Hive 数仓设计的细节

Hadoop 环境的搭建是第一个劝退点，尤其是 Hadoop 3.x 和 Hive 3.x 的版本兼容问题。网上的教程十有八九是 2.x 的，直接套在 3.x 上会踩一堆坑。我的建议是：不要追求最新版本，选一套经过验证的版本组合。我最终用的是 Hadoop 3.1.3 + Hive 3.1.3 + Spark 3.2.1 + Flink 1.14，这四个版本组合经过大量博客验证，坑已经被填得差不多了。

2.1 伪分布式搭建的取舍

伪分布式（Pseudo-Distributed Mode）指的是所有 Hadoop 进程（NameNode、DataNode、ResourceManager、NodeManager）都跑在同一台机器上。毕设场景下这是最务实的方案，因为你不可能在答辩现场演示一个 5 节点的集群，但伪分布式保留了完整的 HDFS 读写流程和 YARN 调度流程。

搭建时有三个容易出问题的点：

1. SSH 免密登录必须配好。别用 root 用户跑 Hadoop，新建一个 hadoop 用户，配好 localhost 的免密。每次启动 start-dfs.sh 都要输入密码会让你崩溃。
2. 核心配置文件的参数要对齐。core-site.xml 里 fs.defaultFS 必须指向 namenode 的地址，hdfs-site.xml 里 dfs.replication 设置为 1（伪分布式只有一份副本），yarn-site.xml 里要配好资源调度器。我见过最离谱的报错是 Hive 连接不上 Hadoop，最后发现是 fs.defaultFS 写成了 localhost 而实际 IP 是 192.168.x.x。
3. JAVA_HOME 必须明确指定。Hadoop 3.x 启动脚本不再自动读取 /etc/profile 里的 JAVA_HOME，你需要在 hadoop-env.sh 里手写 export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64。这里注意一定用 JDK 8，JDK 11 跑 Hadoop 3.1.x 会出现莫名的 HDFS 协议问题。

搭建完成后，用hdfs dfs -mkdir /warehouse建好数据仓库根目录，然后安装 Hive。Hive 默认用 Derby 存元数据，强烈建议换成 MySQL，否则多个终端同时操作会频繁锁表。配置 hive-site.xml 里的 javax.jdo.option.ConnectionURL 指向你的 MySQL，注意加上createDatabaseIfNotExist=true参数，这样 Hive 启动时会自动建库。

2.2 Hive 分层建表：ODS/DWD/DWS/ADS

很多毕设做数仓，建表就是拍脑袋建几张，答辩老师一问数据流向就卡住。正确的做法是严格按四层来设计：

• ODS 层（原始数据层）：表结构和爬虫/模拟数据一一对应，字段名尽量与源数据一致。物流轨迹表、订单表、区域表都是 ODS 层表。这里只做存储，不做清洗。
• DWD 层（明细数据层）：对 ODS 层做清洗、脱敏、维度退化。比如把轨迹表里“已到达【上海转运中心】”这种字符串拆成城市名和中转节点类型；把订单表里的异常数据（金额为负、时间为空）过滤掉。
• DWS 层（汇总数据层）：按主题进行轻度汇总。比如按天按城市统计订单量、按线路统计平均时效。这一层是给后续分析和特征工程用的。
• ADS 层（应用数据层）：面向可视化和模型。比如大屏需要的“全国发货量 Top10 城市”“实时在途包裹数”都从这一层取。

建表时要重点考虑分区。按日期分区是物流数据的常规操作，因为查询和清洗通常以天为单位。我建表的模板一般是：

CREATE TABLE dwd_order_info ( order_id STRING, customer_id STRING, start_city STRING, end_city STRING, weight DOUBLE, order_amount DOUBLE, status STRING, create_time STRING ) PARTITIONED BY (dt STRING) STORED AS PARQUET;

为什么要用 PARQUET 而不是 TEXTFILE？因为物流数据量大，PARQUET 是列式存储，后续 Spark SQL 做特征查询时只需要读取相关列，IO 会少很多。这是一个很小的细节，但答辩时能体现出你有工程意识。

2.3 小文件合并与分区策略

Hive 用久了会有一个非常典型的问题——小文件太多。爬虫每次写入的数据量可能只有几十 MB，但会产生大量小文件，这会导致 NameNode 元数据压力大，Spark 读取时也会因为文件数过多而启动大量 Task。

解决小文件有两种常用手段。一是写入时用 Hive 的hive.merge.mapfiles=true配置自动合并；二是在 PySpark 里用repartition(col("dt"))或者coalesce(n)控制输出文件数。我当时的做法是：ODS 层写入后跑一个简单的 Spark 任务按分区合并小文件，把每个分区文件数量控制在 20 个以内。这个操作看似简单，但直接让后续 DWD 层的查询速度提升了 3 倍以上。

分区策略的另一个关键是避免过度分区。有的同学喜欢把城市也作为分区字段，结果一张表几万个分区，查询反而变慢。我的经验是：日期作为一级分区，城市等维度保留在字段里，查询时用 WHERE 过滤。只有数据量达到亿级才需要考虑二级分区。

3. 物流爬虫：数据来源与清洗的破事

做大数据毕设最尴尬的场景是：模型写好了，流程图也画好了，结果没有真实数据跑演示。物流爬虫就是解决数据来源问题的。但这一步要非常注意合规边界——只要采集公开可访问的信息、控制请求频率、不涉及个人隐私、不绕过任何访问限制，仅用于学习研究。我采集的是快递物流公司公开的运单轨迹查询接口（通过模拟单号查询），以及一些物流行业公开的数据页面。

3.1 采集什么、怎么采集更安全合规

我第一版爬虫贪多，想抓全网所有快递信息，结果被封了 IP 不说，还抓回来大量无用的 HTML 标签数据。后来收敛了采集目标，只抓三类数据：

• 运单轨迹：输入快递单号，获取“已揽收 → 到达某分拨中心 → 派送中 → 签收”的结构化轨迹。
• 网点信息：各省市快递网点的名称、编码、地址（公开信息）。
• 时效路由：模拟不同城市之间寄件的预计时效，用于训练时效预测模型。

技术上用 Scrapy 写爬虫框架，用 requests + BeautifulSoup 做轻量页面解析。需要注意的合规细节是：单次请求必须带合理的 User-Agent 和 Referer，请求间隔至少 1 秒，并且每个目标网站只抓取公开数据，不做登录绕过，不采集个人身份信息。这些在论文的“数据来源”章节要写明，既是合规要求，也是答辩老师会追问的点。

爬虫的工程结构不复杂：

class LogisticsSpider(scrapy.Spider): name = "logistics" headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)", "Referer": "https://www.example.com/" } def parse(self, response): # 解析运单轨迹，提取结构化字段 trace_nodes = response.css('.trace-item') for node in trace_nodes: yield { 'event_time': node.css('.time::text').get(), 'event_desc': node.css('.desc::text').get(), 'location': node.css('.city::text').get(), }

抓到的原始数据直接以 JSON 格式写入本地，再通过脚本批量上传到 HDFS 的 ODS 层对应分区。这里有个关键操作：爬虫端不写 HDFS。一是因为 HDFS 的写入频率不适合高频小批量数据，二是爬虫挂了不能影响数仓。正确的链路是：爬虫 → 本地 JSON 文件 → 定期批量hdfs dfs -put到 ODS 分区。

3.2 清洗与去重：脏数据如何影响后面模型

爬虫数据有多脏，做过的人才知道。字段缺失、时间格式乱七八糟、同一个运单轨迹重复抓取，这些是常态。如果直接把这些数据扔给模型，预测结果的误差会大得离谱。

清洗分三步走。第一步是格式统一：时间字段统一转成yyyy-MM-dd HH:mm:ss，城市字段统一成标准城市名（比如“上海”和“上海市”统一为“上海”）。第二步是去重：按运单号 + 事件时间做联合去重，保留第一条；如果同一运单号存在“签收”事件后面还有“派送中”事件，说明数据异常，整条剔除。第三步是异常值过滤：物流时效不可能为负，中转次数不可能超过 50 次，超过阈值的直接标记为脏数据，交给离线分析时过滤掉。

这段清洗逻辑我建议用 PySpark 写，而不是用 Hive SQL。因为清洗逻辑包含正则表达式和条件判断，用 DataFrame API 写起来更直观，也方便后续复用。一个简单的清洗片段：

from pyspark.sql import functions as F df = spark.read.format("parquet").load("hdfs:///warehouse/ods/track_info") df_clean = ( df.filter(F.col("event_time").rlike(r"^\d{4}-\d{2}-\d{2}")) .dropDuplicates(["order_id", "event_time"]) .withColumn("city_normalized", F.regexp_replace("city", "市$", "")) )

清洗后的数据再写入 DWD 层分区。这一步是整个系统的“质量闸门”，闸门没做好，后面所有环节都会受影响。

4. PyFlink 实时链路与 PySpark 离线链路的分工

有了静态数据后，就要设计动态计算了。我系统里最容易被问到的设计是：为什么要同时用 PyFlink 和 PySpark，直接用 Spark Streaming 不就行了吗？这个问题可以在技术方案里正面回答：本系统的实时指标和离线指标在语义上是完全不同的，实时链路关心“当前这一刻发生了什么”，离线链路关心“过去一段时间的规律和特征”，两者并行不悖。Flink 在事件时间处理、精确一次语义等方面比 Spark Streaming 更适合实时场景；而 Spark 在批量特征工程和机器学习库（MLlib）生态上更成熟，适合离线分析。

4.1 实时和离线的边界划分

以“在途包裹数”为例。实时链路的定义是“当前时刻处于运输中的包裹数量”，它需要从 Kafka 消费最新轨迹事件，每来一条“到达中转站”事件就更新一次状态；而离线链路的定义是“某天平均在途包裹数”，它需要对一整天的轨迹数据做汇总统计。两者语义不同，技术实现也完全不同。

我的边界划分规则有三条：

1. 看大屏实时跳动指标（在途包裹、实时发货量、当前中转异常件数）→ PyFlink。
2. 看趋势、看占比、做同期对比（月度货量走势、线路时效分布）→ PySpark。
3. 给模型训练用的特征→ 全部由 PySpark 离线产出，实时链路不承担特征工程。

这样的好处是职责清晰：PyFlink 的代码量可以控制在 500 行以内，PySpark 负责重活，两者互不干扰。如果混在一起，调试的时候你会疯掉。

4.2 PyFlink 实时统计的实现要点

PyFlink 开发最大的痛点是调试。Java 版的 Flink SQL 可以直接在 Flink SQL Client 里跑，PyFlink 则要写 Python 任务然后提交到集群。建议先用 mini cluster 模式在本地跑通逻辑，再提交到 YARN 上。

我先在 Kafka 里建好logistics_trace这个 topic，爬虫把清洗后的轨迹 JSON 写入 Kafka。PyFlink 任务的核心逻辑分为三步：

from pyflink.datastream import StreamExecutionEnvironment from pyflink.table import StreamTableEnvironment env = StreamExecutionEnvironment.get_execution_environment() t_env = StreamTableEnvironment.create(env) # 1. 从 Kafka 读取实时轨迹流 source_sql = """ CREATE TABLE trace_source ( order_id STRING, event_time STRING, city STRING, event_type STRING, ts TIMESTAMP(3), WATERMARK FOR ts AS ts - INTERVAL '5' SECOND ) WITH ( 'connector' = 'kafka', 'topic' = 'logistics_trace', 'properties.bootstrap.servers' = 'localhost:9092', 'properties.group.id' = 'flink-group', 'format' = 'json', 'scan.startup.mode' = 'latest-offset' ) """ t_env.execute_sql(source_sql) # 2. 按城市和事件类型进行滚动统计 aggregate_sql = """ CREATE TABLE city_stats_sink ( city STRING, event_type STRING, cnt BIGINT, window_start TIMESTAMP(3) ) WITH ( 'connector' = 'print' ) """ t_env.execute_sql(aggregate_sql) t_env.execute_sql(""" INSERT INTO city_stats_sink SELECT city, event_type, COUNT(*), TUMBLE_START(ts, INTERVAL '1' MINUTE) FROM trace_source GROUP BY city, event_type, TUMBLE(ts, INTERVAL '1' MINUTE) """)

这段处理的细节有三个地方值得注意。第一，Watermark 必须设。物流轨迹事件由于网络原因可能乱序，Watermark 允许 FLink 忽略迟到过久的数据，保证窗口计算的准确性。第二，结果 sink 不要直接写 MySQL。高频率的窗口结果会频繁写库，造成 MySQL 压力，正确做法是先写到 Kafka 的realtime_resulttopic，再由一个轻量消费者写 MySQL。第三，建议配合 Checkpoint 机制。在 YARN 上提交任务时配置enable_checkpointing(60)，保证任务重启后状态不丢失。

以我实测的数据量（每秒 100 条轨迹），PyFlink 的吞吐完全够用。如果想模拟更大的数据量，可以在爬虫基础上加一个 Kafka Producer 脚本，把历史轨迹按原时间戳回放，模拟出高并发场景，这在答辩演示时非常加分。

4.3 PySpark 离线计算和特征工程

PySpark 在我的系统里承担三件事：全量数据清洗、统计报表生成、特征工程。统计报表没啥难度，重点说特征工程。模型好不好，一半看特征。物流预测的核心特征是“时空特征”和“历史行为特征”。

对于货量预测，我产出的特征包括：

• 时间特征：是否是工作日/周末、是否节假日、月份、周几、距离最近大促的天数（双11、618）。
• 滞后特征：前一天货量、前一周同时段货量、前一个月平均值。
• 区域特征：区域历史货量均值、区域增长率、区域 GDP 等级（这个用公开统计资料做映射）。
• 天气特征：用公开天气 API 采集的温度、降雨、风力等级。

这些特征在 PySpark 里用窗口函数写非常顺手：

from pyspark.sql.functions import col, lag, datediff, when, avg from pyspark.sql.window import Window w = Window.partitionBy("city").orderBy("dt") feature_df = ( df .withColumn("prev_day_volume", lag("volume", 1).over(w)) .withColumn("prev_7day_avg", avg("volume").over(w.rowsBetween(-7, -1))) .withColumn("is_weekend", when(col("day_of_week").isin([6, 7]), 1).otherwise(0)) )

这里的关键经验是：滞后特征必须按城市分区。不同城市的货量基准差异巨大，如果把全国数据混在一起算滞后值，上海和一个小县城会被拉到同一个基准上，模型会完全学偏。

5. 预测模型：先把问题定义清楚，再谈算法

物流预测是机器学习的经典落地场景，但很多同学一上来就谈 LSTM 有多高级，结果训练集和测试集划分不合理，预测结果一塌糊涂。我做完之后的体会是：“预测什么”比“用什么算法”重要得多。

5.1 预测目标的定义与评估指标

我把物流预测拆成两个独立任务：

• 任务一：城市维度未来 7 天货量预测。这是一个时间序列预测问题，单位是“件”，粒度是“天”。评估指标用 MAPE（平均绝对百分比误差）和 RMSE。为什么用 MAPE？因为货量基数在不同城市差异大，MAPE 对相对误差敏感，更能反映预测的实用价值。比如 A 城市真实值 1000、预测 1100，B 城市真实值 100、预测 110，两者的绝对误差都是 100，但明显 B 城市更不可接受，MAPE 能体现这个差异。
• 任务二：单条线路平均时效预测。这是一个回归问题，单位是“小时”，特征包括起止城市、距离、运输方式、季节、是否节假日。评估指标用 MAE（平均绝对误差），因为时效预测用户更关心“预测差了几个小时”，而不是“差了多少倍”。

5.2 特征工程决定上限

我在 PySpark 中做好的特征，会导出成 parquet 文件，再转成 DataFrame 给模型训练。这里强调一个很多教程不提的细节：时间序列预测的测试集划分必须按时间顺序，不能随机切分。如果你随机打乱数据再划分训练集测试集，模型会“偷看”到未来的信息，测试集上的指标会虚高。正确做法是按时间切分：前 80% 的时间段做训练，后 20% 做测试。

比如我的数据时间范围是 2024-01 到 2024-06，那我用 2024-01 到 2024-05 的数据做训练，6 月的做测试。这在答辩时是一个非常容易被评委认可的点，说明你理解时间序列的本质。

5.3 模型对比：LSTM / XGBoost / Prophet

我做了三个模型的对比，结果写进论文就是很好的实验章节。

结论是：树模型做基线，深度学习做增强。时间序列长度足够长时，LSTM 在小幅度上优于 XGBoost；但如果数据量只有几百天，LSTM 的优势不显著，还容易过拟合。所以最终我用 XGBoost 作为第一版发布模型，LSTM 作为论文中的“深度学习优化方案”展示，两者做对比分析。

LSTM 的代码用 PyTorch 实现，逻辑上并不复杂：

class LSTMVolumnPredictor(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 = self.fc(out[:, -1, :]) return out

关键在于输入数据的构造。要用滑窗方式把时间序列转成监督学习格式：用过去 7 天的特征预测第 8 天的货量。窗口大小是经过实验调的，7 太短学不到周期，30 太长噪音太大，7 天在物流场景刚好覆盖一个自然周。

6. 可视化大屏：让答辩老师一眼看懂你的系统

最后一个模块是可视化。很多教程喜欢推荐 Hadoop 生态的 Hue、Zeppelin 这类工具，但毕设场景我最推荐 Flask + ECharts 自研大屏。原因很直接：你不能控制答辩现场的网络，也不能保证 Zeppelin 服务正常启动，而自研大屏只要 Python 环境在，就一定能跑起来。

6.1 可视化技术选型

后端用 Flask 提供接口，读取 MySQL 中的 ADS 层结果，返回 JSON 给前端。前端用 ECharts 实现图表。ECharts 对中国式大屏的支持非常好，地图、折线、热力图都是现成的，省去大量造轮子的时间。

我的大屏页面包含六个模块：

• 顶部地区货量地图：展示全国各城市当日/近七日发货量，用气泡大小表示货量等级。
• 实时滚动榜单：从 PyFlink 写入 MySQL 的实时结果中读取，展示当前发货量 Top10 城市。
• 货量趋势折线图：展示近 30 天全国总货量变化，叠加预测值形成对比。
• 线路时效分布：展示各运输方式的平均时效柱状图。
• 中转异常监控：展示各城市中转节点异常事件数量。
• 模型预测结果卡片：直接展示未来 7 天预测货量和置信区间。

前端用一个 HTML 文件 + ECharts CDN 就能实现，不需要引入 Vue/React。答辩演示时，先把离线数据跑完，再启动 Flask，页面加载后依次展示各图表，最后切到“模型预测”页面展示预测结果。整个演示过程控制在 5 分钟内，非常流畅。

6.2 大屏指标设计的逻辑

大屏指标不是随便堆的。我总结了一个“三层指标”原则：

• 第一层：全局观指标。让观看者 3 秒内理解系统在说什么，典型指标是“全国今日总发货量”“在途包裹总数”“预测未来 7 日货量”。
• 第二层：分析型指标。支持进一步探索，典型指标是“Top 城市排行”“线路平均时效”“中转异常次数”。
• 第三层：细节型指标。点开某个图表后展示的更深层数据，比如点击地图上的上海，下钻展示上海各区货量分布。

这样做的好处是，答辩老师无论从哪个层级提问，你都有内容可讲。我见过很多同学的大屏，一屏塞了几十个图表，看的人眼花缭乱，反而说不出核心结论。可视化不是炫技，是降低理解成本。

7. 最后说几句实在话

整套系统从环境搭建到演示完成，我前后花了一个半月，每天大概三到四个小时。最快能出成果的路径是：先搭 Hadoop + Hive，跑通 HDFS 上传和 Hive 建表；再写爬虫把数据补齐；然后做 PySpark 离线统计，把趋势图和排行榜先做出来；接着上 PyFlink 实时链路；最后才做预测模型。按这个顺序，你每一步都能看到阶段性成果，不至于中途放弃。

两个最容易拖垮进度的坑，提前给你提个醒。第一个是环境版本问题，Hadoop 和 Hive 的版本不匹配，会浪费你整整两天去排查奇怪的 ClassNotFoundException，所以严格按照统一的版本组合来装。第二个是数据质量问题，脏数据如果不在一开始就清洗干净，模型训练时会反复出现负特征值或空值，让你误以为是代码写错了。清洗脚本一定要最先写好。

另外分享一个实操技巧：给 Kafka 的消费者配置设置合理提交延时，给 PyFlink 设置隐含的 Watermark 延迟，给 Hive 开启分区自动添加，这三处细节做好了，实时大屏的抖动会明显减少，演示效果更稳定。答辩时如果老师问“你系统的创新点在哪”，不要只说“用了很多框架”，可以说清楚：以事务边界划分实时和离线链路、以特征工程驱动货量预测、以三层指标体系组织可视化——这三点才是这个系统真正花过心思的地方。项目资料完整版（源码、论文文档、PPT、演示视频讲解）我都整理好了，参考的时候建议把环境自己搭一遍，代码逐行看懂再改，毕设答辩才稳稳过关。