BigQuery Python: les consultes funcionen a través del proxy, les baixades fallen
Comproveu si la baixada de resultats de BigQuery Python crea un client de Storage API independentment del camí HTTP de la consulta.
Una consulta pot completar-se correctament i, tot i així, fallar en baixar-ne el resultat a pandas. La biblioteca BigQuery Python pot utilitzar un client de BigQuery Storage API separat per a aquesta baixada.
La interfície RowIterator.to_dataframe documenta create_bqstorage_client, que per defecte és true, i un argument bqstorage_client. Llegiu aquests paràmetres juntament amb les dependències presents a l'aplicació. L'èxit al camí habitual de la consulta no demostra que el transport opcional de baixada tingui el mateix suport o configuració de proxy.
| Etapa | Què cal inspeccionar |
|---|---|
| Obtenció de credencials | El transport de credencials i el punt final d'identitat |
| Enviament i sondeig d'una consulta | El camí de sol·licitud del client de BigQuery |
| Baixada mitjançant Storage API | El client de Storage API i el seu transport |
Per a una comparació controlada, l'opció documentada create_bqstorage_client=False evita crear automàticament aquest client addicional. Això pot ajudar a identificar quin camí falla. És una elecció de transport amb implicacions de rendiment, no una prova que el proxy s'hagi reparat.
Si l'aplicació proporciona el seu propi client de Storage API, configureu-lo deliberadament. No assumiu que un objecte HTTP personalitzat adjunt a un altre client el reconfigurarà.
Els exemples antics parlen d'implementacions obsoletes de httplib2 o de ganxos de constructor privats. Feu coincidir la integració amb la generació de biblioteca instal·lada i conserveu l'etapa de fallada a l'informe. Un error de conversió a DataFrame i una connexió de xarxa rebutjada són resultats diferents fins i tot quan es produeixen a la mateixa crida de mètode.