BigQuery Python: navrae werk deur die proxy, aflaaie misluk
Kontroleer of die BigQuery Python-resultaataflaai 'n Storage API-kliënt onafhanklik van die navraag se HTTP-pad skep.
'n Navraag kan suksesvol voltooi en steeds misluk wanneer die resultaat na pandas afgelaai word. Die BigQuery Python-biblioteek kan 'n afsonderlike BigQuery Storage API-kliënt vir daardie aflaai gebruik.
Die RowIterator.to_dataframe-koppelvlak dokumenteer create_bqstorage_client, wat by verstek true is, en 'n bqstorage_client-argument. Lees daardie instellings saam met die afhanklikhede wat in die toepassing teenwoordig is. Sukses op die gewone navraagpad bewys nie dat die opsionele aflaai-transport dieselfde proxy-ondersteuning of -konfigurasie het nie.
| Fase | Wat om te ondersoek |
|---|---|
| Bewerking van geloofsbriewe | Die geloofsbrief-transport en identiteits-eindpunt |
| Indiening en peiling van 'n navraag | Die BigQuery-kliënt se versoekpad |
| Aflaai deur Storage API | Die Storage API-kliënt en sy transport |
Vir 'n beheerde vergelyking vermy die gedokumenteerde create_bqstorage_client=False-opsie die outomatiese skepping van daardie ekstra kliënt. Dit kan help om te bepaal watter pad misluk. Dit is 'n transportkeuse met prestasie-implikasies, nie bewys dat die proxy self herstel is nie.
As die toepassing sy eie Storage API-kliënt verskaf, konfigureer daardie kliënt doelbewus. Moenie aanneem dat 'n pasgemaakte HTTP-objek wat aan 'n ander kliënt gekoppel is, dit herkonfigureer nie.
Ouer voorbeelde bespreek verouderde httplib2-implementasies of private konstruktor-hake. Pas die integrasie by die geïnstalleerde biblioteekgenerasie aan, en hou die mislukkingsfase in die verslag. 'n DataFrame-omskakelingsfout en 'n verwerpte netwerkverbinding is verskillende uitkomste, selfs wanneer hulle in dieselfde metode-oproep voorkom.