BigQuery Python: frågor fungerar genom proxyn, nedladdningar misslyckas
Kontrollera om nedladdningen av BigQuery Python-resultatet skapar en Storage API-klient oberoende av frågans HTTP-väg.
En fråga kan slutföras framgångsrikt och ändå misslyckas när resultatet laddas ned till pandas. BigQuery Python-biblioteket kan använda en separat BigQuery Storage API-klient för den nedladdningen.
Gränssnittet RowIterator.to_dataframe dokumenterar create_bqstorage_client, som har standardvärdet true, och ett bqstorage_client-argument. Läs dessa inställningar tillsammans med de beroenden som finns i applikationen. Framgång på den vanliga frågevägen bevisar inte att den valfria nedladdningstransporten har samma proxy-stöd eller konfiguration.
| Steg | Vad du bör undersöka |
|---|---|
| Anskaffning av autentiseringsuppgifter | Autentiseringsuppgifternas transport och identitetsändpunkten |
| Skicka in och polla en fråga | BigQuery-klientens begärandeväg |
| Ladda ned via Storage API | Storage API-klienten och dess transport |
För en kontrollerad jämförelse undviker det dokumenterade alternativet create_bqstorage_client=False att den extra klienten skapas automatiskt. Det kan hjälpa till att identifiera vilken väg som misslyckas. Det är ett transportval med prestandakonsekvenser, inte bevis på att själva proxyn reparerades.
Om applikationen tillhandahåller sin egen Storage API-klient ska den klienten konfigureras medvetet. Anta inte att ett anpassat HTTP-objekt kopplat till en annan klient konfigurerar om den.
Äldre exempel diskuterar föråldrade httplib2-implementeringar eller privata konstruktorkrokar. Anpassa integrationen till den installerade biblioteksgenerationen och behåll felsteget i rapporten. Ett DataFrame-konverteringsfel och en avvisad nätverksanslutning är olika utfall även när de inträffar i samma metodanrop.