在时间分区的大查询表中，数据何时写入__UNPARTITIONED__?效果如何

Question

我遇到了一些时间分区的bigquery表的异常未记录行为：

我在BigQuery中创建了一个时间分区表，并插入了数据。我能够正常插入-数据被写入今天的分区(我也能够显式地指定一个分区并写入其中)

在对新数据进行了一些测试后，我删除了今天的分区，以便获得干净的数据：(CLI)

bq --project_id=my-project rm v1.mytable$20160613

然后我检查它是否是空的：

select count(*) from [v1.mytable]

结果270而不是0

我再次尝试删除并重新运行查询，结果相同。所以我查询了

select count(*) from [v1.mytable$20160613]

结果0

所以之前的几个日期我可能插入了数据，但都是0。最后我运行

SELECT partition_id from [v1.mytable$__PARTITIONS_SUMMARY__];

结果为

｛未发表20160609 20160613｝

事实上，所有数据都在UNPARTITIONED中

我的问题：

1. 什么时候将数据写入这个特殊分区而不是日常分区，我如何避免这种情况
2. 除了失去处理特定日期的能力(在查询中或删除数据时等)之外，还有其他影响吗？我应该处理这个案子吗

Answer 1

1. 当数据在流缓冲区时，它仍保留在UNARTITIONED分区中。要在查询中处理此分区，可以使用_PARTITIONTIME伪列的值NULL。

   SELECT ... FROM mydataset.mypartitioned_table WHERE _PARTITIONTIME IS NULL

2. 要删除给定分区的数据，我们建议使用返回空结果的查询对其进行写截断。例如：

   bq query --destination_table=mydataset.mypartitionedtable$20160121 --replace 'SELECT 1 as field1, "one" as field2 FROM (SELECT 1 as field1, "one" as field2) WHERE FALSE'

请注意，分区仍然存在(如果您从表$__PARTITIONS__SUMMARY中执行SELECT*)，但它将有0行。

$ bq query 'SELECT COUNT(*) from [mydataset.mypartitionedtable$20160121]'
+-----+
| f0_ |
+-----+
|   0 |
+-----+

Answer 2

这是一个临时状态——一个小时后查询所有记录都属于今天的分区。

因此，效果类似于数据写入的延迟：插入后立即查询可能没有正确分区中的最新数据，但最终这将是正常的