BigQuery Python: کوئریاں پراکسی کے ذریعے چلتی ہیں، ڈاؤن لوڈ ناکام ہوتے ہیں
جانچیں کہ BigQuery Python کے نتیجے کا ڈاؤن لوڈ کوئری کے HTTP راستے سے آزاد Storage API کلائنٹ بناتا ہے یا نہیں۔
ایک کوئری کامیابی سے مکمل ہو سکتی ہے اور پھر بھی اس کا نتیجہ pandas میں ڈاؤن لوڈ کرتے وقت ناکام ہو سکتی ہے۔ BigQuery Python لائبریری اس ڈاؤن لوڈ کے لیے علیحدہ BigQuery Storage API کلائنٹ استعمال کر سکتی ہے۔
RowIterator.to_dataframe انٹرفیس create_bqstorage_client کی دستاویز کرتا ہے، جس کی طے شدہ قدر true ہے، اور bqstorage_client دلیل کی۔ ان ترتیبات کو ایپلیکیشن میں موجود انحصارات کے ساتھ پڑھیں۔ عام کوئری راستے پر کامیابی یہ ثابت نہیں کرتی کہ اختیاری ڈاؤن لوڈ ٹرانسپورٹ کو وہی پراکسی معاونت یا ترتیب حاصل ہے۔
| مرحلہ | کیا جانچنا ہے |
|---|---|
| اسناد کا حصول | اسناد کی ترسیل اور شناخت کا endpoint |
| کوئری جمع کرانا اور پول کرنا | BigQuery کلائنٹ کا درخواست راستہ |
| Storage API کے ذریعے ڈاؤن لوڈ | Storage API کلائنٹ اور اس کی ترسیل |
کنٹرول شدہ موازنے کے لیے، دستاویزی create_bqstorage_client=False اختیار اس اضافی کلائنٹ کے خودکار بننے سے بچاتا ہے۔ یہ شناخت میں مدد کر سکتا ہے کہ کون سا راستہ ناکام ہوتا ہے۔ یہ کارکردگی پر اثرات رکھنے والا ٹرانسپورٹ انتخاب ہے، اس بات کا ثبوت نہیں کہ پراکسی خود ٹھیک ہو گئی۔
اگر ایپلیکیشن اپنا Storage API کلائنٹ فراہم کرتی ہے تو اس کلائنٹ کو جان بوجھ کر ترتیب دیں۔ یہ مت سمجھیں کہ کسی دوسرے کلائنٹ سے منسلک حسب ضرورت HTTP آبجیکٹ اسے دوبارہ ترتیب دیتا ہے۔
پرانی مثالیں متروک httplib2 نفاذ یا نجی constructor ہکس پر بحث کرتی ہیں۔ انضمام کو نصب شدہ لائبریری کی نسل سے ہم آہنگ کریں، اور ناکامی کے مرحلے کو رپورٹ میں رکھیں۔ DataFrame تبدیلی کی خرابی اور مسترد شدہ نیٹ ورک کنکشن ایک ہی میتھڈ کال میں ہونے پر بھی مختلف نتائج ہیں۔