BigQuery Python: барањата работат преку прокси, преземањата не успеваат
Проверете дали преземањето на резултатот во BigQuery Python создава одделен клиент на Storage API независно од HTTP патеката на барањето.
Барањето може успешно да заврши, а сепак да не успее при преземањето на неговиот резултат во pandas. Библиотеката BigQuery Python може да користи одделен клиент на BigQuery Storage API за тоа преземање.
Интерфејсот RowIterator.to_dataframe документира create_bqstorage_client, чија стандардна вредност е true, и аргумент bqstorage_client. Читајте ги тие поставки заедно со зависностите присутни во апликацијата. Успехот на обичната патека на барање не докажува дека изборниот транспорт за преземање има иста поддршка за прокси или иста конфигурација.
| Фаза | Што да се провери |
|---|---|
| Добивање акредитиви | Транспортот на акредитивите и крајната точка за идентитет |
| Поднесување и анкетирање на барање | Патката на барањето на клиентот BigQuery |
| Преземање преку Storage API | Клиентот на Storage API и неговиот транспорт |
За контролирана споредба, документираната опција create_bqstorage_client=False го избегнува автоматското создавање на тој дополнителен клиент. Тоа може да помогне да се утврди која патека не успева. Тоа е избор на транспорт со последици врз перформансите, а не доказ дека самиот прокси бил поправен.
Ако апликацијата обезбедува сопствен клиент на Storage API, конфигурирајте го тој клиент намерно. Не претпоставувајте дека прилагоден HTTP објект прикачен на друг клиент ќе го реконфигурира.
Понестари примери зборуваат за застарени httplib2 имплементации или приватни куки на конструкторот. Усогласете ја интеграцијата со генерацијата на инсталираната библиотека и задржете ја фазата на неуспех во извештајот. Грешка при конверзија во DataFrame и одбиена мрежна врска се различни исходи дури и кога се случуваат во истиот повик на методот.