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 і відхилене мережеве з'єднання — різні результати, навіть якщо вони трапляються в одному виклику методу.