简介一份基于大数据技术的高校舆情监测与分析系统设计方案面向高校管理人员、舆情分析人员以及网络爬虫、数据挖掘方向的师生可用作毕业设计、课程论文或高校信息化建设的参考资料。文档以Python爬虫技术为核心围绕高校舆情监测与分析系统的设计与实现展开阐述高校舆情随意性、直接性、偏差性、突发性等特征并覆盖大数据技术在舆情采集与研判中的应用、爬虫采集策略、以及关键字管理、舆情分析、结果可视化、舆情报告四大功能模块还涉及媒体分析、热度分析、受众分析等可视化维度以及系统的实时监控、准确高效、多态势监控等优点和应用前景。资源共1份docx格式文档容量578KB目录结构完整、论述层次清晰便于直接阅读、二次修改或按章节引用。目前已有232人学习适合希望快速理解高校舆情系统整体架构及爬虫技术落地的读者。1. 高校舆情监测为什么绕不开Python爬虫百度贴吧目前依然是高校学生表达诉求最密集的公开渠道之一课程安排、宿舍管理、社团活动、校园突发事件的讨论往往先在贴吧发酵随后才扩散到其他平台。管理人员如果靠人工巡检只能看到极少数高回复帖子大量沉默但具有苗头性的内容会被漏掉。这套基于大数据技术构建的高校舆情监测与分析系统目标就是把贴吧中与学校相关的帖子采集下来用词频分析判断话题集中度再通过可视化图表直观呈现舆情演进趋势。它面向的是高校宣传部门、学生工作处以及做校园数据分析的开发者不是做舆情压制而是做一个提前发现问题的监测工具。整套链路覆盖了数据采集、存储、分析、可视化四个环节与大数据技术原理与应用课程中的数据流转路径完全对应也常被用作数据科学与大数据技术方向的毕设选题。2. Scrapy框架下的贴吧数据采集实现与调参2.1 选型对比Scrapy为什么比requests加BeautifulSoup更适合贴吧采集的难点不只是发请求还包括翻页调度、请求去重、并发控制、失败重试、结构化输出。用requests配合BeautifulSoup也能写但上面每一件事都要自己手工实现翻页要自己组织URL队列去重要自己维护一个set并发要自己处理线程池重试要自己写装饰器。Scrapy把这些都落到了框架层settings.py里一行CONCURRENT_REQUESTS 16就能控制并发量重复URL由调度器的指纹去重机制自动过滤数据清洗和落库统一走Pipeline管道。Scrapy底层基于Twisted异步IO框架IO等待不阻塞事件循环单机就能跑出不错的吞吐量。但要注意Scrapy默认架构是单机的调度器与去重队列都存放在进程内存里不支持跨进程共享所以原生的Scrapy无法直接做分布式部署。如果后续爬取量从贴吧单吧扩展到全校多吧、多平台就需要引入scrapy-redis把调度队列外置到Redis里这是一条成熟的扩展路径。2.2 Spider与CrawlSpider的选择贴吧场景的特殊性Scrapy提供了两种常用爬虫基类scrapy.Spider和CrawlSpider。贴吧列表页的URL规则非常规整第一页是pn0第二页是pn50第三页是pn100每页固定50条帖子这种明确的翻页参数适合直接用Spider在start_requests里构造URL。CrawlSpider虽然能通过Rule自动提取页面中的链接并跟进但贴吧详情页之间不存在下一篇的入口一个帖子详情页无法直接跳到另一个详情页爬行深度只有2。使用CrawlSpider反而会把列表页两侧的导航链接、热门推荐一并抓进来产生大量偏离主题的请求。所以本系统的核心采集逻辑采用Spider代码可维护性更高后续如果要增加评论翻页直接在parse_detail里继续写yield Request即可。2.3 贴吧列表页与详情页爬虫的核心实现下面这段代码实现了从贴吧列表页翻页采集、再进入帖子详情页提取正文的完整流程。用户在系统页面输入贴吧名称和爬取页数后由Scrapy引擎驱动整个流程。import scrapy from scrapy.http import Request class TiebaSpider(scrapy.Spider): name tieba_spider allowed_domains [tieba.baidu.com] def __init__(self, tieba_namexx大学, page_count10, *args, **kwargs): super().__init__(*args, **kwargs) self.tieba_name tieba_name self.page_count int(page_count) self.base_url https://tieba.baidu.com/f?kw{}pn{} def start_requests(self): # 百度贴吧每页50条帖子pn是起始偏移量 for page in range(self.page_count): pn page * 50 url self.base_url.format(self.tieba_name, pn) yield Request(urlurl, callbackself.parse_list, meta{page: page}, dont_filterFalse) def parse_list(self, response): li_list response.xpath(//li[contains(class,j_thread_list)]) for li in li_list: title_node li.xpath(.//a[contains(class,j_th_tit)]) if not title_node: continue title title_node.xpath(./text()).get() author li.xpath(.//span[contains(class,frs-author-name)]/text()).get() reply_num li.xpath(.//span[contains(class,threadlist_rep_num)]/text()).get() post_href title_node.xpath(./href).get() if post_href: yield Request( urlresponse.urljoin(post_href), callbackself.parse_detail, meta{ title: title.strip() if title else , author: author.strip() if author else , reply_num: reply_num.strip() if reply_num else 0, } ) def parse_detail(self, response): # 详情页一楼正文贴吧内容分布在div.post_content下 content_list response.xpath( //div[contains(class,post_content)]//text()).getall() content .join(content_list).strip() publish_time response.xpath( //span[contains(class,post-tail-wrap)]/span[1]/text()).get() yield { title: response.meta[title], author: response.meta[author], reply_num: response.meta[reply_num], content: content, url: response.url, publish_time: publish_time.strip() if publish_time else , }这段代码的关键点有三个。第一start_requests里通过pn page * 50构造翻页URLpage_count由用户输入控制避免一次性爬取过多触发封禁。第二列表页解析时用XPath定位li节点先判断title_node是否存在再取值防止广告帖或置顶帖结构不一致导致解析异常。第三parse_detail把帖子标题、作者、回复数通过meta字典从列表页透传到详情页详情页只需要补充正文内容和发布时间这样即使详情页请求失败也不会丢列表页已经拿到的元信息。这里有一个需要提的参数dont_filterFalse。默认情况下Scrapy会对请求URL做指纹去重翻页URL是不同pn值不会误判重复保持默认即可。2.4 robots协议与爬取边界Scrapy默认开启ROBOTSTXT_OBEY True遵守目标站点的robots.txt规则。百度贴吧的robots.txt对部分路径做了Disallow限制。对于非商业用途的学术型舆情监测常见做法是在settings.py里设置ROBOTSTXT_OBEY False以便获取完整的公开讨论数据。但关闭协议遵守不等于可以无限抓取必须配合下载延迟和并发限制把请求频率控制在一个对目标站点无压力的水位。下面的配置是实际跑通的一个起点ROBOTSTXT_OBEY False DOWNLOAD_DELAY 3 CONCURRENT_REQUESTS 16 COOKIES_ENABLED False DEFAULT_REQUEST_HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64), Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, }DOWNLOAD_DELAY 3表示每个请求之间至少间隔3秒16个并发请求分散到不同线程整体对贴吧的请求压力与一个普通用户连续翻页相当。COOKIES_ENABLED False关闭Cookie传递避免Scrapy在会话级维护Cookie造成请求特征过于一致。3. MySQL入库、文本清洗与Jieba关键词分析3.1 表结构设计与字段说明贴吧帖子的结构相对固定MySQL表设计不需要太复杂。系统建在baidu库下核心表名为bordered字段设计如下字段名类型说明idint(11)主键自增titlevarchar(255)帖子标题authorvarchar(100)发帖人昵称reply_numint(11)回复数量用于热度初判contenttext帖子一楼正文urlvarchar(255)帖子详情页链接做唯一性约束publish_timevarchar(64)发布时间保留原始字符串便于后续解析url字段建议加唯一索引爬虫重复运行时可以依靠它跳过已经入库的帖子。publish_time没有直接用datetime类型是因为贴吧的时间格式存在昨天3分钟前这类相对时间入库前不做强转留到清洗阶段统一处理。3.2 数据管道写入MySQL的Pipeline实现Scrapy的Item Pipeline是数据落库的收口位置爬虫产生的每个字典都会依次经过Pipeline的process_item方法。import pymysql class MysqlPipeline: def open_spider(self, spider): self.conn pymysql.connect( host127.0.0.1, port3306, userroot, passwordyour_password, databasebaidu, charsetutf8mb4, ) self.cursor self.conn.cursor() def process_item(self, item, spider): # 先用URL判重避免重复入库 self.cursor.execute( SELECT id FROM bordered WHERE url %s, (item[url],)) if self.cursor.fetchone(): return item sql INSERT INTO bordered (title, author, reply_num, content, url, publish_time) VALUES (%s, %s, %s, %s, %s, %s) self.cursor.execute(sql, ( item[title], item[author], item[reply_num], item[content], item[url], item[publish_time], )) self.conn.commit() return item def close_spider(self, spider): self.cursor.close() self.conn.close()open_spider在爬虫启动时建立数据库连接close_spider在爬虫结束时释放资源。process_item里先执行一次SELECT判重再执行INSERT虽然多一次查询但能保证爬虫断点续跑时不会产生重复数据。这里还有一个细节charsetutf8mb4是必须的贴吧内容经常包含emoji和生僻字utf8mb4字符集才能完整存储这类内容。3.3 数据清洗的三类常见脏数据入库不等于可以直接分析。贴吧数据里常见的脏数据有三类第一类是空内容帖子。部分帖子被系统删除后详情页仍返回200状态码但post_content下没有任何文本。清洗策略是过滤content长度小于5的记录。第二类是重复内容。同一用户在不同吧重复发帖或者营销号批量发布相同文案需要按标题和正文的MD5值做近似去重。第三类是无关导航文本。详情页侧栏的吧内导航热门推荐等区块会被XPath误抓到正文结尾清洗时按已知的固定后缀做截断。import hashlib def clean_post(row): content row[content].replace(\n, ).replace(\u3000, ).strip() if len(content) 5: return None # 去掉侧栏导航等干扰文本 for noise in [首页, 上一页, 下一页, 尾页]: content content.replace(noise, ) md5 hashlib.md5(content.encode(utf-8)).hexdigest() row[content_md5] md5 return row清洗阶段用MD5做内容指纹后续在SQL层面对content_md5做DISTINCT查询就能去掉完全重复的帖子成本远低于做文本相似度计算。3.4 Jieba分词与敏感词频率统计舆情分析的核心是把非结构化的帖子文本转成可统计的词频向量。这里使用Jieba分词库默认的lcut方法是精确模式适合做文本分析。针对校园场景还要加载自定义词典把教务处体测宿舍楼奖学金这类贴吧高频词作为整体切分。import jieba import jieba.analyse from collections import Counter # 加载自定义校园词典 jieba.load_userdict(campus_dict.txt) # 载入停用词表 stopwords set() with open(stopwords.txt, r, encodingutf-8) as f: for line in f: stopwords.add(line.strip()) def analyze_topic(text_list, top_n30): word_counter Counter() for text in text_list: words jieba.lcut(text) for word in words: if len(word) 2: continue if word in stopwords: continue word_counter[word] 1 return word_counter.most_common(top_n) def extract_hot_phrases(text): # TF-IDF关键词抽取返回(词, 权重)列表 keywords jieba.analyse.extract_tags( text, topK10, withWeightTrue) return keywordsstopwords.txt里放我们你们这个一个等无意义虚词。extract_hot_phrases使用TF-IDF算法抽取短语权重越高的词在当前帖子集合中的区分度越大这类词往往是舆情事件的核心实体。词频统计结果可以直接用于后续的可视化和报告模块。4. Pandas与Matplotlib实现舆情态势可视化4.1 三个分析维度的数据聚合逻辑摘要中提到的媒体分析、热度分析、受众分析落到数据层面就是三组聚合查询。热度分析按时间维度统计回复量总和看舆情是上升还是消退受众分析按发帖作者统计活跃度和发帖频率识别持续输出观点的活跃用户媒体分析按帖子来源区分是发帖还是回帖、是原创还是转载判断信息的源头形态。import pandas as pd from sqlalchemy import create_engine engine create_engine( mysqlpymysql://root:your_password127.0.0.1:3306/baidu?charsetutf8mb4) df pd.read_sql(SELECT * FROM bordered, engine) # 热度分析按日期统计回复总量 df[date] pd.to_datetime(df[publish_time], errorscoerce) heat_trend df.groupby(df[date].dt.date)[reply_num].sum() # 受众分析统计发帖量Top10作者 author_top df[author].value_counts().head(10) # 媒体分析按帖子URL的路径前缀区分来源 df[source_domain] df[url].str.extract(r//(.*?)/) source_stats df[source_domain].value_counts()pd.to_datetime解析贴吧非标准时间格式时无法解析的值会被设为NaTerrorscoerce保证聚合时不会整体报错。groupby按日期聚合后得到每天回复总量序列这是后续绘制趋势图的数据基础。4.2 Matplotlib图表设计与中文显示处理Matplotlib默认中文字体显示为方框必须显式指定字体。常用做法是设置plt.rcParams[font.sans-serif] [SimHei]同时设置axes.unicode_minus避免负号显示异常。下面这段代码输出三张图覆盖热度趋势、话题词频、热门帖子三个维度。import matplotlib.pyplot as plt from collections import Counter plt.rcParams[font.sans-serif] [SimHei] plt.rcParams[axes.unicode_minus] False # 图1热度趋势折线图 fig, ax plt.subplots(figsize(12, 6)) ax.plot(heat_trend.index, heat_trend.values, color#d9534f, linewidth2) ax.set_title(高校贴吧舆情热度趋势) ax.set_xlabel(日期) ax.set_ylabel(回复总量) plt.xticks(rotation45) plt.tight_layout() plt.savefig(output/heat_trend.png, dpi150) plt.close() # 图2词频Top10横向条形图 top_words analyze_topic(df[content].tolist(), top_n10) words, counts zip(*top_words) fig, ax plt.subplots(figsize(10, 6)) ax.barh(words, counts, color#5bc0de) ax.set_title(话题关键词Top10) ax.set_xlabel(出现次数) plt.tight_layout() plt.savefig(output/top_words.png, dpi150) plt.close()tight_layout()防止旋转后的日期标签被截断dpi150保证图片在Web页面嵌入时清晰度足够。折线图和条形图分别对应热度分析和关键词分析管理人员不需要看懂数据表直接看图的走势就能判断当前舆情的状态。4.3 舆情报告模块的模板化生成报告模块采用模板渲染的方式把图表和统计数据填入HTML模板生成一个可独立打开的静态页面。项目中的常见做法是把整个报告页面保存为report_{date}.html按天归档。from datetime import datetime html_template !DOCTYPE html html headmeta charsetutf-8title舆情日报 {date}/title/head body h1舆情日报 {date}/h1 h2热度趋势/h2 img srcheat_trend.png stylewidth:100% h2关键词Top10/h2 img srctop_words.png stylewidth:100% h2活跃发帖用户/h2 table border1 trth排名/thth用户/thth发帖数/th/tr {table_rows} /table /body /html rows .join( ftrtd{i1}/tdtd{author}/tdtd{count}/td/tr for i, (author, count) in enumerate(author_top.items()) ) html html_template.format( datedatetime.now().strftime(%Y-%m-%d), table_rowsrows, ) with open(output/report_{}.html.format(datetime.now().strftime(%Y%m%d)), w, encodingutf-8) as f: f.write(html)enumerate生成排名序号strftime统一日期格式。报告模块不做动态渲染直接输出静态HTML的好处是零依赖管理人员用任意浏览器打开即可查看无需启动Web服务。5. 反爬虫编排与Scrapy运行验证技巧5.1 贴吧反爬机制与应对策略百度贴吧的反爬主要体现在三个层面IP访问频控、User-Agent识别、账号风控。频控是触发最频繁的同一IP在短时间内请求量超过阈值后会出现验证码弹窗Scrapy请求直接返回302跳转到验证码页。User-Agent识别相对容易绕过通过中间件随机切换UA即可。import random USER_AGENTS [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 Version/17.0 Safari/605.1.15, Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 Gecko/20240101 Firefox/121.0, ] class RandomUserAgentMiddleware: def process_request(self, request, spider): request.headers[User-Agent] random.choice(USER_AGENTS) return None在settings.py中启用这个中间件并把优先级调到500以下DOWNLOADER_MIDDLEWARES { tieba_monitor.middlewares.RandomUserAgentMiddleware: 500, }如果单机跑大批量爬取IP频控仍然避不开实际项目中的做法是维护一个代理IP池在中间件中为每个请求随机分配代理。校园内网或教育网环境下公网出口IP本身就有限更要控制并发数。5.2 爬虫运行状态的验证方法爬虫启动后不要只盯着终端输出建议看三个指标。第一是响应状态码分布在process_response里统计200、302、403的数量如果302占比过高说明已经触发频控。第二是入库去重率对比本次入库条数与请求总数去重率超过70%说明目标数据已经接近采满。第三是详情页解析成功率统计parse_detail成功返回Item的次数与请求次数的比值。class MetricsMiddleware: def __init__(self): self.stats {200: 0, 302: 0, 403: 0} def process_response(self, request, response, spider): self.stats[str(response.status)] 1 spider.logger.info( 状态码分布: {}.format(self.stats)) return response这个中间件把状态码分布实时打到日志里爬虫跑5分钟就能看出当前配置是否安全。若403开始增长需要立即降低CONCURRENT_REQUESTS并调大DOWNLOAD_DELAY。5.3 URL去重指纹与断点续爬Scrapy默认的URL去重基于SHA1指纹存在于内存中爬虫重启后会丢失。这会导致同一个帖子的详情页被重复请求。一方面浪费带宽另一方面增加触发频控的概率。解决方法是启用RFPDupeFilter的持久化或将已经入库的URL在Pipeline里做一遍校验。对于贴吧这种数据增量更新场景最省事的做法是每次采集前读取数据库已有URL集合交给爬虫的start_requests做一次过滤只请求新帖子既降低请求量又保证数据新鲜度。本文还有配套的精品资源点击获取