BigQuery Python: spørringer fungerer gjennom proxyen, nedlastinger feiler
Sjekk om nedlastingen av BigQuery Python-resultatet oppretter en Storage API-klient uavhengig av spørringens HTTP-løp.
En spørring kan fullføres med suksess og likevel feile når resultatet lastes ned til pandas. BigQuery Python-biblioteket kan bruke en egen BigQuery Storage API-klient for den nedlastingen.
RowIterator.to_dataframe-grensesnittet dokumenterer create_bqstorage_client, som har standardverdien true, og et bqstorage_client-argument. Les disse innstillingene sammen med avhengighetene som finnes i applikasjonen. Suksess på det vanlige spørringsløpet beviser ikke at den valgfrie nedlastingstransporten har samme proxy-støtte eller konfigurasjon.
| Trinn | Hva du bør undersøke |
|---|---|
| Anskaffelse av legitimasjon | Legitimasjonstransporten og identitetsendepunktet |
| Sende inn og polle en spørring | Forespørselsløpet til BigQuery-klienten |
| Laste ned via Storage API | Storage API-klienten og transporten dens |
For en kontrollert sammenligning unngår det dokumenterte alternativet create_bqstorage_client=False automatisk opprettelse av den ekstra klienten. Det kan hjelpe med å identifisere hvilket løp som feiler. Det er et transportvalg med ytelseskonsekvenser, ikke bevis på at selve proxyen ble reparert.
Hvis applikasjonen leverer sin egen Storage API-klient, konfigurer den klienten bevisst. Ikke anta at et tilpasset HTTP-objekt festet til en annen klient rekonfigurerer den.
Eldre eksempler diskuterer utdaterte httplib2-implementasjoner eller private konstruktørkroker. Tilpass integrasjonen til bibliotekgenerasjonen som er installert, og behold feiltrinnet i rapporten. En DataFrame-konverteringsfeil og en avvist nettverkstilkobling er forskjellige utfall selv når de skjer i samme metodekall.