Google Big Query Storage API返回时区信息的FastAvro或Pytz不一致

Question

我正在使用Python中的Big Query Storage API读取数据(google-cloud-bigquery-storage==0.4.0，今天也用0.5.0进行了检查)。

对于代码：

result = bq_client.query(sql, project=project).result()
return result.to_dataframe(bqstorage_client=bqs_client)

从一些查询中，SELECT-ing a TIMESTAMP列，我得到以下Pandas DataFrame数据类型：

datetime64[ns, <fastavro._timezone.UTCTzinfo object at 0x...>]

其中，时区信息以fastavro类型存储

对于其他表，我得到

datetime64[ns, UTC]

时区信息存储在pytz对象中。

据我所知(源表不在我的控制范围内，我不能使用公共数据集进行复制)，这似乎是任意的--例如，添加limit子句会导致pytz输出--尽管总是与相同的查询保持一致。

有没有办法总是把pytz格式恢复过来？( avro TZ不可序列化，因此需要识别和转换)。

当会话到期时，这是否会恢复？(24小时？或者是否有可能强制会话结束？)

(不确定支持请求的最佳位置在哪里，但很欣赏Beta版的Big Query Storage API，所以在这里尝试一下。)

编辑:我目前正在通过这样做来解决这个问题

for col in train_df.select_dtypes('datetimetz'): 
    train_df[col] = train_df[col].dt.tz_convert(pytz.UTC)

Answer 1

这看起来像是较新版本中修复的错误，可能与查询结果集中的日期溢出有关。

它看起来是一个关于处理溢出时间戳的剩余问题，根据数据集中的其他值(post的最后一行)，这些时间戳的处理方式是不同的。

原始数据：

2019-09-01T12:34:56.123456789,2019-09-01T12:34:56.123456789Z
2019-09-02T12:34:56.123456789,3019-09-01T12:34:56.123456789Z

日期3019-09-01是对numpy datetime64的故意溢出

创建表：

bq mk -t chris.storage_api_test ts0:TIMESTAMP,ts1:TIMESTAMP
bq load chris.storage_api_test dates.csv

脚本(Python 3.6)：

from google.cloud import bigquery
from google.cloud import bigquery_storage
import pandas as pd

bq_client, bqs_client = bigquery.Client(), bigquery_storage.BigQueryStorageClient()
PROJ = '<PROJECT>'
TABLE = 'chris.storage_api_test'

print("BigQuery Version", bigquery.__version__)

print("="*20, "Table", "="*20)

table = bigquery.TableReference.from_string(f'{PROJ}.{TABLE}')
rows = bq_client.list_rows(table)
df = rows.to_dataframe(bqstorage_client=bqs_client)
print(df.dtypes)
print(df)

print("="*20, "ts0", "="*20)
query = f"select ts0 from {PROJ}.{TABLE}"
result = bq_client.query(query).result()
df = result.to_dataframe(bqstorage_client=bqs_client)
print(df.dtypes)
print(df)

print("="*20, "ts1", "="*20)
query = f"select ts1 from {PROJ}.{TABLE}"
result = bq_client.query(query).result()
df = result.to_dataframe(bqstorage_client=bqs_client)
print(df.dtypes)
print(df)

使用BigQuery 1.12.1 / BQS 0.4.0

Table -> FastAvro 'error' and String column  
ts0 only -> datetime64[ns, pytz.UTC]  
ts1 only -> String



BigQuery Version 1.12.1
==================== Table ====================
ts0    datetime64[ns, <fastavro._timezone.UTCTzinfo o...
ts1                                               object
dtype: object
                               ts0                               ts1
0 2019-09-01 12:34:56.123456+00:00  2019-09-01 12:34:56.123456+00:00
1 2019-09-02 12:34:56.123456+00:00  3019-09-01 12:34:56.123455+00:00
==================== ts0 ====================
ts0    datetime64[ns, UTC]
dtype: object
                               ts0
0 2019-09-01 12:34:56.123456+00:00
1 2019-09-02 12:34:56.123456+00:00
==================== ts1 ====================
ts1    object
dtype: object
                                ts1
0  2019-09-01 12:34:56.123456+00:00
1  3019-09-01 12:34:56.123456+00:00

使用BigQuery 1.20.0 /BQS0.7.0

Table -> datetime64 (with overflowed timestamp)  
ts0 only -> datetime64[ns, pytz.UTC]  
ts1 only -> String

BigQuery Version 1.20.0
==================== Table ====================
ts0    datetime64[ns, UTC]
ts1    datetime64[ns, UTC]

                               ts0                                 ts1
0 2019-09-01 12:34:56.123456+00:00    2019-09-01 12:34:56.123456+00:00
1 2019-09-02 12:34:56.123456+00:00 1850-07-23 13:25:48.704352768+00:00
==================== ts0 ====================
ts0    datetime64[ns, UTC]

                               ts0
0 2019-09-01 12:34:56.123456+00:00
1 2019-09-02 12:34:56.123456+00:00
==================== ts1 ====================
ts1    object

                                ts1
0  2019-09-01 12:34:56.123456+00:00
1  3019-09-01 12:34:56.123456+00:00

仍然存在的一个问题是，当在隔离(ts1)中使用溢出的时间戳时，我不会得到时间戳转换，当它使用另一个值(在表中)时，它会被转换为SELECTing。

我认为，考虑到二进制表示的差异(96和64位)，这将始终是一个问题？尽管一致性可能会有所帮助。

谢谢你的回复，抱歉，这是一个冗长的回答/描述，这让人觉得这是一个微妙的问题？