BigQuery Python: query's werken via de proxy, downloads mislukken
Controleer of het downloaden van BigQuery Python-resultaten een Storage API-client aanmaakt los van het HTTP-pad van de query.
Een query kan met succes voltooien en toch mislukken bij het downloaden van het resultaat naar pandas. De BigQuery Python-bibliotheek kan voor die download een aparte BigQuery Storage API-client gebruiken.
De interface RowIterator.to_dataframe documenteert create_bqstorage_client, dat standaard op true staat, en een argument bqstorage_client. Lees die instellingen samen met de afhankelijkheden die in de applicatie aanwezig zijn. Succes op het gewone querypad bewijst niet dat het optionele downloadtransport dezelfde proxyondersteuning of configuratie heeft.
| Fase | Wat te inspecteren |
|---|---|
| Verkrijgen van inloggegevens | Het transport van inloggegevens en het identiteitseindpunt |
| Een query indienen en pollen | Het aanvraagpad van de BigQuery-client |
| Downloaden via Storage API | De Storage API-client en het transport ervan |
Voor een gecontroleerde vergelijking voorkomt de gedocumenteerde optie create_bqstorage_client=False dat die extra client automatisch wordt aangemaakt. Dat kan helpen vaststellen welk pad mislukt. Het is een transportkeuze met prestatiegevolgen, geen bewijs dat de proxy zelf is gerepareerd.
Als de applicatie een eigen Storage API-client levert, configureer die client dan bewust. Ga er niet van uit dat een aangepast HTTP-object dat aan een andere client is gekoppeld, die opnieuw configureert.
Oudere voorbeelden bespreken verouderde httplib2-implementaties of privé-constructorhaken. Stem de integratie af op de generatie van de geïnstalleerde bibliotheek en houd de faalfase in het rapport. Een DataFrame-conversiefout en een geweigerde netwerkverbinding zijn verschillende uitkomsten, zelfs wanneer ze in dezelfde methodeaanroep optreden.