1. 一个偏静态的景点列表，怎么变成实时可读的"景区热度看板"——项目整体设计
先说项目背景。当时我接到一个需求，某旅游信息服务平台打算做一轮"热门旅游景点"专题内容，手里其实并不缺数据——基础景点名录、用户评分、评论文本、售票渠道的预订量零零散散都有一点，但这些数据分布在不同的Excel表、第三方接口和数据库里，每次做专题都要让运营同学手工整理，一个景点一个景点地核对，效率低且口径不统一。领导层希望能有一个内部系统，输入城市或景点名称，就能快速看到这个景点的热度趋势、用户评价关注点以及同类景区排名。说白了，就是要一个"旅游景点热度数据分析与可视化后台"。
于是我用Django搭了整套系统，前后端分离，后端提供数据API，前端用ECharts渲染图表，数据层接了MySQL和Redis，采集端用Scrapy定时抓取公开数据，分析端用pandas做离线计算。整个项目从需求确认到第一版可用大概花了三周，核心功能包括：景点基础信息管理、热门度自动计算、多维度数据可视化（趋势折线图、城市分布地图、评论关键词词云、景区类型占比饼图）以及PDF报告导出。
这套系统上线之后，运营同学查一个景点的热度不用再翻三张表格，输入景点名点一下，三秒内出结果。而我个人最大的感悟是：这个项目真正有价值的地方不在"可视化大屏"本身，而在那个"热门度结果"是怎么算出来的——数据清洗口径、权重设计、更新策略，这些才是决定系统可用性的关键。下面我把整个建设过程拆开讲，从数据采集、热度模型、Django性能优化到可视化落地，每一步都有可以直接参考的实现细节。
2. 数据采集方案：公开数据集为主、定向补采为辅的双轨策略
2.1 先想清楚要哪几张表
动手写爬虫之前，我先把目标数据实体理清了。旅游景点数据分析，最核心的表一定是景点表，但它自己撑不起"热门"这个结论，必须搭配几个外围表一起统计。最终我设计了五张核心表：
| 表名 | 主要字段 | 数据来源 | 更新频率 |
|---|---|---|---|
| scenic_spots | 景点ID、名称、城市、省份、经纬度、类型（自然/人文/主题乐园等）、开放时间、票价区间 | 公开名录数据集 | 每周 |
| spot_reviews | 景点ID、用户评分（1-5分）、评论内容、评论时间 | 抓取公开评论 | 每天增量 |
| spot_visits | 景点ID、当日预约量/售票量、日期 | 合作渠道接口 | 每天 |
| spot_rankings | 景点ID、榜单类型、排名、上榜时间 | 平台榜单页面 | 每天 |
| city_dic | 城市ID、城市名、省份、行政区级别 | 行政区划库 | 月度 |
这里的核心思路是把"静态信息"和"动态数据"分开。景点名称、经纬度、类型这些一年变不了几次，没必要天天抓；而评分、评论、预约量这些高频变化的数据，才需要走增量更新。设计上分开存储，也为后面的热度计算提供了清晰的数据源。
2.2 采集端的实操方案
采集工作我并没有全用Scrapy裸写，而是分了两路：
一路是公开数据集导入。很多省市文旅部门、开放数据平台都会发布A级景区名录、星级景区名单，字段相对规整。我按月下载这些名录，清洗后导入scenic_spots表。这里有个小坑：同一个景区在不同名录里写法不一致，比如"黄山风景区"有的写成"安徽黄山"，有的带"国家级风景名胜区"后缀。我的处理方法是对景点名做规范化——去空格、统一繁体简体、去掉行政前缀后做一次去重合并，再人工抽检200条确保合并质量。
另一路是定向爬虫补采动态数据。评分和评论从公开评论站点抓，预约量从对接的渠道接口拉，榜单数据解析页面结构获取。因为旅游平台的反爬策略比较敏感，我没有做高并发，而是用Scrapy默认的并发设置，加上随机延迟中间件，每两个请求之间随机延迟3到8秒，每天定时任务在凌晨跑，单次任务控制在数十分钟内完成，跑了一个月没有出现过封禁。
# 随机延迟中间件片段 import random from scrapy import signals class RandomDelayMiddleware: def process_request(self, request, spider): delay = random.uniform(3, 8) time.sleep(delay) return None提示：如果你也想抓公开评论数据，尽量选择有明确API或开放协议的来源，比如某些平台提供了开发者接口申请通道，走正规接口比硬爬页面稳定得多。这里不具体指某个平台，但原则上"先找API，再考虑爬HTML"。
2.3 清洗规则里最容易被忽略的三个细节
数据清洗这件事，我踩了不少坑，说三个印象最深的：
第一个是评分的归一化问题。不同来源的评分口径完全不一样，有的平台是5分制，有的是10分制，还有的显示"4.5分"实际上是"4.48四舍五入"。清洗时我统一规定：所有评分先转成浮点数，再映射到百分制（原始分÷满分×100），存储时保留两位小数。这样后面热度模型里做加权就不会出现"一个5分制平台的4.8分和一个10分制平台的9.2分打架"的情况。
第二个是评论去重。同一段用户评论可能被不同渠道转载，直接统计关键词频率会把重复内容算成高热度。我做了一层基于内容hash的去重：评论正文先做jieba分词，取前50个词的词序列做MD5，如果hash相同就只保留最早那条。
第三个是缺失值处理策略。经纬度缺失的景点，我调用了一个本地离线坐标系转换库，根据地名粗略补充；票价缺失的，不填0而是填NULL，让统计层单独处理——因为票价0可能代表免费景观，也可能就是没采集到，混为一谈会导致分析结果失真。
3. 热门度模型：评分、客流、舆情三要素的加权计算
3.1 为什么不能直接用"评分最高的就是最热门的"
这是整个项目里我花时间最多，也是我觉得最有价值的一部分。
最开始运营同学的需求很简单："把评分最高的前50个景点列出来就行。"但实操几天就发现问题了：一个4.9分但只有32条评论的小众景点，和一个4.7分但有两万条评论、每天预约量排全省前五的知名景区，哪个更"热门"？显然是后者。评价类数据的样本量本身就是一个信号——评论多说明去的人多、讨论的人多。直接按评分排序，等于把"口碑好"和"受欢迎"混为一谈。所以我构建了一个综合热度指数，把三个维度的数据合成一个0到100的分值：
- 口碑维度：基于用户评分的加权平均值，权重40
- 客流维度：基于景区预约量/售票量的近期趋势，权重40
- 舆情维度：基于评论数量级和评论情感倾向，权重20
这个权重分配当时是和各渠道运营讨论后定的，原因是对于"热门"这个概念，实际客流和行为数据比态度数据更有说服力——有人去了、有人在讨论，比单纯说一句好更有热度含金量。
3.2 各维度得分的具体算法
口碑评分（40分制）：取最近90天所有评分的加权平均，时间越近权重越高。具体做法是把评论按周分组，最近一周权重1.0、前一周0.9、再往前0.8……最多回溯13周。这样处理能避免"一年前被刷了一波好评，几个月后热度还在虚高"的问题。
import pandas as pd import numpy as np def compute_reputation_score(reviews_df): # reviews_df: 包含评论时间、评分（百分制） reviews_df['review_time'] = pd.to_datetime(reviews_df['review_time']) reviews_df['week_diff'] = ((pd.Timestamp.now() - reviews_df['review_time']).dt.days // 7).clip(0, 12) reviews_df['weight'] = 1.0 - reviews_df['week_diff'] * 0.1 weighted_avg = np.average( reviews_df['score'], weights=reviews_df['weight'] ) return round(weighted_avg * 0.4, 2) # 口径：百分制评分×40%客流评分（40分制）：这个维度用的不是当天的绝对值，而是近30天日均预约量与去年同期日均量（如果没有去年数据就用近90天均值）的比值。这样设计的原因很实际：不同规模的景区基础客流差异巨大，故宫和一个小型博物馆比绝对值没有意义，比"增长趋势"更能体现当前热度。比值大于1.2说明景区近期明显走热，得满分区间的高位；比值在0.8到1.2之间是平稳期；低于0.8则得分下降。另外为了防止节假日数据造成突刺，我还会把国家法定节假日这一天的数据单独剔除，用前后三天的均值替代。
舆情评分（20分制）：这个维度分两部分。第一部分是评论量的对数归一化——评论数取log10之后做一个min-max映射，这个处理很重要，因为热门景区的评论量级从几百到几十万都有，如果不取对数直接线性归一化，评论量少的景区基本全得0分。第二部分是情感倾向，用SnowNLP对评论摘要做情感判断，计算正面评论占比。两部分各占10分。
import math from snownlp import SnowNLP def compute_sentiment_score(comment_text): s = SnowNLP(comment_text) return s.sentiments # 0~1 之间的情感积极度最终热度指数就是这三个得分加总。为了验证这个模型没有跑偏，我拿历史三周的数据跑了一遍，把排名结果和当时平台自己的人工编辑推荐做了对比，Top 20重合率大约85%，说明模型和人工判断高度一致，剩下的15%反而是模型发现了人工没注意的上升期景点，这让我对这套算法有了信心。
3.3 离线计算与实时查询的配合
热度模型不是每次请求页面时现算的——那样性能上完全撑不住。我的做法是每日凌晨用pandas批量计算全量景点的热度分，写入一张hotspot_scores表，白天所有API都只查这张表。为了支持"当天数据也能反映"的场景，我给客流维度预留了一个实时修正参数：白天每隔两小时拉一次当天预约量，用EMA平滑方式叠加到当天的预估热度上。这样既保证了计算成本可控，又不至于让看板上的数据看起来是"昨天的"。
4. Django对大数据量的承接层设计：ORM优化、缓存策略与异步任务
4.1 最初版本为什么连数据库都扛不住
系统第一版是比较原始的写法——页面访问时直接ORM查找所有景点数据，在前端模板里做循环拼接图表配置。结果数据量到了十几万条评论、几千个景点的时候，页面打开就要3秒以上。我后来分析发现，主要原因有三个：
第一，查询没有走索引。spot_reviews表按spot_id查询评论时，字段上没建联合索引，导致全表扫描。第二，N+1查询广泛存在。列表页展示50个景点时，每个景点又单独查一次评分、一次评论数、一次预约量，总共150多次数据库往返。第三，图表配置在模板里拼JSON，每次请求都要重新序列化一遍几千个点的大数组。
这三个问题加起来，数据量一大，系统就变成了"能跑但不能用"。
4.2 三板斧：索引优化、聚合缓存、异步预热
先建索引。这一步最简单也最有效果。给常用的查询维度建了联合索引：评论表建（spot_id, review_time）复合索引，预约量表建（spot_id, visit_date）复合索引，热度分表建（spot_id, calc_date）复合索引。建完之后，单点景区的评论查询从几百毫秒降到了十几毫秒。
再上缓存。热门度API是读多写少的典型场景，我直接用Django自带的cache框架，接Redis做后端。按"景点详情"维度缓存热度分和聚合摘要，过期时间设为30分钟。这样最热的接口（景点详情页）的体验可以稳定在100毫秒以内。
from django.core.cache import cache def get_spot_hotscore(spot_id): cache_key = f"hotspot_score:{spot_id}" score = cache.get(cache_key) if score is not None: return score score = HotspotScore.objects.filter( spot_id=spot_id, calc_date=date.today() ).values('score', 'rank', 'trend').first() cache.set(cache_key, score, timeout=1800) return score最后把重计算全部挪到异步任务。热度模型计算、评论情感分析、PDF报告生成这类耗时的操作，统一放到Celery异步队列里。Web请求只负责"查已算好的结果"，绝不触发重计算。
4.3 大数据量下的分页策略：游标分页而不是页码分页
景点列表页最开始用传统页码分页，offset在数据量大时会越来越慢。我改成了游标分页：前端把最后一次返回的景点热度分和景点ID传给后端，后端用where条件直接定位下一页起点。这样即使有几万个景点，翻到最后一页的速度也和第一页差不多。
def cursor_paginated_spots(request): last_score = float(request.GET.get('last_score', 1000)) last_id = int(request.GET.get('last_id', 0)) qs = HotspotScore.objects.filter( calc_date=date.today(), score__lt=last_score ).exclude(spot_id=last_id).order_by('-score', 'spot_id')[:20] return qs注意：游标分页适合滚动加载的后台看板，但不适合"我想直接跳到第50页"的场景。如果你需要在页面上显示页码跳转，那还是老老实实用页码分页，但一定要在order_by字段上建好索引。
4.4 本地测试与生产环境数据量差异导致的坑
开发环境我用的SQLite，当时查询都很快，换到生产MySQL后发现接口慢了一倍不止。排查之后才发现是开发环境SQLite不区分大小写排序，而MySQL按utf8mb4_bin时大小写敏感，order_by的排序结果和开发环境不一致，导致缓存命中率下降。后来我把开发环境也切到MySQL的Docker容器，并在最开始的配置里就统一了字符集排序规则（utf8mb4_general_ci），这类问题就再没出现过。这个教训让我养成了一个习惯：新项目一开始就把开发、测试、生产三套环境的数据库类型保持一致，省后续很多排查精力。
5. 可视化落地的关键细节：图表选型、数据口径与交互设计
5.1 为什么选了ECharts而不是其他可视化库
对比了ECharts、Plotly、AntV G2、D3.js之后，我最终选了ECharts。核心原因有三点：
一是它对后端工程师最友好。ECharts的配置项是纯JSON对象，后端把统计结果序列化给前端，前端直接setOption渲染，不需要像D3那样自己操作SVG元素，开发效率高得多。二是地图能力开箱即用。城市分布地图用ECharts内置的geo组件，配一份GeoJSON就能展示省份热力图，不用额外引地图库。三是大屏适配经验成熟。ECharts配合CSS的rem/rem适配方案，能比较轻松地把图表缩放到不同分辨率的屏幕上。
5.2 四个图表的落地过程
城市分布地图：数据层先按省份聚合景点热度分，输出形如[{name: "浙江省", value: 86.5}, ...]的数组，前端用geo组件渲染。这里有一个关键点：景点经纬度不能直接用来在地图上打散点，因为热门景区会相对集中（比如一个城市有多个5A景区），直接打点会大面积重叠。我的做法是先用DBSCAN聚类把同一城市的景点热度合并，再按城市中心点打点，点的大小映射热度值。
热度趋势折线图：按天聚合热度指数，输出最近30天的序列。这个图本身很简单，但我额外加了一条7日移动平均线，因为单日热度数据受周末和天气影响抖动很大，移动平均线能让运营同学一眼看出趋势是上升还是下降。
评论关键词词云：每天定时任务把当天新增评论汇总后做jieba分词，过滤掉停用词，统计词频Top 100写入一张keyword_freq表。前端用词云图组件渲染。这个功能运营反馈很好，能快速看到用户对一个景区的核心评价维度——"排队""夜景""亲子""性价比"这些词一目了然。
景区类型占比饼图：这个图最简单，统计每种景点类型的数量占比，但加了一个联动逻辑——点击饼图的某个类型扇区，下方的景点列表会自动筛选出该类型的热门景区。这个交互让原本"只展示数据"的饼图变成了一个筛选器，后面我越用越觉得，可视化图表如果只是被动展示数字，价值就打折了，带交互的图表才能真的帮用户做信息筛选。
5.3 数据口径统一：前端绝不自己算聚合
项目初期有个前端的同学为了方便，直接在前端对后端返回的明细数据做reduce求和，结果出现了一个Bug：饼图占比总和是102%。排查后发现是浮点数累计求和导致的精度误差，再加上部分数据被重复统计。后来我定了一个规矩：所有汇总、占比、聚合逻辑一律在后端和离线计算中完成，前端只负责渲染后端给的结果。后端保证所有百分比之和精确等于100%（比例值不做四舍五入，最后一项用100减去前面的值倒推）。这条规矩执行之后，数据一致性问题基本绝迹。
5.4 大屏适配与性能的取舍
做了几个大屏页面之后，我深刻体会到——旅游热度看板这类系统，实际使用场景不是市中心的大屏，而是运营工位的普通显示器。所以我在设计时没有刻意做1920x1080的硬适配，而是采用了响应式方案：图表容器宽度用百分比，字体用rem，最小适配宽度1200px。刷新策略也做过调整：地图和词云这类重渲染组件，手动刷新按钮；趋势图和排行榜则允许30秒自动刷新。这样避免所有图表同时轮询接口，减轻后端压力。
6. 部署上线后的性能排查与日常运维
6.1 上线第一天就暴露的数据库连接泄漏问题
系统上线第一天，中午就收到告警：数据库连接数飙到80%以上。我这边部署用的是gunicorn多进程，每进程都维持着自己的连接池，服务一启动，几十个进程加上Celery worker的预创建连接，一下就把MySQL连接数吃满了。这个问题的标准解法是限制连接池大小，并为每个进程设置合理上限。我用的是django-db-connection-pool库，每进程连接池设为5，最大溢出3，配合gunicorn的--workers 4参数，把总连接数控制在了40个以内，告警解除。
6.2 Redis缓存穿透与热点集中在一次热搜事件中的处理
上线第二周遇到一个特殊情况：某个景点因为综艺节目取景突然爆火，运营同学在后台反复查询这个景点的热度趋势，接口日志显示Redis缓存一直未命中。查了之后发现缓存过期30分钟的设计在热点数据上失效了——每一次缓存过期后，如果紧接着有多个并发请求同时到达，Django中简单的get_or_create写法会导致大量请求一起打到数据库。
处理办法是给热点查询加互斥锁（上锁后只允许一个请求去查库回填缓存，其他请求短暂等待），并且把这种"综艺爆火型"景点的热点缓存设置为永不过期，每天凌晨定时重建一次。这样处理之后，即使同一个景点被反复高频查询，也不会压垮数据库。
import redis import time r = redis.Redis() def get_spot_detail_cached(spot_id): cache_key = f"spot_detail:{spot_id}" data = r.get(cache_key) if data is not None: return data lock_key = f"spot_detail_lock:{spot_id}" if r.set(lock_key, "1", nx=True, ex=5): try: data = query_detail_from_db(spot_id) r.set(cache_key, data, ex=1800) finally: r.delete(lock_key) return data time.sleep(0.1) return r.get(cache_key)6.3 每日定时任务的依赖链管理
数据采集、清洗、热度计算、图表数据预生成，这几个任务是典型的串行依赖关系。我一开始用Celery的定时任务各自独立调度，结果经常出现"热度计算跑完了，但评论统计还没更新"这种数据不同步问题。后来我把整个流程改成了一个工作流方式：采集任务完成后发一个信号，触发数据校验任务，校验通过后启动清洗入库，清洗完成后再触发热度计算，依次执行。核心实现上其实就是一套基于数据库状态的任务编排表，每步任务往表里写状态，下一步定时检查状态位。
这个编排方式比较轻量，比直接引入Airflow要简单不少，实际执行下来稳定性很高。我个人的体会是，中小规模的数据项目没必要一上来就上重型调度框架，先把依赖关系用状态表管理清楚，反而运维成本更低。
7. 踩坑记录：从评分被刷到节假日数据突刺，五个真实问题
整个项目从开发到上线，积累的踩坑记录差不多有二十多条，我把其中最有借鉴价值的五个拿出来复盘。
第一个坑：评分数据被"好评返现"污染。某渠道的评论区，有段时间大量出现固定文案的好评。清洗时我没做文本去重，导致该景点口碑分虚高。后来我在评分清洗流程中加了一条规则：文本相似度超过95%的评论，自动降权为原权重的20%，避免垃圾行为干扰统计。
第二个坑：节假日数据突刺。五一假期那几天，不少景区的客流数据直接翻了几倍，热度模型把"节假日临时高峰"算成了"长期热度上涨"，导致假期结束后排名还在高位停留了好几天。后来加上了节假日识别规则，所有法定节假日以及前后各一天的数据，都单独做平滑处理，不参与趋势计算。
第三个坑：时区问题导致预约量"提前消失"。渠道接口返回的日期字段是UTC时区，而MySQL存储用的是东八区，导致每天晚上8点以后的数据会被算到"第二天"，每天的当日客流统计少一块。修复很简单，入库前统一做时间转换，接口返回的UTC时间先转换到Asia/Shanghai再存库。
第四个坑：词云图里出现了景区名以外的乱码词。评论分词后有些网络用语、生僻地名被当成了关键词高频出现，词云变得不可读。后来维护了一个自定义停用词表，同时把景区名称表中的词加入jieba的用户词典，让景区名在分词时被完整识别，不会被切开或者被过滤掉。
第五个坑：排行榜排名跳变。因为热度分计算涉及评价、客流、舆情三个维度，某个维度更新很晚时排名会连续跳变，用户容易困惑——"这个景点怎么突然从第三变成了第一？"后来我规定热度分在当天计算完成后锁定，当天内不因数据增量更新而重算，只允许第二天的全量任务刷新。看板上的排名稳定了，用户反馈也正常了。
最后说几句实话
这套系统上线运行了几个月，目前每日调度稳定，运营团队日常使用正常。我自己的体会是，这个项目真正难的从来不是"用Django写接口"或者"配置ECharts"这种单点技术，而是把数据采集、清洗口径、热度模型、性能优化、前端交互这些环节串成一个闭环。
如果你也想做一个类似的项目，我的建议是先不要急着写代码，花两天时间把你想要分析的"热门"定义清楚——到底是按评分、按客流、还是按讨论度？权重怎么分配？数据从哪来，口径怎么统一？这些问题想清楚之后，技术实现反而是最顺手的一环。另外，开发环境尽量和生产环境保持一致的数据库类型，这种不起眼的细节往往决定了后续排障的天花板。
