2013-10-02 40 views
5

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

私たちは、この場合トークンを取得することを期待しますが、返されるものはありません。

答えて

1

申し訳ありません申し訳ありませんが、あなたに戻ってくるのは少し時間がかかりました。

私はサーバー側に存在するバグを特定することができました。あなたはJavaクライアントとPythonクライアントでこれを見ることになります。私たちは今週中に修正を予定しています。クライアントはすぐに正しく動作するようになります。

私はあなたがこれを既に知っているかどうかは分かりませんが、PythonからAPIにアクセスするために使用できる完全なスタンドアロンのPythonクライアントがあります。私はあなたがbq.pyの一部として配布されているクライアントよりもずっと便利だと思っていました。 https://developers.google.com/bigquery/client-libraries

+0

情報をお寄せいただきありがとうございます。我々は変更を楽しみにしています。私たちはAPIクライアントを認識しており、もともとそれを独占的に使用していました。しかし、いくつかの問題に遭遇しました。そのいくつかは、APIの変更によっていくつかの問題を抱えていました。 bq.pyは必要な機能をほとんどすべて実装しています。可能な限り、テストされたコードを再利用することを熱狂しています。また、組み込みの認証フローコードは、私が思いついたよりもはるかにスムーズです。 変更が生存しているときにお知らせください。 –

+0

Hey Jacob、 問題がまだ解決していれば、今すぐ撮影してお知らせください。 – Eric

+0

これはバックエンドの変更ですか、別の何かをする必要がありますか?私が上で与えたデモンストレーションスクリプトは、同じ不正確な結果を生成する。同様に、コードのラッパーも同様のクエリで失敗します。 –

1

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

あなたが照会しているデータについて気付いた点は、idフィールドのみを選択し、100,000周程度の行をキャッピングすることでした。これにより、約1MM相当のデータが生成されるため、サーバーは結果に改ページしない可能性があります。大量のデータを選択すると、1回の応答ですべての結果を返すことができなくなるため、サーバーのページ付けが強制されます。あなたがsamples.wikipediaの100,000行に対して*を選択した場合は、〜50Mのバックを得ることになります。これは、ページネーションが起こるのを見るのに十分なはずです。

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

+0

実際には、ページングは​​生データサイズではなく行サイズに基づいているという印象を受けました。特に、ページネーションが発生した場合や最大ページングされた結果セットが何であるかについて、ドキュメントはこの主題を混乱させます。それにもかかわらず、bq.pyとAPIを直接呼び出すコード(bq.pyをドライバとして使用する)の両方で、行が少なすぎます。 –

+0

この修正プログラムのタイムラインはありますか?現在のワークフローにとって重大な制限です。それは私が他のクライアントにも影響を及ぼすことが予想されるAPIの問題のようです。 –

+0

この問題はJava APIクライアントにも影響しますか?私たちはいくつかの分析を残しており、いくつかの回避策を探しています。これにはクライアントコードの変更が必要ですか?我々は、コネクター・モジュールをプロダクションにプッシュする準備ができており、依存関係の要件が良好であることを確認する必要があります。 –

関連する問題