Flink SQL Time Travel用 FOR SYSTEM_TIME AS OF 查询历史快照

Time Travel（时间旅行）用于查询表在某个历史时间点的"数据与表结构状态"。你可以指定一个时间点，让 Flink 返回该时间点对应的表数据，适合做：

Flink SQL 通过标准语法实现：FOR SYSTEM_TIME AS OF ...。(Apache Nightlies)

当前 Flink 的 Time Travel 要求表所在的 Catalog 实现：

getTable(ObjectPath tablePath, long timestamp)

也就是说：能不能"回到过去"，不在 SQL 本身，而在 Catalog 是否支持按时间点取表 。(Apache Nightlies)

典型支持者：面向湖/快照表格式的 Catalog（例如 Paimon 的实现思路经常被拿来举例）。(Apache Wiki)

sql 复制代码

SELECT select_list
FROM table_name
FOR SYSTEM_TIME AS OF timestamp_expression;

sql 复制代码

SELECT *
FROM paimon_tb
FOR SYSTEM_TIME AS OF TIMESTAMP '2023-07-31 00:00:00';

sql 复制代码

SELECT *
FROM paimon_tb
FOR SYSTEM_TIME AS OF TIMESTAMP '2023-07-31 00:00:00' - INTERVAL '1' DAY;

Time Travel 对 timestamp_expression 的限制非常严格：只支持能被归约为 TIMESTAMP 常量 的一部分表达式（常量 TIMESTAMP、对 TIMESTAMP 做加减、部分内建函数/部分 UDF）。(Apache Nightlies)

例如这类表达式当前会失败：(Apache Nightlies)

sql 复制代码

SELECT *
FROM paimon_tb
FOR SYSTEM_TIME AS OF TO_TIMESTAMP_LTZ(0, 3);

会抛出类似异常（核心意思是：无法把表达式归约成常量）：(Apache Nightlies)

Unsupported time travel expression: ... can not be reduced to a constant by Flink.

工程建议 ：Time Travel 的时间点尽量写成"可直接计算出的字面量 TIMESTAMP"，把复杂计算放在应用侧或 SQL 外层预计算（但注意：该表达式不能对 view/subquery 生效）。(Apache Nightlies)

这是 Time Travel 最容易踩的大坑之一：

Flink 提供了 table.local-time-zone 来控制会话/作业本地时区：(Apache Nightlies)

sql 复制代码

-- 例如强制统一用 UTC（推荐生产环境）
SET 'table.local-time-zone' = 'UTC';

这样做的意义：避免你在开发机（Asia/Shanghai）和集群（UTC 或 America/Los_Angeles）跑同一条 SQL，查到的"历史点"发生偏移。(Apache Nightlies)

语法：FROM t FOR SYSTEM_TIME AS OF <timestamp_expression> (Apache Nightlies)
前提：Catalog 必须实现 getTable(ObjectPath, long timestamp) 才能按时间点拿表 (Apache Nightlies)
限制：时间表达式必须能归约成常量；复杂函数/UDF 可能直接报不支持 (Apache Nightlies)
时区坑 ：Time Travel 会按 local time zone 把 TIMESTAMP 转 LONG，同 SQL 不同时区可能结果不同；生产建议固定 table.local-time-zone=UTC (Apache Nightlies)