2013-10-02 16 views
5

Stiamo lavorando alla scrittura di un wrapper per bq.py e si riscontrano alcuni problemi con set di risultati superiori a 100k righe. Sembra che in passato questo ha funzionato bene (abbiamo avuto problemi correlati con Google BigQuery Incomplete Query Replies on Odd Attempts). Forse non sto capendo i limiti spiegati nello doc page?bq.py Non risultati cercapersone

Ad esempio:

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

Rendimenti (notare ci sono 4 linee di formattazione):

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

Nel nostro involucro, si accede direttamente l'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', []) 

Noi ci si aspetta di ottenere un token in questo caso, ma nessuno viene restituito.

risposta

1

scusate, mi ci è voluto un po 'per tornare da voi.

Sono stato in grado di identificare un bug che esiste sul lato server, si finirebbe per vederlo con il client Java e il client python. Stiamo pianificando di spingere una soluzione questa settimana. Il tuo cliente dovrebbe iniziare a comportarsi correttamente non appena ciò accade.

BTW, non sono sicuro che lo sapessi già o meno, ma c'è un intero client python standalone che puoi usare per accedere all'API da python. Ho pensato che potrebbe essere un po 'più conveniente per te rispetto al client distribuito come parte di bq.py. Troverai un collegamento ad esso in questa pagina: https://developers.google.com/bigquery/client-libraries

+0

Grazie per l'informazione, non vediamo l'ora di cambiare. Siamo a conoscenza dei client API e in origine li usavamo esclusivamente. Tuttavia, abbiamo riscontrato numerosi problemi, alcuni dovuti a cambiamenti API che ci hanno costretto a prendere in considerazione alternative. bq.py implementa quasi tutte le funzionalità di cui abbiamo bisogno e sono un grande fan del riutilizzo del codice testato quando possibile.Inoltre, il codice di flusso di autenticazione incorporato è molto più fluido di quello che avrei potuto ottenere :-) Per favore fateci sapere quando i cambiamenti sono in diretta. –

+0

Hey Jacob, Fai un tentativo ora e fammi sapere se hai ancora un problema. – Eric

+0

Si trattava di un cambio di backend, o dovrei fare qualcosa di diverso? Lo script di dimostrazione che ho dato sopra genera gli stessi risultati errati. Allo stesso modo, il nostro wrapper attorno al codice fallisce ancora per query simili. –

1

Posso riprodurre il comportamento visualizzato con la riga di comando bq. Sembra un bug, vedrò cosa posso fare per risolverlo.

Una cosa che ho notato dei dati che stai richiedendo era quella di selezionare solo il campo id e limitare il numero di righe attorno a 100.000. Ciò produce circa 1 milione di dati in modo che il server non possa impaginare i risultati. La selezione di una maggiore quantità di dati costringerà il server a paginare poiché non sarà in grado di restituire tutti i risultati in un'unica risposta. Se hai selezionato * per 100.000 file di samples.wikipedia avresti ricevuto circa 50 milioni di copie, il che dovrebbe essere sufficiente per iniziare a vedere l'impaginazione.

Stai vedendo troppo pochi risultati tornare dal client python o sei rimasto sorpreso dal fatto che non è stato restituito page_token per la tua query samples.wikipedia?

+0

Entrambi in realtà - Avevo l'impressione che l'impaginazione fosse basata sulla dimensione della riga anziché sulla dimensione dei dati grezzi. La documentazione è piuttosto confusa su questo argomento, in particolare quando interviene la paginazione e qual è il set di risultati di paging massimo. In ogni caso, stiamo ancora ottenendo troppe poche righe sia in bq.py che nel nostro codice che chiama direttamente l'API (usando bq.py come driver). –

+0

C'è una tempistica per questa correzione? Si tratta di una seria limitazione per il nostro attuale flusso di lavoro. Sembra essere un problema di API, che mi aspetterei possa interessare anche altri client. –

+0

Questo problema riguarda anche il client API Java? Abbiamo alcune analisi che sono un po 'fermi e stiamo cercando qualche soluzione. Ciò richiederà una modifica nel codice cliente? Ci stiamo preparando a introdurre un modulo connettore nella produzione e dobbiamo assicurarci che i requisiti di dipendenza siano soddisfacenti. –

Problemi correlati