اگر دنبال یک ابزار جدی برای اسکرپ کردن سایت ها در مقیاس واقعی هستی، کتابخانه scrapy دقیقا همان چیزی است که باید بشناسی. کتابخانه scrapy فقط یک ابزار برای گرفتن HTML نیست، بلکه یک چارچوب کامل برای ساخت کراولرهای سریع، قابل توسعه و قابل نگهداری است؛ مخصوصا وقتی با چندین صفحه، pagination، رندرهای پیچیده، محدودیت نرخ و خروجی های ساختاریافته سروکار داری.

چرا Scrapy برای کارهای پیشرفته انتخاب می شود

وقتی پروژه اسکرپینگ بزرگ می شود، اسکریپت های ساده با requests و BeautifulSoup خیلی زود به سقف می خورند. مدیریت صف درخواست ها، کنترل نرخ، retry، هندل کردن خطاها، ذخیره سازی خروجی، رعایت قوانین سایت و تمیز نگه داشتن کد به هم می ریزد. Scrapy این موارد را از ابتدا در طراحی خودش دارد و به تو اجازه می دهد به جای جنگیدن با جزئیات تکراری، روی منطق استخراج داده تمرکز کنی.

معماری Scrapy به زبان ساده

Scrapy چند جزء اصلی دارد که کنار هم کار می کنند. Spider منطق پیدا کردن لینک ها و استخراج داده را تعریف می کند. Scheduler صف درخواست ها را مدیریت می کند. Downloader درخواست ها را می فرستد و پاسخ ها را برمی گرداند. Item Pipeline داده های استخراج شده را تمیز و ذخیره می کند. Middleware ها هم وسط راه به تو اجازه می دهند درخواست و پاسخ را دستکاری کنی، مثلا هدرها را تغییر دهی یا Proxy تنظیم کنی. این معماری باعث می شود پروژه اسکرپینگ مثل یک نرم افزار واقعی قابل توسعه باشد.

شروع پروژه و ساخت Spider پایه

در Scrapy همه چیز معمولا از یک پروژه شروع می شود. بعد یک Spider می سازی که نقطه شروع و قوانین پیمایش را مشخص می کند. یک Spider ساده معمولا start_urls دارد و تابع parse که پاسخ را می گیرد و داده را استخراج می کند. اما در کار پیشرفته، همین Spider تبدیل می شود به یک موتور پیمایش که چند مرحله ای، چند صفحه ای و حتی چند دامنه ای کار می کند.

یک نمونه Spider تمیز برای صفحه لیست و صفحه جزئیات

این الگو در پروژه های واقعی خیلی استفاده می شود. اول صفحه لیست را می خوانی، لینک های جزئیات را در می آوری، بعد هر لینک را جداگانه parse می کنی.

import scrapy

class ProductsSpider(scrapy.Spider):
name = “products”
allowed_domains = [“example.com”]
start_urls = [“https://example.com/products”]

def parse(self, response):
for href in response.css(“a.product-card::attr(href)”).getall():
yield response.follow(href, callback=self.parse_detail)

next_page = response.css(“a.next::attr(href)”).get()
if next_page:
yield response.follow(next_page, callback=self.parse)

def parse_detail(self, response):
yield {
“title”: response.css(“h1::text”).get(default=“”).strip(),
“price”: response.css(“.price::text”).get(default=“”).strip(),
“sku”: response.css(“[data-sku]::attr(data-sku)”).get(),
“url”: response.url,
}

نکته مهم این است که response.follow مدیریت لینک نسبی و مطلق را انجام می دهد و کد را تمیز نگه می دارد.

استخراج داده حرفه ای با Selector های پایدار

در اسکرپینگ پیشرفته مشکل اصلی این نیست که داده را از HTML بیرون بکشی، مشکل این است که انتخابگرها با کوچک ترین تغییر UI نشکنند. بهتر است به جای کلاس هایی که ممکن است عوض شوند، دنبال الگوهای پایدارتر باشی. مثلا data attributes، ساختار تگ ها، یا موقعیت های منطقی در DOM. همچنین همیشه برای get مقدار پیش فرض بگذار تا با تغییرات جزئی، کراولر کامل نخوابد.

تمیزکاری داده همان موقع یا در Pipeline

یک تصمیم مهم این است که تمیزکاری را کجا انجام دهی. اگر تمیزکاری خیلی ساده است، داخل Spider انجام بده. اگر قرار است چند مرحله پاک سازی، تبدیل واحد، اعتبارسنجی یا dedup داشته باشی، Pipeline بهتر است. Pipeline باعث می شود Spider سبک بماند و مسئولیت ها قاطی نشوند.

Item ها و تایپ پذیری داده

وقتی پروژه رشد می کند، بهتر است Item تعریف کنی تا خروجی ساختارمند و قابل کنترل باشد. Item مثل یک قرارداد است که می گوید چه فیلدهایی داریم. این کار هم دیباگ را ساده می کند و هم کیفیت خروجی را بالا می برد.

import scrapy

class ProductItem(scrapy.Item):
title = scrapy.Field()
price = scrapy.Field()
sku = scrapy.Field()
url = scrapy.Field()

سپس در Spider به جای dict، Item برمی گردانی. این کار مخصوصا وقتی چند Pipeline داری یا خروجی را به دیتابیس می فرستی مفید است.

مدیریت Pagination و الگوهای پیمایش

Pagination فقط next page نیست. بعضی سایت ها page=2 دارند، بعضی infinite scroll دارند، بعضی هم فیلتر و دسته بندی پیچیده دارند. در Scrapy بهتر است به جای ساختن URL با string، از response.follow استفاده کنی و اگر لازم شد پارامترها را با urllib بسازی تا خطای URL کم شود. اگر سایت دسته بندی دارد، می توانی ابتدا صفحه دسته ها را بخوانی و برای هر دسته یک جریان جدا راه بیندازی.

کنترل سرعت و احترام به سایت

اسکرپینگ حرفه ای یعنی کنترل شده. Scrapy ابزارهای خوبی دارد مثل DOWNLOAD_DELAY، AUTOTHROTTLE، CONCURRENT_REQUESTS و RETRY. ایده اصلی این است که به جای هجوم، منطقی و پایدار درخواست بدهی تا هم کمتر بلاک شوی و هم فشار غیرعادی وارد نکنی. این تنظیمات در فایل settings.py انجام می شود و یکی از تفاوت های پروژه حرفه ای با اسکریپت ساده همین جاست.

تنظیمات پیشنهادی برای شروع منطقی

ROBOTSTXT_OBEY = True
DOWNLOAD_DELAY = 1.0
CONCURRENT_REQUESTS = 8
RETRY_TIMES = 3
AUTOTHROTTLE_ENABLED = True
AUTOTHROTTLE_START_DELAY = 1.0
AUTOTHROTTLE_MAX_DELAY = 10.0

این ها یک نقطه شروع هستند، نه نسخه قطعی. برای هر سایت باید با تست و مشاهده خطاها تنظیم شوند.

مدیریت Session، Cookie و Login

بعضی سایت ها بدون لاگین داده کامل نمی دهند یا بخشی از اطلاعات پشت سشن است. Scrapy به شکل پیش فرض Cookie را مدیریت می کند، اما برای لاگین باید مرحله ورود را مثل یک درخواست جدا ارسال کنی و بعد از آن با همان سشن ادامه دهی. معمولا از FormRequest استفاده می شود تا داده های فرم به شکل درست ارسال شوند.

import scrapy

class LoginSpider(scrapy.Spider):
name = “login_spider”
start_urls = [“https://example.com/login”]

def parse(self, response):
return scrapy.FormRequest.from_response(
response,
formdata={“username”: “user”, “password”: “pass”},
callback=self.after_login
)

def after_login(self, response):
if “logout” not in response.text.lower():
self.logger.error(“Login failed”)
return
yield response.follow(“https://example.com/private”, callback=self.parse_private)

def parse_private(self, response):
yield {“secret”: response.css(“.secret::text”).get()}

در پروژه واقعی، اطلاعات ورود را داخل کد هاردکد نکن و از env یا تنظیمات امن استفاده کن.

ضد بلاک شدن، User Agent و Proxy

سایت ها ممکن است با نرخ بالا یا الگوی ثابت درخواست ها تو را شناسایی کنند. یکی از کارهای رایج این است که User Agent را تنظیم کنی و در صورت نیاز از Proxy استفاده کنی. Scrapy این کار را با middleware ها ساده می کند. اما یادت باشد هدف، پنهان کاری افراطی نیست؛ هدف این است که رفتار کراولر طبیعی تر و پایدارتر باشد و تعداد خطاها کم شود.

کار با JSON API و داده های پشت شبکه

خیلی وقت ها داده اصلی داخل HTML نیست و از API برمی گردد. در این حالت، بهترین کار این است که همان endpoint را پیدا کنی و مستقیم JSON بگیری. Scrapy برای این کار عالی است چون مدیریت درخواست ها و خروجی همچنان همان چارچوب را دارد. فقط به جای CSS selector، با json.loads داده را parse می کنی و فیلدها را بیرون می کشی.

خروجی گرفتن درست و قابل استفاده

Scrapy خروجی را راحت به JSON، JSONL، CSV و حتی XML می دهد. اما در پروژه های جدی، معمولا خروجی باید وارد دیتابیس شود یا روی صف پیام برود. اینجا Pipeline بهترین جاست. مثلا می توانی داده ها را normalize کنی، مقدارهای خالی را حذف کنی، تبدیل قیمت انجام دهی و سپس ذخیره کنی. خروجی خوب یعنی بعدا برای تحلیل و استفاده مجدد دردسر نداشته باشی.

دیباگ و تست در اسکرپینگ پیشرفته

اسکرپینگ بدون دیباگ یعنی وقت تلف کردن. Scrapy ابزارهایی مثل shell دارد که اجازه می دهد همان پاسخ را تعاملی بررسی کنی و selector ها را تست کنی. همچنین لاگ ها را جدی بگیر. اگر خطاهای 403 یا 429 زیاد می بینی، یعنی نرخ یا هدرها مشکل دارند. اگر داده خالی است، یعنی selector ها شکسته اند یا صفحه متفاوت شده. یک روال ساده بساز؛ اول با shell، بعد با یک URL محدود، بعد با اجرای کامل.

هندل کردن خطاها و پایداری طولانی مدت

در پروژه واقعی، همیشه صفحات ناقص، تایم اوت، ریدایرکت عجیب یا HTML خراب وجود دارد. Scrapy با retry و handling به تو کمک می کند، اما بهتر است خودت هم موارد مهم را مدیریت کنی. مثلا اگر یک فیلد حیاتی خالی شد، آن آیتم را علامت گذاری کن تا بعدا بررسی شود. اگر تعداد خطاهای یک دامنه بالا رفت، سرعت را کم کن. این نگاه باعث می شود اسکرپر هفته ها پایدار بماند، نه اینکه یک شب کار کند و بعد بخوابد.

جمع بندی

کتابخانه scrapy برای زمانی است که اسکرپینگ را مثل یک پروژه واقعی می بینی، نه یک اسکریپت یک بار مصرف. با معماری Spider، Pipeline و Middleware می توانی یک سیستم پیمایش بسازی که هم سریع باشد، هم قابل توسعه، هم قابل کنترل. اگر روی انتخابگرهای پایدار، کنترل نرخ، مدیریت سشن و خروجی تمیز تمرکز کنی، نتیجه دقیقا همان چیزی می شود که از وب اسکرپینگ پیشرفته انتظار داری.