教程

选择历史 API

跳转至本页面的以下主题

 

简介

2006 年 3 月第一条推文发出开始,Historical PowerTrack 和 Full-Archive Search 都可以访问任意公开发布的推文。确定哪种产品更适合你的使用案例是获取所需数据的关键。本文重点介绍了两种历史产品之间的区别,目的是帮助你确定使用哪种产品来生成下一个历史推文数据集。

两种历史产品都可以扫描推文归档,检查感兴趣的时间内发布的每条推文,并生成一组与查询匹配的推文。但是,Historical PowerTrack 和 Full-Archive Search 基于的归档架构明显不同,于是造成了根本上的产品差异。这些差异包括受支持的 PowerTrack 运算符、每个请求的规则/筛选条件数量、提供估算值的方式以及传递数据的方式。

首先,我们将概述 Historical PowerTrack API 和 Full-Archive Search API,然后详细讨论这些差异。最后,我们提供如何选择历史产品的一般指导,结束讨论。

Historical PowerTrack

Historical PowerTrack (HPT) 采用基于作业的批处理设计批量提供推文,其中 API 可用于完成多个阶段的作业。这些阶段包括预估数量、接受/拒绝作业、获取作业状态以及下载可能数以千计的数据文件。根据请求时间的长短,可能需要几个小时或几天的时间才能生成作业。每 10 分钟会生成一个数据文件,其中至少包含一条推文。因此,无论匹配的推文数量是多少,一个 30 天的数据集通常会包含大约 4,300 个文件。

Gnip 于 2012 年推出的 Historical PowerTrack 是在文件归档的基础上构建的,每个文件都包含一个持续时间很短的实时 Tweet Firehose。当 Historical PowerTrack 生成数据集时,它会在打开每个文件时执行文件操作,并检查文件中的每条推文。在此过程中,Historical PowerTrack 将访问 JSON 有效负载中具有关联的 PowerTrack 运算符的所有部分。Historical PowerTrack 支持实时 PowerTrack 支持的所有 PowerTrack 运算符。

Full-Archive Search

Full-Archive Search (FAS) 以类似于 Google 搜索的方式提供匹配的推文。当你搜索某个特定字词时,Google 搜索不会一次性返回或显示可能多达数百万的全部匹配结果,而是在每个可滚动的页面上提供少量结果,你可以点击“下一页”来显示下一页的结果…依此类推,直到返回所有匹配项。Full-Archive Search 的工作原理类似,它以一部分推文进行响应,可根据需要分页显示更多推文。

Full-Archive Search 是使用传统的 RESTful 请求/响应模式设计的,当提交一个 PowerTrack 规则时,立即就会提供具有匹配推文的响应。Full-Archive Search 的每个响应最多可提供 500 条推文,并提供“下一页”令牌进行分页,直到收到与查询内容匹配的所有推文。与查询内容匹配的推文越多,通过搜索 API 检索所有数据所需的时间就越长。这是因为需要将分页的结果集逐一拼接在一起,以创建所有返回数据的完整集合。

许多用例关注与查询内容关联的推文数量,而不是实际的推文信息本身。Full-Archive Search 支持“计数”端点,该端点按时间顺序返回匹配的推文数量。这些推文计数以每分钟、每小时或每日总数的形式按时间顺序返回。

请注意,Twitter 还提供 30 天搜索 API。如果仅需要最近 30 天的数据,则此 API 可能最适合你的使用案例。

 

产品差异

以下是 Historical PowerTrack 与 Full-Archive Search 之间的根本差异:

  • 每个请求支持的规则数

    • Historical PowerTrack 作业最多可以支持 1,000 个规则。
    • Full-Archive Search 针对每个请求只接受一个规则。

    • 注意:对于每个产品,一个规则最多可以包含 2,048 个字符。
  • 数据的传递方式

    • Historical PowerTrack 会按时间顺序生成数据文件,每个数据文件包含十分钟的内容。例如,每小时的数据将以六个 10 分钟的数据文件的形式提供(假定每个 10 分钟的时间段至少有一条推文。如果没有,则不会生成任何文件)。因此,完成 Historical PowerTrack“作业”后,下一步就是下载数据文件。在每个 Historical PowerTrack 文件中,JSON 推文有效负载均以原子方式编写,而不以 JSON 数组形式显示。需要将换行符用作分隔符,以分析文件内容。
    • 使用 Full-Archive Search 时,每个响应中的推文都按“结果”数组排列。每个响应最多可提供 500 条推文,如果有更多推文,则会提供“下一页”令牌。例如,如果针对一个 PowerTrack 规则的 60 天请求匹配了 10,000 条推文,则必须至少对搜索 API 发出 20 个请求。
  • 受支持的 PowerTrack 运算符

    • 虽然 FAS 还支持 HPT 支持的大多数运算符,但有一些运算符在 FAS 中无法使用:
bio: profile_bounding_box:
bio_location: profile_point_radius:
bio_name: profile_subregion:
contains: retweets_of_status_id:
is:quote sample:
followers_count: source:
friends_count: statuses_count:
has:lang url_contains:
in_reply_to_status_id:    url_description:
listed_count: url_title:
  • 有关每种产品的运算符的完整列表,请参阅此处:
  • 有关可用运算符的并排比较,请参阅此处
  • 数据量估算

    • Full-Archive Search 提供了一个“计数”端点,可用于按时间顺序生成每分钟、每小时或每日的匹配推文。若使用案例除了解实际数据外,还通过了解数据量获益,则 Full-Archive Search 的“计数”端点是首选工具。请注意,“计数”端点用于衡量预先符合的匹配推文数量。预先符合意味着推文总数不考虑已删除和受保护的推文。数据请求将不包含已删除或私密的推文。

    • Historical PowerTrack API 为作业将要匹配的推文数量提供了一个数量级的估算值。这些估算值以要涵盖的时间段的采样为依据,对于估算历史作业将返回的数据量,可以提供方向性的精确指导。Historical PowerTrack API 估算值将有助于解答某个作业将匹配 100,000 条还是 1,000,000 条推文。目的是就请求将要返回的数据量提供合理的预计值,但 Historical PowerTrack API 不应用作估算工具。

  • 产品许可和定价

Full-Archive Search API 和 Historical PowerTrack API 可提供 12 个月订阅。另外,Historical PowerTrack 也可以提供“一次性”订阅。因此,如果需要将历史推文数据用于一次性项目或临时研究,Historical PowerTrack 将更适合你的需求。

 

选择历史产品

Full-Archive Search 最适合收集数据量较小的数据集,而 Historical PowerTrack 更适合数据量较大的数据集。一般情况下,我们建议最好将 Full-Archive Search 用于推文数量在几百万或以下的数据集。该建议是有意含糊其词的,因为 Full-Archive Search 不能用于极大的数据请求并没有真正的技术原因。但根据你检索数据和利用 API 速率限制的计划,实际上存在一个阈值,Historical PowerTrack 实际上在该点比 Full-Archive Search 处理数据的速度更快。假设 Historical PowerTrack 作业在 6 个小时内提供了 800 万条推文。要通过 Full-Archive Search 提取 800 万条推文,至少需要 16,000 个搜索请求。再假设响应时间为 2 秒,并且某个应用使用单线程进行分页,则实际上 Full-Archive Search 需要更长时间才能检索到这 800 万条推文的数据集。

除了数据量方面的考虑因素和完成时间的对比之外,还有其他原因可以解释为什么历史产品最适合你的使用案例。如果需要使用 Full-Archive Search 中目前不支持的任何运算符(见上文),则 Historical PowerTrack 是正确的选择。Historical PowerTrack 非常适合不易受时间影响的研究。Historical PowerTrack 也更适合大型查询规则集,因为搜索 API 产品针对每个请求仅支持一个 PowerTrack 规则。另一方面,Historical PowerTrack 支持多达一千 (1,000) 个规则。最后,Historical PowerTrack 非常适合实时接收感兴趣的新推文属性(例如话题标签、提及和 URL)会触发历史请求的使用案例。由于 Historical PowerTrack 支持实时 PowerTrack 所支持的所有运算符,因此你始终可以将相应的实时规则“插入”Historical PowerTrack 作业中。

另一方面,如果要构建依赖近乎实时的结果和数据量估算的工具,则 Full-Archive Search 是一个更好的选择。如果要将历史推文结果构建到面板或用户应用程序中,则快速响应是关键。Full-Archive Search 已内置到许多允许用户创建筛选条件并立即检查匹配推文的系统中。根据初始响应,用户可以继续对结果进行分页,或者扩大或缩小筛选范围,然后重试。由于 Full-Archive Search 可通过其“计数”端点提供更准确的数据量估算值,因此另一个常见的搜索用例是,在将筛选条件添加到实时流之前对其进行试验。

 

后续步骤

准备好构建你的解决方案了吗?

阅读文件,然后开始吧