google-bigquery - BigQuery 中的错误或新行为？

Question

自两天前(2016 年 8 月 10 日)以来，曾经可以工作的查询(使用 Google Analytics Premium 的 BQ 导出表)已停止工作。它返回以下错误:

Error: Cannot union tables : Incompatible types. 'hits.latencyTracking.userTimingVariable' : TYPE_INT64 'hits.latencyTracking.userTimingVariable' : TYPE_STRING

经过一番调查，当我查询8月10日之前和之后的表(表ga_sessions_20160810)时，在WHERE子句中使用IN似乎有问题。

我已经简化了我的原始查询以提供一个具有相同基本结构的虚拟查询。以下查询有效(查询 2016-08-08 和 2016-08-09 的数据):

SELECT fullVisitorId, sum(totals.visits)
FROM (select * from TABLE_DATE_RANGE([XXXXXXXX.ga_sessions_],TIMESTAMP('2016-08-08'),TIMESTAMP('2016-08-09')))
WHERE fullVisitorId in(
    SELECT fullVisitorId
    FROM TABLE_DATE_RANGE([XXXXXXXX.ga_sessions_],TIMESTAMP('2016-08-08'),TIMESTAMP('2016-08-09'))
)
GROUP BY fullVisitorId

但是另一个(只是更改日期，在本例中为 2016-08-09 和 2016-08-10)返回错误:

SELECT fullVisitorId, sum(totals.visits)
FROM (select * from TABLE_DATE_RANGE([XXXXXXXX.ga_sessions_],TIMESTAMP('2016-08-09'),TIMESTAMP('2016-08-10')))
WHERE fullVisitorId in(
    SELECT fullVisitorId
    FROM TABLE_DATE_RANGE([XXXXXXXX.ga_sessions_],TIMESTAMP('2016-08-09'),TIMESTAMP('2016-08-10'))
)
GROUP BY fullVisitorId

如果我删除 WHERE 子句或者我只是在 IN 中尝试查询，最后一个查询工作正常，所以我猜问题出在结构 WHERE 字段 IN(...) 上。此外，仅查询 2016-08-10 中的数据确实有效。此外，使用与 fullVisitorId 不同的字段并在不同的 BQ 项目中运行相同的查询也会发生同样的情况。

查看错误描述，应该是变量类型的问题，但不知道hits.latencyTracking.userTimingVariable是什么。我的查询过去可以正常工作，因此我无法弄清楚产生错误的更改。某些字段是否更改了它们的类型或发生了什么？

有没有人经历过这个？这是 BigQuery 中的错误还是新行为？如何解决这个错误？

Answer 1

当您在 select 子句中使用 * 时，当联合发生时它可能会导致问题，它试图组合两种不同的列类型(因为架构从 INT64 更改为 STRING)。

我有两种方法

1) 仅使用您需要的那些字段，而不是在 select 子句中使用 *

SELECT fullVisitorId, sum(totals.visits)
 FROM (select fullVisitorId,totals.visits from TABLE_DATE_RANGE([XXXXXXXX.ga_sessions_],TIMESTAMP('2016-08-09'),TIMESTAMP('2016-08-10')))
  WHERE fullVisitorId in(
   SELECT fullVisitorId
    FROM TABLE_DATE_RANGE([XXXXXXXX.ga_sessions_],TIMESTAMP('2016-08-09'),TIMESTAMP('2016-08-10'))
  ) GROUP BY fullVisitorId

2) 使用 View 拆分内部查询并在稍后的查询中使用 View 。 (即使您只需要使用那些必填字段)

SELECT fullVisitorId, sum(totals.visits)
 FROM [view.innertable2]
  WHERE fullVisitorId in(
    SELECT fullVisitorId from [view.innertable1] ) GROUP BY fullVisitorId

这将排除 hits.latencyTracking.userTimingVariable所以不会有错误。