让数据团队说说他们的网页采集成本,你会听到千兆字节、请求数、积分和成功率。让财务部门说说他们想知道什么,答案更简单:每一条可用记录的成本是多少,这个数字是在上升还是下降?这两种对话很少能对上,因为工程师追踪的数字描述的是流水线,而不是流水线产出的东西。
每条干净记录的成本弥合了这一差距。它是一项采集任务的总成本除以通过验证的记录数,也就是你真正会放进报告、模型或面向客户的产品里的那些记录。本指南将正确定义这个指标,展示钱究竟花在哪里,通过一个示例演算,并对能改变这个指标的杠杆进行排序。
关键要点
- 衡量每条干净记录的成本:总成本除以通过内容验证的记录数,而不是除以请求数或 HTTP 成功数。
- 对于监控类任务,还要加上每次有效变化的成本。大多数重新抓取只是确认了什么都没变,因此一次变化的成本可能是一条记录成本的许多倍。
- 计费模式决定了哪种浪费会造成伤害。按带宽计费惩罚的是过重的页面;按成功次数计费惩罚的是不必要的抓取。
- 一个中位数的主页大约重 2.5 MB,其中只有 22 KB 是 HTML。只抓取你要解析的部分,往往是按带宽计费的采集中最大的一项单一节省。
- 每月按任务报告这一指标,并附上其组成部分。财务能追踪的数字,才是能拿到预算的数字。
谨慎定义这个指标
三个定义完成了大部分工作。
总成本是任务消耗的一切:代理带宽或 API 积分、计算资源、存储,以及如果你诚实的话,维持其运行所花费的工程时间。
一条干净记录是通过验证的记录:必需字段齐全,数值处于合理范围内,且该页面确实是你请求的页面,而不是一个拦截页面、一个验证挑战或一个空壳。一个 HTTP 200 的响应在通过这些检查之前并不算一条干净记录;两者之间的差距正是静默失败率所讨论的主题。
一次有效变化对监控而言至关重要。如果你每天重新抓取一个价格,而它每月只变化两次,那么你在另外 28 天付费得到的记录并没有确认任何新信息。每次有效变化的成本捕捉的是监控真正的目的所在。
了解你的计费方式
同一套流水线可能贵可能便宜,取决于计费模式,因为每种模式计算的东西不同。
| 计费模式 | 你为什么付费 | 什么会让它变贵 |
|---|---|---|
| 住宅代理带宽 | 通过网关的字节数 | 过重的页面、渲染、传输了数据的重试 |
| 网页抓取 API 积分 | 成功的响应 | 不必要的抓取 |
在 Shifter 的住宅网关上,每一个发送或接收的字节都会被计入,包括请求头,而如果在出错前已经传输了字节,失败的请求同样计入。在 Web Scraping API 上,无论是否启用了 JavaScript 渲染,一次成功的请求都消耗一个积分,失败的请求和目标端错误不消耗任何积分,且一次调用内的自动重试算作这一次调用。因此在按带宽计费的模式下,一个拉取了所有图片和脚本的渲染页面,成本可能远高于其 HTML 本身;而在按成功次数计费的模式下,成本是一样的。
体积差距很大。HTTP Archive 的 2025 年 Web Almanac 发现,桌面端中位数主页重 2.86 MB,移动端为 2.56 MB,而两者的中位数 HTML 都是 22 KB。如果你只解析 HTML,或者其背后的一个 JSON 端点,那么一个完全渲染的页面的大部分字节根本没为你带来任何东西。
一个演算示例
设想一项持续一个月的监控任务。下面的数字是示意性的,是为了展示演算而选取的,其中每 GB 3 美元的费率只是示例中的一个整数,并非报价。
| 输入 | 数值 |
|---|---|
| 发送的请求数,包括重试 | 120,000 |
| 每个请求的平均字节数 | 450 KB |
| HTTP 层面的成功数 | 108,000 |
| 通过验证的记录数 | 97,000 |
| 与上一份副本不同的有效记录数 | 6,800 |
| 带宽费率 | 每 GB 3.00 美元 |
| 计算成本 | 40 美元 |
运行下面的计算器,得到:
| 指标 | 数值 |
|---|---|
| 总成本 | 202.00 美元 |
| 每次请求成本 | 0.0017 美元 |
| 每条干净记录成本 | 0.0021 美元 |
| 每次有效变化成本 | 0.0297 美元 |
| 静默失败率 | 10.2% |
| 每条干净记录的字节数 | 约 557 KB |
有两点很突出。每次有效变化的成本大约是每条干净记录成本的十四倍,因为大多数抓取只是确认了什么都没动。而且十分之一的 HTTP 成功并没有产出任何可用的东西。
现在改变一件事:不再渲染完整页面,只抓取解析器需要的 HTML 或 JSON,把平均值从每请求 450 KB 削减到 60 KB。其他一切保持不变。总成本降至 61.60 美元,每条干净记录的成本降至 0.0006 美元,每次有效变化的成本降至 0.0091 美元,仅仅改变页面抓取方式这一项,就带来了超过三分之二的降幅。
这个计算器只需要几行代码:
from dataclasses import dataclass
@dataclass
class Run:
requests: int # every request sent, including retries
bytes_transferred: int # everything through the proxy, failures included
responses_ok: int # HTTP-level successes
records_valid: int # records that passed content validation
records_changed: int # valid records that differed from the last copy
price_per_gb: float # your plan's rate
compute_cost: float = 0.0
people_cost: float = 0.0 # engineering time spent on this job, if you count it
def unit_economics(run):
bandwidth = run.bytes_transferred / 1e9 * run.price_per_gb
total = bandwidth + run.compute_cost + run.people_cost
return {
"total_cost": round(total, 2),
"cost_per_request": round(total / max(1, run.requests), 5),
"cost_per_clean_record": round(total / max(1, run.records_valid), 4),
"cost_per_useful_change": round(total / max(1, run.records_changed), 4),
"silent_failure_rate": round(1 - run.records_valid / max(1, run.responses_ok), 3),
"bytes_per_clean_record": int(run.bytes_transferred / max(1, run.records_valid)),
}
对于按积分计费的任务,把带宽那一行替换为成功响应数乘以每个积分的价格。其余的演算方式相同。
各项杠杆,按影响力大致排序
1. 停止抓取没有变化的东西。 对于监控任务,未发生变化的重新抓取通常是最大的一项支出。根据每个页面实际变化的频率来安排访问计划,并在目标网站支持的情况下使用条件请求,可以在不漏掉变化的情况下减少抓取次数。相关方法见成本感知的抓取调度,如何从噪声中辨别真正的变化见大规模变化检测。
2. 每个页面少抓一点。 在按带宽计费的模式下,除非数据确实需要,否则避免渲染;必须渲染时屏蔽图片、字体和媒体;优先使用 JSON 端点,并保持压缩开启。完整清单见削减代理带宽成本。
3. 修复静默失败。 每一个被当作成功通过的拦截页面、验证挑战或空壳,其成本与一条正常记录相同,却什么也没产出。验证内容,按目标统计失败次数,并修复或放慢那些产生失败的目标。
4. 从稳定的来源提取数据。 维护是一项真实的成本。每次改版都会失效的选择器会消耗工程时间,这就是为什么结构化数据在一年的周期里比单次运行看起来更便宜;参见停止解析 HTML。
5. 将计费模式与目标匹配。 必须渲染的重型页面,按成功次数计费可能更便宜;轻量的 HTML 或 JSON 目标通常按带宽计费更便宜。混合类型的任务组合往往两种都会用到。更广泛的权衡在网页抓取基础设施自建还是购买中有所涉及。
向财务部门报告
一项指标只有被持续、一致地报告,才有意义。每月一次,按任务发布:
- 总成本,拆分为带宽或积分、计算资源,以及如果计入的话,人力。
- 干净记录数,以及每条干净记录的成本。
- 对于监控任务,有效变化数,以及每次有效变化的成本。
- 静默失败率和每条干净记录的字节数,作为两个先行指标。
- 与上个月相比的主要变化,以及原因。
坚持一个季度后,这会把网页数据从一条不透明的基础设施支出,变成一个可以被预算、与从其他渠道购买数据进行比较、并加以论证的单位成本。
结论
千兆字节和请求数描述的是投入的努力。财务关心的是产出:一条可用记录的成本是多少,对监控而言,一次真实变化的成本是多少。用验证而非状态码来定义干净记录,统计任务产生的每一项成本,并按任务每月报告结果。
这些杠杆很少是花哨的手段。在什么都没变的地方少抓取一些,每个页面少抓一些,停止为看起来成功实则不然的页面付费,并从不会失效的来源提取数据。每一项都能直接体现在一个所有在场的人都能读懂的数字上。
来源和参考资料
- HTTP Archive,Web Almanac 2025: Page Weight。中位数页面和 HTML 重量,2025 年 7 月抓取数据。
- Shifter,住宅代理带宽与计费 和 Web Scraping API 错误与限制 文档。