bq.py不寻呼结果

我们正在编写bq.py的包装，并且在结果集大于100k行时遇到了一些问题。它似乎在过去这一直工作得很好（我们有与Google BigQuery Incomplete Query Replies on Odd Attempts相关的问题）。也许我不理解在doc page上解释的限制？bq.py不寻呼结果

例如：

#!/bin/bash 

for i in `seq 99999 100002`; 
do 
    bq query -q --nouse_cache --max_rows 99999999 "SELECT id, FROM [publicdata:samples.wikipedia] LIMIT $i" > $i.txt 
    j=$(cat $i.txt | wc -l) 
    echo "Limit $i Returned $j Rows" 
done

产量（注意有4行格式）：

Limit 99999 Returned 100003 Rows 
Limit 100000 Returned 100004 Rows 
Limit 100001 Returned 100004 Rows 
Limit 100002 Returned 100004 Rows

在我们的包装，我们直接访问API：

while row_count < total_rows: 
    data = client.apiclient.tabledata().list(maxResults=total_rows - row_count, 
               pageToken=page_token, 
               **table_dict).execute() 

    # If there are more results than will fit on a page, 
    # you will recieve a token for the next page 
    page_token = data.get('pageToken', None) 

    # How many rows are there across all pages? 
    total_rows = min(total_rows, int(data['totalRows'])) # Changed to use get(data[rows],0) 
    raw_page = data.get('rows', [])

我们在这种情况下会期望得到一个令牌，但是没有返回。

来源

2013-10-02 Jacob Schaer

对不起，我花了一点时间回到你身边。

我能够识别服务器端存在的错误，最终你会看到这与Java客户端以及Python客户端。我们计划在未来一周内推出修补程序。一旦发生这种情况，您的客户应该开始正确行为。

顺便说一句，我不知道你是否已经知道这一点，但有一个完整的独立Python客户端，你也可以使用它从python访问API。我认为这可能比作为bq.py一部分发布的客户端更方便一些。您可以在此页面上找到它的链接： https://developers.google.com/bigquery/client-libraries

来源

2013-10-08 23:45:48 Eric

感谢您的信息 - 我们期待着这一变化。我们知道API客户端，并且最初只是使用它。但是，我们遇到了很多问题，其中一些原因是API的变化，迫使我们考虑替代方案。 bq.py实现了我们需要的几乎所有功能，并且我尽可能地重用了经过测试的代码。此外，内置的身份验证流程代码比我能想到的要流畅得多:-) 请让我们知道更改何时生效。 –

嘿雅各布，现在给它一个镜头，让我知道如果你仍然有问题。 – Eric

这是一个后端改变，还是我需要做一些不同的事情？我上面给出的演示脚本生成了相同的错误结果。同样，我们的代码包装仍然失败，类似的查询。 –

我可以重现您在bq命令行中看到的行为。这看起来像一个错误，我会看看我能做些什么来修复它。

我曾经注意到有关您要查询的数据的一件事是仅选择id字段，并将行数限制在100,000左右。这会产生大约1M的数据，因此服务器可能不会对结果进行分页。选择更大量的数据将强制服务器进行分页，因为它无法在单个响应中返回所有结果。如果你选择了* 100,000行的samples.wikipedia，你会得到约50M的回应，这应该足以开始看到一些分页发生。

您是否看到python客户端返回的结果太少，或者您惊讶于您的samples.wikipedia查询没有返回page_token？

来源

2013-10-02 23:19:14 Eric

两者实际上 - 我的印象是基于行大小而不是原始数据大小。文档在这个问题上相当混乱，特别是当分页开始时以及最大分页结果集是什么时。无论如何，我们仍然直接在bq.py和我们直接调用API的代码（使用bq.py作为驱动程序）中获得太少行。 –

是否有此修复程序的时间表？这是我们当前工作流程的严重限制。这似乎是一个API问题，我期望它也会影响其他客户端。 –

此问题是否也影响Java API客户端？我们有一些分析报告有些停滞不前，我们正在寻找一些解决方法。这是否需要更改客户端代码？我们正准备将连接器模块投入生产，并且我们需要确保依赖性要求没有问题。 –

bq.py不寻呼结果

回答

相关问题