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 و اتصال شبکه ردشده نتایج متفاوتی هستند حتی وقتی در یک فراخوانی متد رخ دهند.