如何检查BigQuery time-travel查询使用情况及评估保留期调整影响

一、确认过去6个月是否有用户使用时间旅行功能 #

BigQuery时间旅行查询的核心标识是FOR SYSTEM_TIME AS OF语法，你可以通过查询作业日志筛选这类操作：

1. 单项目查询
   执行以下SQL（替换your-project-id为你的项目ID），返回过去6个月内所有使用时间旅行的作业：

SELECT
  job_id,
  user_email,
  start_time,
  query_text
FROM
  `your-project-id.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE
  start_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 MONTH)
  AND query_text LIKE '%FOR SYSTEM_TIME AS OF%'
ORDER BY
  start_time DESC;

如果结果为空，说明这段时间内没有用户使用时间旅行；如果有结果，能直接看到操作人、执行时间和具体查询内容。

2. 跨项目/组织查询
   若要覆盖整个组织的所有项目，可使用JOBS_BY_ORGANIZATION视图（需组织级权限），替换视图路径后执行：

SELECT
  job_id,
  project_id,
  user_email,
  start_time,
  query_text
FROM
  `your-organization-id.INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION`
WHERE
  start_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 MONTH)
  AND query_text LIKE '%FOR SYSTEM_TIME AS OF%'
ORDER BY
  start_time DESC;

二、评估保留期从7天调整为2天的业务影响 #

1. 梳理现有依赖场景 #

• 数据恢复：确认团队是否有在数据误删/误改后，使用时间旅行恢复超过2天前数据的案例；内部流程是否要求保留7天的恢复窗口。
• 数据分析：检查报表、ETL任务中是否存在需要访问2天前以上历史版本数据的逻辑，比如周度复盘是否依赖更早的快照数据。

2. 分析现有时间旅行查询的时间范围 #

基于第一部分的查询结果，统计所有FOR SYSTEM_TIME AS OF指定的时间戳，查看是否有超过2天前的情况。如果所有查询仅访问2天内的历史数据，调整保留期不会影响现有业务。

3. 小范围测试验证 #

找非核心数据集或测试项目，将时间旅行保留期改为2天，尝试访问超过2天前的历史数据，确认是否触发“数据超出保留期”的报错，验证业务流程的容错能力。

4. 准备替代方案 #

如果确实存在访问更早历史数据的需求，可以用快照表（CREATE SNAPSHOT TABLE）定期备份关键数据，既能满足长期访问需求，又能配合物理计费模式降低成本。

内容的提问来源于stack exchange，提问作者CraRevol