0

我有几个表包含无效的标准 SQLTIMESTAMP记录。这些记录在数组中至少嵌套一层。SELECT *即使在使用 Legacy SQL 时，这些记录也会在这些表上中断。他们还破坏了将表导出为 JSON。当我尝试对UPDATE这些表修复记录时，UPDATE除非该语句同时修复所有损坏的字段，否则它会出现错误。这会导致大量UPDATE声明。示例：https ://gist.github.com/dadrian/b83585c23f6cbbcd5f6d6478c92c745d

该UPDATE语句太大而无法编译！

错误：查询执行期间超出资源：没有足够的资源用于查询计划 - 子查询太多或查询太复杂

然后我采取了第二种方法：为每个包含具有无效时间戳的数组（例如字段）的父字段SELECT“修复”到它自己的表中。然后通过加入每个“固定结构”表来创建原始表。每次发生后，看起来像：STRUCTp443.https.tlsUPDATESELECTUPDATE

UPDATE `scratch.domain_20170819_copy` target
SET 
  target.p443.https.tls = fixed_https.tls,
  target.p443.https_www.tls = fixed_https_www.tls,
  target.p25.smtp.starttls.tls = fixed_smtp_starttls.tls
FROM `scratch.domain_20170819_copy` AS original
INNER JOIN `scratch.domain_20170819_https_tls` AS fixed_https
ON original.domain = fixed_https.domain
INNER JOIN `scratch.domain_20170819_https_www_tls` AS fixed_https_www
ON original.domain = fixed_https_www.domain
INNER JOIN `scratch.domain_20170819_smtp_starttls_tls` AS fixed_smtp_starttls
ON original.domain = fixed_smtp_starttls.domain
WHERE
  original.domain = target.domain
AND
  original.domain = fixed_https.domain
AND
  original.domain = fixed_https_www.domain
AND
  original.domain = fixed_smtp_starttls.domain

这适用于足够小的桌子。在较大的表或具有更多（类似损坏）字段的表上，UPDATE 语句不会完成，并且在大约 30 分钟后出现错误

查询执行期间资源超出：ORDER BY 运算符使用了太多内存。

我怎样才能修复这些表？

编辑：无效的时间戳是由于在我们的数据源中意外地将整数时间戳输出为毫秒而不是秒。BQ 解释为秒，这使得时间戳在 48000 年。

编辑：我将架构和示例数据对象添加到要点中。

模式的快速描述：相关数据的形式为a.b.c.tls，其中tls包含所有损坏数据的父对象。tls包含许多事物certificate，其中 , 是一个对象，而chain, with 是一个对象数组certificate。A certificatecontains parsed.extensions.signed_certificate_timestamps，它是一个结构的数组。signed_certificate_timestamps在is的字段中timestamp，其中包含有问题的无效时间戳。这实际上意味着我对 each 有一个嵌套的无效时间戳...tls.certificate.parsed.extensions.signed_certificate_timestamps，并且对于 every 有一个双重嵌套的无效时间戳...tls.chain.certificate.parsed.....signed_certificate_timestamps。

4

0 回答 0