Django+ECharts构建网易云音乐可视化大屏：从数据清洗到用户画像实战

简介：一份面向高校计算机专业学生与科研从业者的网易云音乐可视化项目资料包，基于Python与Django框架构建数据大屏，聚焦用户画像与播放行为分析，适合用作毕业设计、课程设计或项目初期演示。资源共54个文件，以24个Python源码文件为核心，辅以11个编译文件、4个CSV数据表、7个PNG可视化图表、3份Markdown说明文档，并包含设计报告PDF、字体与图片素材，整包约10.57MB。内容覆盖从数据采集到展示的完整流程，包括Scrapy框架爬取网易云热歌榜数据、存储至MySQL、通过Django进行可视化分析等关键环节，数据表保存歌曲与用户信息，图表直观呈现分析结果。同时提供设计报告与详细说明文档，便于理解系统架构和复现项目。目前已有62人学习，适合具备一定Python基础的开发者直接运行体验，或在此代码基础上扩展其他音乐平台的可视化分析功能。

1. 网易云音乐可视化（Python）到底在做什么：从听歌记录到一张能汇报的Django大屏

如果你手里有一批网易云音乐的播放记录——时间、歌曲、歌手、听了多少秒——普通的做法是拉几张 Excel 透视表自己看。但当你需要在周会上把“我们的用户到底喜欢什么”讲清楚时，一张静态表格的说服力远不如一面实时跳动的可视化大屏。这个项目标题指向的正是这样一条链路：用 Python 清洗数据，用 Django 提供数据接口，用 ECharts 在浏览器端渲染大屏，最终把「用户画像」和「播放行为分析」两个模块做成可交互的看板。它适合三类人：想练手 Django 完整项目的进阶新手、需要给运营团队做用户行为看板的数据分析师、以及想把“技术 Demo”做成“能汇报的成品”的开发者。接下来的篇幅，我会顺着数据建模、画像计算、行为聚合、大屏渲染这条线，把每一步怎么做、参数怎么调、坑在哪讲透。

2. 先把数据喂进 Django：模型设计与日志清洗的最小闭环

2.1 数据从哪来：可复现的本地听歌记录导入路径

网易云音乐的对外 API 早已收紧，直接爬接口的路子既不稳定也不合规。常见的做法是：拿自己账号导出的听歌记录 JSON，或者找公开的 Last.fm 听歌记录数据集做字段映射。这两类数据里通常包含这样几个字段：歌曲名、歌手、播放发生的时间戳、歌曲总时长（秒）、本次实际播放时长（秒）。如果你的数据源里没有“实际播放时长”，只有一个播放次数，也能做行为分析，只是“跳过率”这一类指标会退化成“点击次数”。

拿到数据后，第一步不是写 Django 代码，而是先做一次结构体检。我一般会用一段纯 Python 脚本把 JSON 拍平，确认字段名和类型，再决定 Model 怎么设计。千万别跳过这一步——不同日期导出的记录，字段名常常不一致，有的叫song_name，有的叫music_name，在模型层统一字段名能省掉后面 90% 的麻烦。

2.2 建三个表还是建一张宽表：这个项目推荐单表加索引

标题里同时出现了「用户画像」和「播放行为分析」，很多新手一开始就设计了三张表：用户表、歌曲表、播放记录表。但本地数据集的规模通常只有几千到几万条，做三张表关联反而让查询变慢、代码变绕。我更推荐单表方案：一张PlayRecord宽表，把用户标识、歌曲信息、播放时长、时间戳全放进去，用户画像通过聚合这张表得出，播放行为分析也直接查这张表。

# listening/models.py from django.db import models class PlayRecord(models.Model): user_id = models.CharField(max_length=64, db_index=True) song_name = models.CharField(max_length=128, db_index=True) artist = models.CharField(max_length=128, db_index=True) played_at = models.DateTimeField(db_index=True) # 播放发生时间 song_duration = models.IntegerField(default=0) # 歌曲总时长（秒） played_seconds = models.IntegerField(default=0) # 实际播放时长（秒） album = models.CharField(max_length=256, blank=True) # 专辑名，可能为空 class Meta: ordering = ['-played_at'] indexes = [ models.Index(fields=['user_id', 'played_at']), ]

这段模型里有两个容易忽略的设计点。db_index=True不是随便加的，后面做“按小时聚合播放量”“按用户分组算平均时长”这类查询，全靠这两个索引撑速度；played_at用DateTimeField而不是DateField，因为播放行为分析里要拆出“几点钟”这个维度，存日期会丢掉小时信息。song_duration和played_seconds我特意都设了默认值 0，真实数据里脏数据常常缺这两个字段，给默认值是清洗兜底的第一道防线。

2.3 清洗脚本：脏数据过滤与默认值兜底

模型建好之后，写一个独立的清洗脚本，把原始 JSON 转成可直接bulk_create的对象列表。重点处理三类问题：时间戳格式不统一、时区偏移、以及播放时长大于歌曲总时长的逻辑错误。

# listening/utils/clean_data.py import json from datetime import datetime, timezone, timedelta from listening.models import PlayRecord def parse_ts(ts_str): """兼容两种常见时间格式：ISO字符串和毫秒时间戳""" if isinstance(ts_str, (int, float)): return datetime.fromtimestamp(ts_str / 1000, tz=timezone.utc) return datetime.fromisoformat(ts_str.replace('Z', '+00:00')) def load_records(json_path: str, user_id: str) -> list[PlayRecord]: with open(json_path, 'r', encoding='utf-8') as f: raw_items = json.load(f) records = [] for item in raw_items: played_at = parse_ts(item['playTime']) # 中国时区转本地时间，方便后续按小时/星期聚合 played_at = played_at.astimezone(timezone(timedelta(hours=8))) played_seconds = int(item.get('playedSeconds', 0) or 0) song_duration = int(item.get('songDuration', 0) or 0) # 逻辑错误过滤：实际播放超过总时长说明数据有问题 if song_duration > 0 and played_seconds > song_duration: played_seconds = song_duration records.append(PlayRecord( user_id=user_id, song_name=item['songName'], artist=item['artist'], played_at=played_at, song_duration=song_duration, played_seconds=played_seconds, album=item.get('album', ''), )) return records

这里几个参数值得解释。tzinfo的转换不是玄学——很多公开数据集存的是 UTC 时间，如果不转成东八区，后面“凌晨 1 点听歌人数最高”会算到早上 9 点去。played_seconds > song_duration这条过滤规则是血泪经验，本地导出数据里经常出现播放了 5 分钟但歌曲总共只有 3 分钟的情况，不拦截的话“平均播放时长”这个指标会直接失真。写入时用PlayRecord.objects.bulk_create(records, batch_size=500)，几千条数据一次性写入耗时可忽略，比逐条save()快一个数量级，这是 Django 大批量导数据的基本操作。

3. 用户画像计算：五个维度把听众拆成可解释的标签

3.1 画像标签体系：年龄性别拿不到，就用行为倒推

拿不到用户的性别和年龄是音乐场景的常态，所以用户画像不能照搬电商那套“人口属性画像”，要做“行为画像”。我一般拆成五个维度：活跃时段偏好（夜猫子/晨间型）、播放深度（完整听完/频繁切歌）、风格倾向（通过歌手和歌曲名做关键词分类）、收听黏性（连续活跃天数）、曲目多样性（去重歌曲数/总播放次数）。每个维度都对应一个可解释的标签，比如“深夜emo型”“通勤快进党”“老歌收藏家”。

这套体系的好处是，它不用外部数据，直接从PlayRecord表聚合就能算出来。但要注意，风格倾向的分类不能靠人工维护一份歌手清单，那样会累死人。我用的办法是做一个简单的规则分类器，从歌名和歌手名里匹配预设关键词，比如“Live”“现场”归为现场版，“钢琴”“吉他”归为器乐/民谣，匹配不到的统一丢进“其他”类别。

3.2 画像计算：用 Django ORM 聚合还是 pandas，一万条数据怎么选

数据量在一万条以内时，直接用 Django ORM 聚合就够了，不必把数据导到 pandas 里绕一圈。下面这段代码在views.py里完成画像的粗算，输出一个字典，后续直接 JSON 序列化给前端。

# listening/services/profile.py from django.db.models import Count, Avg, F from django.utils import timezone from listening.models import PlayRecord def build_user_profile(user_id: str, days: int = 90) -> dict: cutoff = timezone.now() - timezone.timedelta(days=days) qs = PlayRecord.objects.filter(user_id=user_id, played_at__gte=cutoff) # 维度1：时段偏好，把播放时间按小时拆桶 hour_dist = {h: 0 for h in range(24)} for played_at in qs.values_list('played_at', flat=True): hour_dist[played_at.hour] += 1 # 维度2：播放深度=实际播放/总时长均值 depth = qs.aggregate( avg_played=Avg('played_seconds'), avg_total=Avg('song_duration'), ) play_depth = 0.0 if depth['avg_total'] and depth['avg_total'] > 0: play_depth = round(depth['avg_played'] / depth['avg_total'], 2) # 维度3：黏性=活跃天数 active_days = qs.values('played_at__date').distinct().count() # 维度4：多样性=去重歌曲数/总播放次数 distinct_songs = qs.values('song_name').distinct().count() total_plays = qs.count() diversity = round(distinct_songs / total_plays, 2) if total_plays else 0 return { 'user_id': user_id, 'hour_dist': hour_dist, 'play_depth': play_depth, 'active_days': active_days, 'diversity': diversity, }

小时维度用played_at.hour遍历是没办法做 ORM 的 group by 的，因为数据库函数取小时虽然能聚合，但会写出ExtractHour这种可读性差的代码。数据量小的时候直接遍历列表反而清晰。但这里有个隐藏的性能坑：qs.values_list('played_at', flat=True)会一次性把所有记录的时间加载进内存，如果记录数超过五万，建议改成ExtractHour配合annotate在数据库端完成。

3.3 画像结果落库与增量更新：给大屏加一层“后悔药”

画像计算结果不该每次请求都现算，尤其是大屏要定时刷新时，重复聚合几十万条记录会让页面越刷越慢。常见做法是建一张UserProfileSnapshot表，把画像结果以 JSON 字段落库，再设定一个缓存过期时间。前端访问/api/user-profile时，先查快照，快照过期才触发重算。

# listening/models.py class UserProfileSnapshot(models.Model): user_id = models.CharField(max_length=64, unique=True) profile_json = models.JSONField() updated_at = models.DateTimeField(auto_now=True) # listening/views.py from django.utils import timezone from datetime import timedelta def get_profile_snapshot(user_id: str): CACHE_MINUTES = 30 try: snap = UserProfileSnapshot.objects.get(user_id=user_id) if timezone.now() - snap.updated_at < timedelta(minutes=CACHE_MINUTES): return snap.profile_json except UserProfileSnapshot.DoesNotExist: pass profile = build_user_profile(user_id) UserProfileSnapshot.objects.update_or_create( user_id=user_id, defaults={'profile_json': profile} ) return profile

这里CACHE_MINUTES = 30是根据大屏刷新频率定的——如果大屏 5 秒刷一次，而画像本身变化很慢，30 分钟的缓存能挡住绝大多数重复计算。JSONField 是 Django 3.1 以后内置的字段，直接存储字典，省去序列化转换。落库的另一个好处是“后悔药”：前端展示异常时，你能立刻查快照是脏数据还是当前计算逻辑的问题，而不是面对一片空白的接口。

4. 播放行为分析的四个必看指标：时段、时长、跳过与循环

4.1 时段热力榜：工作日的早晚高峰与周末的午后小高峰

播放行为分析的核心不是单个用户，是整体趋势。我做可视化大屏时，最常放的四个指标分别是：24 小时播放热力、平均收听时长、歌曲跳过率、循环播放率。其中时段热力直接用 SQL 层的GROUP BY配合 Django 的ExtractHour完成，效率远高于 Python 遍历。

# listening/services/behavior.py from django.db.models.functions import ExtractHour, ExtractWeekDay from django.db.models import Count def hour_heatmap(user_id: str = None): qs = PlayRecord.objects.all() if user_id: qs = qs.filter(user_id=user_id) # 按小时+星期几聚合，形成 7x24 热力矩阵 heat = (qs .annotate(hour=ExtractHour('played_at'), weekday=ExtractWeekDay('played_at')) .values('weekday', 'hour') .annotate(cnt=Count('id')) .order_by('weekday', 'hour')) matrix = [[0 for _ in range(24)] for _ in range(7)] for row in heat: matrix[row['weekday'] - 1][row['hour']] = row['cnt'] return matrix

ExtractWeekDay返回值 1 是周日、7 是周六，所以代码里做了row['weekday'] - 1的索引偏移，这个细节不处理，热力图横纵轴会对不上。matrix初始化的7x24全零矩阵是必须的，否则数据库里没有记录的时段会是空值，前端 ECharts 热力图拿到None会直接不渲染整块区域。返回给前端时，记得把matrix包一层：

return {'matrix': matrix, 'x_labels': [f'{h}:00' for h in range(24)]}

4.2 跳过率与循环率：两个需要定义清楚再做聚合的指标

“跳过”和“循环”这两个指标最容易引发歧义，不先定义就写代码，后面一定返工。我用的定义是：跳过率 = 播放时长小于歌曲总时长 30% 的记录占比；循环率 = 24 小时内同一用户播放同一歌曲至少 2 次的歌曲占比。前者反映内容吸引力，后者反映用户黏性。

# 跳过率：用条件聚合一次算出来 from django.db.models import F, FloatField, ExpressionWrapper def skip_rate(user_id: str = None): qs = PlayRecord.objects.all() if user_id: qs = qs.filter(user_id=user_id) result = qs.aggregate( total=Count('id'), skipped=Count('id', filter=Q( played_seconds__lt=F('song_duration') * 0.3 )) ) return round((result['skipped'] / result['total'] * 100), 1)

Count('id', filter=...)是 Django 2.0 以后支持的条件聚合，能在一个查询里同时拿到总数和符合条件的子集数量，不必写两条 SQL。F('song_duration') * 0.3直接在数据库里做字段间的比较，而不是把数据拉回内存。值得注意的是，song_duration = 0的脏数据会让这条规则失效——播放时长永远大于总长效 30%，所以清洗阶段把song_duration = 0的记录剔除掉，或者在这里加一条.exclude(song_duration=0)。

4.3 大屏数据接口：JSON 序列化与避免 N+1 查询

行为分析接口的输出最终要交给前端，格式上建议统一成{code, data, msg}三件套。用 Django 原生的JsonResponse最省事，但要注意datetime对象的处理，Django 内置的DjangoJSONEncoder会把datetime转成 ISO 字符串，而ExtractHour返回的int没有这个问题。如果字段里混入了Decimal或UUID，就需要自定义json.dumps的default参数。

大屏几个接口并发访问时，最常见的性能坑是 N+1 查询——比如先取 10 首歌，再对每首歌查一次播放记录。解决方式是不要循环查库，用values+annotate一次拿到聚合结果。

# 播放行为 Top 歌曲榜，一条 SQL 搞定 from django.db.models import Sum def top_songs(limit=10): return (PlayRecord.objects .values('song_name', 'artist') .annotate(total_plays=Count('id'), total_seconds=Sum('played_seconds')) .order_by('-total_plays') .values('song_name', 'artist', 'total_plays', 'total_seconds') [:limit])

values('song_name', 'artist')后面的annotate会自动按这两个字段分组，这是 Django ORM 里最容易忽略的语法细节——values在annotate前出现，就变成了GROUP BY的声明，而不是查询列。total_seconds字段前端可以直接拿来算“人均收听时长”，不必再让后端加工。

5. 网易云音乐可视化大屏的避坑清单：乱码、空数据与缓存穿透

5.1 中文乱码：JsonResponse 输出\uXXXX转义序列

现象：前端拿到接口返回后，中文全部变成\u97f3\u4e50这样的转义序列，标题栏一片乱码。 原因：Django 的JsonResponse默认使用json.dumps(ensure_ascii=True)，会把所有非 ASCII 字符转成\uXXXX。前端如果直接用字符串渲染，浏览器能解析，但落入页面后一旦被innerHTML二次处理，就变成字面量了。 解决：

from django.http import JsonResponse from django.core.serializers.json import DjangoJSONEncoder def json_response(data): return JsonResponse( {'code': 0, 'data': data}, encoder=DjangoJSONEncoder, json_dumps_params={'ensure_ascii': False} )

ensure_ascii=False让接口直接输出中文原文，配合charset=utf-8响应头，彻底断掉乱码的根。

5.2 空数据让整个大屏白屏：图表组件必须在数据为空时显式返回

现象：导入的是试用数据集，某个月份没有播放记录，结果大屏上所有 ECharts 图表直接不渲染，浏览器控制台报data is undefined。 原因：画布组件在初始化时拿到None或空数组，series.data无法建立坐标系。 解决：接口层永远返回结构完整的空值，不要省略字段。后端做一层兜底：

if not matrix or all(all(v == 0 for v in row) for row in matrix): matrix = [[0 for _ in range(24)] for _ in range(7)]

前端在setOption前加一句：

if (!data || data.length === 0) { chart.clear(); return; }

这样即使没数据，大屏也能显示“今日暂无播放”的占位状态，而不是整块白屏，运营人员不会误以为系统挂了。

5.3 高频刷新把数据库拖垮：SQLite 与 MySQL 的分水岭

现象：大屏 5 秒轮询一次/api/hour-heatmap，数据库连接数被占满，其他页面打开变卡。 原因：Django 开发服务器默认开多个线程，每个请求都占用一个连接。SQLite 对并发写支持差，读多写少时连接池很快就到瓶颈。 解决：本地演示时把CONN_MAX_AGE设为 60，让连接复用；正式部署换 MySQL 或 PostgreSQL 并配置连接池。另一个取巧的办法是给热点接口上 Redis 缓存，再用 Redis 可视化工具直接观察 key 过期状况，排查到底是接口慢还是数据没更新。高德地图在 Redis 里没有这种体感，但缓存穿透时你会立刻看到Cache Miss数量暴涨。

5.4 ECharts 大屏在 2K 显示器上错位：根字体缩放是唯一解

现象：在 2560 分辨率下大屏布局正常，换到 1920 投影时右侧图表溢出屏幕。 原因：大屏设计稿通常按 1920×1080 制作，但浏览器默认字号固定，ECharts 容器宽度用了固定像素值。 解决：在 HTML 模板里加一段全局缩放脚本，让根字体跟随宽度变化，图表内所有字号和间距全部用rem表达。在 Django 的base.html底部插入：

<script> (function () { var baseWidth = 1920; var scale = document.documentElement.clientWidth / baseWidth; document.documentElement.style.fontSize = 100 * scale + 'px'; })(); </script>

这样大屏布局在每个分辨率下等比缩放，而不是横向滚动。注意图表初始化需要放在缩放之后，否则取到的容器宽度是缩放前的。

5.5 播放历史里混入“单曲循环”导致的画像失真：去重策略

现象：某个用户一天内把同一首歌听了 80 遍，画像结果显示“该用户风格高度集中”，但他其实只是下午写代码时开了单曲循环。 原因：单曲循环生成的连续重复记录，会被当成强烈的风格偏好信号。 解决：在清洗阶段对连续重复记录做合并——同一个user_id + song_name + artist，且相邻两条记录时间差小于 10 秒，视为一次循环播放的续听，只保留第一条。注意后续的时长统计要从原记录里取总和，不能直接丢数据。

6. 大屏渲染进阶：WebSocket 实时推送、组件联动与刷新验证

前面章节的数据接口都是“前端主动拉”，这在大屏演示时有个明显缺陷：每次刷新都有 100~300ms 的肉眼可见延迟，而且轮询太频繁会加重接口压力。进阶做法是用 WebSocket 做服务端推送——Django 里最流行的方案是channels库，后端一有新的聚合结果就主动推到浏览器，前端不用发请求。

# listening/consumers.py（使用 channels 的 WebSocket 消费者） import json from asgiref.sync import async_to_sync from channels.generic.websocket import WebsocketConsumer class DashboardConsumer(WebsocketConsumer): def connect(self): self.group_name = 'dashboard' async_to_sync(self.channel_layer.group_add)(self.group_name, self.channel_name) self.accept() def disconnect(self, code): async_to_sync(self.channel_layer.group_discard)( self.group_name, self.channel_name ) def send_metrics(self, event): self.send(text_data=json.dumps(event['data']))

配套的数据推送逻辑可以放在views.py里，当缓存刷新完成时调用async_to_sync(channel_layer.group_send)。我做过的最小闭环是：Django 定时任务每 30 秒重算一次指标，算完推到 WebSocket 组，前端收到后更新 ECharts 的series.data，全程无刷新闪烁。这个方案比轮询优雅，但也要接受它的代价：需要部署daphne或uvicorn作为 ASGI 服务器，开发环境的runserver不支持 WebSocket。

大屏最终验收时，我会做三件事：第一，用无痕窗口打开页面，确认首次加载时间在 3 秒以内；第二，切到 1366×768 分辨率，确认缩放没有裁切右侧图表；第三，断网刷新一次，看页面是否给出了友好的错误提示而不是无限 loading。我自己跑过几次这类项目后的习惯是，把刷新频率、缓存时间、数据量三个参数写进配置文件，每次调试只改配置不动代码。大屏工具收到告警时，第一件事就是去查配置参数，而不是翻代码。这个习惯帮我省了很多“昨天还能显示今天突然白屏”的排查时间，希望帮到你。

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