Large Scale Crawling: ארכיטקטורה וכלים | scraping.co.il

מה ההבדל האמיתי בין Crawling ל-Scraping?

בואו נשים את הדברים על השולחן. רוב האנשים משתמשים במונחים האלה לסירוגין, אבל הם טועים. ההבדל הוא לא סמנטי, הוא ארכיטקטוני. זה הבדל בין לבנות סירת דיג לבין לבנות נושאת מטוסים.

Scraping זה תהליך של חילוץ מידע מסט של דפים ידועים. יש לך רשימה של 10,000 כתובות URL של מוצרים, ואתה רוצה למשוך מהן מחיר, שם ותמונה. הבעיות שלך הן JavaScript rendering, חסימות IP, ו-CAPTCHAs. אתה נלחם באתר היעד.

Crawling, לעומת זאת, הוא תהליך של גילוי. אתה מתחיל עם כתובת אחת או כמה (seeds), והמטרה שלך היא למצוא את כל הקישורים הניתנים לגילוי מאותה נקודה, ולבנות מפה של האתר או של חלק מהאינטרנט. המטרה היא לא בהכרח לחלץ דאטה מכל דף, אלא למצוא דפים חדשים. הבעיות שלך הן ניהול מצב, מניעת כפילויות בקנה מידה של מיליונים, והימנעות מ"מלכודות עכביש" (spider traps).

ב-scraping, אתה יכול להריץ 100 בקשות במקביל לאותו דומיין (עם מספיק פרוקסיז). ב-crawling, לעשות את זה יהרוג את השרת של היעד ויכניס אותך לרשימה שחורה תוך דקות. האתגרים שונים לחלוטין.

לב ה-Crawler: ניהול ה-Frontier

כל crawler, לא משנה כמה הוא גדול, בנוי סביב רעיון מרכזי אחד: ה-Frontier. זה השם המקצועי לתור (queue) של כל ה-URLs שגילינו אבל עוד לא ביקרנו בהם. ניהול ה-frontier הוא 90% מהעבודה בבניית crawler רציני.

ה-frontier אחראי על כמה דברים קריטיים:

אחסון URLs חדשים: כל פעם שה-crawler מבקר בדף ומחלץ ממנו קישורים, הקישורים האלה נשלחים ל-frontier.
מניעת כפילויות (Deduplication): ה-frontier חייב לוודא שאנחנו לא מוסיפים לתור URL שכבר ביקרנו בו או שכבר נמצא בתור. בקנה מידה קטן, אפשר להשתמש ב-`set` פשוט בפייתון. בקנה מידה גדול, זה דורש פתרונות כמו Bloom filters או מסדי נתונים ייעודיים.
תעדוף (Prioritization): לא כל ה-URLs שווים. אולי נרצה לתעדף דפים שנמצאים בעומק רדוד יותר באתר, או דפים מ-sitemap, או דפים שמכילים מילות מפתח מסוימות. ה-frontier מחליט מה ה-worker הבא יקבל.
נימוס (Politeness): ה-crawler צריך להיות אזרח טוב ברשת. ה-frontier אוכף חוקים כמו שמירה על `crawl-delay` מתוך `robots.txt` ומוודא שאנחנו לא שולחים יותר מדי בקשות לאותו דומיין בפרק זמן קצר. אם לא תעשה את זה, אתה תתחיל לקבל שגיאות 429 ותיחסם. פרקטיקה טובה היא לא לשלוח יותר מבקשה אחת כל 2-3 שניות לאותו hostname בלי תלות במה שכתוב ב-`robots.txt`.

בלי frontier חכם, ה-crawler שלך הוא סתם לולאה אינסופית שתקרוס מהר מאוד.

ארכיטקטורה של Crawler מבוזר

כדי לסרוק מיליוני דפים, מכונה אחת לא תספיק. אתה צריך לעבור לארכיטקטורה מבוזרת. רוב המערכות הגדולות נראות פחות או יותר ככה:


# High-level conceptual components

[ Frontier Manager ] <--- (New URLs) --- [ Crawling Workers ]
       |                                          |
       |                                          |
 (URLs to fetch)                                  |
       |                                          |
       '-------------------> (Fetch Page) ----> [ Target Website ]

המרכיבים העיקריים הם:

Frontier Manager: שירות מרכזי (או מבוזר בעצמו) שמנהל את תור ה-URLs, מבצע deduplication, ומתעדף. זה המוח של המבצע.
Crawling Workers: צי של מכונות (או קונטיינרים) שהם "טיפשים". כל מה שהם יודעים לעשות זה לקבל URL מה-Frontier, לבצע את בקשת ה-HTTP, לחלץ קישורים מה-HTML שהתקבל, ולהחזיר את הקישורים החדשים שמצאו בחזרה ל-Frontier. הם stateless.
Scheduler/Dispatcher: הרכיב שמחלק את העבודה. הוא שואל את ה-Frontier "תביא לי 100 URLs לדומיין X", מקבל אותם, ומחלק אותם ל-workers פנויים.
Storage: מסד נתונים (לרוב NoSQL כמו Cassandra או HDFS) שבו נשמר התוכן הגולמי של הדפים שנסרקו, לצד המטא-דאטה שלהם.

הארכיטקטורה הזו מאפשרת סקייל אופקי. צריך עוד כוח? פשוט מוסיפים עוד workers. אם הנושא מעניין אתכם לעומק, יש לנו מאמר שלם על ארכיטקטורת web scraping בסקייל שמפרט את העקרונות האלה.

איפה הכל מתפרק: מלכודות עכביש (Spider Traps)

אז בנית מערכת יפה. יש לך frontier, יש לך workers. אתה מריץ אותה על אתר מסחר אלקטרוני גדול. אחרי כמה שעות, אתה מגלה שה-frontier שלך התנפח ל-50 מיליון URLs, ו-99% מהם הם זבל. מה קרה?

נפלת ב-spider trap קלאסית. אתרים מודרניים מייצרים אינסוף URLs באופן דינמי. חשבו על:

פילטרים וסיווגים: קישורים של סינון לפי צבע, מידה, מחיר, מותג... כל קומבינציה היא URL ייחודי. `?color=red`, `?color=red&size=M`, `?size=M&color=red`. הסדר משתנה, אבל התוכן זהה.
לוחות שנה: קישור ל"חודש הבא" יכול ליצור נתיב אינסופי אל העתיד.
פרמטרים של סשן: `?session_id=xyz123` שמתווסף לכל קישור.

ה-crawler התמים שלך ילך אחרי כל הקישורים האלה, ימלא את ה-frontier בזבל, ולעולם לא יגיע לדפים החשובים באמת. הפתרון הוא לא טכנולוגי, הוא לוגי: חוקים. אתה חייב להגדיר כללים ברורים לגבי אילו תבניות URL מותר ל-crawler לעקוב אחריהן. למשל, להתעלם מכל URL עם פרמטרים מסוימים, או להגביל את עומק הסריקה (depth limit).


import re

def is_valid_url_for_crawl(url):
    # דוגמה פשוטה מאוד
    # אל תעקוב אחרי קישורים עם פרמטרים של מעקב או סשן
    if re.search(r'[?&](utm_|session_id|ref)=', url):
        return False
    
    # אל תיכנס עמוק מדי למבנה עמודים
    # /category/page/3/, /category/page/4/ ...
    if re.search(r'/page/\d{2,}', url):
        return False

    return True

Canonicalization: המלחמה השקטה על כפילויות

מניעת כפילויות היא יותר מסובכת ממה שזה נשמע. ה-URLs הבאים מובילים כולם לאותו דף, אבל כמחרוזות הם שונים:

`http://example.com/page`
`https://example.com/page`
`https://www.example.com/page`
`https://example.com/page/`
`https://example.com/page?utm_source=google`

לפני שאתה מכניס URL ל-frontier (או בודק אם הוא כבר קיים), אתה חייב להעביר אותו תהליך Canonicalization. זה תהליך של נרמול ה-URL לצורה אחידה וקבועה.

פונקציית canonicalization טובה תעשה את הדברים הבאים:

תמיר הכל לאותיות קטנות (lowercase).
תוסיף/תסיר `www` לפי מדיניות קבועה.
תמיד תשתמש ב-`https` על פני `http`.
תסיר פרמטרים לא רלוונטיים (כמו `utm_` או `gclid`).
תסדר את הפרמטרים הנותרים בסדר אלפביתי.
תטפל ב-trailing slashes בצורה עקבית.

רק אחרי שהעברת את ה-URL בתהליך הזה, אתה בודק אם הוא קיים במאגר שלך. הזנחה של שלב זה תוביל לבזבוז עצום של משאבים על סריקת אותו תוכן שוב ושוב.

כלים ופרקטיקות ל-2025

אז איך בונים דבר כזה בפועל? רוב הסיכויים שאתה לא צריך להמציא את הגלגל מחדש.

Scrapy + Frontera: זו הבחירה המודרנית והגמישה ביותר. Scrapy היא ספריית הפייתון הטובה ביותר ל-scraping ו-crawling במכונה בודדת. Frontera הוא פרויקט שמתחבר ל-Scrapy והופך אותו למערכת מבוזרת. הוא מספק את שכבת ה-Frontier החכמה, ומאפשר לך להריץ עשרות spider-workers במקביל. זה השילוב המנצח לרוב הפרויקטים שצריכים לעבור מסקייל קטן לבינוני-גדול.

Apache Nutch: זה הפתרון הוותיק והבשל לתעשייה. Nutch הוא crawler מלא, מבוסס Java, שנבנה לעבוד על גבי Hadoop. הוא פחות גמיש מ-Scrapy, אבל אם המטרה שלך היא לבצע broad crawl על מאות מיליוני דפים, הוא בנוי בדיוק בשביל זה. זה כלי רציני למשימות רציניות.

מערכות פנימיות: חברות גדולות (גוגל, בינג, Common Crawl) בונות מערכות משלהן. למה? כי בסקייל של מיליארדי דפים, כל אופטימיזציה קטנה בפורמט האחסון או באלגוריתם התעדוף מתרגמת לחיסכון של מיליוני דולרים. רובנו לא שם.

ההמלצה שלי? התחילו עם Scrapy. כשתגיעו למגבלות של מכונה בודדת, שלבו את Frontera. זה ייתן לכם 95% מהיכולות שאתם צריכים, עם גמישות מקסימלית.

שאלות נפוצות

ההבדל המרכזי הוא ש-Frontera היא מערכת ניהול frontier מלאה, בעוד ש-Redis הוא מסד נתונים גנרי. Redis יכול לשמש כבסיס לתור פשוט (FIFO/LIFO), אבל Frontera מטפלת בלוגיקה מורכבת יותר "מהקופסה": תעדוף URLs, אכיפת מדיניות נימוס (politeness) פר-דומיין, ניהול מצב של סריקות (crawls), ושמירת מטא-דאטה על בקשות ותשובות. בניית כל היכולות האלה לבד על גבי Redis דורשת עבודת פיתוח משמעותית, בעוד ש-Frontera מספקת אותן כתשתית מוכנה שמתממשקת ישירות עם Scrapy.

טיפול ב-JavaScript בקנה מידה גדול הוא יקר מאוד מבחינת משאבים, ולכן הגישה חייבת להיות סלקטיבית. השלב הראשון הוא לסרוק את האתר ללא הרצת JS, עם HTTP client רגיל, ולנתח אילו דפים מחזירים תוכן ריק או חלקי. רק עבור הדומיינים או תבניות ה-URL הספציפיות האלה, מפעילים "שכבה שנייה" של עיבוד באמצעות headless browser כמו Playwright. ניתן לנהל תור נפרד עבור דפים הדורשים JS, המטופל על ידי workers ייעודיים וחזקים יותר. גישה היברידית זו חוסכת כ-80-90% מזמן ה-CPU ועלויות התשתית.

אסטרטגיה טובה לקביעת עומק סריקה מתחילה בניתוח ידני של מבנה האתר. רוב התוכן החשוב באתרים (מוצרים, מאמרים) נמצא בעומק של 2 עד 4 קליקים מדף הבית. לכן, התחלת הסריקה עם הגבלה לעומק 5 או 6 היא נקודת פתיחה בטוחה שמונעת נפילה למלכודות עכביש. לאחר סריקה ראשונית, ניתן לנתח את ה-URLs שנמצאו בעומק המרבי. אם רואים שם דפים חשובים, ניתן להגדיל את העומק באופן סלקטיבי עבור אזורים ספציפיים באתר, או להוסיף את הדפים האלה כ-seeds חדשים לסריקה הבאה.

Bloom Filter הוא מבנה נתונים הסתברותי שמאפשר לבדוק ביעילות רבה אם איבר מסוים (במקרה שלנו, URL קנוני) נמצא בקבוצה, תוך שימוש בכמות זיכרון קטנה משמעותית מאשר אחסון כל האיברים. הוא יכול לענות "לא, האיבר הזה בוודאות לא נמצא" או "יכול להיות שהאיבר הזה נמצא". כלומר, הוא מונע false negatives אבל מאפשר אחוז קטן של false positives. ב-crawling, זה אומר שבמקרים נדירים לא נסרוק URL שכבר היינו צריכים לסרוק, אבל זה מונע מאיתנו לאחסן מיליארדי URLs בזיכרון רק כדי לבדוק כפילויות, מה שהופך אותו לכלי יעיל מאוד למערכות ענק.

כדאי לבחור ב-Apache Nutch כאשר המטרה היא לבצע broad crawl כללי על חלקים גדולים מהאינטרנט, והגמישות היא פחות קריטית. Nutch הוא פתרון out-of-the-box שלם, מבוסס Java ו-Hadoop, שמיועד לעיבוד batch של מאות מיליוני דפים. לעומת זאת, פתרון מבוסס Scrapy ו-Frontera (בפייתון) הוא הרבה יותר גמיש ומודולרי. הוא מתאים יותר ל-crawls ממוקדים, גם אם הם גדולים, שבהם יש צורך בלוגיקה מותאמת אישית, אינטגרציה קלה עם ספריות Python אחרות, ופיתוח מהיר יותר של ה-crawler עצמו.

Web Crawling בקנה מידה גדול: המדריך המלא