छवि पार्सिंग CV-डेटासेट के लिए: प्रॉक्सी और ट्रैफ़िक खपत

कंप्यूटर विजन मॉडल के प्रशिक्षण के लिए हजारों छवियों को इकट्ठा करना एक ऐसा कार्य है जो लगभग हमेशा दो समस्याओं में उलझ जाता है: डेटा स्रोत (Google Images, Pinterest, मार्केटप्लेस, स्टॉक साइट्स) द्वारा ब्लॉकिंग और अप्रत्याशित रूप से उच्च ट्रैफिक खर्च। एक IP जल्दी ही बैन हो जाता है, और प्रॉक्सी ट्रैफिक का बिल डेटासेट के लेबलिंग की लागत से अधिक हो सकता है। इस लेख में हम देखेंगे कि कैसे एक ऐसा छवि पार्सर डिज़ाइन करें जो ब्लॉकों के कारण डेटा खोता नहीं है, और कैसे ट्रैफिक के लिए बजट पहले से ही गणना करें।

CV के लिए छवियों को इकट्ठा करने में प्रॉक्सी की आवश्यकता क्यों है

कंप्यूटर विजन के लिए डेटासेट अक्सर एक ही स्रोत से नहीं इकट्ठा किए जाते। आमतौर पर यह छवियों की खोज परिणाम, मार्केटप्लेस पर उत्पाद कार्ड, फोटो स्टॉक्स, सोशल मीडिया और ओपन API का संयोजन होता है। लगभग सभी ये स्रोत एक ही IP से अनुरोधों की संख्या पर सीमाएँ लगाते हैं: Google Images लगातार कुछ सौ अनुरोधों के बाद कैप्चा दिखाता है, Pinterest अस्थायी रूप से API तक पहुँच को ब्लॉक करता है, और Wildberries और Ozon संदिग्ध गतिविधि पर जांच पृष्ठ पर रीडायरेक्ट करते हैं या खाली कार्ड देते हैं।

बिना प्रॉक्सी के, आप एक पते से प्रति दिन कुछ सौ या हजार छवियों की छत पर पहुँच जाते हैं। यदि आपको 50,000–500,000 छवियों का डेटासेट चाहिए (और यही आमतौर पर वर्गीकरण और पहचान कार्यों में कॉन्वोल्यूशनल नेटवर्क और ट्रांसफार्मर्स के लिए आवश्यक होता है), तो वितरित IP पते के पूल के बिना इसे उचित समय में इकट्ठा करना शारीरिक रूप से असंभव है — आप या तो लगातार ब्लॉकों का सामना करेंगे, या दिन के समय और भू-स्थान के कारण बहुत偏差 वाला नमूना प्राप्त करेंगे।

दूसरी वजह है डेटा का भौगोलिक विविधता। यदि मॉडल को क्षेत्र की शूटिंग के बावजूद समान रूप से वस्तुओं को पहचानना है (जैसे, विभिन्न देशों में सड़क के संकेत या स्थानीय मार्केटप्लेस पर उत्पाद), तो पार्सर को विभिन्न देशों के IP से कनेक्ट करना होगा। एक डेटा सेंटर के एक आउटबाउंड IP से ऐसा विविधता नहीं मिलेगी।

डेटासेट पर वास्तव में कितना ट्रैफिक खर्च होता है

छवियों को इकट्ठा करते समय ट्रैफिक खर्च अक्सर कम आंका जाता है। समस्या केवल छवियों के वजन में नहीं है — HTML पृष्ठ, JS बंडल, प्रीव्यू, ट्रैकिंग पिक्सेल और CSS भी प्रॉक्सी के माध्यम से चलते हैं, यदि पार्सर को आवश्यक URL पर ठीक से सेट नहीं किया गया है।

सामग्री का प्रकार	औसत वजन	10,000 यूनिट पर ट्रैफिक
प्रीव्यू/थंबनेल (150–300 px)	15–40 KB	~250 MB
मध्यम रिज़ॉल्यूशन की फोटो (800–1200 px)	80–200 KB	~1.4 GB
उच्च रिज़ॉल्यूशन की फोटो (2000+ px)	400 KB – 1.5 MB	~9.5 GB
उत्पाद कार्ड का HTML पृष्ठ (बिना छवियों के)	150–400 KB	~2.7 GB

व्यावहारिक रूप से, यदि आप औसत रिज़ॉल्यूशन की 100,000 छवियों को उत्पाद कार्ड के पृष्ठों के साथ इकट्ठा कर रहे हैं (लेबलिंग निकालने के लिए - श्रेणियाँ, बॉक्स, विशेषताएँ), तो कुल ट्रैफिक खर्च आमतौर पर 25–45 GB के बीच होता है। यदि आपको छोटे वस्तुओं की पहचान के लिए उच्च रिज़ॉल्यूशन की छवियों की आवश्यकता है — तो उन 100,000 यूनिट के लिए 80–150 GB की गणना करें। इन आंकड़ों को प्रॉक्सी की योजना बनाते समय पहले से ही ध्यान में रखना चाहिए, न कि बाद में।

Datacenter, residential और mobile: क्या चुनें

छवियों को इकट्ठा करने के लिए तीन पैरामीटर महत्वपूर्ण हैं: गति, ट्रैफिक की लागत और ब्लॉकों के प्रति स्थिरता। विभिन्न प्रकार की प्रॉक्सी में ये पैरामीटर काफी भिन्न होते हैं।

पैरामीटर	Datacenter	Residential	Mobile
गति	उच्च	मध्यम	निम्न-मध्यम
बैन के प्रति स्थिरता	निम्न	उच्च	बहुत उच्च
ट्रैफिक की लागत	निम्न	मध्यम-उच्च	उच्च
के लिए उपयुक्त	ओपन API, बिना सख्त सुरक्षा वाले स्टॉक्स	Google Images, Pinterest, मार्केटप्लेस	सख्त एंटी-बॉट सुरक्षा वाले सोशल मीडिया

अधिकांश छवि संग्रह कार्यों के लिए रेसिडेंशियल प्रॉक्सी सबसे अच्छा संतुलन प्रदान करते हैं — IP सामान्य उपयोगकर्ताओं की तरह दिखते हैं, इसलिए मार्केटप्लेस और छवि खोज इंजनों की एंटी-बॉट सिस्टम कैप्चा को कम ट्रिगर करते हैं। यदि स्रोत एक ओपन फोटो स्टॉक या बिना सख्त सीमाओं वाला API है, तो डेटा सेंटर प्रॉक्सी का उपयोग करना सस्ता है — ये तेज़ होते हैं और प्रति GB कम कीमत पर बड़े ट्रैफिक वॉल्यूम को पारित करने की अनुमति देते हैं। और मोबाइल ऐप्स या एंटी-बॉट सुरक्षा वाले सोशल मीडिया से छवियों को इकट्ठा करने के लिए मोबाइल प्रॉक्सी सबसे उपयुक्त हैं — ये वास्तविक संचार ऑपरेटरों के IP का उपयोग करते हैं और लगभग कभी भी ब्लॉक नहीं होते हैं।

प्रॉक्सी रोटेशन के साथ requests पर बेसिक पार्सर

प्रारंभ करने के लिए, प्रत्येक अनुरोध पर प्रॉक्सी रोटेशन के साथ requests पर एक सरल समकालिक स्क्रिप्ट उपयुक्त है या एक निर्दिष्ट संख्या के अनुरोधों के बाद। नीचे दिए गए उदाहरण में URL की सूची के माध्यम से छवियों को डाउनलोड करने का एक उदाहरण है, जिसमें सामग्री के प्रकार की जांच और फ़ाइल के आकार की सीमा है, ताकि गलती से गलत प्रारूप की भारी फ़ाइल न खींची जाए।

import requests
import itertools
import hashlib
import os

PROXIES = [
    "http://user:[email protected]:10000",
    "http://user:[email protected]:10000",
    "http://user:[email protected]:10000",
]
proxy_cycle = itertools.cycle(PROXIES)

HEADERS = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
    "Accept": "image/avif,image/webp,image/*,*/*;q=0.8",
}

def download_image(url, save_dir="dataset", max_size_mb=10, timeout=15):
    proxy = next(proxy_cycle)
    proxies = {"http": proxy, "https": proxy}
    try:
        resp = requests.get(url, headers=HEADERS, proxies=proxies, timeout=timeout, stream=True)
        resp.raise_for_status()

        content_type = resp.headers.get("Content-Type", "")
        if "image" not in content_type:
            return None

        content_length = int(resp.headers.get("Content-Length", 0))
        if content_length > max_size_mb * 1024 * 1024:
            return None

        file_hash = hashlib.md5(url.encode()).hexdigest()
        ext = content_type.split("/")[-1].split(";")[0]
        filepath = os.path.join(save_dir, f"{file_hash}.{ext}")

        os.makedirs(save_dir, exist_ok=True)
        with open(filepath, "wb") as f:
            for chunk in resp.iter_content(chunk_size=8192):
                f.write(chunk)

        return filepath
    except requests.exceptions.RequestException as e:
        print(f"{proxy} के माध्यम से {url} पर त्रुटि: {e}")
        return None

मुख्य बिंदु — प्रतिक्रिया के शरीर को डाउनलोड करने से पहले Content-Length की जांच करना। यह ट्रैफिक को बचाता है, बहुत भारी फ़ाइलों को पूरी लोडिंग से पहले ही छानता है। itertools.cycle के माध्यम से प्रॉक्सी का रोटेशन IP के बीच लोड को समान रूप से वितरित करता है, किसी विशेष पते के बैन होने के जोखिम को कम करता है।

aiohttp के माध्यम से असिंक्रोनस संग्रह

requests पर समकालिक स्क्रिप्ट कुछ हजार छवियों के लिए अच्छी होती है, लेकिन 50,000 फ़ाइलों के डेटासेट के लिए असिंक्रोनस होना आवश्यक है — अन्यथा संग्रह दिनों तक खिंच जाएगा। aiohttp के साथ समांतरता को सीमित करने के लिए सेमाफोर — बिना प्रॉक्सी पूल को ओवरलोड किए हजारों समवर्ती कार्यों के लिए एक कार्यशील विकल्प है।

import asyncio
import aiohttp
import itertools

PROXIES = [
    "http://user:[email protected]:10000",
    "http://user:[email protected]:10000",
]
proxy_cycle = itertools.cycle(PROXIES)
sem = asyncio.Semaphore(50)  # समांतर अनुरोधों की सीमा

async def fetch_image(session, url, idx):
    proxy = next(proxy_cycle)
    async with sem:
        try:
            async with session.get(url, proxy=proxy, timeout=15) as resp:
                if resp.status != 200:
                    return
                content_type = resp.headers.get("Content-Type", "")
                if "image" not in content_type:
                    return
                data = await resp.read()
                with open(f"dataset/{idx}.jpg", "wb") as f:
                    f.write(data)
        except Exception as e:
            print(f"{url} पर त्रुटि: {e}")

async def main(urls):
    async with aiohttp.ClientSession() as session:
        tasks = [fetch_image(session, url, i) for i, url in enumerate(urls)]
        await asyncio.gather(*tasks)

# asyncio.run(main(url_list))

50 समवर्ती कनेक्शनों के लिए सेमाफोर — प्रारंभिक बिंदु है। यदि रेसिडेंशियल प्रॉक्सी बिना 429 त्रुटियों और टाइमआउट के लोड को सहन करते हैं, तो धीरे-धीरे 100–150 तक बढ़ाना संभव है। मुख्य बात यह है कि असफल अनुरोधों का प्रतिशत मॉनिटर करें: यदि यह 5–7% से अधिक बढ़ता है, तो समांतरता को कम करना चाहिए, न कि प्रॉक्सी पूल को अनंत रूप से बढ़ाना।

बड़े पैमाने पर संग्रह के लिए Scrapy + प्रॉक्सी-मिडलवेयर

उत्पादन स्तर पर डेटासेट को इकट्ठा करने के लिए, जिसमें अंतर्निहित कतार, पुनः प्रयास और URL की डुप्लिकेशन होती है, Scrapy का उपयोग करना ImagesPipeline के साथ अधिक सुविधाजनक है। यह स्वचालित रूप से छवियों को डाउनलोड करता है, उनकी वैधता की जांच करता है और विभिन्न आकारों के प्रीव्यू उत्पन्न कर सकता है।

# settings.py
ITEM_PIPELINES = {
    'scrapy.pipelines.images.ImagesPipeline': 1,
}
IMAGES_STORE = 'dataset_images'
IMAGES_MIN_HEIGHT = 200
IMAGES_MIN_WIDTH = 200

DOWNLOADER_MIDDLEWARES = {
    'myproject.middlewares.ProxyRotationMiddleware': 350,
}

CONCURRENT_REQUESTS = 32
DOWNLOAD_DELAY = 0.5
RETRY_TIMES = 3

# middlewares.py
import random

class ProxyRotationMiddleware:
    PROXIES = [
        "http://user:[email protected]:10000",
        "http://user:[email protected]:10000",
        "http://user:[email protected]:10000",
    ]

    def process_request(self, request, spider):
        request.meta['proxy'] = random.choice(self.PROXIES)

IMAGES_MIN_HEIGHT और IMAGES_MIN_WIDTH पैरामीटर स्वचालित रूप से छोटे आइकनों और स्प्राइट्स को हटा देते हैं, जो डेटासेट को प्रदूषित करते हैं और ट्रैफिक को बेकार में खर्च करते हैं। DOWNLOAD_DELAY 0.5 सेकंड में एक प्रॉक्सी से अनुरोधों की आवृत्ति को कम करता है, जो Pinterest जैसी सख्त एंटी-फ्रॉड निगरानी वाले स्रोतों पर कैप्चा के हिस्से को कम करता है।

ट्रैफिक खर्च को कैसे कम करें

प्रॉक्सी के माध्यम से ट्रैफिक आमतौर पर मात्रा के अनुसार चार्ज किया जाता है, इसलिए कोई भी ऑप्टिमाइजेशन सीधे बजट को बचाता है। यहाँ कुछ कार्यशील तकनीकें हैं:

यदि प्रशिक्षण के लिए 512–1024 px के रिज़ॉल्यूशन की आवश्यकता है, तो मूल छवि के बजाय प्रीव्यू का अनुरोध करें — अधिकांश स्रोत एक अलग URL या क्वेरी पैरामीटर के माध्यम से आवश्यक आकार की छवि प्रदान करते हैं।
शरीर को डाउनलोड करने से पहले Content-Length के अनुसार फ़िल्टर करें — HEAD अनुरोध या स्ट्रीमिंग GET के हेडर पढ़ने से बहुत भारी फ़ाइलों को उनकी लोडिंग पर ट्रैफिक खर्च किए बिना हटा सकते हैं।
यदि पार्सर हेडलेस ब्राउज़र के माध्यम से काम कर रहा है, तो सहायक संसाधनों को लोड करना बंद करें: CSS, फ़ॉन्ट और ट्रैकिंग स्क्रिप्ट को ब्लॉक करें, केवल HTML और आवश्यक छवियों को छोड़कर।
अनुरोध से पहले URL को डुप्लिकेट करें, न कि डाउनलोड के बाद — उत्पाद कार्ड के विभिन्न पृष्ठों पर समान छवियों (जैसे, Wildberries पर) को पुनः डाउनलोड करने की आवश्यकता नहीं है।
पुनः परीक्षण के दौरान उत्तरों के स्थानीय कैश का उपयोग करें ताकि हर परीक्षण कोड के लिए प्रॉक्सी के माध्यम से ट्रैफिक न चलाना पड़े।

आम गलतियाँ, 403 और दर सीमा

बड़ी मात्रा में छवियों को इकट्ठा करते समय, पार्सर अनिवार्य रूप से 403, 429 और जांच पृष्ठों पर अस्थायी रीडायरेक्ट के उत्तरों का सामना करेगा। इन कोडों को सही तरीके से संभालना ट्रैफिक और प्रॉक्सी पूल दोनों को बचाता है।

कोड/लक्षण	कारण	क्या करें
403 निषिद्ध	IP स्रोत की काली सूची में है	प्रॉक्सी रोटेशन, User-Agent बदलें
429 बहुत अधिक अनुरोध	प्रति मिनट अनुरोधों की सीमा पार हो गई	DOWNLOAD_DELAY बढ़ाएँ, समांतरता कम करें
कैप्चा पर रीडायरेक्ट	व्यवहार विश्लेषण ने बॉट को संदेह किया	रेसिडेंशियल/मोबाइल IP पर स्विच करें
खाली Content-Length	Chunked प्रतिक्रिया या छवि के बजाय प्लेसहोल्डर	डाउनलोड किए गए बाइट्स का वास्तविक आकार जांचें

प्रत्येक प्रॉक्सी के लिए सफल अनुरोधों के हिस्से को अलग से लॉग करना महत्वपूर्ण है। यदि कोई विशेष IP अन्य सभी की तुलना में स्थिर रूप से 403 देता है — तो उसे स्वचालित रूप से रोटेशन से बाहर निकालें, यह प्रतीक्षा किए बिना कि वह पूरे पूल के लिए सामान्य ब्लॉक के आंकड़ों को खींचेगा।

प्रॉक्सी ट्रैफिक के लिए बजट की गणना

संग्रह शुरू करने से पहले, ट्रैफिक की मात्रा का अनुमान लगाना उपयोगी है, न कि बाद में गणना करना। सूत्र सरल है: छवियों की संख्या × फ़ाइल का औसत वजन × ओवरहेड का गुणांक (HTML, हेडर, त्रुटियों के कारण पुनः अनुरोध — आमतौर पर 1.3–1.6)।

औसत रिज़ॉल्यूशन (~150 KB) के 200,000 छवियों के डेटासेट के लिए गणना का उदाहरण उत्पाद कार्ड के पार्सिंग के साथ: 200,000 × 150 KB = 30 GB छवियों का शुद्ध वजन। HTML पृष्ठों और अस्थायी ब्लॉकों के कारण पुनः अनुरोधों को ध्यान में रखते हुए (गुणांक 1.5) कुल खर्च — लगभग 45 GB। यदि कुछ स्रोतों को एंटी-बॉट सुरक्षा के कारण मोबाइल IP की आवश्यकता होती है, तो इसे प्रॉक्सी पूल में अलग से शामिल करें, क्योंकि मोबाइल IP पर ट्रैफिक आमतौर पर रेसिडेंशियल या डेटा सेंटर की तुलना में महंगा होता है।

एक अच्छी प्रथा है कि 1,000–2,000 छवियों की एक पायलट पार्टी इकट्ठा करें, वास्तविक ट्रैफिक खर्च और त्रुटियों के प्रतिशत को मापें, और फिर इसे पूरे योजना बनाये गए डेटासेट के आकार पर एक्सट्रपोल करें। यह किसी भी सैद्धांतिक गणनाओं की तुलना में अधिक सटीक है, क्योंकि यह विशेष स्रोत की विशिष्टता को ध्यान में रखता है।

निष्कर्ष

कंप्यूटर विजन मॉडल के प्रशिक्षण के लिए छवियों को इकट्ठा करना डेटा इंजीनियरिंग और नेटवर्क इन्फ्रास्ट्रक्चर के कुशल प्रबंधन के बीच का कार्य है। पार्सर की सही वास्तुकला (असिंक्रोनस, Content-Length के अनुसार फ़िल्टरिंग, URL की डुप्लिकेशन) ट्रैफिक को बचाती है, जबकि प्रॉक्सी का सावधानीपूर्वक चयन यह निर्धारित करता है कि आप आवश्यक डेटासेट का आकार दिनों में इकट्ठा करेंगे या लगातार ब्लॉकों के कारण हफ्तों में।

यदि डेटा स्रोत उन्नत एंटी-बॉट सुरक्षा का उपयोग करते हैं — छवि खोज इंजन, मार्केटप्लेस, सोशल मीडिया — तो रेसिडेंशियल प्रॉक्सी से शुरू करें: ये बैन के प्रति स्थिरता और ट्रैफिक की लागत के बीच सबसे अच्छा संतुलन प्रदान करते हैं। ओपन API और बिना सख्त सीमाओं वाले स्टॉक्स के लिए, डेटा सेंटर प्रॉक्सी पर बचत करना समझदारी है, और सबसे सुरक्षित मोबाइल ऐप्स के लिए — अंतिम, सबसे कठिन संग्रह भाग के लिए मोबाइल प्रॉक्सी को कनेक्ट करें।