5

現在、 bq.pyのラッパーの作成に取り組んでおり、10万行を超える結果セットで問題が発生しています。過去にはこれでうまくいったようです ( Google BigQuery Incomplete Query Replies on Odd Attempts に関連する問題がありました)。おそらく、ドキュメントページで説明されている制限を理解していないのでしょうか?

例えば：

#!/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

Yields (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', [])

この場合、トークンを取得することが期待されますが、何も返されません。

4

2 に答える 2

1

あなたが見ている動作を bq コマンドラインで再現できます。これはバグのようです。修正するために何ができるか見ていきます。

クエリしているデータについて気づいたことの 1 つは、id フィールドのみを選択し、行数を 100,000 前後に制限していることです。これにより、約 1M 相当のデータが生成されるため、サーバーは結果をページ分割しない可能性があります。大量のデータを選択すると、1 回の応答ですべての結果を返すことができないため、サーバーは強制的にページ分割されます。100,000 行の samples.wikipedia に対して select * を実行した場合、〜 50M が返されます。これは、ページネーションが発生するのを確認するのに十分なはずです。

Python クライアントから返される結果が少なすぎることを確認していますか、それとも、samples.wikipedia クエリに対して page_token が返されなかったことに驚きましたか?

于 2013-10-02T23:19:14.710 に答える