Django大数据电商销售预测系统：数据链路、模型回测与ECharts大屏-开发者社区

简介：面向计算机、软件工程等专业正在准备毕业设计选题的学生，这份开题报告以基于大数据的电商销售预测分析系统为题，围绕 Python 与 Django 技术路线，梳理大数据挖掘在电商销售预测中的应用场景与落地方案。文档从选题依据与目标切入，交代研究目的与研究现状，并给出研究内容的三条主线：大数据分析技术在销售预测中的应用、预测模型的建立与优化、分析系统的设计与实现。研究方案部分进一步展开预测趋势、模式辨认、季节性购物、客户服务等分析思路，说明文献研究与实证研究相结合的基本方法，同时附研究进度安排与十余条参考文献，可直接作为开题材料撰写、答辩提纲与后续开发计划的参考模板。资源为 1 个 docx 文档，压缩包约 25KB，轻量易取，已有 1377 人学习。

1. 电商销售预测系统的真实瓶颈：Django 只是外壳，数据链路才是骨头

做大数据毕设选题时，「基于大数据的电商销售预测分析系统」几乎是年年出现的高频题，多数人第一反应是先选模型——ARIMA 还是 LSTM。真实情况恰好相反：模型换三遍，MAPE 也就动几个点；数据口径错一次，预测曲线能和运营手里的日报差出三成。这套系统的骨架是 Django，它管权限、管表结构、管接口、管大屏取数，Python 侧的算法只负责把一张干净的日粒度宽表变成带置信区间的预测值。真正吃掉时间的是订单明细去重、退款冲销、缺货日期补齐、促销标记对齐这些脏活。下面按一条能跑通的路径讲四件事：Django 里表怎么建、特征表怎么拼、模型怎么回测、结果怎么回写并画到 ECharts 数据可视化大屏上，适合正在写开题报告、准备动手搭第一版的人。

2. Django 后端与大数据侧的分工：MTV 模式下的四个 app 怎么切

先别急着写模型代码。电商销售预测分析系统的数据量级通常落在「单表千万行以内、单机 PostgreSQL 加列存视图能扛」这个区间，远没到必须上大数据集群的程度。我一般会先把在线查询和离线计算切开：Django 只做秒级响应的事，重计算全部推到离线任务里落表，在线只读结果。这条边界画不清楚，后面接口超时、页面转圈、答辩现场演示卡死都是必然。

2.1 先定在线与离线的边界，再谈 Django 该做什么

判断标准很简单：一个请求里如果出现「跑模型」「扫全量订单」「算 28 天滑窗」，就不该放在视图函数里。常见做法是每天凌晨由调度器触发一次离线任务，把未来 14 到 30 天的预测值写进结果表，Django 的接口只做biz_date范围过滤和时间序列排序，响应时间稳定在几十毫秒。

画大数据架构图的时候也别只画「采集层—计算层—应用层」三层就交差，把 Django 的位置标清楚：它在应用层里既当 API 网关，又当元数据管理员，还是可视化页面的模板渲染方。离线侧产出的宽表可以落在同一套 PostgreSQL 里，也可以用 Hive/Spark 跑完再同步回来，但同步的粒度一定是「SKU × 日期」，不是明细行。前者一天几十万行，后者一天几千万行，导入耗时差两个数量级。

提示：把「预测口径」写进表注释里。同一个 sku_id，销量口径是「支付件数」还是「签收件数」，退款是当期冲销还是按原单日期回补，这些细节不写下来，三个月后自己都说不清。

2.2 按 MTV 模式拆 app：数据接入、预测计算、结果查询、可视化

Django 之 MTV 模式里 M 是模型、T 是模板、V 是视图，很多人学到这儿会问 MTV 到底有什么用。落到这个项目上就是一句话：数据表结构、页面渲染、请求处理三者解耦，谁的活谁干。拆 app 时不要一个 app 塞到底，按职责切四个更利于后续维护。

app 名称	职责	关键内容
`datacenter`	数据接入与清洗	订单、商品、渠道模型，聚合任务，口径校验脚本
`forecast`	预测计算	特征构造、模型训练、回测、结果回写
`api`	只读接口	DRF 视图集，负责预测曲线、排行、预警三个出口
`dashboard`	页面渲染	模板、ECharts 配置、导出按钮

创建 app 的命令很直接，注意项目名和 app 名不要重名，否则导入时会撞包：

python -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate pip install django djangorestframework pandas numpy lightgbm statsmodels \ celery redis psycopg2-binary python-dotenv django-admin startproject salesforecast . python manage.py startapp datacenter python manage.py startapp forecast python manage.py startapp api python manage.py startapp dashboard

这段命令做三件事：建虚拟环境、装齐依赖、用django-admin startproject生成配置目录。最后那个点号别漏，它让项目直接落在当前目录而不是再套一层文件夹。startapp生成的apps.py里建议把default_auto_field设成BigAutoField，订单明细这一类表主键增长很快，AutoField到 21 亿会溢出。

2.3 三张核心表的字段设计与索引选择

表不需要多，四张就够跑通全流程：商品维表、订单明细、日粒度聚合、预测结果。维表读多写少，明细表只写不读（只做聚合），聚合表被频繁查询。索引加在查询路径上，别在明细表上乱加。

# datacenter/models.py from django.db import models class DimSku(models.Model): sku_id = models.CharField(max_length=32, unique=True) sku_name = models.CharField(max_length=128) category = models.CharField(max_length=64, db_index=True) price = models.DecimalField(max_digits=10, decimal_places=2) on_sale = models.BooleanField(default=True) class OrderItem(models.Model): order_id = models.CharField(max_length=32, db_index=True) sku = models.ForeignKey(DimSku, on_delete=models.DO_NOTHING, db_column="sku_id") order_time = models.DateTimeField(db_index=True) qty = models.IntegerField() amount = models.DecimalField(max_digits=12, decimal_places=2) channel = models.CharField(max_length=16) is_refund = models.BooleanField(default=False) # 退款/取消单，聚合时必须剔除 class DailySales(models.Model): sku = models.ForeignKey(DimSku, on_delete=models.CASCADE, db_column="sku_id") stat_date = models.DateField() qty = models.IntegerField() amount = models.DecimalField(max_digits=14, decimal_places=2) order_cnt = models.IntegerField() class Meta: constraints = [ models.UniqueConstraint(fields=["sku", "stat_date"], name="uniq_sku_date") ] indexes = [models.Index(fields=["stat_date"])] class PredResult(models.Model): sku = models.ForeignKey(DimSku, on_delete=models.CASCADE, db_column="sku_id") biz_date = models.DateField() yhat = models.FloatField() yhat_lower = models.FloatField(null=True) yhat_upper = models.FloatField(null=True) model_name = models.CharField(max_length=32) created_at = models.DateTimeField(auto_now=True) class Meta: constraints = [ models.UniqueConstraint( fields=["sku", "biz_date", "model_name"], name="uniq_pred" ) ] indexes = [models.Index(fields=["biz_date", "model_name"])]

OrderItem.sku用DO_NOTHING而不是CASCADE，是因为明细表属于事实数据，商品下架不应该级联删掉历史订单。DailySales上的联合唯一约束是幂等写入的前提——聚合任务重跑时靠ON CONFLICT覆盖，不会产生重复行。PredResult的索引顺序是biz_date在前，因为大屏查询几乎总是「按日期区间拉全部 SKU」，把日期放在联合索引第一列才能吃到索引。

2.4 本地跑通的最小流程与解释器配置

建好模型后走一遍迁移，再从shell里插两条假数据验证链路：

python manage.py makemigrations datacenter python manage.py migrate python manage.py shell -c " from datacenter.models import DimSku, DailySales import datetime sku, _ = DimSku.objects.get_or_create(sku_id='SKU001', defaults={'sku_name': '测试商品', 'category': '家居', 'price': 59.9}) DailySales.objects.update_or_create(sku=sku, stat_date=datetime.date(2025, 1, 1), defaults={'qty': 12, 'amount': 718.8, 'order_cnt': 9}) print(DailySales.objects.filter(sku_id='SKU001').count()) "

makemigrations只根据模型差异生成迁移文件，migrate才真正建表，两者别混。shell -c适合验证小片段，正式清洗脚本写成management/commands/下的自定义命令更规范。VS Code Python 环境配置或者 PyCharm 配置 Python 环境这件事，重点只有一个：解释器路径要指向.venv/bin/python或.venv\Scripts\python.exe，而不是系统那个。解释器选错，pip install装到全局，跑起来就是ModuleNotFoundError，这一条踩过的人最多。

3. Python 侧销售预测的落地：特征表、基线模型与回测口径

到了算法这一层，最容易犯的错是直接拿明细数据喂模型。明细里有大量重复订单行、取消单、赠品零元单，不聚合不剔除，特征全是噪声。正确路径是先把订单明细按「SKU × 日」聚合成宽表，再在宽表上造特征。电商销量有很强的星期效应和促销脉冲，所以特征里必须包含滞后项、滑动统计量、星期与促销标记三类。

3.1 从订单明细聚合到日粒度宽表

聚合用 SQL 做比用 ORM 快得多，直接把DailySales当目标表：

INSERT INTO datacenter_dailysales (sku_id, stat_date, qty, amount, order_cnt) SELECT sku_id, DATE(order_time) AS stat_date, SUM(qty) AS qty, SUM(amount) AS amount, COUNT(DISTINCT order_id) AS order_cnt FROM datacenter_orderitem WHERE is_refund = FALSE AND order_time >= %s AND order_time < %s GROUP BY sku_id, DATE(order_time) ON CONFLICT (sku_id, stat_date) DO UPDATE SET qty = EXCLUDED.qty, amount = EXCLUDED.amount, order_cnt = EXCLUDED.order_cnt;

时间条件用左闭右开，避免边界日期被算两次；COUNT(DISTINCT order_id)而不是COUNT(*)，因为一个订单可能包含同一 SKU 的多行；ON CONFLICT ... DO UPDATE让这段 SQL 可以重复跑，补数时不会炸唯一约束。MySQL 用户把最后三行换成ON DUPLICATE KEY UPDATE即可，语义一致。

3.2 特征清单：滞后项、滑动窗口、星期与促销编码

读宽表时务必先按日期补齐。断货或者当天零销量，数据库里根本没有那一行，不补日期直接算 7 日均线，会把停售期算成正常销量。

import pandas as pd LAGS = (1, 7, 14, 28) WINDOWS = (7, 14, 28) def build_features(df: pd.DataFrame) -> pd.DataFrame: df = df.sort_values("stat_date").copy() df["stat_date"] = pd.to_datetime(df["stat_date"]) full_idx = pd.date_range(df["stat_date"].min(), df["stat_date"].max(), freq="D") df = df.set_index("stat_date").reindex(full_idx).rename_axis("stat_date") df["qty"] = df["qty"].fillna(0) df["amount"] = df["amount"].fillna(0) df["dow"] = df.index.dayofweek df["is_weekend"] = (df["dow"] >= 5).astype(int) df["is_promo"] = df["promo_flag"].fillna(0).astype(int) # 促销日历打标后的字段 for lag in LAGS: df[f"lag_{lag}"] = df["qty"].shift(lag) for w in WINDOWS: df[f"roll_mean_{w}"] = df["qty"].shift(1).rolling(w).mean() df[f"roll_std_{w}"] = df["qty"].shift(1).rolling(w).std() return df.dropna()

参数	含义	调参建议
`LAGS`	滞后阶数	至少覆盖 1 个完整周期，日粒度用 7 的倍数
`WINDOWS`	滑动窗口长度	7 看短期波动，28 看月度趋势
`shift(1)`	特征时点回退一天	防止用当天真实值预测当天，这是最常见的泄漏
`is_promo`	促销标记	大促当天销量翻倍，不标出来模型会当成异常点

shift(1)那行是整套特征工程里最关键的一行。少了它，离线回测的 MAPE 会低得离谱，上线后一塌糊涂，这是数据泄漏最典型的形态。

3.3 LightGBM 与 ARIMA 两条基线的可复现代码

单 SKU 数、单店数据量在几千到几万行区间时，ARIMA 适合做「平滑无大促」的品类，LightGBM 适合有促销和星期效应的 SKU。两条基线都跑，答辩时才有对比可讲。

import lightgbm as lgb import numpy as np from sklearn.metrics import mean_absolute_error FEAT_COLS = [c for c in df.columns if c.startswith(("lag_", "roll_", "dow", "is_"))] HORIZON = 14 train, test = df.iloc[:-HORIZON], df.iloc[-HORIZON:] model = lgb.LGBMRegressor( n_estimators=400, # 树的数量，配合 learning_rate 调 learning_rate=0.05, # 步长，越小越稳但训练慢 num_leaves=31, # 单树复杂度，超过 127 在千级样本上必过拟合 min_child_samples=20, # 叶子最小样本数，小样本场景调大到 30~50 subsample=0.9, random_state=42, # 固定种子，保证结果可复现 ) model.fit(train[FEAT_COLS], train["qty"]) pred = model.predict(test[FEAT_COLS]).clip(min=0) # 销量不能为负 print("MAE =", mean_absolute_error(test["qty"], pred))

clip(min=0)看着不起眼，但回归模型输出负值后，前端画出来的预测曲线会穿到 0 轴以下，运营一眼就判定系统不可信。random_state固定同样重要，同一份数据两次跑出不同结果，任何复盘都无从谈起。

3.4 回测切分与 MAPE/WAPE 口径

时间序列不能随机切分，这是硬规则。随机切会让未来信息渗透进训练集，指标好看但不反映真实能力。正确做法是滚动原点回测：固定训练窗口，向前推 14 天预测，再整体前移 14 天，重复 4 到 5 轮。

指标	计算方式	适用场景
MAPE	平均绝对百分比误差	销量量级相近的 SKU 横向比较
WAPE	绝对误差总和 ÷ 真实值总和	存在大量零销量的稀疏 SKU，比 MAPE 稳
sMAPE	对称百分比误差	真实值接近 0 时避免分母爆炸
RMSE	均方根误差	更惩罚大偏差，适合关注缺货风险的场景

一个常见误用是拿 MAPE 去比较日销个位数和日销上千的 SKU，前者分母小，百分比误差自然大，结论会完全反过来。分类目看 WAPE，分 SKU 看 MAE，这个口径在开题报告里写清楚，答辩时被追问的概率会低很多。

4. 预测结果回写 Django 并出图：任务调度、接口与大屏

离线算出预测值之后，把它稳定地送回数据库，再让接口和大屏读出去，这一段决定系统能不能演示。三个坑分别是：写入太慢、重复跑产生脏数据、导出大文件把 worker 撑爆。

4.1 批量写入预测结果：bulk_create 与删除重写的取舍

一次预测可能产出几十万行，逐条save()会慢到不可接受。较新版本的 Django 提供bulk_create(update_conflicts=...)，一次 SQL 搞定插入或更新；版本不支持时退回「先删后插」，但删的时候别用queryset.delete()——Django 执行查询删除对象时会逐条触发信号，几十万行会很慢。

from django.db import transaction from forecast.models import PredResult def flush_results(model_name: str, rows: list[dict]) -> int: objs = [PredResult(model_name=model_name, **r) for r in rows] with transaction.atomic(): # 整体替换：先按模型名清空该批次，再批量插入，避免残留旧值 PredResult.objects.filter(model_name=model_name).delete() PredResult.objects.bulk_create(objs, batch_size=2000) return len(objs)

batch_size=2000是经验值，PostgreSQL 下单条 INSERT 参数超过 65535 会报错，2000 行乘以字段数一般还在安全区。transaction.atomic()保证删除和插入要么都成功要么都回滚，不会出现「删完但没插进去」的空窗期。

4.2 Celery 定时任务与失败重试

调度用 Celery beat，每天凌晨跑一次。任务里包一层重试，数据库瞬时不可用时不至于整天没有预测值。

from celery import shared_task from celery.schedules import crontab from datetime import date, timedelta @shared_task(bind=True, max_retries=3, default_retry_delay=600) def run_daily_forecast(self, model_name: str = "lgbm"): try: rows = compute_and_predict(model_name) # 抽出来的纯计算函数 return flush_results(model_name, rows) except Exception as exc: raise self.retry(exc=exc) # settings.py 里注册 CELERY_BEAT_SCHEDULE = { "daily-forecast": { "task": "forecast.tasks.run_daily_forecast", "schedule": crontab(hour=2, minute=30), } }

max_retries=3配合default_retry_delay=600表示失败后每 10 分钟重试一次，最多 3 次。注意bind=True才能拿到self，忘了写就会报AttributeError。

4.3 DRF 三个查询接口与参数约定

接口只做读，参数固定下来，前端才能照着写。

端点	路径	主要参数	返回
预测曲线	`/api/forecast/`	`sku_id`、`model`、`start`、`end`	日期、预测值、上下界
类目排行	`/api/rank/`	`category`、`biz_date`、`top_n`	SKU 与预测销量降序
库存预警	`/api/alert/`	`biz_date`、`ratio`	预测销量高于库存水平的 SKU

from rest_framework import serializers from forecast.models import PredResult class PredResultSerializer(serializers.ModelSerializer): sku_id = serializers.CharField(source="sku.sku_id") sku_name = serializers.CharField(source="sku.sku_name") class Meta: model = PredResult fields = ["sku_id", "sku_name", "biz_date", "yhat", "yhat_lower", "yhat_upper"]

用source="sku.sku_id"而不是嵌套序列化器，能少一层对象构造。配套的视图集里用select_related("sku")，避免 N+1 查询——一天拉 30 个 SKU 的曲线，少了这个会打出 30 次 SQL。

4.4 ECharts 数据可视化大屏怎么读预测区间

大屏只画一条预测线是不够的，yhat_lower和yhat_upper必须一起展示，否则运营会把点预测当成承诺值。ECharts 里用两条折线加areaStyle叠出置信带，或者直接用自定义系列画区间条。前端配置里把xAxis.type设成'category'并按biz_date排序，不要交给 ECharts 自动推断时间轴，跨月时容易错位。

大屏上安排四块：预测曲线带区间、类目销量 Top10 横向柱图、库存预警红色列表、模型最近一次运行时间与 WAPE。最后那块看着多余，但答辩现场最容易被问「你这数准不准」，有 WAPE 摆在那里，比口头解释有效得多。

4.5 导出报表：StreamingHttpResponse 的 content_type 与 content_disposition

导出 CSV 时如果用普通HttpResponse先拼好整个字符串，几十万行会直接吃满内存。用流式响应边查边发：

from django.http import StreamingHttpResponse from forecast.models import PredResult def export_forecast(request): def rows(): yield "\ufeff" # UTF-8 BOM，缺了它 Excel 打开中文列名会乱码 yield "sku_id,biz_date,yhat,yhat_lower,yhat_upper\r\n" qs = (PredResult.objects.filter(model_name="lgbm") .order_by("sku_id", "biz_date") .iterator(chunk_size=2000)) for r in qs: yield f"{r.sku_id},{r.biz_date:%Y-%m-%d},{r.yhat:.2f},{r.yhat_lower:.2f},{r.yhat_upper:.2f}\r\n" resp = StreamingHttpResponse(rows(), content_type="text/csv; charset=utf-8") resp["Content-Disposition"] = 'attachment; filename="forecast.csv"' return resp

content_type决定浏览器怎么解释响应体，text/csv; charset=utf-8让它按 CSV 处理并按 UTF-8 解码；Content-Disposition的attachment表示触发下载而不是内联预览，filename指定默认文件名。如果文件名要带中文，直接塞进filename会因为 HTTP 头不允许非 ASCII 字符而报错，标准做法是加一个filename*=UTF-8''的百分号编码版本作为兜底。

5. 开题答辩最容易被追问的三件事

系统能跑起来只是及格线，评审老师真正在意的是结论站不站得住。

5.1 用固定随机种子与数据快照保证可复现

任何一次跑出的指标都要能被重新跑出来。做法有两步：代码里所有涉及随机的环节显式传random_state，包括 LightGBM、sklearn 的划分函数、numpy 的采样；数据侧存一份快照，把训练用的DailySales按biz_date区间导出成 parquet 放在data/snapshots/下，文件名里带日期。这样即使原始订单表被后续增量刷新，也能回到当时那份数据重跑一遍。答辩演示前把快照和对应的指标文件一起放进仓库，被问「这个数怎么来的」时能当场复现，比任何解释都有说服力。

5.2 特征重要性与残差检查

LightGBM 训练完直接调model.feature_importances_，把排名前 15 的特征画成横向柱图。通常lag_7、roll_mean_28会排最前，如果is_promo排到了第一，说明促销样本太少、模型在记住异常点，这时候要检查促销日历是不是标错了。残差检查更直接：把回测期的真实值 - 预测值按日期画散点，如果残差整体偏正或者偏负，说明模型有系统性偏差，大概率是缺失了趋势项或者某个大促没有打标。这两张图放进开题报告的实验章节，比堆一堆指标表格更让人信服。

5.3 waitress + nginx 部署与漂移监控

Windows 上演示常用 waitress 加 nginx 反向代理，waitress-serve --listen=0.0.0.0:8000 salesforecast.wsgi:application起服务，nginx 里把client_max_body_size调大到 20M 以上，否则导出接口在大批量请求下会被拦。上线之后跑一个轻量监控：每周算一次最近 7 天的 WAPE，超过阈值就触发重训练。

监控项	触发阈值	处理动作
近 7 天 WAPE	高于基线 30%	标记该品类，人工核查促销打标
预测值连续 3 天为 0	任意 SKU	检查源数据是否断流
任务执行时长	超过上次的 2 倍	排查聚合 SQL 是否走全表扫描
特征缺失率	超过 5%	暂停该 SKU 预测输出，避免误导