基于深度学习的用户购物行为预测与可视化系统全栈解析

简介本资源是一套面向高校计算机专业学生的Python毕业设计实战项目聚焦淘宝用户购物行为的可视化分析与深度学习预测适用于毕设、课程设计及工程实训等场景兼顾技术小白与进阶学习者。项目采用Django构建后端服务、Vue实现响应式前端、Spark处理海量用户行为数据、Scrapy爬虫采集原始电商数据并基于MySQL 5.7持久化存储完整覆盖Web开发、大数据分析与AI建模全链路。压缩包共629个文件含110个Vue组件、68个Python核心脚本含模型训练与ETL逻辑、70个JS交互文件、48个PNG/JPG图表资源及2个SQL数据库初始化脚本整体30.56MB配套bat批处理脚本如安装.bat、运行.bat、初始化hive数据库.bat显著降低环境部署门槛。目前已有91人下载学习提供即装即跑的可执行源码、结构清晰的模块划分spider数据采集层、spark分析层、django业务层、vue展示层以及完整数据库设计文档助力开发者快速掌握多技术栈协同开发能力。 如果你在翻毕设题目的时候看到“基于深度学习的淘宝用户购物可视化与行为预测系统”这一串名字第一反应很可能和我当时一样这题看着挺全但到底是考爬虫、考大数据、考深度学习还是考Web开发说实话这题全占了。它本质上是一条完整的电商用户数据链路——先采集用户购物行为数据再用Spark做海量数据的清洗和特征工程然后训练深度学习模型去预测用户下一步会不会产生购买行为最后用Django把这些结果以可视化看板的形式呈现出来。整条链路从数据采集到模型训练再到Web展示每一步都要落地所以很多选了这个题的同学都会卡在“不知道从哪里下手”。这个题对毕设来说有个非常实在的价值它不考验单项技术的极致深度而是考验你把Python、爬虫、Spark、深度学习、Django这几样东西串起来的工程能力。我手上的项目编号是5p246最后交付的是一套完整可运行的代码包。这篇文章我就按实际做完这套系统的顺序从需求拆解、技术选型、数据采集、Spark处理、深度学习建模、Django可视化以及踩坑经验这几个维度完整讲一遍给后面准备做同类项目的同学一条能直接照着走的路。1. 选题后的第一件事把这题的需求拆到不能再拆1.1 一个题目背后的多重技术维度很多同学拿到这个题目后就开始搜代码、装环境这是错误的打开方式。你首先要搞清楚导师和评审到底想从你的系统里看到什么。我拆完这个题目之后把它归纳成了四个核心问题数据从哪来淘宝用户的购物行为数据不可能直接给你所以要用爬虫技术去采集或者用公开数据集加模拟数据补全。数据怎么处理采集回来的原始数据是脏的、乱的、规模大的需要用Spark做分布式清洗、转换和特征提取。行为怎么预测基于用户的历史行为序列用深度学习模型预测他未来是否会发生购买行为。结果怎么展示训练好的模型和统计结果不能只停留在终端里要做一个Web系统把用户画像、商品分析、购买预测都可视化呈现出来。这四个问题正好对应系统的四个模块采集模块、数据处理模块、预测模块、可视化模块。你只要在开题报告里把这条链路讲清楚导师基本不会质疑你的选题价值。1.2 系统模块的边界划分理清问题之后我建议直接把系统的数据流画成一条线爬虫采集/模拟数据 - 原始数据集 - Spark清洗与特征工程 - 特征数据集 - 深度学习训练与推理 - 预测结果 - Django可视化展示这条线里的每一步都是上一层的输入。我在设计系统时把模块之间的接口都定义成文件和数据表的格式比如爬虫输出CSVSpark读取CSV并输出处理后的Parquet或特征CSVDjango再读取这些文件渲染图表模型则单独保存为权重文件供Django调用。模块之间不强耦合哪个环节出了问题就单独替换后期调试非常方便。1.3 哪些功能必须做哪些可以明确不做毕设最忌讳的就是什么都想加。我在做这个系统时给自己划了一条能力边界必须做用户购买行为的二分类预测买/不买、销售额与商品类别的统计分析、用户画像可视化、预测结果展示页面。选做不做个性化商品推荐排序、实时流式计算、复杂的反爬对抗。这些内容技术难度高很容易把一个毕设拖成无底洞。我建议你也按这个思路把“能做”和“值得做”分开。平台名是淘宝但你实际要构建的是一套可迁移的电商行为分析框架把数据源换成京东、拼多多一样能跑这才叫掌握了核心能力。2. 技术栈选型推演为什么偏偏是Spark、Django、爬虫和深度学习2.1 数据获取层爬虫与模拟数据的取舍淘宝的反爬强度做过的人都知道登录验证、滑块、签名参数一堆真要硬爬光逆向请求参数就能耗掉你大半个月。所以在数据获取层我的方案是“公开数据验证 模拟数据补量”。我并没有完全抛弃爬虫。爬虫模块用Scrapy框架实现了对公开商品页面的基础采集主要用来验证字段结构和数据格式是否符合设计预期。真正用于模型训练和可视化的核心数据是参照淘宝用户行为数据集比如UserBehavior公开数据集的字段格式模拟生成的包括用户ID、商品ID、商品类目、行为类型浏览、收藏、加购、购买、行为时间等。这套做法在毕设答辩中完全说得通你展示了爬虫能力又避免了把时间耗在反爬对抗上。2.2 数据处理层为什么要用Spark而不是Pandas很多人会问数据量也就几万条用Pandas不香吗为什么非得上Spark我的回答是这个题目的关键词里写着“大数据”和“海量用户行为”用Spark不是因为它处理几万条数据更快而是因为你要在毕设里体现出对分布式计算的理解。Spark的DataFrame API在做分组聚合、用户行为序列构建时代码写起来和Pandas有些相似但底层是分布式执行引擎可以水平扩展。更关键的是Spark自带的MLlib和特征处理工具能和后面的深度学习流程无缝衔接。我当时在环境里配的是PySpark直接用Python写Spark作业避免了Scala的学习成本。你如果用Windows记得装Hadoop的winutils.exe否则Spark本地跑会报错这个我后面单独讲。2.3 模型层深度学习凭什么能预测用户行为用户购物行为本质上是时序数据浏览商品、加入购物车、收藏、最终购买这是一个有先后顺序的决策链条。传统方法比如逻辑回归只能把每个行为当作独立特征来用丢失了先后顺序里的信息。而深度学习里的循环神经网络天然适合处理序列数据。我最终选用的是GRU门控循环单元而不是LSTM。理由很直接GRU参数更少、训练更快在用户行为序列这种长度不算特别长的场景下效果和LSTM基本持平。嵌入层把用户ID和商品ID映射成稠密向量再经过GRU层捕捉行为之间的依赖关系最后通过全连接层输出购买概率。这就是整个预测模块的核心逻辑。2.4 应用层Django在整个系统里的定位Django在这个系统里承担的是“承上启下”的角色往下读取Spark处理好的特征数据往上渲染可视化图表同时还要加载深度学习模型对外提供预测接口。我选Django而不是Flask的原因主要有三个一是Django自带Admin后台和用户认证体系展示项目时可以直接在后台管理数据显得系统完整二是Django的ORM操作数据库非常方便省去大量SQL拼接三是Django的模板系统能很好地配合ECharts做服务端渲染。如果你只是做一个轻量级演示Flask也行但Django在应对“毕设评审查功能完整性”这个场景时会更有优势。3. 数据采集与预处理爬虫模块到底怎么写才不白写3.1 采集字段的设计决定了后面所有环节是否顺利数据字段是整个系统的心脏。我设计字段时参考了电商用户行为分析的标准格式一共五个核心字段加一个扩展字段字段名类型说明user_idstring用户唯一标识item_idstring商品唯一标识category_idstring商品类目IDbehavior_typestring行为类型pv浏览、fav收藏、cart加购、buy购买timestamplong行为时间戳pricefloat商品价格模拟数据补充这里有个很关键的经验behavior_type的取值一定要固定枚举值不要用中文或自由文本。后面Spark做one-hot编码和特征工程时枚举值能省掉大量字符串处理的麻烦。3.2 爬虫架构与模拟数据生成策略爬虫模块我用了Scrapy框架结构上分为Spider层和Pipeline层。Spider层负责发送请求、解析页面Pipeline层负责清洗数据、写入文件。当然对淘宝这种级别的站点我并没有去做深度的逆向破解而是用一个公开测试页面验证了爬虫链路的可用性再把核心精力放在模拟数据生成器上。模拟数据生成器其实就是一个带随机逻辑的Python脚本随机生成用户ID、商品ID、类目ID按幂律分布生成浏览、收藏、加购、购买行为序列。这里我强烈建议你让行为序列符合“浏览多、购买少”的电商规律否则后面模型训练出来的结果会失真。我生成的时候控制了转换率浏览到收藏约10%收藏到加购约20%加购到购买约30%这样整条漏斗看起来才像真实数据。3.3 数据落盘与初步清洗规则无论爬虫抓到的还是模拟生成的数据最终都要落盘。我用的存储格式是CSV每一行是一条行为记录。落盘之后初步清洗是必不可少的去重同一用户在同一秒对同一商品的重复行为记录只保留一条。时间戳清洗把非法时间戳比如1970年之前或超过当前时间删除。字段完整性检查任何一行如果user_id、item_id为空直接剔除。这三个规则看似简单但对后面Spark Processing的稳定性影响很大。我用Python脚本做了第一轮清洗输出干净的原始数据文件这样Spark读进来的时候就不会因为脏数据导致任务中途崩溃。4. Spark数据处理与特征工程从原始行为日志到模型输入的完整实现4.1 数据加载与ETL用DataFrame统一数据入口进入Spark阶段第一步是用PySpark读取清洗后的CSV文件。代码非常简洁from pyspark.sql import SparkSession from pyspark.sql.functions import col, to_timestamp spark SparkSession.builder.appName(taobao_etl).getOrCreate() df spark.read.csv(data/raw_user_behavior.csv, headerTrue, inferSchemaTrue) df df.withColumn(event_time, to_timestamp(col(timestamp))) df df.filter(col(user_id).isNotNull() col(item_id).isNotNull())这里有个容易被忽略的细节Spark读取CSV时如果不指定schema会默认把全部列当字符串处理。虽然inferSchema会自动推断类型但在大数据量下它会额外扫描一遍文件。我建议在项目里直接显式定义schema既省时间又避免推断错误。ETL过程中还需要做维度对齐。比如行为类型字段里可能出现大小写不一致需要统一转换为小写时间字段需要统一为时间戳格式方便后面提取小时、星期等时间特征。这个环节不要省因为Django展示的很多图表都依赖于干净的时间字段。4.2 构建用户行为序列这是深度学习模型的前置输入深度学习的预测模型不接收“多行零散记录”它接收的是“一个用户按时间排序的行为序列”。所以Spark阶段最核心的一步就是把每个用户的行为记录聚合成一个序列。做法是先按user_id分组再按event_time排序把该用户所有行为对应的item_id、category_id、behavior_type分别组成列表。PySpark的collect_list函数可以完成这个聚合但要注意排序问题。collect_list本身不保证顺序所以要先对全表按user_id和event_time排序再用groupByagg。序列构建好之后通常还需要做截断和补长。我设置的序列最大长度是50超过50的截断不足50的用0填充。这样做的好处是让所有输入张量形状一致方便深度学习模型批量训练。这个逻辑可以在Spark里直接算好也可以导出后在Python里处理我选择了后者因为后面做Padding时用NumPy更顺手。4.3 特征工程不只是序列还有统计特征除了行为序列我还用Spark的groupBy和agg计算了一批统计特征这些特征会和序列特征拼接在一起共同输入模型。统计特征包括用户的浏览总次数、收藏总次数、加购总次数、购买总次数。用户的购买转化率购买次数除以行为总次数。用户的活跃天数最早行为时间到最晚行为时间的跨度。最近一次行为距预测日的时间差recency反映用户活跃度。用户偏好的商品类目购买次数最多的类目ID。这些特征用Spark的聚合函数可以一次性算出来。我在这里有一个经验统计特征不要贪多选10个以内最有解释性的就够。特征太多不仅增加训练时间还容易引入噪声。把这些特征保存成feature_engineered.csv后面模型训练时直接和序列特征合并使用。5. 深度学习行为预测模型从结构设计到训练调参的完整记录5.1 把预测问题定义清楚二分类还是多分类我在系统里把用户行为预测定义成了一个二分类问题给定一个用户最近30天的行为序列预测他在未来7天内是否会发生购买行为。标签为1表示会买0表示不会买。为什么不做多分类比如预测用户具体会买哪个商品因为商品数量庞大类别极不均衡做多分类会让模型复杂度和训练难度都急剧上升毕设周期根本撑不住。二分类既有明确的业务意义营销定向、用户唤醒又能清晰评估模型效果是性价比最高的选择。正负样本的处理也要注意。电商场景中“购买”行为是少数直接训练会导致模型偏向预测“不买”。我用的方式是下采样从没有购买行为的用户里随机抽取与购买用户等量的样本构造一个1:1的训练集。这样模型不会因为正负样本失衡而失效。5.2 模型结构Embedding BiGRU Attention Dense模型结构我基于Keras实现核心是嵌入层、双向GRU层、注意力层和输出层。下面是我实际用的简化版代码import tensorflow as tf from tensorflow.keras import layers, Model def build_model(vocab_size_item, seq_len50, embed_dim64): item_input layers.Input(shape(seq_len,), nameitem_seq) item_embed layers.Embedding(vocab_size_item, embed_dim, mask_zeroTrue)(item_input) gru_out layers.Bidirectional( layers.GRU(units64, return_sequencesTrue, dropout0.2) )(item_embed) attention_weight layers.Dense(1, activationtanh)(gru_out) attention_weight layers.Flatten()(attention_weight) attention_weight layers.Activation(softmax)(attention_weight) context layers.Dot(axes1)([gru_out, attention_weight]) flat layers.Flatten()(context) dense layers.Dense(32, activationrelu)(flat) output layers.Dense(1, activationsigmoid)(dense) model Model(inputsitem_input, outputsoutput) return model这段代码里有几个值得展开的点第一Embedding层设了mask_zeroTrue这样前面Padding的0值不会参与计算避免无效信息干扰模型。第二我用了双向GRU。用户行为序列里某个行为是否导致购买不一定只取决于它之前的行为也可能与之后的行为相关双向结构能同时捕捉前后文信息。第三注意力层的作用是对行为序列中不同的位置分配不同权重。比如用户三天前的浏览可能比两周前的浏览对“近期是否购买”更有影响力注意力机制让模型自己学会这种权重分配。我对比过纯GRU、LSTM、GRUAttention三种结构在验证集AUC上GRUAttention最高达到了0.86左右纯GRU大概0.83LSTM和GRU差不多但训练时间更长。所以如果时间紧直接上GRUAttention性价比最高。5.3 训练配置与调参经验训练参数我一开始用一个相对保守的配置序列长度50Embedding维度64GRU隐层维度64batch_size为128初始学习率0.001优化器用Adam损失函数用binary_crossentropy评估指标用AUC和准确率。数据集按7:2:1切分成训练集、验证集、测试集。训练时加了EarlyStopping监控验证集AUC连续3个epoch不提升就停止避免过拟合。我实际跑下来大约在第8个epoch收敛训练时间在CPU上也能控制在半小时以内。调参过程中我踩过一个明显的坑一开始学习率设成0.01结果模型在训练初期loss疯狂震荡AUC一直上不去。后来改成0.001才恢复正常。我建议你如果发现训练不收敛第一个要怀疑的就是学习率太大别急着调网络结构。另外一个值得注意的参数是序列长度。我试过把序列长度设为100发现效果并没有明显提升但训练时间翻了一倍。因为绝大多数用户的行为序列长度集中在30到60之间设50已经能覆盖大部分情况。参数不是越大越好够用就行。6. Django可视化平台把数据、模型和图表整合成一个能答辩的系统6.1 Django项目的整体架构Django部分我按功能拆成了三个Appdata_analysis负责统计图表的页面和接口prediction负责模型预测接口users负责登录和后台管理。这样做的好处是代码职责清晰遇到问题能快速定位。项目的数据读取采用“文件落地ORM辅助”的混合方式。Spark处理好的统计结果保存为CSV和JSON文件Django在视图里直接读取并传给模板渲染而用户账号、预测记录等结构化数据则存SQLite数据库通过Django的ORM来操作。这样既保证了图表数据的高效加载又不失Django在数据管理上的优势。6.2 可视化图表的选型与落地可视化我选的是ECharts原因很简单中文文档全、图表类型丰富、社区案例多。我从数据中产出了以下几种图表用户行为漏斗图从浏览到购买每一步的人数转化直观展示电商漏斗。商品类目销售额饼图分析哪些类目贡献了主要销售额。每日购买趋势折线图观察时间维度的购买波动。用户购买力分布柱状图按价格区间统计购买人数。ECharts的使用方式是在Django模板中引入echarts.min.js然后通过后端把数据塞到模板变量里再在前端用JavaScript初始化图表。数据格式上我统一在Django视图里把数据转成JSON格式模板中通过json_script模板标签传给JavaScript这样避免了手动拼接字符串导致的引号转义问题。6.3 预测功能的实现方式预测功能是系统的亮点我做了一个独立的“用户行为预测”页面用户在表单里输入用户ID系统从Spark处理好的特征文件里查出该用户的行为序列加载训练好的Keras模型进行推理最终返回该用户未来7天购买概率并配上风险等级标签高/中/低购买意向。这个过程中最关键的细节是模型加载方式。Keras的load_model方法可以加载完整模型我建议把训练好的模型保存为.keras格式然后放到Django项目的model目录下。在Django视图里用全局变量缓存模型对象避免每次请求都重新加载模型否则并发请求时系统会卡死。我实测过不缓存的情况下单次预测要等好几秒缓存后基本毫秒级响应。预测接口返回的数据是JSON前端拿到后展示结果。为了增强演示效果我还加了最近10条行为记录的表格展示让评审老师能看到“模型是在什么数据基础上做出的判断”。这一点在答辩时非常加分因为老师能直观看到输入和输出的对应关系。7. 开发过程中真实踩过的坑以及答辩准备的几条建议7.1 环境与版本层面的坑整个开发过程里环境问题占了我三分之一的时间。最典型的是PySpark在Windows下的运行问题不装Hadoop的winutils.exeSparkContext初始化时会直接报错。解决办法是下载对应Hadoop版本的winutils放到一个目录然后设置环境变量HADOOP_HOME指向它。还有一个坑是Python和TensorFlow的版本兼容问题。我一开始用Python 3.11装TensorFlow结果提示没有对应的预编译包。后来降到Python 3.9配合TensorFlow 2.12才顺利装好。所以建议你动手前先确认版本矩阵别在环境上消耗太多时间。7.2 数据与模型层面的坑在模型训练阶段我踩过最深的坑是序列对齐问题Spark输出的行为序列中每个用户长度不一致如果不做padding直接训练TensorFlow会报维度不一致错误。这个问题的解法就是前面说的统一截断到50并用0填充。另一个值得注意的问题是样本均衡。我第一次训练时用的是原始不均衡数据模型AUC只有0.62看起来能用但实际上模型对“购买”类样本的召回率非常低。做下采样之后AUC提升到0.86模型的业务价值才真正体现出来。所以分类问题里正负样本比例一定要提前关注。7.3 可视化与展示层面的坑Django的静态文件处理是个经典坑。开发环境用runserver启动时静态文件需要放在App的static目录下并在settings.py里配置STATICFILES_DIRS。我一开始把echarts.min.js放在了项目根目录下的static文件夹结果页面一直加载不出图表检查浏览器控制台才发现是404。还有一个容易忽略的问题ECharts图表在页面切换后可能因为容器宽度变化而变形需要在窗口大小变更时调用resize方法。我这里写了一个简单的监听器不然切换菜单再回来图表会被压扁显得很不专业。7.4 答辩演示的关键点最后聊一下答辩。这个系统的演示顺序我建议固定成一条主线从数据采集展示爬虫代码和模拟数据生成脚本到数据处理展示Spark处理日志和特征文件再到模型训练展示训练曲线和评估指标最后到可视化平台现场演示预测功能。这条主线顺着数据流走评审老师很容易跟上思路。老师大概率会追问这几个问题为什么用GRU不用LSTMSpark和Pandas的区别是什么模拟数据和真实数据的差异会不会影响模型可信度你在做之前就要把这些问题想透。不用背标准答案用你实际开发中踩过的坑和调参经验来回答反而更有说服力。整个项目做完之后最大的感受是这个题目最难的其实不是某一个技术点而是把五个技术栈串起来的能力。你爬虫的数据Spark能不能直接读Spark的特征模型能不能直接用模型的输出Django能不能方便地展示每一步衔接都决定了最终系统的完成度。希望这篇文章能帮准备做同类项目的同学少走一些弯路。本文还有配套的精品资源点击获取