2026-2-5

记一次 GoogleTrends爬虫

起因是2026美赛开始，一个朋友委托我获取某档节目中若干明星的热度信息(2026年美赛C题)，他们希望分析的是GoogleTrends中相应明星的热度趋势

GoogleTrends 简介

Google Trends（谷歌趋势）是谷歌于 2006 年 5 月 11 日推出的免费搜索数据分析工具，基于谷歌搜索与 YouTube 等平台的海量匿名搜索数据，以相对热度（0-100）呈现关键词在不同时间、地区、类别下的搜索趋势与分布，支持对比、相关查询挖掘等核心能力，广泛用于市场研究、内容选题、竞品分析与趋势预判。以下从核心要点、功能、数据机制、应用场景、爬取要点展开说明。

**GoogleTrends对于爬虫来说，最大的优势是其支持匿名进行访问，也就意味着对于并发操作的时候，并不需要同时注册多个不同账户。**国内的百度指数平台我也有爬过，但是需要登录，还好当时数据量并不是很大，因此单线程跑了一段时候后就收集好了所有数据。

前期踩点与确定目标

有一个存储着408位明星的keywords文件。节目播出日期是2005至今。

于是我先尝试进行搜索其中的第一个keyword，可以发现趋势图中的每个数据点间隔仅有几十分钟。但是实际上将时间调整到2005年左右的时间，仅支持查看每日的数据。在实际测试中，GoogleTrends支持获取全部数据，而每个数据的单位为月度。同时个人测试的过程中，若一段时间为90天左右，那么数据单位为日度；而一段时间为360天，那么数据单位为周度

于是可以明确此次爬虫的目标为:获取GoogleTrends中每个keyword的月度、周度、日度数据

寻找现有框架

例如GoogleTrends这种知名度比较高的应用，一般都会有先人写过程序并放在网上，我们只需要站在巨人的肩膀上就行，不要重复造轮子，除非以学习为目的。

Pytrends 是一个非官方的Google趋势API，用于在Python中分析和获取Google搜索趋势数据。

GeneralMills/pytrends: Pseudo API for Google Trends 目前该项目已经归档，但是延申出来的其他项目还在持续更新

1
2
3

trends = TrendReq(hl='en-US', tz=360)
trends.build_payload("关键词",timeframe=f'{开始时间} {结束时间}',geo="位置")
trend_data = trends.interest_over_time() # 获取热度随时间的数据

根据该框架，我们能够很轻易构造第一个类**GoogleTrends**,该类的功能为:

接收关键词，查询类型，查询时间片
根据查询类型与时间片构建TrendReq对象，进行调用interest_over_time()方法
存储，返回，校验等基础功能，同时提供合并多个时间片的静态方法(用于断点续传)供外部调用

代理池与多线程并发

当开始尝试单线程运行时，发现刚爬取8次数据便遇到了429 Too Many Requests。此时得考虑接入代理池了。

代理池:在项目的实际过程中，我使用的是123proxy的隧道代理服务，但是最终失败了。具体原因不明，但是可以知道的是，当我尝试让请求通过123proxy的隧道代理进行转发后，访问ifconfig.me是能够正常访问的，但是在尝试访问Google的时候，直接出现了以下错误，怀疑是代理池不干净导致的，当然因为时间缘故没过多测试，所以只是怀疑阶段。

1	`Connection aborted.', ConnectionResetError(104, 'Connection reset by peer' )`

实际项目中的代替方案:由于项目时间较紧，实际测试发现，可以通过手动切换我机器中的V2ray节点进行爬取，每个节点在并行线程数为20的情况下，大约能爬取 100次数据，节点稳定可以到接近200（当然，这里用到了服务器池的策略）

**多线程并发:**当数据量起来的时候，一个多线程自然是少不了的，使用concurrent库与 tqdm库构建一个可视化进度的多线程类TaskController:

接收外部处理好的关键词表
提供各种不同查询类型的静态方法以供调用
自行处理断点续传等功能

服务器池

当然，这是一个自己胡诌的一个概念，按理来说爬虫是没有这个概念的，但是对于GoogleTrends比较特殊，其服务器遍布全球各国。于是我将pytrends的模块抓了出来(好消息就是，该模块完全由一个py文件构成)，然后将内部硬编码的GoogleTrends的url写了一套按照不同线程随机分配的算法，确保每个线程调用时请求的是不同国家的服务器。好消息是，这样的策略一定程度上起了一点作用，但是坏消息就是，google的同步也非常快，因此能看到请求到一定数量时全线程发现了429code。

基于V2ray的代理池

这里是未完成的设想，因为最终是半自动化完成的，而人工部分就是切换V2ray的节点，于是设想是否能够为每个线程或者进程分配一个独自的代理节点，因为个人认为代理节点在一定程度上算是比较干净（爬虫意义），而在V2ray的代理池中，再加入随机轮换策略，应该能构成一个通行率较高的本地代理池。当然，如果后面还要爬虫项目的话，我大概率会尝试一下。

总结

本次项目因为有第三方的pytrends框架，让整个流程加速了不少，节省了非常多自己分析接口以及加解密的过程，过程中的话，可能没太多新的经验，更多的是在思考如何写一个完美的项目。同之前百度指数的爬虫来说，这一次困难点可能还是在于我并没有一套比较完善的代理机制，这一点希望未来的我能够去构建完善他。