BigQuery Python: zapytania działają przez proxy, pobieranie się nie udaje
Sprawdź, czy pobieranie wyniku BigQuery Python tworzy osobny klient Storage API niezależnie od ścieżki HTTP zapytania.
Zapytanie może zakończyć się powodzeniem, a mimo to nie udać się przy pobieraniu jego wyniku do pandas. Biblioteka BigQuery Python może do tego pobierania użyć osobnego klienta BigQuery Storage API.
Interfejs RowIterator.to_dataframe dokumentuje create_bqstorage_client, którego domyślna wartość to true, oraz argument bqstorage_client. Czytaj te ustawienia razem z zależnościami obecnymi w aplikacji. Sukces na zwykłej ścieżce zapytania nie dowodzi, że opcjonalny transport pobierania ma takie samo wsparcie proxy lub konfigurację.
| Etap | Co sprawdzić |
|---|---|
| Uzyskiwanie poświadczeń | Transport poświadczeń i punkt końcowy tożsamości |
| Wysyłanie i odpytywanie zapytania | Ścieżka żądania klienta BigQuery |
| Pobieranie przez Storage API | Klient Storage API i jego transport |
W kontrolowanym porównaniu udokumentowana opcja create_bqstorage_client=False pozwala uniknąć automatycznego tworzenia tego dodatkowego klienta. Może to pomóc ustalić, która ścieżka zawodzi. To wybór transportu z konsekwencjami wydajnościowymi, a nie dowód, że samo proxy zostało naprawione.
Jeśli aplikacja dostarcza własnego klienta Storage API, skonfiguruj go świadomie. Nie zakładaj, że niestandardowy obiekt HTTP dołączony do innego klienta przekonfiguruje go.
Starsze przykłady omawiają przestarzałe implementacje httplib2 lub prywatne haki konstruktora. Dopasuj integrację do generacji zainstalowanej biblioteki i zachowaj etap awarii w raporcie. Błąd konwersji DataFrame i odrzucone połączenie sieciowe to różne wyniki, nawet gdy występują w tym samym wywołaniu metody.