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 і адхіленае сеткавае злучэнне — розныя вынікі, нават калі яны ўзнікаюць у адным выкліку метаду.