Snowflake 在 TIMESTAMP_NTZ 列中显示“无效日期”

Teg*_*ale 6 database snowflake-cloud-data-platform

在我们的 Snowflake 数据仓库实例中,当使用 DDL 语句将数据从阶段加载到表中时,timestamp_ntz 列中的某些记录在 Snowflake UI 中COPY INTO显示值。Invalid date

timestamp_ntz 列中的这些Invalid date值具有以下特性:

  • 它们不为 NULL
  • 它们似乎被认为总是大于当前时间戳,并且此属性可用于过滤它们,例如。WHERE strange_timestamp_col > current_timestamp()
  • 它们不是“前端”的东西,即。在 Snowflake UI 中 - 他们使用 Snowflake 中的数据破坏其他客户端

我们希望在尝试执行COPY INTODDL 语句时,无效的数据格式会返回错误;相反,这些具有奇怪属性的邪恶伪时间戳被插入。

Teg*_*ale 6

我们发现我们的暂存 parquet 文件中的一些 unix 时间戳值被格式化为整数,一些被格式化为字符串!

解决方案是始终将列转换为 VARCHAR,然后转换为 TIMESTAMP_NTZ。

使用 unix 时间戳的示例:

SELECT 1620502461213752::timestamp_ntz;->Invalid date

SELECT 1620502461213752::varchar::timestamp_ntz;->2021-05-08 19:34:21.213

SELECT '1620502461213752'::timestamp_ntz;->2021-05-08 19:34:21.213

这似乎是因为timestamp_ntz只接受以毫秒为单位的整数纪元时间戳(例如 1620502461213)。

然而,当整数被转换为varchar第一个时,然后timestamp_ntz正确解释以微秒为单位的纪元时间戳(例如1620502461213752)。这可能也适用于以纳秒为单位的时间戳,尽管我没有证实这种情况。

因此,Invalid date对于遥远的未来时间戳来说,这似乎是一个奇怪的前端问题,是由错误识别纪元时间戳单位造成的。

  • 我完全同意; 这是一次非常不可靠的经历。我们预计无效的数据格式会在尝试“COPY INTO” DDL 时引发错误。不幸的是,这并没有发生,我们在 timestamp_ntz 列中遇到了这些奇怪的“无效日期”值。 (2认同)