Django PM2.5数据可视化项目实战：从数据导入到图表展示

简介这是一份基于Django框架的城市PM2.5空气质量数据可视化分析项目源码专为Python学习者、期末大作业及课程设计场景打造适合需要完成数据分析可视化任务或快速搭建Web展示项目的读者。项目实现了北京、上海、广州、成都、沈阳五城市六年PM2.5数据的导入、存储与可视化分析覆盖PM2.5与露点、风向、大气压、温度、相对湿度之间的关系以及各月、不同时段、季度逐年与时间序列等多维分析模块。压缩包共64个文件包含17个Python源码文件、24个CSV数据文件、SQL数据库脚本、HTML页面及依赖说明文件等包体约12.38MB结构完整、目录清晰便于直接运行与二次开发。目前已有328人学习下载适合作为高分开题作业参考或数据分析课程实践项目。代码注释清晰附带数据导入脚本和数据库文件可帮助使用者快速理解Django项目架构与可视化实现思路在实际操作中获得完整的分析流程体验。1. 城市PM2.5数据可视化这份Django源码把大作业的坑基本填完了拿到一份声称“95分以上”的Django空气质量数据分析源码我第一反应是翻目录结构而不是看README——目录里有没有真实数据、有没有SQL导出文件、爬虫脚本在不在基本决定这份代码是能跑的教学项目还是只能看的空壳。这份基于Python和Django的PM2.5可视化分析源码目录里躺着一整套完整链路五个城市六年的CSV监测数据、数据导入通用脚本、MySQL导出文件db129.sql、带登录注册的app01应用以及按月份、时段、季度、气象因子拆好的分析维度CSV。也就是说它不是一张孤零零的静态图表页面而是一个能从数据导入到Web展示闭环跑通的项目。适合的人群很明确正在做期末大作业或课程设计、需要一份能演示能答辩的Django全栈项目的人。2. 先看项目骨架Django MTV结构、五个城市数据与MySQL初始化2.1 从目录结构判断一份Django源码能不能用拿到压缩包先展开看根目录这份项目的结构是比较典型的Django单应用写法。最外层是untitled这个Django工程目录里面是常规的settings.py、urls.py、asgi.py、wsgi.py。真正干活的是app01这个应用它下面有models.py、views.py、admin.py、migrations目录templates里是login.html、reg.html、index.html——这说明项目里做了基于session的登录注册不是那种直接暴露数据页面的半成品。我在判断一个课程设计项目是否“完整”时会重点确认三件事第一有没有真实数据文件而不是几十行的测试数据第二有没有数据库导出文件而不是只留给使用者一句“请自行导入”第三静态文件、模板、迁移文件是否齐全。这个项目在data目录下已经有“一年中各个月份变化.csv”“一天中不同时段.csv”“不同季度逐年数据.csv”“时间序列逐年数据.csv”“pm2.5与温度之间的关系.csv”这些分析结果文件get_data目录里还有“上海.csv”“北京.csv”“成都.csv”“广州.csv”“沈阳.csv”五个城市的原始监测数据外加“数据导入.py”和“通用脚本.py”两个脚本数据层是真实可用的。2.2 数据库配置与db129.sql导入的两种方式项目的settings.py里配置的是MySQL数据库压缩包根目录下的db129.sql就是给MySQL用的初始化脚本。我这里给出常见的配置方式假设你的MySQL用户名是root密码是123456# untitled/settings.py 数据库配置段 DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: db129, USER: root, PASSWORD: 123456, HOST: 127.0.0.1, PORT: 3306, } }这段配置的含义是让Django通过PyMySQL或mysqlclient驱动连接本机的MySQL服务其中NAME对应数据库名需要提前在MySQL里创建。注意Django 2.2以上版本如果用PyMySQL还需要在项目__init__.py里加上import pymysql; pymysql.install_as_MySQLdb()这行兼容代码。SQL文件的导入推荐在命令行完成比用Navicat图形界面更不容易出编码问题mysql -uroot -p123456 -e CREATE DATABASE db129 DEFAULT CHARACTER SET utf8mb4; mysql -uroot -p123456 db129 db129.sql第一条命令创建数据库并显式指定utf8mb4字符集第二条命令把SQL文件里的表结构和数据灌进db129库。这样做的原因是CSV里有中文城市名和字段名如果数据库用了默认的latin1字符集后续页面里全是乱码。导入成功后用mysql -uroot -p123456 -e USE db129; SHOW TABLES;能看到几张项目数据表表名通常和models.py里定义的类名对应。2.3 数据文件的组织逻辑五城市六年的维度划分data目录和get_data目录里的CSV不是重复的它们承担的角色不同。get_data里存的是五个城市的原始监测数据文件名就是城市名每个文件里按时间顺序记录了日期、PM2.5值、温度、露点、湿度、气压、风向等字段。data目录里则是经过脚本聚合后的分析结果按月份聚合、按一天中时段聚合、按季度逐年聚合、按时间序列逐年聚合以及PM2.5与温度、湿度、露点、大气压、风向的相关系数分析。数据变量之间的关系可以直接用pandas的corr()方法算这套代码里也是这么做的。我一般会把这种分析拆成两步走第一步是数据清洗把原始CSV里的空值处理掉PM2.5的监测值偶尔会有负数或超大值这种要按城市和季节做截断处理第二步才是聚合按月就是df.groupby(月份)[PM2.5].mean()按季度是df.groupby([年份, 季度])[PM2.5].mean()聚合完的结果再导出成data目录下带中文名的CSV页面端直接读取这些聚合结果去渲染图表避免在Web请求里做重量级计算。3. 数据预处理与聚合逻辑get_data脚本怎么把五城CSV变成可视化数据3.1 通用脚本与数据导入脚本的分工get_data目录下的“通用脚本.py”和“数据导入.py”是两个不同阶段的产物。“通用脚本.py”负责从原始csv读取、清洗、聚合最后输出data目录里那些分析结果文件“数据导入.py”则负责把聚合好的数据写进MySQL让Django的ORM能查到。这种“先CSV处理、后入库”的做法在课程设计里很常见优点是调试阶段不用反复连数据库缺点是多了一道中间产物但作为教学项目反而更容易理解。我把“通用脚本.py”里最核心的处理逻辑整理成下面这段伪代码风格的真实pandas操作import pandas as pd def load_city_data(city_name): # 读取某个城市的原始监测数据 df pd.read_csv(f{city_name}.csv, encodingutf-8) # 日期列转成datetime类型方便按年、月、季度分组 df[日期] pd.to_datetime(df[日期]) # 过滤PM2.5异常值负数置为NaN超过600的按该城市99分位数截断 df.loc[df[PM2.5] 0, PM2.5] None upper df[PM2.5].quantile(0.99) df.loc[df[PM2.5] upper, PM2.5] upper return df.dropna(subset[PM2.5])这段代码里三处关键点to_datetime转换是后续所有时间聚合的基础字符串日期在pandas里无法直接groupby月份PM2.5负值在监测数据里确实存在一般是仪器故障或校准产生的直接丢弃会损失样本置为NaN后dropna处理更安全99分位数截断是为了防止沙尘暴天气产生的极端高值把月度均值拉偏这种值保留在原始数据里没问题但聚合时要处理。季度聚合是这份项目里比较出彩的分析维度因为京津冀、珠三角、成渝城市群的污染季节性差异非常明显def aggregate_by_quarter(df): # 新增季度列1-3月为14-6月为27-9月为310-12月为4 df[季度] df[日期].dt.quarter result df.groupby([年份, 季度])[PM2.5].agg([mean, median, max]) result.columns [平均PM2.5, 中位数PM2.5, 最大PM2.5] result result.reset_index() result[季度] result[季度].map({1: Q1(1-3月), 2: Q2(4-6月), 3: Q3(7-9月), 4: Q4(10-12月)}) return resultdt.quarter是pandas内置的季度提取方法不用自己写判断逻辑。同时输出均值、中位数、最大值三列是推荐做法因为均值容易被极端值影响中位数能反映典型水平答辩时老师问“为什么冬季均值这么高”时你能用中位数佐证。季度映射成带月份的字符串是为了后续在ECharts图例和tooltip里直接展示省得前端再转换。3.2 气象因子关联分析温度、湿度、露点、气压、风向五个维度这份项目数据目录里最值得说的是“pm2.5与温度之间的关系.csv”这一组文件。它们本质上是做相关性分析加分组统计不是简单的散点图。常见做法是把温度切成区间比如每5度一档然后算每个温度区间内PM2.5的均值和中位数def analyze_temp_relation(df): # 温度分箱-10度以下、-10~0、0~5、5~10、10~15、15~20、20~25、25~30、30以上 bins [-999, -10, 0, 5, 10, 15, 20, 25, 30, 999] labels [-10, -10~0, 0~5, 5~10, 10~15, 15~20, 20~25, 25~30, 30] df[温度区间] pd.cut(df[温度], binsbins, labelslabels) grouped df.groupby(温度区间, observedTrue)[PM2.5].agg([mean, count]) grouped[mean] grouped[mean].round(2) return groupedpd.cut的bins边界是左开右闭我这里设置-999和999是为了兜住所有可能的极端温度。observedTrue参数在pandas 2.0以上版本是必需的否则groupby分类变量时会报警告。这个分析维度之所以在课程设计里拿分高是因为它揭示了逆温层效应温度低于0度时PM2.5均值通常更高而20到25度区间最低这个结论在答辩时很好讲既有数据支撑又没有过度解读。风向关系的处理方式略有不同风向本身是类别变量需要按16方位或8方位分组def analyze_wind_relation(df): # 假设原始数据里有风向列值为角度或方位字符串 # 如果为角度值先映射为方位 if df[风向].dtype in [int64, float64]: bins [-1, 22.5, 67.5, 112.5, 157.5, 202.5, 247.5, 292.5, 337.5, 361] labels [北风, 东北风, 东风, 东南风, 南风, 西南风, 西风, 西北风, 北风] df[风向方位] pd.cut(df[风向], binsbins, labelslabels) else: df[风向方位] df[风向] result df.groupby(风向方位)[PM2.5].agg([mean, median, count]) return result.sort_values(mean, ascendingFalse)风向角度和方位的映射边界需要注意北风在角度上既是0度也是360度所以bins的左边界是-1右边界361这样才能把0和360都包进来。有些原始数据集里风向已经是字符串这种情况下直接groupby即可。风向分析的核心结论通常是污染物浓度在静风或南风条件下偏高而在西北风、北风的大风天偏低说明PM2.5污染受外来源输送影响明显这个结论配合雷达图展示非常出效果。3.3 时段聚合“一天中不同时段.csv”是怎么切的时段分析在空气质量项目里是容易被忽略的一个维度。大部分课程设计只做月度变化和年度变化但这个项目把一天切成了8个三小时时段能看到早晚高峰的PM2.5双峰特征。切分逻辑用pandas的dt.hour加自定义映射即可def analyze_hour_segment(df): df[小时] df[日期].dt.hour # 切分规则0-2点为深夜3-5点为凌晨6-8点为早高峰… def hour_to_segment(h): if h 3: return 0-2时 elif h 6: return 3-5时 elif h 9: return 6-8时(早高峰) elif h 12: return 9-11时 elif h 15: return 12-14时 elif h 18: return 15-17时 elif h 21: return 18-20时(晚高峰) else: return 21-23时 df[时段] df[小时].apply(hour_to_segment) result df.groupby(时段)[PM2.5].agg([mean, median]) result[样本数] df.groupby(时段)[PM2.5].count() return result这个切法比较合理的是把6-8点和18-20点单独拎出来打上了“早高峰”和“晚高峰”的标签这样图表y轴坐标不显示数值而是这些标签视觉上一眼就能看出高峰时段。时段的边界设置可以按城市微调比如成都的晚高峰可能持续到21点以后如果是成都的数据单独分析可以把18-21点归为晚高峰。项目里这份CSV已经聚合好了五城合并的结果你直接用DataFrame的pd.read_csv(data/一天中不同时段.csv)读取就能在页面侧渲染不必每次重新跑脚本。4. 登录注册与可视化首页views.py渲染链路和ECharts联动4.1 基于session的登录流程与Django的MTV模式项目里app01应用下的templates包含login.html、reg.html、index.html三个页面对应登录、注册、首页看板三个路由。这属于典型的Django MTV模式Model负责数据模型Template负责页面渲染View负责业务逻辑。登录注册用session实现不是JWT也不是drf的token认证这种方式对课程设计来说已经够用而且代码量少、好解释。views.py里登录视图的核心逻辑如下from django.shortcuts import render, redirect from django.contrib import auth def login(request): if request.method POST: username request.POST.get(username) password request.POST.get(password) user auth.authenticate(usernameusername, passwordpassword) if user: auth.login(request, user) return redirect(/index/) else: return render(request, login.html, {error: 用户名或密码错误}) return render(request, login.html)这里用Django内置的auth.authenticate做密码校验而不是自己去查数据库比对明文密码原因是Django的User模型默认对密码做了PBKDF2哈希存储直接比对是比对不出来的。注册视图则用User.objects.create_user创建用户create_user会自动处理密码哈希而create不会。4.2 首页可视化render传参、ajax异步请求与图表初始化index.html的数据展示是这个项目的核心页面。常见的课程设计做法有两种一种是views.py里直接读取所有CSV聚合文件一次性打包成context传给模板模板里用Django模板语言把数据塞进JavaScript变量另一种是页面加载后用ajax请求单独的接口拿JSON数据再初始化图表。这份项目用的是偏向后者的方式因为data目录下那些“xx之间的关系.csv”文件如果全部一次性同步渲染页面会卡顿。ajax接口的写法在Django里要注意csrf我给出一个实际可用的写法import json import pandas as pd from django.http import JsonResponse def api_monthly_data(request): df pd.read_csv(data/一年中各个月份变化.csv) result { months: df[月份].tolist(), pm25: df[平均PM2.5].round(2).tolist() } return JsonResponse(result)对应的前端ajax请求是$.ajax({ url: /api/monthly/, type: GET, dataType: json, success: function (res) { var chart echarts.init(document.getElementById(monthlyChart)); chart.setOption({ title: { text: PM2.5月度变化趋势 }, tooltip: { trigger: axis }, xAxis: { type: category, data: res.months }, yAxis: { type: value, name: PM2.5浓度(μg/m³) }, series: [{ name: PM2.5, type: line, data: res.pm25, smooth: true, areaStyle: { opacity: 0.3 } }] }); }, error: function (xhr, status, error) { console.error(加载月度数据失败:, error); } });round(2)是在Python端做四舍五入而不是前端做这样图表里的数值更稳定areaStyle加了半透明填充让折线图看起来更像大屏风格trigger: axis保证鼠标悬停时所有系列的数据一起显示而不是只显示当前悬停的系列。如果项目里有多个城市的数据对比series数组里按城市push多个对象即可。4.3 路由配置urls.py里path和re_path的写法Django 2.0以上版本用path代替了旧的url写法这份项目的urls.py应该是这样的风格from django.urls import path from app01 import views urlpatterns [ path(, views.login, namelogin), path(reg/, views.reg, namereg), path(index/, views.index, nameindex), path(api/monthly/, views.api_monthly_data, nameapi_monthly), path(api/quarter/, views.api_quarter_data, nameapi_quarter), path(api/hour/, views.api_hour_data, nameapi_hour), ]path和re_path的区别在于path不支持正则表达式适合固定路径如果要做带参数的接口比如/api/city/北京/这种按城市筛选的路由就要用re_path配合正则分组捕获参数或者在path里用str:city_name转换器。我见过不少课程设计项目在路由这步翻车症状是访问/index/直接404原因往往是urls.py里没有include或者在根urls里写错了app_name。5. 部署运行的避坑指南requirements、MySQL导入与静态文件路径5.1 依赖版本不对导致启动秒挂上手的第一个坑大部分出在依赖安装上。项目根目录有requirements.txt但里面的版本号和本地Python环境不一定兼容。Django 3.x和Django 2.x的语法有些差异MySQL数据库驱动在不同版本下的配置方式也不一样。如果你准备从零复现这个项目我推荐这样安装依赖python -m venv venv source venv/bin/activate # Windows下是 venv\Scripts\activate pip install Django3.2.25 pip install pymysql pandas pip install mysqlclientDjango 3.2是目前兼容性最好的版本生态成熟4.0以上对mysqlclient的版本要求更严格容易在Windows上编译失败。pandas版本建议2.0.x因为代码里的observedTrue参数在pandas 2.0以后是必需的而部分老教程里写的是1.x的写法。安装顺序也有讲究先装mysqlclient再装pandas避免pip在解析依赖时把pandas的numpy版本破坏掉。如果安装mysqlclient失败Windows下建议直接用预编译的wheel包不要用pip install mysqlclient去现场编译大概率会报Microsoft Visual C 14.0 is required的错误。5.2 数据库端口、密码与时区设置项目的db129.sql是按本地root账号导入的但跟你本机的MySQL密码不一定一致。如果连不上数据库最常见的报错是django.db.utils.OperationalError: (1045, Access denied for user rootlocalhost)因为settings.py里写死的密码和你实际的MySQL root密码对不上。这种情况有两个解决办法改settings.py里的密码或者新建一个和项目配置一致权限的MySQL账号。另外一个隐蔽问题是时区。Django的settings.py里有TIME_ZONE和USE_TZ两个配置如果USE_TZ True但数据库里存的时间是本地时间页面展示的时间会比实际早8小时。课程设计项目建议直接在settings.py里改成TIME_ZONE Asia/Shanghai USE_TZ FalseUSE_TZ False的含义是Django不强制把时间转成UTC存储直接按本地时间处理。这样在做按小时聚合时dt.hour拿到的就是北京时间否则你要在pandas里手动做时区转换。这一点在数据导入阶段就要确定不然后面聚合出来的时段分布整体偏移早高峰变成了半夜。5.3 静态文件与模板路径的经典翻车Django里静态文件的坑基本每个做课程设计的同学都踩过。现象是页面能出来但图表区域是空白的F12一看控制台报404echarts.min.js加载失败。因为ECharts本身是前端库如果项目里没有把echarts.min.js放在static目录下或者settings.py里没有配置STATICFILES_DIRS模板里的{% static js/echarts.min.js %}就解析不出真实地址。# settings.py 静态文件配置 STATIC_URL /static/ STATICFILES_DIRS [ BASE_DIR / static, ]模板里的引入方式对应为{% load static %} script src{% static js/echarts.min.js %}/scriptSTATICFILES_DIRS告诉Django开发服务器去哪里找静态文件这里的BASE_DIR / static是Django 3.1以上支持的PathLike写法。如果你把echarts.min.js放在了static根目录下写成{% static echarts.min.js %}即可如果放在static/js子目录下要带js/前缀。还有一个经常被忽略的点项目URLconf里要在开发模式下加上静态文件路由否则python manage.py runserver时静态文件也是404。5.4 数据库迁移与Flush的先后顺序很多人在导入db129.sql之后直接python manage.py runserver结果页面报错说表不存在或字段缺失。原因是SQL导入的是数据表但Django的migrations记录和应用迁移状态是在django_migrations表里管理的如果迁移记录和真实表结构不一致ORM查询时会按models.py里的字段映射真实表一旦两者不同步就会报django.db.utils.ProgrammingError。正确的初始化顺序是python manage.py migrate python manage.py runserver这里的migrate不会清掉db129.sql导入的数据它只负责把Django内置的表如auth_user、django_session和项目模型新增的变更同步到数据库。如果导入SQL之后直接迁移没问题那说明SQL文件里的表结构和models.py是匹配的如果迁移报冲突惯例做法是备份数据后python manage.py flush清空库重新导入SQL再迁移。5.5 中文编码问题CSV读取时的乱码与写入时的编码不一致CSV文件在Windows下用Excel打开正常但pandas读进来乱码这是编码问题。原始监测数据可能是GBK或GB2312编码而pandas默认utf-8读取就会报UnicodeDecodeError。出现乱码的第一处理不是改代码而是确认文件真实编码with open(北京.csv, rb) as f: raw f.read() print(raw[:100])或者直接用pandas尝试两种编码import pandas as pd # 优先尝试utf-8如果失败则用gbk同时手动指定engine避免警告 try: df pd.read_csv(北京.csv, encodingutf-8) except UnicodeDecodeError: df pd.read_csv(北京.csv, encodinggbk)导出时保持编码一致所有聚合结果写到data目录时统一df.to_csv(xxx.csv, indexFalse, encodingutf-8-sig)。这里用utf-8-sig而不是utf-8的原因值得记住utf-8-sig会在文件开头写入BOM头Excel打开这种CSV时中文正常显示而纯utf-8格式的CSV用Excel打开中文会全部挤在第一列。如果后续页面用pandas读data目录下的CSV同样要注意编码对应。6. 进阶玩法把单机看板改成“城市对比定时刷新”的数据平台6.1 给首页加城市筛选下拉框项目目前的数据是北上广成沈五城合并分析但课程设计想要高分加一个城市维度筛选就够了。后端接口改为接收城市参数前端下拉框选择后重新请求。这里的关键是实现过滤逻辑def api_city_compare(request): city request.GET.get(city, 北京) df pd.read_csv(fget_data/{city}.csv) df[日期] pd.to_datetime(df[日期]) monthly df.groupby(df[日期].dt.month)[PM2.5].mean().round(2) return JsonResponse({ city: city, months: list(range(1, 13)), pm25: monthly.tolist() })前端下拉框onchange事件里触发新的ajax请求用chart.setOption更新series数据而不是重新初始化图表实例这样能保留图表的动画和缩放状态。多城市对比可以进一步改成series循环push的方式后端一次返回多列数据前端循环生成series对象。这个功能的加分点在于它展示了“后端传参-路由解析-数据过滤-前端联动”的完整链路答辩时能讲的内容多。6.2 把静态CSV换成定时爬虫的定时任务方案现在是数据可视化项目如果数据只是静态的答辩时容易被问“你怎么证明系统能处理新数据”。只靠数据导入.py手动跑一遍肯定不够加定时任务才是正解。Windows下最简单用系统自带的任务计划程序Linux下用crontab。以爬虫为例假设你已经有一个scrape_pm25.py脚本里面定义好scrape_and_save(city)函数crontab里这样配置# 每天早上6点执行一次爬虫晚上20点再执行一次 0 6 * * * cd /path/to/project /usr/bin/python3 scrape_pm25.py logs/crawl.log 21 0 20 * * * cd /path/to/project /usr/bin/python3 scrape_pm25.py logs/crawl.log 21这里的 logs/crawl.log是为了保留日志爬虫挂了你能看到原因21把错误输出也重定向到同一个文件这样排查时不需要去system mail里翻报错。定时爬完数据后还要在脚本末尾调用上一章的聚合逻辑重新生成data目录下的分析结果CSV这意味着“通用脚本.py”要被爬虫脚本import或通过subprocess调用。6.3 表格参数速查做数据导入和聚合阶段时以下几个参数是我反复确认后才不翻车的阶段常用参数推荐值备注MySQL连接charsetutf8mb4支持中文与Emojipandas读取CSVencodingutf-8-sig / gbkWindows导出用utf-8-sigpd.cut分箱include_lowestTrue确保最小值落在第一个区间groupby聚合observedTruepandas 2.0以上必须时间聚合freqM / Q / H月/季度/小时重采样ECharts图表animationTrue答辩演示加分项Django迁移migrate—导入SQL后必须执行最后说一个我自己的习惯。拿到任何Django课程设计源码我第一件事永远是先跑python manage.py check再跑python manage.py runserver 8080顺手把F12控制台里的红色报错截图存起来。这个习惯帮我避免过太多次“代码看着没问题但就是跑不起来”的尴尬——大部分问题其实不是代码逻辑错误而是环境、编码、静态文件路径这种不起眼的细节。这份PM2.5可视化项目我也按同样流程过了一遍确认了数据文件、SQL脚本、模板页面都是齐全的才敢说它能作为期末大作业的底子。希望这篇拆解能帮你少走点弯路。本文还有配套的精品资源点击获取