timestamp[ns]和timestamp[s]两种时间戳数据类型有什么区别？

二者本质是精度不同的Unix时间戳，方括号内标识的是时间计数的最小单位：

• timestamp[s] 为秒级精度时间戳：以Unix纪元（1970-01-01 00:00:00 UTC）为起点，存储的是到目标时间的整秒数，最小时间粒度为1秒
• timestamp[ns] 为纳秒级精度时间戳：同样以Unix纪元为起点，存储的是到目标时间的纳秒数（1秒=10^9纳秒），最小时间粒度为1纳秒

场景差异说明 #

Parquet/JSON文件中的表现 #

Parquet原生支持多精度timestamp逻辑类型，写入时会根据数据来源自动标记精度：

• 常规业务日志、交易统计类数据如果只记录到秒，通常会存为timestamp[s]
• 性能监控、高频交易、前端埋点等需要高精度时间差统计的场景，普遍会存为timestamp[ns]

Redshift DDL映射规则 #

Redshift原生TIMESTAMP/TIMESTAMPTZ类型最高支持微秒级精度（1秒=10^6微秒），映射时需注意精度损失问题：

• timestamp[s]可直接映射为Redshift的TIMESTAMP，无精度损失
• timestamp[ns]映射为Redshift的TIMESTAMP时会自动截断到微秒位，若业务需要保留完整纳秒精度，需额外新增BIGINT类型字段存储原始纳秒数值

示例对比 #

同一时间点的不同存储值 #

以时间2024-05-20 13:14:15.123456789 UTC为例：

• timestamp[s]存储值为1716182055，转换为可读时间后展示为2024-05-20 13:14:15，小数点后的精度会完全丢弃
• timestamp[ns]存储值为1716182055123456789，转换为可读时间后可完整展示2024-05-20 13:14:15.123456789

Redshift DDL生成示例 #

对应timestamp[s]类型字段create_time的DDL写法：

CREATE TABLE business_order (
    order_id BIGINT,
    create_time TIMESTAMP
);

对应timestamp[ns]类型字段pay_time、需要保留纳秒精度的DDL写法：

CREATE TABLE high_freq_trade (
    trade_id BIGINT,
    pay_time TIMESTAMP, -- 自动截断到微秒，用于普通时间查询
    pay_time_ns BIGINT -- 存储原始纳秒值，用于高精度时间差计算
);

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