构建一个真正可扩展的 Google Places 提取工具

Source: Dev.to

从 Google Places 提取数据看起来很简单，直到你尝试大规模操作。

几百条结果还好，几千条就开始卡顿。全国范围的提取会暴露所有问题：分页限制、重复数据、速率限制、不明确的费用、长时间运行中途失败。

本文阐述了我在构建本地 Google Places 提取工具时最终形成的 模式。示例来自英国的真实项目，但该方法 与国家无关。不进行爬取。不使用 SaaS。仅是受控、可重复的提取。

真正的问题不是访问

Google Places 数据可以通过官方 API 访问。这并不是难点。

难点在于它周围的所有事情：

• 分页上限导致必须分散查询
• 同一家企业会出现在多个附近搜索中
• API 速率限制和临时错误
• 长时间的提取在数小时的进度后失败
• 在任务完成之前无法看到费用

大多数工具要么忽视这些限制，要么将其隐藏在订阅后面。

强制结构的使用案例

原始任务在纸面上很简单：

• 提取英国各地的理发师
• 包含电话号码
• 导出为 CSV
• 避免重复
• 保持 API 成本可预测

实际上，这意味着需要覆盖英格兰、苏格兰、威尔士和北爱尔兰的 200+ 城市，同时保持任务可恢复且可审计。这迫使我们采用更为严谨的架构。

核心设计原则

与国家无关的搜索策略

英国案例使用了预定义的城市列表。相同的方法可以在任何地方使用。关键不在于国家，而在于 搜索网格：

• 城市、地区或自定义位置
• 每个位置一次查询
• 对每个区域的分页深度进行控制

更改输入列表后，工具即可在全球范围内工作。

明确的分页控制

Google Places 的分页速度慢且有上限。该工具：

• 限制每个位置的页面数量
• 在页面请求之间插入延迟
• 当结果变得冗余时提前停止

这在原始速度与可预测性之间做出权衡。规模化时，可预测性更重要。

去重作为首要任务

重复数据是必然的。去重基于：

• Place ID（地点 ID）
• 电话号码

这可以消除相邻城市以及重复查询之间的重叠。去重不是事后清理步骤，而是提取循环的一部分。

导出前过滤，而非事后过滤

在 Excel 中筛选成千上万行是失败的做法。工具在提取过程中进行过滤：

• 包含关键词
• 排除关键词
• 可选的电话要求

不良数据永远不会写入磁盘。

限流与检查点

长时间运行时有两件事很重要：

• 不被封锁
• 不丢失进度

该工具包括：

• 请求之间的固定延迟
• 定期将检查点保存到磁盘

如果进程中止，它会从最近的检查点恢复。无需重新运行，也不会浪费配额。

示例配置模式

一个简化的配置在概念上看起来是这样的：

• 搜索查询和可选的地点类型
• 目标结果数量
• 包含和排除的关键字
• 分页深度
• 请求延迟
• 输出格式和检查点间隔

逻辑保持稳定。可变性转移到配置中。

为什么这不是爬取

此方法使用官方的 Google Places API。这带来了权衡：

• 您遵守速率限制
• 您按请求付费
• 您接受 API 的数据模型

作为回报，您获得：

• 稳定性
• 法律明确性
• 可预测的失败

对于许多业务数据集，这比爬取更合适的权衡。

此模式未解决的内容

明确表达很重要。此不会：

• 绕过 Google 限制
• 提取隐藏字段
• 保证超出 API 约束的完整性

它优化的是控制，而非全知。

从脚本到产品，理念不变

首个版本是为客户项目构建的 Node.js 脚本。随后，同样的模式演变为本地桌面应用：

• 使用 UI 取代配置文件
• 实时成本估算
• 暂停与恢复控制
• 字段级别的导出选择

相同的原则。更好的可用性。重要的不是应用本身，而是模式。

要点

如果你需要大规模获取 Google Places 数据，制胜之道不是巧妙的爬取，而是：

• 将地理区域划分为受控单元
• 将分页和去重视为核心逻辑
• 及早显现成本和失败
• 在本地运行，使用自己的 API 密钥

其他一切都是实现细节。